Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime
So this commit worries me.
This bug is a good find, and the fix is obviously needed and urgent, but I'm
not
sure about the implementation at all. (I've Cc:-ed a few more x86 low level
gents.)
* Matt Fleming wrote:
> /*
> + * Iterate the EFI memory map in reverse order because the regions
> + * will be mapped top-down. The end result is the same as if we had
> + * mapped things forward, but doesn't require us to change the
> + * existing implementation of efi_map_region().
> + */
> +static inline void *efi_map_next_entry_reverse(void *entry)
> +{
> + /* Initial call */
> + if (!entry)
> + return memmap.map_end - memmap.desc_size;
> +
> + entry -= memmap.desc_size;
> + if (entry < memmap.map)
> + return NULL;
> +
> + return entry;
> +}
> +
> +/*
> + * efi_map_next_entry - Return the next EFI memory map descriptor
> + * @entry: Previous EFI memory map descriptor
> + *
> + * This is a helper function to iterate over the EFI memory map, which
> + * we do in different orders depending on the current configuration.
> + *
> + * To begin traversing the memory map @entry must be %NULL.
> + *
> + * Returns %NULL when we reach the end of the memory map.
> + */
> +static void *efi_map_next_entry(void *entry)
> +{
> + if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
> + /*
> + * Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE
> + * config table feature requires us to map all entries
> + * in the same order as they appear in the EFI memory
> + * map. That is to say, entry N must have a lower
> + * virtual address than entry N+1. This is because the
> + * firmware toolchain leaves relative references in
> + * the code/data sections, which are split and become
> + * separate EFI memory regions. Mapping things
> + * out-of-order leads to the firmware accessing
> + * unmapped addresses.
> + *
> + * Since we need to map things this way whether or not
> + * the kernel actually makes use of
> + * EFI_PROPERTIES_TABLE, let's just switch to this
> + * scheme by default for 64-bit.
The thing is, if relative accesses between these 'sections' do happen then the
requirement is much stronger than just 'ordered by addresses' - then we must
map
them continuously and as a single block!
So at minimum the comment should say that. But I think we want more:
> + */
> + return efi_map_next_entry_reverse(entry);
> + }
> +
> + /* Initial call */
> + if (!entry)
> + return memmap.map;
> +
> + entry += memmap.desc_size;
> + if (entry >= memmap.map_end)
> + return NULL;
> +
> + return entry;
> +}
> +
> +/*
> * Map the efi memory ranges of the runtime services and update new_mmap with
> * virtual addresses.
> */
> @@ -714,7 +778,8 @@ static void * __init efi_map_regions(int *count, int
> *pg_shift)
> unsigned long left = 0;
> efi_memory_desc_t *md;
>
> - for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> + p = NULL;
> + while ((p = efi_map_next_entry(p))) {
> md = p;
> if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
So why is this 64-bit only? Is 32-bit not affected because there we allocate
virtual addresses bottom-up?
This would be a lot clearer if we just mapped the entries in order, no
questions
asked. Conditions like this:
> + if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
... just invite confusion and possible corner cases where we end up mapping
them
wrong.
So could we make the whole code obviously bottom-up? Such as first calculating
the
size of virtual memory needed, then allocating a _single_, obviously continuous
mapping, and then doing a very clear in-order mapping within that window? That
would remove any bitness and legacy dependencies.
Good virtual memory layout is so critical for any third party code that this
should be the central property of the whole approach, not just some side
condition
somewhere in an iteration loop.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] remoteproc: Add additional crash reasons
The Qualcomm WCNSS can crash by watchdog or a fatal software error. Add
these types to the list of remoteproc crash reasons.
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/remoteproc_core.c | 2 ++
include/linux/remoteproc.h | 4
2 files changed, 6 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 45eef766dd41..cad59ec938b1 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -57,6 +57,8 @@ static DEFINE_IDA(rproc_dev_index);
static const char * const rproc_crash_names[] = {
[RPROC_MMUFAULT]= "mmufault",
+ [RPROC_WATCHDOG]= "watchdog",
+ [RPROC_FATAL_ERROR] = "fatal error",
};
/* translate rproc_crash_type to string */
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index 9c4e1384f636..1c457a8dd5a6 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -365,6 +365,8 @@ enum rproc_state {
/**
* enum rproc_crash_type - remote processor crash types
* @RPROC_MMUFAULT:iommu fault
+ * @RPROC_WATCHDOG:watchdog bite
+ * @RPROC_FATAL_ERROR fatal error
*
* Each element of the enum is used as an array index. So that, the value of
* the elements should be always something sane.
@@ -373,6 +375,8 @@ enum rproc_state {
*/
enum rproc_crash_type {
RPROC_MMUFAULT,
+ RPROC_WATCHDOG,
+ RPROC_FATAL_ERROR,
};
/**
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] remoteproc: qcom: Introduce WCNSS peripheral image loader
This introduces the peripheral image loader, for loading WCNSS firmware
and boot the core on e.g. MSM8974. The firmware is verified and booted
with the help of the Peripheral Authentication System (PAS) in
TrustZone.
Signed-off-by: Bjorn Andersson
---
The mdt loader is kept separate as it's used to load the ADSP and VENUS (video
processor) firmware as well.
drivers/remoteproc/Kconfig | 11 +
drivers/remoteproc/Makefile | 2 +
drivers/remoteproc/qcom_mdt_loader.c | 213
drivers/remoteproc/qcom_mdt_loader.h | 8 +
drivers/remoteproc/qcom_wcnss.c | 615 +++
5 files changed, 849 insertions(+)
create mode 100644 drivers/remoteproc/qcom_mdt_loader.c
create mode 100644 drivers/remoteproc/qcom_mdt_loader.h
create mode 100644 drivers/remoteproc/qcom_wcnss.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 28c711f0ac6b..f4eb07907851 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -77,4 +77,15 @@ config DA8XX_REMOTEPROC
It's safe to say n here if you're not interested in multimedia
offloading.
+config QCOM_MDT_LOADER
+ tristate
+
+config QCOM_WCNSS_PIL
+ tristate "Qualcomm WCNSS Peripheral Image Loader"
+ depends on OF && ARCH_QCOM
+ select REMOTEPROC
+ select QCOM_MDT_LOADER
+ help
+ Peripherial Image Loader for the WCNSS block.
+
endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 81b04d1e2e58..beb9a4be7ffd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_STE_MODEM_RPROC) += ste_modem_rproc.o
obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
+obj-$(CONFIG_QCOM_MDT_LOADER) += qcom_mdt_loader.o
+obj-$(CONFIG_QCOM_WCNSS_PIL) += qcom_wcnss.o
diff --git a/drivers/remoteproc/qcom_mdt_loader.c
b/drivers/remoteproc/qcom_mdt_loader.c
new file mode 100644
index ..30d67f3e63c1
--- /dev/null
+++ b/drivers/remoteproc/qcom_mdt_loader.c
@@ -0,0 +1,213 @@
+/*
+ * Qualcomm Peripheral Image Loader
+ *
+ * Copyright (C) 2015 Sony Mobile Communications Inc
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "remoteproc_internal.h"
+
+#define segment_is_hash(flag) (((flag) & (0x7 << 24)) == (0x2 << 24))
+
+static int segment_is_loadable(const struct elf32_phdr *p)
+{
+ return (p->p_type == PT_LOAD) &&
+ !segment_is_hash(p->p_flags) &&
+ p->p_memsz;
+}
+
+/**
+ * rproc_mdt_sanity_check() - sanity check mdt firmware header
+ * @rproc: the remote processor handle
+ * @fw: the mdt header firmware image
+ *
+ * Returns 0 for a valid header, -EINVAL otherwise.
+ */
+int qcom_mdt_sanity_check(struct rproc *rproc,
+ const struct firmware *fw)
+{
+ struct elf32_hdr *ehdr;
+
+ if (!fw) {
+ dev_err(>dev, "failed to load %s\n", rproc->name);
+ return -EINVAL;
+ }
+
+ if (fw->size < sizeof(struct elf32_hdr)) {
+ dev_err(>dev, "image is too small\n");
+ return -EINVAL;
+ }
+
+ ehdr = (struct elf32_hdr *)fw->data;
+ if (memcmp(ehdr->e_ident, ELFMAG, SELFMAG)) {
+ dev_err(>dev, "image is corrupted (bad magic)\n");
+ return -EINVAL;
+ }
+
+ if (ehdr->e_phnum == 0) {
+ dev_err(>dev, "no loadable segments\n");
+ return -EINVAL;
+ }
+
+ if (sizeof(struct elf32_phdr) * ehdr->e_phnum +
+ sizeof(struct elf32_hdr) > fw->size) {
+ dev_err(>dev, "firmware size is too small\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_mdt_sanity_check);
+
+/**
+ * qcom_mdt_find_rsc_table() - provide dummy resource table for remoteproc
+ * @rproc: remoteproc handle
+ * @fw:firmware header
+ * @tablesz: outgoing size of the table
+ *
+ * Returns a dummy table.
+ */
+struct resource_table *qcom_mdt_find_rsc_table(struct rproc *rproc,
+ const struct firmware *fw,
+
[PATCH 1/4] remoteproc: core: Make the loaded resource table optional
Remote processors like the ones found in the Qualcomm SoCs does not have
a resource table passed to them, so make it optional by only populating
it if it does exist.
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/remoteproc_core.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 8b3130f22b42..45eef766dd41 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -854,12 +854,8 @@ static int rproc_fw_boot(struct rproc *rproc, const struct
firmware *fw)
* copy this information to device memory.
*/
loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
- if (!loaded_table) {
- ret = -EINVAL;
- goto clean_up;
- }
-
- memcpy(loaded_table, rproc->cached_table, tablesz);
+ if (loaded_table)
+ memcpy(loaded_table, rproc->cached_table, tablesz);
/* power up the remote processor */
ret = rproc->ops->start(rproc);
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] dt-binding: remoteproc: Introduce Qualcomm WCNSS loader binding
The document defines the binding for a component that loads firmware for
and boots the Qualcomm WCNSS core.
Signed-off-by: Bjorn Andersson
---
.../bindings/remoteproc/qcom,wcnss-pil.txt | 107 +
1 file changed, 107 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
new file mode 100644
index ..9fbaf564662e
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
@@ -0,0 +1,107 @@
+Qualcomm WCNSS Peripheral Image Loader
+
+This document defines the binding for a component that loads and boots firmware
+on the Qualcomm WCNSS core.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,riva-pil",
+ "qcom,pronto-v1-pil",
+ "qcom,pronto-v2-pil"
+
+- reg:
+ Usage: required
+ Value type:
+ Definition: base address and size of riva/pronto PMU registers
+
+- interrupts-extended:
+ Usage: required
+ Value type:
+ Definition: should specify the watchdog, fatal, ready, handover and
+ stop-ack IRQs, in order.
+
+- interrupt-names:
+ Usage: required
+ Value type:
+ Definition: should be "wdog", "fatal", "ready", "handover", "stop-ack"
+
+- clocks:
+ Usage: required
+ Value type:
+ Definition: should specify the xo clock and optionally the rf_clk
+
+- clock-names:
+ Usage: requireduired
+ Value type:
+ Definition: should be "xo", optionally followed by "rf"
+
+- qcom,firmware-name:
+ Usage: required
+ Value type:
+ Definition: name of the firmware to be loaded
+
+- qcom,crash-reason:
+ Usage: required
+ Value type:
+ Definition: SMEM item used by WCNSS for storing the error messages upon
+ a fatal exception
+
+- qcom,iris-vddxo-supply:
+- qcom,iris-vddrfa-supply:
+- qcom,iris-vddpa-supply:
+- qcom,iris-vdddig-supply:
+- qcom,pronto-vddmx-supply:
+- qcom,pronto-vddcx-supply:
+- qcom,pronto-vddpx-supply:
+ Usage: required
+ Value type:
+ Definition: reference to the regulators to be held on behalf of the
+ booting of the WCNSS core
+
+- qcom,state:
+ Usage: required
+ Value type:
+ Definition: reference to the SMEM state used to indicate to WCNSS that
+ it should shut down
+
+- qcom,state-names:
+ Usage: required
+ Value type:
+ Definition: should be "stop"
+
+= EXAMPLE
+
+pronto_rproc@fb21b000 {
+ compatible = "qcom,pronto-v2-pil";
+ reg = <0xfb21b000 0x3000>;
+
+ interrupts-extended = < 0 149 1>,
+ <_smp2p_slave 0 0>,
+ <_smp2p_slave 1 0>,
+ <_smp2p_slave 2 0>,
+ <_smp2p_slave 3 0>;
+ interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
+
+ clocks = < RPM_CXO_CLK_SRC>, < RPM_CXO_A2>;
+ clock-names = "xo", "rf";
+
+ qcom,firmware-name = "wcnss";
+
+ qcom,crash-reason = <422>;
+
+ qcom,iris-vddxo-supply = <_l6>;
+ qcom,iris-vddrfa-supply = <_l11>;
+ qcom,iris-vddpa-supply = <_l19>;
+ qcom,iris-vdddig-supply = <_s3>;
+ qcom,pronto-vddmx-supply = <_s1>;
+ qcom,pronto-vddcx-supply = <_s2>;
+ qcom,pronto-vddpx-supply = <_s3>;
+
+ qcom,state = <_smp2p_out 0>;
+ qcom,state-names = "stop";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pin_a>;
+};
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] WCNSS Peripheral Image Loader
This series provides the minimum changes needed to use remotproc on the Qualcomm platform, it then introduces the Peripheral Image Loader for the WCNSS core. The implementation depends on https://lkml.org/lkml/2015/9/24/723 Bjorn Andersson (4): remoteproc: core: Make the loaded resource table optional remoteproc: Add additional crash reasons remoteproc: qcom: Introduce WCNSS peripheral image loader dt-binding: remoteproc: Introduce Qualcomm WCNSS loader binding .../bindings/remoteproc/qcom,wcnss-pil.txt | 107 drivers/remoteproc/Kconfig | 11 + drivers/remoteproc/Makefile| 2 + drivers/remoteproc/qcom_mdt_loader.c | 213 +++ drivers/remoteproc/qcom_mdt_loader.h | 8 + drivers/remoteproc/qcom_wcnss.c| 615 + drivers/remoteproc/remoteproc_core.c | 10 +- include/linux/remoteproc.h | 4 + 8 files changed, 964 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt create mode 100644 drivers/remoteproc/qcom_mdt_loader.c create mode 100644 drivers/remoteproc/qcom_mdt_loader.h create mode 100644 drivers/remoteproc/qcom_wcnss.c -- 1.8.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT] Networking
1) When we run a tap on netlink sockets, we have to copy mmap'd SKBs instead of cloning them. From Daniel Borkmann. 2) When converting classical BPF into eBPF, fix the setting of the source reg to BPF_REG_X. From Tycho Andersen. 3) Fix igmpv3/mldv2 report parsing in the bridge multicast code, from Linus Lussing. 4) Fix dst refcounting for ipv6 tunnels, from Martin KaFai Lau. 5) Set NLM_F_REPLACE flag properly when replacing ipv6 routes, from Roopa Prabhu. 6) Add some new cxgb4 PCI device IDs, from Hariprasad Shenai. 7) Fix headroom tests and SKB leaks in ipv6 fragmentation code, from FLorian Westphal. 8) Check DMA mapping errors in bna driver, from Ivan Vecera. 9) Several 8139cp bug fixes (dev_kfree_skb_any in interrupt context, misclearing of interrupt status in TX timeout handler, etc.) from David Woodhouse. 10) In tipc, reset SKB header pointer after skb_linearize(), from Erik Hugne. 11) Fix autobind races et al. in netlink code, from Herbert Xu with help from Tejun Heo and others. 12) Missing SET_NETDEV_DEV in sunvnet driver, from Sowmini Varadhan. 13) Fix various races in timewait timer and reqsk_queue_hadh_req, from Eric Dumazet. 14) Fix array overruns in mac80211, from Johannes Berg and Dan Carpenter. 15) Fix data race in rhashtable_rehash_one(), from Dmitriy Vyukov. 16) Fix race between poll_one_napi and napi_disable, from Neil Horman. 17) Fix byte order in geneve tunnel port config, from John W. Linville. 18) Fix handling of ARP replies over lightweight tunnels, from Jiri Benc. 19) We can loop when fib rule dumps cross multiple SKBs, fix from Wilson Kok and Roopa Prabhu. 20) Several reference count handling bug fixes in the PHY/MDIO layer from Russel King. 21) Fix lockdep splat in ppp_dev_uninit(), from Guillaume Nault. 22) Fix crash in icmp_route_lookup(), from David Ahern. Please pull, thanks a lot! The following changes since commit 64d1def7d33856824d2c5c6fd6d4579d4d54bb87: Merge tag 'sound-fix-4.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2015-09-11 09:42:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net for you to fetch changes up to bdb06cbf77cb01911694cc9076ffa8196b7b9b61: net: Fix panic in icmp_route_lookup (2015-09-25 21:44:02 -0700) Alexey Khoroshilov (1): irda: ali-ircc: Fix deadlock in ali_ircc_sir_change_speed() Arnd Bergmann (1): bnx2x: use ktime_get_seconds() for timestamp Daniel Borkmann (1): netlink, mmap: transform mmap skb into full skb on taps David Ahern (3): net: Add documentation for VRF device net: Fix vti use case with oif in dst lookups net: Fix panic in icmp_route_lookup David S. Miller (10): Merge branch 'ip6tunnel_dst' Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth Merge branch 'vxlan-fixes' Merge git://git.kernel.org/.../pablo/nf Merge branch 'net-of-autoload' Merge branch 'phy-of-autoload' Merge branch 'netcp-fixes' Merge branch 'lwt_arp' Merge tag 'mac80211-for-davem-2015-09-22' of git://git.kernel.org/.../jberg/mac80211 Merge branch 'phy-mdio-refcnt' David Woodhouse (10): solos-pci: Increase headroom on received packets 8139cp: Use dev_kfree_skb_any() instead of dev_kfree_skb() in cp_clean_rings() 8139cp: Call __cp_set_rx_mode() from cp_tx_timeout() Fix AF_PACKET ABI breakage in 4.2 8139cp: Do not re-enable RX interrupts in cp_tx_timeout() 8139cp: Fix tx_queued debug message to print correct slot numbers 8139cp: Fix TSO/scatter-gather descriptor setup 8139cp: Reduce duplicate csum/tso code in cp_start_xmit() 8139cp: Fix DMA unmapping of transmitted buffers 8139cp: Dump contents of descriptor ring on TX timeout Dmitriy Vyukov (1): lib: fix data race in rhashtable_rehash_one Eric Dumazet (6): net/mlx4_en: really allow to change RSS key tcp_cubic: do not set epoch_start in the future tcp/dccp: fix timewait races in timer handling inet: fix races in reqsk_queue_hash_req() tcp: add proper TS val into RST packets bnx2x: byte swap rss_key to comply to Toeplitz specs Erik Hugne (1): tipc: reinitialize pointer after skb linearize Florian Westphal (3): netfilter: nf_log: don't zap all loggers on unregister netfilter: bridge: fix routing of bridge frames with call-iptables=1 ipv6: ip6_fragment: fix headroom tests and skb leak Guillaume Nault (1): ppp: fix lockdep splat in ppp_dev_uninit() Hariprasad Shenai (1): cxgb4: add device ID for few T5 adapters Herbert Xu (2): netlink: Fix autobind race condition that leads to zero port ID netlink: Replace rhash_portid with bound Ivan Vecera (1): bna: check for dma mapping errors Javier Martinez Canillas
[PATCH 3/4] tools/power turbostat: KNL workaround for %Busy and Avg_MHz
From: Hubert Chrzaniuk
KNL increments APERF and MPERF every 1024 clocks.
This is compliant with the architecture specification,
which requires that only the ratio of APERF/MPERF need be valid.
However, turbostat takes advantage of the fact that these
two MSRs increment every un-halted clock
at the actual and base frequency:
AVG_MHz = APERF_delta/measurement_interval
%Busy = MPERF_delta/TSC_delta
This quirk is needed for these calculations to also work on KNL,
which would otherwise show a value 1024x smaller than expected.
Signed-off-by: Hubert Chrzaniuk
Signed-off-by: Len Brown
---
tools/power/x86/turbostat/turbostat.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index e05d3033..d333c81 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -71,6 +71,7 @@ unsigned int extra_msr_offset32;
unsigned int extra_msr_offset64;
unsigned int extra_delta_offset32;
unsigned int extra_delta_offset64;
+unsigned int aperf_mperf_multiplier = 1;
int do_smi;
double bclk;
unsigned int show_pkg;
@@ -984,6 +985,8 @@ int get_counters(struct thread_data *t, struct core_data
*c, struct pkg_data *p)
return -3;
if (get_msr(cpu, MSR_IA32_MPERF, >mperf))
return -4;
+ t->aperf = t->aperf * aperf_mperf_multiplier;
+ t->mperf = t->mperf * aperf_mperf_multiplier;
}
if (do_smi) {
@@ -2541,6 +2544,13 @@ int is_knl(unsigned int family, unsigned int model)
return 0;
}
+unsigned int get_aperf_mperf_multiplier(unsigned int family, unsigned int
model)
+{
+ if (is_knl(family, model))
+ return 1024;
+ return 1;
+}
+
#define SLM_BCLK_FREQS 5
double slm_freq_table[SLM_BCLK_FREQS] = { 83.3, 100.0, 133.3, 116.7, 80.0};
@@ -2742,6 +2752,9 @@ void process_cpuid()
}
}
+ if (has_aperf)
+ aperf_mperf_multiplier = get_aperf_mperf_multiplier(family,
model);
+
do_nhm_platform_info = do_nhm_cstates = do_smi = probe_nhm_msrs(family,
model);
do_snb_cstates = has_snb_msrs(family, model);
do_pc2 = do_snb_cstates && (pkg_cstate_limit >= PCL__2);
--
2.6.0.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] tools/power turbostat: IVB Xeon: fix --debug regression
From: Len Brown
Staring in Linux-4.3-rc1,
commit 6fb3143b561c ("tools/power turbostat: dump CONFIG_TDP")
touches MSR 0x648, which is not supported on IVB-Xeon.
This results in "turbostat --debug" exiting on those systems:
turbostat: /dev/cpu/2/msr offset 0x648 read failed: Input/output error
Remove IVB-Xeon from the list of machines supporting with that MSR.
Signed-off-by: Len Brown
---
tools/power/x86/turbostat/turbostat.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index 9655cb4..e05d3033 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -1926,8 +1926,6 @@ int has_config_tdp(unsigned int family, unsigned int
model)
switch (model) {
case 0x3A: /* IVB */
- case 0x3E: /* IVB Xeon */
-
case 0x3C: /* HSW */
case 0x3F: /* HSX */
case 0x45: /* HSW */
--
2.6.0.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] tools/power turbostat: SKL: Adjust for TSC difference from base frequency
From: Len Brown
On a Skylake with 1500MHz base frequency,
the TSC runs at 1512MHz.
This is because the TSC is no longer in the n*100 MHz BCLK domain,
but is now in the m*24MHz crystal clock domain. (24 MHz * 63 = 1512 MHz)
This adds error to several calculations in turbostat,
unless the TSC sample sizes are adjusted for this difference.
Note that calculations in the time domain are immune
from this issue, as the timing sub-system has already
calibrated the TSC against a known wall clock.
AVG_MHz = APERF_delta/measurement_interval
need no adjustment. APERF_delta is in the BCLK domain,
and measurement_interval is in the time domain.
TSC_MHz = TSC_delta/measurement_interval
needs no adjustment -- as we really do want to report
the actual measured TSC delta here, and measurement_interval
is in the accurate time domain.
%Busy = MPERF_delta/TSC_delta
needs adjustment to use TSC_BCLK_DOMAIN_delta.
TSC_BCLK_DOMAIN_delta = TSC_delta * base_hz / tsc_hz
Bzy_MHz = TSC_delta/APERF_delta/MPERF_delta/measurement_interval
need adjustment as above.
No other metrics in turbostat need to be adjusted.
Before:
CPU Avg_MHz %Busy Bzy_MHz TSC_MHz
- 550 24.8422161512
02191 98.7322191514
2 00.0121301512
1 90.4320161512
3 20.0820161512
After:
CPU Avg_MHz %Busy Bzy_MHz TSC_MHz
- 550 25.0521981512
02190 99.6221991512
2 00.0121521512
1 90.4620001512
3 20.1020001512
Note that in this example, the "Before" Bzy_MHz
was reported as exceeding the 2200 max turbo rate.
Also, even a pinned spin loop would not be reported
as over 99% busy.
Signed-off-by: Len Brown
---
tools/power/x86/turbostat/turbostat.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index d333c81..31d756b 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -74,6 +74,8 @@ unsigned int extra_delta_offset64;
unsigned int aperf_mperf_multiplier = 1;
int do_smi;
double bclk;
+double base_hz;
+double tsc_tweak = 1.0;
unsigned int show_pkg;
unsigned int show_core;
unsigned int show_cpu;
@@ -503,7 +505,7 @@ int format_counters(struct thread_data *t, struct core_data
*c,
/* %Busy */
if (has_aperf) {
if (!skip_c0)
- outp += sprintf(outp, "%8.2f", 100.0 * t->mperf/t->tsc);
+ outp += sprintf(outp, "%8.2f", 100.0 *
t->mperf/t->tsc/tsc_tweak);
else
outp += sprintf(outp, "");
}
@@ -511,7 +513,7 @@ int format_counters(struct thread_data *t, struct core_data
*c,
/* Bzy_MHz */
if (has_aperf)
outp += sprintf(outp, "%8.0f",
- 1.0 * t->tsc / units * t->aperf / t->mperf /
interval_float);
+ 1.0 * t->tsc * tsc_tweak / units * t->aperf / t->mperf
/ interval_float);
/* TSC_MHz */
outp += sprintf(outp, "%8.0f", 1.0 * t->tsc/units/interval_float);
@@ -1152,6 +1154,19 @@ int slv_pkg_cstate_limits[16] = {PCL__0, PCL__1, PCLRSV,
PCLRSV, PCL__4, PCLRSV,
int amt_pkg_cstate_limits[16] = {PCL__0, PCL__1, PCL__2, PCLRSV, PCLRSV,
PCLRSV, PCL__6, PCL__7, PCLRSV, PCLRSV, PCLRSV, PCLRSV, PCLRSV, PCLRSV, PCLRSV,
PCLRSV};
int phi_pkg_cstate_limits[16] = {PCL__0, PCL__2, PCL_6N, PCL_6R, PCLRSV,
PCLRSV, PCLRSV, PCLUNL, PCLRSV, PCLRSV, PCLRSV, PCLRSV, PCLRSV, PCLRSV, PCLRSV,
PCLRSV};
+
+static void
+calculate_tsc_tweak()
+{
+ unsigned long long msr;
+ unsigned int base_ratio;
+
+ get_msr(base_cpu, MSR_NHM_PLATFORM_INFO, );
+ base_ratio = (msr >> 8) & 0xFF;
+ base_hz = base_ratio * bclk * 100;
+ tsc_tweak = base_hz / tsc_hz;
+}
+
static void
dump_nhm_platform_info(void)
{
@@ -2773,6 +2788,9 @@ void process_cpuid()
if (debug)
dump_cstate_pstate_config_info();
+ if (has_skl_msrs(family, model))
+ calculate_tsc_tweak();
+
return;
}
--
2.6.0.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
intel_idle and turbostat patches for Linux-4.3
Hi Rafael, The following patches are available on my "intel_idle" and "turbostat" branches, as usual, plus here for review. [PATCH 1/4] intel_idle: Skylake Client Support - updated Initial SKL intel_idle support went into 4.3-rc1. That patch works, but this patch makes it more optimal, under some conditions. [PATCH 2/4] tools/power turbostat: IVB Xeon: fix --debug regression This is a regression fix for a 4.1-rc1 patch It was rude for turbostat to start failing on IVB-Xeon boxes. [PATCH 3/4] tools/power turbostat: KNL workaround for %Busy and This works around a newly documented hardware quirk. [PATCH 4/4] tools/power turbostat: SKL: Adjust for TSC difference This works around an accuracy error that initially looked insignificant, but on some configurations it will be big enough to be noticed and confuse users, so here we address it fully. Thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] intel_idle: Skylake Client Support - updated
From: Len Brown
Addition of PC9 state, and minor tweaks to existing PC6 and PC8 states.
Signed-off-by: Len Brown
---
drivers/idle/intel_idle.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 3a3738f..cd4510a 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -620,7 +620,7 @@ static struct cpuidle_state skl_cstates[] = {
.name = "C6-SKL",
.desc = "MWAIT 0x20",
.flags = MWAIT2flg(0x20) | CPUIDLE_FLAG_TLB_FLUSHED,
- .exit_latency = 75,
+ .exit_latency = 85,
.target_residency = 200,
.enter = _idle,
.enter_freeze = intel_idle_freeze, },
@@ -636,11 +636,19 @@ static struct cpuidle_state skl_cstates[] = {
.name = "C8-SKL",
.desc = "MWAIT 0x40",
.flags = MWAIT2flg(0x40) | CPUIDLE_FLAG_TLB_FLUSHED,
- .exit_latency = 174,
+ .exit_latency = 200,
.target_residency = 800,
.enter = _idle,
.enter_freeze = intel_idle_freeze, },
{
+ .name = "C9-SKL",
+ .desc = "MWAIT 0x50",
+ .flags = MWAIT2flg(0x50) | CPUIDLE_FLAG_TLB_FLUSHED,
+ .exit_latency = 480,
+ .target_residency = 5000,
+ .enter = _idle,
+ .enter_freeze = intel_idle_freeze, },
+ {
.name = "C10-SKL",
.desc = "MWAIT 0x60",
.flags = MWAIT2flg(0x60) | CPUIDLE_FLAG_TLB_FLUSHED,
--
2.6.0.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan
On Tue, 2015-09-15 at 09:07AM +0800, Shawn Lin wrote: > On 2015/9/14 23:07, Sören Brinkmann wrote: > >Hi Shawn, > > > >overall, it looks good to me. I have some questions though. > > > >On Mon, 2015-09-14 at 02:29PM +0800, Shawn Lin wrote: > > [...] > > >>+err_phy_exit: > >>+ phy_init(phy); > > > >Just to confirm, are these actions in the error path correct? E.g. > >if the power_off() call fails, is it safe to call power_on()? Isn't > >the phy still powered on? (this would apply to other error paths too) > > > > Cool question! > > While writing this, I had read generic phy stuffs deliberately to find a > solution for a case: how to deal with ping-pong fails? In another word, if > power_off call fails, then we should call power_on, but unfortunately it > fails again then we call power_off... so endless nested err handling... No > answer yet. > > So, I assumed two cases happened when power_off call fails: > (1) *real power_off* is done, but some other stuffs in the calling path > fail, so phy is really power_off in theory. We need to power_on it again, > but if it fail, we don't know PHY is on or off since we don't know power_on > fails for what? *real power on* ? some other stuffs? > > (2) *real power_off* isn't completed, so indeed it's *still* in power_on > state. The reason we never need to check the return value of power_on cross > the err handling is that whether power_on call successfully or not, it's > always make phy in power_on state. > > Now, let's think about case(1). > After reading dozens of sample codes(such as USB, UFS, MBUS) that adopt > generic phy framework for PHY management, real thing should be like that: > they NEVER deal with case(1). > > It's a trick of sub-phy drivers themself. power_on/off calling path return > err for two case: > <1> phy_runtime callback fails. It's after *real power on/off*, so > definitely *real power on/off* is conpleted. That is the case(2) I mentioned > above. > <2> sub-phy drivers return err for phy->ops->power_off(phy); Look > into all the sub-phy drivers twice, we find that they always return success > for phy->ops->power_off hook. Why? Because all of them > write registers to enable/disable something, always consider things going > well. Actually if we write value into a register, we have to think that it's > functional. > > Anyway, back to this patch. > Indeed we also write value into arasan phy's register to do > phy_power_on/off/init/exit to make things work. Right, we return success > state for all of these them just as all the other sub-phy drivers do. > > Feel free to let me know if I make mistakes or misunderstanding above. > > >>+ return ret; > >>+} > > [...] > > >>+ } > >>+ } > > > >I assume you looked at options for having the error paths in a > >consolidated location? I guess this may be the nicest solution since all > >of this is in this conditional block? > > > > yep, otherwise we should add some *if* statements to check sdhci_arasan->phy > cross the err handles. And I intent to strictly limit > the phy stuffs under the scope of arasan,sdhci-5.1 currently. > > >Feel free to add my > >Acked-by: Sören Brinkmann > > > > Thanks, Sören. :) Makes all sense to me. Thanks for all the details. Sören -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
iwlwifi: Error sending REPLY_ADD_STA
Hello, sometimes the Wifi adapter (Wireless-N 2230) in this Lenovo Thinkpad E431 "disappears" and cannot be fixed by re-loading the iwlwifi kernel module either. Only a reboot will do. When I was running 3.16.0-4-amd64 from Debian/stable, I noticed the following message, but only _once_ and Wifi worked fine even with that message: iwlwifi :04:00.0: Error sending REPLY_TX_LINK_QUALITY_CMD: time out after 2000ms. iwlwifi :04:00.0: Current CMD queue read_ptr 25 write_ptr 26 iwlwifi :04:00.0: Loaded firmware version: 18.168.6.1 iwlwifi :04:00.0: Microcode SW error detected. Restarting 0x200. Now with Linux 4.2 it happens more often, I'll attach a the error below, the full kernel logs and .config can be found here: http://nerdbynature.de/bits/v4.2/ The initial error messages so far: Linux version 3.16.0-4-amd64, Aug 17 iwlwifi :04:00.0: Error sending REPLY_TX_LINK_QUALITY_CMD: time out after 2000ms. Linux version 4.2.0-rc7, Aug 30 iwlwifi :04:00.0: Error sending REPLY_ADD_STA: time out after 2000ms. Linux version 4.2.0, Sep 19 iwlwifi :04:00.0: Error sending REPLY_ADD_STA: time out after 2000ms. Linux version 4.2.0, Sep 20 iwlwifi :04:00.0: Error sending REPLY_ADD_STA: time out after 2000ms. Linux version 4.2.0, Sep 25 iwlwifi :04:00.0: Error sending REPLY_ADD_STA: time out after 2000ms. I found old reports of these messages on the net, but either they were marked fixed[0] or years old[1][2] or not applicable to my card[3] Does anybody has an idea what's going on here? Thanks, Christian. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1029785 [1] https://answers.launchpad.net/ubuntu/+source/gnome-nettool/+question/221076 [2] https://lkml.org/lkml/2012/2/8/247 [3] https://lists.fedoraproject.org/pipermail/users/2011-June/400906.html === dmesg usb 1-3: USB disconnect, device number 2 iwlwifi :04:00.0: Error sending REPLY_ADD_STA: time out after 2000ms. iwlwifi :04:00.0: Current CMD queue read_ptr 192 write_ptr 193 [ cut here ] WARNING: CPU: 2 PID: 25891 at /usr/local/src/linux-git/drivers/net/wireless/iwlwifi/pcie/trans.c:1444 iwl_trans_pcie_grab_nic_access+0x100/0x110 [iwlwifi]() Timeout waiting for hardware access (CSR_GP_CNTRL 0x) Modules linked in: md4 nls_iso8859_15 cifs auth_rpcgss oid_registry nfsv4 dns_resolver xfs libcrc32c ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter xt_conntrack nf_conntrack ip_tables x_tables ctr ccm pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) nfs lockd grace fscache sunrpc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev sha256_ssse3 sha256_generic hmac x86_pkg_temp_thermal drbg snd_hda_codec_hdmi intel_powerclamp coretemp aesni_intel aes_x86_64 glue_helper arc4 lrw gf128mul ablk_helper cryptd snd_hda_codec_conexant snd_hda_codec_generic snd_pcsp psmouse iwldvm snd_hda_intel snd_hda_codec mac80211 snd_hwdep iwlwifi snd_hda_core cfg80211 lpc_ich i2c_i801 snd_pcm snd_timer snd shpchp soundcore battery ac processor loop fuse autofs4 mmc_block hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid btrfs xor raid6_pq rtsx_pci_sdmmc mmc_core xhci_pci ehci_pci xhci_hcd e hci_hcd sr_mod cdrom sg rtsx_pci usbcore mfd_core usb_common thermal CPU: 2 PID: 25891 Comm: kworker/u16:1 Tainted: G O4.2.0 #2 Hardware name: LENOVO 6277CTO/6277CTO, BIOS HEET48WW (1.29 ) 03/13/2015 Workqueue: phy0 ieee80211_ba_session_work [mac80211] c0327bd8 baacb049 c0327bd8 8158173a 8801cffb7aa0 8104ccb7 8800c27f4000 8800c27f7ca8 8801cffb7b38 8104cd48 Call Trace: [] ? dump_stack+0x40/0x50 [] ? warn_slowpath_common+0x77/0xb0 [] ? warn_slowpath_fmt+0x58/0x80 [] ? iwl_trans_pcie_grab_nic_access+0x100/0x110 [iwlwifi] [] ? iwl_write_prph+0x2e/0x70 [iwlwifi] [] ? iwl_force_nmi+0x1d/0x60 [iwlwifi] [] ? iwl_trans_pcie_send_hcmd+0x3c0/0x420 [iwlwifi] [] ? wait_woken+0x80/0x80 [] ? iwl_send_add_sta+0x7f/0xd0 [iwldvm] [] ? iwl_sta_rx_agg_stop+0xfb/0x150 [iwldvm] [] ? iwlagn_mac_ampdu_action+0x103/0x1e0 [iwldvm] [] ? ___ieee80211_stop_rx_ba_session+0xaf/0x1b0 [mac80211] [] ? ieee80211_ba_session_work+0x100/0x170 [mac80211] [] ? process_one_work+0x137/0x360 [] ? pwq_activate_delayed_work+0x27/0x40 [] ? worker_thread+0x5d/0x450 [] ? perf_cgroup_switch+0x1a0/0x1a0 [] ? rescuer_thread+0x310/0x310 [] ? kthread+0xda/0xf0 [] ? kthread_create_on_node+0x1b0/0x1b0 [] ? ret_from_fork+0x3f/0x70 [] ? kthread_create_on_node+0x1b0/0x1b0 ---[ end trace 6435c974dd1d2317 ]--- iwlwifi :04:00.0: Loaded firmware version: 18.168.6.1 iwlwifi :04:00.0: Start IWL Error Log Dump: iwlwifi :04:00.0: Status: 0x004C, count: -30719 iwlwifi :04:00.0: 0xBAACB049 | ADVANCED_SYSASSERT iwlwifi :04:00.0: 0x | uPc
Re: [PATCH net-next v3] net: Fix Hisilicon Network Subsystem Support Compilation
From: huangdaode
Date: Fri, 25 Sep 2015 16:29:50 +0800
> @@ -191,9 +191,12 @@ static void hns_rcb_ring_init(struct ring_pair_cb
> *ring_pair, int ring_type)
> if (ring_type == RX_RING) {
> dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_L_REG,
> (u32)dma);
> +#ifdef CONFIG_64BIT
> dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_H_REG,
> (u32)(dma >> 32));
> -
> +#else
> + dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_H_REG, 0);
> +#endif
> dsaf_write_dev(q, RCB_RING_RX_RING_BD_LEN_REG,
> bd_size_type);
> dsaf_write_dev(q, RCB_RING_RX_RING_BD_NUM_REG,
CONFIG_64BIT doesn't tell you if _DMA_ addresses are 64-bit or not.
Furthermore there is a portable way to shift a 32-bit value down
32-bits whilst avoiding warnings.
(x >> 31) >> 1
So you should definitely use that instead of the CONFIG_64BIT test.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Glibc recvmsg from kernel netlink socket hangs forever
Herbert, On 09/25/2015 08:55 AM, Herbert Xu wrote: On Thu, Sep 24, 2015 at 10:34:10PM -0700, Guenter Roeck wrote: Any idea what may be needed for 4.1 ? I am currently trying https://patchwork.ozlabs.org/patch/473041/, This patch should not make any difference on 4.1 and later because 4.1 is where I rewrote rhashtable resizing and it should work (or if it is broken then the latest kernel should be broken too). but I have no idea if that will help with the problem we are seeing there. Having looked at your message agin I don't think the issue I alluded to is relevant since the symptom there ought to be a straight kernel lock-up as opposed to just a user-space one because you will end up with the kernel sending a message to itself. And the fact that 4.2 works is more indicative as the bug is present in both 4.1 and 4.2. I'll try to reproduce this in 4.1 as time permits but no promises. After applying your two patches, I don't see the problem in 4.1 anymore. We'll run the system through regression; the complete cycle may take a couple of weeks. I'll let you know if we find any further problems. If you submit additional patches in that area, it would be great if you can Cc: me. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi
$ objdump --dwarf drivers/powercap/intel_rapl.o |grep iosf <65ad> DW_AT_name: (indirect string, offset: 0x3644): iosf_mbi_read <65f7> DW_AT_name: (indirect string, offset: 0x496): iosf_mbi_write 5300iosf_mbi.h 0x0490 656c5f69 6400696f 73665f6d 62695f77 el_id.iosf_mbi_w 0x3640 72656700 696f7366 5f6d6269 5f726561 reg.iosf_mbi_rea $ grep -i iosf_mbi .config # CONFIG_IOSF_MBI is not set It is compiled and included by header file. Pengyu On 09/25/2015 12:33 AM, Jacob Pan wrote: On Thu, 24 Sep 2015 18:03:32 +0800 Pengyu Ma wrote: So the problematic case is when RAPL=Y IOSF=M Since real IOSF functions are available when #if IS_ENABLED(CONFIG_IOSF_MBI) There will be no dummy functions for RAPL to reference in this case. iosf_mbi_write/read will warn itself. it does not compile. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dax: fix deadlock in __dax_fault
On Fri, Sep 25, 2015 at 12:53:57PM +1000, Dave Chinner wrote:
> On Thu, Sep 24, 2015 at 09:50:29AM -0600, Ross Zwisler wrote:
> > On Thu, Sep 24, 2015 at 12:52:25PM +1000, Dave Chinner wrote:
> > > On Wed, Sep 23, 2015 at 02:40:00PM -0600, Ross Zwisler wrote:
> > > > Fix the deadlock exposed by xfstests generic/075. Here is the sequence
> > > > that was causing us to deadlock:
> > > >
> > > > 1) enter __dax_fault()
> > > > 2) page = find_get_page() gives us a page, so skip
> > > > i_mmap_lock_write(mapping)
> > > > 3) if (!buffer_mapped() && !buffer_unwritten() && !vmf->cow_page)
> > > > passes, enter this block
> > > > 4) if (vmf->flags & FAULT_FLAG_WRITE) fails, so do the else case and
> > > > i_mmap_unlock_write(mapping);
> > > > return dax_load_hole(mapping, page, vmf);
> > > >
> > > > This causes us to up_write() a semaphore that we weren't holding.
> > > >
> > > > The up_write() on a semaphore we didn't down_write() happens twice in
> > > > a row, and then the next time we try and i_mmap_lock_write(), we hang.
> > > >
> > > > Signed-off-by: Ross Zwisler
> > > > Reported-by: Dave Chinner
> > > > ---
> > > > fs/dax.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/fs/dax.c b/fs/dax.c
> > > > index 7ae6df7..df1b0ac 100644
> > > > --- a/fs/dax.c
> > > > +++ b/fs/dax.c
> > > > @@ -405,7 +405,8 @@ int __dax_fault(struct vm_area_struct *vma, struct
> > > > vm_fault *vmf,
> > > > if (error)
> > > > goto unlock;
> > > > } else {
> > > > - i_mmap_unlock_write(mapping);
> > > > + if (!page)
> > > > + i_mmap_unlock_write(mapping);
> > > > return dax_load_hole(mapping, page, vmf);
> > > > }
> > > > }
> > >
> > > I can't review this properly because I can't work out how this
> > > locking is supposed to work. Captain, we have a Charlie Foxtrot
> > > situation here:
> > >
> > > page = find_get_page(mapping, vmf->pgoff)
> > > if (page) {
> > >
> > > } else {
> > > i_mmap_lock_write(mapping);
> > > }
> > >
> > > So if there's no page in the page cache, we lock the i_mmap_lock.
> > > The we have the case the above patch fixes. Then later:
> > >
> > > if (vmf->cow_page) {
> > > .
> > > if (!page) {
> > > /* can fall through */
> > > }
> > > return VM_FAULT_LOCKED;
> > > }
> > >
> > > Which means __dax_fault() can also return here with the
> > > i_mmap_lock_write() held. There's no documentation to indicate why
> > > this is valid, and only by looking about 4 function calls higher up
> > > the stack can I see that there's some attempt to handle this
> > > *specific return condition* (in do_cow_fault()). That also is
> > > lacking in documentation explaining the circumstances where we might
> > > have the i_mmap_lock_write() held and have to release it. (Not to
> > > mention the beautiful copy-n-waste of the unlock code, either.)
> > >
> > > The above code in __dax_fault() is then followed by this gem:
> > >
> > > /* Check we didn't race with a read fault installing a new page */
> > > if (!page && major)
> > > page = find_lock_page(mapping, vmf->pgoff);
> > >
> > > if (page) {
> > > /* mapping invalidation */
> > > }
> > > .
> > >
> > > if (!page)
> > > i_mmap_unlock_write(mapping);
> > >
> > > Which means that if we had a race with another read fault, we'll
> > > remove the page from the page cache, insert the new direct mapped
> > > pfn into the mapping, and *then fail to unlock the i_mmap lock*.
> > >
> > > Is this supposed to work this way? Or is it another bug?
> > >
> > > Another difficult question this change of locking raised that I
> > > can't answer: is it valid to call into the filesystem via getblock()
> > > or complete_unwritten() while holding the i_mmap_rwsem? This puts
> > > filesystem transactions and locks inside the scope of i_mmap_rwsem,
> > > which may have impact on the fact that we already have an inode lock
> > > order dependency w.r.t. i_mmap_rwsem through truncate (and probably
> > > other paths, too).
> > >
> > > So, please document the locking model, explain the corner cases and
> > > the intricacies like why *unbalanced, return value conditional
> > > locking* is necessary, and update the charts of lock order
> > > dependencies in places like mm/filemap.c, and then we might have
> > > some idea of how much of a train-wreck this actually is
> >
> > Yep, I saw these too, but didn't yet know how to deal with them. We have at
> > similar issues with __dax_pmd_fault():
> >
> > i_mmap_lock_write(mapping);
> > length = get_block(inode, block, , write);
> > if (length)
> > return VM_FAULT_SIGBUS;
> >
> > Whoops, we
Re: Glibc recvmsg from kernel netlink socket hangs forever
On 09/25/2015 02:37 PM, Steven Schlansker wrote: On Sep 24, 2015, at 10:34 PM, Guenter Roeck wrote: Herbert, On 09/24/2015 09:58 PM, Herbert Xu wrote: On Thu, Sep 24, 2015 at 09:36:53PM -0700, Guenter Roeck wrote: http://comments.gmane.org/gmane.linux.network/363085 might explain your problem. I thought this was resolved in 4.1, but it looks like the problem still persists there. At least I have reports from my workplace that 4.1.6 and 4.1.7 are still affected. I don't know if there have been any relevant changes in 4.2. Copying Herbert and Eric for additional input. There was a separate bug discovered by Tejun recently. You need to apply the patches https://patchwork.ozlabs.org/patch/519245/ https://patchwork.ozlabs.org/patch/520824/ I assume this is on top of mainline ? There is another follow-up but it shouldn't make any difference in practice. Any idea what may be needed for 4.1 ? I am currently trying https://patchwork.ozlabs.org/patch/473041/, but I have no idea if that will help with the problem we are seeing there. Thank you for the patches to try, I'll build a kernel with them early next week and report back. It sounds like it may not match my problem exactly so we'll see. In the meantime, I also observed the following oops: [ 1709.620092] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 1709.624058] BUG: unable to handle kernel paging request at ea001dbef3c0 [ 1709.624058] IP: [] 0xea001dbef3c0 [ 1709.624058] PGD 78f7dc067 PUD 78f7db067 PMD 80078ec001e3 [ 1709.624058] Oops: 0011 [#1] SMP [ 1709.624058] Modules linked in: i2c_piix4(E) btrfs(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) aesni_intel(E) aes_x86_64(E) lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) cryptd(E) floppy(E) [ 1709.624058] CPU: 4 PID: 19714 Comm: pf_dump Tainted: GE 4.0.4 #1 For 4.0.x, you _really_ need to update to 4.0.9 to get the following two patches. cf8befcc1a55 netlink: Disable insertions/removals during rehash 18889a4315a5 netlink: Reset portid after netlink_insert failure Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] f2fs: do not skip dentry block writes
Previously, we skip dentry block writes when wbc is SYNC_NONE with no memory
pressure and the number of dirty pages is pretty small.
But, we didn't skip for normal data writes, which gives us not much big impact
on overall performance.
Moreover, by skipping some data writes, kworker falls into infinite loop to try
to write blocks, when many dir inodes have only one dentry block.
So, this patch removes skipping data writes.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c| 5 -
fs/f2fs/node.c| 5 -
fs/f2fs/node.h| 1 -
fs/f2fs/segment.h | 4 +---
4 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index bc04e92..a903423 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1340,11 +1340,6 @@ static int f2fs_write_data_pages(struct address_space
*mapping,
if (!get_dirty_pages(inode) && wbc->sync_mode == WB_SYNC_NONE)
return 0;
- if (S_ISDIR(inode->i_mode) && wbc->sync_mode == WB_SYNC_NONE &&
- get_dirty_pages(inode) < nr_pages_to_skip(sbi, DATA) &&
- available_free_memory(sbi, DIRTY_DENTS))
- goto skip_write;
-
/* during POR, we don't need to trigger writepage at all. */
if (unlikely(is_sbi_flag_set(sbi, SBI_POR_DOING)))
goto skip_write;
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 4d9bedf..1fe49ca 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -52,11 +52,6 @@ bool available_free_memory(struct f2fs_sb_info *sbi, int
type)
mem_size = (nm_i->nat_cnt * sizeof(struct nat_entry)) >>
PAGE_CACHE_SHIFT;
res = mem_size < ((avail_ram * nm_i->ram_thresh / 100) >> 2);
- } else if (type == DIRTY_DENTS) {
- if (sbi->sb->s_bdi->wb.dirty_exceeded)
- return false;
- mem_size = get_pages(sbi, F2FS_DIRTY_DENTS);
- res = mem_size < ((avail_ram * nm_i->ram_thresh / 100) >> 1);
} else if (type == INO_ENTRIES) {
int i;
diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
index 7427e95..51c62ed 100644
--- a/fs/f2fs/node.h
+++ b/fs/f2fs/node.h
@@ -118,7 +118,6 @@ static inline void raw_nat_from_node_info(struct
f2fs_nat_entry *raw_ne,
enum mem_type {
FREE_NIDS, /* indicates the free nid list */
NAT_ENTRIES,/* indicates the cached nat entry */
- DIRTY_DENTS,/* indicates dirty dentry pages */
INO_ENTRIES,/* indicates inode entries */
EXTENT_CACHE, /* indicates extent cache */
BASE_CHECK, /* check kernel status */
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index b6e4ed1..a294da7 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -697,9 +697,7 @@ static inline int nr_pages_to_skip(struct f2fs_sb_info
*sbi, int type)
if (sbi->sb->s_bdi->wb.dirty_exceeded)
return 0;
- if (type == DATA)
- return sbi->blocks_per_seg;
- else if (type == NODE)
+ if (type == NODE)
return 3 * sbi->blocks_per_seg;
else if (type == META)
return MAX_BIO_BLOCKS(sbi);
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] drm/i915: PSR regressions on Broadwell
When using PSR, I see the screen freeze after only a few frames (sometimes a
split second; sometimes it seems like practically the first frame). Bisecting
led me to commit 3301d4092106 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT
logic") in v4.2. This patch is the simplest fix that gets it working again for
me, but it's probably wrong.
Random thought: perhaps my panel's DPCD is programmed incorrectly?
Anyway, any tips on fixing this properly?
Seen on Chromebook Pixel 2.
Also required this patch to get PSR properly running on 4.3-rc2:
https://patchwork.freedesktop.org/patch/57698/
Signed-off-by: Brian Norris
---
drivers/gpu/drm/i915/intel_psr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 7e335a8546f6..4cd33b76b8a6 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -261,7 +261,8 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp)
uint32_t val = 0x0;
const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
- if (intel_dp->psr_dpcd[1] & DP_PSR_NO_TRAIN_ON_EXIT) {
+ if ((intel_dp->psr_dpcd[1] & DP_PSR_NO_TRAIN_ON_EXIT) &&
+ !IS_BROADWELL(dev)) {
/* It doesn't mean we shouldn't send TPS patters, so let's
send the minimal TP1 possible and skip TP2. */
val |= EDP_PSR_TP1_TIME_100us;
--
2.6.0.rc2.230.g3dd15c0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 3/7] powerpc: atomic: Implement atomic{,64}_{add,sub}_return_* variants
On Fri, Sep 25, 2015 at 02:29:04PM -0700, Paul E. McKenney wrote:
> On Wed, Sep 23, 2015 at 08:07:55AM +0800, Boqun Feng wrote:
> > On Tue, Sep 22, 2015 at 08:25:40AM -0700, Paul E. McKenney wrote:
> > > On Tue, Sep 22, 2015 at 07:37:04AM +0800, Boqun Feng wrote:
> > > > On Tue, Sep 22, 2015 at 07:26:56AM +0800, Boqun Feng wrote:
> > > > > On Mon, Sep 21, 2015 at 11:24:27PM +0100, Will Deacon wrote:
> > > > > > Hi Boqun,
> > > > > >
> > > > > > On Sun, Sep 20, 2015 at 09:23:03AM +0100, Boqun Feng wrote:
> > > > > > > On Sat, Sep 19, 2015 at 11:33:10PM +0800, Boqun Feng wrote:
> > > > > > > > On Fri, Sep 18, 2015 at 05:59:02PM +0100, Will Deacon wrote:
> > > > > > > > > On Wed, Sep 16, 2015 at 04:49:31PM +0100, Boqun Feng wrote:
> > > > > > > > > > On powerpc, we don't need a general memory barrier to
> > > > > > > > > > achieve acquire and
> > > > > > > > > > release semantics, so __atomic_op_{acquire,release} can be
> > > > > > > > > > implemented
> > > > > > > > > > using "lwsync" and "isync".
> > > > > > > > >
> > > > > > > > > I'm assuming isync+ctrl isn't transitive, so we need to get
> > > > > > > > > to the bottom
> > > > > > > >
> > > > > > > > Actually the transitivity is still guaranteed here, I think ;-)
> > > > > >
> > > > > > The litmus test I'm thinking of is:
> > > > > >
> > > > > >
> > > > > > {
> > > > > > 0:r2=x;
> > > > > > 1:r2=x; 1:r5=z;
> > > > > > 2:r2=z; 2:r4=x;
> > > > > > }
> > > > > > P0 | P1| P2 ;
> > > > > > li r1,1 | lwz r1,0(r2) | lwz r1,0(r2) ;
> > > > > > stw r1,0(r2) | cmpw r1,r1| cmpw r1,r1 ;
> > > > > > | beq LC00 | beq LC01;
> > > > > > | LC00: | LC01:;
> > > > > > | isync | isync;
> > > > > > | li r4,1 | lwz r3,0(r4) ;
> > > > > > | stw r4,0(r5) | ;
> > > > > > exists
> > > > > > (1:r1=1 /\ 2:r1=1 /\ 2:r3=0)
> > > > > >
> > > > > >
> > > > > > Which appears to be allowed. I don't think you need to worry about
> > > > > > backwards
> > > > > > branches for the ctrl+isync construction (none of the current
> > > > > > example do,
> > > > > > afaict).
> > > > > >
> > > > >
> > > > > Yes.. my care of backwards branches is not quite related to the
> > > > > topic, I
> > > > > concerned that mostly because my test is using atomic operation, and I
> > > > > just want to test the exact asm code.
> > > > >
> > > > > > Anyway, all the problematic cases seem to arise when we start mixing
> > > > > > ACQUIRE/RELEASE accesses with relaxed accesses (i.e. where an
> > > > > > access from
> > > > > > one group reads from an access in the other group). It would be
> > > > > > simplest
> > > > > > to say that this doesn't provide any transitivity guarantees, and
> > > > > > that
> > > > > > an ACQUIRE must always read from a RELEASE if transitivity is
> > > > > > required.
> > > > > >
> > > > >
> > > > > Agreed. RELEASE alone doesn't provide transitivity and transitivity is
> > > > ^^^
> > > > This should be ACQUIRE...
> > > >
> > > > > guaranteed only if an ACQUIRE read from a RELEASE. That's exactly the
> > > > > direction which the link (https://lkml.org/lkml/2015/9/15/836) is
> > > > > heading to. So I think we are fine here to use ctrl+isync here, right?
> > >
> > > We are going to have to err on the side of strictness, that is, having
> > > the documentation place more requirements on the developer than the union
> > > of the hardware does. Besides, I haven't heard any recent complaints
> > > that memory-barriers.txt is too simple. ;-)
> >
> > Agreed ;-)
> >
> > For atomic operations, using isync in ACQUIRE operations does gaurantee
> > that a pure RELEASE/ACQUIRE chain provides transitivity. So, again, I
> > think we are fine here to use isync in ACQUIRE atomic operations,
> > unless you think we need to be more strict, i.e, making ACQUIRE itself
> > provide transitivy?
>
> As I understand it, either isync or lwsync suffices, with the choice
> depending on the hardware. The kernel will rewrite itself at boot time
> if you use the appropriate macro. ;-)
>
Yep ;-)
Thank you and Will both for your comments. To be honest, I just began to
learn about these transitivity and cumulativity things recently. That's
a lot of fun to discuss these with you, Peter and Will, and the
herdtools you suggested and the N2745 document you wrote really helped a
lot. Thank you again!
Regards,
Boqun
signature.asc
Description: PGP signature
Re: [PATCH] platform: x86: PMC IPC depends on ACPI
On 09/25/15 09:38, Lee Jones wrote: > This patch solves: > > on x86_64: > > when CONFIG_ACPI is not enabled: > > ../drivers/mfd/intel_soc_pmic_bxtwc.c: In function 'bxtwc_probe': > ../drivers/mfd/intel_soc_pmic_bxtwc.c:342:2: > error: implicit declaration of function 'acpi_evaluate_integer' > [-Werror=implicit-function-declaration] > status = acpi_evaluate_integer(handle, "_HRV", NULL, ); > ^ > > Reported-by: Randy Dunlap > Signed-off-by: Lee Jones Works for me. Thanks. Acked-by: Randy Dunlap > --- > drivers/platform/x86/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig > index c69bb70..744cb80 100644 > --- a/drivers/platform/x86/Kconfig > +++ b/drivers/platform/x86/Kconfig > @@ -914,6 +914,7 @@ config PVPANIC > > config INTEL_PMC_IPC > tristate "Intel PMC IPC Driver" > + depends on ACPI > ---help--- > This driver provides support for PMC control on some Intel platforms. > The PMC is an ARC processor which defines IPC commands for communication > -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 4.3-rc1 build error on CentOS 5.11 "scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or directory"
On Fri, Sep 25, 2015 at 7:24 AM, David Howells wrote: > Here's my patch with the changes squashed into it for reference. > > David > --- > commit 81852354cf81402ae69fda4d67138accab2702d5 > Author: David Howells > Date: Thu Sep 24 14:06:02 2015 +0100 > > MODSIGN: Change from CMS to PKCS#7 signing if the openssl is too old > > The sign-file.c program actually uses CMS rather than PKCS#7 to sign a > file > since that allows the target X.509 certificate to be specified by > subjectKeyId rather than by issuer + serialNumber. > > However, older versions of the OpenSSL crypto library (such as may be > found > in CentOS 5.11) don't support CMS. Assume everything prior to > OpenSSL-1.0.0 doesn't support CMS and switch to using PKCS#7 in that case. > > Further, the pre-1.0.0 OpenSSL only supports PKCS#7 signing with SHA1, so > give an error from the sign-file script if the caller requests anything > other than SHA1. > > The compiler gives the following error with an OpenSSL crypto library > that's too old: > > HOSTCC scripts/sign-file > scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or > directory > #include > > Reported-by: Vinson Lee > Signed-off-by: David Howells > Acked-by: David Woodhouse > This squashed patch also builds for me on CentOS 5.11. Linux 4.2-rc2 plus this patch booted up without issue and it appears this feature is available. $ dmesg | grep -i 'x.*509' [1.888412] Asymmetric key parser 'x509' registered [3.485152] Loading compiled-in X.509 certificates [3.490659] Loaded X.509 cert 'Build time autogenerated kernel key: ea8ef2f666280e4d429a8ff8a2056069bbb55979' Vinson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:610:33: sparse: symbol 'pxtal_data' was not declared. Should it be static?
Hi Enric, FYI, build test results on v4.3-rc2 (pls ignore if it's inappropriate base for your patch). reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:610:33: sparse: symbol >> 'pxtal_data' was not declared. Should it be static? >> drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:643:6: sparse: symbol >> 'sp_tx_initialization' was not declared. Should it be static? >> drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:2188:6: sparse: symbol >> 'sp_initialization' was not declared. Should it be static? >> drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:649:30: sparse: cast >> truncates bits from constant value (ff7f becomes 7f) drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:2129:30: sparse: cast truncates bits from constant value (ff7f becomes 7f) >> drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:2140:38: sparse: cast >> truncates bits from constant value (ff1f becomes 1f) Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH linux-review] drm: bridge: anx78xx: pxtal_data[] can be static
Signed-off-by: Fengguang Wu
---
slimport_tx_drv.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
b/drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
index 7721326..9afebab 100644
--- a/drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
+++ b/drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
@@ -607,7 +607,7 @@ static void hdmi_rx_initialization(struct anx78xx *anx78xx)
hdmi_rx_set_termination(anx78xx, 0);
}
-struct anx78xx_clock_data const pxtal_data[XTAL_CLK_NUM] = {
+static struct anx78xx_clock_data const pxtal_data[XTAL_CLK_NUM] = {
{19, 192},
{24, 240},
{25, 250},
@@ -640,7 +640,7 @@ static void xtal_clk_sel(struct anx78xx *anx78xx)
((pxtal_data[XTAL_27M].xtal_clk >> 1) - 2) << 3);
}
-void sp_tx_initialization(struct anx78xx *anx78xx)
+static void sp_tx_initialization(struct anx78xx *anx78xx)
{
sp_write_reg(anx78xx, TX_P0, AUX_CTRL2, 0x30);
sp_write_reg_or(anx78xx, TX_P0, AUX_CTRL2, 0x08);
@@ -2185,7 +2185,7 @@ static void sp_config_audio_output(struct anx78xx
*anx78xx)
/**End Audio process/
-void sp_initialization(struct anx78xx *anx78xx)
+static void sp_initialization(struct anx78xx *anx78xx)
{
/* Waitting Hot plug event! */
if (!(sp.common_int_status.common_int[3] & PLUG))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] devm_memremap_pages: use numa_mem_id
Hint to closest numa node for the placement of newly allocated pages.
As that is where the device's other allocations will originate by
default when it does not specify a NUMA node.
Cc: Christoph Hellwig
Cc: Ross Zwisler
Signed-off-by: Dan Williams
---
kernel/memremap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 72b0c66628b6..86a5cdeb18f2 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -175,7 +175,7 @@ void *devm_memremap_pages(struct device *dev, struct
resource *res)
nid = dev_to_node(dev);
if (nid < 0)
- nid = 0;
+ nid = numa_mem_id();
error = arch_add_memory(nid, res->start, resource_size(res), true);
if (error) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] devm: make allocations numa aware by default
Given we already have a device just use dev_to_node() to provide hint
allocations for devres. However, current devres_alloc() users will need
to explicitly opt-in with devres_alloc_node().
Signed-off-by: Dan Williams
---
drivers/base/devres.c | 19 ++-
include/linux/device.h | 16
2 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 875464690117..8fc654f0807b 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -82,12 +82,12 @@ static struct devres_group * node_to_group(struct
devres_node *node)
}
static __always_inline struct devres * alloc_dr(dr_release_t release,
- size_t size, gfp_t gfp)
+ size_t size, gfp_t gfp, int nid)
{
size_t tot_size = sizeof(struct devres) + size;
struct devres *dr;
- dr = kmalloc_track_caller(tot_size, gfp);
+ dr = kmalloc_node_track_caller(tot_size, gfp, nid);
if (unlikely(!dr))
return NULL;
@@ -106,24 +106,25 @@ static void add_dr(struct device *dev, struct devres_node
*node)
}
#ifdef CONFIG_DEBUG_DEVRES
-void * __devres_alloc(dr_release_t release, size_t size, gfp_t gfp,
+void * __devres_alloc_node(dr_release_t release, size_t size, gfp_t gfp, int
nid,
const char *name)
{
struct devres *dr;
- dr = alloc_dr(release, size, gfp | __GFP_ZERO);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO, nid);
if (unlikely(!dr))
return NULL;
set_node_dbginfo(>node, name, size);
return dr->data;
}
-EXPORT_SYMBOL_GPL(__devres_alloc);
+EXPORT_SYMBOL_GPL(__devres_alloc_node);
#else
/**
* devres_alloc - Allocate device resource data
* @release: Release function devres will be associated with
* @size: Allocation size
* @gfp: Allocation flags
+ * @nid: NUMA node
*
* Allocate devres of @size bytes. The allocated area is zeroed, then
* associated with @release. The returned pointer can be passed to
@@ -132,16 +133,16 @@ EXPORT_SYMBOL_GPL(__devres_alloc);
* RETURNS:
* Pointer to allocated devres on success, NULL on failure.
*/
-void * devres_alloc(dr_release_t release, size_t size, gfp_t gfp)
+void * devres_alloc_node(dr_release_t release, size_t size, gfp_t gfp, int nid)
{
struct devres *dr;
- dr = alloc_dr(release, size, gfp | __GFP_ZERO);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO, nid);
if (unlikely(!dr))
return NULL;
return dr->data;
}
-EXPORT_SYMBOL_GPL(devres_alloc);
+EXPORT_SYMBOL_GPL(devres_alloc_node);
#endif
/**
@@ -776,7 +777,7 @@ void * devm_kmalloc(struct device *dev, size_t size, gfp_t
gfp)
struct devres *dr;
/* use raw alloc_dr for kmalloc caller tracing */
- dr = alloc_dr(devm_kmalloc_release, size, gfp);
+ dr = alloc_dr(devm_kmalloc_release, size, gfp, dev_to_node(dev));
if (unlikely(!dr))
return NULL;
diff --git a/include/linux/device.h b/include/linux/device.h
index 5d7bc6349930..b8f411b57dcb 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -604,13 +604,21 @@ typedef void (*dr_release_t)(struct device *dev, void
*res);
typedef int (*dr_match_t)(struct device *dev, void *res, void *match_data);
#ifdef CONFIG_DEBUG_DEVRES
-extern void *__devres_alloc(dr_release_t release, size_t size, gfp_t gfp,
-const char *name);
+extern void *__devres_alloc_node(dr_release_t release, size_t size, gfp_t gfp,
+int nid, const char *name);
#define devres_alloc(release, size, gfp) \
- __devres_alloc(release, size, gfp, #release)
+ __devres_alloc_node(release, size, gfp, NUMA_NO_NODE, #release)
+#define devres_alloc_node(release, size, gfp, nid) \
+ __devres_alloc_node(release, size, gfp, nid, #release)
#else
-extern void *devres_alloc(dr_release_t release, size_t size, gfp_t gfp);
+extern void *devres_alloc_node(dr_release_t release, size_t size, gfp_t gfp,
+ int nid);
+static inline void *devres_alloc(dr_release_t release, size_t size, gfp_t gfp)
+{
+ return devres_alloc_node(release, size, gfp, NUMA_NO_NODE);
+}
#endif
+
extern void devres_for_each_res(struct device *dev, dr_release_t release,
dr_match_t match, void *match_data,
void (*fn)(struct device *, void *, void *),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] numa allocations for devm and pmem
I noticed that pmem should be using blk_alloc_queue_node() and then I wondered about the devm allocations... So, here is a quick conversion of devm to use dev_to_node() for node local allocations by default and as a result pmem to allocate all its driver infrastructure near to the device. --- Dan Williams (3): devm: make allocations numa aware by default devm_memremap_pages: use numa_mem_id pmem, memremap: convert to numa aware allocations drivers/base/devres.c | 19 ++- drivers/nvdimm/pmem.c |5 +++-- include/linux/device.h | 16 kernel/memremap.c |9 + 4 files changed, 30 insertions(+), 19 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] pmem, memremap: convert to numa aware allocations
Given that pmem ranges come with numa-locality hints, arrange for the
resulting driver objects to be obtained from node-local memory.
Signed-off-by: Dan Williams
---
drivers/nvdimm/pmem.c |5 +++--
kernel/memremap.c |7 ---
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index b9525385c0dc..570764a7599e 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -177,9 +177,10 @@ static void pmem_detach_disk(struct pmem_device *pmem)
static int pmem_attach_disk(struct device *dev,
struct nd_namespace_common *ndns, struct pmem_device *pmem)
{
+ int nid = dev_to_node(dev);
struct gendisk *disk;
- pmem->pmem_queue = blk_alloc_queue(GFP_KERNEL);
+ pmem->pmem_queue = blk_alloc_queue_node(GFP_KERNEL, nid);
if (!pmem->pmem_queue)
return -ENOMEM;
@@ -189,7 +190,7 @@ static int pmem_attach_disk(struct device *dev,
blk_queue_bounce_limit(pmem->pmem_queue, BLK_BOUNCE_ANY);
queue_flag_set_unlocked(QUEUE_FLAG_NONROT, pmem->pmem_queue);
- disk = alloc_disk(0);
+ disk = alloc_disk_node(0, nid);
if (!disk) {
blk_cleanup_queue(pmem->pmem_queue);
return -ENOMEM;
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 86a5cdeb18f2..f257c4e66e60 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -114,7 +114,8 @@ void *devm_memremap(struct device *dev, resource_size_t
offset,
{
void **ptr, *addr;
- ptr = devres_alloc(devm_memremap_release, sizeof(*ptr), GFP_KERNEL);
+ ptr = devres_alloc_node(devm_memremap_release, sizeof(*ptr), GFP_KERNEL,
+ dev_to_node(dev));
if (!ptr)
return NULL;
@@ -166,8 +167,8 @@ void *devm_memremap_pages(struct device *dev, struct
resource *res)
if (is_ram == REGION_INTERSECTS)
return __va(res->start);
- page_map = devres_alloc(devm_memremap_pages_release,
- sizeof(*page_map), GFP_KERNEL);
+ page_map = devres_alloc_node(devm_memremap_pages_release,
+ sizeof(*page_map), GFP_KERNEL, dev_to_node(dev));
if (!page_map)
return ERR_PTR(-ENOMEM);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] driver-core: platform: Provide helpers for multi-driver modules
On Fri, Sep 25, 2015 at 04:29:44PM +0200, Thierry Reding wrote: > On Thu, Sep 24, 2015 at 07:02:36PM +0200, Thierry Reding wrote: > > From: Thierry Reding > > > > Some modules register several sub-drivers. Provide a helper that makes > > it easy to register and unregister a list of sub-drivers, as well as > > unwind properly on error. > > > > Cc: Greg Kroah-Hartman > > Signed-off-by: Thierry Reding > > --- > > Documentation/driver-model/platform.txt | 11 ++ > > drivers/base/platform.c | 60 > > + > > include/linux/platform_device.h | 5 +++ > > 3 files changed, 76 insertions(+) > > Hi Greg, > > In addition to patches 2-6 I have about two dozen patches across various > subsystems that make use of this. I didn't want to spam everyone with > all of them before you've given an indication about what you think about > this patch. > > The diffstat of the conversions I did is this: > > drivers/crypto/n2_core.c | 17 +++-- > drivers/edac/mpc85xx_edac.c | 16 > drivers/edac/mv64x60_edac.c | 39 > +++ > drivers/gpio/gpio-mpc5200.c | 17 +++-- > drivers/gpu/drm/armada/armada_drv.c | 16 +++- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 42 > -- > drivers/gpu/drm/omapdrm/omap_drv.c | 24 > +++- > drivers/gpu/host1x/dev.c | 17 +++-- > drivers/input/misc/sparcspkr.c | 18 +++--- > drivers/iommu/msm_iommu_dev.c| 25 > +++-- > drivers/leds/leds-sunfire.c | 23 > +++ > drivers/mfd/sta2x11-mfd.c| 36 > ++-- > drivers/net/ethernet/adi/bfin_mac.c | 14 +++--- > drivers/net/ethernet/broadcom/bcm63xx_enet.c | 28 > > drivers/net/ethernet/freescale/fec_mpc52xx.c | 22 +- > drivers/net/ethernet/marvell/mv643xx_eth.c | 19 +++ > drivers/pinctrl/pinctrl-adi2.c | 24 > > drivers/pinctrl/pinctrl-at91.c | 14 +++--- > drivers/regulator/lp8788-ldo.c | 16 +++- > drivers/regulator/wm831x-dcdc.c | 31 > +-- > drivers/regulator/wm831x-ldo.c | 27 > --- > drivers/tty/serial/mpsc.c| 19 --- > drivers/usb/gadget/udc/dummy_hcd.c | 17 - > drivers/video/fbdev/s3c2410fb.c | 15 +++ > 24 files changed, 186 insertions(+), 350 deletions(-) > > That's not too thrilling but in many cases this fixes a potential bug if > a driver fails to register and the code doesn't properly unregister any > previously registered drivers. > > Anyway, if you think this is worth merging, how would you like to go > about it? Do you want Acked-bys on all the patches and merge them > through your tree? Perhaps the easiest would be to just merge this patch > and then take the other patches through the maintainer trees after the > core patch has landed? The last thing is the easiest, but you have to wait a release cycle for that. Or I can take the whole series if you want to, just cc: the proper subsystem maintainers when you send them. It's up to you. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] avr32: convert to asm-generic/memory_model.h
On Thu, Sep 24, 2015 at 8:10 AM, Christoph Hellwig wrote: > On Wed, Sep 23, 2015 at 12:41:18AM -0400, Dan Williams wrote: >> Switch avr32/include/asm/page.h to use the common defintions for >> pfn_to_page(), page_to_pfn(), and ARCH_PFN_OFFSET. > > This was the last architecture not using asm-generic/memory_model.h, > so it might be time to move it to linux/ or even fold it into an > existing header. I went to go attempt this, but ia64 is still a holdout, as its DISCONTIGMEM setup can't use the generic memory_model definitions. #ifdef CONFIG_DISCONTIGMEM # define page_to_pfn(page) ((unsigned long) (page - vmem_map)) # define pfn_to_page(pfn) (vmem_map + (pfn)) #else # include #endif #else # include #endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] PCI/MSI: X-Gene: Remove msi_controller assignment in X-Gene PCIe driver
On Fri, Sep 25, 2015 at 4:34 PM, Bjorn Helgaas wrote:
> On Fri, Sep 18, 2015 at 09:59:56AM +0100, Marc Zyngier wrote:
>> On Wed, 16 Sep 2015 17:31:40 -0700
>> Duc Dang wrote:
>>
>> > With commit 8d63bc7beaee ("PCI/MSI: pci-xgene-msi: Get rid of
>> > struct msi_controller"), it is no longer required to assign
>> > msi_controller for X-Gene PCIe host bridge to support MSI. This
>> > patch removes this unnecessary code and also helps avoid a warning
>> > message ("failed to enable MSI") during boot.
>> >
>> > Signed-off-by: Duc Dang
>> > Cc: Tanmay Inamdar
>>
>> Acked-by: Marc Zyngier
>
> I lost the original mail from Duc, but I applied this to pci/host-xgene for
> v4.4 with this changelog:
Thanks a lot, Bjorn.
>
> commit 00b9b91cb330e70b6bc571a9aa7175b4590ca452
> Author: Duc Dang
> Date: Wed Sep 16 17:31:40 2015 -0700
>
> PCI/MSI: xgene: Remove msi_controller assignment
>
> After 8d63bc7beaee ("PCI/MSI: pci-xgene-msi: Get rid of struct
> msi_controller"), it is no longer required to assign msi_controller for
> X-Gene PCIe host bridge to support MSI.
>
> Remove this unnecessary code. This also avoids a warning message ("failed
> to enable MSI") during boot.
>
> [bhelgaas: changelog]
> Signed-off-by: Duc Dang
> Signed-off-by: Bjorn Helgaas
> Acked-by: Marc Zyngier
> Cc: Tanmay Inamdar
Regards,
Duc Dang.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] PCI: Unassigned Expansion ROM BARs
On Fri, Sep 25, 2015 at 9:18 AM, Alex Williamson wrote: >> > > Or do we want to keep a white list to say which device should have >> > > ROM bar as mush have, and other is optional to have ? >> > >> > Subject: [RFC PATCH] PCI: Add pci_dev_need_rom_bar() >> > >> > Only set that for >> > 1. if BIOS/firmware already set ROM bar. >> > 2. via quirks for some devices. >> > >> > We assign those needed ROM bar as required >> > and other ROM bars as optional resources. >> >> I'd rather not have a whitelist if we can avoid it. We'd be >> continually adding new devices to it, and it makes the system harder >> to understand because there's no consistent rule about how ROMs are >> handled. I don't like that whitelist way, and hope we can find better way to handle all the cases elegantly. >> >> Alex mentioned the idea of ripping the ROM, and I'd like to explore >> that idea a little more. What if we could temporarily assign space >> for the ROM during enumeration, read the contents, cache the contents >> somewhere, then deallocate the actual BAR space? We could hang onto >> the cache and give it to anybody who later needs the ROM. > > That sounds pretty good, so long as we can consider the ROM to be > perfectly static. I don't know if anything relies on an in-place update > or if there are ROMs that are less read-only than others. Maybe it's > safe to assume that or at least safe to assume that if the BIOS didn't > leave room for them, then we can consider them static. It might be > interesting to strace some of the userspace firmware update programs for > add-in cards to see if they re-read the ROM to determine if it has > changed. Should cover most cases. But there is some driver like drivers/mtd/maps/pci.c::drivers/mtd/maps/pci.c do have write operation to the mmio range. > > We already sort of do this for VGA ROMs. When a driver tries to map the > boot VGA ROM they actually map the shadow copy at 0xC (iirc) rather > than the one on the device. This actually sort of sucks because this > particular shadow copy certainly is not read-only and in all the glory > that is VGA, the shadow sometimes gets modified by the execution of the > VGA ROM itself and we no longer have access to the pristine device > version of it (bad for device assignment of primary graphics). > > Now, if we want to make our own shadow copies for all ROMs, it seems > pretty clear that we first need to get access to the ROM, which means we > need to figure out if the BIOS mapped it. If the ROM BAR is outside of > the bridge aperture (catching both 0 and 0xFFF..000) or overlaps a > standard ROM BAR, we can consider it unprogrammed. In that case we need > to try to do the trick above with unmapping standard BARs to get the > shadow copy. Otherwise we should be able to get the shadow copy in > place (maybe a question of which we prefer to use in this case). I > would be willing to risk that if the BIOS didn't leave room for the ROM > and we can't map it into the space used by other BARs or it doesn't fit > the bridge aperture, we can spit out a printk warning and skip it. I > expect a very low failure rate. Maybe we can combine two methods together: 1. have NEED_ROM_BAR, and it is set a) if BIOS allocate resource to yet (maybe not, so we leave space for MMIO bars) b) via limited whitelist that will not support static copy. 2. kernel will try to allocate resource to ROM bar with NEED_ROM_BAR as required, and others as optional 3. for ROM bar that can not get assigned, kernel try to borrow mmio range from other MMIO bar on the device, and save a copy and expose that via /sys/.../rom That should happen FINAL_FIXUP stage before driver get loaded. --- There is risk on it, some add-on card firmware would stop working if kernel ever try to change MMIO bar. then we will need blacklist to skip BAR on those devices. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] ACPI / tables: simplify acpi_parse_entries
On Wednesday, September 16, 2015 01:58:06 PM Sudeep Holla wrote: > acpi_parse_entries passes the table end pointer to the sub-table entry > handler. acpi_parse_entries itself could validate the end of an entry > against the table end using the length in the sub-table entry. > > This patch adds the validation of the sub-table entry end using the > length field.This will help to eliminate the need to pass the table end > to the handlers. > > It also moves the check for zero length entry early so that execution of > the handler can be avoided. > > Cc: "Rafael J. Wysocki" > Signed-off-by: Sudeep Holla > > --- > drivers/acpi/tables.c | 31 +++ > 1 file changed, 15 insertions(+), 16 deletions(-) > > Hi Rafael, > > As I mentioned earlier, this needs to be applied after Al's MADT changes > are merged. You might get simple conflicts in acpi_parse_entries. This needs to be rebased on top of some patches in my linux-next branch. It probably is better to rebase it on top of my bleeding-edge branch that contains the Al's patches already, though. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] scsi: provide UAPI version of scsi/sg.h and scsi/scsi_ioctl.h
On 09/25/2015 11:27 AM, Paolo Bonzini wrote: > Provide a UAPI version of the header in the kernel, making it easier > for interested projects to use an up-to-date version of the header. > > The new headers are placed under uapi/linux/ so as not to conflict > with the glibc-provided headers in /usr/include/scsi. > > /dev/sgN default values are implementation aspects, and are moved to > drivers/scsi/sg.c instead (together with e.g. SG_ALLOW_DIO_DEF). > However, SG_SCATTER_SZ is used by Wine so it is kept in linux/sg.h > SG_MAX_QUEUE could also be useful. > > struct scsi_ioctl_command and struct scsi_idlun used to be under > "#ifdef __KERNEL__", but they are actually useful for userspace as > well. Add them to the new header. > > Cc: James Bottomley > Cc: Christoph Hellwig > Cc: linux-s...@vger.kernel.org > Cc: Bart Van Assche > Signed-off-by: Paolo Bonzini > --- [ .. ] Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] scsi: move all obsolete ioctls to scsi_ioctl.h
On 09/25/2015 11:27 AM, Paolo Bonzini wrote: > Some are in scsi.h. Keep them together in preparation for exposing them > in UAPI headers. > > Cc: James Bottomley > Cc: Christoph Hellwig > Cc: linux-s...@vger.kernel.org > Reviewed-by: Bart Van Assche > Signed-off-by: Paolo Bonzini > --- > include/scsi/scsi.h | 20 > include/scsi/scsi_ioctl.h | 20 > 2 files changed, 20 insertions(+), 20 deletions(-) > [ .. ] Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] scsi: cleanup scsi/scsi_ioctl.h
On 09/25/2015 11:27 AM, Paolo Bonzini wrote:
> SCSI_REMOVAL_* goes together with other SCSI command constants in
> include/scsi/scsi.h. It is also used outside the implementation
> of the ioctls (and it is not part of the user API).
>
> scsi_fctargaddress/Scsi_FCTargAddress has had no in-tree use since
> commit ca61f10ab2b8 ("[SCSI] remove broken driver cpqfc", 2005-10-29).
> Remove it, just in time for the the tenth anniversary of its demise.
>
> Cc: James Bottomley
> Cc: Christoph Hellwig
> Cc: linux-s...@vger.kernel.org
> Reviewed-by: Bart Van Assche
> Signed-off-by: Paolo Bonzini
> ---
> include/scsi/scsi.h | 6 ++
> include/scsi/scsi_ioctl.h | 8
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
[ .. ]
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] scsi: remove old-style type names from sg.h
On 09/25/2015 11:27 AM, Paolo Bonzini wrote:
> These will not be exported by the new linux/sg.h header, and scsi/sg.h will
> not have any user API after linux/sg.h is created. Since they have no
> user in the kernel, they can be zapped.
>
> Cc: James Bottomley
> Cc: Christoph Hellwig
> Cc: linux-s...@vger.kernel.org
> Reviewed-by: Bart Van Assche
> Signed-off-by: Paolo Bonzini
> ---
> include/scsi/sg.h | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/include/scsi/sg.h b/include/scsi/sg.h
> index 3afec7032448..370c78c37926 100644
> --- a/include/scsi/sg.h
> +++ b/include/scsi/sg.h
> @@ -207,12 +207,6 @@ typedef struct sg_req_info { /* used by
> SG_GET_REQUEST_TABLE ioctl() */
>
> #define SG_BIG_BUFF SG_DEF_RESERVED_SIZE/* for backward compatibility */
>
> -/* Alternate style type names, "..._t" variants preferred */
> -typedef struct sg_io_hdr Sg_io_hdr;
> -typedef struct sg_io_vec Sg_io_vec;
> -typedef struct sg_scsi_id Sg_scsi_id;
> -typedef struct sg_req_info Sg_req_info;
> -
>
> /* vv */
> /* The older SG interface based on the 'sg_header' structure follows. */
>
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugfix 1/2] ACPI, PCI, irq: Do not share PCI IRQ with ISA IRQ
On Thu, Sep 17, 2015 at 02:02:45PM +0800, Jiang Liu wrote:
> Avoid IRQs occupied by ISA IRQs when allocating IRQs for PCI link devices,
> otherwise it may cause interrupt storm due to incompatible pin attributes.
>
> This issue was triggered on a KVM virtual machine, which
> 1) uses IRQ9 for SCI in high level mode.
> 2) defines an PCI interrupt link device (LNKS) with IRQ9 as the only
>possible irq.
> 3) has an PCI device referring to link device LNKS.
> So it causes interrupt storm when enabling the PCI device because PCI IRQ
> works in low level mode.
>
> Signed-off-by: Jiang Liu
Acked-by: Bjorn Helgaas
> ---
> drivers/acpi/pci_irq.c |1 +
> drivers/acpi/pci_link.c | 13 +
> include/linux/acpi.h|1 +
> 3 files changed, 15 insertions(+)
>
> diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
> index 6da0f9beab19..c9336751e5e3 100644
> --- a/drivers/acpi/pci_irq.c
> +++ b/drivers/acpi/pci_irq.c
> @@ -372,6 +372,7 @@ static int acpi_isa_register_gsi(struct pci_dev *dev)
>
> /* Interrupt Line values above 0xF are forbidden */
> if (dev->irq > 0 && (dev->irq <= 0xF) &&
> + acpi_isa_irq_available(dev->irq) &&
> (acpi_isa_irq_to_gsi(dev->irq, _gsi) == 0)) {
> dev_warn(>dev, "PCI INT %c: no GSI - using ISA IRQ %d\n",
>pin_name(dev->pin), dev->irq);
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 3b4ea98e3ea0..246e50d22120 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -553,6 +553,13 @@ static int acpi_pci_link_allocate(struct acpi_pci_link
> *link)
> irq = link->irq.possible[i];
> }
> }
> + if (acpi_irq_penalty[irq] >= PIRQ_PENALTY_ISA_ALWAYS) {
> + printk(KERN_ERR PREFIX "No IRQ available for %s [%s]. "
> + "Try pci=noacpi or acpi=off\n",
> + acpi_device_name(link->device),
> + acpi_device_bid(link->device));
> + return -ENODEV;
> + }
>
> /* Attempt to enable the link device at this IRQ. */
> if (acpi_pci_link_set(link, irq)) {
> @@ -821,6 +828,12 @@ void acpi_penalize_isa_irq(int irq, int active)
> }
> }
>
> +bool acpi_isa_irq_available(int irq)
> +{
> + return irq >= 0 && (irq >= ARRAY_SIZE(acpi_irq_penalty) ||
> + acpi_irq_penalty[irq] < PIRQ_PENALTY_ISA_ALWAYS);
> +}
> +
> /*
> * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict with
> * PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be use for
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 7235c4851460..43856d19cf4d 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -217,6 +217,7 @@ struct pci_dev;
>
> int acpi_pci_irq_enable (struct pci_dev *dev);
> void acpi_penalize_isa_irq(int irq, int active);
> +bool acpi_isa_irq_available(int irq);
> void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
> void acpi_pci_irq_disable (struct pci_dev *dev);
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugfix 2/2] ACPI / PCI: Remove duplicated penalty on SCI IRQ
On Thu, Sep 17, 2015 at 02:02:46PM +0800, Jiang Liu wrote: > Now we have dedicated interface acpi_penalize_sci_irq() to penalize > ISA IRQ used by ACPI SCI, so remove duplicated code to penalize ACPI SCI > in acpi_irq_penalty_init(). > > Signed-off-by: Jiang Liu Acked-by: Bjorn Helgaas > --- > drivers/acpi/pci_link.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c > index 246e50d22120..7c8408b946ca 100644 > --- a/drivers/acpi/pci_link.c > +++ b/drivers/acpi/pci_link.c > @@ -498,8 +498,7 @@ int __init acpi_irq_penalty_init(void) > PIRQ_PENALTY_PCI_POSSIBLE; > } > } > - /* Add a penalty for the SCI */ > - acpi_irq_penalty[acpi_gbl_FADT.sci_interrupt] += PIRQ_PENALTY_PCI_USING; > + > return 0; > } > > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] PCI/MSI: X-Gene: Remove msi_controller assignment in X-Gene PCIe driver
On Fri, Sep 18, 2015 at 09:59:56AM +0100, Marc Zyngier wrote:
> On Wed, 16 Sep 2015 17:31:40 -0700
> Duc Dang wrote:
>
> > With commit 8d63bc7beaee ("PCI/MSI: pci-xgene-msi: Get rid of
> > struct msi_controller"), it is no longer required to assign
> > msi_controller for X-Gene PCIe host bridge to support MSI. This
> > patch removes this unnecessary code and also helps avoid a warning
> > message ("failed to enable MSI") during boot.
> >
> > Signed-off-by: Duc Dang
> > Cc: Tanmay Inamdar
>
> Acked-by: Marc Zyngier
I lost the original mail from Duc, but I applied this to pci/host-xgene for
v4.4 with this changelog:
commit 00b9b91cb330e70b6bc571a9aa7175b4590ca452
Author: Duc Dang
Date: Wed Sep 16 17:31:40 2015 -0700
PCI/MSI: xgene: Remove msi_controller assignment
After 8d63bc7beaee ("PCI/MSI: pci-xgene-msi: Get rid of struct
msi_controller"), it is no longer required to assign msi_controller for
X-Gene PCIe host bridge to support MSI.
Remove this unnecessary code. This also avoids a warning message ("failed
to enable MSI") during boot.
[bhelgaas: changelog]
Signed-off-by: Duc Dang
Signed-off-by: Bjorn Helgaas
Acked-by: Marc Zyngier
Cc: Tanmay Inamdar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dax: fix deadlock in __dax_fault
On Fri, Sep 25, 2015 at 12:23:34PM -0600, Ross Zwisler wrote: > On Fri, Sep 25, 2015 at 12:53:57PM +1000, Dave Chinner wrote: > <> > > We've already got block allocation serialisation at the filesystem > > level, and the issue is the unserialised block zeroing being done by > > the dax code. That can be fixed by moving the zeroing into the > > filesystem code when it runs "complete_unwritten" and checks whether > > the mapping has already been marked as written or not... > > > > I've recently pointed out in a different thread that this is the > > solution to whatever that problem was (can't recall which > > thread/problem is was now :/ ) and it the same solution here. We > > already have the serialisation we need, we just need to move the > > block zeroing operation into the appropriate places to make it work > > correctly. > > I think perhaps this is the thread that you're remembering: > https://lkml.org/lkml/2015/8/11/731 Ah, yes, the read vs write fault race condition, whereas this change was to address write vs write fault races. And neither of which address the fault vs truncate problem properly, either, which is what the XFS_MMAP_LOCKING addresses. So, yeah, pushing the block zeroing down to the filesystem gets rid of multiple problems that concurrent page faults have with initialisation without adding any more serialisation or overhead. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] acpi: Add basic device probing infrastructure
On Sunday, September 13, 2015 03:02:19 PM Marc Zyngier wrote:
The subject is slightly confusing IMO (there is a device probing infrastructure
in the ACPI subsystem, but not for the kind of devices in question here).
> IRQ controllers and timers are the two types of device the kernel
> requires before being able to use the device driver model.
>
> ACPI so far lacks a proper probing infrastructure similar to the one
> we have with DT, where we're able to declare IRQ chips and
> clocksources inside the driver code, and let the core code pick it up
> and call us back on a match. This leads to all kind of really ugly
> hacks all over the arm64 code and even in the ACPI layer.
>
> In order to allow some basic probing based on the ACPI tables,
> introduce "struct acpi_probe_entry" which contains just enough
> data and callbacks to match a table, an optional subtable, and
> call a probe function. A driver can, at build time, register itself
> and expect being called if the right entry exists in the ACPI
> table.
>
> A acpi_probe_device_table() is provided, taking an identifier for
> a set of acpi_prove_entries, and iterating over the registered
> entries.
>
> Signed-off-by: Marc Zyngier
> ---
> drivers/acpi/scan.c | 39 +++
> include/asm-generic/vmlinux.lds.h | 10 ++
> include/linux/acpi.h | 65
> +++
> 3 files changed, 114 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 01136b8..ac3030b 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1933,3 +1933,42 @@ int __init acpi_scan_init(void)
> mutex_unlock(_scan_lock);
> return result;
> }
> +
> +static struct acpi_probe_entry *ape;
> +static int acpi_probe_count;
> +static DEFINE_SPINLOCK(acpi_probe_lock);
> +
> +static int __init acpi_match_madt(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + if (!ape->validate_subtbl || ape->validate_subtbl(header, ape))
> + if (!ape->probe_subtbl(header, end))
> + acpi_probe_count++;
> +
> + return 0;
> +}
> +
> +int __init __acpi_probe_device_table(struct acpi_probe_entry *ap_head, int
> nr)
> +{
> + int count = 0;
> +
> + if (acpi_disabled)
> + return 0;
> +
> + spin_lock(_probe_lock);
> + for (ape = ap_head; nr; ape++, nr--) {
> + if (ACPI_COMPARE_NAME(ACPI_SIG_MADT, ape->id)) {
> + acpi_probe_count = 0;
> + acpi_table_parse_madt(ape->type, acpi_match_madt, 0);
> + count += acpi_probe_count;
> + } else {
> + int res;
> + res = acpi_table_parse(ape->id, ape->probe_table);
> + if (!res)
> + count++;
> + }
> + }
> + spin_unlock(_probe_lock);
> +
> + return count;
> +}
> diff --git a/include/asm-generic/vmlinux.lds.h
> b/include/asm-generic/vmlinux.lds.h
> index 1781e54..efd7ed1 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -181,6 +181,16 @@
> #define CPUIDLE_METHOD_OF_TABLES() OF_TABLE(CONFIG_CPU_IDLE, cpuidle_method)
> #define EARLYCON_OF_TABLES() OF_TABLE(CONFIG_SERIAL_EARLYCON, earlycon)
>
> +#ifdef CONFIG_ACPI
> +#define ACPI_PROBE_TABLE(name)
> \
> + . = ALIGN(8); \
> + VMLINUX_SYMBOL(__##name##_acpi_probe_table) = .;\
> + *(__##name##_acpi_probe_table) \
> + VMLINUX_SYMBOL(__##name##_acpi_probe_table_end) = .;
> +#else
> +#define ACPI_PROBE_TABLE(name)
> +#endif
> +
> #define KERNEL_DTB() \
> STRUCT_ALIGN(); \
> VMLINUX_SYMBOL(__dtb_start) = .;\
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 7235c48..c63fbda 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -759,6 +759,61 @@ int acpi_dev_prop_read(struct acpi_device *adev, const
> char *propname,
>
> struct acpi_device *acpi_get_next_child(struct device *dev,
> struct acpi_device *child);
> +
> +struct acpi_probe_entry;
> +typedef bool (*acpi_probe_entry_validate_subtbl)(struct acpi_subtable_header
> *,
> + struct acpi_probe_entry *);
> +
> +#define ACPI_TABLE_ID_LEN5
> +
> +/**
> + * struct acpi_probe_entry - boot-time probing entry
> + * @id: ACPI table name
> + * @type:Optional subtable type to match
> + * (if @id contains subtables)
> + * @validate_subtbl: Optional callback to check the validity of
> + * the subtable
I'd call this subtbl_valid
Re: [PATCH 0/8] Broadcom iProc PCIe fixes and outbound mapping support
On Tue, Sep 15, 2015 at 05:39:14PM -0700, Ray Jui wrote: > This patch series contains various fixes and outbound mapping support for > the Broadcom iProc PCIe driver. Some of the critical fixes include 1) fix of > PCIe core reset logic and therefore remove its dependency on the bootloader; > 2) improved link detection logic that works for more iProc based SoCs. > > This patch series also adds the outbound address mapping support. While > outbound address mapping support is not required on chips like North Star, > Cygnus, and etc., some of the newer iProc based chips like North Star 2 > require > this support to properly map the AXI address into the address used in the > iProc > PCIe core > > This patch series is constructed based on Linux v4.3-rc1 (with workaround to > disable calls to pci_read_bridge_bases in pci/probe.c that breaks some of the > ARM based PCIe devices including iProc) > > This patch series is tested on the following platforms with an Intel e1000e > based PCIe x1 NIC card: > - ARM32 based Cygnus BCM958305K Wireless Audio board > - ARM64 based North Star 2 SVK board > > code available at GITHUB: > https://github.com/Broadcom/cygnus-linux/tree/iproc-pcie-fix-v1 > > Ray Jui (8): > PCI: iproc: Fix code comment > PCI: iproc: Remove unused code > PCI: iproc: Remove ARCH specific flag > PCI: iproc: Fix PCIe reset logic > PCI: iproc: Improve link detection logic > PCI: iproc: Update iProc PCIe device tree bindings > PCI: iproc: Add outbound mapping support > PCI: iproc: Fix compile warnings > > .../devicetree/bindings/pci/brcm,iproc-pcie.txt| 20 +++ > drivers/pci/host/pcie-iproc-platform.c | 27 > drivers/pci/host/pcie-iproc.c | 159 > +++-- > drivers/pci/host/pcie-iproc.h | 20 ++- > 4 files changed, 210 insertions(+), 16 deletions(-) Applied to pci/host-iproc for v4.4, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/26] x86, pkeys: notify userspace about protection key faults
On 09/25/2015 12:11 AM, Ingo Molnar wrote:
>>> > > Btw., how does pkey support interact with hugepages?
>> >
>> > Surprisingly little. I've made sure that everything works with huge pages
>> > and
>> > that the (huge) PTEs and VMAs get set up correctly, but I'm not sure I had
>> > to
>> > touch the huge page code at all. I have test code to ensure that it works
>> > the
>> > same as with small pages, but everything worked pretty naturally.
> Yeah, so the reason I'm asking about expectations is that this code:
>
> + follow_ret = follow_pte(tsk->mm, address, , );
> + if (!follow_ret) {
> + /*
> +* On a successful follow, make sure to
> +* drop the lock.
> +*/
> + pte = *ptep;
> + pte_unmap_unlock(ptep, ptl);
> + ret = pte_pkey(pte);
>
> is visibly hugepage-unsafe: if a vma is hugepage mapped, there are no ptes,
> only
> pmds - and the protection key index lives in the pmd. We don't seem to
> recover
> that information properly.
You got me on this one. I assumed that follow_pte() handled huge pages.
It does not.
But, the code still worked. Since follow_pte() fails for all huge
pages, it just falls back to pulling the protection key out of the VMA,
which _does_ work for huge pages.
I've actually removed the PTE walking and I just now use the VMA
directly. I don't see a ton of additional value from walking the page
tables when we can get what we need from the VMA.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/5] ACPI probing infrastructure
On Sunday, September 13, 2015 03:02:18 PM Marc Zyngier wrote: > IRQ controllers and timers are the two types of device the kernel > requires before being able to use the device driver model. > > The Device Tree infrastructure makes it very easy to make these > discoverable by the rest of the kernel. For example, each interrupt > controller driver has at least one entry like this: > > IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init); > > which says: if you find a node having "arm,gic-400" as a compatible > string in the device tree, then call gic_of_init with this node as a > parameter. The probing itself is done by the OF layer when the > architecture code calls of_irq_init() (usually via irqchip_init). > > This has a number of benefits: > > - The irqchip code is self-contained. No architecture specific entry > point, no exposed symbols. Just a standard interface. > > - The low-level architecture code doesn't have to know about which > interrupt controller is present. It just calls into the firmware > interface (of_irq_init) which is going to sort things out. > > Similar infrastructure is provided for the timers/clock sources. Note > that this is not a replacement for the device model, but acts as a > probing infrastructure for things that are required too early for the > device infrastructure to be available. > > What I'm aiming for is to introduce the same level of abstraction for > ACPI, or at least for the few bits that are required before a full blown > ACPI/device model can be used. For this, I introduce something vaguely > similar: > > IRQCHIP_ACPI_DECLARE(gic_v2, ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR, >gic_validate_dist, ACPI_MADT_GIC_VERSION_V2, >gic_v2_acpi_init); > > which says: if you find a ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR entry in > MADT (implied by the macro), and that entry is of type > ACPI_MADT_GIC_VERSION_V2 (as checked by gic_validate_dist), then call > gic_v2_acpi_init with the entry as a parameter. A bit more convoluted, > but still without any special entry point. > > The various interrupt controller drivers can then implement the above, > and the arch code can use a firmware-specific call to get the probing > done, still oblivious to what interrupt controller is being used. It > also makes the adaptation of a DT driver to ACPI easier. > > It turns out that providing such a probing infrastructure is rather > easy, and provides a much deserved cleanup in both the arch code, the > GIC driver, and the architected timer driver. > > I'm sure there is some more code to be deleted, and one can only > wonder why this wasn't done before the arm64 code was initially merged > (the diffstat says it all...). > > Patches are against v4.3-rc1, and a branch is available at > > git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git > acpi/device-probing-v2 > > * From the initial version: > - Make the infrastructure more DT like by providing an > acpi_probe_entry array per "device type" (one for irqchips, one > for clocksources). This means that entries can depend on any ACPI > static table. > - Use some cpp magic to reduce the amount of code added to an > absolute minimum. > - Rebased on v4.3-rc1 > > Marc Zyngier (5): > acpi: Add basic device probing infrastructure > irqchip/acpi: Add probing infrastructure for ACPI-based irqchips > irqchip/gic: Convert the GIC driver to ACPI probing > clocksource/acpi: Add probing infrastructure for ACPI-based > clocksources > clocksource/arm_arch_timer: Convert to ACPI probing I'm generally fine with this (modulo a couple of super-minor nits in the first patch), but it needs ACKs from Thomas for the irqchip-related and clocksource-related patches. Plus [3/5] needs to be rebased on top of the Al's patches removing BAD_MADT_ENTRY (currently in my bleeding-edge branch). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] HID: hid-input: allow input_configured callback return errors
When configuring input device via input_configured callback we may
encounter errors (for example input_mt_init_slots() may fail). Instead
of continuing with half-initialized input device let's allow driver
indicate failures.
Signed-off-by: Jaikumar Ganesh
Signed-off-by: Arve Hjønnevåg
Signed-off-by: Dmitry Torokhov
---
drivers/hid/hid-appleir.c| 4 +++-
drivers/hid/hid-elo.c| 4 +++-
drivers/hid/hid-input.c | 10 ++
drivers/hid/hid-lenovo.c | 4 +++-
drivers/hid/hid-logitech-hidpp.c | 4 +++-
drivers/hid/hid-magicmouse.c | 8 ++--
drivers/hid/hid-multitouch.c | 19 ++-
drivers/hid/hid-ntrig.c | 6 --
drivers/hid/hid-rmi.c| 11 +++
drivers/hid/hid-sony.c | 13 ++---
drivers/hid/hid-uclogic.c| 6 --
include/linux/hid.h | 4 ++--
12 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/hid/hid-appleir.c b/drivers/hid/hid-appleir.c
index 0e6a42d..07cbc70 100644
--- a/drivers/hid/hid-appleir.c
+++ b/drivers/hid/hid-appleir.c
@@ -256,7 +256,7 @@ out:
return 0;
}
-static void appleir_input_configured(struct hid_device *hid,
+static int appleir_input_configured(struct hid_device *hid,
struct hid_input *hidinput)
{
struct input_dev *input_dev = hidinput->input;
@@ -275,6 +275,8 @@ static void appleir_input_configured(struct hid_device *hid,
for (i = 0; i < ARRAY_SIZE(appleir_key_table); i++)
set_bit(appleir->keymap[i], input_dev->keybit);
clear_bit(KEY_RESERVED, input_dev->keybit);
+
+ return 0;
}
static int appleir_input_mapping(struct hid_device *hid,
diff --git a/drivers/hid/hid-elo.c b/drivers/hid/hid-elo.c
index 4e49462..aad8c16 100644
--- a/drivers/hid/hid-elo.c
+++ b/drivers/hid/hid-elo.c
@@ -37,7 +37,7 @@ static bool use_fw_quirk = true;
module_param(use_fw_quirk, bool, S_IRUGO);
MODULE_PARM_DESC(use_fw_quirk, "Do periodic pokes for broken M firmwares
(default = true)");
-static void elo_input_configured(struct hid_device *hdev,
+static int elo_input_configured(struct hid_device *hdev,
struct hid_input *hidinput)
{
struct input_dev *input = hidinput->input;
@@ -45,6 +45,8 @@ static void elo_input_configured(struct hid_device *hdev,
set_bit(BTN_TOUCH, input->keybit);
set_bit(ABS_PRESSURE, input->absbit);
input_set_abs_params(input, ABS_PRESSURE, 0, 256, 0, 0);
+
+ return 0;
}
static void elo_process_data(struct input_dev *input, const u8 *data, int size)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 53aeaf6..2ba6bf6 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1510,8 +1510,9 @@ int hidinput_connect(struct hid_device *hid, unsigned int
force)
* UGCI) cram a lot of unrelated inputs into the
* same interface. */
hidinput->report = report;
- if (drv->input_configured)
- drv->input_configured(hid, hidinput);
+ if (drv->input_configured &&
+ drv->input_configured(hid, hidinput))
+ goto out_cleanup;
if (input_register_device(hidinput->input))
goto out_cleanup;
hidinput = NULL;
@@ -1532,8 +1533,9 @@ int hidinput_connect(struct hid_device *hid, unsigned int
force)
}
if (hidinput) {
- if (drv->input_configured)
- drv->input_configured(hid, hidinput);
+ if (drv->input_configured &&
+ drv->input_configured(hid, hidinput))
+ goto out_cleanup;
if (input_register_device(hidinput->input))
goto out_cleanup;
}
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index e4bc6cb..8979f1f 100644
--- a/drivers/hid/hid-lenovo.c
+++ b/drivers/hid/hid-lenovo.c
@@ -848,7 +848,7 @@ static void lenovo_remove(struct hid_device *hdev)
hid_hw_stop(hdev);
}
-static void lenovo_input_configured(struct hid_device *hdev,
+static int lenovo_input_configured(struct hid_device *hdev,
struct hid_input *hi)
{
switch (hdev->product) {
@@ -863,6 +863,8 @@ static void lenovo_input_configured(struct hid_device *hdev,
}
break;
}
+
+ return 0;
}
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 452e5d5..5fd9786 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -1285,13 +1285,15 @@ static void hidpp_populate_input(struct hidpp_device
*hidpp,
m560_populate_input(hidpp,
Re: PIDs Controller Limit
> On Thu, Sep 24, 2015 at 09:42:38AM +1000, Aleksa Sarai wrote: >> Does it make sense for the PIDs controller to allow a user to set a >> limit of 0? Since we don't cancel attaches, a limit of 0 doesn't >> affect anything (nothing stops attaches, and you need to have a >> process in the PIDs cgroup in order for fork()s to be affected by the >> limit). So I think that attempting to set pid.limit to 0 should return >> an -EINVAL. > > I don't know. Why does it matter? Well, it might be confusing that a limit of `0` is not different from a limit of `1`. Especially since someone might think that a limit of `0` means "no processes AT ALL", which is wrong. Although, I guess they should've just RTFM'd in that case. -- Aleksa Sarai (cyphar) www.cyphar.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/2] pwm: Broadcom BCM7038 PWM controller (v4)
On 14/09/15 16:47, Florian Fainelli wrote: > Hi, > > This patch series add PWM support for the Broadcom BCM7xxx > chips which feature one or more PWM controllers capable of > output periods from 148ns to ~622ms using a combination of > variable and fixed frequency settings. Thierry, are you happy with this version of the patches? Thanks. > > The controller does not support setting a polarity. > > This is based on Thierry's pwm/next branch. > > Florian Fainelli (2): > Documentation: dt: add Broadcom BCM7038 PWM controller binding > pwm: Add Broadcom BCM7038 PWM controller support > > .../devicetree/bindings/pwm/brcm,bcm7038-pwm.txt | 20 ++ > drivers/pwm/Kconfig| 10 + > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-brcmstb.c | 345 > + > 4 files changed, 376 insertions(+) > create mode 100644 Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt > create mode 100644 drivers/pwm/pwm-brcmstb.c > -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/5] Provide better MADT subtable sanity checks
On Wednesday, September 16, 2015 05:26:40 PM Al Stone wrote: > Currently, the BAD_MADT_ENTRY macro is used to do a very simple sanity > check on the various subtables that are defined for the MADT. The check > compares the size of the subtable data structure as defined by ACPICA to > the length entry in the subtable. If they are not the same, the assumption > is that the subtable is incorrect. > > Over time, the ACPI spec has allowed for MADT subtables where this can > never be true (the local SAPIC subtable, for example). Or, more recently, > the spec has accumulated some minor flaws where there are three possible > sizes for a subtable, all of which are valid, but only for specific versions > of the spec (the GICC subtable). In both cases, BAD_MADT_ENTRY reports these > subtables as bad when they are not. In order to retain some sanity check > on the MADT subtables, we now have to special case these subtables. Of > necessity, these special cases have ended up in arch-dependent code (arm64) > or an arch has simply decided to forgo the check (ia64). > > This patch set replaces the BAD_MADT_ENTRY macro with a function called > bad_madt_entry(). This function uses a data set of details about the > subtables to provide more sanity checking than before: > > -- is the subtable legal for the version given in the FADT? > > -- is the subtable legal for the revision of the MADT in use? > > -- is the subtable of the proper length (including checking > on the one variable length subtable that is currently ignored), > given the FADT version and the MADT revision? > > Further, this patch set adds in the call to bad_madt_entry() from the > acpi_table_parse_madt() function, allowing it to be used consistently > by all architectures, for all subtables, and removing the need for each > of the subtable traversal callback functions to use BAD_MADT_ENTRY. > > In theory, as the ACPI specification changes, we would only have to add > additional information to the data set describing the MADT subtables in > order to continue providing sanity checks, even when new subtables are > added. > > These patches have been tested on an APM Mustang (arm64) and are known to > work there. They have also been cross-compiled for x86 and ia64 with no > known failures. > > Changes for v4: >-- Remove extraneous white space change (Graeme Gregory) >-- acpi_parse_entries() changes also needed a check to make sure that > only MADT entries used bad_madt_entry() (Sudeep Holla) >-- inadvertent use of 01day build noted that bad_madt_entry() can be > static, so added it (Sudeep Holla, Fengguang Wu) > > Changes for v3: >-- Reviewed-and-tested-by from Sudeep Holla for arm64 parts >-- Clearer language in error messages (Graeme Gregory, Timur Tabi) >-- Double checked that inserting call to bad_madt_entry() into the > function acpi_parse_entries() does not impact current behavior > (Sudeep Holla) > > Changes for v2: >-- Acked-by on 2/5 from Marc Zyngier and Catalin Marinas for ARM >-- Correct faulty end of loop test found by Timur Tabi > > > Al Stone (5): > ACPI: add in a bad_madt_entry() function to eventually replace the > macro > ACPI / ARM64: remove usage of BAD_MADT_ENTRY/BAD_MADT_GICC_ENTRY > ACPI / IA64: remove usage of BAD_MADT_ENTRY > ACPI / X86: remove usage of BAD_MADT_ENTRY > ACPI: remove definition of BAD_MADT_ENTRY macro I've queued this up for v4.4, but I had to rebase it on top of some previous changes in my linux-next branch. Can you please look at my bleeding-edge branch and see if the result of the rebase is as intended? In particular, I'm not sure if we really need to return -EINVAL from acpi_parse_entries_array() when we find a bad MADT entry or it will be sufficient to simply go to the next entry in that case? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend
On Friday, September 25, 2015 11:52:23 PM Rafael J. Wysocki wrote: > On Friday, September 25, 2015 05:13:04 PM Alan Stern wrote: > > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > > > > > On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote: > > > > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > > > > > > > > > We are missing the "no remote wakeup" bit now (well, there is a PM > > > > > QoS flag, > > > > > but it isn't very useful, so I'd prefer to replace it with a "no > > > > > remote wakeup" > > > > > bit in struct dev_pm_info or something similar). > > > > > > > > > > That is actually quite important, because (a) we can save energy but > > > > > not > > > > > configuring the device to do remote wakeup in the first place and (b) > > > > > that > > > > > may involve more than just the driver (for example, disabling PCI or > > > > > ACPI > > > > > remote wakeup involves the bus type or similar). > > > > > > > > > > So it looks like we need to be able to distinguish between "runtime > > > > > suspend > > > > > with remote wakeup" and "runtime suspend without remote wakeup". > > > > > > > > > > And if we do the latter, we may not even need the "inhibit" thing any > > > > > more, > > > > > because suspended devices without that are not configured to do > > > > > remote wakeup > > > > > cannot really signal anything in the majority of cases. > > > > > > > > That works only for drivers that use autosuspend to go to low power in > > > > between events. It doesn't work for drivers that remain at full power > > > > as long as the device file is open. That kind of driver does require > > > > an "inhibit" interface. > > > > > > Or an interface allowing user space to trigger pm_request_idle() for them. > > > > > > So user space would change the "no remote wakeup" setting and then do the > > > "try to suspend now" thing. > > > > So something like: > > > > echo on >/sys/.../power/control (in case the device was > > already in runtime suspend with wakeups enabled) > > echo off >/sys/.../power/wakeup > > echo auto >/sys/.../power/control > > That, or there may be an additional value, say "aggressive", to write to the > control file in which case it becomes just > > echo aggressive >/sys/.../power/control That said I suppose that the "off" value for the "wakeup" file might also be useful in some other cases, so it likely is a better approach. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] selinux: use kstrdup() in security_get_bools()
This is much simpler.
Signed-off-by: Rasmus Villemoes
---
security/selinux/ss/services.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 994c824a34c6..aa2bdcb20848 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -2609,18 +2609,12 @@ int security_get_bools(int *len, char ***names, int
**values)
goto err;
for (i = 0; i < *len; i++) {
- size_t name_len;
-
(*values)[i] = policydb.bool_val_to_struct[i]->state;
- name_len = strlen(sym_name(, SYM_BOOLS, i)) + 1;
rc = -ENOMEM;
- (*names)[i] = kmalloc(sizeof(char) * name_len, GFP_ATOMIC);
+ (*names)[i] = kstrdup(sym_name(, SYM_BOOLS, i),
GFP_ATOMIC);
if (!(*names)[i])
goto err;
-
- strncpy((*names)[i], sym_name(, SYM_BOOLS, i),
name_len);
- (*names)[i][name_len - 1] = 0;
}
rc = 0;
out:
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] selinux: remove pointless cast in selinux_inode_setsecurity()
security_context_to_sid() expects a const char* argument, so there's no point in casting away the const qualifier of value. Signed-off-by: Rasmus Villemoes --- security/selinux/hooks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index fd50cd5ac2ec..5edb57df86f8 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -3162,7 +3162,7 @@ static int selinux_inode_setsecurity(struct inode *inode, const char *name, if (!value || !size) return -EACCES; - rc = security_context_to_sid((void *)value, size, , GFP_KERNEL); + rc = security_context_to_sid(value, size, , GFP_KERNEL); if (rc) return rc; -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] selinux: use sprintf return value
sprintf returns the number of characters printed (excluding '\0'), so we can use that and avoid duplicating the length computation. Signed-off-by: Rasmus Villemoes --- security/selinux/ss/services.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c index aa2bdcb20848..ebb5eb3c318c 100644 --- a/security/selinux/ss/services.c +++ b/security/selinux/ss/services.c @@ -1218,13 +1218,10 @@ static int context_struct_to_string(struct context *context, char **scontext, u3 /* * Copy the user name, role name and type name into the context. */ - sprintf(scontextp, "%s:%s:%s", + scontextp += sprintf(scontextp, "%s:%s:%s", sym_name(, SYM_USERS, context->user - 1), sym_name(, SYM_ROLES, context->role - 1), sym_name(, SYM_TYPES, context->type - 1)); - scontextp += strlen(sym_name(, SYM_USERS, context->user - 1)) + -1 + strlen(sym_name(, SYM_ROLES, context->role - 1)) + -1 + strlen(sym_name(, SYM_TYPES, context->type - 1)); mls_sid_to_context(context, ); -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] selinux: use kmemdup in security_sid_to_context_core()
Signed-off-by: Rasmus Villemoes
---
security/selinux/ss/services.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index c550df0e0ff1..994c824a34c6 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1259,12 +1259,12 @@ static int security_sid_to_context_core(u32 sid, char
**scontext,
*scontext_len = strlen(initial_sid_to_string[sid]) + 1;
if (!scontext)
goto out;
- scontextp = kmalloc(*scontext_len, GFP_ATOMIC);
+ scontextp = kmemdup(initial_sid_to_string[sid],
+ *scontext_len, GFP_ATOMIC);
if (!scontextp) {
rc = -ENOMEM;
goto out;
}
- strcpy(scontextp, initial_sid_to_string[sid]);
*scontext = scontextp;
goto out;
}
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] selinux: minor cleanup suggestions
A few random things I stumbled on. While I'm pretty sure of the change in 1/5, I'm also confused, because the doc for the reverse security_sid_to_context state that @scontext_len is set to "the length of the string", which one would normally interpret as being what strlen() would give (i.e., without the \0). However, security_sid_to_context_core clearly includes the \0 in the return value, and I think callers rely on that. Rasmus Villemoes (5): selinux: introduce security_context_str_to_sid selinux: remove pointless cast in selinux_inode_setsecurity() selinux: use kmemdup in security_sid_to_context_core() selinux: use kstrdup() in security_get_bools() selinux: use sprintf return value security/selinux/hooks.c| 14 +- security/selinux/include/security.h | 2 ++ security/selinux/selinuxfs.c| 26 +- security/selinux/ss/services.c | 22 +- 4 files changed, 25 insertions(+), 39 deletions(-) -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] selinux: introduce security_context_str_to_sid
There seems to be a little confusion as to whether the scontext_len
parameter of security_context_to_sid() includes the nul-byte or
not. Reading security_context_to_sid_core(), it seems that the
expectation is that it does not (both the string copying and the test
for scontext_len being zero hint at that).
Introduce the helper security_context_str_to_sid() to do the strlen()
call and fix all callers.
Signed-off-by: Rasmus Villemoes
---
security/selinux/hooks.c| 12
security/selinux/include/security.h | 2 ++
security/selinux/selinuxfs.c| 26 +-
security/selinux/ss/services.c | 5 +
4 files changed, 20 insertions(+), 25 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e4369d86e588..fd50cd5ac2ec 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -674,10 +674,9 @@ static int selinux_set_mnt_opts(struct super_block *sb,
if (flags[i] == SBLABEL_MNT)
continue;
- rc = security_context_to_sid(mount_options[i],
-strlen(mount_options[i]), ,
GFP_KERNEL);
+ rc = security_context_str_to_sid(mount_options[i], ,
GFP_KERNEL);
if (rc) {
- printk(KERN_WARNING "SELinux: security_context_to_sid"
+ printk(KERN_WARNING "SELinux:
security_context_str_to_sid"
"(%s) failed for (dev %s, type %s) errno=%d\n",
mount_options[i], sb->s_id, name, rc);
goto out;
@@ -2617,15 +2616,12 @@ static int selinux_sb_remount(struct super_block *sb,
void *data)
for (i = 0; i < opts.num_mnt_opts; i++) {
u32 sid;
- size_t len;
if (flags[i] == SBLABEL_MNT)
continue;
- len = strlen(mount_options[i]);
- rc = security_context_to_sid(mount_options[i], len, ,
-GFP_KERNEL);
+ rc = security_context_str_to_sid(mount_options[i], ,
GFP_KERNEL);
if (rc) {
- printk(KERN_WARNING "SELinux: security_context_to_sid"
+ printk(KERN_WARNING "SELinux:
security_context_str_to_sid"
"(%s) failed for (dev %s, type %s) errno=%d\n",
mount_options[i], sb->s_id, sb->s_type->name,
rc);
goto out_free_opts;
diff --git a/security/selinux/include/security.h
b/security/selinux/include/security.h
index 6a681d26bf20..223e9fd15d66 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -166,6 +166,8 @@ int security_sid_to_context_force(u32 sid, char **scontext,
u32 *scontext_len);
int security_context_to_sid(const char *scontext, u32 scontext_len,
u32 *out_sid, gfp_t gfp);
+int security_context_str_to_sid(const char *scontext, u32 *out_sid, gfp_t gfp);
+
int security_context_to_sid_default(const char *scontext, u32 scontext_len,
u32 *out_sid, u32 def_sid, gfp_t gfp_flags);
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 5bed7716f8ab..c02da25d7b63 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -731,13 +731,11 @@ static ssize_t sel_write_access(struct file *file, char
*buf, size_t size)
if (sscanf(buf, "%s %s %hu", scon, tcon, ) != 3)
goto out;
- length = security_context_to_sid(scon, strlen(scon) + 1, ,
-GFP_KERNEL);
+ length = security_context_str_to_sid(scon, , GFP_KERNEL);
if (length)
goto out;
- length = security_context_to_sid(tcon, strlen(tcon) + 1, ,
-GFP_KERNEL);
+ length = security_context_str_to_sid(tcon, , GFP_KERNEL);
if (length)
goto out;
@@ -819,13 +817,11 @@ static ssize_t sel_write_create(struct file *file, char
*buf, size_t size)
objname = namebuf;
}
- length = security_context_to_sid(scon, strlen(scon) + 1, ,
-GFP_KERNEL);
+ length = security_context_str_to_sid(scon, , GFP_KERNEL);
if (length)
goto out;
- length = security_context_to_sid(tcon, strlen(tcon) + 1, ,
-GFP_KERNEL);
+ length = security_context_str_to_sid(tcon, , GFP_KERNEL);
if (length)
goto out;
@@ -882,13 +878,11 @@ static ssize_t sel_write_relabel(struct file *file, char
*buf, size_t size)
if (sscanf(buf, "%s %s %hu", scon, tcon, ) != 3)
goto out;
- length = security_context_to_sid(scon, strlen(scon) + 1, ,
-
Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On Fri, Sep 25, 2015 at 11:44 PM, Viresh Kumar wrote: > On 25-09-15, 22:58, Rafael J. Wysocki wrote: >> Say you have three adjacent fields in a structure, x, y, z, each one byte >> long. >> Initially, all of them are equal to 0. >> >> CPU A writes 1 to x and CPU B writes 2 to y at the same time. >> >> What's the result? > > But then two CPUs can update the same variable as well, and we must > have proper locking in place to fix that. Right. So if you allow something like debugfs to update your structure, how do you make sure there is the proper locking? Is that not a problem in all of the places modified by the [2/2]? How can the future users of the API know what to do to avoid potential problems with it? > > Anyway, that problem isn't here for sure as its between two > unsigned-longs. So, should I just move it to bool and resend ? I guess it might be more convenient to fold this into the other patch, because we seem to be splitting hairs here. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
consignment
Contact us for your compensation consignment box -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: First kernel patch (optimization)
Hi Erik, > > Yeah, I'm still reading this email thread and learned lots from it. > I'm working on something more meaningful, but it's not going to be > ground breaking of course, there is a led on my capslock key on a new > machine I won at work that does not switch off properly after it is > switched on. Is it Debian-derivative by any chance? Their capslock setup is wonky because CapsLock key does no actually set up as a CapsLock but another modifier. Also is it in X or is it on text console? Because X handles led state on its own... > I think it is something to do with the LED_CAPSL variable > in here: > > drivers/hid/usbhid/usbkbd.c I do not think you are using usbkbd driver - it is for keyboards in "boot protocol" and barely anyone users them in such mode. You need to look into drivers/hid/hid-input.c. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions
From: Ard Biesheuvel
The new Properties Table feature introduced in UEFIv2.5 may split
memory regions that cover PE/COFF memory images into separate code
and data regions. Since these regions only differ in the type (runtime
code vs runtime data) and the permission bits, but not in the memory
type attributes (UC/WC/WT/WB), the spec does not require them to be
aligned to 64 KB.
Since the relative offset of PE/COFF .text and .data segments cannot
be changed on the fly, this means that we can no longer pad out those
regions to be mappable using 64 KB pages.
Unfortunately, there is no annotation in the UEFI memory map that
identifies data regions that were split off from a code region, so we
must apply this logic to all adjacent runtime regions whose attributes
only differ in the permission bits.
So instead of rounding each memory region to 64 KB alignment at both
ends, only round down regions that are not directly preceded by another
runtime region with the same type attributes. Since the UEFI spec does
not mandate that the memory map be sorted, this means we also need to
sort it first.
Note that this change will result in all EFI_MEMORY_RUNTIME regions whose
start addresses are not aligned to the OS page size to be mapped with
executable permissions (i.e., on kernels compiled with 64 KB pages).
However, since these mappings are only active during the time that UEFI
Runtime Services are being invoked, the window for abuse is rather small.
Signed-off-by: Ard Biesheuvel
Tested-by: Mark Salter
Reviewed-by: Mark Salter
Cc: Leif Lindholm
Reviewed-by: Mark Rutland
Tested-by: Mark Rutland [UEFI 2.4 only]
Cc: Catalin Marinas
Cc: Will Deacon
Cc: # v4.0+
Signed-off-by: Matt Fleming
---
arch/arm64/kernel/efi.c | 3 +-
drivers/firmware/efi/libstub/arm-stub.c | 88 +++--
2 files changed, 75 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index e8ca6eaedd02..13671a9cf016 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -258,7 +258,8 @@ static bool __init efi_virtmap_init(void)
*/
if (!is_normal_ram(md))
prot = __pgprot(PROT_DEVICE_nGnRE);
- else if (md->type == EFI_RUNTIME_SERVICES_CODE)
+ else if (md->type == EFI_RUNTIME_SERVICES_CODE ||
+!PAGE_ALIGNED(md->phys_addr))
prot = PAGE_KERNEL_EXEC;
else
prot = PAGE_KERNEL;
diff --git a/drivers/firmware/efi/libstub/arm-stub.c
b/drivers/firmware/efi/libstub/arm-stub.c
index e29560e6b40b..950c87f5d279 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -13,6 +13,7 @@
*/
#include
+#include
#include
#include "efistub.h"
@@ -305,6 +306,44 @@ fail:
*/
#define EFI_RT_VIRTUAL_BASE0x4000
+static int cmp_mem_desc(const void *l, const void *r)
+{
+ const efi_memory_desc_t *left = l, *right = r;
+
+ return (left->phys_addr > right->phys_addr) ? 1 : -1;
+}
+
+/*
+ * Returns whether region @left ends exactly where region @right starts,
+ * or false if either argument is NULL.
+ */
+static bool regions_are_adjacent(efi_memory_desc_t *left,
+efi_memory_desc_t *right)
+{
+ u64 left_end;
+
+ if (left == NULL || right == NULL)
+ return false;
+
+ left_end = left->phys_addr + left->num_pages * EFI_PAGE_SIZE;
+
+ return left_end == right->phys_addr;
+}
+
+/*
+ * Returns whether region @left and region @right have compatible memory type
+ * mapping attributes, and are both EFI_MEMORY_RUNTIME regions.
+ */
+static bool regions_have_compatible_memory_type_attrs(efi_memory_desc_t *left,
+ efi_memory_desc_t *right)
+{
+ static const u64 mem_type_mask = EFI_MEMORY_WB | EFI_MEMORY_WT |
+EFI_MEMORY_WC | EFI_MEMORY_UC |
+EFI_MEMORY_RUNTIME;
+
+ return ((left->attribute ^ right->attribute) & mem_type_mask) == 0;
+}
+
/*
* efi_get_virtmap() - create a virtual mapping for the EFI memory map
*
@@ -317,33 +356,52 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map,
unsigned long map_size,
int *count)
{
u64 efi_virt_base = EFI_RT_VIRTUAL_BASE;
- efi_memory_desc_t *out = runtime_map;
+ efi_memory_desc_t *in, *prev = NULL, *out = runtime_map;
int l;
- for (l = 0; l < map_size; l += desc_size) {
- efi_memory_desc_t *in = (void *)memory_map + l;
+ /*
+* To work around potential issues with the Properties Table feature
+* introduced in UEFI 2.5, which may split PE/COFF executable images
+* in memory into several RuntimeServicesCode and RuntimeServicesData
+* regions, we need to preserve the relative offsets
[PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime
From: Matt Fleming
Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that
signals that the firmware PE/COFF loader supports splitting code and
data sections of PE/COFF images into separate EFI memory map entries.
This allows the kernel to map those regions with strict memory
protections, e.g. EFI_MEMORY_RO for code, EFI_MEMORY_XP for data, etc.
Unfortunately, an unwritten requirement of this new feature is that
the regions need to be mapped with the same offsets relative to each
other as observed in the EFI memory map. If this is not done crashes
like this may occur,
[0.006391] BUG: unable to handle kernel paging request at fffefe6086dd
[0.006923] IP: [] 0xfffefe6086dd
[0.007000] Call Trace:
[0.007000] [] efi_call+0x7e/0x100
[0.007000] [] ? virt_efi_set_variable+0x61/0x90
[0.007000] [] efi_delete_dummy_variable+0x63/0x70
[0.007000] [] efi_enter_virtual_mode+0x383/0x392
[0.007000] [] start_kernel+0x38a/0x417
[0.007000] [] x86_64_start_reservations+0x2a/0x2c
[0.007000] [] x86_64_start_kernel+0xeb/0xef
Here 0xfffefe6086dd refers to an address the firmware expects to
be mapped but which the OS never claimed was mapped. The issue is that
included in these regions are relative addresses to other regions
which were emitted by the firmware toolchain before the "splitting" of
sections occurred at runtime.
Needless to say, we don't satisfy this unwritten requirement on x86_64
and instead map the EFI memory map entries in reverse order. The above
crash is almost certainly triggerable with any kernel newer than v3.13
because that's when we rewrote the EFI runtime region mapping code, in
commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping"). For
kernel versions before v3.13 things may work by pure luck depending on
the fragmentation of the kernel virtual address space at the time we
map the EFI regions.
Instead of mapping the EFI memory map entries in reverse order, where
entry N has a higher virtual address than entry N+1, map them in the
same order as they appear in the EFI memory map to preserve this
relative offset between regions.
This patch has been kept as small as possible with the intention that
it should be applied aggressively to stable and distribution kernels.
It is very much a bugfix rather than support for a new feature, since
when EFI_PROPERTIES_TABLE is enabled we must map things as outlined
above to even boot - we have no way of asking the firmware not to
split the code/data regions.
In fact, this patch doesn't even make use of the more strict memory
protections available in UEFI v2.5. That will come later.
Reported-by: Ard Biesheuvel
Suggested-by: Ard Biesheuvel
Cc: "Lee, Chun-Yi"
Cc: Borislav Petkov
Cc: Leif Lindholm
Cc: Peter Jones
Cc: James Bottomley
Cc: Matthew Garrett
Cc: H. Peter Anvin
Cc: Dave Young
Cc:
Signed-off-by: Matt Fleming
---
arch/x86/platform/efi/efi.c | 67 -
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 1db84c0758b7..6a28ded74211 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -705,6 +705,70 @@ out:
}
/*
+ * Iterate the EFI memory map in reverse order because the regions
+ * will be mapped top-down. The end result is the same as if we had
+ * mapped things forward, but doesn't require us to change the
+ * existing implementation of efi_map_region().
+ */
+static inline void *efi_map_next_entry_reverse(void *entry)
+{
+ /* Initial call */
+ if (!entry)
+ return memmap.map_end - memmap.desc_size;
+
+ entry -= memmap.desc_size;
+ if (entry < memmap.map)
+ return NULL;
+
+ return entry;
+}
+
+/*
+ * efi_map_next_entry - Return the next EFI memory map descriptor
+ * @entry: Previous EFI memory map descriptor
+ *
+ * This is a helper function to iterate over the EFI memory map, which
+ * we do in different orders depending on the current configuration.
+ *
+ * To begin traversing the memory map @entry must be %NULL.
+ *
+ * Returns %NULL when we reach the end of the memory map.
+ */
+static void *efi_map_next_entry(void *entry)
+{
+ if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_64BIT)) {
+ /*
+* Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE
+* config table feature requires us to map all entries
+* in the same order as they appear in the EFI memory
+* map. That is to say, entry N must have a lower
+* virtual address than entry N+1. This is because the
+* firmware toolchain leaves relative references in
+* the code/data sections, which are split and become
+* separate EFI memory regions. Mapping things
+* out-of-order leads to the firmware accessing
+* unmapped addresses.
+
[GIT PULL 0/2] EFI urgent fixes
From: Matt Fleming Folks, The patches in this pull request fix kernel crashes when booting Linux on UEFI v2.5 machines with the Properties Table feature enabled. Essentially, when this feature is enabled the firmware allocates separate entries in the EFI memory map for the code and data sections of PE/COFF images, whereas previously only one memory map entry would have existed. Because we've now got two entries that reference each other we *must* map them into the kernel virtual address space with the same offsets and in the same order as they appear in the EFI memory map. Failure to do so causes the firmware to access unmapped/invalid addresses. These patches were intentionally kept as small as possible so that they can be backported by distributions, aggressively. The following changes since commit 1f93e4a96c9109378204c147b3eec0d0e8100fde: Linux 4.3-rc2 (2015-09-20 14:32:34 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent for you to fetch changes up to 1fa25e09ca2ce07f03bca93ad71800c312fd4951: arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions (2015-09-25 22:35:15 +0100) * arm64 bug fix for UEFI 2.5 firmware that has the Properties Table feature enabled. The fix avoids a kernel crash by removing the padding between runtime regions that we currently do in the kernel so we don't break the EFI's cross-region references - Ard Biesheuvel * Map EFI memory regions in-order on x86 so that we maintain the relative offset between regions and fix a crash when booting on UEFI 2.5 machines with the Properties Table feature enabled. Ard Biesheuvel (1): arm64/efi: Don't pad between EFI_MEMORY_RUNTIME regions Matt Fleming (1): x86/efi: Map EFI memmap entries in-order at runtime arch/arm64/kernel/efi.c | 3 +- arch/x86/platform/efi/efi.c | 67 - drivers/firmware/efi/libstub/arm-stub.c | 88 +++-- 3 files changed, 141 insertions(+), 17 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Glibc recvmsg from kernel netlink socket hangs forever
On Sep 25, 2015, at 2:37 PM, Steven Schlansker wrote: > > On Sep 24, 2015, at 10:34 PM, Guenter Roeck wrote: > >> Herbert, >> >> On 09/24/2015 09:58 PM, Herbert Xu wrote: >>> On Thu, Sep 24, 2015 at 09:36:53PM -0700, Guenter Roeck wrote: http://comments.gmane.org/gmane.linux.network/363085 might explain your problem. I thought this was resolved in 4.1, but it looks like the problem still persists there. At least I have reports from my workplace that 4.1.6 and 4.1.7 are still affected. I don't know if there have been any relevant changes in 4.2. Copying Herbert and Eric for additional input. >>> >>> There was a separate bug discovered by Tejun recently. You need >>> to apply the patches >>> >>> https://patchwork.ozlabs.org/patch/519245/ >>> https://patchwork.ozlabs.org/patch/520824/ >>> >> I assume this is on top of mainline ? >> >>> There is another follow-up but it shouldn't make any difference >>> in practice. >>> >> >> Any idea what may be needed for 4.1 ? >> I am currently trying https://patchwork.ozlabs.org/patch/473041/, >> but I have no idea if that will help with the problem we are seeing there. > > Thank you for the patches to try, I'll build a kernel with them early next > week > and report back. It sounds like it may not match my problem exactly so we'll > see. Huh, when it rains, it pours... now I have a legit panic too! [ 1675.228701] BUG: unable to handle kernel paging request at fe70 [ 1675.232058] IP: [] netlink_compare+0xa/0x30 [ 1675.232058] PGD 2015067 PUD 2017067 PMD 0 [ 1675.232058] Oops: [#1] SMP [ 1675.232058] Modules linked in: i2c_piix4(E) btrfs(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) aesni_intel(E) aes_x86_64(E) lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) cryptd(E) floppy(E) [ 1675.232058] CPU: 2 PID: 11152 Comm: pf_dump Tainted: GE 4.0.4 #1 [ 1675.232058] Hardware name: Xen HVM domU, BIOS 4.2.amazon 05/06/2015 [ 1675.232058] task: 880150fa6480 ti: 880150fb4000 task.ti: 880150fb4000 [ 1675.232058] RIP: 0010:[] [] netlink_compare+0xa/0x30 [ 1675.232058] RSP: 0018:880150fb7d10 EFLAGS: 00010246 [ 1675.232058] RAX: RBX: 023e503b RCX: 0561f992 [ 1675.232058] RDX: fffc27e4 RSI: 880150fb7db8 RDI: fbb8 [ 1675.232058] RBP: 880150fb7d58 R08: 8805a82f5ab8 R09: 000c [ 1675.232058] R10: R11: 0202 R12: [ 1675.232058] R13: 8175dce0 R14: 88008b37e800 R15: 88076db4 [ 1675.232058] FS: 7feec2440700() GS:88078fc4() knlGS: [ 1675.232058] CS: 0010 DS: ES: CR0: 80050033 [ 1675.232058] CR2: fe70 CR3: 00053bd17000 CR4: 001407e0 [ 1675.232058] Stack: [ 1675.232058] 81434dae 88076d864400 880150fb7db8 8801559ee8b8 [ 1675.232058] 88076db4 8805a82f5c48 88008b37e800 88076d864400 [ 1675.232058] 880150fb7da8 81435476 880150fb7db8 [ 1675.232058] Call Trace: [ 1675.232058] [] ? rhashtable_lookup_compare+0x5e/0xb0 [ 1675.232058] [] rhashtable_lookup_compare_insert+0x66/0xc0 [ 1675.232058] [] netlink_insert+0x83/0xe0 [ 1675.232058] [] netlink_autobind.isra.34+0xad/0xd0 [ 1675.232058] [] netlink_bind+0x1b1/0x240 [ 1675.232058] [] SYSC_bind+0xb8/0xf0 [ 1675.232058] [] ? __audit_syscall_entry+0xb4/0x110 [ 1675.232058] [] ? do_audit_syscall_entry+0x6c/0x70 [ 1675.232058] [] ? syscall_trace_enter_phase1+0x123/0x180 [ 1675.232058] [] ? syscall_trace_leave+0xc6/0x120 [ 1675.232058] [] ? fd_install+0x25/0x30 [ 1675.232058] [] SyS_bind+0xe/0x10 [ 1675.232058] [] system_call_fastpath+0x16/0x1b [ 1675.232058] Code: 00 8b 77 08 39 77 14 8d 4e 01 41 0f 44 c9 41 39 c8 89 4f 08 74 09 48 8b 08 83 3c 11 04 74 e2 5d c3 0f 1f 44 00 00 31 c0 8b 56 08 <39> 97 b8 02 00 00 55 48 89 e5 74 0a 5d c3 0f 1f 84 00 00 00 00 [ 1675.232058] RIP [] netlink_compare+0xa/0x30 [ 1675.232058] RSP [ 1675.232058] CR2: fe70 [ 1675.232058] ---[ end trace 963ff50a058120d0 ]--- [ 1675.232058] Kernel panic - not syncing: Fatal exception in interrupt [ 1675.232058] Kernel Offset: 0x0 from 0x8100 (relocation range: 0x8000-0x9fff) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of: add vendor prefix for Socionext Inc.
On Wed, Sep 9, 2015 at 3:04 AM, Lee Jones wrote: > On Wed, 09 Sep 2015, Masahiro Yamada wrote: >> 2015-08-25 0:11 GMT+09:00 Rob Herring : >> > On Mon, Aug 24, 2015 at 1:57 AM, Lee Jones wrote: >> >> On Wed, 29 Jul 2015, Masahiro Yamada wrote: >> >> >> >>> Signed-off-by: Masahiro Yamada >> >>> --- >> >>> >> >>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + >> >>> 1 file changed, 1 insertion(+) >> >> >> >> Patch has been around for nearly a month and is pretty trivial, so I'm >> >> just going to go ahead an apply it. >> > >> > Okay. I just added it now going thru my backlog, but will drop it. >> > >> > Rob >> > >> >> So, where has this patch gone? >> >> I've not seen it anywhere. > > That's a very good question. I must have mis-applied it some how. > > Sorry for this. I will try to get it into v4.3 by hook or by crook. I've applied this and it is in Linus' tree now. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On 25-09-15, 22:58, Rafael J. Wysocki wrote: > Say you have three adjacent fields in a structure, x, y, z, each one byte > long. > Initially, all of them are equal to 0. > > CPU A writes 1 to x and CPU B writes 2 to y at the same time. > > What's the result? But then two CPUs can update the same variable as well, and we must have proper locking in place to fix that. Anyway, that problem isn't here for sure as its between two unsigned-longs. So, should I just move it to bool and resend ? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/4] KVM: arm/arm64: check power_off in kvm_arch_vcpu_runnable
kvm_arch_vcpu_runnable now also checks whether the power_off
flag is set.
Signed-off-by: Eric Auger
Reviewed-by: Christoffer Dall
---
arch/arm/kvm/arm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 2b19ef7..9d16f76 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -352,7 +352,8 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
*/
int kvm_arch_vcpu_runnable(struct kvm_vcpu *v)
{
- return !!v->arch.irq_lines || kvm_vgic_vcpu_pending_irq(v);
+ return ((!!v->arch.irq_lines || kvm_vgic_vcpu_pending_irq(v))
+ && !v->arch.power_off);
}
/* Just ensure a guest exit from a particular CPU */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/4] KVM: arm/arm64: check power_off in critical section before VCPU run
In case a vcpu off PSCI call is called just after we executed the
vcpu_sleep check, we can enter the guest although power_off
is set. Let's check the power_off state in the critical section,
just before entering the guest.
Signed-off-by: Eric Auger
Reported-by: Christoffer Dall
Reviewed-by: Christoffer Dall
---
v2 -> v3:
- reword commit message
---
arch/arm/kvm/arm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 9d16f76..4eb59e3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -560,7 +560,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run)
run->exit_reason = KVM_EXIT_INTR;
}
- if (ret <= 0 || need_new_vmid_gen(vcpu->kvm)) {
+ if (ret <= 0 || need_new_vmid_gen(vcpu->kvm) ||
+ vcpu->arch.power_off) {
local_irq_enable();
kvm_timer_sync_hwstate(vcpu);
kvm_vgic_sync_hwstate(vcpu);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/4] KVM: arm/arm64: guest synchronous halt/resume
This series introduces the capability to synchronously exit the guest and prevent it from being re-entered. This modality will be used by IRQ forwarding series when changing the state of the IRQ. Former pause flag used when starting the vcpu in KVM_ARM_VCPU_POWER_OFF state, in PSCI calls and in KVM_SET_MP_STATE ioctl is renamed into power_off. A new pause flag is introduced. Both now are checked in kvm_arch_vcpu_runnable and in the VCPU_RUN critical section, before entering the vcpu. Best Regards Eric History: v2 -> v3: - unified the comment associated to the pause flag - correct commit message of "KVM: arm/arm64: check power_off in critical section before VCPU run" - add Christoffer R-b on whole series v1 -> v2: - check pause, power_off and in kvm_arch_vcpu_runnable - check power_off in vcpu_run critcal section before guest entry - correct compil issue in first patch reported by Andrew - rename vcpu_pause into vcpu_sleep RFC -> PATCH v1: - originally part of [RFC 00/17] ARM IRQ forward control based on IRQ bypass manager (https://lkml.org/lkml/2015/7/2/268) and isolated in this series. - added __maybe_unused following Marc's advice Eric Auger (4): KVM: arm/arm64: rename pause into power_off KVM: arm/arm64: check power_off in kvm_arch_vcpu_runnable KVM: arm/arm64: check power_off in critical section before VCPU run KVM: arm/arm64: implement kvm_arm_[halt,resume]_guest arch/arm/include/asm/kvm_host.h | 5 +++- arch/arm/kvm/arm.c| 53 ++- arch/arm/kvm/psci.c | 10 arch/arm64/include/asm/kvm_host.h | 5 +++- 4 files changed, 54 insertions(+), 19 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/4] KVM: arm/arm64: rename pause into power_off
The kvm_vcpu_arch pause field is renamed into power_off to prepare
for the introduction of a new pause field. Also vcpu_pause is renamed
into vcpu_sleep since we will sleep until both power_off and pause are
false.
Signed-off-by: Eric Auger
Reviewed-by: Christoffer Dall
---
v1 -> v2:
- rename pause in kvm_arch_vcpu_ioctl_[set,get]_mpstate
- rename vcpu_pause into vcpu_sleep
---
arch/arm/include/asm/kvm_host.h | 4 ++--
arch/arm/kvm/arm.c| 20 ++--
arch/arm/kvm/psci.c | 10 +-
arch/arm64/include/asm/kvm_host.h | 4 ++--
4 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 3df1e97..1931a25 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -125,8 +125,8 @@ struct kvm_vcpu_arch {
* here.
*/
- /* Don't run the guest on this vcpu */
- bool pause;
+ /* vcpu power-off state */
+ bool power_off;
/* IO related fields */
struct kvm_decode mmio_decode;
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index a9491ef..2b19ef7 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -318,7 +318,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
struct kvm_mp_state *mp_state)
{
- if (vcpu->arch.pause)
+ if (vcpu->arch.power_off)
mp_state->mp_state = KVM_MP_STATE_STOPPED;
else
mp_state->mp_state = KVM_MP_STATE_RUNNABLE;
@@ -331,10 +331,10 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
{
switch (mp_state->mp_state) {
case KVM_MP_STATE_RUNNABLE:
- vcpu->arch.pause = false;
+ vcpu->arch.power_off = false;
break;
case KVM_MP_STATE_STOPPED:
- vcpu->arch.pause = true;
+ vcpu->arch.power_off = true;
break;
default:
return -EINVAL;
@@ -478,11 +478,11 @@ bool kvm_arch_intc_initialized(struct kvm *kvm)
return vgic_initialized(kvm);
}
-static void vcpu_pause(struct kvm_vcpu *vcpu)
+static void vcpu_sleep(struct kvm_vcpu *vcpu)
{
wait_queue_head_t *wq = kvm_arch_vcpu_wq(vcpu);
- wait_event_interruptible(*wq, !vcpu->arch.pause);
+ wait_event_interruptible(*wq, !vcpu->arch.power_off);
}
static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu)
@@ -532,8 +532,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run)
update_vttbr(vcpu->kvm);
- if (vcpu->arch.pause)
- vcpu_pause(vcpu);
+ if (vcpu->arch.power_off)
+ vcpu_sleep(vcpu);
/*
* Disarming the background timer must be done in a
@@ -780,12 +780,12 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu
*vcpu,
vcpu_reset_hcr(vcpu);
/*
-* Handle the "start in power-off" case by marking the VCPU as paused.
+* Handle the "start in power-off" case.
*/
if (test_bit(KVM_ARM_VCPU_POWER_OFF, vcpu->arch.features))
- vcpu->arch.pause = true;
+ vcpu->arch.power_off = true;
else
- vcpu->arch.pause = false;
+ vcpu->arch.power_off = false;
return 0;
}
diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
index ad6f642..0b55696 100644
--- a/arch/arm/kvm/psci.c
+++ b/arch/arm/kvm/psci.c
@@ -63,7 +63,7 @@ static unsigned long kvm_psci_vcpu_suspend(struct kvm_vcpu
*vcpu)
static void kvm_psci_vcpu_off(struct kvm_vcpu *vcpu)
{
- vcpu->arch.pause = true;
+ vcpu->arch.power_off = true;
}
static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
@@ -87,7 +87,7 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu
*source_vcpu)
*/
if (!vcpu)
return PSCI_RET_INVALID_PARAMS;
- if (!vcpu->arch.pause) {
+ if (!vcpu->arch.power_off) {
if (kvm_psci_version(source_vcpu) != KVM_ARM_PSCI_0_1)
return PSCI_RET_ALREADY_ON;
else
@@ -115,7 +115,7 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu
*source_vcpu)
* the general puspose registers are undefined upon CPU_ON.
*/
*vcpu_reg(vcpu, 0) = context_id;
- vcpu->arch.pause = false;
+ vcpu->arch.power_off = false;
smp_mb(); /* Make sure the above is visible */
wq = kvm_arch_vcpu_wq(vcpu);
@@ -153,7 +153,7 @@ static unsigned long kvm_psci_vcpu_affinity_info(struct
kvm_vcpu *vcpu)
mpidr = kvm_vcpu_get_mpidr_aff(tmp);
if ((mpidr & target_affinity_mask) == target_affinity) {
matching_cpus++;
- if (!tmp->arch.pause)
+
[PATCH v3 4/4] KVM: arm/arm64: implement kvm_arm_[halt,resume]_guest
We introduce kvm_arm_halt_guest and resume functions. They
will be used for IRQ forward state change.
Halt is synchronous and prevents the guest from being re-entered.
We use the same mechanism put in place for PSCI former pause,
now renamed power_off. A new flag is introduced in arch vcpu state,
pause, only meant to be used by those functions.
Signed-off-by: Eric Auger
Reviewed-by: Christoffer Dall
---
v2 -> v3:
- change the comment associated to the pause flag into:
Don't run the guest (internal implementation need)
- add Christoffer's R-b
v1 -> v2:
- check pause in kvm_arch_vcpu_runnable
- we cannot use kvm_vcpu_block since this latter would exit on
IRQ/FIQ and this is not what we want
---
arch/arm/include/asm/kvm_host.h | 3 +++
arch/arm/kvm/arm.c| 35 +++
arch/arm64/include/asm/kvm_host.h | 3 +++
3 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 1931a25..efbb812 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -128,6 +128,9 @@ struct kvm_vcpu_arch {
/* vcpu power-off state */
bool power_off;
+/* Don't run the guest (internal implementation need) */
+ bool pause;
+
/* IO related fields */
struct kvm_decode mmio_decode;
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 4eb59e3..0308092 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -353,7 +353,7 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
int kvm_arch_vcpu_runnable(struct kvm_vcpu *v)
{
return ((!!v->arch.irq_lines || kvm_vgic_vcpu_pending_irq(v))
- && !v->arch.power_off);
+ && !v->arch.power_off && !v->arch.pause);
}
/* Just ensure a guest exit from a particular CPU */
@@ -479,11 +479,38 @@ bool kvm_arch_intc_initialized(struct kvm *kvm)
return vgic_initialized(kvm);
}
+static void kvm_arm_halt_guest(struct kvm *kvm) __maybe_unused;
+static void kvm_arm_resume_guest(struct kvm *kvm) __maybe_unused;
+
+static void kvm_arm_halt_guest(struct kvm *kvm)
+{
+ int i;
+ struct kvm_vcpu *vcpu;
+
+ kvm_for_each_vcpu(i, vcpu, kvm)
+ vcpu->arch.pause = true;
+ force_vm_exit(cpu_all_mask);
+}
+
+static void kvm_arm_resume_guest(struct kvm *kvm)
+{
+ int i;
+ struct kvm_vcpu *vcpu;
+
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ wait_queue_head_t *wq = kvm_arch_vcpu_wq(vcpu);
+
+ vcpu->arch.pause = false;
+ wake_up_interruptible(wq);
+ }
+}
+
static void vcpu_sleep(struct kvm_vcpu *vcpu)
{
wait_queue_head_t *wq = kvm_arch_vcpu_wq(vcpu);
- wait_event_interruptible(*wq, !vcpu->arch.power_off);
+ wait_event_interruptible(*wq, ((!vcpu->arch.power_off) &&
+ (!vcpu->arch.pause)));
}
static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu)
@@ -533,7 +560,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run)
update_vttbr(vcpu->kvm);
- if (vcpu->arch.power_off)
+ if (vcpu->arch.power_off || vcpu->arch.pause)
vcpu_sleep(vcpu);
/*
@@ -561,7 +588,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run)
}
if (ret <= 0 || need_new_vmid_gen(vcpu->kvm) ||
- vcpu->arch.power_off) {
+ vcpu->arch.power_off || vcpu->arch.pause) {
local_irq_enable();
kvm_timer_sync_hwstate(vcpu);
kvm_vgic_sync_hwstate(vcpu);
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index d89ec1b..d19dfd6 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -151,6 +151,9 @@ struct kvm_vcpu_arch {
/* vcpu power-off state */
bool power_off;
+ /* Don't run the guest (internal implementation need) */
+ bool pause;
+
/* IO related fields */
struct kvm_decode mmio_decode;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 3/7] powerpc: atomic: Implement atomic{,64}_{add,sub}_return_* variants
On Wed, Sep 23, 2015 at 08:07:55AM +0800, Boqun Feng wrote:
> On Tue, Sep 22, 2015 at 08:25:40AM -0700, Paul E. McKenney wrote:
> > On Tue, Sep 22, 2015 at 07:37:04AM +0800, Boqun Feng wrote:
> > > On Tue, Sep 22, 2015 at 07:26:56AM +0800, Boqun Feng wrote:
> > > > On Mon, Sep 21, 2015 at 11:24:27PM +0100, Will Deacon wrote:
> > > > > Hi Boqun,
> > > > >
> > > > > On Sun, Sep 20, 2015 at 09:23:03AM +0100, Boqun Feng wrote:
> > > > > > On Sat, Sep 19, 2015 at 11:33:10PM +0800, Boqun Feng wrote:
> > > > > > > On Fri, Sep 18, 2015 at 05:59:02PM +0100, Will Deacon wrote:
> > > > > > > > On Wed, Sep 16, 2015 at 04:49:31PM +0100, Boqun Feng wrote:
> > > > > > > > > On powerpc, we don't need a general memory barrier to achieve
> > > > > > > > > acquire and
> > > > > > > > > release semantics, so __atomic_op_{acquire,release} can be
> > > > > > > > > implemented
> > > > > > > > > using "lwsync" and "isync".
> > > > > > > >
> > > > > > > > I'm assuming isync+ctrl isn't transitive, so we need to get to
> > > > > > > > the bottom
> > > > > > >
> > > > > > > Actually the transitivity is still guaranteed here, I think ;-)
> > > > >
> > > > > The litmus test I'm thinking of is:
> > > > >
> > > > >
> > > > > {
> > > > > 0:r2=x;
> > > > > 1:r2=x; 1:r5=z;
> > > > > 2:r2=z; 2:r4=x;
> > > > > }
> > > > > P0 | P1| P2 ;
> > > > > li r1,1 | lwz r1,0(r2) | lwz r1,0(r2) ;
> > > > > stw r1,0(r2) | cmpw r1,r1| cmpw r1,r1 ;
> > > > > | beq LC00 | beq LC01;
> > > > > | LC00: | LC01:;
> > > > > | isync | isync;
> > > > > | li r4,1 | lwz r3,0(r4) ;
> > > > > | stw r4,0(r5) | ;
> > > > > exists
> > > > > (1:r1=1 /\ 2:r1=1 /\ 2:r3=0)
> > > > >
> > > > >
> > > > > Which appears to be allowed. I don't think you need to worry about
> > > > > backwards
> > > > > branches for the ctrl+isync construction (none of the current example
> > > > > do,
> > > > > afaict).
> > > > >
> > > >
> > > > Yes.. my care of backwards branches is not quite related to the topic, I
> > > > concerned that mostly because my test is using atomic operation, and I
> > > > just want to test the exact asm code.
> > > >
> > > > > Anyway, all the problematic cases seem to arise when we start mixing
> > > > > ACQUIRE/RELEASE accesses with relaxed accesses (i.e. where an access
> > > > > from
> > > > > one group reads from an access in the other group). It would be
> > > > > simplest
> > > > > to say that this doesn't provide any transitivity guarantees, and that
> > > > > an ACQUIRE must always read from a RELEASE if transitivity is
> > > > > required.
> > > > >
> > > >
> > > > Agreed. RELEASE alone doesn't provide transitivity and transitivity is
> > > ^^^
> > > This should be ACQUIRE...
> > >
> > > > guaranteed only if an ACQUIRE read from a RELEASE. That's exactly the
> > > > direction which the link (https://lkml.org/lkml/2015/9/15/836) is
> > > > heading to. So I think we are fine here to use ctrl+isync here, right?
> >
> > We are going to have to err on the side of strictness, that is, having
> > the documentation place more requirements on the developer than the union
> > of the hardware does. Besides, I haven't heard any recent complaints
> > that memory-barriers.txt is too simple. ;-)
>
> Agreed ;-)
>
> For atomic operations, using isync in ACQUIRE operations does gaurantee
> that a pure RELEASE/ACQUIRE chain provides transitivity. So, again, I
> think we are fine here to use isync in ACQUIRE atomic operations,
> unless you think we need to be more strict, i.e, making ACQUIRE itself
> provide transitivy?
As I understand it, either isync or lwsync suffices, with the choice
depending on the hardware. The kernel will rewrite itself at boot time
if you use the appropriate macro. ;-)
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -tip 2/3] sched/wake_q: Relax to acquire semantics
On Wed, Sep 23, 2015 at 08:43:21AM +0200, Martin Schwidefsky wrote:
> On Tue, 22 Sep 2015 08:28:22 -0700
> "Paul E. McKenney" wrote:
>
> > On Tue, Sep 22, 2015 at 04:33:07PM +0200, Martin Schwidefsky wrote:
> > > On Tue, 22 Sep 2015 21:29:14 +0800
> > > Boqun Feng wrote:
> > >
> > > > On Tue, Sep 22, 2015 at 02:51:36PM +0200, Martin Schwidefsky wrote:
> > > > > On Tue, 22 Sep 2015 20:23:26 +0800
> > > > > Boqun Feng wrote:
> > > > >
> > > > > > Hi Martin,
> > > > > >
> > > > > > On Tue, Sep 22, 2015 at 12:27:35PM +0200, Martin Schwidefsky wrote:
> > > > > > > On Mon, 21 Sep 2015 11:22:52 +0200
> > > > > > > Martin Schwidefsky wrote:
> > > > > > >
> > > > > > > > On Fri, 18 Sep 2015 14:41:20 -0700
> > > > > > > > "Paul E. McKenney" wrote:
> > > > > > > >
> > > > > > > > > On Tue, Sep 15, 2015 at 10:09:41AM -0700, Paul E. McKenney
> > > > > > > > > wrote:
> > > > > > > > > > On Tue, Sep 15, 2015 at 06:30:28PM +0200, Peter Zijlstra
> > > > > > > > > > wrote:
> > > > > > > > > > > On Tue, Sep 15, 2015 at 08:34:48AM -0700, Paul E.
> > > > > > > > > > > McKenney wrote:
> > > > > > > > > > > > On Tue, Sep 15, 2015 at 04:14:39PM +0200, Peter
> > > > > > > > > > > > Zijlstra wrote:
> > > > > > > > > > > > > On Tue, Sep 15, 2015 at 07:09:22AM -0700, Paul E.
> > > > > > > > > > > > > McKenney wrote:
> > > > > > > > > > > > > > On Tue, Sep 15, 2015 at 02:48:00PM +0200, Peter
> > > > > > > > > > > > > > Zijlstra wrote:
> > > > > > > > > > > > > > > On Tue, Sep 15, 2015 at 05:41:42AM -0700, Paul E.
> > > > > > > > > > > > > > > McKenney wrote:
> > > > > > > > > > > > > > > > > Never mind, the PPC people will implement
> > > > > > > > > > > > > > > > > this with lwsync and that is
> > > > > > > > > > > > > > > > > very much not transitive IIRC.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I am probably lost on context, but...
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > It turns out that lwsync is transitive in
> > > > > > > > > > > > > > > > special cases. One of them
> > > > > > > > > > > > > > > > is a series of release-acquire pairs, which can
> > > > > > > > > > > > > > > > extend indefinitely.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Does that help in this case?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Probably not, but good to know. I still don't
> > > > > > > > > > > > > > > think we want to rely on
> > > > > > > > > > > > > > > ACQUIRE/RELEASE being transitive in general
> > > > > > > > > > > > > > > though.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > OK, I will bite... Why not?
> > > > > > > > > > > > >
> > > > > > > > > > > > > It would mean us reviewing all archs (again) and
> > > > > > > > > > > > > documenting it I
> > > > > > > > > > > > > suppose. Which is of course entirely possible.
> > > > > > > > > > > > >
> > > > > > > > > > > > > That said, I don't think the case at hand requires
> > > > > > > > > > > > > it, so lets postpone
> > > > > > > > > > > > > this for now ;-)
> > > > > > > > > > > >
> > > > > > > > > > > > True enough, but in my experience smp_store_release()
> > > > > > > > > > > > and
> > > > > > > > > > > > smp_load_acquire() are a -lot- easier to use than other
> > > > > > > > > > > > barriers,
> > > > > > > > > > > > and transitivity will help promote their use. So...
> > > > > > > > > > > >
> > > > > > > > > > > > All the TSO architectures (x86, s390, SPARC, HPPA, ...)
> > > > > > > > > > > > support transitive
> > > > > > > > > > > > smp_store_release()/smp_load_acquire() via their native
> > > > > > > > > > > > ordering in
> > > > > > > > > > > > combination with barrier() macros. x86 with
> > > > > > > > > > > > CONFIG_X86_PPRO_FENCE=y,
> > > > > > > > > > > > which is not TSO, uses an mfence instruction. Power
> > > > > > > > > > > > supports this via
> > > > > > > > > > > > lwsync's partial cumulativity. ARM64 supports it in
> > > > > > > > > > > > SMP via the new ldar
> > > > > > > > > > > > and stlr instructions (in non-SMP, it uses barrier(),
> > > > > > > > > > > > which suffices
> > > > > > > > > > > > in that case). IA64 supports this via total ordering
> > > > > > > > > > > > of all release
> > > > > > > > > > > > instructions in theory and by the actual full-barrier
> > > > > > > > > > > > implementation
> > > > > > > > > > > > in practice (and the fact that gcc emits st.rel and
> > > > > > > > > > > > ld.acq instructions
> > > > > > > > > > > > for volatile stores and loads). All other
> > > > > > > > > > > > architectures use smp_mb(),
> > > > > > > > > > > > which is transitive.
> > > > > > > > > > > >
> > > > > > > > > > > > Did I miss anything?
> > > > > > > > > > >
> > > > > > > > > > > I think that about covers it.. the only odd duckling
> > > > > > > > > > > might be s390 which
> > > > > > > > > > > is documented as TSO but recently grew
> > > > > > > > > > > smp_mb__{before,after}_atomic(),
> > > > > > > > > > >
Re: Glibc recvmsg from kernel netlink socket hangs forever
On Sep 24, 2015, at 10:34 PM, Guenter Roeck wrote: > Herbert, > > On 09/24/2015 09:58 PM, Herbert Xu wrote: >> On Thu, Sep 24, 2015 at 09:36:53PM -0700, Guenter Roeck wrote: >>> >>> http://comments.gmane.org/gmane.linux.network/363085 >>> >>> might explain your problem. >>> >>> I thought this was resolved in 4.1, but it looks like the problem still >>> persists >>> there. At least I have reports from my workplace that 4.1.6 and 4.1.7 are >>> still >>> affected. I don't know if there have been any relevant changes in 4.2. >>> >>> Copying Herbert and Eric for additional input. >> >> There was a separate bug discovered by Tejun recently. You need >> to apply the patches >> >> https://patchwork.ozlabs.org/patch/519245/ >> https://patchwork.ozlabs.org/patch/520824/ >> > I assume this is on top of mainline ? > >> There is another follow-up but it shouldn't make any difference >> in practice. >> > > Any idea what may be needed for 4.1 ? > I am currently trying https://patchwork.ozlabs.org/patch/473041/, > but I have no idea if that will help with the problem we are seeing there. Thank you for the patches to try, I'll build a kernel with them early next week and report back. It sounds like it may not match my problem exactly so we'll see. In the meantime, I also observed the following oops: [ 1709.620092] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 1709.624058] BUG: unable to handle kernel paging request at ea001dbef3c0 [ 1709.624058] IP: [] 0xea001dbef3c0 [ 1709.624058] PGD 78f7dc067 PUD 78f7db067 PMD 80078ec001e3 [ 1709.624058] Oops: 0011 [#1] SMP [ 1709.624058] Modules linked in: i2c_piix4(E) btrfs(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) aesni_intel(E) aes_x86_64(E) lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) cryptd(E) floppy(E) [ 1709.624058] CPU: 4 PID: 19714 Comm: pf_dump Tainted: GE 4.0.4 #1 [ 1709.624058] Hardware name: Xen HVM domU, BIOS 4.2.amazon 05/06/2015 [ 1709.624058] task: 880605a18000 ti: 8805f9358000 task.ti: 8805f9358000 [ 1709.624058] RIP: 0010:[] [] 0xea001dbef3c0 [ 1709.624058] RSP: 0018:8805f935bbc0 EFLAGS: 00010246 [ 1709.624058] RAX: ea001dbef3c0 RBX: 0007 RCX: [ 1709.624058] RDX: 2100 RSI: 8805f992f308 RDI: 8806622f6b00 [ 1709.624058] RBP: 8805f935bc08 R08: 1ec0 R09: 2100 [ 1709.624058] R10: R11: 880771003200 R12: 8806622f6b00 [ 1709.624058] R13: 0002 R14: 8239e238 R15: 8805f992f308 [ 1709.624058] FS: 7f0735f29700() GS:88078fc8() knlGS: [ 1709.624058] CS: 0010 DS: ES: CR0: 80050033 [ 1709.624058] CR2: ea001dbef3c0 CR3: 0005f7e88000 CR4: 001407e0 [ 1709.624058] Stack: [ 1709.624058] 81735ca2 8805f992f348 88076b491400 [ 1709.624058] 8805f992f000 8806622f6b00 0ec0 8805f992f308 [ 1709.624058] 88065ffb 8805f935bc38 8176028a 8805f992f000 [ 1709.624058] Call Trace: [ 1709.624058] [] ? rtnl_dump_all+0x122/0x1a0 [ 1709.624058] [] netlink_dump+0x11a/0x2d0 [ 1709.624058] [] netlink_recvmsg+0x1e5/0x360 [ 1709.624058] [] ? kmem_cache_free+0x1b9/0x1d0 [ 1709.624058] [] sock_recvmsg+0x6f/0xa0 [ 1709.624058] [] ___sys_recvmsg+0xe4/0x200 [ 1709.624058] [] ? __fget_light+0x25/0x70 [ 1709.624058] [] __sys_recvmsg+0x42/0x80 [ 1709.624058] [] ? int_check_syscall_exit_work+0x34/0x3d [ 1709.624058] [] SyS_recvmsg+0x12/0x20 [ 1709.624058] [] system_call_fastpath+0x16/0x1b [ 1709.624058] Code: 00 00 00 ff ff ff ff 01 00 00 00 00 01 10 00 00 00 ad de 00 02 20 00 00 00 ad de 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 ff ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1709.798299] RIP [] 0xea001dbef3c0 [ 1709.798299] RSP [ 1709.798299] CR2: ea001dbef3c0 [ 1709.798299] ---[ end trace 2e069ceceed3d61a ]--- It's so far only been noticed once. I don't know if it is the same issue, it certainly doesn't always happen when this problem occurs, but it looks curious all the same... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] Docs: dt: fsl-mc: update binding to include msi-parent
The Freescale Management Complex and all associated objects
use message interrupts, and thus an msi-parent is required.
Signed-off-by: Stuart Yoder
---
Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index c7a26ca..6aac955 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -30,11 +30,17 @@ Required properties:
region may not be present in some scenarios, such
as in the device tree presented to a virtual machine.
+- msi-parent
+Value type:
+Definition: Must be present and point to the MSI controller node
+handling message interrupts for the MC.
+
Example:
fsl_mc: fsl-mc@80c00 {
compatible = "fsl,qoriq-mc";
reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
<0x 0x0834 0 0x4>; /* MC control reg */
+msi-parent = <>;
};
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/5] Support CPR on MSM8916
On Friday, September 18, 2015 05:52:04 PM Stephen Boyd wrote:
> This patch series adds support for CPR on MSM8916. The first
> patch exposes a corner voting API to the CPR driver so that we can
> change the corner for the MX regulator. If possible I would
> like to make this patch prettier, but I don't have any great
> ideas right now. The next patch adds support to adjust voltages in the OPP
> layer, and then hooks that up to cpufreq-dt so that we can adjust
> the voltage in response to what CPR tells us to do. I've also thrown
> in a patch to make RCU lockdep warnings go away, but I'm not sure if it's
> right. There's still work to do.
>
> The final patch adds the CPR driver. This still has some rough edges. With
> the OPPv2 bindings I'm thinking of moving the frequency tables into DT
> and adding a custom vendor property to describe which fuse corner to use for
> each frequency.
>
> Once you have these patches in place along with a CPU clock driver you
> can eanble enable cpufreq-dt and add the cpufreq-dt device (maybe the
> CPR driver should add the cpufreq-dt device?) and you'll see interrupts
> for CPR and OPP voltage adjustments triggering CPUfreq to modify voltages.
>
> Andy Gross (1):
> regulator: smd: Add floor and corner operations
>
> Stephen Boyd (4):
> PM / OPP: Support adjusting OPP voltages at runtime
> OPP: Allow notifiers to call dev_pm_opp_get_{voltage,freq} RCU-free
> cpufreq-dt: Handle OPP voltage adjust events
> power: avs: Add support for CPR (Core Power Reduction)
>From the responses so far I gather there will be a v3?
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next v10 2/3] mfd: devicetree: add bindings for Atmel Flexcom
On Thu, 24 Sep 2015, Cyrille Pitchen wrote:
> This patch documents the DT bindings for the Atmel Flexcom which will be
> introduced by sama5d2x SoCs. These bindings will be used by the actual
> Flexcom driver to be sent in another patch.
>
> Signed-off-by: Cyrille Pitchen
> Acked-by: Boris Brezillon
> Acked-by: Alexandre Belloni
> Acked-by: Nicolas Ferre
> ---
> .../devicetree/bindings/mfd/atmel-flexcom.txt | 67
> ++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> new file mode 100644
> index ..fc3511e41542
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> @@ -0,0 +1,67 @@
> +* Device tree bindings for Atmel Flexcom (Flexible Serial Communication Unit)
> +
> +The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
> +controller and an USART. Only one function can be used at a time and is
> chosen
> +at boot time according to the device tree.
> +
> +Required properties:
> +- compatible:Should be "atmel,sama5d2-flexcom"
> +- reg: Should be the offset/length value for Flexcom
> dedicated
> + I/O registers (without USART, TWI or SPI registers).
> +- clocks:Should be the Flexcom peripheral clock from PMC.
> +- #address-cells:Should be <1>
> +- #size-cells: Should be <1>
> +- ranges:Should be one range for the full I/O register region
> + (including USART, TWI and SPI registers).
> +- atmel,flexcom-mode:Should be one of the 3 following macros as
> defined in
They're not macros.
> + include/dt-bindings/mfd/atmel-flexcom.h:
This is Linux specific. Please remove it from the binding document.
> + - ATMEL_FLEXCOM_MODE_USART for USART
> + - ATMEL_FLEXCOM_MODE_SPI for SPI
> + - ATMEL_FLEXCOM_MODE_TWI for I2C
> +
> +Required child:
> +a single child device of type matching the "atmel,flexcom-mode" property.
s/a/A/
> +The reg property of this child should be:
> +- <0x200 0x200> for USART
> +- <0x400 0x200> for SPI
> +- <0x600 0x200> for I2C
Address/offset information doesn't belong in the binding document.
> +The phandle provided by the clocks property of the child is the same as one
> for
> +the Flexcom parent.
> +
> +Other properties remain unchanged. See documentation of the respective
> device:
Unchanged since when?
> +- ../serial/atmel-usart.txt
> +- ../spi/spi_atmel.txt
> +- ../i2c/i2c-at91.txt
> +
> +Example:
> +
> +flexcom@f8034000 {
> + compatible = "atmel,sama5d2-flexcom";
> + reg = <0xf8034000 0x200>;
> + clocks = <_clk>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0xf8034000 0x800>;
> + atmel,flexcom-mode = ;
> +
> + spi@400 {
> + compatible = "atmel,at91rm9200-spi";
> + reg = <0x400 0x200>;
> + interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_flx0_default>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <_clk>;
> + clock-names = "spi_clk";
> + atmel,fifo-size = <32>;
> +
> + mtd_dataflash@0 {
> + compatible = "atmel,at25f512b";
> + reg = <0>;
> + spi-max-frequency = <2000>;
> + };
> + };
> +};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next v10 1/3] mfd: atmel-flexcom: create include file with macros used by DT bindings
On Thu, 24 Sep 2015, Cyrille Pitchen wrote: > This patch defines some macros to be used as value for the > "atmel,flexcom-mode" DT property. This value is then written into > the Operating Mode (OPMODE) bit field of the Flexcom Mode Register. > > Signed-off-by: Cyrille Pitchen > Acked-by: Nicolas Ferre > --- > include/dt-bindings/mfd/atmel-flexcom.h | 16 > 1 file changed, 16 insertions(+) > create mode 100644 include/dt-bindings/mfd/atmel-flexcom.h > > diff --git a/include/dt-bindings/mfd/atmel-flexcom.h > b/include/dt-bindings/mfd/atmel-flexcom.h > new file mode 100644 > index ..6728f2851b4d > --- /dev/null > +++ b/include/dt-bindings/mfd/atmel-flexcom.h > @@ -0,0 +1,16 @@ > +/* > + * This header provides macros for Atmel Flexcom DT bindings. > + * > + * Copyright (C) 2015 Cyrille Pitchen > + * > + * GPLv2 only I'm not sure this constitutes as a proper licence statement. > + */ > + > +#ifndef __DT_BINDINGS_ATMEL_FLEXCOM_H__ > +#define __DT_BINDINGS_ATMEL_FLEXCOM_H__ > + > +#define ATMEL_FLEXCOM_MODE_USART 1 > +#define ATMEL_FLEXCOM_MODE_SPI 2 > +#define ATMEL_FLEXCOM_MODE_TWI 3 > + > +#endif /* __DT_BINDINGS_ATMEL_FLEXCOM_H__ */ -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC
On Fri, 25 Sep 2015, Andrew F. Davis wrote:
> On 09/25/2015 11:50 AM, Lee Jones wrote:
> >On Thu, 24 Sep 2015, Andrew F. Davis wrote:
> >
> >>This patch adds support for TPS65912 mfd device. It provides
> >>communication through the I2C and SPI interfaces. It contains
> >>the following components:
> >>
> >> - Regulators
> >> - GPIO controller
> >>
> >>Signed-off-by: Andrew F. Davis
> >>---
> >> drivers/mfd/Kconfig | 24 +++
> >> drivers/mfd/Makefile | 3 +
> >> drivers/mfd/tps65912-core.c | 114 +
> >> drivers/mfd/tps65912-i2c.c | 86 ++
> >> drivers/mfd/tps65912-spi.c | 85 ++
> >> include/linux/mfd/tps65912.h | 393
> >> +++
> >> 6 files changed, 705 insertions(+)
> >> create mode 100644 drivers/mfd/tps65912-core.c
> >> create mode 100644 drivers/mfd/tps65912-i2c.c
> >> create mode 100644 drivers/mfd/tps65912-spi.c
> >> create mode 100644 include/linux/mfd/tps65912.h
> >
> >[...]
> >
> >>+#define TPS65912_IRQ(_name, _reg, _offset) \
> >>+ [TPS65912_IRQ_ ## _name] = {\
> >>+ .mask = TPS65912_ ## _reg ## _ ## _name,\
> >>+ .reg_offset = _offset, \
> >>+ }
> >
> >I told you about this already.
> >
> >If you want this set to be merged for v4.3 then you'll need commit
> >b4fe8ba ("regmap: Add generic macro to define regmap_irq") from my
> >tree.
>
> You asked me to submit this to Mark Brown, I didn't realize you also
> wanted me to use the one in your tree. Using yours will make my lines
> over 80 chars and so it kind of defeats the purpose but I'll do it
> for v4.
I asked two of you to upstream a generic incarnation of your
implementation. The other guy got there first. Now I want everyone
to use it instead of hand-rolling their own.
> >[...]
> >
> >>+static struct i2c_driver tps65912_i2c_driver = {
> >>+ .driver = {
> >>+ .name = "tps65912",
> >>+ .of_match_table = tps65912_i2c_of_match_table,
> >
> >of_match_ptr()
> >
>
> Why? tps65912_i2c_of_match_table is always compiled in.
But it needn't be.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend
On Friday, September 25, 2015 05:13:04 PM Alan Stern wrote: > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > > > On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote: > > > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > > > > > > > We are missing the "no remote wakeup" bit now (well, there is a PM QoS > > > > flag, > > > > but it isn't very useful, so I'd prefer to replace it with a "no remote > > > > wakeup" > > > > bit in struct dev_pm_info or something similar). > > > > > > > > That is actually quite important, because (a) we can save energy but not > > > > configuring the device to do remote wakeup in the first place and (b) > > > > that > > > > may involve more than just the driver (for example, disabling PCI or > > > > ACPI > > > > remote wakeup involves the bus type or similar). > > > > > > > > So it looks like we need to be able to distinguish between "runtime > > > > suspend > > > > with remote wakeup" and "runtime suspend without remote wakeup". > > > > > > > > And if we do the latter, we may not even need the "inhibit" thing any > > > > more, > > > > because suspended devices without that are not configured to do remote > > > > wakeup > > > > cannot really signal anything in the majority of cases. > > > > > > That works only for drivers that use autosuspend to go to low power in > > > between events. It doesn't work for drivers that remain at full power > > > as long as the device file is open. That kind of driver does require > > > an "inhibit" interface. > > > > Or an interface allowing user space to trigger pm_request_idle() for them. > > > > So user space would change the "no remote wakeup" setting and then do the > > "try to suspend now" thing. > > So something like: > > echo on >/sys/.../power/control (in case the device was > already in runtime suspend with wakeups enabled) > echo off >/sys/.../power/wakeup > echo auto >/sys/.../power/control That, or there may be an additional value, say "aggressive", to write to the control file in which case it becomes just echo aggressive >/sys/.../power/control > > This should work. But it would require that the driver doesn't > increment the usage counter when the device file is opened. Right. > I can imagine this might lead to trouble if you're dealing with hardware that > doesn't support remote wakeup very well. The driver wouldn't be able > to work around the hardware issue by incrementing the usage counter. Or the "aggressive" mode wouldn't work for it. > In real life this might not be a serious issue. I don't know. Me neither. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Docs: dt: update binding for Freescale Management Complex
Update the binding for the Freescale Management Complex to include definition of ranges, msi-parent, and dpmac subnodes. Stuart Yoder (3): Docs: dt: fsl-mc: update binding to include msi-parent Docs: dt: fsl-mc update binding to include definition of ranges Docs: dt: fsl-mc: update binding to define dpmac subnodes .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 81 +- 1 file changed, 80 insertions(+), 1 deletion(-) -- 2.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Docs: dt: fsl-mc update binding to include definition of ranges
Define a ranges property to specify the mapping between
the MC address space and the system address space.
Signed-off-by: Stuart Yoder
---
.../devicetree/bindings/misc/fsl,qoriq-mc.txt | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6aac955..848975f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -35,6 +35,26 @@ Required properties:
Definition: Must be present and point to the MSI controller node
handling message interrupts for the MC.
+- ranges
+Value type:
+Definition: A standard property. Defines the mapping between the child
+MC address space and the parent system address space.
+
+The MC address space is defined by 3 components:
+
+
+Valid values for region type are
+ 0x0 - MC portals
+ 0x1 - QBMAN portals
+
+- #address-cells
+Value type:
+Definition: Must be 3. (see definition in 'ranges' property)
+
+- #size-cells
+Value type:
+Definition: Must be 1.
+
Example:
fsl_mc: fsl-mc@80c00 {
@@ -42,5 +62,13 @@ Example:
reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
<0x 0x0834 0 0x4>; /* MC control reg */
msi-parent = <>;
-};
+#address-cells = <3>;
+#size-cells = <1>;
+/*
+ * Region type 0x0 - MC portals
+ * Region type 0x1 - QBMAN portals
+ */
+ranges = <0x0 0x0 0x0 0x8 0x0c00 0x400
+ 0x1 0x0 0x0 0x8 0x1800 0x800>;
+};
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] Docs: dt: fsl-mc: update binding to define dpmac subnodes
The fsl-mc node may optionally have dpmac sub-nodes that describe
the relationship between the Ethernet MACs which belong to the MC
and the Ethernet PHYs on the system board.
Signed-off-by: Stuart Yoder
---
.../devicetree/bindings/misc/fsl,qoriq-mc.txt | 45 ++
1 file changed, 45 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 848975f..6611a7c 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -55,6 +55,40 @@ Required properties:
Value type:
Definition: Must be 1.
+Sub-nodes:
+
+The fsl-mc node may optionally have dpmac sub-nodes that describe
+the relationship between the Ethernet MACs which belong to the MC
+and the Ethernet PHYs on the system board.
+
+The dpmac nodes must be under a node named "dpmacs" which contains
+the following properties:
+
+- #address-cells
+ Value type:
+ Definition: Must be present if dpmac sub-nodes are defined and
must
+ have a value of 1.
+
+- #size-cells
+ Value type:
+ Definition: Must be present if dpmac sub-nodes are defined and
must
+ have a value of 0.
+
+These nodes must have the following properties:
+
+- compatible
+ Value type:
+ Definition: Must be "fsl,qoriq-mc-dpmac".
+
+- reg
+ Value type:
+ Definition: Specifies the id of the dpmac.
+
+- phy-handle
+ Value type:
+ Definition: Specifies the phandle to the PHY device node
associated
+ with the this dpmac.
+
Example:
fsl_mc: fsl-mc@80c00 {
@@ -71,4 +105,15 @@ Example:
*/
ranges = <0x0 0x0 0x0 0x8 0x0c00 0x400
0x1 0x0 0x0 0x8 0x1800 0x800>;
+
+dpmacs {
+#address-cells = <1>;
+#size-cells = <0>;
+
+dpmac@1 {
+compatible = "fsl,qoriq-mc-dpmac";
+reg = <1>;
+phy-handle = <_phy0>;
+}
+}
};
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6 4/9] Input: goodix - write configuration data to device
> -Original Message-
> From: Bastien Nocera [mailto:had...@hadess.net]
> Sent: 25 September, 2015 17:41
> To: Tirdea, Irina; Dmitry Torokhov; Aleksei Mamlin;
> linux-in...@vger.kernel.org
> Cc: Mark Rutland; Purdila, Octavian; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v6 4/9] Input: goodix - write configuration data to device
>
> On Tue, 2015-09-15 at 17:31 +0300, Irina Tirdea wrote:
> > Goodix devices can be configured by writing custom data to the device
> > at
> > init. The configuration data is read with request_firmware from
> > "goodix__cfg.bin", where is the product id read from the
> > device
> > (e.g.: goodix_911_cfg.bin for Goodix GT911, goodix_9271_cfg.bin for
> > GT9271).
> >
> > The configuration information has a specific format described in the
> > Goodix
> > datasheet. It includes X/Y resolution, maximum supported touch
> > points,
> > interrupt flags, various sesitivity factors and settings for advanced
>
> sensitivity.
Will fix this in next version of the patches. I will wait for you reply on
the gpio issue before sending a new version.
Thanks,
Irina
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 1/2] audit: stop an old auditd being starved out by a new auditd
On Friday, September 25, 2015 07:10:19 AM Richard Guy Briggs wrote:
> On 15/09/24, Paul Moore wrote:
> > On Friday, September 18, 2015 03:59:58 AM Richard Guy Briggs wrote:
...
> > XXX
>
> ???
Sorry, ignore that. The "XXX" was a placeholder for me while I was reviewing
your patch; normally I got back and replace those all with text or drop them,
but one slipped through in this case.
> > > diff --git a/kernel/audit.c b/kernel/audit.c
> > > index 18cdfe2..3399ab2 100644
> > > --- a/kernel/audit.c
> > > +++ b/kernel/audit.c
> > > @@ -810,6 +810,15 @@ static int audit_set_feature(struct sk_buff *skb)
> > >
> > > return 0;
> > >
> > > }
> > >
> > > +static int audit_ping(pid_t pid, u32 seq, u32 portid)
> > > +{
> > > + struct sk_buff *skb = audit_make_reply(portid,seq,AUDIT_PING,0,0,
> > > + , sizeof(pid));
> >
> > This is almost surely going to end up using the wrong netlink sequence
> > number and portid since you are passing the new requestor's information
> > below. I didn't chase down the netlink_unicast() guts to see if it
> > replaces the portid, it might (it probably does), but that still leaves
> > the sequence number.
>
> It is intended to use the new pid and new netlink sequence number to the
> old audit_sock and old portid.
You don't want to put the new portid/seqno in a netlink header that is being
sent to the old auditd.
> There is no other sequence number available and it is this new sequence
> number and pid that needs reporting to the old auditd.
The audit_make_reply() function is the wrong thing to be using here, we should
create our own buffer from scratch like most other records. Also, yes, we
want to include the new pid, but I really don't think there is any value in
including the seqno of the AUDIT_SET/AUDIT_STATUS_PID message.
> > Also, this is more of a attempted hijack message and not a simple ping,
> > right?
>
> Ok, so maybe AUDIT_PING is not the appropriate name for it. I don't
> have a problem changing it, but I think the pid of the hijacker would be
> useful information to the ping-ee unless the ping message was only ever
> issues in a contextless kernel-initiated message.
Let's change the message name, this isn't a ping message and we may want to
have a ping message at some point in the future.
> > If we want to create a simple ping message, leave the pid out of it; if we
> > want to indicate to an existing auditd that another process is attempting
> > to hijack the audit connection then we should probably create a proper
> > audit record with a type other than AUDIT_PING. I tend to think there is
> > more value in the hijack message than the ping message, but I can be
> > convinced either way.
>
> Is there any compelling reason to create a pure ping message that gets
> sent out periodically to test if auditd is still alive (audit_pid,
> audit_sock and audit_nlk_portid are valid)?
Possibly, but let's leave that as a future experiment.
> Is there any reason to reserve that AUDIT_PING macro at this time should it
> be determined that it is necessary in the future?
I don't think we need to reserve it now, we can allocate the ping message type
if/when we decide to implement it.
--
paul moore
security @ redhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend
On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote: > > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote: > > > > > We are missing the "no remote wakeup" bit now (well, there is a PM QoS > > > flag, > > > but it isn't very useful, so I'd prefer to replace it with a "no remote > > > wakeup" > > > bit in struct dev_pm_info or something similar). > > > > > > That is actually quite important, because (a) we can save energy but not > > > configuring the device to do remote wakeup in the first place and (b) that > > > may involve more than just the driver (for example, disabling PCI or ACPI > > > remote wakeup involves the bus type or similar). > > > > > > So it looks like we need to be able to distinguish between "runtime > > > suspend > > > with remote wakeup" and "runtime suspend without remote wakeup". > > > > > > And if we do the latter, we may not even need the "inhibit" thing any > > > more, > > > because suspended devices without that are not configured to do remote > > > wakeup > > > cannot really signal anything in the majority of cases. > > > > That works only for drivers that use autosuspend to go to low power in > > between events. It doesn't work for drivers that remain at full power > > as long as the device file is open. That kind of driver does require > > an "inhibit" interface. > > Or an interface allowing user space to trigger pm_request_idle() for them. > > So user space would change the "no remote wakeup" setting and then do the > "try to suspend now" thing. So something like: echo on >/sys/.../power/control (in case the device was already in runtime suspend with wakeups enabled) echo off >/sys/.../power/wakeup echo auto >/sys/.../power/control This should work. But it would require that the driver doesn't increment the usage counter when the device file is opened. I can imagine this might lead to trouble if you're dealing with hardware that doesn't support remote wakeup very well. The driver wouldn't be able to work around the hardware issue by incrementing the usage counter. In real life this might not be a serious issue. I don't know. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] PM / OPP: of_property_count_u32_elems() can return errors
On Tuesday, September 22, 2015 09:51:27 AM Stephen Boyd wrote:
> On 09/22, Viresh Kumar wrote:
> > of_property_count_u32_elems() will never return 0, but a -ve error value
> > of a positive count. And so the current !count check is wrong.
> >
> > Also, a missing "opp-microvolt" property isn't a problem and so we need
> > to do of_find_property() separately to confirm that.
> >
> > Fixes: 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2"
> > bindings")
> > Signed-off-by: Viresh Kumar
> > ---
>
> Reviewed-by: Stephen Boyd
Applied, thanks!
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / OPP: Fix typo modifcation -> modification
On Thursday, September 24, 2015 01:58:21 PM Viresh Kumar wrote: > On 24 September 2015 at 12:28, Stephen Boyd wrote: > > Reported-by: Viresh Kumar > > Signed-off-by: Stephen Boyd > > --- > > drivers/base/power/opp/core.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c > > index 8a72f0e586e8..62b918144b5b 100644 > > --- a/drivers/base/power/opp/core.c > > +++ b/drivers/base/power/opp/core.c > > @@ -961,7 +961,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_add); > > * share a common logic which is isolated here. > > * > > * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the > > - * copy operation, returns 0 if no modifcation was done OR modification was > > + * copy operation, returns 0 if no modification was done OR modification > > was > > * successful. > > * > > * Locking: The internal device_opp and opp structures are RCU protected. > > @@ -1049,7 +1049,7 @@ unlock: > > * mutex locking or synchronize_rcu() blocking calls cannot be used. > > * > > * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the > > - * copy operation, returns 0 if no modifcation was done OR modification was > > + * copy operation, returns 0 if no modification was done OR modification > > was > > * successful. > > */ > > int dev_pm_opp_enable(struct device *dev, unsigned long freq) > > @@ -1075,7 +1075,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_enable); > > * mutex locking or synchronize_rcu() blocking calls cannot be used. > > * > > * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the > > - * copy operation, returns 0 if no modifcation was done OR modification was > > + * copy operation, returns 0 if no modification was done OR modification > > was > > * successful. > > */ > > int dev_pm_opp_disable(struct device *dev, unsigned long freq) > > Acked-by: Viresh Kumar Applied, thanks! Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/15] block, dax, pmem: reference counting infrastructure
On Fri, 2015-09-25 at 04:32 -0700, Christoph Hellwig wrote:
> On Thu, Sep 24, 2015 at 05:03:18PM -0700, Dan Williams wrote:
> > That makes sense to me, especially because drivers/nvdimm/blk.c is
> > broken in the same way as drivers/nvdimm/pmem.c and it would be
> > awkward to have it use blk_dax_get() / blk_dax_put(). The
> > percpu_refcount should be valid for all queues and it will only ever
> > be > 1 in the blk_mq and libnvdimm cases (for now). Will fix.
>
> Looking at this a bit more it might actually make sense to grab the
> referene in common code before calling into ->make_request.
>
> Jens, any opinion on that?
...this works for me:
8<-
Subject: [PATCH] block: generic request_queue reference counting
Allow pmem, and other synchronous/bio-based block drivers, to fallback
on a per-cpu reference count managed by the core for tracking queue
live/dead state.
The existing per-cpu reference count for the blk_mq case is promoted to
be used in all block i/o scenarios. This involves initializing it by
default, waiting for it to drop to zero at exit, and holding a live
reference over the invocation of q->make_request_fn() in
generic_make_request(). The blk_mq code continues to take its own
reference per blk_mq request and retains the ability to freeze the
queue, but the check that the queue is frozen is moved to
generic_make_request().
This fixes crash signatures like the following:
BUG: unable to handle kernel paging request at 88014000
[..]
Call Trace:
[] ? copy_user_handle_tail+0x5f/0x70
[] pmem_do_bvec.isra.11+0x70/0xf0 [nd_pmem]
[] pmem_make_request+0xd1/0x200 [nd_pmem]
[] ? mempool_alloc+0x72/0x1a0
[] generic_make_request+0xd6/0x110
[] submit_bio+0x76/0x170
[] submit_bh_wbc+0x12f/0x160
[] submit_bh+0x12/0x20
[] jbd2_write_superblock+0x8d/0x170
[] jbd2_mark_journal_empty+0x5d/0x90
[] jbd2_journal_destroy+0x24b/0x270
[] ? put_pwq_unlocked+0x2a/0x30
[] ? destroy_workqueue+0x225/0x250
[] ext4_put_super+0x64/0x360
[] generic_shutdown_super+0x6a/0xf0
Cc: Jens Axboe
Cc: Keith Busch
Cc: Ross Zwisler
Suggested-by: Christoph Hellwig
Signed-off-by: Dan Williams
---
block/blk-core.c | 71 ++--
block/blk-mq-sysfs.c | 6
block/blk-mq.c | 80 +++---
block/blk-sysfs.c | 3 +-
block/blk.h| 14 +
include/linux/blk-mq.h | 1 -
include/linux/blkdev.h | 2 +-
7 files changed, 102 insertions(+), 75 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 2eb722d48773..6062550baaef 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -554,19 +554,17 @@ void blk_cleanup_queue(struct request_queue *q)
* Drain all requests queued before DYING marking. Set DEAD flag to
* prevent that q->request_fn() gets invoked after draining finished.
*/
- if (q->mq_ops) {
- blk_mq_freeze_queue(q);
- spin_lock_irq(lock);
- } else {
- spin_lock_irq(lock);
+ blk_freeze_queue(q);
+ spin_lock_irq(lock);
+ if (!q->mq_ops)
__blk_drain_queue(q, true);
- }
queue_flag_set(QUEUE_FLAG_DEAD, q);
spin_unlock_irq(lock);
/* @q won't process any more request, flush async actions */
del_timer_sync(>backing_dev_info.laptop_mode_wb_timer);
blk_sync_queue(q);
+ percpu_ref_exit(>q_usage_counter);
if (q->mq_ops)
blk_mq_free_queue(q);
@@ -629,6 +627,40 @@ struct request_queue *blk_alloc_queue(gfp_t gfp_mask)
}
EXPORT_SYMBOL(blk_alloc_queue);
+int blk_queue_enter(struct request_queue *q, gfp_t gfp)
+{
+ while (true) {
+ int ret;
+
+ if (percpu_ref_tryget_live(>q_usage_counter))
+ return 0;
+
+ if (!(gfp & __GFP_WAIT))
+ return -EBUSY;
+
+ ret = wait_event_interruptible(q->mq_freeze_wq,
+ !atomic_read(>mq_freeze_depth) ||
+ blk_queue_dying(q));
+ if (blk_queue_dying(q))
+ return -ENODEV;
+ if (ret)
+ return ret;
+ }
+}
+
+void blk_queue_exit(struct request_queue *q)
+{
+ percpu_ref_put(>q_usage_counter);
+}
+
+static void blk_queue_usage_counter_release(struct percpu_ref *ref)
+{
+ struct request_queue *q =
+ container_of(ref, struct request_queue, q_usage_counter);
+
+ wake_up_all(>mq_freeze_wq);
+}
+
struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, int node_id)
{
struct request_queue *q;
@@ -690,11 +722,22 @@ struct request_queue *blk_alloc_queue_node(gfp_t
gfp_mask, int node_id)
init_waitqueue_head(>mq_freeze_wq);
- if (blkcg_init_queue(q))
+ /*
+* Init percpu_ref in atomic mode so that it's faster to shutdown.
+* See
RE: [PATCH v3 1/5] Input: goodix - reset device at init
> -Original Message- > From: Bastien Nocera [mailto:had...@hadess.net] > Sent: 25 September, 2015 17:44 > To: Tirdea, Irina; linux-in...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Rob Herring; Pawel Moll; Ian Campbell; > Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark > Rutland; devicet...@vger.kernel.org > Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init > > On Thu, 2015-09-10 at 14:04 +, Tirdea, Irina wrote: > > > > > -Original Message- > > > From: Bastien Nocera [mailto:had...@hadess.net] > > > Sent: 09 September, 2015 20:03 > > > To: Tirdea, Irina; linux-in...@vger.kernel.org > > > Cc: linux-kernel@vger.kernel.org; Rob Herring; Pawel Moll; Ian > > > Campbell; Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark > > > Rutland; devicet...@vger.kernel.org > > > Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init > > > > > > On Thu, 2015-07-30 at 11:27 +, Tirdea, Irina wrote: > > > > I can send some additional patches that will simplify testing the > > > > configuration update to the Goodix device. I think this feature > > > > is > > > > the easiest > > > > to test so we can determine if writing to the interrupt pin > > > > actually > > > > works. > > > > However, even if it is a BIOS problem and the code will work, the > > > > warning > > > > will still be printed in dmesg. > > > > > > > > > Somehow missed this mail before replying to the current patchset. > > > I'd > > > be fine with that, though it's still not clear to me whether the > > > BIOS/hardware is at fault, or the code that's being added to the > > > driver > > > ;) > > > > > > > The reset procedure is described in the Goodix GT911 datasheet [1] > > and is > > used for power-on reset and power management. The power-on sequence > > is described in chapter 6.1. I2C Timing, in the Power-on Timing > > diagram. > > The sequence for putting the device to sleep is described in chapter > > 7.1. Operating Modes, c) Sleep mode. These sequences use the > > interrupt > > pin as output. > > > > The warning you mentioned comes from the following code in the goodix > > driver, which sets the interrupt to be used as output: > > > > + error = gpiod_direction_output(ts->gpiod_int, ts->client- > > >addr == 0x14); > > > > The gpiod_direction_output() call ends up in > > drivers/pinctrl/intel/pinctrl-baytrail.c: > > /* > > * Before making any direction modifications, do a check if gpio > > * is set for direct IRQ. On baytrail, setting GPIO to output does > > * not make sense, so let's at least warn the caller before they > > shoot > > * themselves in the foot. > > */ > > WARN(readl(conf_reg) & BYT_DIRECT_IRQ_EN, > > "Potential Error: Setting GPIO with direct_irq_en to output"); > > > > So the problem comes from using the gpio interrupt pin as output, > > which > > should not work on Baytrail if BYT_DIRECT_IRQ_EN is set by BIOS. > > The above warning is introduced and discussed in [2] and [3]. As I > > mentioned, > > this could be a real HW issue or the BIOS sets BYT_DIRECT_IRQ_EN when > > it should not. I have also tested these patches on a Baytrail > > plarform > > (that uses the same pinctrl driver), but I did not see any issues > > since > > BYT_DIRECT_IRQ_EN is not set in my case for the interrupt gpio pin. > > Do we have a way to work-around this in the GPIO driver? > > > To determine if using the interrupt pin as output works, you can test > > updating > > the goodix configuration [4]. > > Right, the problem being that it's a later patch in the branch, and > that the driver will fail to probe if there's an error from the GPIO > call. > The warning from your dmesg output will not cause probe to fail. If you look at the code for byt_gpio_direction_output, it will just print a warning and continue [1]: WARN(readl(conf_reg) & BYT_DIRECT_IRQ_EN, "Potential Error: Setting GPIO with direct_irq_en to output"); I thought probe finishes successfully, but due to the warning in dmesg you are not sure whether the IRQ GPIO pin can be used as output. If probe fails, it must be for another reason than the direct_irq_en warning. > Would you have a patch for me to test that would bypass this error, or > at least fallback gracefully to not resetting, not probing GPIOs if > they're badly setup? If the driver fails to initialize the GPIOs, it will at least print some "Failed to get GPIO" warnings in dmesg. Do you have such messages in dmesg or any additional information on why probe fails? The current code will ignore GPIOs if they are not defined in ACPI (see the check for -ENOENT), but does not ignore other error codes. If you want to bypass all GPIO errors, you can use the code below. Thanks, Irina diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c index 9c58583..f7ec0ba 100644 --- a/drivers/input/touchscreen/goodix.c +++ b/drivers/input/touchscreen/goodix.c @@ -528,9 +528,7 @@ static int goodix_ts_probe(struct i2c_client
Re: [PATCH] xen/pvhvm: add soft reset on kexec/kdump support
On 09/25/2015 03:35 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 25, 2015 at 03:19:57PM -0400, Boris Ostrovsky wrote:
On 09/25/2015 03:01 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 25, 2015 at 01:17:40PM -0400, Boris Ostrovsky wrote:
On 09/25/2015 12:07 PM, Vitaly Kuznetsov wrote:
Also, I am not sure I see how this new op will be used in the
hypervisor --- currently AFAICS it is only processed under
is_hardware_domain(). Are there other patches that will support HVM
guests?
Please see my Xen series:
http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg00547.html
(last 'full' submission).
All patches from my 'toolstack-assisted approach to PVHVM guest kexec'
are already merged to xen.git (first 10 are already in 'master' and the
last one is in 'staging').
OK, so I was looking at the right tree. Then I don't understand how
SHUTDOWN_soft_reset would be reached for a non-privileged domain. The only
path that I see is
domain_shutdown()
{
...
if ( is_hardware_domain(d) )
hwdom_shutdown(reason);
...
}
Is there another path to handle this op?
Yes:
e1bd9812966de9a16f30a58e7162b80bd6af361b libxc: support XEN_DOMCTL_soft_reset
operation
and
c57e6ebd8c3e490e353e68d96abec1dad01e72f5 (lib)xl: soft reset support
That's toolstack issuing hypercalls from dom0.
I am asking about (non-privileged) guest itself calling SCHEDOP_shutdown.
The hypervisor ends up calling:
__domain_finalise_shutdown which sends an VIRQ_DOM_EXC to dom0 which
makes the toolstack do all of those operations.
OK. But the I don't see anyone checking that 'reason' (or
'shutdown_code') is SHUTDOWN_soft_reset. In other words, the guest can
do 'xen_reboot(23)' or 'xen_reboot(154)'. Or, it seems, even
'xen_reboot(SHUTDOWN_reboot)'? The only value it shouldn't be is
SHUTDOWN_suspend.
-boris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] scripts/kconfig/Makefile: Allow KBUILD_DEFCONFIG to be a target
Dne 24.9.2015 v 00:16 Michael Ellerman napsal(a): > > > On 23 September 2015 19:50:52 GMT+10:00, Michal Marek > wrote: >> On 2015-09-23 07:40, Michael Ellerman wrote: >>> +else ifneq ($(wildcard >> arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)),) >>> @$(kecho) "*** Default configuration is based on >> '$(KBUILD_DEFCONFIG)'" >>> $(Q)$< $(silent) >> --defconfig=arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig) >>> +else + @$(kecho) "*** Default configuration is based on target >> '$(KBUILD_DEFCONFIG)'" >>> + $(Q)$(MAKE) -f $(srctree)/Makefile $(KBUILD_DEFCONFIG) endif >> >> What is the anticipated usage of this? The patch is not needed to >> make >> >> make ppc64le_defconfig >> >> work with the second patch. If it was, this would create a loop >> anyway. > > The idea is to make 'make defconfig' work when KBUILD_DEFCONFIG is > ppc64le_defconfig (which happens for us when uname returns ppc64le) > and additionally when ppc64le_defconfig is not a real file. Ah, that makes sense. You can add Acked-by: Michal Marek if you want. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] convert to use generic irq handler
On 9/25/15 12:28 PM, Grygorii Strashko wrote: This patch series contains patches which fixes wrong APIs usage in atomic context on RT-kernel. The final goal is to make TI OMAP GPIO driver compatible with -RT kernel as much as possible. Patch 1: required to be compatible with -RT kernel, because PM runtime's irq_safe mode is incompatible with -RT. Patch 2: This patch converts TI OMAP GPIO driver to use generic irq handler instead of chained IRQ handler. This way OMAP GPIO driver will be compatible with RT-kernel where it will be forced thread IRQ handler while in non-RT kernel it still will be executed in HW IRQ context. Boot, basic gpio functionality tested on: dra7-evm, BeagleBone(white), am43xx-gpevm, am437x-sk Manually tested on dra7-evm including suspend/resume and wakeup. Links on RFC: https://lkml.org/lkml/2015/8/18/161 https://lkml.org/lkml/2015/8/18/162 Grygorii Strashko (2): gpio: omap: move pm runtime in irq_chip.irq_bus_lock/sync_unlock gpio: omap: convert to use generic irq handler Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC] x86: Reduce MAX_LOCAL_APIC and MAX_IO_APICS
Before this change MAX_LOCAL_APIC had the fixed value of 32*1024.
Such a big value causes several data arrays to be quite oversized:
phys_cpu_present_map is 4 kbytes (one bit per apic id),
__apicid_to_node[] is 64 kbytes,
apic_version[] is 128 kbytes.
On "usual" systems, APIC ids simply go from zero
to maximum logical CPU number, mirroring CPU ids.
On broken and unusual multi-socket systems
APIC ids can be non-contiguous.
This patch changes MAX_LOCAL_APIC definition as follows:
= It is guaranteed to be at least 16.
= If NR_CPUS > 16, then it's equal to NR_CPUS.
= A new CONFIG_MAX_LAPIC_ID can be used to increase it
(but not decrease).
MAX_IO_APICS was 128. This is a bit large too, making,
for example, ioapics[] array 9216 bytes big.
After this patch, MAX_IO_APICS is at least 8, at most 128.
If NR_CPUS is in this range, then MAX_IO_APICS = NR_CPUS.
apic_version[] array is changed from int to u8 -
APIC version values as of year 2015 are no larger than 0x1f
on all known CPUs.
A bit of code added to ensure that the statement
apic_version[apicid] = version;
in generic_processor_info() is safe wrt bad values in both
'apicid' and 'version' variables.
This change reduces NR_CPUS=64 kernel's data size by 204661 bytes:
text data bss dec hex filename
91353669 13825744 19021824 124201237 7672915 vmlinux.before
91353680 13760336 18882560 123996576 76409a0 vmlinux
Signed-off-by: Denys Vlasenko
CC: Ingo Molnar
CC: Jiang Liu
CC: Thomas Gleixner
CC: Len Brown
CC: x...@kernel.org
CC: linux-kernel@vger.kernel.org
---
arch/x86/Kconfig | 11 +++
arch/x86/include/asm/apicdef.h | 23 +--
arch/x86/include/asm/mpspec.h | 2 +-
arch/x86/kernel/apic/apic.c| 19 ++-
4 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 328c835..9e7c4c1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -872,6 +872,17 @@ config NR_CPUS
This is purely to save memory - each supported CPU adds
approximately eight kilobytes to the kernel image.
+config MAX_LAPIC_ID
+ int "Maximum APIC ID"
+ range 8 32768
+ default "8"
+ ---help---
+ Use this option to set maximum allowed Local APIC ID higher than
+ maximum number of CPUs. This may be necessary for machines
+ with large number of processor sockets and non-contiguous
+ LAPIC numbering.
+ This setting will be automatically rounded up, if necessary.
+
config SCHED_SMT
bool "SMT (Hyperthreading) scheduler support"
depends on SMP
diff --git a/arch/x86/include/asm/apicdef.h b/arch/x86/include/asm/apicdef.h
index c46bb99..64e2476 100644
--- a/arch/x86/include/asm/apicdef.h
+++ b/arch/x86/include/asm/apicdef.h
@@ -147,15 +147,26 @@
#define XAPIC_ENABLE (1UL << 11)
#define X2APIC_ENABLE (1UL << 10)
-#ifdef CONFIG_X86_32
-# define MAX_IO_APICS 64
-# define MAX_LOCAL_APIC 256
-#else
-# define MAX_IO_APICS 128
-# define MAX_LOCAL_APIC 32768
+/*
+ * Allow non-contiguous APIC IDs for small machines:
+ * APIC ids 0..15 are valid in any config.
+ * Typical SMP machines have contiguous APIC IDs: 0..NR_CPUS-1.
+ * CONFIG_MAX_LAPIC_ID can override.
+ */
+#define MAX_LOCAL_APIC (NR_CPUS < 16 ? 16 : NR_CPUS)
+#if MAX_LOCAL_APIC < CONFIG_MAX_LAPIC_ID
+# undef MAX_LOCAL_APIC
+# define MAX_LOCAL_APIC CONFIG_MAX_LAPIC_ID
#endif
/*
+ * Minimum is 8.
+ * For largish NR_CPUS, we expect to have no more IOAPICs than CPUs.
+ * No matter how large NR_CPUS is, max is 128.
+ */
+#define MAX_IO_APICS (NR_CPUS < 8 ? 8 : NR_CPUS < 128 ? NR_CPUS : 128)
+
+/*
* All x86-64 systems are xAPIC compatible.
* In the following, "apicid" is a physical APIC ID.
*/
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index b07233b..8d0c2e6 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -6,7 +6,7 @@
#include
#include
-extern int apic_version[];
+extern u8 apic_version[];
extern int pic_mode;
#ifdef CONFIG_X86_32
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 24e94ce..f49a956 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1798,7 +1798,7 @@ void __init register_lapic_address(unsigned long address)
}
}
-int apic_version[MAX_LOCAL_APIC];
+u8 apic_version[MAX_LOCAL_APIC];
/*
* Local APIC interrupts
@@ -2054,6 +2054,23 @@ int generic_processor_info(int apicid, int version)
return -EINVAL;
}
+ if ((unsigned)apicid >= ARRAY_SIZE(apic_version)) {
+ int thiscpu = max + disabled_cpus;
+ pr_warning("APIC: APIC id 0x%x is too large."
+ " Processor %d ignored.\n",
+ apicid, thiscpu);
+ disabled_cpus++;
+ return -EINVAL;
+ }
+ if ((unsigned)version > 255) {
+ int thiscpu =
[GIT PULL] cgroup fixes for v4.3-rc2
Hello, Linus.
Another cgroup fix pull. The cgroup writeback support got
inadvertently enabled for traditional hierarchies revealing two
regressions which are currently being worked on. It shouldn't have
been enabled on traditional hierarchies, so disable it on them. This
is enough for making the regressions go away for people who aren't
experimenting with cgroup.
Thanks.
The following changes since commit 0c986253b939cc14c69d4adbe2b4121bdf4aa220:
Revert "sched, cgroup: replace signal_struct->group_rwsem with a global
percpu_rwsem" (2015-09-16 11:51:12 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-4.3-fixes
for you to fetch changes up to 9badce000e2ce68ba74838a3cd356dde58221c2f:
cgroup, writeback: don't enable cgroup writeback on traditional hierarchies
(2015-09-24 16:48:52 -0400)
Tejun Heo (1):
cgroup, writeback: don't enable cgroup writeback on traditional
hierarchies
include/linux/backing-dev.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
index 5a5d79e..d5eb4ad1 100644
--- a/include/linux/backing-dev.h
+++ b/include/linux/backing-dev.h
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -252,13 +253,19 @@ int inode_congested(struct inode *inode, int cong_bits);
* @inode: inode of interest
*
* cgroup writeback requires support from both the bdi and filesystem.
- * Test whether @inode has both.
+ * Also, both memcg and iocg have to be on the default hierarchy. Test
+ * whether all conditions are met.
+ *
+ * Note that the test result may change dynamically on the same inode
+ * depending on how memcg and iocg are configured.
*/
static inline bool inode_cgwb_enabled(struct inode *inode)
{
struct backing_dev_info *bdi = inode_to_bdi(inode);
- return bdi_cap_account_dirty(bdi) &&
+ return cgroup_on_dfl(mem_cgroup_root_css->cgroup) &&
+ cgroup_on_dfl(blkcg_root_css->cgroup) &&
+ bdi_cap_account_dirty(bdi) &&
(bdi->capabilities & BDI_CAP_CGROUP_WRITEBACK) &&
(inode->i_sb->s_iflags & SB_I_CGROUPWB);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote: > On 25 September 2015 at 13:33, Rafael J. Wysocki wrote: > > You're going to change that into bool in the next patch, right? > > Yeah. > > > So what if bool is a byte and the field is not word-aligned > > Its between two 'unsigned long' variables today, and the struct isn't packed. > So, it will be aligned, isn't it? > > > and changing > > that byte requires a read-modify-write. How do we ensure that things remain > > consistent in that case? > > I didn't understood why a read-modify-write is special here? That's > what will happen > to most of the non-word-sized fields anyway? > > Probably I didn't understood what you meant.. Say you have three adjacent fields in a structure, x, y, z, each one byte long. Initially, all of them are equal to 0. CPU A writes 1 to x and CPU B writes 2 to y at the same time. What's the result? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/19] SUNRPC: fix variable type
ACK. Assuming Trond gets this.--b.
On Thu, Sep 24, 2015 at 04:00:09PM +0200, Andrzej Hajda wrote:
> Due to incorrect len type bc_send_request returned always zero.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi,
>
> To avoid problems with too many mail recipients I have sent whole
> patchset only to LKML. Anyway patches have no dependencies.
>
> Regards
> Andrzej
> ---
> net/sunrpc/xprtsock.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
> index 1a85e0e..60fb002 100644
> --- a/net/sunrpc/xprtsock.c
> +++ b/net/sunrpc/xprtsock.c
> @@ -2472,7 +2472,7 @@ static int bc_send_request(struct rpc_task *task)
> {
> struct rpc_rqst *req = task->tk_rqstp;
> struct svc_xprt *xprt;
> - u32 len;
> + int len;
>
> dprintk("sending request with xid: %08x\n", ntohl(req->rq_xid));
> /*
> --
> 1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
On 25 September 2015 at 13:33, Rafael J. Wysocki wrote: > You're going to change that into bool in the next patch, right? Yeah. > So what if bool is a byte and the field is not word-aligned Its between two 'unsigned long' variables today, and the struct isn't packed. So, it will be aligned, isn't it? > and changing > that byte requires a read-modify-write. How do we ensure that things remain > consistent in that case? I didn't understood why a read-modify-write is special here? That's what will happen to most of the non-word-sized fields anyway? Probably I didn't understood what you meant.. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Make /dev/urandom scalable
On Fri, Sep 25, 2015 at 03:07:54PM -0400, Austin S Hemmelgarn wrote: > > Interestingly, based on what dieharder is already saying about performance, > /dev/urandom is slower than AES_OFB (at least, on this particular system, > happy to provide hardware specs if someone wants). Yeah, not surprised by that. We're currently using a crypto hash instead of AES, which means we're not doing any kind of hardware acceleration. Crazy applications that want to spend 100% of the CPU generating random numbers instead of you know, doing _useful_ work notwithstanding, /dev/urandom never had high performance as one of its design goals. The assumption was that if you needed that kind of performance, you would use a user-space cryptographic random number generator. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
