[PATCH] watchdog: sp805: add restart handler
Add restart handler for SP805 watchdog so that the driver can be
used to reboot the system.
Signed-off-by: Jongsung Kim
---
drivers/watchdog/sp805_wdt.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index 01d816251302..01f7b6c29f92 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -67,6 +68,7 @@ struct sp805_wdt {
struct clk *clk;
struct amba_device *adev;
unsigned intload_val;
+ struct notifier_block restart;
};
static bool nowayout = WATCHDOG_NOWAYOUT;
@@ -200,6 +202,18 @@ static const struct watchdog_ops wdt_ops = {
.get_timeleft = wdt_timeleft,
};
+static int
+wdt_restart(struct notifier_block *this, unsigned long mode, void *cmd)
+{
+ struct sp805_wdt *wdt = container_of(this, struct sp805_wdt, restart);
+
+ writel_relaxed(0, wdt->base + WDTCONTROL);
+ writel_relaxed(0, wdt->base + WDTLOAD);
+ writel_relaxed(INT_ENABLE | RESET_ENABLE, wdt->base + WDTCONTROL);
+
+ return 0;
+}
+
static int
sp805_wdt_probe(struct amba_device *adev, const struct amba_id *id)
{
@@ -241,6 +255,10 @@ sp805_wdt_probe(struct amba_device *adev, const struct
amba_id *id)
}
amba_set_drvdata(adev, wdt);
+ wdt->restart.notifier_call = wdt_restart;
+ wdt->restart.priority = 128;
+ register_restart_handler(&wdt->restart);
+
dev_info(&adev->dev, "registration successful\n");
return 0;
@@ -253,6 +271,7 @@ static int sp805_wdt_remove(struct amba_device *adev)
{
struct sp805_wdt *wdt = amba_get_drvdata(adev);
+ unregister_restart_handler(&wdt->restart);
watchdog_unregister_device(&wdt->wdd);
watchdog_set_drvdata(&wdt->wdd, NULL);
--
2.14.1
Re: [PATCH RFC 2/8] mm: introduce PG_offline
On 29.04.2018 23:08, Michal Hocko wrote: > On Sun 22-04-18 17:13:52, David Hildenbrand wrote: >> On 22.04.2018 16:02, Matthew Wilcox wrote: >>> On Sun, Apr 22, 2018 at 10:17:31AM +0200, David Hildenbrand wrote: On 22.04.2018 05:01, Matthew Wilcox wrote: > On Sat, Apr 21, 2018 at 06:52:18PM +0200, Vlastimil Babka wrote: >> Sounds like your newly introduced "page types" could be useful here? I >> don't suppose those offline pages would be using mapcount which is >> aliased there? > > Oh, that's a good point! Yes, this is a perfect use for page_type. > We have something like twenty bits available there. > > Now you've got me thinking that we can move PG_hwpoison and PG_reserved > to be page_type flags too. That'll take us from 23 to 21 bits (on 32-bit, > with PG_UNCACHED) Some things to clarify here. I modified the current RFC to also allow PG_offline on allocated (ballooned) pages (e.g. virtio-balloon). kdump based dump tools can then easily identify which pages are not to be dumped (either because the content is invalid or not accessible). I previously stated that ballooned pages would be marked as PG_reserved, which is not true (at least not for virtio-balloon). However this allows me to detect if all pages in a section are offline by looking at (PG_reserved && PG_offline). So I can actually tell if a page is marked as offline and allocated or really offline. 1. The location (not the number!) of PG_hwpoison is basically ABI and cannot be changed. Moving it around will most probably break dump tools. (see kernel/crash_core.c) >>> >>> It's not ABI. It already changed after 4.9 when PG_waiters was introduced >>> by commit 62906027091f. >> >> It is, please have a look at the file I pointed you to. >> >> We export the *value* of PG_hwpoison in the ELF file, therefore the >> *value* can change, but the *location* (page_flags, mapcount, whatever) >> must not change. Or am I missing something here? I don't think we can >> move PG_hwpoison that easily. >> >> Also, I can read "For pages that are never mapped to userspace, >> page->mapcount may be used for storing extra information about page >> type" - is that true for PG_hwpoison/PG_reserved? I am skeptical. >> >> And we need something similar for PG_offline, because it will become >> ABI. (I can see that PAGE_BUDDY_MAPCOUNT_VALUE is also exported in an >> ELF file, so maybe a new page type might work for marking a page offline >> - but I have to look at the details first tomorrow) > > Wait wait wait. Who is relying on this? Kdump? Page flags have always > been an internal implementation detail and _nobody_ outside of the > kernel should ever rely on the specific value. Well, kdump has been > cheating but that is because kdump is inherently tight to a specific > kernel implementation but that doesn't make it a stable ABI IMHO. > Restricting the kernel internals because of a debugging tool would be > quite insane. > kdump tools (makedumptool) don't rely on any specific value or assume anything. Using the example of musing PG_hwpoison to mapcount: If it sees PG_hwpoison: - it knows the right bit number to use - it knows the kernel uses it If it doesn't see PG_hwpoison (in the ELF info) anymore: - it cannot exclude poisoned pages anymore, potentially crashing the system during a dump If you have a better fitting name for "requires a interlocked update with tools to keep it working" than ABI, please let me know :) Anyhow, I have a new prototype based on PAGE_OFFLINE_MAPCOUNT_VALUE that I will share briefly. -- Thanks, David / dhildenb
[PATCH v4 3/6] iommu: support iommu configuration for fsl-mc devices
Signed-off-by: Nipun Gupta
---
drivers/iommu/of_iommu.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 811e160..284474d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define NO_IOMMU 1
@@ -159,6 +160,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16
alias, void *data)
return err;
}
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+ struct device_node *master_np)
+{
+ struct of_phandle_args iommu_spec = { .args_count = 1 };
+ int err;
+
+ err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+"iommu-map-mask", &iommu_spec.np,
+iommu_spec.args);
+ if (err)
+ return err == -ENODEV ? NO_IOMMU : err;
+
+ err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+ of_node_put(iommu_spec.np);
+ return err;
+}
+
const struct iommu_ops *of_iommu_configure(struct device *dev,
struct device_node *master_np)
{
@@ -190,6 +208,8 @@ const struct iommu_ops *of_iommu_configure(struct device
*dev,
err = pci_for_each_dma_alias(to_pci_dev(dev),
of_pci_iommu_init, &info);
+ } else if (dev_is_fsl_mc(dev)) {
+ err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
--
1.9.1
[PATCH v4 4/6] iommu: arm-smmu: Add support for the fsl-mc bus
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
Signed-off-by: Nipun Gupta
---
drivers/iommu/arm-smmu.c | 7 +++
drivers/iommu/iommu.c| 21 +
include/linux/fsl/mc.h | 8
include/linux/iommu.h| 2 ++
4 files changed, 38 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
#include
#include
+#include
#include "io-pgtable.h"
#include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct
device *dev)
if (dev_is_pci(dev))
group = pci_device_group(dev);
+ else if (dev_is_fsl_mc(dev))
+ group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
}
#endif
+#ifdef CONFIG_FSL_MC_BUS
+ if (!iommu_present(&fsl_mc_bus_type))
+ bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops);
+#endif
}
static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d2aa2320..6d4ce35 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
}
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+ struct device *cont_dev = fsl_mc_cont_dev(dev);
+ struct iommu_group *group;
+
+ /* Container device is responsible for creating the iommu group */
+ if (fsl_mc_is_cont_dev(dev)) {
+ group = iommu_group_alloc();
+ if (IS_ERR(group))
+ return NULL;
+ } else {
+ get_device(cont_dev);
+ group = iommu_group_get(cont_dev);
+ put_device(cont_dev);
+ }
+
+ return group;
+}
+
/**
* iommu_group_get_for_dev - Find or create the IOMMU group for a device
* @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
#define dev_is_fsl_mc(_dev) (0)
#endif
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+ FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+ (_dev) : (_dev)->parent)
+
/*
* module_fsl_mc_driver() - Helper macro for drivers that don't do
* anything special in module init/exit. This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 19938ee..2981200 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain
*domain,
extern struct iommu_group *pci_device_group(struct device *dev);
/* Generic device grouping function */
extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
/**
* struct iommu_fwspec - per-device IOMMU instance data
--
1.9.1
[PATCH v4 5/6] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
Signed-off-by: Nipun Gupta
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..624828b 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct
kobj_uevent_env *env)
return 0;
}
+static int fsl_mc_dma_configure(struct device *dev)
+{
+ struct device *dma_dev = dev;
+
+ while (dev_is_fsl_mc(dma_dev))
+ dma_dev = dma_dev->parent;
+
+ return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
.name = "fsl-mc",
.match = fsl_mc_bus_match,
.uevent = fsl_mc_bus_uevent,
+ .dma_configure = fsl_mc_dma_configure,
.dev_groups = fsl_mc_dev_groups,
};
EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = &mc_dev->dma_mask;
+ mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
dev_set_msi_domain(&mc_dev->dev,
dev_get_msi_domain(&parent_mc_dev->dev));
}
@@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
- /* Objects are coherent, unless 'no shareability' flag set. */
- if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
- arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
-
/*
* The device-specific probe callback will get invoked by device_add()
*/
--
1.9.1
[PATCH v4 6/6] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc
fsl-mc bus support the new iommu-map property. Comply to this binding
for fsl_mc bus.
Signed-off-by: Nipun Gupta
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 137ef4d..6010505 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -184,6 +184,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
clockgen: clocking@130 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x0008 0x0c00 0 0x40>,/* MC portal
base */
<0x 0x0834 0 0x4>; /* MC control
reg */
msi-parent = <&its>;
+ iommu-map = <0 &smmu 0 0>; /* This is fixed-up by
u-boot */
+ dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
@@ -460,6 +463,8 @@
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
#global-interrupts = <12>;
+ #iommu-cells = <1>;
+ stream-match-mask = <0x7C00>;
interrupts = <0 13 4>, /* global secure fault */
<0 14 4>, /* combined secure interrupt */
<0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
<0 204 4>, <0 205 4>,
<0 206 4>, <0 207 4>,
<0 208 4>, <0 209 4>;
- mmu-masters = <&fsl_mc 0x300 0>;
};
dspi: dspi@210 {
--
1.9.1
[PATCH v4 1/6] Docs: dt: add fsl-mc iommu-map device-tree binding
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.
Signed-off-by: Nipun Gupta
Reviewed-by: Rob Herring
---
.../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 ++
1 file changed, 39 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..8cbed4f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware
objects/devices
such as network interfaces, crypto accelerator instances, L2 switches,
etc.
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
Required properties:
- compatible
@@ -88,14 +107,34 @@ Sub-nodes:
Value type:
Definition: Specifies the phandle to the PHY device node
associated
with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+ data.
+
+ The property is an arbitrary number of tuples of
+ (icid-base,iommu,iommu-base,length).
+
+ Any ICID i in the interval [icid-base, icid-base + length) is
+ associated with the listed IOMMU, with the iommu-specifier
+ (i - icid-base + iommu-base).
Example:
+smmu: iommu@500 {
+ compatible = "arm,mmu-500";
+ #iommu-cells = <2>;
+ stream-match-mask = <0x7C00>;
+ ...
+};
+
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 = <&its>;
+/* define map for ICIDs 23-64 */
+iommu-map = <23 &smmu 23 41>;
#address-cells = <3>;
#size-cells = <1>;
--
1.9.1
[PATCH v4 0/6] Support for fsl-mc bus and its devices in SMMU
This patchset defines IOMMU DT binding for fsl-mc bus and adds support in SMMU for fsl-mc bus. This patch series is dependent on patset: https://patchwork.kernel.org/patch/10317337/ These patches - Define property 'iommu-map' for fsl-mc bus (patch 1) - Integrates the fsl-mc bus with the SMMU using this IOMMU binding (patch 2,3,4) - Adds the dma configuration support for fsl-mc bus (patch 5) - Updates the fsl-mc device node with iommu/dma related changes (patch6) Changes in v2: - use iommu-map property for fsl-mc bus - rebase over patchset https://patchwork.kernel.org/patch/10317337/ and make corresponding changes for dma configuration of devices on fsl-mc bus Changes in v3: - move of_map_rid in drivers/of/address.c Changes in v4: - move of_map_rid in drivers/of/base.c Nipun Gupta (6): Docs: dt: add fsl-mc iommu-map device-tree binding iommu: of: make of_pci_map_rid() available for other devices too iommu: support iommu configuration for fsl-mc devices iommu: arm-smmu: Add support for the fsl-mc bus bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 39 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +- drivers/bus/fsl-mc/fsl-mc-bus.c| 16 +++- drivers/iommu/arm-smmu.c | 7 ++ drivers/iommu/iommu.c | 21 + drivers/iommu/of_iommu.c | 25 - drivers/of/base.c | 102 + drivers/of/irq.c | 5 +- drivers/pci/of.c | 101 include/linux/fsl/mc.h | 8 ++ include/linux/iommu.h | 2 + include/linux/of.h | 11 +++ include/linux/of_pci.h | 10 -- 13 files changed, 231 insertions(+), 122 deletions(-) -- 1.9.1
[PATCH v4 2/6] iommu: of: make of_pci_map_rid() available for other devices too
iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.
'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
functional change done in the API.
Signed-off-by: Nipun Gupta
---
drivers/iommu/of_iommu.c | 5 +--
drivers/of/base.c| 102 +++
drivers/of/irq.c | 5 +--
drivers/pci/of.c | 101 --
include/linux/of.h | 11 +
include/linux/of_pci.h | 10 -
6 files changed, 117 insertions(+), 117 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..811e160 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -149,9 +149,8 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16
alias, void *data)
struct of_phandle_args iommu_spec = { .args_count = 1 };
int err;
- err = of_pci_map_rid(info->np, alias, "iommu-map",
-"iommu-map-mask", &iommu_spec.np,
-iommu_spec.args);
+ err = of_map_rid(info->np, alias, "iommu-map", "iommu-map-mask",
+&iommu_spec.np, iommu_spec.args);
if (err)
return err == -ENODEV ? NO_IOMMU : err;
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 848f549..c7aac81 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1995,3 +1995,105 @@ int of_find_last_cache_level(unsigned int cpu)
return cache_level;
}
+
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+ const char *map_name, const char *map_mask_name,
+ struct device_node **target, u32 *id_out)
+{
+ u32 map_mask, masked_rid;
+ int map_len;
+ const __be32 *map = NULL;
+
+ if (!np || !map_name || (!target && !id_out))
+ return -EINVAL;
+
+ map = of_get_property(np, map_name, &map_len);
+ if (!map) {
+ if (target)
+ return -ENODEV;
+ /* Otherwise, no map implies no translation */
+ *id_out = rid;
+ return 0;
+ }
+
+ if (!map_len || map_len % (4 * sizeof(*map))) {
+ pr_err("%pOF: Error: Bad %s length: %d\n", np,
+ map_name, map_len);
+ return -EINVAL;
+ }
+
+ /* The default is to select all bits. */
+ map_mask = 0x;
+
+ /*
+* Can be overridden by "{iommu,msi}-map-mask" property.
+* If of_property_read_u32() fails, the default is used.
+*/
+ if (map_mask_name)
+ of_property_read_u32(np, map_mask_name, &map_mask);
+
+ masked_rid = map_mask & rid;
+ for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+ struct device_node *phandle_node;
+ u32 rid_base = be32_to_cpup(map + 0);
+ u32 phandle = be32_to_cpup(map + 1);
+ u32 out_base = be32_to_cpup(map + 2);
+ u32 rid_len = be32_to_cpup(map + 3);
+
+ if (rid_base & ~map_mask) {
+ pr_err("%pOF: Invalid %s translation - %s-mask (0x%x)
ignores rid-base (0x%x)\n",
+ np, map_name, map_name,
+ map_mask, rid_base);
+ return -EFAULT;
+ }
+
+ if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+ continue;
+
+ phandle_node = of_find_node_by_phandle(phandle);
+ if (!phandle_node)
+ return -ENODEV;
+
+ if (target) {
+ if (*target)
+ of_node_put(phandle_node);
+ else
+ *target = phandle_node;
+
+ if (*target != phandle_node)
+ continue
Re: [PATCH] random: remove unused argument from add_interrupt_randomness()
Hi Sultan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc3 next-20180426]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sultan-Alsawaf/random-remove-unused-argument-from-add_interrupt_randomness/20180430-111445
config: i386-randconfig-x013-201817 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/hv/hv.c: In function 'hv_stimer0_isr':
>> drivers/hv/hv.c:118:2: error: too many arguments to function
>> 'add_interrupt_randomness'
add_interrupt_randomness(stimer0_vector, 0);
^~~~
In file included from drivers/hv/hv.c:30:0:
include/linux/random.h:35:13: note: declared here
extern void add_interrupt_randomness(int irq) __latent_entropy;
^~~~
vim +/add_interrupt_randomness +118 drivers/hv/hv.c
3e7ee490 drivers/staging/hv/Hv.c Hank Janssen 2009-07-13 105
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 106 /*
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 107 * ISR for
when stimer0 is operating in Direct Mode. Direct Mode
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 108 * does not
use VMbus or any VMbus messages, so process here and not
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 109 * in the
VMbus driver code.
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 110 */
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 111
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 112 static void
hv_stimer0_isr(void)
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 113 {
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 114 struct
hv_per_cpu_context *hv_cpu;
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 115
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 116 hv_cpu
= this_cpu_ptr(hv_context.cpu_context);
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 117
hv_cpu->clk_evt->event_handler(hv_cpu->clk_evt);
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 @118
add_interrupt_randomness(stimer0_vector, 0);
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 119 }
248e742a drivers/hv/hv.c Michael Kelley 2018-03-04 120
:: The code at line 118 was first introduced by commit
:: 248e742a396e7f00b283f1c56e14b1bef6e3ec56 Drivers: hv: vmbus: Implement
Direct Mode for stimer0
:: TO: Michael Kelley
:: CC: Greg Kroah-Hartman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v2] i2c: at91: Read all available bytes at once
Am 28.04.2018 um 14:38 schrieb Wolfram Sang: On Thu, Apr 26, 2018 at 11:53:14AM +0200, David Engraf wrote: With FIFO enabled it is possible to read multiple bytes at once in the interrupt handler as long as RXRDY is set. This may also reduce the number of interrupts. This patch polls RXRDY and reads all available bytes at once. Signed-off-by: David Engraf checkpatch said twice: WARNING: line over 80 characters While I am not super-strict with this limit, it makes sense here IMO. The comment stays readable, and we don't even lose a line. Sorry for that. Fixed it this time for you. Thanks - David Applied to for-next, thanks!
Re: [PATCH V4] clk: at91: PLL recalc_rate() now using cached MUL and DIV values
On Sun, 29 Apr 2018 15:01:11 -0400
Marcin Ziemianowicz wrote:
> When a USB device is connected to the USB host port on the SAM9N12 then
> you get "-62" error which seems to indicate USB replies from the device
> are timing out. Based on a logic sniffer, I saw the USB bus was running
> at half speed.
>
> The PLL code uses cached MUL and DIV values which get set in set_rate()
> and applied in prepare(), but the recalc_rate() function instead
> queries the hardware instead of using these cached values. Therefore,
> if recalc_rate() is called between a set_rate() and prepare(), the
> wrong frequency is calculated and later the USB clock divider for the
> SAM9N12 SOC will be configured for an incorrect clock.
>
> In my case, the PLL hardware was set to 96 Mhz before the OHCI
> driver loads, and therefore the usb clock divider was being set
> to /2 even though the OHCI driver set the PLL to 48 Mhz.
>
> As an alternative explanation, I noticed this was fixed in the past by
> 87e2ed338f1b ("clk: at91: fix recalc_rate implementation of PLL
> driver") but the bug was later re-introduced by 1bdf02326b71 ("clk:
> at91: make use of syscon/regmap internally").
>
> Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally)
> Cc:
> Signed-off-by: Marcin Ziemianowicz
Acked-by: Boris Brezillon
> ---
> Thank you for bearing with me about this Boris.
>
> Changes since V3:
> Fix for double returns found by kbluild test robot
> > Comments by Boris Brezillon about email formatting issues
> Changes since V2:
> Removed all logging/debug messages I added
> > Comment by Boris Brezillon about my fix being wrong addressed
> Changes since V1:
> Added patch set cover letter
> Shortened lines which were over >80 characters long
> > Comment by Greg Kroah-Hartman about "from" field in email addressed
> > Comment by Alan Stern about redundant debug lines addressed
>
> drivers/clk/at91/clk-pll.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
> index 7d3223fc..72b6091e 100644
> --- a/drivers/clk/at91/clk-pll.c
> +++ b/drivers/clk/at91/clk-pll.c
> @@ -132,19 +132,8 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw
> *hw,
>unsigned long parent_rate)
> {
> struct clk_pll *pll = to_clk_pll(hw);
> - unsigned int pllr;
> - u16 mul;
> - u8 div;
> -
> - regmap_read(pll->regmap, PLL_REG(pll->id), &pllr);
> -
> - div = PLL_DIV(pllr);
> - mul = PLL_MUL(pllr, pll->layout);
> -
> - if (!div || !mul)
> - return 0;
>
> - return (parent_rate / div) * (mul + 1);
> + return (parent_rate / pll->div) * (pll->mul + 1);
> }
>
> static long clk_pll_get_best_div_mul(struct clk_pll *pll, unsigned long rate,
[PATCH] i2c: core-smbus: fix a potential uninitialization bug
In i2c_smbus_xfer_emulated(), there are two buffers: msgbuf0 and msgbuf1,
which are used to save a series of messages, as mentioned in the comment.
According to the value of the variable "size", msgbuf0 is initialized to
various values. In contrast, msgbuf1 is left uninitialized until the
function i2c_transfer() is invoked. However, mgsbuf1 is not always
initialized on all possible execution paths (implementation) of
i2c_transfer(). Thus, it is possible that mgsbuf1 may still not be
uninitialized even after the invocation of the function i2c_transfer(). In
the following execution, the uninitialized msgbuf1 will be used, such as
for security checks. Since uninitialized values can be random and
arbitrary, this will cause undefined behaviors or even check bypass. For
example, it is expected that if the value of "size" is
I2C_SMBUS_BLOCK_PROC_CALL, the value of data->block[0] should not be larger
than I2C_SMBUS_BLOCK_MAX. But, at the end of i2c_smbus_xfer_emulated(), the
value read from msgbuf1 is assigned to data->block[0], which can
potentially lead to invalid block write size, as demonstrated in the error
message.
This patch simply initializes the buffer msgbuf1 with 0 to avoid undefined
behaviors or security issues.
Signed-off-by: Wenwen Wang
---
drivers/i2c/i2c-core-smbus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
index b5aec33..0fcca75 100644
--- a/drivers/i2c/i2c-core-smbus.c
+++ b/drivers/i2c/i2c-core-smbus.c
@@ -324,7 +324,7 @@ static s32 i2c_smbus_xfer_emulated(struct i2c_adapter
*adapter, u16 addr,
* somewhat simpler.
*/
unsigned char msgbuf0[I2C_SMBUS_BLOCK_MAX+3];
- unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2];
+ unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2] = {0};
int num = read_write == I2C_SMBUS_READ ? 2 : 1;
int i;
u8 partial_pec = 0;
--
2.7.4
[PATCH v2 01/10] PCI: Make pci_get_new_domain_nr() static
From: Jan Kiszka
The only user of pci_get_new_domain_nr() is of_pci_bus_find_domain_nr().
Since they are defined in the same compilation unit,
pci_get_new_domain_nr() can be made static, which also simplifies
preprocessor conditionals.
No functional change intended.
Signed-off-by: Jan Kiszka
Acked-by: Lorenzo Pieralisi
---
drivers/pci/pci.c | 6 ++
include/linux/pci.h | 3 ---
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a04197ce767d..811d71e7ee05 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5702,15 +5702,14 @@ static void pci_no_domains(void)
#endif
}
-#ifdef CONFIG_PCI_DOMAINS
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
static atomic_t __domain_nr = ATOMIC_INIT(-1);
-int pci_get_new_domain_nr(void)
+static int pci_get_new_domain_nr(void)
{
return atomic_inc_return(&__domain_nr);
}
-#ifdef CONFIG_PCI_DOMAINS_GENERIC
static int of_pci_bus_find_domain_nr(struct device *parent)
{
static int use_dt_domains = -1;
@@ -5765,7 +5764,6 @@ int pci_bus_find_domain_nr(struct pci_bus *bus, struct
device *parent)
acpi_pci_bus_find_domain_nr(bus);
}
#endif
-#endif
/**
* pci_ext_cfg_avail - can we access extended PCI config space?
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 73178a2fcee0..963232a6cd2e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1510,12 +1510,10 @@ void pci_cfg_access_unlock(struct pci_dev *dev);
*/
#ifdef CONFIG_PCI_DOMAINS
extern int pci_domains_supported;
-int pci_get_new_domain_nr(void);
#else
enum { pci_domains_supported = 0 };
static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
static inline int pci_proc_domain(struct pci_bus *bus) { return 0; }
-static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
#endif /* CONFIG_PCI_DOMAINS */
/*
@@ -1670,7 +1668,6 @@ static inline struct pci_dev
*pci_get_domain_bus_and_slot(int domain,
static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return NULL; }
-static inline int pci_get_new_domain_nr(void) { return -ENOSYS; }
#define dev_is_pci(d) (false)
#define dev_is_pf(d) (false)
--
2.13.6
[PATCH v2 00/10] PCI: leak fixes, removable generic PCI host, assorted stuff
Changes in v2: - patch 1: commit message reworking as suggested by Lorenzo - patch 3-6: split-up as suggested by Bjorn - patch 8: new - patch 10: select PCI_DOMAINS from PCI_HOST_GENERIC, rather than allowing manual choice, as suggested by Lorenzo This primarily enables to unbind the generic PCI host controller without leaving lots of memory leaks behind. A previous proposal patch 5 was rejected because of those issues [1]. The fixes have been validated in the Jailhouse setup, where we add and remove a virtual PCI host controller on hypervisor activation/ deactivation, with the help of kmemleak. Besides that, there is tiny PCI API cleanup at the beginning and support for manually enabled PCI domains at the end that enables the Jailhouse scenario. Jan [1] http://lkml.iu.edu/hypermail/linux/kernel/1606.3/00072.html CC: Jingoo Han CC: Joao Pinto CC: Lorenzo Pieralisi CC: Will Deacon Jan Kiszka (10): PCI: Make pci_get_new_domain_nr() static PCI: Fix memory leak of devm_pci_alloc_host_bridge() PCI: Factor out __of_pci_get_host_bridge_resources() PCI: Add dev parameter to __of_pci_get_host_bridge_resources() PCI: Replace pr_*() with dev_*() in __of_pci_get_host_bridge_resources() PCI: Introduce devm_of_pci_get_host_bridge_resources() PCI: Convert of_pci_get_host_bridge_resources() users to devm variant PCI: Deprecate of_pci_get_host_bridge_resources() PCI: Add support for unbinding the generic PCI host controller PCI: Enable PCI_DOMAINS along with generic PCI host controller drivers/pci/dwc/pcie-designware-host.c | 2 +- drivers/pci/host/Kconfig | 1 + drivers/pci/host/pci-aardvark.c| 5 +- drivers/pci/host/pci-ftpci100.c| 4 +- drivers/pci/host/pci-host-common.c | 13 drivers/pci/host/pci-host-generic.c| 1 + drivers/pci/host/pci-v3-semi.c | 3 +- drivers/pci/host/pci-versatile.c | 3 +- drivers/pci/host/pci-xgene.c | 3 +- drivers/pci/host/pcie-altera.c | 5 +- drivers/pci/host/pcie-iproc-platform.c | 4 +- drivers/pci/host/pcie-rcar.c | 5 +- drivers/pci/host/pcie-rockchip.c | 4 +- drivers/pci/host/pcie-xilinx-nwl.c | 4 +- drivers/pci/host/pcie-xilinx.c | 4 +- drivers/pci/of.c | 105 + drivers/pci/pci.c | 6 +- drivers/pci/probe.c| 4 +- include/linux/of_pci.h | 42 - include/linux/pci-ecam.h | 1 + include/linux/pci.h| 3 - 21 files changed, 149 insertions(+), 73 deletions(-) -- 2.13.6
[PATCH v2 10/10] PCI: Enable PCI_DOMAINS along with generic PCI host controller
From: Jan Kiszka This controller is often instantiated by hypervisors, and they may add multiple of them or add them in addition to a physical host controller like the Jailhouse hypervisor is doing. Therefore allow for multiple domains so that we can handle them all. Signed-off-by: Jan Kiszka --- drivers/pci/host/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index 0d0177ce436c..3d25b35bb5ab 100644 --- a/drivers/pci/host/Kconfig +++ b/drivers/pci/host/Kconfig @@ -68,6 +68,7 @@ config PCI_HOST_GENERIC depends on (ARM || ARM64) && OF select PCI_HOST_COMMON select IRQ_DOMAIN + select PCI_DOMAINS help Say Y here if you want to support a simple generic PCI host controller, such as the one emulated by kvmtool. -- 2.13.6
[PATCH v2 05/10] PCI: Replace pr_*() with dev_*() in __of_pci_get_host_bridge_resources()
From: Jan Kiszka
Now that we have a device reference, make use of it for printing. And as
long as dev can still be NULL, we will still get some reasonable output
nevertheless.
Signed-off-by: Jan Kiszka
---
drivers/pci/of.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index bfa282b538d5..8f6cbf13e18d 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -266,15 +266,15 @@ static int __of_pci_get_host_bridge_resources(struct
device *dev,
if (!bus_range)
return -ENOMEM;
- pr_info("host bridge %pOF ranges:\n", dev_node);
+ dev_info(dev, "host bridge %pOF ranges:\n", dev_node);
err = of_pci_parse_bus_range(dev_node, bus_range);
if (err) {
bus_range->start = busno;
bus_range->end = bus_max;
bus_range->flags = IORESOURCE_BUS;
- pr_info(" No bus range found for %pOF, using %pR\n",
- dev_node, bus_range);
+ dev_info(dev, " No bus range found for %pOF, using %pR\n",
+dev_node, bus_range);
} else {
if (bus_range->end > bus_range->start + bus_max)
bus_range->end = bus_range->start + bus_max;
@@ -286,7 +286,7 @@ static int __of_pci_get_host_bridge_resources(struct device
*dev,
if (err)
goto parse_failed;
- pr_debug("Parsing ranges property...\n");
+ dev_dbg(dev, "Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
/* Read next ranges element */
if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
@@ -295,9 +295,9 @@ static int __of_pci_get_host_bridge_resources(struct device
*dev,
snprintf(range_type, 4, "MEM");
else
snprintf(range_type, 4, "err");
- pr_info(" %s %#010llx..%#010llx -> %#010llx\n", range_type,
- range.cpu_addr, range.cpu_addr + range.size - 1,
- range.pci_addr);
+ dev_info(dev, " %s %#010llx..%#010llx -> %#010llx\n",
+range_type, range.cpu_addr,
+range.cpu_addr + range.size - 1, range.pci_addr);
/*
* If we failed translation or got a zero-sized region
@@ -324,14 +324,16 @@ static int __of_pci_get_host_bridge_resources(struct
device *dev,
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
- pr_err("I/O range found for %pOF. Please
provide an io_base pointer to save CPU base address\n",
+ dev_err(dev,
+ "I/O range found for %pOF. Please
provide an io_base pointer to save CPU base address\n",
dev_node);
err = -EINVAL;
goto conversion_failed;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
- pr_warn("More than one I/O resource converted
for %pOF. CPU base address for old range lost!\n",
- dev_node);
+ dev_warn(dev,
+"More than one I/O resource converted
for %pOF. CPU base address for old range lost!\n",
+dev_node);
*io_base = range.cpu_addr;
}
--
2.13.6
[PATCH v2 08/10] PCI: Deprecate of_pci_get_host_bridge_resources()
From: Jan Kiszka
There are no in-tree users remaining, all are converted to the managed
variant. And it is unlikely that any out-of-tree user got the resource
management right as well. So deprecate the interface and push users to
the managed version instead.
To avoid raising a warning when exporting a deprecated symbol, wrap the
API with an inline and export an internal name.
Signed-off-by: Jan Kiszka
---
drivers/pci/of.c | 23 ++-
include/linux/of_pci.h | 36
2 files changed, 34 insertions(+), 25 deletions(-)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 5a88d46a41b7..ccf8c7544e10 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -351,33 +351,14 @@ static int __of_pci_get_host_bridge_resources(struct
device *dev,
return err;
}
-/**
- * of_pci_get_host_bridge_resources() - Parse PCI host bridge resources from DT
- * @dev_node: device node of the host bridge having the range property
- * @busno: bus number associated with the bridge root bus
- * @bus_max: maximum number of buses for this bridge
- * @resources: list where the range of resources will be added after DT parsing
- * @io_base: pointer to a variable that will contain on return the physical
- * address for the start of the I/O range. Can be NULL if the caller doesn't
- * expect I/O ranges to be present in the device tree.
- *
- * It is the caller's job to free the @resources list.
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping based on its content. It is expected
- * that the property conforms with the Power ePAPR document.
- *
- * It returns zero if the range parsing has been successful or a standard error
- * value if it failed.
- */
-int of_pci_get_host_bridge_resources(struct device_node *dev_node,
+int __of_pci_get_host_bridge_resources_deprecated(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
{
return __of_pci_get_host_bridge_resources(NULL, dev_node, busno,
bus_max, resources, io_base);
}
-EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+EXPORT_SYMBOL_GPL(__of_pci_get_host_bridge_resources_deprecated);
/**
* of_pci_get_host_bridge_resources() - Resource-managed parsing of PCI host
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 08b8f02426a5..c6408bd6f862 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -71,26 +71,54 @@ of_irq_parse_and_map_pci(const struct pci_dev *dev, u8
slot, u8 pin)
#endif
#if defined(CONFIG_OF_ADDRESS)
-int of_pci_get_host_bridge_resources(struct device_node *dev_node,
+int __of_pci_get_host_bridge_resources_deprecated(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
#else
-static inline int of_pci_get_host_bridge_resources(struct device_node
*dev_node,
+static inline int devm_of_pci_get_host_bridge_resources(struct device *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
{
return -EINVAL;
}
+#endif
-static inline int devm_of_pci_get_host_bridge_resources(struct device *dev,
+/**
+ * of_pci_get_host_bridge_resources() - Parse PCI host bridge resources from DT
+ * @dev_node: device node of the host bridge having the range property
+ * @busno: bus number associated with the bridge root bus
+ * @bus_max: maximum number of buses for this bridge
+ * @resources: list where the range of resources will be added after DT parsing
+ * @io_base: pointer to a variable that will contain on return the physical
+ * address for the start of the I/O range. Can be NULL if the caller doesn't
+ * expect I/O ranges to be present in the device tree.
+ *
+ * It is the caller's job to free the @resources list.
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping based on its content. It is expected
+ * that the property conforms with the Power ePAPR document.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ *
+ * Note: This function is deprecated and will eventually be removed. Use
+ * devm_of_pci_get_host_bridge_resources() instead.
+ */
+static inline int __deprecated of_pci_get_host_bridge_resources(
+ struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_
[PATCH v2 04/10] PCI: Add dev parameter to __of_pci_get_host_bridge_resources()
From: Jan Kiszka
When non-NULL, use the new dev parameter of
__of_pci_get_host_bridge_resources() to allocate the resource data
structures via devm_kzalloc. That allows to release them automatically
during device destruction.
Signed-off-by: Jan Kiszka
---
drivers/pci/of.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 375de447a58e..bfa282b538d5 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -243,7 +243,7 @@ void of_pci_check_probe_only(void)
EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
#if defined(CONFIG_OF_ADDRESS)
-static int __of_pci_get_host_bridge_resources(
+static int __of_pci_get_host_bridge_resources(struct device *dev,
struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
@@ -259,7 +259,10 @@ static int __of_pci_get_host_bridge_resources(
if (io_base)
*io_base = (resource_size_t)OF_BAD_ADDR;
- bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
+ if (dev)
+ bus_range = devm_kzalloc(dev,sizeof(*bus_range), GFP_KERNEL);
+ else
+ bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
if (!bus_range)
return -ENOMEM;
@@ -303,7 +306,11 @@ static int __of_pci_get_host_bridge_resources(
if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
continue;
- res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+ if (dev)
+ res = devm_kzalloc(dev, sizeof(struct resource),
+ GFP_KERNEL);
+ else
+ res = kzalloc(sizeof(struct resource), GFP_KERNEL);
if (!res) {
err = -ENOMEM;
goto parse_failed;
@@ -365,7 +372,7 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
{
- return __of_pci_get_host_bridge_resources(dev_node, busno,
+ return __of_pci_get_host_bridge_resources(NULL, dev_node, busno,
bus_max, resources, io_base);
}
EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
--
2.13.6
[PATCH v2 06/10] PCI: Introduce devm_of_pci_get_host_bridge_resources()
From: Jan Kiszka
of_pci_get_host_bridge_resources() allocates the resource structures it
fills dynamically, but none of its callers care to release them so far.
Rather than requiring everyone to do this explicitly, introduce a
managed version of that service. This differs API-wise only in taking a
reference to the associated device, rather than to the device tree node.
As of_pci_get_host_bridge_resources() is an exported interface, we
cannot simply drop it at this point. After converting all in-tree users
to the new API, we will phase out the unmanaged one.
Signed-off-by: Jan Kiszka
---
drivers/pci/of.c | 28
include/linux/of_pci.h | 10 ++
2 files changed, 38 insertions(+)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 8f6cbf13e18d..f16b343d3b85 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -378,6 +378,34 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev_node,
bus_max, resources, io_base);
}
EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
+/**
+ * of_pci_get_host_bridge_resources() - Resource-managed parsing of PCI host
+ * bridge resources from DT
+ * @dev: host bridge device
+ * @busno: bus number associated with the bridge root bus
+ * @bus_max: maximum number of buses for this bridge
+ * @resources: list where the range of resources will be added after DT parsing
+ * @io_base: pointer to a variable that will contain on return the physical
+ * address for the start of the I/O range. Can be NULL if the caller doesn't
+ * expect I/O ranges to be present in the device tree.
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping based on its content. It is expected
+ * that the property conforms with the Power ePAPR document.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ */
+int devm_of_pci_get_host_bridge_resources(struct device *dev,
+ unsigned char busno, unsigned char bus_max,
+ struct list_head *resources, resource_size_t *io_base)
+{
+ return __of_pci_get_host_bridge_resources(dev, dev->of_node, busno,
+ bus_max, resources, io_base);
+}
+EXPORT_SYMBOL_GPL(devm_of_pci_get_host_bridge_resources);
+
#endif /* CONFIG_OF_ADDRESS */
/**
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 74eec1943ad2..08b8f02426a5 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -74,6 +74,9 @@ of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot,
u8 pin)
int of_pci_get_host_bridge_resources(struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
+int devm_of_pci_get_host_bridge_resources(struct device *dev,
+ unsigned char busno, unsigned char bus_max,
+ struct list_head *resources, resource_size_t *io_base);
#else
static inline int of_pci_get_host_bridge_resources(struct device_node
*dev_node,
unsigned char busno, unsigned char bus_max,
@@ -81,6 +84,13 @@ static inline int of_pci_get_host_bridge_resources(struct
device_node *dev_node,
{
return -EINVAL;
}
+
+static inline int devm_of_pci_get_host_bridge_resources(struct device *dev,
+ unsigned char busno, unsigned char bus_max,
+ struct list_head *resources, resource_size_t *io_base)
+{
+ return -EINVAL;
+}
#endif
#endif
--
2.13.6
[PATCH v2 03/10] PCI: Factor out __of_pci_get_host_bridge_resources()
From: Jan Kiszka
This will be needed for sharing the core logic between current
of_pci_get_host_bridge_resources() and upcoming
devm_of_pci_get_host_bridge_resources().
Already rename the dev parameter to dev_node in order to free the
namespace for a real device parameter.
No functional changes.
Signed-off-by: Jan Kiszka
---
drivers/pci/of.c | 63 --
include/linux/of_pci.h | 4 ++--
2 files changed, 38 insertions(+), 29 deletions(-)
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index a28355c273ae..375de447a58e 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -243,26 +243,8 @@ void of_pci_check_probe_only(void)
EXPORT_SYMBOL_GPL(of_pci_check_probe_only);
#if defined(CONFIG_OF_ADDRESS)
-/**
- * of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
- * @dev: device node of the host bridge having the range property
- * @busno: bus number associated with the bridge root bus
- * @bus_max: maximum number of buses for this bridge
- * @resources: list where the range of resources will be added after DT parsing
- * @io_base: pointer to a variable that will contain on return the physical
- * address for the start of the I/O range. Can be NULL if the caller doesn't
- * expect I/O ranges to be present in the device tree.
- *
- * It is the caller's job to free the @resources list.
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping based on its content. It is expected
- * that the property conforms with the Power ePAPR document.
- *
- * It returns zero if the range parsing has been successful or a standard error
- * value if it failed.
- */
-int of_pci_get_host_bridge_resources(struct device_node *dev,
+static int __of_pci_get_host_bridge_resources(
+ struct device_node *dev_node,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
{
@@ -281,15 +263,15 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
if (!bus_range)
return -ENOMEM;
- pr_info("host bridge %pOF ranges:\n", dev);
+ pr_info("host bridge %pOF ranges:\n", dev_node);
- err = of_pci_parse_bus_range(dev, bus_range);
+ err = of_pci_parse_bus_range(dev_node, bus_range);
if (err) {
bus_range->start = busno;
bus_range->end = bus_max;
bus_range->flags = IORESOURCE_BUS;
pr_info(" No bus range found for %pOF, using %pR\n",
- dev, bus_range);
+ dev_node, bus_range);
} else {
if (bus_range->end > bus_range->start + bus_max)
bus_range->end = bus_range->start + bus_max;
@@ -297,7 +279,7 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
pci_add_resource(resources, bus_range);
/* Check for ranges property */
- err = of_pci_range_parser_init(&parser, dev);
+ err = of_pci_range_parser_init(&parser, dev_node);
if (err)
goto parse_failed;
@@ -327,7 +309,7 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
goto parse_failed;
}
- err = of_pci_range_to_resource(&range, dev, res);
+ err = of_pci_range_to_resource(&range, dev_node, res);
if (err) {
kfree(res);
continue;
@@ -336,13 +318,13 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
if (resource_type(res) == IORESOURCE_IO) {
if (!io_base) {
pr_err("I/O range found for %pOF. Please
provide an io_base pointer to save CPU base address\n",
- dev);
+ dev_node);
err = -EINVAL;
goto conversion_failed;
}
if (*io_base != (resource_size_t)OF_BAD_ADDR)
pr_warn("More than one I/O resource converted
for %pOF. CPU base address for old range lost!\n",
- dev);
+ dev_node);
*io_base = range.cpu_addr;
}
@@ -359,6 +341,33 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
pci_free_resource_list(resources);
return err;
}
+
+/**
+ * of_pci_get_host_bridge_resources() - Parse PCI host bridge resources from DT
+ * @dev_node: device node of the host bridge having the range property
+ * @busno: bus number associated with the bridge root bus
+ * @bus_max: maximum number of buses for this bridge
+ * @resources: list where the range of resources will be added after DT parsing
+
[PATCH v2 09/10] PCI: Add support for unbinding the generic PCI host controller
From: Jan Kiszka
Particularly useful when working in virtual environments where the
controller may come and go, but possibly not only there.
CC: Will Deacon
CC: Lorenzo Pieralisi
Signed-off-by: Jan Kiszka
---
drivers/pci/host/pci-host-common.c | 13 +
drivers/pci/host/pci-host-generic.c | 1 +
include/linux/pci-ecam.h| 1 +
3 files changed, 15 insertions(+)
diff --git a/drivers/pci/host/pci-host-common.c
b/drivers/pci/host/pci-host-common.c
index 5d028f53fdcd..d8f10451f273 100644
--- a/drivers/pci/host/pci-host-common.c
+++ b/drivers/pci/host/pci-host-common.c
@@ -101,5 +101,18 @@ int pci_host_common_probe(struct platform_device *pdev,
return ret;
}
+ platform_set_drvdata(pdev, bridge->bus);
+ return 0;
+}
+
+int pci_host_common_remove(struct platform_device *pdev)
+{
+ struct pci_bus *bus = platform_get_drvdata(pdev);
+
+ pci_lock_rescan_remove();
+ pci_stop_root_bus(bus);
+ pci_remove_root_bus(bus);
+ pci_unlock_rescan_remove();
+
return 0;
}
diff --git a/drivers/pci/host/pci-host-generic.c
b/drivers/pci/host/pci-host-generic.c
index 45319ee3b484..dea3ec7592a2 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -95,5 +95,6 @@ static struct platform_driver gen_pci_driver = {
.suppress_bind_attrs = true,
},
.probe = gen_pci_probe,
+ .remove = pci_host_common_remove,
};
builtin_platform_driver(gen_pci_driver);
diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
index baadad1aabbc..29efa09d686b 100644
--- a/include/linux/pci-ecam.h
+++ b/include/linux/pci-ecam.h
@@ -62,5 +62,6 @@ extern struct pci_ecam_ops xgene_v2_pcie_ecam_ops; /* APM
X-Gene PCIe v2.x */
/* for DT-based PCI controllers that support ECAM */
int pci_host_common_probe(struct platform_device *pdev,
struct pci_ecam_ops *ops);
+int pci_host_common_remove(struct platform_device *pdev);
#endif
#endif
--
2.13.6
Re: [PATCH 3/4] rculist: add list_for_each_entry_from_rcu()
On Mon, Apr 30, 2018 at 02:31:30PM +1000, NeilBrown wrote: > list_for_each_entry_from_rcu() is an RCU version of > list_for_each_entry_from(). It walks a linked list under rcu > protection, from a given start point. > > It is similar to list_for_each_entry_continue_rcu() but starts *at* > the given position rather than *after* it. > > Naturally, the start point must be known to be in the list. I'd suggest giving an explicit advisory comment to clarify and suggest correct usage: "This would typically require either that you obtained the node from a previous walk of the list in the same RCU read-side critical section, or that you held some sort of non-RCU reference (such as a reference count) to keep the node alive *and* in the list." (Feel free to wordsmith the exact wording, but something like that seems like it would help people understand how to use this correctly, and make it less likely that they'd use it incorrectly.)
[PATCH v2 02/10] PCI: Fix memory leak of devm_pci_alloc_host_bridge()
From: Jan Kiszka
devm_pci_release_host_bridge_dev() failed to release the resource list.
Fixes: 5c3f18cce083 ("PCI: Add devm_pci_alloc_host_bridge() interface")
Signed-off-by: Jan Kiszka
---
drivers/pci/probe.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ac91b6fd0bcd..eccf204c9160 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -526,12 +526,14 @@ static void devm_pci_release_host_bridge_dev(struct
device *dev)
if (bridge->release_fn)
bridge->release_fn(bridge);
+
+ pci_free_resource_list(&bridge->windows);
}
static void pci_release_host_bridge_dev(struct device *dev)
{
devm_pci_release_host_bridge_dev(dev);
- pci_free_host_bridge(to_pci_host_bridge(dev));
+ kfree(to_pci_host_bridge(dev));
}
struct pci_host_bridge *pci_alloc_host_bridge(size_t priv)
--
2.13.6
[PATCH v2 07/10] PCI: Convert of_pci_get_host_bridge_resources() users to devm variant
From: Jan Kiszka
Straightforward for all of them, no more leaks afterwards.
CC: Jingoo Han
CC: Joao Pinto
CC: Lorenzo Pieralisi
Signed-off-by: Jan Kiszka
Acked-by: Jingoo Han
---
drivers/pci/dwc/pcie-designware-host.c | 2 +-
drivers/pci/host/pci-aardvark.c| 5 ++---
drivers/pci/host/pci-ftpci100.c| 4 ++--
drivers/pci/host/pci-v3-semi.c | 3 ++-
drivers/pci/host/pci-versatile.c | 3 +--
drivers/pci/host/pci-xgene.c | 3 ++-
drivers/pci/host/pcie-altera.c | 5 ++---
drivers/pci/host/pcie-iproc-platform.c | 4 ++--
drivers/pci/host/pcie-rcar.c | 5 ++---
drivers/pci/host/pcie-rockchip.c | 4 ++--
drivers/pci/host/pcie-xilinx-nwl.c | 4 ++--
drivers/pci/host/pcie-xilinx.c | 4 ++--
drivers/pci/of.c | 4 ++--
13 files changed, 24 insertions(+), 26 deletions(-)
diff --git a/drivers/pci/dwc/pcie-designware-host.c
b/drivers/pci/dwc/pcie-designware-host.c
index 6c409079d514..a8f6ab54b4c0 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -342,7 +342,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
if (!bridge)
return -ENOMEM;
- ret = of_pci_get_host_bridge_resources(np, 0, 0xff,
+ ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
&bridge->windows, &pp->io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c
index 9abf549631b4..1e048dd806dc 100644
--- a/drivers/pci/host/pci-aardvark.c
+++ b/drivers/pci/host/pci-aardvark.c
@@ -822,14 +822,13 @@ static int advk_pcie_parse_request_of_pci_ranges(struct
advk_pcie *pcie)
{
int err, res_valid = 0;
struct device *dev = &pcie->pdev->dev;
- struct device_node *np = dev->of_node;
struct resource_entry *win, *tmp;
resource_size_t iobase;
INIT_LIST_HEAD(&pcie->resources);
- err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pcie->resources,
- &iobase);
+ err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ &pcie->resources, &iobase);
if (err)
return err;
diff --git a/drivers/pci/host/pci-ftpci100.c b/drivers/pci/host/pci-ftpci100.c
index 5008fd87956a..87748eaeaaed 100644
--- a/drivers/pci/host/pci-ftpci100.c
+++ b/drivers/pci/host/pci-ftpci100.c
@@ -476,8 +476,8 @@ static int faraday_pci_probe(struct platform_device *pdev)
if (IS_ERR(p->base))
return PTR_ERR(p->base);
- ret = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff,
- &res, &io_base);
+ ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ &res, &io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-v3-semi.c b/drivers/pci/host/pci-v3-semi.c
index 0a4dea796663..167bf6f6b378 100644
--- a/drivers/pci/host/pci-v3-semi.c
+++ b/drivers/pci/host/pci-v3-semi.c
@@ -791,7 +791,8 @@ static int v3_pci_probe(struct platform_device *pdev)
if (IS_ERR(v3->config_base))
return PTR_ERR(v3->config_base);
- ret = of_pci_get_host_bridge_resources(np, 0, 0xff, &res, &io_base);
+ ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+ &io_base);
if (ret)
return ret;
diff --git a/drivers/pci/host/pci-versatile.c b/drivers/pci/host/pci-versatile.c
index 5b3876f5312b..ff2cd12b3978 100644
--- a/drivers/pci/host/pci-versatile.c
+++ b/drivers/pci/host/pci-versatile.c
@@ -64,11 +64,10 @@ static int versatile_pci_parse_request_of_pci_ranges(struct
device *dev,
struct list_head *res)
{
int err, mem = 1, res_valid = 0;
- struct device_node *np = dev->of_node;
resource_size_t iobase;
struct resource_entry *win, *tmp;
- err = of_pci_get_host_bridge_resources(np, 0, 0xff, res, &iobase);
+ err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, res, &iobase);
if (err)
return err;
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index 0a0d7ee6d3c9..7b3ed6e34b6c 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -632,7 +632,8 @@ static int xgene_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = of_pci_get_host_bridge_resources(dn, 0, 0xff, &res, &iobase);
+ ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff, &res,
+ &iobase);
if (ret)
return ret;
diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
index a6af62e
Re: [RFC PATCH 1/2] ACPI / PNP: Don't add "enumeration_by_parent" devices
On Fri, 27 Apr 2018, John Garry wrote:
> On 26/04/2018 15:23, John Garry wrote:
> > On 26/04/2018 15:08, Mika Westerberg wrote:
> > > On Thu, Apr 26, 2018 at 02:49:49PM +0100, John Garry wrote:
> > > > diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> > > > index 2d4611e..b04425b 100644
> > > > --- a/drivers/bus/hisi_lpc.c
> > > > +++ b/drivers/bus/hisi_lpc.c
> > > > @@ -18,6 +18,8 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > +#include "../tty/serial/8250/8250.h"
> > > >
> > > > #define DRV_NAME "hisi-lpc"
> > > >
> > > > @@ -345,6 +347,7 @@ static void hisi_lpc_comm_outs(void *hostdata,
> > > > unsigned
> > > > long pio,
> > > > #define MFD_CHILD_NAME_LEN (ACPI_ID_LEN +
> > > > sizeof(MFD_CHILD_NAME_PREFIX) -
> > > > 1)
> > > >
> > > > struct hisi_lpc_mfd_cell {
> > > > +struct plat_serial8250_port serial8250_port;
> > > > struct mfd_cell_acpi_match acpi_match;
> > > > char name[MFD_CHILD_NAME_LEN];
> > > > char pnpid[ACPI_ID_LEN];
> > > > @@ -513,10 +516,31 @@ static int hisi_lpc_acpi_probe(struct device
> > > > *hostdev)
> > > > dev_warn(&child->dev, "set resource fail (%d)\n", ret);
> > > > return ret;
> > > > }
> > > > +if (!strcmp(acpi_device_hid(child), "HISI1031")) {
> > >
> >
> > Hi Mika,
> >
> > > Hmm, there is a way in struct mfd_cell to match child devices using _HID
> > > so is there something preventing you from using that?
> >
> > Not that I know about. Can you describe this method? I guess I also
> > don't need to set the mfd_cell pnpid either for this special case device.
> >
>
> So we using the mfd_cell to match child devices using _HID. At a glance, I
> don't actually see other drivers to use mfd_cell_acpi_match.pnpid .
>
> Anyway we don't use static tables as we need to update the resources of the
> cell dynamically. However I do look at a driver like intel_quark_i2c_gpio.c,
> and this dynamically modifies the value of global mfd_cell array here:
> https://elixir.bootlin.com/linux/latest/source/drivers/mfd/intel_quark_i2c_gpio.c#L266
>
> I know the cell array is only used at probe time, but this did not look to
> be good standard practice to me.
Lots of drivers do this to supply dynamic data. If there is no other
sane way of providing such data, it's fine to do. Although each
situation should be dealt with on a case-by-case basis.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
linux-next: Tree for Apr 30
Hi all, Changes since 20180426: The qcom tree lost its build failure. The clk-samsung tree lost its build failure. The net-next tree gained a conflict against the net tree. The ipsec-next tree gained a conflict against the net-next tree. The rpmsg tree lost its build failure. Non-merge commits (relative to Linus' tree): 3135 3014 files changed, 121018 insertions(+), 56873 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 258 trees (counting Linus' and 44 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (6da6c0db5316 Linux v4.17-rc3) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (6d08b06e67cd Linux 4.17-rc2) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (30cfae461581 ARM: replace unnecessary perl with sed and the shell $(( )) operator) Merging arm64-fixes/for-next/fixes (3789c122d0a0 arm64: avoid instrumenting atomic_ll_sc.o) Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" comment) Merging powerpc-fixes/fixes (b2d7ecbe3556 powerpc/kvm/booke: Fix altivec related build break) Merging sparc/master (17dec0a94915 Merge branch 'userns-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (1d39fd1bedbd Merge branch 'sfc-more-ARFS-fixes') Merging bpf/master (815425567dea bpf: fix uninitialized variable in bpf tools) Merging ipsec/master (b48c05ab5d32 xfrm: Fix warning in xfrm6_tunnel_net_exit.) Merging netfilter/master (2f99aa31cd7a netfilter: nf_tables: skip synchronize_rcu if transaction log is empty) Merging ipvs/master (765cca91b895 netfilter: conntrack: include kmemleak.h for kmemleak_not_leak()) Merging wireless-drivers/master (af8a41cccf8f rtlwifi: cleanup 8723be ant_sel definition) Merging mac80211/master (2f0605a697f4 nl80211: Free connkeys on external authentication failure) Merging rdma-fixes/for-rc (dc5640f294e4 IB/core: Fix deleting default GIDs when changing mac adddress) Merging sound-current/for-linus (52759c096351 ALSA: dice: fix kernel NULL pointer dereference due to invalid calculation for array index) Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to pcie_print_link_status() messages) Merging driver-core.current/driver-core-linus (b93815d0f37e firmware: some documentation fixes) Merging tty.current/tty-linus (bcdd0ca8cb87 tty: Use __GFP_NOFAIL for tty_ldisc_get()) Merging usb.current/usb-linus (573a09487375 Merge tag 'usb-serial-4.17-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus) Merging usb-gadget-fixes/fixes (ed769520727e usb: gadget: composite Allow for larger configuration descriptors) Merging usb-serial-fixes/usb-linus (470b5d6f0cf4 USB: serial: ftdi_sio: use jtag quirk for Arrow USB Blaster) Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: fix ulpi-node lookup) Merging phy/fixes (60cc43fc8884 Linux 4.17-rc1) Merging staging.current/staging-linus (b00e2fd10429 staging: wilc1000: fix NULL pointer exception in host_int_parse_assoc_resp_info()) Merging char-misc.current/char-misc-linus (6a7228d90d42
Re: [RFD] x86: The future of MPX
On 04/28/2018 09:44 AM, Linus Torvalds wrote: > On Sat, Apr 28, 2018 at 9:36 AM Linus Torvalds < > torva...@linux-foundation.org> wrote: > >> They need to be run as root. > Side note: don't get me wrong. If the MPX stuff isn't supported by gcc, > then there is little point in us supporting it in the kernel either. The loss of the GCC support is definitely a bummer. There are no objections from me against removing it from future kernels. I think it will be pretty straightforward, just leaving the prctl() numbers as placeholders.
Re: Linux messages full of `random: get_random_u32 called from`
On Sun, Apr 29, 2018 at 08:11:07PM -0400, Theodore Y. Ts'o wrote:
>
> What your patch does is assume that there is a full bit of uncertainty
> that can be obtained from the information gathered from each
> interrupt. I *might* be willing to assume that to be valid on x86
> systems that have a high resolution cycle counter. But on ARM
> platforms, especially during system bootup when the user isn't typing
> anything and SSD's and flash storage tend to have very predictable
> timing patterns? Not a bet I'd be willing to take. Even with a cycle
> counter, there's a reason why we assumed that we need to mix in timing
> results from 64 interrupts or one second's worth before we would give
> a single bit's worth of entropy credit.
>
> - Ted
What about abusing high-resolution timers to get entropy? Since hrtimers can't
make guarantees down to the nanosecond, there's always a skew between the
requested expiry time and the actual expiry time.
Please see the attached patch and let me know just how horrible it is.
Sultan
>From b0d21c38558c661531d4cb46816fbb36b874a169 Mon Sep 17 00:00:00 2001
From: Sultan Alsawaf
Date: Sun, 29 Apr 2018 21:28:08 -0700
Subject: [PATCH] random: use high-res timers to generate entropy until crng
init is done
---
drivers/char/random.c | 47 +++
1 file changed, 47 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index d9e38523b383..af2d60bbcec3 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -286,6 +286,7 @@
#define OUTPUT_POOL_WORDS (1 << (OUTPUT_POOL_SHIFT-5))
#define SEC_XFER_SIZE 512
#define EXTRACT_SIZE 10
+#define ENTROPY_GEN_INTVL_NS (1 * NSEC_PER_MSEC)
#define LONGS(x) (((x) + sizeof(unsigned long) - 1)/sizeof(unsigned long))
@@ -408,6 +409,8 @@ static struct fasync_struct *fasync;
static DEFINE_SPINLOCK(random_ready_list_lock);
static LIST_HEAD(random_ready_list);
+static struct hrtimer entropy_gen_hrtimer;
+
struct crng_state {
__u32 state[16];
unsigned long init_time;
@@ -2287,3 +2290,47 @@ void add_hwgenerator_randomness(const char *buffer,
size_t count,
credit_entropy_bits(poolp, entropy);
}
EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
+
+/*
+ * Generate entropy on init using high-res timers. Although high-res timers
+ * provide nanosecond precision, they don't actually honor requests to the
+ * nanosecond. The skew between the expected time difference in nanoseconds and
+ * the actual time difference can be used as a way to generate entropy on boot
+ * for machines that lack sufficient boot-time entropy.
+ */
+static enum hrtimer_restart entropy_timer_cb(struct hrtimer *timer)
+{
+ static u64 prev_ns;
+ u64 curr_ns, delta;
+
+ if (crng_ready())
+ return HRTIMER_NORESTART;
+
+ curr_ns = ktime_get_mono_fast_ns();
+ delta = curr_ns - prev_ns;
+
+ add_interrupt_randomness(delta);
+
+ /* Use the hrtimer skew to make the next interval more unpredictable */
+ if (likely(prev_ns))
+ hrtimer_add_expires_ns(timer, delta);
+ else
+ hrtimer_add_expires_ns(timer, ENTROPY_GEN_INTVL_NS);
+
+ prev_ns = curr_ns;
+ return HRTIMER_RESTART;
+}
+
+static int entropy_gen_hrtimer_init(void)
+{
+ if (!IS_ENABLED(CONFIG_HIGH_RES_TIMERS))
+ return 0;
+
+ hrtimer_init(&entropy_gen_hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+
+ entropy_gen_hrtimer.function = entropy_timer_cb;
+ hrtimer_start(&entropy_gen_hrtimer, ns_to_ktime(ENTROPY_GEN_INTVL_NS),
+ HRTIMER_MODE_REL);
+ return 0;
+}
+core_initcall(entropy_gen_hrtimer_init);
--
2.14.1
[PATCH 4/4] NFS: Avoid quadratic search when freeing delegations.
There are three places that walk all delegation for an nfs_client and
restart whenever they find something interesting - potentially
resulting in a quadratic search: If there are 10,000 uninteresting
delegations followed by 10,000 interesting one, then the code
skips over 100,000,000 delegations, which can take a noticeable amount
of time.
Of these nfs_delegation_reap_unclaimed() and
nfs_reap_expired_delegations() are only called during unusual events:
a server reboots or reports expired delegations, probably due to a
network partition. Optimizing these is not particularly important.
The third, nfs_client_return_marked_delegations(), is called
periodically via nfs_expire_unreferenced_delegations(). It could
cause periodic problems on a busy server.
New delegations are added to the end of the list, so if there are
10,000 open files with delegations, and 10,000 more recently opened files
that received delegations but are now closed, then
nfs_client_return_marked_delegations() can take seconds to skip over
the 10,000 open files 10,000 times. That is a waste of time.
The avoid this waste a place-holder (an inode) is kept when locks are
dropped, so that the place can usually be found again after taking
rcu_readlock(). This place holder ensure that we find the right
starting point in the list of nfs_servers, and makes is probable that
we find the right starting point in the list of delegations.
We might need to occasionally restart at the head of that list.
It might be possible that the place_holder inode could lose its
delegation separately, and then get a new one using the same (freed
and then reallocated) 'struct nfs_delegation'. Were this to happen,
the new delegation would be at the end of the list and we would miss
returning some other delegations. This would have the effect of
unnecessarily delaying the return of some unused delegations until the
next time this function is called - typically 90 seconds later. As
this is not a correctness issue and is vanishingly unlikely to happen,
it does not seem worth addressing.
Signed-off-by: NeilBrown
---
fs/nfs/delegation.c | 57 +++
1 file changed, 53 insertions(+), 4 deletions(-)
diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index 76ab1374f589..cfec852c8bad 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -483,28 +483,73 @@ static bool nfs_delegation_need_return(struct
nfs_delegation *delegation)
int nfs_client_return_marked_delegations(struct nfs_client *clp)
{
struct nfs_delegation *delegation;
+ struct nfs_delegation *prev;
struct nfs_server *server;
struct inode *inode;
+ struct inode *place_holder = NULL;
+ struct nfs_delegation *place_holder_deleg = NULL;
int err = 0;
restart:
+ /*
+* To avoid quadratic looping we hold a reference
+* to an inode place_holder. Each time we restart, we
+* list nfs_servers from the server of that inode, and
+* delegation in the server from the delegations of that
+* inode.
+* prev is an RCU-protected pointer to a delegation which
+* wasn't marked for return and might be a good choice for
+* the next place_holder.
+*/
rcu_read_lock();
- list_for_each_entry_rcu(server, &clp->cl_superblocks, client_link) {
- list_for_each_entry_rcu(delegation, &server->delegations,
- super_list) {
- if (!nfs_delegation_need_return(delegation))
+ prev = NULL;
+ if (place_holder)
+ server = NFS_SERVER(place_holder);
+ else
+ server = list_entry_rcu(clp->cl_superblocks.next,
+ struct nfs_server, client_link);
+ list_for_each_entry_from_rcu(server, &clp->cl_superblocks, client_link)
{
+ delegation = NULL;
+ if (place_holder && server == NFS_SERVER(place_holder))
+ delegation =
rcu_dereference(NFS_I(place_holder)->delegation);
+ if (!delegation || delegation != place_holder_deleg)
+ delegation = list_entry_rcu(server->delegations.next,
+ struct nfs_delegation,
super_list);
+ list_for_each_entry_from_rcu(delegation, &server->delegations,
super_list) {
+ struct inode *to_put = NULL;
+
+ if (!nfs_delegation_need_return(delegation)) {
+ prev = delegation;
continue;
+ }
if (!nfs_sb_active(server->super))
break;
+
+ if (prev) {
+ struct inode *tmp;
+
+ tmp = nfs_delegation_grab_inode(prev);
+ if (t
[PATCH 3/4] rculist: add list_for_each_entry_from_rcu()
list_for_each_entry_from_rcu() is an RCU version of list_for_each_entry_from(). It walks a linked list under rcu protection, from a given start point. It is similar to list_for_each_entry_continue_rcu() but starts *at* the given position rather than *after* it. Naturally, the start point must be known to be in the list. Signed-off-by: NeilBrown --- include/linux/rculist.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/linux/rculist.h b/include/linux/rculist.h index 127f534fec94..36df6ccbc874 100644 --- a/include/linux/rculist.h +++ b/include/linux/rculist.h @@ -403,6 +403,19 @@ static inline void list_splice_tail_init_rcu(struct list_head *list, &pos->member != (head);\ pos = list_entry_rcu(pos->member.next, typeof(*pos), member)) +/** + * list_for_each_entry_from_rcu - iterate over a list from current point + * @pos: the type * to use as a loop cursor. + * @head: the head for your list. + * @member:the name of the list_node within the struct. + * + * Iterate over the tail of a list starting from a given position, + * which must have been in the list when the RCU read lock was taken. + */ +#define list_for_each_entry_from_rcu(pos, head, member) \ + for (; &(pos)->member != (head); \ + pos = list_entry_rcu(pos->member.next, typeof(*(pos)), member)) + /** * hlist_del_rcu - deletes entry from hash list without re-initialization * @n: the element to delete from the hash list.
[PATCH 2/4] NFS: use cond_resched() when restarting walk of delegation list.
In three places we walk the list of delegations for an nfs_client until an interesting one is found, then we act of that delegation and restart the walk. New delegations are added to the end of a list and the interesting delegations are usually old, so in many case we won't repeat a long walk over and over again, but it is possible - particularly if the first server in the list has a large number of uninteresting delegations. In each cache the work done on interesting delegations will often complete without sleeping, so this could loop many times without giving up the CPU. So add a cond_resched() at an appropriate point to avoid hogging the CPU for too long. Signed-off-by: NeilBrown --- fs/nfs/delegation.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c index af32365894c8..76ab1374f589 100644 --- a/fs/nfs/delegation.c +++ b/fs/nfs/delegation.c @@ -508,6 +508,7 @@ int nfs_client_return_marked_delegations(struct nfs_client *clp) err = nfs_end_delegation_return(inode, delegation, 0); iput(inode); nfs_sb_deactive(server->super); + cond_resched(); if (!err) goto restart; set_bit(NFS4CLNT_DELEGRETURN, &clp->cl_state); @@ -904,6 +905,7 @@ void nfs_delegation_reap_unclaimed(struct nfs_client *clp) } iput(inode); nfs_sb_deactive(server->super); + cond_resched(); goto restart; } } @@ -1020,6 +1022,7 @@ void nfs_reap_expired_delegations(struct nfs_client *clp) } iput(inode); nfs_sb_deactive(server->super); + cond_resched(); goto restart; } }
[PATCH 1/4] NFS: slight optimization for walking list for delegations
There are 3 places where we walk the list of delegations
for an nfs_client.
In each case there are two nested loops, one for nfs_servers
and one for nfs_delegations.
When we find an interesting delegation we try to get an active
reference to the server. If that fails, it is pointless to
continue to look at the other delegation for the server as
we will never be able to get an active reference.
So instead of continuing in the inner loop, break out
and continue in the outer loop.
---
fs/nfs/delegation.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index 1819d0d0ba4b..af32365894c8 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -495,7 +495,7 @@ int nfs_client_return_marked_delegations(struct nfs_client
*clp)
if (!nfs_delegation_need_return(delegation))
continue;
if (!nfs_sb_active(server->super))
- continue;
+ break;
inode = nfs_delegation_grab_inode(delegation);
if (inode == NULL) {
rcu_read_unlock();
@@ -887,7 +887,7 @@ void nfs_delegation_reap_unclaimed(struct nfs_client *clp)
&delegation->flags) == 0)
continue;
if (!nfs_sb_active(server->super))
- continue;
+ break;
inode = nfs_delegation_grab_inode(delegation);
if (inode == NULL) {
rcu_read_unlock();
@@ -995,7 +995,7 @@ void nfs_reap_expired_delegations(struct nfs_client *clp)
&delegation->flags) == 0)
continue;
if (!nfs_sb_active(server->super))
- continue;
+ break;
inode = nfs_delegation_grab_inode(delegation);
if (inode == NULL) {
rcu_read_unlock();
[PATCH 0/4 V2] Avoid quadratic search when freeing delegations
Following review from Mathieu (thanks) I've made some revisions and split this into four patches. The RCU change is now in patch 3 by itself. I've also revised the description in the main (final) patch quite a bit. Thanks, NeilBrown --- NeilBrown (4): NFS: slight optimization for walking list for delegations NFS: use cond_resched() when restarting walk of delegation list. rculist: add list_for_each_entry_from_rcu() NFS: Avoid quadratic search when freeing delegations. fs/nfs/delegation.c | 66 ++- include/linux/rculist.h | 13 + 2 files changed, 72 insertions(+), 7 deletions(-) -- Signature
Re: [PATCHv2 1/1] arm64: To remove initrd reserved area entry from memblock
Please ignore this mail. I missed replying to the thread.
I have resubmitted over the proper thread.
On Mon, 30 Apr 2018, 09:44 CHANDAN VN, wrote:
>
> INITRD reserved area entry is not removed from memblock
> even though initrd reserved area is freed. After freeing
> the memory it is released from memblock. The same can be
> checked from /sys/kernel/debug/memblock/reserved.
>
> The patch makes sure that the initrd entry is removed from
> memblock when keepinitrd is not enabled.
>
> The patch only affects accounting and debugging. This does not
> fix any memory leak.
>
> Signed-off-by: CHANDAN VN
> ---
> arch/arm64/mm/init.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 9f3c47a..1b18b47 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -646,8 +646,10 @@ void free_initmem(void)
>
> void __init free_initrd_mem(unsigned long start, unsigned long end)
> {
> - if (!keep_initrd)
> + if (!keep_initrd) {
> free_reserved_area((void *)start, (void *)end, 0, "initrd");
> + memblock_free(__virt_to_phys(start), end - start);
> + }
> }
>
> static int __init keepinitrd_setup(char *__unused)
> --
> 1.9.1
>
[PATCH] iio: humidity: hts221: Fix sensor reads after resume
CTRL1 register (ODR & BDU settings) gets reset after system comes back
from suspend, causing subsequent reads from the sensor to fail.
This patch restores the CTRL1 register after resume.
Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git iio-fixes-for-4.14b
Since 4.17.rc1, this driver uses REGMAP; I'll send a separate patch to
address this issue.
Cc: sta...@vger.kernel.org
Fixes: ffebe74b7c95 (iio: humidity: hts221: avoid useless ODR reconfiguration)
Signed-off-by: Shrirang Bagul
---
drivers/iio/humidity/hts221_core.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/humidity/hts221_core.c
b/drivers/iio/humidity/hts221_core.c
index 32524a8dc66f..fed2da64fa3b 100644
--- a/drivers/iio/humidity/hts221_core.c
+++ b/drivers/iio/humidity/hts221_core.c
@@ -674,11 +674,15 @@ static int __maybe_unused hts221_resume(struct device
*dev)
struct hts221_hw *hw = iio_priv(iio_dev);
int err = 0;
- if (hw->enabled)
- err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
-HTS221_ENABLE_MASK, true);
+ err = hts221_write_with_mask(hw, HTS221_REG_CNTRL1_ADDR,
+HTS221_BDU_MASK, 1);
+ if (err < 0)
+ goto fail_err;
- return err;
+ err = hts221_update_odr(hw, hw->odr);
+
+fail_err:
+ return err < 0 ? err : 0;
}
const struct dev_pm_ops hts221_pm_ops = {
--
2.14.1
[PATCHv2 1/1] arm64: To remove initrd reserved area entry from memblock
INITRD reserved area entry is not removed from memblock
even though initrd reserved area is freed. After freeing
the memory it is released from memblock. The same can be
checked from /sys/kernel/debug/memblock/reserved.
The patch makes sure that the initrd entry is removed from
memblock when keepinitrd is not enabled.
The patch only affects accounting and debugging. This does not
fix any memory leak.
Signed-off-by: CHANDAN VN
---
arch/arm64/mm/init.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9f3c47a..1b18b47 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -646,8 +646,10 @@ void free_initmem(void)
void __init free_initrd_mem(unsigned long start, unsigned long end)
{
- if (!keep_initrd)
+ if (!keep_initrd) {
free_reserved_area((void *)start, (void *)end, 0, "initrd");
+ memblock_free(__virt_to_phys(start), end - start);
+ }
}
static int __init keepinitrd_setup(char *__unused)
--
1.9.1
[PATCHv2 1/1] arm64: To remove initrd reserved area entry from memblock
INITRD reserved area entry is not removed from memblock
even though initrd reserved area is freed. After freeing
the memory it is released from memblock. The same can be
checked from /sys/kernel/debug/memblock/reserved.
The patch makes sure that the initrd entry is removed from
memblock when keepinitrd is not enabled.
The patch only affects accounting and debugging. This does not
fix any memory leak.
Signed-off-by: CHANDAN VN
---
arch/arm64/mm/init.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9f3c47a..1b18b47 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -646,8 +646,10 @@ void free_initmem(void)
void __init free_initrd_mem(unsigned long start, unsigned long end)
{
- if (!keep_initrd)
+ if (!keep_initrd) {
free_reserved_area((void *)start, (void *)end, 0, "initrd");
+ memblock_free(__virt_to_phys(start), end - start);
+ }
}
static int __init keepinitrd_setup(char *__unused)
--
1.9.1
Re: [PATCH 3/3] genalloc: selftest
Hi Igor, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc3 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Igor-Stoppa/linux-next-mm-hardening-Track-genalloc-allocations/20180430-064850 config: um-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=um All errors (new ones prefixed by >>): >> lib/test_genalloc.c:18:10: fatal error: linux/test_genalloc.h: No such file >> or directory #include ^~~ compilation terminated. vim +18 lib/test_genalloc.c 17 > 18 #include 19 20 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
RE: [PATCH 2/6 v3] iommu: of: make of_pci_map_rid() available for other devices too
> -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: Friday, April 27, 2018 10:46 PM > To: Nipun Gupta > Cc: robin.mur...@arm.com; will.dea...@arm.com; mark.rutl...@arm.com; > catalin.mari...@arm.com; h...@lst.de; gre...@linuxfoundation.org; > j...@8bytes.org; m.szyprow...@samsung.com; shawn...@kernel.org; > frowand.l...@gmail.com; bhelg...@google.com; iommu@lists.linux- > foundation.org; linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; linux- > p...@vger.kernel.org; Bharat Bhushan ; > stuyo...@gmail.com; Laurentiu Tudor ; Leo Li > > Subject: Re: [PATCH 2/6 v3] iommu: of: make of_pci_map_rid() available for > other devices too > > On Fri, Apr 27, 2018 at 03:57:02PM +0530, Nipun Gupta wrote: > > iommu-map property is also used by devices with fsl-mc. This > > patch moves the of_pci_map_rid to generic location, so that it > > can be used by other busses too. > > > > 'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no > > functional change done in the API. > > > > Signed-off-by: Nipun Gupta > > --- > > drivers/iommu/of_iommu.c | 6 +-- > > drivers/of/address.c | 102 > + > > drivers/of/irq.c | 7 ++-- > > drivers/pci/of.c | 101 > > > > include/linux/of_address.h | 11 + > > include/linux/of_pci.h | 10 - > > 6 files changed, 120 insertions(+), 117 deletions(-) > > of/address.c isn't really the best fit either, though I don't have a > better suggestion. > > I'm guessing this breaks on Sparc which doesn't build of/address.c. > I guess move it to base.c and of.h if that is the case. Sure, that makes sense. Thank you for the suggestion !! I'll spin off new version with this change. Regards, Nipun > > Rob
[PATCH] random: remove unused argument from add_interrupt_randomness()
>From cdc2a03f93fdec88ad040a212605e20ab97c3e19 Mon Sep 17 00:00:00 2001
From: Sultan Alsawaf
Date: Sun, 29 Apr 2018 20:04:35 -0700
Subject: [PATCH] random: remove unused argument from add_interrupt_randomness()
The irq_flags parameter is not used. Remove it.
Signed-off-by: Sultan Alsawaf
---
drivers/char/random.c | 4 ++--
drivers/hv/vmbus_drv.c | 2 +-
include/linux/random.h | 2 +-
kernel/irq/handle.c| 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 38729baed6ee..d9e38523b383 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -131,7 +131,7 @@
* void add_device_randomness(const void *buf, unsigned int size);
* void add_input_randomness(unsigned int type, unsigned int code,
*unsigned int value);
- * void add_interrupt_randomness(int irq, int irq_flags);
+ * void add_interrupt_randomness(int irq);
* void add_disk_randomness(struct gendisk *disk);
*
* add_device_randomness() is for adding data to the random pool that
@@ -1164,7 +1164,7 @@ static __u32 get_reg(struct fast_pool *f, struct pt_regs
*regs)
return *ptr;
}
-void add_interrupt_randomness(int irq, int irq_flags)
+void add_interrupt_randomness(int irq)
{
struct entropy_store*r;
struct fast_pool*fast_pool = this_cpu_ptr(&irq_randomness);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index bc65c4d79c1f..777096d560cb 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1016,7 +1016,7 @@ static void vmbus_isr(void)
tasklet_schedule(&hv_cpu->msg_dpc);
}
- add_interrupt_randomness(HYPERVISOR_CALLBACK_VECTOR, 0);
+ add_interrupt_randomness(HYPERVISOR_CALLBACK_VECTOR);
}
diff --git a/include/linux/random.h b/include/linux/random.h
index 4024f7d9c77d..b71f87dbf7cd 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -32,7 +32,7 @@ static inline void add_latent_entropy(void) {}
extern void add_input_randomness(unsigned int type, unsigned int code,
unsigned int value) __latent_entropy;
-extern void add_interrupt_randomness(int irq, int irq_flags) __latent_entropy;
+extern void add_interrupt_randomness(int irq) __latent_entropy;
extern void get_random_bytes(void *buf, int nbytes);
extern int wait_for_random_bytes(void);
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 79f987b942b8..1bc4dcc489d0 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -186,7 +186,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
retval = __handle_irq_event_percpu(desc, &flags);
- add_interrupt_randomness(desc->irq_data.irq, flags);
+ add_interrupt_randomness(desc->irq_data.irq);
if (!noirqdebug)
note_interrupt(desc, retval);
--
2.14.1
Re: [RFC net-next 0/5] Support for PHY test modes
From: Florian Fainelli Date: Fri, 27 Apr 2018 17:32:30 -0700 > This patch series adds support for specifying PHY test modes through > ethtool and paves the ground for adding support for more complex > test modes that might require data to be exchanged between user and > kernel space. > > As an example, patches are included to add support for the IEEE > electrical test modes for 100BaseT2 and 1000BaseT. Those do not > require data to be passed back and forth. > > I believe the infrastructure to be usable enough to add support for > other things like: > > - cable diagnostics > - pattern generator/waveform generator with specific pattern being > indicated for instance > > Questions for Andrew, and others: > > - there could be room for adding additional ETH_TEST_FL_* values in order to > help determine how the test should be running > - some of these tests can be disruptive to connectivity, the minimum we could > do is stop the PHY state machine and restart it when "normal" is used to > exit > those test modes > > Comments welcome! Generally, no objection to providing this in the general manner you have implemented it via ethtool. I think in order to answer the disruptive question, you need to give some information about what kind of context this stuff would be used in, and if in those contexts what the user expectations are or might be. Are these test modes something that usually would be initiated with the interface down?
fscache kasan splat on v4.17-rc3
[ 46.333213] == [ 46.336298] BUG: KASAN: slab-out-of-bounds in fscache_alloc_cookie+0x129/0x310 [ 46.338208] Read of size 4 at addr 8803ea90261c by task mount.nfs/839 [ 46.342780] CPU: 2 PID: 839 Comm: mount.nfs Not tainted 4.17.0-rc3-backup-debug+ #1 [ 46.342783] Hardware name: ASUS All Series/Z97-DELUXE, BIOS 2602 08/18/2015 [ 46.342784] Call Trace: [ 46.342790] dump_stack+0x74/0xbb [ 46.342795] print_address_description+0x9b/0x2b0 [ 46.342797] kasan_report+0x258/0x380 [ 46.355407] ? fscache_alloc_cookie+0x129/0x310 [ 46.355410] fscache_alloc_cookie+0x129/0x310 [ 46.355413] __fscache_acquire_cookie+0xd2/0x570 [ 46.355417] nfs_fscache_get_client_cookie+0x206/0x220 [ 46.355419] ? nfs_readpage_from_fscache_complete+0xa0/0xa0 [ 46.355422] ? rcu_read_lock_sched_held+0x8a/0xa0 [ 46.355426] ? memcpy+0x34/0x50 [ 46.355428] nfs_alloc_client+0x1d9/0x1f0 [ 46.371854] nfs4_alloc_client+0x22/0x420 [ 46.371857] nfs_get_client+0x47d/0x8f0 [ 46.371860] ? pcpu_alloc+0x599/0xaf0 [ 46.371862] nfs4_set_client+0x155/0x1e0 [ 46.371865] ? nfs4_check_serverowner_major_id+0x50/0x50 [ 46.371867] nfs4_create_server+0x261/0x4e0 [ 46.371870] ? nfs4_set_ds_client+0x200/0x200 [ 46.371872] ? alloc_vfsmnt+0xa6/0x360 [ 46.371875] ? __lockdep_init_map+0xaa/0x290 [ 46.371878] nfs4_remote_mount+0x31/0x60 [ 46.371880] mount_fs+0x2f/0xd0 [ 46.371884] vfs_kern_mount+0x68/0x200 [ 46.396948] nfs_do_root_mount+0x7f/0xc0 [ 46.396952] ? do_raw_spin_unlock+0xa2/0x130 [ 46.396954] nfs4_try_mount+0x7f/0x110 [ 46.396957] nfs_fs_mount+0xca5/0x1450 [ 46.396960] ? pcpu_alloc+0x599/0xaf0 [ 46.396962] ? nfs_remount+0x8a0/0x8a0 [ 46.396964] ? mark_held_locks+0x1c/0xb0 [ 46.396967] ? __raw_spin_lock_init+0x1c/0x70 [ 46.412631] ? trace_hardirqs_on_caller+0x187/0x260 [ 46.412633] ? nfs_clone_super+0x150/0x150 [ 46.412635] ? nfs_destroy_inode+0x20/0x20 [ 46.412637] ? __lockdep_init_map+0xaa/0x290 [ 46.412639] ? __lockdep_init_map+0xaa/0x290 [ 46.412641] ? mount_fs+0x2f/0xd0 [ 46.412642] mount_fs+0x2f/0xd0 [ 46.412645] vfs_kern_mount+0x68/0x200 [ 46.412648] ? do_raw_read_unlock+0x28/0x50 [ 46.412651] do_mount+0x2ac/0x14f0 [ 46.412653] ? copy_mount_string+0x20/0x20 [ 46.431590] ? copy_mount_options+0xe6/0x1b0 [ 46.431592] ? copy_mount_options+0x100/0x1b0 [ 46.431594] ? copy_mount_options+0xe6/0x1b0 [ 46.431596] ksys_mount+0x7e/0xd0 [ 46.431599] __x64_sys_mount+0x62/0x70 [ 46.431601] do_syscall_64+0xc7/0x8a0 [ 46.431603] ? syscall_return_slowpath+0x3c0/0x3c0 [ 46.431605] ? mark_held_locks+0x1c/0xb0 [ 46.431609] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe [ 46.431611] ? trace_hardirqs_off_caller+0xc2/0x110 [ 46.431613] ? trace_hardirqs_off_thunk+0x1a/0x1c [ 46.431615] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 46.431617] RIP: 0033:0x7f546ceb97fa [ 46.431619] RSP: 002b:7ffdf1c9d078 EFLAGS: 0206 ORIG_RAX: 00a5 [ 46.431622] RAX: ffda RBX: RCX: 7f546ceb97fa [ 46.431623] RDX: 55decf202b20 RSI: 55decf202b40 RDI: 55decf204850 [ 46.431625] RBP: 7ffdf1c9d1d0 R08: 55decf206680 R09: 62353a303036343a [ 46.431626] R10: 0c00 R11: 0206 R12: 7ffdf1c9d1d0 [ 46.431627] R13: 55decf205870 R14: 001c R15: 7ffdf1c9d0e0 [ 46.431631] Allocated by task 839: [ 46.431634] kasan_kmalloc+0xa0/0xd0 [ 46.431636] __kmalloc+0x156/0x350 [ 46.431639] fscache_alloc_cookie+0x2e4/0x310 [ 46.431640] __fscache_acquire_cookie+0xd2/0x570 [ 46.431643] nfs_fscache_get_client_cookie+0x206/0x220 [ 46.431645] nfs_alloc_client+0x1d9/0x1f0 [ 46.431648] nfs4_alloc_client+0x22/0x420 [ 46.431650] nfs_get_client+0x47d/0x8f0 [ 46.431652] nfs4_set_client+0x155/0x1e0 [ 46.431653] nfs4_create_server+0x261/0x4e0 [ 46.431655] nfs4_remote_mount+0x31/0x60 [ 46.431657] mount_fs+0x2f/0xd0 [ 46.431659] vfs_kern_mount+0x68/0x200 [ 46.431662] nfs_do_root_mount+0x7f/0xc0 [ 46.484441] nfs4_try_mount+0x7f/0x110 [ 46.484443] nfs_fs_mount+0xca5/0x1450 [ 46.484445] mount_fs+0x2f/0xd0 [ 46.484447] vfs_kern_mount+0x68/0x200 [ 46.484449] do_mount+0x2ac/0x14f0 [ 46.484451] ksys_mount+0x7e/0xd0 [ 46.484452] __x64_sys_mount+0x62/0x70 [ 46.484455] do_syscall_64+0xc7/0x8a0 [ 46.484458] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 46.484461] Freed by task 407: [ 46.499159] __kasan_slab_free+0x11d/0x160 [ 46.499161] kfree+0xe5/0x320 [ 46.499163] kobject_uevent_env+0x1ab/0x760 [ 46.499165] kobject_synth_uevent+0x470/0x4e0 [ 46.499168] uevent_store+0x1c/0x40 [ 46.499171] kernfs_fop_write+0x196/0x230 [ 46.499174] __vfs_write+0xc5/0x310 [ 46.499175] vfs_write+0xfb/0x250 [ 46.499177] ksys_write+0xa7/0x130 [ 46.499180] do_syscall_64+0xc7/0x8a0 [ 46.512915] entry_SYSCALL_64_af
Re: [PATCH] net: systemport: fix spelling mistake: "asymetric" -> "asymmetric"
From: Colin King Date: Fri, 27 Apr 2018 20:09:25 +0100 > From: Colin Ian King > > Trivial fix to spelling mistake in netdev_warn warning message > > Signed-off-by: Colin Ian King Applied, thank you.
[PATCH] KVM: X86: Limit timer frequency with more smaller interval
From: Wanpeng Li Anthoine reported: The period used by Windows change over time but it can be 1 milliseconds or less. I saw the limit_periodic_timer_frequency print so 500 microseconds is sometimes reached. This patchs limits timer frequency with more smaller interval 200ms(5000Hz) to leave some headroom as Paolo suggested since Windows 10 changed the scheduler tick limit from 1024 Hz to 2048 Hz. Reported-by: Anthoine Bourgeois Suggested-by: Paolo Bonzini Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Anthoine Bourgeois Signed-off-by: Wanpeng Li --- arch/x86/kvm/x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 51ecd38..dc47073 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -114,7 +114,7 @@ module_param(ignore_msrs, bool, S_IRUGO | S_IWUSR); static bool __read_mostly report_ignored_msrs = true; module_param(report_ignored_msrs, bool, S_IRUGO | S_IWUSR); -unsigned int min_timer_period_us = 500; +unsigned int min_timer_period_us = 200; module_param(min_timer_period_us, uint, S_IRUGO | S_IWUSR); static bool __read_mostly kvmclock_periodic_sync = true; -- 2.7.4
Re: [PATCH] NFS: Avoid quadratic search when freeing delegations.
On Fri, Apr 27 2018, Mathieu Desnoyers wrote:
> - On Apr 27, 2018, at 1:29 AM, NeilBrown ne...@suse.com wrote:
>
>> If an NFS client has 10,000 delegations which are between 90 and 180 seconds
>> old,
>> and 10,000 which are between 180 and 270 seconds old, with none of them still
>> in use, it is likely that the old ones are at the end of the list.
>> The first 10,000 will not be marked to be returned, the last 10,000 will.
>>
>> To return these, the code starts at the front of the list and finds the
>> first delegation needing to be returned (testing 10,000 on the way).
>> Then it drops rcu_readlock(), returns the delegation and starts again,
>> and does this 10,000 times.
>>
>> As delegation return is async, it may never block, so these 10,000
>> delegation will be returned without stopping for a breath. The soft-lock
>> detector will notice and complain.
>>
>> This patch makes 3 changes.
>>
>> 1/ cond_resched() is added so that the soft-lockup detector doesn't notice.
>> 2/ A place-holder (an inode) is kept when locks are dropped, so that
>> the place can usually be found again after taking rcu_readlock().
>> This means we don't need to skip over 10,000 entries 10,000 times,
>> 100 million pointless operations - which could eaisly be a larger
>> number.
>> 3/ If nfs_sb_active() fails, break out of the loop - there is no point
>> in continuing.
>>
>> The patch also add list_for_each_entry_from_rcu() to rculist.h in
>> order to achieve 2/.
>>
>> Signed-off-by: NeilBrown
>> ---
>>
>> Hi,
>> I'm hoping one of the RCU reviewers will provide an Acked-by for the
>> rculist.h change.
>>
>> If you'ld like 3 patches instead of just one, please let me know. But
>> they all see to fit well together.
Thanks for your review!
>
> I think the RCU list API changes should sit in their own patch.
I guess I can split it into a separate patch if you like. Hopefully it
can still go in through the NFS tree so we need to sync separate trees.
>
>>
>> thanks,
>> NeilBrown
>>
>>
>> fs/nfs/delegation.c | 57
>> -
>> include/linux/rculist.h | 10 +
>> 2 files changed, 62 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
>> index 1819d0d0ba4b..c3d9e21ab440 100644
>> --- a/fs/nfs/delegation.c
>> +++ b/fs/nfs/delegation.c
>> @@ -483,19 +483,56 @@ static bool nfs_delegation_need_return(struct
>> nfs_delegation *delegation)
>> int nfs_client_return_marked_delegations(struct nfs_client *clp)
>> {
>> struct nfs_delegation *delegation;
>> +struct nfs_delegation *prev;
>> struct nfs_server *server;
>> struct inode *inode;
>> +struct inode *place_holder = NULL;
>> int err = 0;
>>
>> restart:
>> +/*
>> + * To avoid quadratic looping we hold an reference
>
> an reference -> a reference
Fixed, thanks.
>
>> + * to an inode place_holder. Each time we restart, we
>> + * list nfs_servers from the server of that inode, and
>> + * delegation in the server from the delegations of that
>> + * inode.
>> + * prev is an RCU-protected pointer to a delegation which
>> + * wasn't marked for return and might be a good choice for
>> + * the next place_holder.
>> + */
>> rcu_read_lock();
>> -list_for_each_entry_rcu(server, &clp->cl_superblocks, client_link) {
>> -list_for_each_entry_rcu(delegation, &server->delegations,
>> -super_list) {
>> -if (!nfs_delegation_need_return(delegation))
>> +prev = NULL;
>> +if (place_holder)
>> +server = NFS_SERVER(place_holder);
>> +else
>> +server = list_entry_rcu(clp->cl_superblocks.next,
>> +struct nfs_server, client_link);
>> +list_for_each_entry_from_rcu(server, &clp->cl_superblocks, client_link)
>> {
>
> Unless I'm missing something, you should define the delegation variable within
> this scope.
I could, yes. But that was true before the patch as well. I don't
really want to change things that I don't need to change.
This is really a style issue. If Trond or Anna prefer the variable in
the most local scope, I'll move it.
>
>> +delegation = NULL;
>> +if (place_holder && server == NFS_SERVER(place_holder))
>> +delegation =
>> rcu_dereference(NFS_I(place_holder)->delegation);
>> +if (!delegation)
>> +delegation = list_entry_rcu(server->delegations.next,
>> +struct nfs_delegation,
>> super_list);
>
> AFAIU, what makes this work is that you expect grabbing the inode
> reference will ensure the entry is not removed from the RCU list until
> the iput().
>
There are two lists, a per "struct nfs_client" list of "struct
nfs_server", and a per "struct nfs_server" list of "struct
nfs_delegation".
I expect that grabbing the
Re: [PATCH 3/3] genalloc: selftest
Hi Igor, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc3 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Igor-Stoppa/linux-next-mm-hardening-Track-genalloc-allocations/20180430-064850 config: i386-tinyconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> init/main.c:94:10: fatal error: linux/test_genalloc.h: No such file or >> directory #include ^~~ compilation terminated. vim +94 init/main.c 13 14 #include 15 #include 16 #include 17 #include 18 #include 19 #include 20 #include 21 #include 22 #include 23 #include 24 #include 25 #include 26 #include 27 #include 28 #include 29 #include 30 #include 31 #include 32 #include 33 #include 34 #include 35 #include 36 #include 37 #include 38 #include 39 #include 40 #include 41 #include 42 #include 43 #include 44 #include 45 #include 46 #include 47 #include 48 #include 49 #include 50 #include 51 #include 52 #include 53 #include 54 #include 55 #include 56 #include 57 #include 58 #include 59 #include 60 #include 61 #include 62 #include 63 #include 64 #include 65 #include 66 #include 67 #include 68 #include 69 #include 70 #include 71 #include 72 #include 73 #include 74 #include 75 #include 76 #include 77 #include 78 #include 79 #include 80 #include 81 #include 82 #include 83 #include 84 #include 85 #include 86 #include 87 #include 88 #include 89 #include 90 #include 91 #include 92 #include 93 #include > 94 #include 95 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v6 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code
On Fri, 2018-04-20 at 13:25 +0800, Honghui Zhang (张洪辉) wrote: > From: Honghui Zhang > > Two fixups for mediatek's host bridge: > The first patch fixup class type and vendor ID for MT7622. > The second patch fixup the IRQ handle routine by using irq_chip solution > to avoid IRQ reentry which may exist for both MT2712 and MT7622. > > Change since v5: > - Make the comments consistend with the code modification in the first patch. > - Using writew to performing a 16-bit write. > - Using irq_chip solution to fix the IRQ issue. > > The v5 patchset could be found in: > https://patchwork.kernel.org/patch/10133303 > https://patchwork.kernel.org/patch/10133305 > > Change since v4: > - Only setup vendor ID for MT7622, igorning the device ID since mediatek's >host bridge driver does not cares about the device ID. > > Change since v3: > - Setup the class type and vendor ID at the beginning of startup instead >of in a quirk. > - Add mediatek's vendor ID, it could be found in: >https://pcisig.com/membership/member-companies?combine=&page=4 > > Change since v2: > - Move the initialize of the iterate before the loop to fix an >INTx IRQ issue in the first patch > > Change since v1: > - Add the second patch. > - Make the first patch's commit message more standard. > Honghui Zhang (2): > PCI: mediatek: Set up vendor ID and class type for MT7622 > PCI: mediatek: Using chained IRQ to setup IRQ handle > > drivers/pci/host/pcie-mediatek.c | 220 > +++ > include/linux/pci_ids.h | 2 + > 2 files changed, 133 insertions(+), 89 deletions(-) Acked-by: Ryder Lee for the series. Thanks
[PATCH resend] VFS: simplify seq_file iteration code and interface
Just resending after 2 weeks silence, in case it fell through a crack.
Thanks,
NeilBrown
("git am -c" understands this line)
--8<-
The documentation for seq_file suggests that it is necessary to be
able to move the iterator to a given offset, however that is not the
case. If the iterator is stored in the private data and is stable
from one read() syscall to the next, it is only necessary to support
first/next interactions. Implementing this in a client is a little
clumsy.
- if ->start() is given a pos of zero, it should go to start of
sequence.
- if ->start() is given the name pos that was given to the most recent
next() or start(), it should restore the iterator to state just
before that last call
- if ->start is given another number, it should set the iterator one
beyond the start just before the last ->start or ->next call.
Also, the documentation says that the implementation can interpret the
pos however it likes (other than zero meaning start), but seq_file
increments the pos sometimes which does impose on the implementation.
This patch simplifies the interface for first/next iteration and
simplifies the code, while maintaining complete backward
compatability. Now:
- if ->start() is given a pos of zero, it should return an iterator
placed at the start of the sequence
- if ->start() is given a non-zero pos, it should return the iterator
in the same state it was after the last ->start or ->next.
This is particularly useful for interators which walk the multiple
chains in a hash table, e.g. using rhashtable_walk*. See
fs/gfs2/glock.c and drivers/staging/lustre/lustre/llite/vvp_dev.c
A large part of achieving this is to *always* call ->next after ->show
has successfully stored all of an entry in the buffer. Never just
increment the index instead.
Also:
- always pass &m->index to ->start() and ->next(), never a temp
variable
- don't clear ->from when ->count is zero, as ->from is dead when
->count is zero.
Some ->next functions do not increment *pos when they return NULL.
To maintain compatability with this, we still need to increment
m->index in one place, if ->next didn't increment it.
Note that such ->next functions are buggy and should be fixed.
A simple demonstration is
dd if=/proc/swaps bs=1000 skip=1
Choose any block size larger than the size of /proc/swaps.
This will always show the whole last line of /proc/swaps.
This patch doesn't work around buggy next() functions for this case.
Signed-off-by: NeilBrown
---
Documentation/filesystems/seq_file.txt | 63 ++
fs/seq_file.c | 53 +++-
2 files changed, 62 insertions(+), 54 deletions(-)
diff --git a/Documentation/filesystems/seq_file.txt
b/Documentation/filesystems/seq_file.txt
index 9de4303201e1..d412b236a9d6 100644
--- a/Documentation/filesystems/seq_file.txt
+++ b/Documentation/filesystems/seq_file.txt
@@ -66,23 +66,39 @@ kernel 3.10. Current versions require the following update
The iterator interface
-Modules implementing a virtual file with seq_file must implement a simple
-iterator object that allows stepping through the data of interest.
-Iterators must be able to move to a specific position - like the file they
-implement - but the interpretation of that position is up to the iterator
-itself. A seq_file implementation that is formatting firewall rules, for
-example, could interpret position N as the Nth rule in the chain.
-Positioning can thus be done in whatever way makes the most sense for the
-generator of the data, which need not be aware of how a position translates
-to an offset in the virtual file. The one obvious exception is that a
-position of zero should indicate the beginning of the file.
+Modules implementing a virtual file with seq_file must implement an
+iterator object that allows stepping through the data of interest
+during a "session" (roughly one read() system call). If the iterator
+is able to move to a specific position - like the file they implement,
+though with freedom to map the position number to a sequence location
+in whatever way is convenient - the iterator need only exist
+transiently during a session. If the iterator cannot easily find a
+numerical position but works well with a first/next interface, the
+iterator can be stored in the private data area and continue from one
+session to the next.
+
+A seq_file implementation that is formatting firewall rules from a
+table, for example, could provide a simple iterator that interprets
+position N as the Nth rule in the chain. A seq_file implementation
+that presents the content of a, potentially volatile, linked list
+might record a pointer into that list, providing that can be done
+without risk of the current location being removed.
+
+Positioning can thus be done in whatever way makes the most sense for
+the generator of the data, which need not be aware of how a position
+translates to an offset in th
Re: [PATCH] vhost: make msg padding explicit
From: "Michael S. Tsirkin" Date: Fri, 27 Apr 2018 19:02:05 +0300 > There's a 32 bit hole just after type. It's best to > give it a name, this way compiler is forced to initialize > it with rest of the structure. > > Reported-by: Kevin Easton > Signed-off-by: Michael S. Tsirkin Who applied this, me? :-)
Re: [PATCH v4 net-next 0/2] tcp: mmap: rework zerocopy receive
From: Eric Dumazet Date: Fri, 27 Apr 2018 08:58:07 -0700 > syzbot reported a lockdep issue caused by tcp mmap() support. > > I implemented Andy Lutomirski nice suggestions to resolve the > issue and increase scalability as well. > > First patch is adding a new getsockopt() operation and changes mmap() > behavior. > > Second patch changes tcp_mmap reference program. > > v4: tcp mmap() support depends on CONFIG_MMU, as kbuild bot told us. > > v3: change TCP_ZEROCOPY_RECEIVE to be a getsockopt() option > instead of setsockopt(), feedback from Ka-Cheon Poon > > v2: Added a missing page align of zc->length in tcp_zerocopy_receive() > Properly clear zc->recv_skip_hint in case user request was completed. Looks great, series applied, thanks Eric.
Re: linux-next: manual merge of the usb tree with the usb.current tree
Hi all,
On Mon, 23 Apr 2018 13:04:44 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the usb tree got a conflict in:
>
> drivers/usb/core/hcd.c
>
> between commit:
>
> 63cb03f5c11e ("usb: core: split usb_phy_roothub_{init,alloc}")
>
> from the usb.current tree and commit:
>
> bc40f5341741 ("USB: core: hcd: drop support for legacy phys")
>
> from the usb tree.
>
> I fixed it up (see below - though I am not sure what happens to the
> phy_roothub allocation when usb_phy_roothub_init fails) and can carry
> the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/usb/core/hcd.c
> index 0a42c5df3c0f,ac5bcf449d7d..
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@@ -2742,35 -2740,11 +2743,15 @@@ int usb_add_hcd(struct usb_hcd *hcd
> int retval;
> struct usb_device *rhdev;
>
> - if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->skip_phy_initialization) {
> - struct usb_phy *phy = usb_get_phy_dev(hcd->self.sysdev, 0);
> -
> - if (IS_ERR(phy)) {
> - retval = PTR_ERR(phy);
> - if (retval == -EPROBE_DEFER)
> - return retval;
> - } else {
> - retval = usb_phy_init(phy);
> - if (retval) {
> - usb_put_phy(phy);
> - return retval;
> - }
> - hcd->usb_phy = phy;
> - hcd->remove_phy = 1;
> - }
> - }
> -
> if (!hcd->skip_phy_initialization && usb_hcd_is_primary_hcd(hcd)) {
> -hcd->phy_roothub = usb_phy_roothub_init(hcd->self.sysdev);
> +hcd->phy_roothub = usb_phy_roothub_alloc(hcd->self.sysdev);
> - if (IS_ERR(hcd->phy_roothub)) {
> - retval = PTR_ERR(hcd->phy_roothub);
> - goto err_phy_roothub_alloc;
> - }
> + if (IS_ERR(hcd->phy_roothub))
> + return PTR_ERR(hcd->phy_roothub);
>
> +retval = usb_phy_roothub_init(hcd->phy_roothub);
> +if (retval)
> - goto err_phy_roothub_alloc;
> ++return retval;
> +
> retval = usb_phy_roothub_power_on(hcd->phy_roothub);
> if (retval)
> goto err_usb_phy_roothub_power_on;
This is now a conflict between the battery tree (since it merged the
usb tree) and Linus' tree (since it merged the usb.current tree).
--
Cheers,
Stephen Rothwell
pgpylkKm1dsNZ.pgp
Description: OpenPGP digital signature
[PATCH] ethtool: fix a potential missing-check bug
In ethtool_get_rxnfc(), the object "info" is firstly copied from
user-space. If the FLOW_RSS flag is set in the member field flow_type of
"info" (and cmd is ETHTOOL_GRXFH), info needs to be copied again from
user-space because FLOW_RSS is newer and has new definition, as mentioned
in the comment. However, given that the user data resides in user-space, a
malicious user can race to change the data after the first copy. By doing
so, the user can inject inconsistent data. For example, in the second
copy, the FLOW_RSS flag could be cleared in the field flow_type of "info".
In the following execution, "info" will be used in the function
ops->get_rxnfc(). Such inconsistent data can potentially lead to unexpected
information leakage since ops->get_rxnfc() will prepare various types of
data according to flow_type, and the prepared data will be eventually
copied to user-space. This inconsistent data may also cause undefined
behaviors based on how ops->get_rxnfc() is implemented.
This patch re-verifies the flow_type field of "info" after the second copy.
If the value is not as expected, an error code will be returned.
Signed-off-by: Wenwen Wang
---
net/core/ethtool.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 03416e6..a121034 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1032,6 +1032,8 @@ static noinline_for_stack int ethtool_get_rxnfc(struct
net_device *dev,
info_size = sizeof(info);
if (copy_from_user(&info, useraddr, info_size))
return -EFAULT;
+ if (!(info.flow_type & FLOW_RSS))
+ return -EINVAL;
}
if (info.cmd == ETHTOOL_GRXCLSRLALL) {
--
2.7.4
Re: [PATCH net-next 0/3] net: dsa: mv88e6xxx: remove Global 2 setup
From: Vivien Didelot Date: Thu, 26 Apr 2018 21:56:43 -0400 > Parts of the mv88e6xxx driver still write arbitrary registers of > different banks at setup time, which is misleading especially when > supporting multiple device models. > > This patchset moves two features setup into the top lovel > mv88e6xxx_setup function and kills the old Global 2 register bank setup > function. It brings no functional changes. Series applied, thanks Vivien.
WARNING in md_ioctl
Hello, syzbot hit the following crash on upstream commit c61a56ababa404961fa769a2b24229f18e461961 (Sun Apr 29 17:06:05 2018 +) Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=1e46a0864c1a6e9bd3d8 C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5771999158730752 syzkaller reproducer: https://syzkaller.appspot.com/x/repro.syz?id=6399853584187392 Raw console output: https://syzkaller.appspot.com/x/log.txt?id=6389218171420672 Kernel config: https://syzkaller.appspot.com/x/.config?id=4617060493481910265 compiler: gcc (GCC) 8.0.1 20180413 (experimental) IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1e46a0864c1a6e9bd...@syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. See footer for details. If you forward the report, please keep this part and the footer. random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) md: md0 stopped. md: md0 stopped. WARNING: CPU: 1 PID: 4511 at drivers/md/md.c:7188 md_ioctl+0x3427/0x6360 drivers/md/md.c:7188 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 4511 Comm: syz-executor107 Not tainted 4.17.0-rc2+ #24 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 panic+0x22f/0x4de kernel/panic.c:184 __warn.cold.8+0x163/0x1b3 kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992 RIP: 0010:md_ioctl+0x3427/0x6360 drivers/md/md.c:7188 RSP: 0018:8801ad9b7400 EFLAGS: 00010293 RAX: 8801acf7a540 RBX: 0932 RCX: 8565f354 RDX: RSI: 85661c37 RDI: 0007 RBP: 8801ad9b79c0 R08: 8801acf7a540 R09: ed0039894699 R10: 8801ad9b73f0 R11: 8801cc4a34cf R12: 0932 R13: 8801cc4a3328 R14: 8801ad9b7998 R15: 0001 __blkdev_driver_ioctl block/ioctl.c:303 [inline] blkdev_ioctl+0x9b6/0x2020 block/ioctl.c:601 block_ioctl+0xee/0x130 fs/block_dev.c:1877 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:500 [inline] do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701 __do_sys_ioctl fs/ioctl.c:708 [inline] __se_sys_ioctl fs/ioctl.c:706 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:706 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x445a59 RSP: 002b:7f00dd147da8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: RCX: 00445a59 RDX: 2080 RSI: 0932 RDI: 0003 RBP: 006dac3c R08: 7f00dd148700 R09: R10: 7f00dd148700 R11: 0246 R12: 006dac38 R13: 30646d2f7665642f R14: 7f00dd1489c0 R15: 0003 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a dumb bot. It may contain errors. See https://goo.gl/tpsmEJ for details. Direct all questions to syzkal...@googlegroups.com. syzbot will keep track of this bug report. If you forgot to add the Reported-by tag, once the fix for this bug is merged into any tree, please reply to this email with: #syz fix: exact-commit-title If you want to test a patch for this bug, please reply with: #syz test: git://repo/address.git branch and provide the patch inline or as an attachment. To mark this as a duplicate of another syzbot report, please reply with: #syz dup: exact-subject-of-another-report If it's a one-off invalid bug report, please reply with: #syz invalid Note: if the crash happens again, it will cause creation of a new bug report. Note: all commands must start from beginning of the line in the email body.
linux-next: manual merge of the ipsec-next tree with the net-next tree
Hi all,
Today's linux-next merge of the ipsec-next tree got a conflict in:
net/ipv4/ip_output.c
between commit:
bec1f6f69736 ("udp: generate gso with UDP_SEGMENT")
from the net-next tree and commit:
cd027a5433d6 ("udp: enable UDP checksum offload for ESP")
from the ipsec-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/ip_output.c
index f2338e40c37d,a2dfb5a9ba76..
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@@ -909,8 -906,8 +909,8 @@@ static int __ip_append_data(struct soc
if (transhdrlen &&
length + fragheaderlen <= mtu &&
rt->dst.dev->features & (NETIF_F_HW_CSUM | NETIF_F_IP_CSUM) &&
- !(flags & MSG_MORE) &&
+ (!(flags & MSG_MORE) || cork->gso_size) &&
- !exthdrlen)
+ (!exthdrlen || (rt->dst.dev->features & NETIF_F_HW_ESP_TX_CSUM)))
csummode = CHECKSUM_PARTIAL;
cork->length += length;
pgpB0ugoU7JD2.pgp
Description: OpenPGP digital signature
Re: Linux messages full of `random: get_random_u32 called from`
On 04/29/2018 03:05 PM, Theodore Y. Ts'o wrote: What would be useful is if people gave reports that listed exactly what laptop and distributions they are using. Just "a high spec x86 laptop" isn't terribly useful, because*my* brand-new Dell XPS 13 running Debian testing is working just fine. The year, model, make, and CPU type plus what distribution (and distro version number) you are running is useful, so I can assess how wide spread the unhappiness is going to be, and what mitigation steps make sense. I'm pretty sure Fedora is hitting this in our VMs. I just spent some time debugging an issue of a boot delay with someone from the infrastructure team where it would take upwards of 2 minutes to boot. If someone holds down a key, it boots in 4 seconds. There's a qemu reproducer at https://bugzilla.redhat.com/show_bug.cgi?id=1572916#c3 I suggested a cat on the keyboard as a workaround. Independently, we also got a report of a boot hang in GCE with 4.16.4 where as 4.16.3 works which corresponds to the previous report of a stable regression. This was just via IRC so I didn't have time to dig into this. Thanks, Laura
Re: Linux messages full of `random: get_random_u32 called from`
On Sun, Apr 29, 2018 at 07:07:29PM -0400, Dave Jones wrote: > > Why do we continue to print this stuff out when crng_init=1 though ? > > answering my own question, I think.. This is a tristate, and we need it > to be >1 to be quiet, which doesn't happen until.. > > > [ 165.806247] random: crng init done > > this point. Right. What happens is that we divert the first 64 bits of entropy credits directly into the crng state, without initializing the input_pool. So when we hit crng_init=1, the crng has only 64 bits of entropy (conservatively speaking); furthermore, since we aren't doing catastrophic reseeding, if something is continuously reading from /dev/urandom or get_random_bytes() during that time, then the attacker could be able to detremine which one of the 32 states the entropy pool was when the entropy count was 5, and then 5 bits later, poll the output of the pool again, and guess which of the 32 states the pool was in, etc., and effectively keep up with the entropy as it trickles in. This is the reasoning behind catastrophic reseeding; we wait until we have 128 bits of entropy in the input pool, and then we reseed the pool all at once. Why do we have the crng_init=1 state? Because it provides some basic protection for super-early users of the entropy pool. It's essentially a bandaid, and we could improve the time to get to fully initialize by about 33% if we left the pool totally unititalized and only focused on filling the input pool. But given that on many distributions, ssh still insists on initializing long-term public keys at first boot from /dev/urandom, instead of *waiting* until the first time someone attempts to ssh into box, or waiting until getrandom(2) doesn't block --- without hanging the boot --- we have the crng_init=1 hack essentially as a palliative. I view this as working around broken user space. But userspace has been broken for a long time, and users tend to blame the kernel, not userspace - Ted
Re: Linux messages full of `random: get_random_u32 called from`
On Sun, Apr 29, 2018 at 03:49:28PM -0700, Sultan Alsawaf wrote: > On Mon, Apr 30, 2018 at 12:43:48AM +0200, Jason A. Donenfeld wrote: > > > - if ((fast_pool->count < 64) && > > > - !time_after(now, fast_pool->last + HZ)) > > > - return; > > > - > > > > I suspect you still want the rate-limiting in place. But if you _do_ > > want to cheat like this, you could instead just modify the condition > > to only relax the rate limiting when !crng_init(). > > Good idea. Attached a new patch that's less intrusive. It still fixes my > issue, > of course. What your patch does is assume that there is a full bit of uncertainty that can be obtained from the information gathered from each interrupt. I *might* be willing to assume that to be valid on x86 systems that have a high resolution cycle counter. But on ARM platforms, especially during system bootup when the user isn't typing anything and SSD's and flash storage tend to have very predictable timing patterns? Not a bet I'd be willing to take. Even with a cycle counter, there's a reason why we assumed that we need to mix in timing results from 64 interrupts or one second's worth before we would give a single bit's worth of entropy credit. - Ted
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
tools/testing/selftests/net/Makefile
between commit:
9faedd643fd9 ("selftests: net: add in_netns.sh TEST_GEN_PROGS_EXTENDED")
from the net tree and commit:
a160725780e3 ("selftests: udp gso")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/testing/selftests/net/Makefile
index daf5effec3f0,df9102ec7b7a..
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@@ -5,12 -5,14 +5,15 @@@ CFLAGS = -Wall -Wl,--no-as-needed -O2
CFLAGS += -I../../../../usr/include/
TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh
rtnetlink.sh
- TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh
-TEST_PROGS += fib_tests.sh fib-onlink-tests.sh in_netns.sh pmtu.sh udpgso.sh
++TEST_PROGS += fib_tests.sh fib-onlink-tests.sh pmtu.sh udpgso.sh
+ TEST_PROGS += udpgso_bench.sh
+TEST_GEN_PROGS_EXTENDED := in_netns.sh
TEST_GEN_FILES = socket
TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
+ TEST_GEN_FILES += tcp_mmap
TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict
+ TEST_GEN_PROGS += udpgso udpgso_bench_tx udpgso_bench_rx
include ../lib.mk
pgpQAJbgTlv5e.pgp
Description: OpenPGP digital signature
Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")
On Sun, Apr 29, 2018 at 12:15:11PM +0200, Rafał Miłecki wrote: > On 29 April 2018 at 07:26, Greg Kroah-Hartman > wrote: > > On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote: > >> Due to some maintainers *preferring* BSD-compatible license for DTS > >> files [0], I was writing mine using ISC. I had no very special reason > >> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen > >> ISC as I read about its "removal of language deemed unnecessary". > >> > >> I took a moment to look at the new SPDX thing and noticed that: > >> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example > > > > Yeah, bad example, we should fix that text up. Care to send a patch? :) > > Sure. I see that license-rules.rst also refers to LICENSES/other/ZLib > which also doesn't exist. > > As "other" directory contains only GPL-1.0 and MPL-1.1 I guess one of > these should be referenced. See the patch set that Thomas has posted to hopefully resolve these issues. I think they are all now taken care of with that series. > >> 2) License file LICENSES/other/ISC doesn't exist > >> 3) ISC is listed as an *example* under the "Not recommended licenses" > > > > Yes, please don't use it if at all possible. > > > >> First of all, as ISC is used by some files in the Linux kernel, I > >> think it's worth adding to the LICENSE/*/ISC. > > > > I see it is only used in a very small number of dts files. Why not just > > use BSD-2-Clause instead? What do you find in ISC that is not available > > to you with just BSD? > > As said, I read about its "removal of language deemed unnecessary". I > assumed that the simpler license text the better. Simple up to a point, having loads of different licenses is a mess, as you are finding out :) > >> Secondly, it isn't 100% clear to me if ISC is preferred or not > >> recommended. File license-rules.rst suggests the later by listing it > >> as an example for "Not recommended". It's just an example though, so > >> I'm not 100% sure without seeing it in either: "preferred" or "other" > >> directories. Also if anyone finds it "Not recommended", can we get a > >> short explanation why is it so, please? > > > > The license is functionally equalivant to BSD-2, so why would you want > > to add more complexity here and have two licenses that are the same be > > "recommended"? > > I don't insist on it, I'm trying to figure out what's the best for the > Linux community. > > On the other hand I could ask why do we want more complexity by having > MIT license. It's very similar to the BSD-2-Clause after all. AFAIK > the only minor differences are that: > 1) MIT clearly allows sublicensing > 2) BSD 2-Clause clearly requires distributing *binaries* with > copyrights + license text I think you will find more dual-licensed MIT code in the tree already than ISC, right? And really, in the end, the odds of someone taking this code _out_ of the tree and using it only under a non-GPLv2 license is slim, to none, so it's best to just stick with the common licenses, as long as they match what you wish the code to abide by. As you want to follow what MIT says, then just use that and all should be good, right? thanks, greg k-h
Re: [PATCH v2] input/touchscreen: atmel_mxt_ts: Add correct touchpad button mapping for the Caroline Chromebook.
Hello,
On 26/04/2018 18:42:18 CEST, Dmitry Torokhov wrote:
> On Thu, Apr 26, 2018 at 06:45:32AM -0700, Guenter Roeck wrote:
>> On Wed, Apr 25, 2018 at 10:37 PM, Vittorio Gambaletta (VittGam) <
>> linuxb...@vittgam.net> wrote:
>>
>> > Hello,
>> >
>> > On 26/04/2018 00:57:34 CEST, Dmitry Torokhov wrote:
>> > > On Wed, Apr 25, 2018 at 03:26:50PM -0700, Dmitry Torokhov wrote:
>> > >> On Wed, Apr 25, 2018 at 02:32:58PM +0200, Vittorio Gambaletta (VittGam)
>> > wrote:
>> > >> > This patch adds the correct platform data information for the Caroline
>> > >> > Chromebook, so that the mouse button does not get stuck in pressed
>> > state
>> > >> > after the first click.
>> > >> >
>> > >> > The Samus button keymap and platform data definition are the correct
>> > >> > ones for Caroline, so they have been reused here.
>> > >> >
>> > >> > v2: updated patch offset after 20180409 changes.
>> > >> >
>> > >> > Cc: sta...@vger.kernel.org
>> > >> > Signed-off-by: Vittorio Gambaletta
>> > >> > Signed-off-by: Salvatore Bellizzi
>> > >> >
>> > >>
>> > >> Applied, thank you.
>> > >>
>> > >> > ---
>> > >> >
>> > >> > --- a/drivers/input/touchscreen/atmel_mxt_ts.c
>> > >> > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
>> > >> > @@ -3035,6 +3035,15 @@
>> > >> >.driver_data = samus_platform_data,
>> > >> >},
>> > >> >{
>> > >> > + /* Samsung Chromebook Pro */
>> > >> > + .ident = "Samsung Chromebook Pro",
>> > >> > + .matches = {
>> > >> > + DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),
>> > >
>> > > I've been alerted that shipping BIOS has vendor not capitalized; where
>> > > did you get the firmware that has vendor all capitals?
>> >
>> > Upstream coreboot and mrchromebox's coreboot, which do support loading
>> > Linux
>> > natively or with UEFI, both use capitalized GOOGLE as DMI System Vendor
>> > as far as I know.
>> >
>> > By the way, the shipping BIOS (coreboot customized by Google) does not
>> > support
>> > mainline Linux natively (eg. without seabios and nasty tricks), but only
>> > Chromium OS, which for Caroline is an old 3.something fork of Linux, so
>> > this
>> > patch does not really apply to Chromium OS or to Linux running on shipping
>> > BIOS.
>> >
>> Can you provide details or a pointer to it ? The mainline kernel boots
>> fine for me (with a ChromeOS distribution), with the exception of the
>> Google/GOOGLE problem.
Hmmm, did you change the kernel on your ChromeOS system, or did Google update
it?
My Chromebook was on 3.18 when I was still having stock Google Chrome OS on it.
This should be the relevant tree:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/release-R58-9334.B-caroline-chromeos-3.18
>> > Anyway if I recall correctly, the DMI System Vendor should be GOOGLE in
>> > Google's coreboot for Caroline too, but I'm not 100% sure and cannot check
>> > right now.
>> >
>> >
>> FWIW, the DMI system vendor is "Google" in my Caroline. I'll dig up
>> configuration files later today - maybe it was changed to "GOOGLE" at some
>> point and I have an old Bios in my system.
>
> I believe all shipping BIOSes use "Google" as vendor, as it is what is
> specified in src/mainboard/google/Kconfig::MAINBOARD_VENDOR and our
> configs/build scripts do not override it.
>
> I do not know why we have this difference.
Okay, so first of all sorry for the confusion.
The upstream coreboot still does not have Caroline support as far as I can tell.
Instead, I'm using coreboot by Matt aka Mr. Chromebox, who is working towards
upstreaming all of Google Skylake boards, such as Caroline, into coreboot.
His default configs were overriding the CONFIG_MAINBOARD_SMBIOS_MANUFACTURER
option as "GOOGLE" for every board, including recent ones which started to
use "Google". I've contacted him about this, and at the end he will change
the string back to "Google".
>> Thanks,
>> Guenter
>>
>> By the way please note that this is the DMI System Vendor and not the DMI
>> > BIOS version string, which indeed starts with "Google_" in the shipping
>> > BIOS
>> > (but not in coreboot, see f56db262e46d3368ee4e5c9e19797853cab382cd).
>
> Hmm, I just tried checking out tree from
> https://review.coreboot.org/coreboot.git and do not see this commit:
>
> dtor@dtor-ws:~/coreboot $ git show f56db262e46d3368ee4e5c9e19797853cab382cd
> fatal: bad object f56db262e46d3368ee4e5c9e19797853cab382cd
> dtor@dtor-ws:~/coreboot $ git log --oneline -1 HEAD
> 82d0f91420 (HEAD -> master, origin/master, origin/HEAD) soc/intel/apollolake:
> enable exception handling in every stage for glk
Sorry, this was a Linux commit hash:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f56db262e46d3368ee4e5c9e19797853cab382cd
> Anyway, if you are overriding the shipping BIOS, then please adjust
> coreboot to use device-tree compatible bindings (via PRP0001 HID and
> _DSD properties - you can check out bindings for PENH device in Caroline
> to see how they can be used). This
Re: Moving unmaintained filesystems to staging
On Sun, Apr 29, 2018 at 10:07:26PM +0200, Ondrej Zary wrote: > On Sunday 29 April 2018 14:07:05 Greg KH wrote: > > On Thu, Apr 26, 2018 at 08:11:08AM +0200, Pavel Machek wrote: > > > On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote: > > > > Recently ncpfs got moved to staging. Also recently, we had some fuzzer > > > > developers report bugs in hfs, which they deem a security hole because > > > > Ubuntu attempts to automount an inserted USB device as hfs. > > > > > > We promise "no-regressions" for code in main repository, no such > > > promise for staging. We have quite a lot of code without maintainer. > > > > > > Moving code to staging means it will get broken -- staging was not > > > designed for this. I believe moving anything there is bad idea. > > > > > > Staging is for ugly code, not for code that needs new maintainter. > > > > Staging is used for getting code _out_ of the kernel tree as well as > > _in_. We use it all the time to move code there, see if anyone shows up > > in 6-8 months to say "I will fix this!", and if not, we delete it. > > > > Look at what just happened to IRDA in the 4.17-rc1 release as an example > > of this. > > Really a "great" example of deleting working code :( What do you mean? The irda code was broken and not working at all. There were loads of bug reports about it for years, with no developers or maintainers willing to do the work on it to get it to actually work again. If someone does want to step up and do it, great! It's a simple revert of two git commits and they are back in business. Dropping code from the tree is not like it is gone for forever. If someone wants to pick it up, it is trivial to do so. Git is good :) thanks, greg k-h
Re: Linux messages full of `random: get_random_u32 called from`
On Sun, Apr 29, 2018 at 07:02:02PM -0400, Dave Jones wrote: > On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: > > > Can you tell me a bit about your system? What distribution, what > > hardware is present in your sytsem (what architecture, what > > peripherals are attached, etc.)? > > > > There's a reason why we made this --- we were declaring the random > > number pool to be fully intialized before it really was, and that was > > a potential security concern. It's not as bad as the weakness > > discovered by Nadia Heninger in 2012. (See https://factorable.net for > > more details.) However, this is not one of those things where we like > > to fool around. > > > > So I want to understand if this is an issue with a particular hardware > > configuration, or whether it's just a badly designed Linux init system > > or embedded setup, or something else. After all, you wouldn't want > > the NSA spying on all of your network traffic, would you? :-) > > Why do we continue to print this stuff out when crng_init=1 though ? answering my own question, I think.. This is a tristate, and we need it to be >1 to be quiet, which doesn't happen until.. > [ 165.806247] random: crng init done this point. Dave
Re: Linux messages full of `random: get_random_u32 called from`
On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: > Can you tell me a bit about your system? What distribution, what > hardware is present in your sytsem (what architecture, what > peripherals are attached, etc.)? > > There's a reason why we made this --- we were declaring the random > number pool to be fully intialized before it really was, and that was > a potential security concern. It's not as bad as the weakness > discovered by Nadia Heninger in 2012. (See https://factorable.net for > more details.) However, this is not one of those things where we like > to fool around. > > So I want to understand if this is an issue with a particular hardware > configuration, or whether it's just a badly designed Linux init system > or embedded setup, or something else. After all, you wouldn't want > the NSA spying on all of your network traffic, would you? :-) Why do we continue to print this stuff out when crng_init=1 though ? (This from debian stable, on a pretty basic atom box, but similar dmesg's on everything else I've put 4.17-rc on so far) [0.00] random: get_random_bytes called from start_kernel+0x96/0x519 with crng_init=0 [0.00] random: get_random_u64 called from __kmem_cache_create+0x39/0x450 with crng_init=0 [0.00] random: get_random_u64 called from cache_random_seq_create+0x76/0x120 with crng_init=0 [0.151401] calling initialize_ptr_random+0x0/0x36 @ 1 [0.151527] initcall initialize_ptr_random+0x0/0x36 returned 0 after 0 usecs [0.294661] calling prandom_init+0x0/0xbd @ 1 [0.294763] initcall prandom_init+0x0/0xbd returned 0 after 0 usecs [1.430529] _warn_unseeded_randomness: 165 callbacks suppressed [1.430540] random: get_random_u64 called from __kmem_cache_create+0x39/0x450 with crng_init=0 [1.430860] random: get_random_u64 called from cache_random_seq_create+0x76/0x120 with crng_init=0 [1.452240] random: get_random_u64 called from copy_process.part.67+0x1ae/0x1e60 with crng_init=0 [2.954901] _warn_unseeded_randomness: 54 callbacks suppressed [2.954910] random: get_random_u64 called from __kmem_cache_create+0x39/0x450 with crng_init=0 [2.955185] random: get_random_u64 called from cache_random_seq_create+0x76/0x120 with crng_init=0 [2.957701] random: get_random_u64 called from __kmem_cache_create+0x39/0x450 with crng_init=0 [6.017364] _warn_unseeded_randomness: 88 callbacks suppressed [6.017373] random: get_random_u64 called from __kmem_cache_create+0x39/0x450 with crng_init=0 [6.042652] random: get_random_u64 called from cache_random_seq_create+0x76/0x120 with crng_init=0 [6.060333] random: get_random_u64 called from __kmem_cache_create+0x39/0x450 with crng_init=0 [6.951978] calling prandom_reseed+0x0/0x2a @ 1 [6.960627] initcall prandom_reseed+0x0/0x2a returned 0 after 105 usecs [7.371745] _warn_unseeded_randomness: 37 callbacks suppressed [7.371759] random: get_random_u64 called from arch_pick_mmap_layout+0x64/0x130 with crng_init=0 [7.395926] random: get_random_u64 called from load_elf_binary+0x4ae/0x1720 with crng_init=0 [7.411549] random: get_random_u32 called from arch_align_stack+0x37/0x50 with crng_init=0 [7.553379] random: systemd-udevd: uninitialized urandom read (16 bytes read) [7.563210] random: systemd-udevd: uninitialized urandom read (16 bytes read) [7.571498] random: systemd-udevd: uninitialized urandom read (16 bytes read) [8.449679] _warn_unseeded_randomness: 154 callbacks suppressed [8.449691] random: get_random_u64 called from copy_process.part.67+0x1ae/0x1e60 with crng_init=0 [8.483097] random: get_random_u64 called from arch_pick_mmap_layout+0x64/0x130 with crng_init=0 [8.497999] random: get_random_u64 called from load_elf_binary+0x4ae/0x1720 with crng_init=0 [9.353904] random: fast init done [9.770384] _warn_unseeded_randomness: 187 callbacks suppressed [9.770398] random: get_random_u32 called from bucket_table_alloc+0x84/0x1b0 with crng_init=1 [9.791514] random: get_random_u32 called from new_slab+0x174/0x680 with crng_init=1 [9.834909] random: get_random_u64 called from copy_process.part.67+0x1ae/0x1e60 with crng_init=1 [ 10.802200] _warn_unseeded_randomness: 168 callbacks suppressed [ 10.802214] random: get_random_u64 called from arch_pick_mmap_layout+0x64/0x130 with crng_init=1 [ 10.802276] random: get_random_u64 called from load_elf_binary+0x4ae/0x1720 with crng_init=1 [ 10.802289] random: get_random_u32 called from arch_align_stack+0x37/0x50 with crng_init=1 [ 11.821109] _warn_unseeded_randomness: 160 callbacks suppressed [ 11.821122] random: get_random_u64 called from copy_process.part.67+0x1ae/0x1e60 with crng_init=1 [ 11.863770] random: get_random_u32 called from bucket_table_alloc+0x84/0x1b0 with crng_init=1 [ 11.869384] random: get_random_u32 called from new_slab+0x174/0x680 with crng_init=1 [ 12.843237] _warn_unseeded_rando
Re: Linux messages full of `random: get_random_u32 called from`
On Mon, Apr 30, 2018 at 12:43:48AM +0200, Jason A. Donenfeld wrote: > > - if ((fast_pool->count < 64) && > > - !time_after(now, fast_pool->last + HZ)) > > - return; > > - > > I suspect you still want the rate-limiting in place. But if you _do_ > want to cheat like this, you could instead just modify the condition > to only relax the rate limiting when !crng_init(). Good idea. Attached a new patch that's less intrusive. It still fixes my issue, of course. Sultan >From 6870b0383b88438d842599aa8608a260e6fb0ed2 Mon Sep 17 00:00:00 2001 From: Sultan Alsawaf Date: Sun, 29 Apr 2018 15:44:27 -0700 Subject: [PATCH] random: don't ratelimit add_interrupt_randomness() until crng is ready --- drivers/char/random.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 38729baed6ee..8c00c008e797 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1201,7 +1201,7 @@ void add_interrupt_randomness(int irq, int irq_flags) } if ((fast_pool->count < 64) && - !time_after(now, fast_pool->last + HZ)) + !time_after(now, fast_pool->last + HZ) && crng_ready()) return; r = &input_pool; -- 2.14.1
Attention
-- Hello, I am British Citizen working with a Multinational Company based in Québec, Canada/USA . There is a viable opportunity in our company I requires your cooperation or you recommend someone you trust to carry out in your region. The opportunity will not interfere with your present job as it doesn't matter your area of specialization. Should you desire to know more about the opportunity, Write me back to provide you the details of the offer. Thanks and Regards, Allen Mellor
Re: Linux messages full of `random: get_random_u32 called from`
> - if ((fast_pool->count < 64) && > - !time_after(now, fast_pool->last + HZ)) > - return; > - I suspect you still want the rate-limiting in place. But if you _do_ want to cheat like this, you could instead just modify the condition to only relax the rate limiting when !crng_init().
Re: Linux messages full of `random: get_random_u32 called from`
Hi! > What would be useful is if people gave reports that listed exactly > what laptop and distributions they are using. Just "a high spec x86 > laptop" isn't terribly useful, because *my* brand-new Dell XPS 13 > running Debian testing is working just fine. The year, model, make, > and CPU type plus what distribution (and distro version number) you > are running is useful, so I can assess how wide spread the unhappiness > is going to be, and what mitigation steps make sense. Thinkpad X60, model name : Genuine Intel(R) CPU T2400 @ 1.83GHz pavel@amd:~$ cat /etc/debian_version 8.10 I already posted some dmesg snippets, but system boots. On _this_ boot, it was ok, and I do not see anything: pavel@amd:/data/l/linux-next-32$ dmesg | grep urandom pavel@amd:/data/l/linux-next-32$ Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 3/3] genalloc: selftest
On 29/04/18 07:36, Randy Dunlap wrote: On 04/28/2018 07:45 PM, Igor Stoppa wrote: [...] + test_genalloc(); Is there a stub for test_genalloc() when its config option is not enabled? I don't see it. I failed to add to the patch include/linux/test_genalloc.h :-/ That's where the stub is hiding. diff --git a/lib/Kconfig b/lib/Kconfig index 09565d779324..2bf89af50728 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -303,6 +303,21 @@ config DECOMPRESS_LZ4 config GENERIC_ALLOCATOR bool These TEST_ kconfig symbols should be in lib/Kconfig.debug, not lib/Kconfig. ok, I will fix it +config TEST_GENERIC_ALLOCATOR + bool "genalloc tester" + default n + select GENERIC_ALLOCATOR This should depend on GENERIC_ALLOCATOR, not select it. See TEST_PARMAN, TEST_BPF, TEST_FIRMWARE, TEST_SYSCTL, TEST_DEBUG_VIRTUAL in lib/Kconfig.debug. I was actually wondering about this. The dependency I came up with allows to perform the test even if nothing is selecting genalloc, but ok, if this is how it is done, I'll adjust to it. + help + Enable automated testing of the generic allocator. + The testing is primarily for the tracking of allocated space. + +config TEST_GENERIC_ALLOCATOR_VERBOSE + bool "make the genalloc tester more verbose" + default n + select TEST_GENERIC_ALLOCATOR depends on TEST_GENERIC_ALLOCATOR ok [...] + * guarranteed; allowing the boot to continue means risking to corrupt guaranteed; hmmm -- thanks, igor
Re: Linux messages full of `random: get_random_u32 called from`
On Sun, Apr 29, 2018 at 06:05:19PM -0400, Theodore Y. Ts'o wrote:
> It's more accurate to say that using /dev/urandom is no worse than
> before (from a few years ago). There are, alas, plenty of
> distributions and user space application programmers that basically
> got lazy using /dev/urandom, and assumed that there would be plenty of
> entropy during early system startup.
>
> When they switched over the getrandom(2), the most egregious examples
> of this caused pain (and they got fixed), but due to a bug in
> drivers/char/random.c, if getrandom(2) was called after the entropy
> pool was "half initialized", it would not block, but proceed.
>
> Is that exploitable? Well, Jann and I didn't find an _obvious_ way to
> exploit the short coming, which is this wasn't treated like an
> emergency situation ala the embarassing situation we had five years
> ago[1].
>
> [1] https://factorable.net/paper.html
>
> However, it was enough to make us be uncomfortable, which is why I
> pushed the changes that I did. At least on the devices we had at
> hand, using the distributions that we typically use, the impact seemed
> minimal. Unfortuantely, there is no way to know for sure without
> rolling out change and seeing who screams. In the ideal world,
> software would not require cryptographic randomness immediately after
> boot, before the user logs in. And ***really***, as in [1], softwaret
> should not be generating long-term public keys that are essential to
> the security of the box a few seconds immediately after the device is
> first unboxed and plugged in.i
>
> What would be useful is if people gave reports that listed exactly
> what laptop and distributions they are using. Just "a high spec x86
> laptop" isn't terribly useful, because *my* brand-new Dell XPS 13
> running Debian testing is working just fine. The year, model, make,
> and CPU type plus what distribution (and distro version number) you
> are running is useful, so I can assess how wide spread the unhappiness
> is going to be, and what mitigation steps make sense.
>
>
> What mitigations steps can be taken?
>
> If you believe in security-through-complexity (the cache architecture
> of x86 is *so* complicated no one can understand it, so
> Jitterentropy / Haveged *must* be secure), or security-through-secrecy
> (the cache architecture of x86 is only avilable to internal architects
> inside Intel, so Jitterentropy / Haveged *must* be secure, never mind
> that the Intel CPU architects who were asked about it were "nervous"),
> then wiring up CONFIG_JITTERENTROPY or using haveged might be one
> approach.
>
> If you believe that Intel hasn't backdoored RDRAND, then installing
> rng-tools and running rngd with --enable-drng will enable RDRAND.
> That seems to be popular with various defense contractors, perhaps on
> the assumption that if it _was_ backdoored (no one knows for sure), it
> was probably with the connivance or request of the US government, who
> doesn't need to worry about spying on itself.
>
> Or you can use some kind of open hardware design RNG, such as
> ChoasKey[2] from Altus Metrum. But that requires using specially
> ordered hardware plugged into a USB slot, and it's probably not a mass
> solution.
>
> [2] https://altusmetrum.org/ChaosKey/
>
>
> Personally, I prefer fixing the software to simply not require
> cryptographic grade entropy before the user has logged in. Because
> it's better than the alternatives.
>
> - Ted
>
The attached patch fixes my crng init woes. With it, crng init completes 0.86
seconds into boot, but I can't help but feel like a solution this obvious would
just expose my Richard Stallman photo collection to prying eyes at the NSA.
Thoughts on the patch?
Sultan
>From 597b0f2b3c986f853bf1d30a7fb9d76869e47fe8 Mon Sep 17 00:00:00 2001
From: Sultan Alsawaf
Date: Sun, 29 Apr 2018 15:22:59 -0700
Subject: [PATCH] random: remove ratelimiting from add_interrupt_randomness()
---
drivers/char/random.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 38729baed6ee..5b38277b104a 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -574,7 +574,6 @@ static void mix_pool_bytes(struct entropy_store *r, const
void *in,
struct fast_pool {
__u32 pool[4];
- unsigned long last;
unsigned short reg_idx;
unsigned char count;
};
@@ -1195,20 +1194,14 @@ void add_interrupt_randomness(int irq, int irq_flags)
crng_fast_load((char *) fast_pool->pool,
sizeof(fast_pool->pool))) {
fast_pool->count = 0;
- fast_pool->last = now;
}
return;
}
- if ((fast_pool->count < 64) &&
- !time_after(now, fast_pool->last + HZ))
- return;
-
r = &input_pool;
if (!spin_trylock(&r->lock))
Re: Linux messages full of `random: get_random_u32 called from`
On Sun, Apr 29, 2018 at 01:20:33PM -0700, Sultan Alsawaf wrote: > On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote: > > Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE > > Okay, but /dev/urandom isn't a solution to this problem because it isn't > usable > until crng init is complete, so it suffers from the same init lag as > /dev/random. It's more accurate to say that using /dev/urandom is no worse than before (from a few years ago). There are, alas, plenty of distributions and user space application programmers that basically got lazy using /dev/urandom, and assumed that there would be plenty of entropy during early system startup. When they switched over the getrandom(2), the most egregious examples of this caused pain (and they got fixed), but due to a bug in drivers/char/random.c, if getrandom(2) was called after the entropy pool was "half initialized", it would not block, but proceed. Is that exploitable? Well, Jann and I didn't find an _obvious_ way to exploit the short coming, which is this wasn't treated like an emergency situation ala the embarassing situation we had five years ago[1]. [1] https://factorable.net/paper.html However, it was enough to make us be uncomfortable, which is why I pushed the changes that I did. At least on the devices we had at hand, using the distributions that we typically use, the impact seemed minimal. Unfortuantely, there is no way to know for sure without rolling out change and seeing who screams. In the ideal world, software would not require cryptographic randomness immediately after boot, before the user logs in. And ***really***, as in [1], softwaret should not be generating long-term public keys that are essential to the security of the box a few seconds immediately after the device is first unboxed and plugged in.i What would be useful is if people gave reports that listed exactly what laptop and distributions they are using. Just "a high spec x86 laptop" isn't terribly useful, because *my* brand-new Dell XPS 13 running Debian testing is working just fine. The year, model, make, and CPU type plus what distribution (and distro version number) you are running is useful, so I can assess how wide spread the unhappiness is going to be, and what mitigation steps make sense. What mitigations steps can be taken? If you believe in security-through-complexity (the cache architecture of x86 is *so* complicated no one can understand it, so Jitterentropy / Haveged *must* be secure), or security-through-secrecy (the cache architecture of x86 is only avilable to internal architects inside Intel, so Jitterentropy / Haveged *must* be secure, never mind that the Intel CPU architects who were asked about it were "nervous"), then wiring up CONFIG_JITTERENTROPY or using haveged might be one approach. If you believe that Intel hasn't backdoored RDRAND, then installing rng-tools and running rngd with --enable-drng will enable RDRAND. That seems to be popular with various defense contractors, perhaps on the assumption that if it _was_ backdoored (no one knows for sure), it was probably with the connivance or request of the US government, who doesn't need to worry about spying on itself. Or you can use some kind of open hardware design RNG, such as ChoasKey[2] from Altus Metrum. But that requires using specially ordered hardware plugged into a USB slot, and it's probably not a mass solution. [2] https://altusmetrum.org/ChaosKey/ Personally, I prefer fixing the software to simply not require cryptographic grade entropy before the user has logged in. Because it's better than the alternatives. - Ted
Re: [PATCH 09/11] ASoC: AMD: Fix clocks in CZ DA7219 machine driver
On Thu, Apr 26, 2018 at 5:17 AM Vijendar Mukunda
wrote:
> From: Akshu Agrawal
> System clock on the platform is 25Mhz and not 24Mhz.
> PLL_OUT for da7219 codec to use DA7219_PLL_FREQ_OUT_98304
> as it is for 48KHz SR.
> Signed-off-by: Akshu Agrawal
> Signed-off-by: Vijendar Mukunda
Reviewed-by: Daniel Kurtz
> ---
> sound/soc/amd/acp-da7219-max98357a.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
> diff --git a/sound/soc/amd/acp-da7219-max98357a.c
b/sound/soc/amd/acp-da7219-max98357a.c
> index 6495eed..fa5ad5b 100644
> --- a/sound/soc/amd/acp-da7219-max98357a.c
> +++ b/sound/soc/amd/acp-da7219-max98357a.c
> @@ -39,8 +39,7 @@
> #include "../codecs/da7219.h"
> #include "../codecs/da7219-aad.h"
> -#define CZ_PLAT_CLK 2400
> -#define MCLK_RATE 24576000
> +#define CZ_PLAT_CLK 2500
> #define DUAL_CHANNEL 2
> static struct snd_soc_jack cz_jack;
> @@ -63,7 +62,7 @@ static int cz_da7219_init(struct snd_soc_pcm_runtime
*rtd)
> }
> ret = snd_soc_dai_set_pll(codec_dai, 0, DA7219_SYSCLK_PLL,
> - CZ_PLAT_CLK, MCLK_RATE);
> + CZ_PLAT_CLK, DA7219_PLL_FREQ_OUT_98304);
> if (ret < 0) {
> dev_err(rtd->dev, "can't set codec pll: %d\n", ret);
> return ret;
> --
> 2.7.4
Re: [PATCH 10/11] ASoC: AMD: Add const to snd_soc_ops instances
On Thu, Apr 26, 2018 at 5:18 AM Vijendar Mukunda
wrote:
> From: Akshu Agrawal
> Marking snd_soc_ops instances const
> Signed-off-by: Akshu Agrawal
> Signed-off-by: Vijendar Mukunda
Reviewed-by: Daniel Kurtz
> ---
> sound/soc/amd/acp-da7219-max98357a.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> diff --git a/sound/soc/amd/acp-da7219-max98357a.c
b/sound/soc/amd/acp-da7219-max98357a.c
> index fa5ad5b..133139d 100644
> --- a/sound/soc/amd/acp-da7219-max98357a.c
> +++ b/sound/soc/amd/acp-da7219-max98357a.c
> @@ -171,17 +171,17 @@ static void cz_dmic_shutdown(struct
snd_pcm_substream *substream)
> da7219_clk_disable();
> }
> -static struct snd_soc_ops cz_da7219_cap_ops = {
> +static const struct snd_soc_ops cz_da7219_cap_ops = {
> .startup = cz_da7219_startup,
> .shutdown = cz_da7219_shutdown,
> };
> -static struct snd_soc_ops cz_max_play_ops = {
> +static const struct snd_soc_ops cz_max_play_ops = {
> .startup = cz_max_startup,
> .shutdown = cz_max_shutdown,
> };
> -static struct snd_soc_ops cz_dmic_cap_ops = {
> +static const struct snd_soc_ops cz_dmic_cap_ops = {
> .startup = cz_dmic_startup,
> .shutdown = cz_dmic_shutdown,
> };
> --
> 2.7.4
Re: [PATCH 02/11] ASoC: amd: dma config parameters changes
Hi Vijendar,
On Thu, Apr 26, 2018 at 5:14 AM Vijendar Mukunda
wrote:
> Added dma configuration parameters to rtd structure.
> Moved dma configuration parameters intialization to
> hw_params callback.
> Removed hard coding in prepare and trigger callbacks.
> Signed-off-by: Vijendar Mukunda
> ---
>sound/soc/amd/acp-pcm-dma.c | 97
+
>sound/soc/amd/acp.h | 5 +++
>2 files changed, 41 insertions(+), 61 deletions(-)
> diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
> index 9c026c4..f18ed9a 100644
> --- a/sound/soc/amd/acp-pcm-dma.c
> +++ b/sound/soc/amd/acp-pcm-dma.c
> @@ -321,19 +321,12 @@ static void config_acp_dma(void __iomem *acp_mmio,
> u32 asic_type)
>{
> u32 pte_offset, sram_bank;
> - u16 ch1, ch2, destination, dma_dscr_idx;
> if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK) {
> pte_offset = ACP_PLAYBACK_PTE_OFFSET;
> - ch1 = SYSRAM_TO_ACP_CH_NUM;
> - ch2 = ACP_TO_I2S_DMA_CH_NUM;
> sram_bank = ACP_SHARED_RAM_BANK_1_ADDRESS;
> - destination = TO_ACP_I2S_1;
> -
> } else {
> pte_offset = ACP_CAPTURE_PTE_OFFSET;
> - ch1 = SYSRAM_TO_ACP_CH_NUM;
> - ch2 = ACP_TO_I2S_DMA_CH_NUM;
Wait... since this is the capture stream, shouldn't the channels have been:
ch1 = ACP_TO_SYSRAM_CH_NUM; /* 14 */
ch2 = I2S_TO_ACP_DMA_CH_NUM; /* 15 */
Is this an existing bug? Why does everything still work if these are wrong?
> switch (asic_type) {
> case CHIP_STONEY:
> sram_bank = ACP_SHARED_RAM_BANK_3_ADDRESS;
> @@ -341,30 +334,19 @@ static void config_acp_dma(void __iomem *acp_mmio,
> default:
> sram_bank = ACP_SHARED_RAM_BANK_5_ADDRESS;
> }
> - destination = FROM_ACP_I2S_1;
> }
> -
> acp_pte_config(acp_mmio, rtd->pg, rtd->num_of_pages,
> pte_offset);
> - if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK)
> - dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH12;
> - else
> - dma_dscr_idx = CAPTURE_START_DMA_DESCR_CH14;
> -
> /* Configure System memory <-> ACP SRAM DMA descriptors */
> set_acp_sysmem_dma_descriptors(acp_mmio, rtd->size,
> - rtd->direction, pte_offset, ch1,
> - sram_bank, dma_dscr_idx,
asic_type);
> -
> - if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK)
> - dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH13;
> - else
> - dma_dscr_idx = CAPTURE_START_DMA_DESCR_CH15;
> + rtd->direction, pte_offset,
> + rtd->ch1, sram_bank,
> + rtd->dma_dscr_idx_1, asic_type);
> /* Configure ACP SRAM <-> I2S DMA descriptors */
> set_acp_to_i2s_dma_descriptors(acp_mmio, rtd->size,
> rtd->direction, sram_bank,
> - destination, ch2, dma_dscr_idx,
> - asic_type);
> + rtd->destination, rtd->ch2,
> + rtd->dma_dscr_idx_2, asic_type);
>}
>/* Start a given DMA channel transfer */
> @@ -804,6 +786,21 @@ static int acp_dma_hw_params(struct
snd_pcm_substream *substream,
> acp_reg_write(val, adata->acp_mmio,
> mmACP_I2S_16BIT_RESOLUTION_EN);
> }
> +
> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> + rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
> + rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
> + rtd->destination = TO_ACP_I2S_1;
> + rtd->dma_dscr_idx_1 = PLAYBACK_START_DMA_DESCR_CH12;
> + rtd->dma_dscr_idx_2 = PLAYBACK_START_DMA_DESCR_CH13;
> + } else {
> + rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
> + rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
> + rtd->destination = FROM_ACP_I2S_1;
> + rtd->dma_dscr_idx_1 = CAPTURE_START_DMA_DESCR_CH14;
> + rtd->dma_dscr_idx_2 = CAPTURE_START_DMA_DESCR_CH15;
> + }
> +
I think you should do this initialization in acp_dma_open(), where the
audio_substream_data is kzalloc'ed and otherwise initialized to match the
provided snd_pcm_substream.
> size = params_buffer_bytes(params);
> status = snd_pcm_lib_malloc_pages(substream, size);
> if (status < 0)
> @@ -898,21 +895,15 @@ static int acp_dma_prepare(struct snd_pcm_substream
*substream)
> if (!rtd)
> return -EINVAL;
> - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
Re: [PATCH 05/11] ASoC: amd: pte offset related dma driver changes
On Thu, Apr 26, 2018 at 5:16 AM Vijendar Mukunda
wrote:
> Added pte offset variable in audio_substream_data structure.
> Added Stoney related PTE offset macros in acp header file.
> Modified hw_params callback to assign the pte offset value
> based on asic_type.
> Signed-off-by: Vijendar Mukunda
> ---
> sound/soc/amd/acp-pcm-dma.c | 26 +++---
> sound/soc/amd/acp.h | 5 +
> 2 files changed, 24 insertions(+), 7 deletions(-)
> diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
> index 5f34be1..cb22653 100644
> --- a/sound/soc/amd/acp-pcm-dma.c
> +++ b/sound/soc/amd/acp-pcm-dma.c
> @@ -320,13 +320,11 @@ static void config_acp_dma(void __iomem *acp_mmio,
> struct audio_substream_data *rtd,
> u32 asic_type)
> {
> - u32 pte_offset, sram_bank;
> + u32 sram_bank;
> - if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK) {
> - pte_offset = ACP_PLAYBACK_PTE_OFFSET;
> + if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK)
> sram_bank = ACP_SHARED_RAM_BANK_1_ADDRESS;
> - } else {
> - pte_offset = ACP_CAPTURE_PTE_OFFSET;
> + else {
> switch (asic_type) {
> case CHIP_STONEY:
> sram_bank = ACP_SHARED_RAM_BANK_3_ADDRESS;
> @@ -336,10 +334,10 @@ static void config_acp_dma(void __iomem *acp_mmio,
> }
> }
> acp_pte_config(acp_mmio, rtd->pg, rtd->num_of_pages,
> - pte_offset);
> + rtd->pte_offset);
> /* Configure System memory <-> ACP SRAM DMA descriptors */
> set_acp_sysmem_dma_descriptors(acp_mmio, rtd->size,
> - rtd->direction, pte_offset,
> + rtd->direction, rtd->pte_offset,
> rtd->ch1, sram_bank,
> rtd->dma_dscr_idx_1, asic_type);
> /* Configure ACP SRAM <-> I2S DMA descriptors */
> @@ -788,6 +786,13 @@ static int acp_dma_hw_params(struct
snd_pcm_substream *substream,
> }
> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> + switch (adata->asic_type) {
> + case CHIP_STONEY:
> + rtd->pte_offset = ACP_ST_PLAYBACK_PTE_OFFSET;
> + break;
> + default:
> + rtd->pte_offset = ACP_PLAYBACK_PTE_OFFSET;
> + }
As in patch 2, I believe this would be better done in acp_dma_open().
Why does Stoney use a different PTE_OFFSET? Please answer this question in
the commit message.
-Dan
> rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
> rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
> rtd->destination = TO_ACP_I2S_1;
> @@ -797,6 +802,13 @@ static int acp_dma_hw_params(struct
snd_pcm_substream *substream,
> mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH;
> rtd->byte_cnt_low_reg_offset =
mmACP_I2S_TRANSMIT_BYTE_CNT_LOW;
> } else {
> + switch (adata->asic_type) {
> + case CHIP_STONEY:
> + rtd->pte_offset = ACP_ST_CAPTURE_PTE_OFFSET;
> + break;
> + default:
> + rtd->pte_offset = ACP_CAPTURE_PTE_OFFSET;
> + }
> rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
> rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
> rtd->destination = FROM_ACP_I2S_1;
> diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
> index 82470bc..2f48d1d 100644
> --- a/sound/soc/amd/acp.h
> +++ b/sound/soc/amd/acp.h
> @@ -10,6 +10,10 @@
> #define ACP_PLAYBACK_PTE_OFFSET10
> #define ACP_CAPTURE_PTE_OFFSET 0
> +/* Playback and Capture Offset for Stoney */
> +#define ACP_ST_PLAYBACK_PTE_OFFSET 0x04
> +#define ACP_ST_CAPTURE_PTE_OFFSET 0x00
> +
> #define ACP_GARLIC_CNTL_DEFAULT0x0FB4
> #define ACP_ONION_CNTL_DEFAULT 0x0FB4
> @@ -90,6 +94,7 @@ struct audio_substream_data {
> u16 destination;
> u16 dma_dscr_idx_1;
> u16 dma_dscr_idx_2;
> + u32 pte_offset;
> u32 byte_cnt_high_reg_offset;
> u32 byte_cnt_low_reg_offset;
> uint64_t size;
> --
> 2.7.4
Re: [PATCH 06/11] ASoC: amd: sram bank update changes
On Thu, Apr 26, 2018 at 5:16 AM Vijendar Mukunda
wrote:
> Added sram bank variable to audio_substream_data structure.
> Signed-off-by: Vijendar Mukunda
Move initialization to acp_dma_open(), otherwise this is:
Reviewed-by: Daniel Kurtz
> ---
> sound/soc/amd/acp-pcm-dma.c | 20 +---
> sound/soc/amd/acp.h | 20 ++--
> 2 files changed, 19 insertions(+), 21 deletions(-)
> diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
> index cb22653..b7bffc7 100644
> --- a/sound/soc/amd/acp-pcm-dma.c
> +++ b/sound/soc/amd/acp-pcm-dma.c
> @@ -320,29 +320,16 @@ static void config_acp_dma(void __iomem *acp_mmio,
> struct audio_substream_data *rtd,
> u32 asic_type)
> {
> - u32 sram_bank;
> -
> - if (rtd->direction == SNDRV_PCM_STREAM_PLAYBACK)
> - sram_bank = ACP_SHARED_RAM_BANK_1_ADDRESS;
> - else {
> - switch (asic_type) {
> - case CHIP_STONEY:
> - sram_bank = ACP_SHARED_RAM_BANK_3_ADDRESS;
> - break;
> - default:
> - sram_bank = ACP_SHARED_RAM_BANK_5_ADDRESS;
> - }
> - }
> acp_pte_config(acp_mmio, rtd->pg, rtd->num_of_pages,
> rtd->pte_offset);
> /* Configure System memory <-> ACP SRAM DMA descriptors */
> set_acp_sysmem_dma_descriptors(acp_mmio, rtd->size,
> rtd->direction, rtd->pte_offset,
> - rtd->ch1, sram_bank,
> + rtd->ch1, rtd->sram_bank,
> rtd->dma_dscr_idx_1, asic_type);
> /* Configure ACP SRAM <-> I2S DMA descriptors */
> set_acp_to_i2s_dma_descriptors(acp_mmio, rtd->size,
> - rtd->direction, sram_bank,
> + rtd->direction, rtd->sram_bank,
> rtd->destination, rtd->ch2,
> rtd->dma_dscr_idx_2, asic_type);
> }
> @@ -795,6 +782,7 @@ static int acp_dma_hw_params(struct snd_pcm_substream
*substream,
> }
> rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
> rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
> + rtd->sram_bank = ACP_SRAM_BANK_1_ADDRESS;
> rtd->destination = TO_ACP_I2S_1;
> rtd->dma_dscr_idx_1 = PLAYBACK_START_DMA_DESCR_CH12;
> rtd->dma_dscr_idx_2 = PLAYBACK_START_DMA_DESCR_CH13;
> @@ -805,9 +793,11 @@ static int acp_dma_hw_params(struct
snd_pcm_substream *substream,
> switch (adata->asic_type) {
> case CHIP_STONEY:
> rtd->pte_offset = ACP_ST_CAPTURE_PTE_OFFSET;
> + rtd->sram_bank = ACP_SRAM_BANK_2_ADDRESS;
> break;
> default:
> rtd->pte_offset = ACP_CAPTURE_PTE_OFFSET;
> + rtd->sram_bank = ACP_SRAM_BANK_5_ADDRESS;
> }
> rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
> rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
> diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
> index 2f48d1d..62695ed 100644
> --- a/sound/soc/amd/acp.h
> +++ b/sound/soc/amd/acp.h
> @@ -19,12 +19,19 @@
> #define ACP_PHYSICAL_BASE 0x14000
> -/* Playback SRAM address (as a destination in dma descriptor) */
> -#define ACP_SHARED_RAM_BANK_1_ADDRESS 0x4002000
> -
> -/* Capture SRAM address (as a source in dma descriptor) */
> -#define ACP_SHARED_RAM_BANK_5_ADDRESS 0x400A000
> -#define ACP_SHARED_RAM_BANK_3_ADDRESS 0x4006000
> +/*
> + * In case of I2S SP controller instance, Stoney uses SRAM bank 1 for
> + * playback and SRAM Bank 2 for capture where as in case of BT I2S
> + * Instance, Stoney uses SRAM Bank 3 for playback & SRAM Bank 4 will
> + * be used for capture. Carrizo uses I2S SP controller instance. SRAM
Banks
> + * 1, 2, 3, 4 will be used for playback & SRAM Banks 5, 6, 7, 8 will be
used
> + * for capture scenario.
> + */
> +#define ACP_SRAM_BANK_1_ADDRESS0x4002000
> +#define ACP_SRAM_BANK_2_ADDRESS0x4004000
> +#define ACP_SRAM_BANK_3_ADDRESS0x4006000
> +#define ACP_SRAM_BANK_4_ADDRESS0x4008000
> +#define ACP_SRAM_BANK_5_ADDRESS0x400A000
> #define ACP_DMA_RESET_TIME 1
> #define ACP_CLOCK_EN_TIME_OUT_VALUE0x00FF
> @@ -95,6 +102,7 @@ struct audio_substream_data {
> u16 dma_dscr_idx_1;
> u16 dma_dscr_idx_2;
> u32 pte_offset;
> + u32 sram_bank;
> u32 byte_cnt_high_reg_offset;
> u32 byte_cnt_low_reg_offset;
> uint64_t size;
> --
> 2.7.4
Re: [PATCH 04/11] ASoC: amd: removed separate byte count variables for playback and capture
Hi Vijendar,
On Thu, Apr 26, 2018 at 5:15 AM Vijendar Mukunda
wrote:
> Removed separate byte count variables for playback and capture.
> Signed-off-by: Vijendar Mukunda
Reviewed-by: Daniel Kurtz
> ---
> sound/soc/amd/acp-pcm-dma.c | 19 +--
> sound/soc/amd/acp.h | 3 +--
> 2 files changed, 6 insertions(+), 16 deletions(-)
> diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
> index 019f696..5f34be1 100644
> --- a/sound/soc/amd/acp-pcm-dma.c
> +++ b/sound/soc/amd/acp-pcm-dma.c
> @@ -866,13 +866,8 @@ static snd_pcm_uframes_t acp_dma_pointer(struct
snd_pcm_substream *substream)
> buffersize = frames_to_bytes(runtime, runtime->buffer_size);
> bytescount = acp_get_byte_count(rtd);
> - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> - if (bytescount > rtd->i2ssp_renderbytescount)
> - bytescount = bytescount -
rtd->i2ssp_renderbytescount;
> - } else {
> - if (bytescount > rtd->i2ssp_capturebytescount)
> - bytescount = bytescount -
rtd->i2ssp_capturebytescount;
> - }
> + if (bytescount > rtd->bytescount)
> + bytescount = bytescount - rtd->bytescount;
nit, this could be:
bytescount -= rtd->bytescount;
> pos = do_div(bytescount, buffersize);
> return bytes_to_frames(runtime, pos);
> }
> @@ -921,9 +916,9 @@ static int acp_dma_trigger(struct snd_pcm_substream
*substream, int cmd)
> case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> case SNDRV_PCM_TRIGGER_RESUME:
> bytescount = acp_get_byte_count(rtd);
> + if (rtd->bytescount == 0)
> + rtd->bytescount = bytescount;
> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> - if (rtd->i2ssp_renderbytescount == 0)
> - rtd->i2ssp_renderbytescount = bytescount;
> acp_dma_start(rtd->acp_mmio, rtd->ch1, false);
> while (acp_reg_read(rtd->acp_mmio,
mmACP_DMA_CH_STS) &
> BIT(rtd->ch1)) {
> @@ -934,9 +929,6 @@ static int acp_dma_trigger(struct snd_pcm_substream
*substream, int cmd)
> }
> cpu_relax();
> }
> - } else {
> - if (rtd->i2ssp_capturebytescount == 0)
> - rtd->i2ssp_capturebytescount = bytescount;
> }
> acp_dma_start(rtd->acp_mmio, rtd->ch2, true);
> ret = 0;
> @@ -947,12 +939,11 @@ static int acp_dma_trigger(struct snd_pcm_substream
*substream, int cmd)
> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> acp_dma_stop(rtd->acp_mmio, rtd->ch1);
> ret = acp_dma_stop(rtd->acp_mmio, rtd->ch2);
> - rtd->i2ssp_renderbytescount = 0;
> } else {
> acp_dma_stop(rtd->acp_mmio, rtd->ch2);
> ret = acp_dma_stop(rtd->acp_mmio, rtd->ch1);
> - rtd->i2ssp_capturebytescount = 0;
> }
> + rtd->bytescount = 0;
> break;
> default:
> ret = -EINVAL;
> diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
> index 3b076c6..82470bc 100644
> --- a/sound/soc/amd/acp.h
> +++ b/sound/soc/amd/acp.h
> @@ -93,8 +93,7 @@ struct audio_substream_data {
> u32 byte_cnt_high_reg_offset;
> u32 byte_cnt_low_reg_offset;
> uint64_t size;
> - u64 i2ssp_renderbytescount;
> - u64 i2ssp_capturebytescount;
> + u64 bytescount;
> void __iomem *acp_mmio;
> };
> --
> 2.7.4
Re: [PATCH 03/11] ASoC: amd: added byte count register offset variables to rtd
Hi Vijendar,
On Thu, Apr 26, 2018 at 5:14 AM Vijendar Mukunda
wrote:
> Added byte count register offset variables to audio_substream_data
> structure. Modified dma pointer callback.
> Signed-off-by: Vijendar Mukunda
Please fix the small indentation nits, otherwise this one is:
Reviewed-by: Daniel Kurtz
> ---
> sound/soc/amd/acp-pcm-dma.c | 36 +++-
> sound/soc/amd/acp.h | 2 ++
> 2 files changed, 17 insertions(+), 21 deletions(-)
> diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
> index f18ed9a..019f696 100644
> --- a/sound/soc/amd/acp-pcm-dma.c
> +++ b/sound/soc/amd/acp-pcm-dma.c
> @@ -793,12 +793,18 @@ static int acp_dma_hw_params(struct
snd_pcm_substream *substream,
> rtd->destination = TO_ACP_I2S_1;
> rtd->dma_dscr_idx_1 = PLAYBACK_START_DMA_DESCR_CH12;
> rtd->dma_dscr_idx_2 = PLAYBACK_START_DMA_DESCR_CH13;
> + rtd->byte_cnt_high_reg_offset =
> + mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH;
Indent relative to line above with 2 tabs.
> + rtd->byte_cnt_low_reg_offset =
mmACP_I2S_TRANSMIT_BYTE_CNT_LOW;
> } else {
> rtd->ch1 = SYSRAM_TO_ACP_CH_NUM;
> rtd->ch2 = ACP_TO_I2S_DMA_CH_NUM;
> rtd->destination = FROM_ACP_I2S_1;
> rtd->dma_dscr_idx_1 = CAPTURE_START_DMA_DESCR_CH14;
> rtd->dma_dscr_idx_2 = CAPTURE_START_DMA_DESCR_CH15;
> + rtd->byte_cnt_high_reg_offset =
> + mmACP_I2S_RECEIVED_BYTE_CNT_HIGH;
here too.
> + rtd->byte_cnt_low_reg_offset =
mmACP_I2S_RECEIVED_BYTE_CNT_LOW;
> }
> size = params_buffer_bytes(params);
> @@ -834,26 +840,15 @@ static int acp_dma_hw_free(struct snd_pcm_substream
*substream)
> return snd_pcm_lib_free_pages(substream);
> }
> -static u64 acp_get_byte_count(void __iomem *acp_mmio, int stream)
> +static u64 acp_get_byte_count(struct audio_substream_data *rtd)
> {
> - union acp_dma_count playback_dma_count;
> - union acp_dma_count capture_dma_count;
> - u64 bytescount = 0;
> + union acp_dma_count byte_count;
> - if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
> - playback_dma_count.bcount.high = acp_reg_read(acp_mmio,
> - mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH);
> - playback_dma_count.bcount.low = acp_reg_read(acp_mmio,
> - mmACP_I2S_TRANSMIT_BYTE_CNT_LOW);
> - bytescount = playback_dma_count.bytescount;
> - } else {
> - capture_dma_count.bcount.high = acp_reg_read(acp_mmio,
> - mmACP_I2S_RECEIVED_BYTE_CNT_HIGH);
> - capture_dma_count.bcount.low = acp_reg_read(acp_mmio,
> - mmACP_I2S_RECEIVED_BYTE_CNT_LOW);
> - bytescount = capture_dma_count.bytescount;
> - }
> - return bytescount;
> + byte_count.bcount.high = acp_reg_read(rtd->acp_mmio,
> +
rtd->byte_cnt_high_reg_offset);
> + byte_count.bcount.low = acp_reg_read(rtd->acp_mmio,
> +
rtd->byte_cnt_low_reg_offset);
> + return byte_count.bytescount;
> }
> static snd_pcm_uframes_t acp_dma_pointer(struct snd_pcm_substream
*substream)
> @@ -869,7 +864,7 @@ static snd_pcm_uframes_t acp_dma_pointer(struct
snd_pcm_substream *substream)
> return -EINVAL;
> buffersize = frames_to_bytes(runtime, runtime->buffer_size);
> - bytescount = acp_get_byte_count(rtd->acp_mmio, substream->stream);
> + bytescount = acp_get_byte_count(rtd);
> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> if (bytescount > rtd->i2ssp_renderbytescount)
> @@ -925,8 +920,7 @@ static int acp_dma_trigger(struct snd_pcm_substream
*substream, int cmd)
> case SNDRV_PCM_TRIGGER_START:
> case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> case SNDRV_PCM_TRIGGER_RESUME:
> - bytescount = acp_get_byte_count(rtd->acp_mmio,
> - substream->stream);
> + bytescount = acp_get_byte_count(rtd);
> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> if (rtd->i2ssp_renderbytescount == 0)
> rtd->i2ssp_renderbytescount = bytescount;
> diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
> index 5e25428..3b076c6 100644
> --- a/sound/soc/amd/acp.h
> +++ b/sound/soc/amd/acp.h
> @@ -90,6 +90,8 @@ struct audio_substream_data {
> u16 destination;
> u16 dma_dscr_idx_1;
> u16 dma_dscr_idx_2;
> + u32 byte_cnt_high_reg_offset;
> + u32 byte_cnt_low_reg_offset;
> uint64_t size;
> u64 i2ssp_renderbytescount;
> u64 i2ssp_capturebytescount;
> --
> 2.7.4
Re: Linux messages full of `random: get_random_u32 called from`
On Sun, Apr 29, 2018 at 11:18:55PM +0200, Pavel Machek wrote:
> So -- I'm pretty sure systemd and friends should be using
> /dev/urandom. Maybe gpg wants to use /dev/random. _Maybe_.
>
> [2.948192] random: systemd: uninitialized urandom read (16 bytes
> read)
> [2.953526] systemd[1]: systemd 215 running in system mode. (+PAM
> +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ
> -SECCOMP -APPARMOR)
> [2.980278] systemd[1]: Detected architecture 'x86'.
> [3.115072] usb 5-2: New USB device found, idVendor=0483,
> idProduct=2016, bcdDevice= 0.01
> [3.119633] usb 5-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [3.124147] usb 5-2: Product: Biometric Coprocessor
> [3.128621] usb 5-2: Manufacturer: STMicroelectronics
> [3.163839] systemd[1]: Failed to insert module 'ipv6'
> [3.181266] systemd[1]: Set hostname to .
> [3.267243] random: systemd-sysv-ge: uninitialized urandom read (16
> bytes read)
> [3.669590] random: systemd-sysv-ge: uninitialized urandom read (16
> bytes read)
> [3.696242] random: systemd: uninitialized urandom read (16 bytes
> read)
> [3.700066] random: systemd: uninitialized urandom read (16 bytes
> read)
> [3.703716] random: systemd: uninitialized urandom read (16 bytes
> read)
>
> Anyway, urandom should need to be seeded once, and then provide random
> data forever... which is not impression I get from the dmesg output
> above. Boot clearly proceeds... somehow. So now I'm confused.
Hmm... Well, the attached patch (which redirects /dev/random to /dev/urandom)
didn't fix my boot issue, so I'm at a loss as well.
Sultan
>From 15f54e2756866956d8713fdec92b54c6c69eb1bb Mon Sep 17 00:00:00 2001
From: Sultan Alsawaf
Date: Sun, 29 Apr 2018 12:53:44 -0700
Subject: [PATCH] char: mem: Link /dev/random to /dev/urandom
---
drivers/char/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index ffeb60d3434c..0cd22e6100ad 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -870,7 +870,7 @@ static const struct memdev {
#endif
[5] = { "zero", 0666, &zero_fops, 0 },
[7] = { "full", 0666, &full_fops, 0 },
-[8] = { "random", 0666, &random_fops, 0 },
+[8] = { "random", 0666, &urandom_fops, 0 },
[9] = { "urandom", 0666, &urandom_fops, 0 },
#ifdef CONFIG_PRINTK
[11] = { "kmsg", 0644, &kmsg_fops, 0 },
--
2.14.1
Linux 4.17-rc3
You all know the drill by now, and everything looks pretty normal. As
usual, we have an rc3 that is noticeably bigger than rc2 was. Whatever the
reason for the pattern (whether it just be "people have had time to find
bugs" or "people took a breather after the merge window"), the pattern is
alive and well.
And by now, I think we've fixed all the nastiest fall-out from the merge
window. In particular, the PTI large-page fallout that hit some people with
particular configurations should all be good.
But another marker of "things look normal" is that almost 60% of the patch
is driver fixes all over: networking, gpu, sound, scsi, usb, you name it.
Outside of drivers, we've got the usual architecture suspects: x86, arm64,
powerpc. Some generic networking fixes, and misc tooling (perf and
selftests). With some core kernel fixes in there too (mainly timers and
tracing, the first mainly because we sadly had to revert the nice
CLOCK_{MONOTONIC,BOOTTIME} unification because it turns out people really
do care about the differences).
Shortlog appended for the details.
Go out and test,
Linus
---
Abhay Kumar (1):
drm/i915/audio: set minimum CD clock to twice the BCLK
Abhinav Kumar (3):
drm/msm/dsi: check return value for video done waits
drm/msm/dsi: check video mode engine status before waiting
drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY
Ahbong Chang (1):
tracing: Add missing forward declaration
Ahmed Abdelsalam (1):
ipv6: sr: fix NULL pointer dereference in seg6_do_srh_encap()- v4 pkts
Ajay Singh (1):
staging: wilc1000: fix NULL pointer exception in
host_int_parse_assoc_resp_info()
Alan Jenkins (1):
block: do not use interruptible wait anywhere
Alexander Aring (3):
net: sched: ife: signal not finding metaid
net: sched: ife: handle malformed tlv length
net: sched: ife: check on metadata length
Alexander Popov (1):
i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()
Alistair Popple (3):
powerpc/powernv/npu: Add lock to prevent race in concurrent context
init/destroy
powerpc/powernv/npu: Prevent overwriting of pnv_npu2_init_contex()
callback parameters
powerpc/powernv/npu: Do a PID GPU TLB flush when invalidating a large
address range
Amir Goldstein (1):
: fix end_name_hash() for 64bit long
Anatolij Gustschin (1):
fpga-manager: altera-ps-spi: preserve nCONFIG state
Anders Roxell (1):
selftests: bpf: update .gitignore with missing generated files
Andre Przywara (1):
KVM: arm/arm64: vgic: Kick new VCPU on interrupt migration
Andres Rodriguez (2):
drm/amdkfd: fix clock counter retrieval for node without GPU
firmware: some documentation fixes
André Wild (1):
s390/cpum_cf: rename IBM z13/z14 counter names
Andy Lutomirski (1):
x86/entry/64/compat: Preserve r8-r11 in int $0x80
Anirudh Venkataramanan (2):
ice: Fix initialization for num_nodes_added
ice: Fix incorrect comment for action type
Ard Biesheuvel (1):
ACPI / button: make module loadable when booted in non-ACPI mode
Arend van Spriel (1):
drivers: change struct device_driver::coredump() return type to void
Arnd Bergmann (4):
ASoC: rsnd: mark PM functions __maybe_unused
netfilter: fix CONFIG_NF_REJECT_IPV6=m link error
usb: select USB_COMMON for usb role switch config
x86/ipc: Fix x32 version of shmid64_ds and msqid64_ds
Aurelien Jarno (1):
RISC-V: build vdso-dummy.o with -no-pie
Balbir Singh (2):
powerpc/mm: Flush cache on memory hot(un)plug
powerpc/powernv/memtrace: Let the arch hotunplug code flush cache
Baolin Wang (2):
i2c: sprd: Prevent i2c accesses after suspend is called
i2c: sprd: Fix the i2c count issue
Bart Van Assche (1):
scsi: sd_zbc: Avoid that resetting a zone fails sporadically
Ben Hutchings (3):
drm/msm: Fix possible null dereference on failure of get_pages()
test_firmware: Install all scripts
test_firmware: fix setting old custom fw path back on exit, second try
Ben Shelton (1):
ice: Do not check INTEVENT bit for OICR interrupts
Bernat, Yehezkel (1):
MAINTAINERS: update my email address
Biju Das (1):
serial: sh-sci: Document r8a77470 bindings
Boris Brezillon (1):
mtd: nand: Fix nanddev_mtd_erase()
Borislav Petkov (2):
x86/microcode/intel: Save microcode patch unconditionally
x86/microcode: Do not exit early from __reload_late()
Chen Yu (1):
ACPI / PM: Blacklist Low Power S0 Idle _DSM for ThinkPad X1
Tablet(2016)
Chris Leech (1):
scsi: iscsi: respond to netlink with unicast when appropriate
Christoffer Dall (1):
MAINTAINERS: Update e-mail address for Christoffer Dall
Christoph Hellwig (2):
riscv: select DMA_DIRECT_OPS instead of redefining it
riscv: there is no
Colin Ian King (3):
firmware: arm_scmi: remove redunda
Re: Linux messages full of `random: get_random_u32 called from`
On Sun 2018-04-29 13:20:33, Sultan Alsawaf wrote: > On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote: > > Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE > > Okay, but /dev/urandom isn't a solution to this problem because it isn't > usable > until crng init is complete, so it suffers from the same init lag as > /dev/random. So -- I'm pretty sure systemd and friends should be using /dev/urandom. Maybe gpg wants to use /dev/random. _Maybe_. [2.948192] random: systemd: uninitialized urandom read (16 bytes read) [2.953526] systemd[1]: systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR) [2.980278] systemd[1]: Detected architecture 'x86'. [3.115072] usb 5-2: New USB device found, idVendor=0483, idProduct=2016, bcdDevice= 0.01 [3.119633] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [3.124147] usb 5-2: Product: Biometric Coprocessor [3.128621] usb 5-2: Manufacturer: STMicroelectronics [3.163839] systemd[1]: Failed to insert module 'ipv6' [3.181266] systemd[1]: Set hostname to . [3.267243] random: systemd-sysv-ge: uninitialized urandom read (16 bytes read) [3.669590] random: systemd-sysv-ge: uninitialized urandom read (16 bytes read) [3.696242] random: systemd: uninitialized urandom read (16 bytes read) [3.700066] random: systemd: uninitialized urandom read (16 bytes read) [3.703716] random: systemd: uninitialized urandom read (16 bytes read) Anyway, urandom should need to be seeded once, and then provide random data forever... which is not impression I get from the dmesg output above. Boot clearly proceeds... somehow. So now I'm confused. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
linux-next: Signed-off-by missing for commit in the net tree
Hi all,
Commit
6082d9c9c94a ("net/mlx5: Fix mlx5_get_vector_affinity function")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgp24cxUfSI9L.pgp
Description: OpenPGP digital signature
anmodning forretning
god dag anmodning forretning Jeg bruger dette medie til at informere dig om transaktionen for overførsel af $ 21.500.000 (Twenty-en million fem hundrede tusinde dollars) i min bank i Kina til dig som modtager. Det vil være 100% sikker, er den finansielle officer af den afdøde kunde. For god forståelse af forretningsforslaget kan du sende dit svar på engelsk Venligst kontakt mig på min private e-mail nedenfor for eventuelle spørgsmål og yderligere information. chinsang...@gmail.com Med venlig hilsen Chin Sang e-mail: chinsang...@gmail.com
Re: [PATCH RFC 2/8] mm: introduce PG_offline
On Sun 22-04-18 17:13:52, David Hildenbrand wrote: > On 22.04.2018 16:02, Matthew Wilcox wrote: > > On Sun, Apr 22, 2018 at 10:17:31AM +0200, David Hildenbrand wrote: > >> On 22.04.2018 05:01, Matthew Wilcox wrote: > >>> On Sat, Apr 21, 2018 at 06:52:18PM +0200, Vlastimil Babka wrote: > Sounds like your newly introduced "page types" could be useful here? I > don't suppose those offline pages would be using mapcount which is > aliased there? > >>> > >>> Oh, that's a good point! Yes, this is a perfect use for page_type. > >>> We have something like twenty bits available there. > >>> > >>> Now you've got me thinking that we can move PG_hwpoison and PG_reserved > >>> to be page_type flags too. That'll take us from 23 to 21 bits (on 32-bit, > >>> with PG_UNCACHED) > >> > >> Some things to clarify here. I modified the current RFC to also allow > >> PG_offline on allocated (ballooned) pages (e.g. virtio-balloon). > >> > >> kdump based dump tools can then easily identify which pages are not to > >> be dumped (either because the content is invalid or not accessible). > >> > >> I previously stated that ballooned pages would be marked as PG_reserved, > >> which is not true (at least not for virtio-balloon). However this allows > >> me to detect if all pages in a section are offline by looking at > >> (PG_reserved && PG_offline). So I can actually tell if a page is marked > >> as offline and allocated or really offline. > >> > >> > >> 1. The location (not the number!) of PG_hwpoison is basically ABI and > >> cannot be changed. Moving it around will most probably break dump tools. > >> (see kernel/crash_core.c) > > > > It's not ABI. It already changed after 4.9 when PG_waiters was introduced > > by commit 62906027091f. > > It is, please have a look at the file I pointed you to. > > We export the *value* of PG_hwpoison in the ELF file, therefore the > *value* can change, but the *location* (page_flags, mapcount, whatever) > must not change. Or am I missing something here? I don't think we can > move PG_hwpoison that easily. > > Also, I can read "For pages that are never mapped to userspace, > page->mapcount may be used for storing extra information about page > type" - is that true for PG_hwpoison/PG_reserved? I am skeptical. > > And we need something similar for PG_offline, because it will become > ABI. (I can see that PAGE_BUDDY_MAPCOUNT_VALUE is also exported in an > ELF file, so maybe a new page type might work for marking a page offline > - but I have to look at the details first tomorrow) Wait wait wait. Who is relying on this? Kdump? Page flags have always been an internal implementation detail and _nobody_ outside of the kernel should ever rely on the specific value. Well, kdump has been cheating but that is because kdump is inherently tight to a specific kernel implementation but that doesn't make it a stable ABI IMHO. Restricting the kernel internals because of a debugging tool would be quite insane. -- Michal Hocko SUSE Labs
Re: [PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation
On Sun, Apr 29, 2018 at 2:01 PM, Andreas Färber wrote: > "pwm0" sounds like a zero-indexed instance of some pwm block. If 0 is > the version here, I'd suggest to make it "pwm-0" for example - you might > want to take a look at the Xilinx bindings, which use a strict x.yy suffix. That's fine. I'll change it to pwm-0.00 in the next patch series. > Most SoCs don't have clearly versioned IP though, that's why for > community-contributed bindings the first SoC we encounter the IP in > usually gets the name. In this particular case, we do have versioned IP, and we will be contributing drivers for those which wind up in linux-capable chips.
Re: [PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation
Am 29.04.2018 um 22:51 schrieb Wesley Terpstra: > On Sat, Apr 28, 2018 at 10:54 PM, Thierry Reding > wrote: >> On Fri, Apr 27, 2018 at 03:59:56PM -0700, Wesley W. Terpstra wrote: >>> +Required properties: >>> +- compatible: should be "sifive,pwm0" >> >> Why not simply "sifive,pwm"? If this is supposed to be some sort of >> version number, then it is more customary to use the name of the first >> SoC that integrates the IP. There are some exceptions, like for example >> when the IP is third-party and is integrated in a number of different >> SoCs. In such cases the IP is often properly versioned. But that doesn't >> seem to be the case here. > > It is indeed a version number. The first SoC which integrated this IP > cannot run linux. We've put a version number like this into all of our > IP blocks. Isn't an increasing number, which clearly indicates > increased functionality, better than a reference to a sequence of SoCs > whose relationships are not all that clear? "pwm0" sounds like a zero-indexed instance of some pwm block. If 0 is the version here, I'd suggest to make it "pwm-0" for example - you might want to take a look at the Xilinx bindings, which use a strict x.yy suffix. Most SoCs don't have clearly versioned IP though, that's why for community-contributed bindings the first SoC we encounter the IP in usually gets the name. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH] staging: luster: llite: fix a potential missing-check bug when copying lumv
On Sun, Apr 29, 2018 at 8:20 AM, Greg Kroah-Hartman wrote: > On Sat, Apr 28, 2018 at 04:04:25PM +, Dilger, Andreas wrote: >> On Apr 27, 2018, at 17:45, Wenwen Wang wrote: >> > [PATCH] staging: luster: llite: fix potential missing-check bug when >> > copying lumv >> >> (typo) s/luster/lustre/ >> >> > In ll_dir_ioctl(), the object lumv3 is firstly copied from the user space >> > using Its address, i.e., lumv1 = &lumv3. If the lmm_magic field of lumv3 is >> > LOV_USER_MAGIV_V3, lumv3 will be modified by the second copy from the user >> >> (typo) s/MAGIV/MAGIC/ >> >> > space. The second copy is necessary, because the two versions (i.e., >> > lov_user_md_v1 and lov_user_md_v3) have different data formats and lengths. >> > However, given that the user data resides in the user space, a malicious >> > user-space process can race to change the data between the two copies. By >> > doing so, the attacker can provide a data with an inconsistent version, >> > e.g., v1 version + v3 data. This can lead to logical errors in the >> > following execution in ll_dir_setstripe(), which performs different actions >> > according to the version specified by the field lmm_magic. >> >> This isn't a serious bug in the end. The LOV_USER_MAGIC_V3 check just copies >> a bit more data from userspace (the lmm_pool field). It would be more of a >> problem if the reverse was possible (copy smaller V1 buffer, but change the >> magic to LOV_USER_MAGIC_V3 afterward), but this isn't possible since the >> second >> copy is not done if there is a V1 magic. If the user changes from V3 magic >> to V1 in a racy manner it means less data will be used than copied, which >> is harmless. >> >> > This patch rechecks the version field lmm_magic in the second copy. If the >> > version is not as expected, i.e., LOV_USER_MAGIC_V3, an error code will be >> > returned: -EINVAL. >> >> This isn't a bad idea in any case, since it verifies the data copied from >> userspace is still valid. > > So you agree with this patch? Or do not? > > confused, > > greg k-h It is worth fixing this bug, since it offers an opportunity for adversaries to provide inconsistent user data. In addition to the unwanted version LOV_USER_MAGIC_V1, a malicious user can also use the version LMV_USER_MAGIC, which is also unexpected but allowed in the function ll_dir_setstripe(). These inconsistent data can cause potential logical errors in the following execution. Hence it is necessary to re-verify the data copied from userspace. Thanks! Wenwen
Re: [PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation
On Sat, Apr 28, 2018 at 10:54 PM, Thierry Reding wrote: > On Fri, Apr 27, 2018 at 03:59:56PM -0700, Wesley W. Terpstra wrote: >> +Unlike most other PWM controllers, the SiFive PWM controller currently only >> +supports one period for all channels in the PWM. This is set globally in >> DTS. >> +The period also has significant restrictions on the values it can achieve, >> +which the driver rounds to the nearest achievable frequency. > > How about you encode this in the driver rather than DT? We have several > drivers with similar restrictions and they usually allow the first PWM > channel to choose an arbitrary period and return an error if subsequent > channels request a period that can't be supported. > > I think something similar could work with that second restriction. Why > not return an error if the exact period can't be set? Or perhaps allow > some percentage of deviation. Interesting. There are two ways to use this PWM. In one mode you use all channels of the PWM as outputs. This is the mode the driver supports because the HiFive Unleashed board uses all channels connected to LEDs. In this case, the PWM period must always be a power-of-two reduction from the core bus clock frequency. The core bus clock frequency can vary. Therefore, even if the caller's frequency can be achieved at the time of the method call, it may not remain achievable. You might say this is a ridiculous PWM design, and I'd agree with you, but sadly this is what is found in these chips. So effectively, the only thing we can guarantee is that the period is within a multiple of sqrt(2) from the requested period, except even that is not true due to saturation restrictions that could push the period even further from what you ask. In the other mode (where you sacrifice one of the output channels), you have finer control of the period, but it still affects all channels. This mode might be a better fit for your proposed API, except that the driver would still be subject to saturation restrictions on the period. And those restrictions will change as the core bus frequency is changed, which means that again, even if your target period can be achieved (common to all channels) at invocation, it might not be achievable later. IMO the only real control this PWM can offer reliably is the duty cycle, which is why I've written it how I have. If you see a better solution to the above problems, I am open to suggestions. >> +Required properties: >> +- compatible: should be "sifive,pwm0" > > Why not simply "sifive,pwm"? If this is supposed to be some sort of > version number, then it is more customary to use the name of the first > SoC that integrates the IP. There are some exceptions, like for example > when the IP is third-party and is integrated in a number of different > SoCs. In such cases the IP is often properly versioned. But that doesn't > seem to be the case here. It is indeed a version number. The first SoC which integrated this IP cannot run linux. We've put a version number like this into all of our IP blocks. Isn't an increasing number, which clearly indicates increased functionality, better than a reference to a sequence of SoCs whose relationships are not all that clear?
Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct
On Sun, Apr 29, 2018 at 09:59:27AM -0700, Kees Cook wrote: > Did this ever happen? Not yet. I brought it up at LSFMM, and I'll repost the patches soon. > I'd also like to see kmalloc_array_3d() or > something that takes three size arguments. We have a lot of this > pattern too: > > kmalloc(sizeof(foo) * A * B, gfp...) > > And we could turn that into: > > kmalloc_array_3d(sizeof(foo), A, B, gfp...) Are either of A or B constant? Because if so, we could just use kmalloc_array. If not, then kmalloc_array_3d becomes a little more expensive than kmalloc_array because we have to do a divide at runtime instead of compile-time. that's still better than allocating too few bytes, of course. I'm wondering how far down the abc + ab + ac + bc + d rabbit-hole we're going to end up going. As far as we have to, I guess.
Re: Linux messages full of `random: get_random_u32 called from`
On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote: > Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE Okay, but /dev/urandom isn't a solution to this problem because it isn't usable until crng init is complete, so it suffers from the same init lag as /dev/random. Sultan
Re: Linux messages full of `random: get_random_u32 called from`
On Sun, Apr 29, 2018 at 11:30:57AM -0700, Sultan Alsawaf wrote: > > Mind you, this laptop has a 45W CPU, so power savings were definitely not > considered in its design. Do you have any machines that can provide enough > boot entropy to satisfy crng init without requiring user-provided entropy? My 2018 Dell XPS 13 laptop, running "egrep '(random|EXT4)' /var/log/kern.log": Apr 24 17:05:01 cwcc kernel: [0.00] random: get_random_bytes called from start_kernel+0x83/0x500 with crng_init=0 Apr 24 17:05:01 cwcc kernel: [1.363383] random: fast init done Apr 24 17:05:01 cwcc kernel: [3.567432] random: lvm: uninitialized urandom read (4 bytes read) Apr 24 17:05:01 cwcc kernel: [3.593132] random: lvm: uninitialized urandom read (4 bytes read) Apr 24 17:05:01 cwcc kernel: [7.584838] random: cryptsetup: uninitialized urandom read (2 bytes read) Apr 24 17:05:01 cwcc kernel: [7.600685] random: cryptsetup: uninitialized urandom read (2 bytes read) Apr 24 17:05:01 cwcc kernel: [7.803194] random: cryptsetup: uninitialized urandom read (2 bytes read) Apr 24 17:05:01 cwcc kernel: [7.831050] random: lvm: uninitialized urandom read (4 bytes read) Apr 24 17:05:01 cwcc kernel: [7.851884] random: lvm: uninitialized urandom read (4 bytes read) Apr 24 17:05:01 cwcc kernel: [7.875382] random: lvm: uninitialized urandom read (2 bytes read) Apr 24 17:05:01 cwcc kernel: [8.162552] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null) Apr 24 17:05:01 cwcc kernel: [8.646497] random: crng init done - Ted
Re: Moving unmaintained filesystems to staging
On Sunday 29 April 2018 14:07:05 Greg KH wrote: > On Thu, Apr 26, 2018 at 08:11:08AM +0200, Pavel Machek wrote: > > On Wed 2018-04-25 08:46:02, Matthew Wilcox wrote: > > > Recently ncpfs got moved to staging. Also recently, we had some fuzzer > > > developers report bugs in hfs, which they deem a security hole because > > > Ubuntu attempts to automount an inserted USB device as hfs. > > > > We promise "no-regressions" for code in main repository, no such > > promise for staging. We have quite a lot of code without maintainer. > > > > Moving code to staging means it will get broken -- staging was not > > designed for this. I believe moving anything there is bad idea. > > > > Staging is for ugly code, not for code that needs new maintainter. > > Staging is used for getting code _out_ of the kernel tree as well as > _in_. We use it all the time to move code there, see if anyone shows up > in 6-8 months to say "I will fix this!", and if not, we delete it. > > Look at what just happened to IRDA in the 4.17-rc1 release as an example > of this. Really a "great" example of deleting working code :( -- Ondrej Zary
[PATCH v6 3/3] pinctrl: bcm2835: Add support for output-low output-high properties
Properties to set initial value of pin output buffer. This can be useful for configure hardware in overlay files, and in early boot for checking it states in QA sanity tests. Signed-off-by: Matheus Castello --- drivers/pinctrl/bcm/pinctrl-bcm2835.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c index 0231107..3bc0d04 100644 --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c @@ -965,6 +965,11 @@ static int bcm2835_pinconf_set(struct pinctrl_dev *pctldev, bcm2835_pull_config_set(pc, pin, BCM2835_PUD_UP); break; + /* Set output-high or output-low */ + case PIN_CONFIG_OUTPUT: + bcm2835_gpio_set_bit(pc, arg ? GPSET0 : GPCLR0, pin); + break; + default: return -EINVAL; -- 2.7.4
Re: [PATCH v6 0/3] bcm2835: Add generic pinctrl support
This series adds support for generic binding for pinctrl bcm2835 driver, and add the code for set output buffer of a pin using the output-low and output-high generic properties. Tested on Raspberry Pi Zero W, based on bcm2835 SoC. Changes since v5: (Suggested by Stefan Wahren) - Fix checkpatch warnings - Use PIN_CONFIG_END+1 for bcm2835_pinconf_param for our pull legacy configuration (Suggested by Linus Walleij) - Only resend patch 2+3 - Add Stephen Warren for subsequent postings Changes since v4: (Suggested by Rob Herring) - Change dt-bindings docs driver reference to hardware in case the BCM2835 pin configuration and multiplexing Changes since v3: (Suggested by Stefan Wahren) - Change dt-bindings docs patch order and subject Changes since v2: (Suggested by Eric Anholt) - Remove PACK and UNPACK macros - Use pinconf_to_config_* functions (Suggested by Stefan Wahren) - Fold Kconfig changes with the driver changes in a single patch - Add devicetree bindings documentations about generic properties support - Add devicetree bindings maintainers Matheus Castello (2): pinctrl: bcm2835: Add support for generic pinctrl binding pinctrl: bcm2835: Add support for output-low output-high properties drivers/pinctrl/bcm/Kconfig | 1 + drivers/pinctrl/bcm/pinctrl-bcm2835.c | 100 +- 2 files changed, 64 insertions(+), 37 deletions(-) -- 2.7.4
[PATCH v6 2/3] pinctrl: bcm2835: Add support for generic pinctrl binding
To keep driver up to date we add generic pinctrl binding support, which
covers the features used in this driver and has additional node properties
that this SoC has compatibility, so enabling future implementations of
these properties without the need to create new node properties in the
device trees.
The logic of this change maintain the old brcm legacy binding support in
order to keep the ABI stable.
Signed-off-by: Matheus Castello
---
A brief explanation of what I did:
Add pinconf-generic header for use the defines and pinctrl-generic API.
Add dt-bindings pinctrl bcm2835 header to use functions selections and
pulls definitions, which functions definitions where duplicated in the
enum bcm2835_fsel, I removed the duplicate defines from enum.
Assign PIN_CONFIG_END+1 offset for bcm2835_pinconf_param pull legacy param to
avoid potential conflicts.
In the bcm2835_pctl_dt_node_to_map_pull I used the generic macro for
pack the legacy param and arguments, since it will be unpacked along with
generic properties that is packed with this same macro.
In bcm2835_pctl_dt_node_to_map I thougt it was better, and simpler, to use
pinctrl-generic parse code instead of parsing it inside the driver, so code
first check for generic binding parse, if something is parsed then it is
assumed that are using the new generic style, and when nothing is found then
parse continues to search for legacy properties.
In the bcm2835_pinconf_set was changed the unpack legacy by the generic, and
was added a switch for the parameter tests, since pinctrl generic uses 3
properties to define the states of the pull instead of one with arguments, that
was the reason too that bcm2835_pull_config_set function was added, for reuse
the code that set state of pull.
drivers/pinctrl/bcm/Kconfig | 1 +
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 95 +--
2 files changed, 59 insertions(+), 37 deletions(-)
diff --git a/drivers/pinctrl/bcm/Kconfig b/drivers/pinctrl/bcm/Kconfig
index e8c4e4f..0f38d51 100644
--- a/drivers/pinctrl/bcm/Kconfig
+++ b/drivers/pinctrl/bcm/Kconfig
@@ -20,6 +20,7 @@ config PINCTRL_BCM2835
bool
select PINMUX
select PINCONF
+ select GENERIC_PINCONF
select GPIOLIB_IRQCHIP
config PINCTRL_IPROC_GPIO
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 785c366..0231107 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -36,11 +36,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#define MODULE_NAME "pinctrl-bcm2835"
#define BCM2835_NUM_GPIOS 54
@@ -72,13 +74,9 @@
enum bcm2835_pinconf_param {
/* argument: bcm2835_pinconf_pull */
- BCM2835_PINCONF_PARAM_PULL,
+ BCM2835_PINCONF_PARAM_PULL = 0x80,
};
-#define BCM2835_PINCONF_PACK(_param_, _arg_) ((_param_) << 16 | (_arg_))
-#define BCM2835_PINCONF_UNPACK_PARAM(_conf_) ((_conf_) >> 16)
-#define BCM2835_PINCONF_UNPACK_ARG(_conf_) ((_conf_) & 0x)
-
struct bcm2835_pinctrl {
struct device *dev;
void __iomem *base;
@@ -213,14 +211,6 @@ static const char * const bcm2835_gpio_groups[] = {
};
enum bcm2835_fsel {
- BCM2835_FSEL_GPIO_IN = 0,
- BCM2835_FSEL_GPIO_OUT = 1,
- BCM2835_FSEL_ALT0 = 4,
- BCM2835_FSEL_ALT1 = 5,
- BCM2835_FSEL_ALT2 = 6,
- BCM2835_FSEL_ALT3 = 7,
- BCM2835_FSEL_ALT4 = 3,
- BCM2835_FSEL_ALT5 = 2,
BCM2835_FSEL_COUNT = 8,
BCM2835_FSEL_MASK = 0x7,
};
@@ -714,7 +704,7 @@ static int bcm2835_pctl_dt_node_to_map_pull(struct
bcm2835_pinctrl *pc,
configs = kzalloc(sizeof(*configs), GFP_KERNEL);
if (!configs)
return -ENOMEM;
- configs[0] = BCM2835_PINCONF_PACK(BCM2835_PINCONF_PARAM_PULL, pull);
+ configs[0] = pinconf_to_config_packed(BCM2835_PINCONF_PARAM_PULL, pull);
map->type = PIN_MAP_TYPE_CONFIGS_PIN;
map->data.configs.group_or_pin = bcm2835_gpio_pins[pin].name;
@@ -727,7 +717,7 @@ static int bcm2835_pctl_dt_node_to_map_pull(struct
bcm2835_pinctrl *pc,
static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev *pctldev,
struct device_node *np,
- struct pinctrl_map **map, unsigned *num_maps)
+ struct pinctrl_map **map, unsigned int *num_maps)
{
struct bcm2835_pinctrl *pc = pinctrl_dev_get_drvdata(pctldev);
struct property *pins, *funcs, *pulls;
@@ -736,6 +726,12 @@ static int bcm2835_pctl_dt_node_to_map(struct pinctrl_dev
*pctldev,
int i, err;
u32 pin, func, pull;
+ /* Check for generic binding in this node */
+ err = pinconf_generic_dt_node_to_map_all(pctldev, np, map, num_maps);
+ if (err || *num_maps)
+ return err;
+
+ /* Generic binding did not find anything continue with legacy parse */
pins = of_find_property(np, "brcm,pins", NULL);
Re: [PATCH] staging: mt7621-eth: fix line over 80 char / extra line in mtk_set_link_ksettings()
On Thu, Apr 26, 2018 at 09:29:09PM -0300, Jefferson Capovilla wrote: > Fix 'line over 80 characters' issue found by checkpatch.pl script in > mtk_set_link_ksettings(). > Fix extra line before end of function. That is two different things, please break this up into two different emails and send them as a patch series. thanks, greg k-h
Re: [PATCH v4 00/10] Add the I3C subsystem
On Mon, Apr 23, 2018 at 07:56:46PM +0200, Greg Kroah-Hartman wrote: > On Mon, Apr 23, 2018 at 07:38:14PM +0200, Boris Brezillon wrote: > > Hi, > > > > On Fri, 30 Mar 2018 09:47:41 +0200 > > Boris Brezillon wrote: > > > > > This patch series is a proposal for a new I3C subsystem. > > > > This v4 has been sent almost a month ago and I didn't get any feedback > > so far apart from Rob's R-b. Greg, is there any chance we can get these > > patches merged in 4.18? If not, could you tell me what should be > > addressed/improved/reworked? > > I'll look over it later this week, thanks. At first glance, it would be great to have at least one other reviewed-by or signed-off-by on the main code here. I don't want to be the only one to have to review it :) thanks, greg k-h
Re: [PATCH v4 03/10] i3c: Add sysfs ABI spec
On Fri, Mar 30, 2018 at 09:47:44AM +0200, Boris Brezillon wrote: > Document sysfs files/directories/symlinks exposed by the I3C subsystem. > > Signed-off-by: Boris Brezillon > --- > Changes in v2: > - new patch > --- > Documentation/ABI/testing/sysfs-bus-i3c | 95 > + > 1 file changed, 95 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c > > diff --git a/Documentation/ABI/testing/sysfs-bus-i3c > b/Documentation/ABI/testing/sysfs-bus-i3c > new file mode 100644 > index ..5e88cc093e0e > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-bus-i3c > @@ -0,0 +1,95 @@ > +What:/sys/bus/i3c/devices/i3c- > +KernelVersion: 4.16 Wrong kernel versions :)
Re: RW GDT replaced by Read-Only GDT and a GPL Interface
On Tue, Apr 17, 2018 at 05:33:25PM -0400, Gregory Panic wrote: > Hi, > > I have been working on a VMX driver for a custom hypervisor which > depends on features that KVM is not built for. Up until recently > (4.12.x), our module has been working just fine. When we started to > build support for Ubuntu 18.04 (4.15.x+), we ran into an issue. > > Unfortunately the following commits broke functionality, causing > kernel segfaults, due to a placing the GDT in the FIXMAP area, and > setting that mapping to Read-Only. > #69218e47994da614e7af600bf06887750ab6657a > and > #45fc8757d1d2128e342b4e7ef39adedf7752faac > > Up until now, the GDT has been Read-Write, which allowed for resetting > the TSS to available, and then Reloading it after a VMExit. The KVM > and Xen work-arounds for this were implemented by creating a GPL'd > interface to remap the GDT to the original Read/Write mapping and then > back. > > Up to this point we've been able to maintain independence from GPL, As has been stated numberous times, the lack of EXPORT_SYMBOL_GPL() does NOT mean that the interface you are using is not covered under the GPL license of the kernel. Please consult with an IP lawyer for the details if you are interested. Best of luck with your driver! greg k-h
