Re: [PATCH v2 03/10] kexec: separate PageHighMem() and PageHighMemZone() use case
On Mon, May 04, 2020 at 09:03:56AM -0500, Eric W. Biederman wrote: > > I have added in the kexec mailling list. > > Looking at the patch we are discussing it appears that the kexec code > could be doing much better in highmem situations today but is not. Sound great! > > > Joonsoo Kim writes: > > > 2020년 5월 1일 (금) 오후 11:06, Eric W. Biederman 님이 작성: > >> > >> js1...@gmail.com writes: > >> > >> > From: Joonsoo Kim > >> > > >> > Until now, PageHighMem() is used for two different cases. One is to check > >> > if there is a direct mapping for this page or not. The other is to check > >> > the zone of this page, that is, weather it is the highmem type zone or > >> > not. > >> > > >> > Now, we have separate functions, PageHighMem() and PageHighMemZone() for > >> > each cases. Use appropriate one. > >> > > >> > Note that there are some rules to determine the proper macro. > >> > > >> > 1. If PageHighMem() is called for checking if the direct mapping exists > >> > or not, use PageHighMem(). > >> > 2. If PageHighMem() is used to predict the previous gfp_flags for > >> > this page, use PageHighMemZone(). The zone of the page is related to > >> > the gfp_flags. > >> > 3. If purpose of calling PageHighMem() is to count highmem page and > >> > to interact with the system by using this count, use PageHighMemZone(). > >> > This counter is usually used to calculate the available memory for an > >> > kernel allocation and pages on the highmem zone cannot be available > >> > for an kernel allocation. > >> > 4. Otherwise, use PageHighMemZone(). It's safe since it's implementation > >> > is just copy of the previous PageHighMem() implementation and won't > >> > be changed. > >> > > >> > I apply the rule #2 for this patch. > >> > >> Hmm. > >> > >> What happened to the notion of deprecating and reducing the usage of > >> highmem? I know that we have some embedded architectures where it is > >> still important but this feels like it flies in the face of that. > > > > AFAIK, deprecating highmem requires some more time and, before then, > > we need to support it. > > But it at least makes sense to look at what we are doing with highmem > and ask if it makes sense. > > >> This part of kexec would be much more maintainable if it had a proper > >> mm layer helper that tested to see if the page matched the passed in > >> gfp flags. That way the mm layer could keep changing and doing weird > >> gyrations and this code would not care. > > > > Good idea! I will do it. > > > >> > >> What would be really helpful is if there was a straight forward way to > >> allocate memory whose physical address fits in the native word size. > >> > >> > >> All I know for certain about this patch is that it takes a piece of code > >> that looked like it made sense, and transfroms it into something I can > >> not easily verify, and can not maintain. > > > > Although I decide to make a helper as you described above, I don't > > understand why you think that a new code isn't maintainable. It is just > > the same thing with different name. Could you elaborate more why do > > you think so? > > Because the current code is already wrong. It does not handle > the general case of what it claims to handle. When the only distinction > that needs to be drawn is highmem or not highmem that is likely fine. > But now you are making it possible to draw more distinctions. At which > point I have no idea which distinction needs to be drawn. > > > The code and the logic is about 20 years old. When it was written I > don't recally taking numa seriously and the kernel only had 3 zones > as I recall (DMA aka the now deprecated GFP_DMA, NORMAL, and HIGH). > > The code attempts to work around limitations of those old zones amd play > nice in a highmem world by allocating memory HIGH memory and not using > it if the memory was above 4G ( on 32bit ). > > Looking the kernel now has GFP_DMA32 so on 32bit with highmem we should > probably be using that, when allocating memory. > >From quick investigation, unfortunately, ZONE_DMA32 isn't available on x86 32bit now so using GFP_DMA32 to allocate memory below 4G would not work. Enabling ZONE_DMA32 on x86 32bit would be not simple, so, IMHO, it would be better to leave the code as it is. > > > Further in dealing with this memory management situation we only > have two situations we call kimage_alloc_page. > > For an indirect page which must have a valid page_address(page). > We could probably relax that if we cared to. > > For a general kexec page to store the next kernel in until we switch. > The general pages can be in high memory. > > In a highmem world all of those pages should be below 32bit. > > > > Given that we fundamentally have two situations my sense is that we > should just refactor the code so that we never have to deal with: > > > /* The old page I have found cannot be a >* destination page, so return it if it's >*
Re: [PATCH 0/3] kasan: memorize and print call_rcu stack
> On May 6, 2020, at 1:19 AM, Walter Wu wrote: > > This patchset improves KASAN reports by making them to have > call_rcu() call stack information. It is helpful for programmers > to solve use-after-free or double-free memory issue. > > The KASAN report was as follows(cleaned up slightly): > > BUG: KASAN: use-after-free in kasan_rcu_reclaim+0x58/0x60 > > Freed by task 0: > save_stack+0x24/0x50 > __kasan_slab_free+0x110/0x178 > kasan_slab_free+0x10/0x18 > kfree+0x98/0x270 > kasan_rcu_reclaim+0x1c/0x60 > rcu_core+0x8b4/0x10f8 > rcu_core_si+0xc/0x18 > efi_header_end+0x238/0xa6c > > First call_rcu() call stack: > save_stack+0x24/0x50 > kasan_record_callrcu+0xc8/0xd8 > call_rcu+0x190/0x580 > kasan_rcu_uaf+0x1d8/0x278 > > Last call_rcu() call stack: > (stack is not available) > > > Add new CONFIG option to record first and last call_rcu() call stack > and KASAN report prints two call_rcu() call stack. > > This option doesn't increase the cost of memory consumption. It is > only suitable for generic KASAN. I don’t understand why this needs to be a Kconfig option at all. If call_rcu() stacks are useful in general, then just always gather those information. How do developers judge if they need to select this option or not?
[no subject]
Subject: [PATCH v6] MIPS: Truncate link address into 32bit for 32bit kernel
In-Reply-To: <20200413062651.3992652-1-jiaxun.y...@flygoat.com>
LLD failed to link vmlinux with 64bit load address for 32bit ELF
while bfd will strip 64bit address into 32bit silently.
To fix LLD build, we should truncate load address provided by platform
into 32bit for 32bit kernel.
Signed-off-by: Jiaxun Yang
Link: https://github.com/ClangBuiltLinux/linux/issues/786
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784
Reviewed-by: Fangrui Song
Reviewed-by: Kees Cook
Tested-by: Nathan Chancellor
Cc: Maciej W. Rozycki
---
V2: Take MaskRay's shell magic.
V3: After spent an hour on dealing with special character issue in
Makefile, I gave up to do shell hacks and write a util in C instead.
Thanks Maciej for pointing out Makefile variable problem.
v4: Finally we managed to find a Makefile method to do it properly
thanks to Kees. As it's too far from the initial version, I removed
Review & Test tag from Nick and Fangrui and Cc instead.
v5: Care vmlinuz as well.
v6: Rename to LIKER_LOAD_ADDRESS
---
arch/mips/Makefile | 13 -
arch/mips/boot/compressed/Makefile | 2 +-
arch/mips/kernel/vmlinux.lds.S | 2 +-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index e1c44aed8156..68c0f22fefc0 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -288,12 +288,23 @@ ifdef CONFIG_64BIT
endif
endif
+# When linking a 32-bit executable the LLVM linker cannot cope with a
+# 32-bit load address that has been sign-extended to 64 bits. Simply
+# remove the upper 32 bits then, as it is safe to do so with other
+# linkers.
+ifdef CONFIG_64BIT
+ load-ld = $(load-y)
+else
+ load-ld = $(subst 0x,0x,$(load-y))
+endif
+
KBUILD_AFLAGS += $(cflags-y)
KBUILD_CFLAGS += $(cflags-y)
-KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y)
+KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y)
-DLINKER_LOAD_ADDRESS=$(load-ld)
KBUILD_CPPFLAGS += -DDATAOFFSET=$(if $(dataoffset-y),$(dataoffset-y),0)
bootvars-y = VMLINUX_LOAD_ADDRESS=$(load-y) \
+ LINKER_LOAD_ADDRESS=$(load-ld) \
VMLINUX_ENTRY_ADDRESS=$(entry-y) \
PLATFORM="$(platform-y)" \
ITS_INPUTS="$(its-y)"
diff --git a/arch/mips/boot/compressed/Makefile
b/arch/mips/boot/compressed/Makefile
index 0df0ee8a298d..3d391256ab7e 100644
--- a/arch/mips/boot/compressed/Makefile
+++ b/arch/mips/boot/compressed/Makefile
@@ -90,7 +90,7 @@ ifneq ($(zload-y),)
VMLINUZ_LOAD_ADDRESS := $(zload-y)
else
VMLINUZ_LOAD_ADDRESS = $(shell $(obj)/calc_vmlinuz_load_addr \
- $(obj)/vmlinux.bin $(VMLINUX_LOAD_ADDRESS))
+ $(obj)/vmlinux.bin $(LINKER_LOAD_ADDRESS))
endif
UIMAGE_LOADADDR = $(VMLINUZ_LOAD_ADDRESS)
diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
index a5f00ec73ea6..5226cd8e4bee 100644
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -55,7 +55,7 @@ SECTIONS
/* . = 0xa830; */
. = 0x8030;
#endif
- . = VMLINUX_LOAD_ADDRESS;
+ . = LINKER_LOAD_ADDRESS;
/* read-only */
_text = .; /* Text and read-only data */
.text : {
MAINTAINERS: Wrong ordering in DYNAMIC INTERRUPT MODERATION
Hi Jakub,
with your commit 9b038086f06b ("docs: networking: convert DIM to RST"),
visible on next-20200505, ./scripts/checkpatch.pl -f MAINTAINERS
complains:
WARNING: Misordered MAINTAINERS entry - list file patterns in alphabetic order
#5966: FILE: MAINTAINERS:5966:
+F: lib/dim/
+F: Documentation/networking/net_dim.rst
This is due to wrong ordering of the entries in your submission. If you
would like me to send you a patch fixing that, please just let me know.
It is a recent addition to checkpatch.pl to report ordering problems in
MAINTAINERS, so you might have not seen that at submission time.
Best regards,
Lukas
[PATCH v2 5/5] [media] mtk-mdp: Remove mtk_mdp_comp.id and supporting functionality
Since components are registered in a list, the numeric component id that
specified a location in an array is not necessary.
Signed-off-by: ei...@chromium.org
Signed-off-by: Eizan Miyamoto
---
Changes in v1:
- rebase onto linux-next/master to pick up
757570f11fa4b0ce5472a6583de6f06e996a8527
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 60 +++
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 19 +-
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 10 +---
3 files changed, 11 insertions(+), 78 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index da2bdad7a8d1..362fff924aef 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -14,46 +14,6 @@
#include "mtk_mdp_comp.h"
-static const char * const mtk_mdp_comp_stem[MTK_MDP_COMP_TYPE_MAX] = {
- "mdp-rdma",
- "mdp-rsz",
- "mdp-wdma",
- "mdp-wrot",
-};
-
-struct mtk_mdp_comp_match {
- enum mtk_mdp_comp_type type;
- int alias_id;
-};
-
-static const struct mtk_mdp_comp_match mtk_mdp_matches[MTK_MDP_COMP_ID_MAX] = {
- { MTK_MDP_RDMA, 0 },
- { MTK_MDP_RDMA, 1 },
- { MTK_MDP_RSZ, 0 },
- { MTK_MDP_RSZ, 1 },
- { MTK_MDP_RSZ, 2 },
- { MTK_MDP_WDMA, 0 },
- { MTK_MDP_WROT, 0 },
- { MTK_MDP_WROT, 1 },
-};
-
-int mtk_mdp_comp_get_id(struct device *dev, struct device_node *node,
- enum mtk_mdp_comp_type comp_type)
-{
- int id = of_alias_get_id(node, mtk_mdp_comp_stem[comp_type]);
- int i;
-
- for (i = 0; i < ARRAY_SIZE(mtk_mdp_matches); i++) {
- if (comp_type == mtk_mdp_matches[i].type &&
- id == mtk_mdp_matches[i].alias_id)
- return i;
- }
-
- dev_err(dev, "Failed to get id. type: %d, id: %d\n", comp_type, id);
-
- return -EINVAL;
-}
-
void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
{
int i, err;
@@ -62,8 +22,8 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
mtk_mdp_comp *comp)
err = mtk_smi_larb_get(comp->larb_dev);
if (err)
dev_err(dev,
- "failed to get larb, err %d. type:%d id:%d\n",
- err, comp->type, comp->id);
+ "failed to get larb, err %d. type:%d\n",
+ err, comp->type);
}
for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
@@ -72,8 +32,8 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
mtk_mdp_comp *comp)
err = clk_prepare_enable(comp->clk[i]);
if (err)
dev_err(dev,
- "failed to enable clock, err %d. type:%d id:%d i:%d\n",
- err, comp->type, comp->id, i);
+ "failed to enable clock, err %d. type:%d i:%d\n",
+ err, comp->type, i);
}
}
@@ -92,21 +52,15 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct
mtk_mdp_comp *comp)
}
int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
- struct mtk_mdp_comp *comp, enum mtk_mdp_comp_id comp_id)
+ struct mtk_mdp_comp *comp,
+ enum mtk_mdp_comp_type comp_type)
{
struct device_node *larb_node;
struct platform_device *larb_pdev;
int i;
- if (comp_id < 0 || comp_id >= MTK_MDP_COMP_ID_MAX) {
- dev_err(dev, "Invalid comp_id %d\n", comp_id);
- return -EINVAL;
- }
-
- INIT_LIST_HEAD(>node);
comp->dev_node = of_node_get(node);
- comp->id = comp_id;
- comp->type = mtk_mdp_matches[comp_id].type;
+ comp->type = comp_type;
for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
comp->clk[i] = of_clk_get(node, i);
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 1f745891c6c3..1bf0242cce46 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -22,18 +22,6 @@ enum mtk_mdp_comp_type {
MTK_MDP_COMP_TYPE_MAX,
};
-enum mtk_mdp_comp_id {
- MTK_MDP_COMP_RDMA0,
- MTK_MDP_COMP_RDMA1,
- MTK_MDP_COMP_RSZ0,
- MTK_MDP_COMP_RSZ1,
- MTK_MDP_COMP_RSZ2,
- MTK_MDP_COMP_WDMA,
- MTK_MDP_COMP_WROT0,
- MTK_MDP_COMP_WROT1,
- MTK_MDP_COMP_ID_MAX,
-};
-
/**
* struct mtk_mdp_comp - the MDP's function component data
* @node: list node to track sibing MDP components
@@ -41,7 +29,6 @@ enum mtk_mdp_comp_id {
* @clk: clocks required for component
* @larb_dev: SMI device required for component
* @type: component type
- * @id:component ID
*/
struct mtk_mdp_comp {
struct
[PATCH v2 4/5] [media] mtk-mdp: convert mtk_mdp_dev.comp array to list
The functions mtk_mdp_register/unregister_component have been created to
add / remove items from the list of components.
This will eventually enable us to specify a list of components in the
device tree instead of hardcoding them into this driver.
The list is modified by a single thread at driver probe time, and will
not be traversed by another thread until the call to pm_runtime_enable
at the end of probing.
Signed-off-by: ei...@chromium.org
Reviewed-by: Enric Balletbo I Serra
Signed-off-by: Eizan Miyamoto
---
Changes in v1: None
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 1 +
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 +
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 46 +--
drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 10 +++-
4 files changed, 43 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index c76cd61fb178..da2bdad7a8d1 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -103,6 +103,7 @@ int mtk_mdp_comp_init(struct device *dev, struct
device_node *node,
return -EINVAL;
}
+ INIT_LIST_HEAD(>node);
comp->dev_node = of_node_get(node);
comp->id = comp_id;
comp->type = mtk_mdp_matches[comp_id].type;
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 3b83bd6e0d8b..1f745891c6c3 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -36,6 +36,7 @@ enum mtk_mdp_comp_id {
/**
* struct mtk_mdp_comp - the MDP's function component data
+ * @node: list node to track sibing MDP components
* @dev_node: component device node
* @clk: clocks required for component
* @larb_dev: SMI device required for component
@@ -43,6 +44,7 @@ enum mtk_mdp_comp_id {
* @id:component ID
*/
struct mtk_mdp_comp {
+ struct list_headnode;
struct device_node *dev_node;
struct clk *clk[2];
struct device *larb_dev;
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 17d155219ba2..40b9fda8b03b 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -55,19 +55,19 @@ MODULE_DEVICE_TABLE(of, mtk_mdp_of_ids);
static void mtk_mdp_clock_on(struct mtk_mdp_dev *mdp)
{
struct device *dev = >pdev->dev;
- int i;
+ struct mtk_mdp_comp *comp_node;
- for (i = 0; i < ARRAY_SIZE(mdp->comp); i++)
- mtk_mdp_comp_clock_on(dev, mdp->comp[i]);
+ list_for_each_entry(comp_node, >comp_list, node)
+ mtk_mdp_comp_clock_on(dev, comp_node);
}
static void mtk_mdp_clock_off(struct mtk_mdp_dev *mdp)
{
struct device *dev = >pdev->dev;
- int i;
+ struct mtk_mdp_comp *comp_node;
- for (i = 0; i < ARRAY_SIZE(mdp->comp); i++)
- mtk_mdp_comp_clock_off(dev, mdp->comp[i]);
+ list_for_each_entry(comp_node, >comp_list, node)
+ mtk_mdp_comp_clock_off(dev, comp_node);
}
static void mtk_mdp_wdt_worker(struct work_struct *work)
@@ -91,12 +91,25 @@ static void mtk_mdp_reset_handler(void *priv)
queue_work(mdp->wdt_wq, >wdt_work);
}
+void mtk_mdp_register_component(struct mtk_mdp_dev *mdp,
+ struct mtk_mdp_comp *comp)
+{
+ list_add(>comp_list, >node);
+}
+
+void mtk_mdp_unregister_component(struct mtk_mdp_dev *mdp,
+ struct mtk_mdp_comp *comp)
+{
+ list_del(>node);
+}
+
static int mtk_mdp_probe(struct platform_device *pdev)
{
struct mtk_mdp_dev *mdp;
struct device *dev = >dev;
struct device_node *node, *parent;
- int i, ret = 0;
+ struct mtk_mdp_comp *comp, *comp_temp;
+ int ret = 0;
mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
if (!mdp)
@@ -104,6 +117,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
mdp->id = pdev->id;
mdp->pdev = pdev;
+ INIT_LIST_HEAD(>comp_list);
INIT_LIST_HEAD(>ctx_list);
mutex_init(>lock);
@@ -124,7 +138,6 @@ static int mtk_mdp_probe(struct platform_device *pdev)
const struct of_device_id *of_id;
enum mtk_mdp_comp_type comp_type;
int comp_id;
- struct mtk_mdp_comp *comp;
of_id = of_match_node(mtk_mdp_comp_dt_ids, node);
if (!of_id)
@@ -150,13 +163,14 @@ static int mtk_mdp_probe(struct platform_device *pdev)
of_node_put(node);
goto err_comp;
}
- mdp->comp[comp_id] = comp;
ret = mtk_mdp_comp_init(dev, node, comp, comp_id);
if (ret) {
[PATCH v2 1/5] [media] mtk-mdp: remove mtk_mdp_comp.regs from mtk_mdp_comp.h
These fields are not used and can be removed.
Signed-off-by: ei...@chromium.org
Reviewed-by: Enric Balletbo I Serra
Signed-off-by: Eizan Miyamoto
---
Changes in v1: None
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 1 -
drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index 58abfbdfb82d..c76cd61fb178 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -106,7 +106,6 @@ int mtk_mdp_comp_init(struct device *dev, struct
device_node *node,
comp->dev_node = of_node_get(node);
comp->id = comp_id;
comp->type = mtk_mdp_matches[comp_id].type;
- comp->regs = of_iomap(node, 0);
for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
comp->clk[i] = of_clk_get(node, i);
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 998a4b953025..3b83bd6e0d8b 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -38,7 +38,6 @@ enum mtk_mdp_comp_id {
* struct mtk_mdp_comp - the MDP's function component data
* @dev_node: component device node
* @clk: clocks required for component
- * @regs: Mapped address of component registers.
* @larb_dev: SMI device required for component
* @type: component type
* @id:component ID
@@ -46,7 +45,6 @@ enum mtk_mdp_comp_id {
struct mtk_mdp_comp {
struct device_node *dev_node;
struct clk *clk[2];
- void __iomem*regs;
struct device *larb_dev;
enum mtk_mdp_comp_type type;
enum mtk_mdp_comp_idid;
--
2.26.2.526.g744177e7f7-goog
[PATCH v2 0/5] MTK MDP driver cleanups to prep for futher work
It most notably converts an array of MDP components to a list instead, but also removes some unused fields. This series of patches does some cleanup in preparation for futher work so that hardware video decode works on 4.19 and later kernels. We are planning on adding a dummy driver for the relevant MDP components that will be bound together using the component framework, which will enable calls to set up IOMMUs and LARBs, and make calls into pm_runtime. Changes in v2: - remove unnecessary error handling labels in favor of err_m2m_register - rebase onto linux-next/master to pick up 757570f11fa4b0ce5472a6583de6f06e996a8527 Eizan Miyamoto (5): [media] mtk-mdp: remove mtk_mdp_comp.regs from mtk_mdp_comp.h [media] mtk-mdp: handle vb2_dma_contig_set_max_seg_size errors during probe [media] mtk-mdp: handle vpu_wdt_reg_handler() errors during probe [media] mtk-mdp: convert mtk_mdp_dev.comp array to list [media] mtk-mdp: Remove mtk_mdp_comp.id and supporting functionality drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 60 ++-- drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 23 ++ drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 70 --- drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 10 ++- 4 files changed, 64 insertions(+), 99 deletions(-) -- 2.26.2.526.g744177e7f7-goog
[PATCH v2 3/5] [media] mtk-mdp: handle vpu_wdt_reg_handler() errors during probe
This is a cleanup to better handle errors during MDP probe.
Signed-off-by: ei...@chromium.org
Signed-off-by: Eizan Miyamoto
---
Changes in v1:
- remove unnecessary error handling labels in favor of err_m2m_register
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 9b24b8d46eb7..17d155219ba2 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -188,8 +188,12 @@ static int mtk_mdp_probe(struct platform_device *pdev)
}
mdp->vpu_dev = vpu_get_plat_device(pdev);
- vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
- VPU_RST_MDP);
+ ret = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
+ VPU_RST_MDP);
+ if (ret) {
+ dev_err(>dev, "Failed to register reset handler\n");
+ goto err_m2m_register;
+ }
platform_set_drvdata(pdev, mdp);
--
2.26.2.526.g744177e7f7-goog
[PATCH v2 2/5] [media] mtk-mdp: handle vb2_dma_contig_set_max_seg_size errors during probe
This is a cleanup to better handle errors during MDP probe.
Signed-off-by: ei...@chromium.org
Signed-off-by: Eizan Miyamoto
---
Changes in v1:
- remove unnecessary error handling labels in favor of err_m2m_register
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index aeaed2cf4458..9b24b8d46eb7 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -193,7 +193,11 @@ static int mtk_mdp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mdp);
- vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
+ ret = vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
+ if (ret) {
+ dev_err(>dev, "Failed to set vb2 dma mag seg size\n");
+ goto err_m2m_register;
+ }
pm_runtime_enable(dev);
dev_dbg(dev, "mdp-%d registered successfully\n", mdp->id);
--
2.26.2.526.g744177e7f7-goog
RE: [PATCH v2 2/2] PCI: hv: Retry PCI bus D0 entry when the first attempt failed with invalid device state
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: Tuesday, May 5, 2020 11:10 PM
> To: Wei Hu
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger ;
> wei@kernel.org; r...@kernel.org; bhelg...@google.com; linux-
> hyp...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Dexuan Cui ; Michael Kelley
>
> Subject: Re: [PATCH v2 2/2] PCI: hv: Retry PCI bus D0 entry when the first
> attempt failed with invalid device state
>
> On Fri, May 01, 2020 at 01:37:28PM +0800, Wei Hu wrote:
> > In the case of kdump, the PCI device was not cleanly shut down before
> > the kdump kernel starts. This causes the initial attempt of entering
> > D0 state in the kdump kernel to fail with invalid device state
> > returned from Hyper-V host.
> > When this happens, explicitly call PCI bus exit and retry to enter the
> > D0 state.
> >
> > Signed-off-by: Wei Hu
> > ---
> >v2: Incorporate review comments from Michael Kelley, Dexuan Cui and
> >Bjorn Helgaas
> >
> > drivers/pci/controller/pci-hyperv.c | 40
> > +++--
> > 1 file changed, 38 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pci-hyperv.c
> > b/drivers/pci/controller/pci-hyperv.c
> > index e6fac0187722..92092a47d3af 100644
> > --- a/drivers/pci/controller/pci-hyperv.c
> > +++ b/drivers/pci/controller/pci-hyperv.c
> > @@ -2739,6 +2739,8 @@ static void hv_free_config_window(struct
> hv_pcibus_device *hbus)
> > vmbus_free_mmio(hbus->mem_config->start,
> PCI_CONFIG_MMIO_LENGTH); }
> >
> > +static int hv_pci_bus_exit(struct hv_device *hdev, bool keep_devs);
> > +
> > /**
> > * hv_pci_enter_d0() - Bring the "bus" into the D0 power state
> > * @hdev: VMBus's tracking struct for this root PCI bus
> > @@ -2751,8 +2753,10 @@ static int hv_pci_enter_d0(struct hv_device
> *hdev)
> > struct pci_bus_d0_entry *d0_entry;
> > struct hv_pci_compl comp_pkt;
> > struct pci_packet *pkt;
> > + bool retry = true;
> > int ret;
> >
> > +enter_d0_retry:
> > /*
> > * Tell the host that the bus is ready to use, and moved into the
> > * powered-on state. This includes telling the host which region @@
> > -2779,6 +2783,38 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
> > if (ret)
> > goto exit;
> >
> > + /*
> > +* In certain case (Kdump) the pci device of interest was
> > +* not cleanly shut down and resource is still held on host
> > +* side, the host could return invalid device status.
> > +* We need to explicitly request host to release the resource
> > +* and try to enter D0 again.
> > +*/
> > + if (comp_pkt.completion_status < 0 && retry) {
> > + retry = false;
> > +
> > + dev_err(>device, "Retrying D0 Entry\n");
> > +
> > + /*
> > +* Hv_pci_bus_exit() calls hv_send_resource_released()
> > +* to free up resources of its child devices.
> > +* In the kdump kernel we need to set the
> > +* wslot_res_allocated to 255 so it scans all child
> > +* devices to release resources allocated in the
> > +* normal kernel before panic happened.
> > +*/
> > + hbus->wslot_res_allocated = 255;
>
> I'd rather write a specific function eg hv_pci_bus_shutdown() to make it
> explicit.
> Actually, isn't it something that should *always* be _enforced_ at host bridge
> probe time - regardless of the kernel you are booting on ?
>
It is only needed in kdump kernel when the normal kernel which just crashed
failed to deallocate the PCI resources cleanly. All the states have been taken
care of in the normal kernel without needing this.
Wei
MAINTAINERS: Wrong ordering in S390 PCI SUBSYSTEM
Hi Pierre,
with your commit de267a7c71ba ("s390/pci: Documentation for zPCI"),
visible on next-20200505, ./scripts/checkpatch.pl -f MAINTAINERS
complains:
WARNING: Misordered MAINTAINERS entry - list file patterns in alphabetic order
#14723: FILE: MAINTAINERS:14723:
+F: drivers/pci/hotplug/s390_pci_hpc.c
+F: Documentation/s390/pci.rst
This is due to wrong ordering of the entries in your submission. If you
would like me to send you a patch fixing that, please just let me know.
It is a recent addition to checkpatch.pl to report ordering problems in
MAINTAINERS, so you might have not seen that at submission time.
Best regards,
Lukas
RE: [PATCH v2 1/2] PCI: hv: Fix the PCI HyperV probe failure path to release resource properly
Hi Lorenzo,
Thanks for your review. Please see my comments inline.
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: Tuesday, May 5, 2020 11:03 PM
> To: Wei Hu
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger ;
> wei@kernel.org; r...@kernel.org; bhelg...@google.com; linux-
> hyp...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Dexuan Cui ; Michael Kelley
>
> Subject: Re: [PATCH v2 1/2] PCI: hv: Fix the PCI HyperV probe failure path to
> release resource properly
>
> On Fri, May 01, 2020 at 01:36:17PM +0800, Wei Hu wrote:
> > Some error cases in hv_pci_probe() were not handled. Fix these error
> > paths to release the resourses and clean up the state properly.
>
> This patch does more than that. It adds a variable to store the number of
> slots
> actually allocated - I presume to free only allocated on slots on the exit
> path.
>
> Two patches required I am afraid.
Well, adding this variable is needed to make the call of "(void)
hv_pci_bus_exit(hdev, true)"
at the end to work and clean up the PCI state in the failure path. Just adding
this variable
would not make any changes. So I think it may be better to put them in single
patch?
>
> > Signed-off-by: Wei Hu
> > ---
> > drivers/pci/controller/pci-hyperv.c | 20
> > 1 file changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pci-hyperv.c
> > b/drivers/pci/controller/pci-hyperv.c
> > index e15022ff63e3..e6fac0187722 100644
> > --- a/drivers/pci/controller/pci-hyperv.c
> > +++ b/drivers/pci/controller/pci-hyperv.c
> > @@ -480,6 +480,9 @@ struct hv_pcibus_device {
> >
> > struct workqueue_struct *wq;
> >
> > + /* Highest slot of child device with resources allocated */
> > + int wslot_res_allocated;
>
> I don't understand why you need an int rather than a u32.
>
> Furthermore, I think a bitmap is more appropriate for what this variable is
> used
> for.
So it can use a negative value (-1 in this case) to indicated none of any
resources
has been allocated. Currently value between 0-255 indicating some resources
have been allocated. Of course I can use 0x to indicate that if it were
u32. But
it wouldn't make much difference, would it?
It would take 32 bytes for total 256 child slots in bitmap, while it only takes
4 bytes
using int. It is not in critical path so scanning from the location one by one
is not a big
deal.
>
> > +
> > /* hypercall arg, must not cross page boundary */
> > struct hv_retarget_device_interrupt retarget_msi_interrupt_params;
> >
> > @@ -2847,7 +2850,7 @@ static int hv_send_resources_allocated(struct
> hv_device *hdev)
> > struct hv_pci_dev *hpdev;
> > struct pci_packet *pkt;
> > size_t size_res;
> > - u32 wslot;
> > + int wslot;
> > int ret;
> >
> > size_res = (hbus->protocol_version < PCI_PROTOCOL_VERSION_1_2)
> @@
> > -2900,6 +2903,8 @@ static int hv_send_resources_allocated(struct hv_device
> *hdev)
> > comp_pkt.completion_status);
> > break;
> > }
> > +
> > + hbus->wslot_res_allocated = wslot;
> > }
> >
> > kfree(pkt);
> > @@ -2918,10 +2923,10 @@ static int hv_send_resources_released(struct
> hv_device *hdev)
> > struct hv_pcibus_device *hbus = hv_get_drvdata(hdev);
> > struct pci_child_message pkt;
> > struct hv_pci_dev *hpdev;
> > - u32 wslot;
> > + int wslot;
> > int ret;
> >
> > - for (wslot = 0; wslot < 256; wslot++) {
> > + for (wslot = hbus->wslot_res_allocated; wslot >= 0; wslot--) {
> > hpdev = get_pcichild_wslot(hbus, wslot);
> > if (!hpdev)
> > continue;
> > @@ -2936,8 +2941,12 @@ static int hv_send_resources_released(struct
> hv_device *hdev)
> >VM_PKT_DATA_INBAND, 0);
> > if (ret)
> > return ret;
> > +
> > + hbus->wslot_res_allocated = wslot - 1;
>
> Do you really need to set it at every loop iteration ?
>
> Moreover, I think a bitmap is better suited for what you are doing, given that
> you may skip some loop indexes on !hpdev.
>
The value is set in the loop whenever a resource was successfully released. It
could
happen that it failed in the next iteration so the last one which had succeeded
would be
recorded in this variable. It is needed at the end of loop when this
iteration succeeds.
Once again since it is not in the critical path, just using an signed integer
is straightforward,
less error prone and a bit easier to maintain than bitmap in my opinion.
> > }
> >
> > + hbus->wslot_res_allocated = -1;
> > +
> > return 0;
> > }
> >
> > @@ -3037,6 +3046,7 @@ static int hv_pci_probe(struct hv_device *hdev,
> > if (!hbus)
> > return -ENOMEM;
> > hbus->state = hv_pcibus_init;
> > + hbus->wslot_res_allocated = -1;
> >
> > /*
> > * The PCI bus "domain" is what is
[PATCH v2 RESEND] MAINTAINERS: rectify MMP SUPPORT after moving cputype.h
Commit 32adcaa010fa ("ARM: mmp: move cputype.h to include/linux/soc/")
added a file entry that does not point to the intended file location.
Since then, ./scripts/get_maintainer.pl --self-test complains:
warning: no file matches F: linux/soc/mmp/
Rectify the MAINTAINERS entry now.
Fixes: 32adcaa010fa ("ARM: mmp: move cputype.h to include/linux/soc/")
Signed-off-by: Lukas Bulwahn
---
Jiri, please pick this patch.
v1 & v1-RESEND: was ignored.
v1 -> v2:
- v1 does not apply after reordering MAINTAINERS, i.e., commit 4400b7d68f6e
("MAINTAINERS: sort entries by entry name") and commit 3b50142d8528
("MAINTAINERS: sort field names for all entries").
- PATCH v2 applies on v5.7-rc1 now. Please pick v2 instead of v1.
v2-resend:
- still applies on v5.7-rc4 and next-20200505
- asking for inclusion through trivial tree, as maintainers are not
responding.
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db31497..a0fef0c33ba5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11327,7 +11327,7 @@ S: Odd Fixes
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp.git
F: arch/arm/boot/dts/mmp*
F: arch/arm/mach-mmp/
-F: linux/soc/mmp/
+F: include/linux/soc/mmp/
MMP USB PHY DRIVERS
R: Lubomir Rintel
--
2.17.1
Re: [PATCH v3 1/2] arm: rpi: Add function to trigger VL805's firmware load
Hi Nicolas, On Wed, May 6, 2020 at 12:26 AM Nicolas Saenz Julienne wrote: > > On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware > may either be loaded directly from an EEPROM or, if not present, by the > SoC's VideCore (the SoC's co-processor). Introduce the function that > informs VideCore that VL805 may need its firmware loaded. > I still did not get it. Without the firmware being loaded, does xHCI on RPi 4 still work? What exact functionality does the firmware provide? > Signed-off-by: Nicolas Saenz Julienne > > --- > Changes since v2: > - Correct wrong function name in comment > - Add better comment on rpi_firmware_init_vl805() > > Changes since v1: > - Rename function so it's not mistaken with regular firmware loading > > arch/arm/mach-bcm283x/include/mach/mbox.h | 13 +++ > arch/arm/mach-bcm283x/include/mach/msg.h | 7 > arch/arm/mach-bcm283x/msg.c | 45 +++ > 3 files changed, 65 insertions(+) > Regards, Bin
Re: [PATCH] uprobes: ensure that uprobe->offset and ->ref_ctr_offset are properly aligned
* Oleg Nesterov [2020-05-04 18:47:25]: > uprobe_write_opcode() must not cross page boundary; prepare_uprobe() > relies on arch_uprobe_analyze_insn() which should validate "vaddr" but > some architectures (csky, s390, and sparc) don't do this. > > We can remove the BUG_ON() check in prepare_uprobe() and validate the > offset early in __uprobe_register(). The new IS_ALIGNED() check matches > the alignment check in arch_prepare_kprobe() on supported architectures, > so I think that all insns must be aligned to UPROBE_SWBP_INSN_SIZE. > > Another problem is __update_ref_ctr() which was wrong from the very > beginning, it can read/write outside of kmap'ed page unless "vaddr" is > aligned to sizeof(short), __uprobe_register() should check this too. > > Cc: sta...@vger.kernel.org > Reported-by: Linus Torvalds > Suggested-by: Linus Torvalds > Signed-off-by: Oleg Nesterov Thanks Oleg. Looks good to me. Reviewed-by: Srikar Dronamraju > --- -- Thanks and Regards Srikar Dronamraju
Re: [PATCH] virtio_net: fix lockdep warning on 32 bit
On 2020/5/6 上午8:01, Michael S. Tsirkin wrote:
When we fill up a receive VQ, try_fill_recv currently tries to count
kicks using a 64 bit stats counter. Turns out, on a 32 bit kernel that
uses a seqcount. sequence counts are "lock" constructs where you need to
make sure that writers are serialized.
In turn, this means that we mustn't run two try_fill_recv concurrently.
Which of course we don't. We do run try_fill_recv sometimes from a fully
preemptible context and sometimes from a softirq (napi) context.
However, when it comes to the seqcount, lockdep is trying to enforce
the rule that the same lock isn't accessed from preemptible
and softirq context. This causes a false-positive warning:
WARNING: inconsistent lock state
...
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
As a work around, shut down the warning by switching
to u64_stats_update_begin_irqsave - that works by disabling
interrupts on 32 bit only, is a NOP on 64 bit.
Reported-by: Thomas Gleixner
Suggested-by: Eric Dumazet
Signed-off-by: Michael S. Tsirkin
---
I'm not thrilled about this but this seems the best we can do for now.
Completely untested.
Thomas, can you pls let me know the config I need to trigger the warning
in question?
drivers/net/virtio_net.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 6594aab4910e..95393b61187f 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1243,9 +1243,11 @@ static bool try_fill_recv(struct virtnet_info *vi,
struct receive_queue *rq,
break;
} while (rq->vq->num_free);
if (virtqueue_kick_prepare(rq->vq) && virtqueue_notify(rq->vq)) {
- u64_stats_update_begin(>stats.syncp);
+ unsigned long flags;
+
+ flags = u64_stats_update_begin_irqsave(>stats.syncp);
rq->stats.kicks++;
- u64_stats_update_end(>stats.syncp);
+ u64_stats_update_end_irqrestore(>stats.syncp);
}
return !oom;
Acked-by: Jason Wang
[PATCH 3/3] kasan: add KASAN_RCU_STACK_RECORD documentation
This adds the documentation for the KASAN_RCU_STACK_RECORD config option. Signed-off-by: Walter Wu Cc: Andrey Ryabinin Cc: Dmitry Vyukov Cc: Alexander Potapenko Cc: Jonathan Corbet --- Documentation/dev-tools/kasan.rst | 21 + 1 file changed, 21 insertions(+) diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index c652d740735d..368ff0dad0d7 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -281,3 +281,24 @@ unmapped. This will require changes in arch-specific code. This allows ``VMAP_STACK`` support on x86, and can simplify support of architectures that do not have a fixed module region. + +CONFIG_KASAN_RCU_STACK_RECORD +~ + +With CONFIG_KASAN_RCU_STACK_RECORD, when call_rcu() is called, it will +store the call_rcu() call stack into slub alloc meta-data. The goal +is to print call_rcu() information in KASAN report. It is helpful for +use-after-free or double free memory issue. + +Record first and last call_rcu() call stack and print two call_rcu() +call stack in KASAN report. + +This option doesn't increase the cost of memory consumption, we add two +call_rcu() call stack into struct kasan_alloc_meta and size is 8 bytes. +Remove the free track from struct kasan_alloc_meta and size is 8 bytes. +So we don't enlarge the slub meta-data size. + +This option is only suitable for generic KASAN. Because the free track +is stored in freed object. so free track is valid information only when +it exists in the quarantine. If the slub object is in-use state, then +KASAN report doesn't print call_rcu() free track information. -- 2.18.0
[PATCH 2/3] kasan: record and print the free track
We add new KASAN_RCU_STACK_RECORD configuration option. It will move
free track from slub meta-data (struct kasan_alloc_meta) into freed object.
Because we hope this options doesn't enlarge slub meta-data size.
This option doesn't enlarge struct kasan_alloc_meta size.
- add two call_rcu() call stack into kasan_alloc_meta, size is 8 bytes.
- remove free track from kasan_alloc_meta, size is 8 bytes.
This option is only suitable for generic KASAN, because we move free track
into the freed object, so free track is valid information only when it
exists in quarantine. If the object is in-use state, then the KASAN report
doesn't print call_rcu() free track information.
[1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
Signed-off-by: Walter Wu
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Alexander Potapenko
---
mm/kasan/common.c | 10 +-
mm/kasan/report.c | 24 +---
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 32d422bdf127..13ec03e225a7 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -321,8 +321,15 @@ void kasan_record_callrcu(void *addr)
/* record last call_rcu() call stack */
alloc_info->rcu_free_stack[1] = save_stack(GFP_NOWAIT);
}
-#endif
+static void kasan_set_free_info(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ /* store free track into freed object */
+ set_track((struct kasan_track *)(object + BYTES_PER_WORD), GFP_NOWAIT);
+}
+
+#else
static void kasan_set_free_info(struct kmem_cache *cache,
void *object, u8 tag)
{
@@ -339,6 +346,7 @@ static void kasan_set_free_info(struct kmem_cache *cache,
set_track(_meta->free_track[idx], GFP_NOWAIT);
}
+#endif
void kasan_poison_slab(struct page *page)
{
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 7aaccc70b65b..f2b0c6b9dffa 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -175,8 +175,23 @@ static void kasan_print_rcu_free_stack(struct
kasan_alloc_meta *alloc_info)
print_track(_track, "Last call_rcu() call stack", true);
pr_err("\n");
}
-#endif
+static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
+ void *object, u8 tag, const void *addr)
+{
+ u8 *shadow_addr = (u8 *)kasan_mem_to_shadow(addr);
+
+ /*
+* Only the freed object can get free track,
+* because free track information is stored to freed object.
+*/
+ if (*shadow_addr == KASAN_KMALLOC_FREE)
+ return (struct kasan_track *)(object + BYTES_PER_WORD);
+ else
+ return NULL;
+}
+
+#else
static struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
void *object, u8 tag, const void *addr)
{
@@ -196,6 +211,7 @@ static struct kasan_track *kasan_get_free_track(struct
kmem_cache *cache,
return _meta->free_track[i];
}
+#endif
static void describe_object(struct kmem_cache *cache, void *object,
const void *addr, u8 tag)
@@ -208,8 +224,10 @@ static void describe_object(struct kmem_cache *cache, void
*object,
print_track(_info->alloc_track, "Allocated", false);
pr_err("\n");
free_track = kasan_get_free_track(cache, object, tag, addr);
- print_track(free_track, "Freed", false);
- pr_err("\n");
+ if (free_track) {
+ print_track(free_track, "Freed", false);
+ pr_err("\n");
+ }
#ifdef CONFIG_KASAN_RCU_STACK_RECORD
kasan_print_rcu_free_stack(alloc_info);
#endif
--
2.18.0
[PATCH v2 RESEND] MAINTAINERS: correct typo in new NXP LAYERSCAPE GEN4
Commit 3edeb49525bb ("dt-bindings: PCI: Add NXP Layerscape SoCs PCIe Gen4
controller") includes a new entry in MAINTAINERS, but slipped in a typo in
one of the file entries.
Hence, since then, ./scripts/get_maintainer.pl --self-test complains:
warning: no file matches F: \
drivers/pci/controller/mobibeil/pcie-layerscape-gen4.c
Correct the typo in PCI DRIVER FOR NXP LAYERSCAPE GEN4 CONTROLLER.
Signed-off-by: Lukas Bulwahn
---
Rob, please pick this patch (it is not urgent, though).
v1: https://lore.kernel.org/lkml/20200314142559.13505-1-lukas.bulw...@gmail.com/
- already received: Reviewed-by: Hou Zhiqiang
- Bjorn Helgaas' suggestion to squash this into commit 3edeb49525bb
("dt-bindings: PCI: Add NXP Layerscape SoCs PCIe Gen4 controller") before
merging upstream did not happen.
v1 -> v2:
- v1 does not apply after reordering MAINTAINERS, i.e., commit 4400b7d68f6e
("MAINTAINERS: sort entries by entry name") and commit 3b50142d8528
("MAINTAINERS: sort field names for all entries").
- PATCH v2 applies on v5.7-rc1 now. Please pick v2 instead of v1.
v2-resend:
- resend of v2:
https://lore.kernel.org/lkml/20200413070649.7014-1-lukas.bulw...@gmail.com/
- still applies to v5.7-rc4 and next-20200505
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db31497..0fd27329e6f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12941,7 +12941,7 @@ L: linux-...@vger.kernel.org
L: linux-arm-ker...@lists.infradead.org
S: Maintained
F: Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
-F: drivers/pci/controller/mobibeil/pcie-layerscape-gen4.c
+F: drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
PCI DRIVER FOR RENESAS R-CAR
M: Marek Vasut
--
2.17.1
[PATCH 1/3] rcu/kasan: record and print call_rcu() call stack
When call_rcu() is called, we store the call_rcu() call stack into
slub alloc meta-data, so that KASAN report prints call_rcu() information.
We add new KASAN_RCU_STACK_RECORD configuration option. It will record
first and last call_rcu() call stack and KASAN report will print two
call_rcu() call stack.
This option doesn't increase the cost of memory consumption. Because
we don't enlarge struct kasan_alloc_meta size.
- add two call_rcu() call stack into kasan_alloc_meta, size is 8 bytes.
- remove free track from kasan_alloc_meta, size is 8 bytes.
[1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
Signed-off-by: Walter Wu
Suggested-by: Dmitry Vyukov
Cc: Andrey Ryabinin
Cc: Dmitry Vyukov
Cc: Alexander Potapenko
Cc: Andrew Morton
Cc: Paul E. McKenney
Cc: Josh Triplett
Cc: Mathieu Desnoyers
Cc: Lai Jiangshan
Cc: Joel Fernandes
---
include/linux/kasan.h | 7 +++
kernel/rcu/tree.c | 4
lib/Kconfig.kasan | 11 +++
mm/kasan/common.c | 23 +++
mm/kasan/kasan.h | 12
mm/kasan/report.c | 33 +++--
6 files changed, 84 insertions(+), 6 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 31314ca7c635..5eeece6893cd 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -96,6 +96,12 @@ size_t kasan_metadata_size(struct kmem_cache *cache);
bool kasan_save_enable_multi_shot(void);
void kasan_restore_multi_shot(bool enabled);
+#ifdef CONFIG_KASAN_RCU_STACK_RECORD
+void kasan_record_callrcu(void *ptr);
+#else
+static inline void kasan_record_callrcu(void *ptr) {}
+#endif
+
#else /* CONFIG_KASAN */
static inline void kasan_unpoison_shadow(const void *address, size_t size) {}
@@ -165,6 +171,7 @@ static inline void kasan_remove_zero_shadow(void *start,
static inline void kasan_unpoison_slab(const void *ptr) { }
static inline size_t kasan_metadata_size(struct kmem_cache *cache) { return 0;
}
+static inline void kasan_record_callrcu(void *ptr) {}
#endif /* CONFIG_KASAN */
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 06548e2ebb72..145c79becf7b 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -57,6 +57,7 @@
#include
#include
#include
+#include
#include "../time/tick-internal.h"
#include "tree.h"
@@ -2694,6 +2695,9 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func)
trace_rcu_callback(rcu_state.name, head,
rcu_segcblist_n_cbs(>cblist));
+ if (IS_ENABLED(CONFIG_KASAN_RCU_STACK_RECORD))
+ kasan_record_callrcu(head);
+
/* Go handle any RCU core processing required. */
if (IS_ENABLED(CONFIG_RCU_NOCB_CPU) &&
unlikely(rcu_segcblist_is_offloaded(>cblist))) {
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 81f5464ea9e1..022934049cc2 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -158,6 +158,17 @@ config KASAN_VMALLOC
for KASAN to detect more sorts of errors (and to support vmapped
stacks), but at the cost of higher memory usage.
+config KASAN_RCU_STACK_RECORD
+ bool "Record and print call_rcu() call stack"
+ depends on KASAN_GENERIC
+ help
+ By default, the KASAN report doesn't print call_rcu() call stack.
+ It is very difficult to analyze memory issues(e.g., use-after-free).
+
+ Enabling this option will print first and last call_rcu() call stack.
+ It doesn't enlarge slub alloc meta-data size, so it doesn't increase
+ the cost of memory consumption.
+
config TEST_KASAN
tristate "Module for testing KASAN for bug detection"
depends on m && KASAN
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 2906358e42f0..32d422bdf127 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -299,6 +299,29 @@ struct kasan_free_meta *get_free_info(struct kmem_cache
*cache,
return (void *)object + cache->kasan_info.free_meta_offset;
}
+#ifdef CONFIG_KASAN_RCU_STACK_RECORD
+void kasan_record_callrcu(void *addr)
+{
+ struct page *page = kasan_addr_to_page(addr);
+ struct kmem_cache *cache;
+ struct kasan_alloc_meta *alloc_info;
+ void *object;
+
+ if (!(page && PageSlab(page)))
+ return;
+
+ cache = page->slab_cache;
+ object = nearest_obj(cache, page, addr);
+ alloc_info = get_alloc_info(cache, object);
+
+ if (!alloc_info->rcu_free_stack[0])
+ /* record first call_rcu() call stack */
+ alloc_info->rcu_free_stack[0] = save_stack(GFP_NOWAIT);
+ else
+ /* record last call_rcu() call stack */
+ alloc_info->rcu_free_stack[1] = save_stack(GFP_NOWAIT);
+}
+#endif
static void kasan_set_free_info(struct kmem_cache *cache,
void *object, u8 tag)
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index e8f37199d885..adc105b9cd07 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
[PATCH 0/3] kasan: memorize and print call_rcu stack
This patchset improves KASAN reports by making them to have call_rcu() call stack information. It is helpful for programmers to solve use-after-free or double-free memory issue. The KASAN report was as follows(cleaned up slightly): BUG: KASAN: use-after-free in kasan_rcu_reclaim+0x58/0x60 Freed by task 0: save_stack+0x24/0x50 __kasan_slab_free+0x110/0x178 kasan_slab_free+0x10/0x18 kfree+0x98/0x270 kasan_rcu_reclaim+0x1c/0x60 rcu_core+0x8b4/0x10f8 rcu_core_si+0xc/0x18 efi_header_end+0x238/0xa6c First call_rcu() call stack: save_stack+0x24/0x50 kasan_record_callrcu+0xc8/0xd8 call_rcu+0x190/0x580 kasan_rcu_uaf+0x1d8/0x278 Last call_rcu() call stack: (stack is not available) Add new CONFIG option to record first and last call_rcu() call stack and KASAN report prints two call_rcu() call stack. This option doesn't increase the cost of memory consumption. It is only suitable for generic KASAN. [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437 Walter Wu (3): rcu/kasan: record and print call_rcu() call stack kasan: record and print the free track kasan: add KASAN_RCU_STACK_RECORD documentation Documentation/dev-tools/kasan.rst | 21 + include/linux/kasan.h | 7 +++ kernel/rcu/tree.c | 5 + lib/Kconfig.kasan | 11 +++ mm/kasan/common.c | 31 +++ mm/kasan/kasan.h | 12 mm/kasan/report.c | 53 ++--- 7 files changed, 133 insertions(+), 7 deletions(-)
Re: [PATCH net v2 1/2] Revert "coallocate socket_wq with socket itself"
Hi SeongJae,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net/master]
url:
https://github.com/0day-ci/linux/commits/SeongJae-Park/Revert-the-socket_alloc-life-cycle-change/20200506-032051
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
755f5738ff981769211a0bfac709d514ef5b9f86
config: x86_64-randconfig-g001-20200505 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
24b4965ce65b14ead595dcc68add22ba37533207)
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> net/smc/af_smc.c:473:19: error: member reference type 'struct socket_wq *'
>> is a pointer; did you mean to use '->'?
smc->clcsock->wq.fasync_list =
^
->
net/smc/af_smc.c:474:25: error: member reference type 'struct socket_wq *'
is a pointer; did you mean to use '->'?
smc->sk.sk_socket->wq.fasync_list;
~^
->
2 errors generated.
vim +473 net/smc/af_smc.c
0cfdd8f92cac01 Ursula Braun 2017-01-09 466
07603b230895a7 Ursula Braun 2019-04-11 467 static void
smc_switch_to_fallback(struct smc_sock *smc)
07603b230895a7 Ursula Braun 2019-04-11 468 {
07603b230895a7 Ursula Braun 2019-04-11 469 smc->use_fallback = true;
07603b230895a7 Ursula Braun 2019-04-11 470 if (smc->sk.sk_socket &&
smc->sk.sk_socket->file) {
07603b230895a7 Ursula Braun 2019-04-11 471 smc->clcsock->file =
smc->sk.sk_socket->file;
07603b230895a7 Ursula Braun 2019-04-11 472
smc->clcsock->file->private_data = smc->clcsock;
67f562e3e14775 Ursula Braun 2020-02-14 @473
smc->clcsock->wq.fasync_list =
67f562e3e14775 Ursula Braun 2020-02-14 474
smc->sk.sk_socket->wq.fasync_list;
07603b230895a7 Ursula Braun 2019-04-11 475 }
07603b230895a7 Ursula Braun 2019-04-11 476 }
07603b230895a7 Ursula Braun 2019-04-11 477
:: The code at line 473 was first introduced by commit
:: 67f562e3e147750a02b2a91d21a163fc44a1d13e net/smc: transfer fasync_list
in case of fallback
:: TO: Ursula Braun
:: CC: David S. Miller
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v5 0/7] Add interrupt support to FPGA DFL drivers
Hi Moritz: Hao and I did several rounds of review and fix in the mailing list. Now the patches are all acked by Hao. Could you please help review it when you have time? Thanks! :) On Mon, Apr 20, 2020 at 04:11:36PM +0800, Xu Yilun wrote: > This patchset add interrupt support to FPGA DFL drivers. > > With these patches, DFL driver will parse and assign interrupt resources > for enumerated feature devices and their sub features. > > This patchset also introduces a set of APIs for user to monitor DFL > interrupts. Three sub features (DFL FME error, DFL AFU error and user > interrupt) drivers now support these APIs. > > Patch #1: DFL framework change. Accept interrupt info input from DFL bus > driver, and add interrupt parsing and assignment for feature > sub devices. > Patch #2: DFL pci driver change, add interrupt info on DFL enumeration. > Patch #3: DFL framework change. Add helper functions for feature sub > device drivers to handle interrupt and notify users. > Patch #4: Add interrupt support for AFU error reporting sub feature. > Patch #5: Add interrupt support for FME global error reporting sub > feature. > Patch #6: Add interrupt support for a new sub feature, to handle user > interrupts implemented in AFU. > Patch #7: Documentation for DFL interrupt handling. > > Main changes from v1: > - Early validating irq table for each feature in parse_feature_irq() >in Patch #1. > - Changes IOCTL interfaces. use DFL_FPGA_FME/PORT_XXX_GET_IRQ_NUM >instead of DFL_FPGA_FME/PORT_XXX_GET_INFO, delete flag field for >DFL_FPGA_FME/PORT_XXX_SET_IRQ param > > Main changes from v2: > - put parse_feature_irqs() inside create_feature_instance(). > - refines code for dfl_fpga_set_irq_triggers, delete local variable j. > - put_user() instead of copy_to_user() for DFL_FPGA_XXX_GET_IRQ_NUM IOCTL > > Main changes from v3: > - rebased to 5.7-rc1. > - fail the dfl enumeration when irq parsing error happens. > - Add 2 helper functions in dfl.c to handle generic irq ioctls in feature >drivers. > > Main changes from v4: > - Minor fixes for Hao's comments. > > Xu Yilun (7): > fpga: dfl: parse interrupt info for feature devices on enumeration > fpga: dfl: pci: add irq info for feature devices enumeration > fpga: dfl: introduce interrupt trigger setting API > fpga: dfl: afu: add interrupt support for port error reporting > fpga: dfl: fme: add interrupt support for global error reporting > fpga: dfl: afu: add AFU interrupt support > Documentation: fpga: dfl: add descriptions for interrupt related > interfaces. > > Documentation/fpga/dfl.rst| 19 +++ > drivers/fpga/dfl-afu-error.c | 17 +++ > drivers/fpga/dfl-afu-main.c | 32 + > drivers/fpga/dfl-fme-error.c | 18 +++ > drivers/fpga/dfl-fme-main.c | 6 + > drivers/fpga/dfl-pci.c| 80 +-- > drivers/fpga/dfl.c| 310 > ++ > drivers/fpga/dfl.h| 57 > include/uapi/linux/fpga-dfl.h | 82 +++ > 9 files changed, 612 insertions(+), 9 deletions(-) > > -- > 2.7.4
Re: [PATCH] xenbus: avoid stack overflow warning
On 05.05.20 22:57, Arnd Bergmann wrote: On Tue, May 5, 2020 at 6:02 PM Jürgen Groß wrote: On 05.05.20 17:01, Arnd Bergmann wrote: On Tue, May 5, 2020 at 4:34 PM Jürgen Groß wrote: On 05.05.20 16:15, Arnd Bergmann wrote: I considered that as well, and don't really mind either way. I think it does get a bit ugly whatever we do. If you prefer the union, I can respin the patch that way. Hmm, thinking more about it I think the real clean solution would be to extend struct map_ring_valloc_hvm to cover the pv case, too, to add the map and unmap arrays (possibly as a union) to it and to allocate it dynamically instead of having it on the stack. Would you be fine doing this? This is a little more complex than I'd want to do without doing any testing (and no, I don't want to do the testing either) ;-) It does sound like a better approach though. I take this as you are fine with me writing the patch and adding you as "Reported-by:"? Juergen
Re: [PATCH] crypto: blake2b - Fix clang optimization for ARMv7-M
On Tue, May 05, 2020 at 03:53:45PM +0200, Arnd Bergmann wrote:
> When building for ARMv7-M, clang-9 or higher tries to unroll some loops,
> which ends up confusing the register allocator to the point of generating
> rather bad code and using more than the warning limit for stack frames:
>
> warning: stack frame size of 1200 bytes in function 'blake2b_compress'
> [-Wframe-larger-than=]
>
> Forcing it to not unroll the final loop avoids this problem.
>
> Fixes: 91d689337fe8 ("crypto: blake2b - add blake2b generic implementation")
> Signed-off-by: Arnd Bergmann
> ---
> crypto/blake2b_generic.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/blake2b_generic.c b/crypto/blake2b_generic.c
> index 1d262374fa4e..0ffd8d92e308 100644
> --- a/crypto/blake2b_generic.c
> +++ b/crypto/blake2b_generic.c
> @@ -129,7 +129,9 @@ static void blake2b_compress(struct blake2b_state *S,
> ROUND(9);
> ROUND(10);
> ROUND(11);
> -
> +#ifdef CONFIG_CC_IS_CLANG
Given your comment in the bug:
"The code is written to assume no loops are unrolled"
Does it make sense to make this unconditional and take compiler
heuristics out of it?
> +#pragma nounroll /* https://bugs.llvm.org/show_bug.cgi?id=45803 */
> +#endif
> for (i = 0; i < 8; ++i)
> S->h[i] = S->h[i] ^ v[i] ^ v[i + 8];
> }
> --
> 2.26.0
>
Re: [PATCH v1] dt-bindings: net: nxp,tja11xx: rework validation support
On Tue, May 05, 2020 at 04:01:27PM +0200, Andrew Lunn wrote: > On Tue, May 05, 2020 at 12:42:15PM +0200, Oleksij Rempel wrote: > > To properly identify this node, we need to use ethernet-phy-id0180.dc80. > > And add missing required properties. > > > > Signed-off-by: Oleksij Rempel > > --- > > .../devicetree/bindings/net/nxp,tja11xx.yaml | 55 --- > > 1 file changed, 35 insertions(+), 20 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml > > b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml > > index 42be0255512b3..cc322107a24a2 100644 > > --- a/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml > > +++ b/Documentation/devicetree/bindings/net/nxp,tja11xx.yaml > > @@ -1,4 +1,4 @@ > > -# SPDX-License-Identifier: GPL-2.0+ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > %YAML 1.2 > > --- > > $id: http://devicetree.org/schemas/net/nxp,tja11xx.yaml# > > @@ -12,44 +12,59 @@ maintainers: > >- Heiner Kallweit > > > > description: > > - Bindings for NXP TJA11xx automotive PHYs > > + Bindings for the NXP TJA1102 automotive PHY. This is a dual PHY package > > where > > + only the first PHY has global configuration register and HW health > > + monitoring. > > > > -allOf: > > - - $ref: ethernet-phy.yaml# > > +properties: > > + compatible: > > +const: ethernet-phy-id0180.dc80 > > +description: ethernet-phy-id0180.dc80 used for TJA1102 PHY > > + > > + reg: > > +minimum: 0 > > +maximum: 14 > > +description: > > + The PHY address of the parent PHY. > > Hi Oleksij > > reg is normally 0 to 31, since that is the address range for MDIO. > Did you use 14 here because of what strapping allows? Yes. Only BITs 1:3 are configurable. BIT(0) is always 0 for the PHY0 and 1 for the PHY1 > > +required: > > + - compatible > > + - reg > > + - '#address-cells' > > + - '#size-cells' > > So we have two different meanings of 'required' here. > > One meaning is the code requires it. compatible is not required, the > driver will correctly be bind to the device based on its ID registers. > Is reg also required by the code? > > The second meaning is about keeping the yaml verifier happy. It seems > like compatible is needed for the verifier. Is reg also required? We > do recommend having reg, but the generic code does not require it. reg is used by: tja1102_p0_probe() tja1102_p1_register() of_mdio_parse_addr() But this is required for the slave PHY. I assume the reg can be optional for the master PHY. Should I? Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: PGP signature
[PATCH -next] drm/amdgpu/navi10: fix unsigned comparison with 0
Fixes warning because size is uint32_t and can never be negtative
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1296:12: warning:
comparison of unsigned expression < 0 is always false [-Wtype-limits]
if (size < 0)
Reported-by: Hulk Robot
Signed-off-by: ChenTao
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index 2184d247a9f7..0c9be864d072 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -1293,8 +1293,6 @@ static int navi10_set_power_profile_mode(struct
smu_context *smu, long *input, u
}
if (smu->power_profile_mode == PP_SMC_POWER_PROFILE_CUSTOM) {
- if (size < 0)
- return -EINVAL;
ret = smu_update_table(smu,
SMU_TABLE_ACTIVITY_MONITOR_COEFF,
WORKLOAD_PPLIB_CUSTOM_BIT,
--
2.22.0
Re: [PATCH v4 04/10] loop: Refactor loop_set_status() size calculation
On Fri, May 01, 2020 at 09:33:23PM +0200, Martijn Coenen wrote: > On Fri, May 1, 2020 at 7:30 PM Christoph Hellwig wrote: > > > > For some reason this fails to apply for me against both > > Jens' for-5.8/block and Linus' current tree. > > > > What is the baseline for this series? > > This was based on Linus' tree from a week or two ago or so, but I > think you're most likely missing this one? > > https://lkml.org/lkml/2020/3/31/755 > > (I mentioned it in the cover letter, but can make it a part of this > series if you prefer). Yes, I missed that one.
Re: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive Unleashed A00 board.
On Wed, May 6, 2020 at 9:26 AM Sagar Kadam wrote: > > Hi Palmer, > > > -Original Message- > > From: Palmer Dabbelt > > Sent: Wednesday, May 6, 2020 4:54 AM > > To: Sagar Kadam > > Cc: tudor.amba...@microchip.com; miquel.ray...@bootlin.com; > > rich...@nod.at; vigne...@ti.com; Paul Walmsley > > ; linux-ri...@lists.infradead.org; linux- > > ker...@vger.kernel.org; linux-...@lists.infradead.org > > Subject: RE: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive > > Unleashed > > A00 board. > > > > [External Email] Do not click links or attachments unless you recognize the > > sender and know the content is safe > > > > On Tue, 05 May 2020 00:18:45 PDT (-0700), sagar.ka...@sifive.com wrote: > > > Hello Palmer, > > > > > >> -Original Message- > > >> From: Palmer Dabbelt > > >> Sent: Tuesday, May 5, 2020 3:40 AM > > >> To: Sagar Kadam > > >> Cc: tudor.amba...@microchip.com; miquel.ray...@bootlin.com; > > >> rich...@nod.at; vigne...@ti.com; Paul Walmsley > > >> ; linux-ri...@lists.infradead.org; linux- > > >> ker...@vger.kernel.org; linux-...@lists.infradead.org; Sagar Kadam > > >> > > >> Subject: Re: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive > > Unleashed > > >> A00 board. > > >> > > >> [External Email] Do not click links or attachments unless you recognize > > the > > >> sender and know the content is safe > > >> > > >> On Thu, 30 Apr 2020 02:58:51 PDT (-0700), sagar.ka...@sifive.com > > wrote: > > >> > Enable MTD based SPI-NOR framework in order to use spi flash > > available > > >> > on HiFive Unleashed A00 board. > > >> > > > >> > Signed-off-by: Sagar Shrikant Kadam > > >> > --- > > >> > arch/riscv/configs/defconfig | 2 ++ > > >> > 1 file changed, 2 insertions(+) > > >> > > > >> > diff --git a/arch/riscv/configs/defconfig > > >> > b/arch/riscv/configs/defconfig index 4da4886..970580b 100644 > > >> > --- a/arch/riscv/configs/defconfig > > >> > +++ b/arch/riscv/configs/defconfig > > >> > @@ -80,6 +80,8 @@ CONFIG_USB_STORAGE=y CONFIG_USB_UAS=y > > >> CONFIG_MMC=y > > >> > CONFIG_MMC_SPI=y > > >> > +CONFIG_MTD=y > > >> > +CONFIG_MTD_SPI_NOR=y > > >> > CONFIG_RTC_CLASS=y > > >> > CONFIG_VIRTIO_PCI=y > > >> > CONFIG_VIRTIO_BALLOON=y > > >> > > >> From the second patch's description I'm assuming that MTD still > > functions > > >> correctly without that change? > > > > > > Yes Palmer, the second patch is to enable QUAD write to nor flash.. > > > MTD function's correctly without second patch. > > > > > > Using the character interface (/dev/mtd0) mtd_utils (mtd_debug : > > erase/read/write) work fine. > > > We might require CONFIG_MTD_BLOCK, CONFIG_MTD_CMDLINE_PARTS > > in order to use MTD partitioning. > > > IMHO it can be at user's choice weather to use flash partitions or not, > > > so I > > have not enabled. Please let me > > > know if I should enable these features as well. > > > > Looks like arm64 has these: > > > > arch/arm64/configs/defconfig:CONFIG_MTD=y > > arch/arm64/configs/defconfig:CONFIG_MTD_BLOCK=y > > arch/arm64/configs/defconfig:CONFIG_MTD_CFI=y > > arch/arm64/configs/defconfig:CONFIG_MTD_CFI_ADV_OPTIONS=y > > arch/arm64/configs/defconfig:CONFIG_MTD_CFI_INTELEXT=y > > arch/arm64/configs/defconfig:CONFIG_MTD_CFI_AMDSTD=y > > arch/arm64/configs/defconfig:CONFIG_MTD_CFI_STAA=y > > arch/arm64/configs/defconfig:CONFIG_MTD_PHYSMAP=y > > arch/arm64/configs/defconfig:CONFIG_MTD_PHYSMAP_OF=y > > arch/arm64/configs/defconfig:CONFIG_MTD_DATAFLASH=y > > arch/arm64/configs/defconfig:CONFIG_MTD_SST25L=y > > arch/arm64/configs/defconfig:CONFIG_MTD_RAW_NAND=y > > arch/arm64/configs/defconfig:CONFIG_MTD_NAND_DENALI_DT=y > > arch/arm64/configs/defconfig:CONFIG_MTD_NAND_MARVELL=y > > arch/arm64/configs/defconfig:CONFIG_MTD_NAND_FSL_IFC=y > > arch/arm64/configs/defconfig:CONFIG_MTD_NAND_QCOM=y > > arch/arm64/configs/defconfig:CONFIG_MTD_SPI_NOR=y > > > > so I think we're good with just what you have here: MTD_BLOCK doesn't > > seem that > > useful, and the rest are drivers. That said, these (along with SPI and > > SPI_SIFIVE) should really be in Kconfig.socs rather than defconfig. Can you > > send a patch that does that? > > > > Yes sure, I will send a V2 series, where SPI, SPI_SIFIVE, MTD, > and MTD_SPI_NOR will be a part of Kconfig.socs. We had build issues in past by selecting major driver subsystems in Kconfig.socs I suggest to select SPI_SIFIVE from Kconfig.socs and other platform independent options should go in defconfig and rv32_defconfig. The general rule of thumb is to force select only required drivers from Kconfig.socs. Regards, Anup > > Thanks & BR, > Sagar Kadam > > > > > > > To demonstrate a bit more with linux 5.7-rc3 > > > > > > Specify on U-boot prompt: > > > # setenv bootargs "root=/dev/ram rw console=ttySIF0 > > mtdparts=spi0.0:1024k(loader1),4096K(loader2),26M(rootfs)" > > > > > > After booting linux will enumerate mtd partitions: > > > # cat /proc/mtd > > > dev:size erasesize name > > > mtd0: 0010 1000 "loader1" > > > mtd1:
[GIT PULL] Crypto Fixes for 5.7
Hi Linus: This push fixes a potential scheduling latency problem for the algorithms used by WireGuard. The following changes since commit 55b3209acbb01cb02b1ee6b1afe80d83b1aab36d: crypto: caam - fix the address of the last entry of S/G (2020-04-16 16:48:56 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus for you to fetch changes up to a9a8ba90fa5857c2c8a0e32eef2159cec717da11: crypto: arch/nhpoly1305 - process in explicit 4k chunks (2020-04-30 15:16:59 +1000) Jason A. Donenfeld (2): crypto: arch/lib - limit simd usage to 4k chunks crypto: arch/nhpoly1305 - process in explicit 4k chunks arch/arm/crypto/chacha-glue.c| 14 +++--- arch/arm/crypto/nhpoly1305-neon-glue.c | 2 +- arch/arm/crypto/poly1305-glue.c | 15 +++ arch/arm64/crypto/chacha-neon-glue.c | 14 +++--- arch/arm64/crypto/nhpoly1305-neon-glue.c | 2 +- arch/arm64/crypto/poly1305-glue.c| 15 +++ arch/x86/crypto/blake2s-glue.c | 10 -- arch/x86/crypto/chacha_glue.c| 14 +++--- arch/x86/crypto/nhpoly1305-avx2-glue.c | 2 +- arch/x86/crypto/nhpoly1305-sse2-glue.c | 2 +- arch/x86/crypto/poly1305_glue.c | 13 ++--- 11 files changed, 69 insertions(+), 34 deletions(-) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH -next] firmware: imx: scu: Fix possible memory leak in imx_scu_probe()
'chan_name' is malloced in imx_scu_probe() and should be freed
before leaving from the error handling cases, otherwise it will
cause memory leak.
Fixes: edbee095fafb ("firmware: imx: add SCU firmware driver support")
Signed-off-by: Wei Yongjun
---
drivers/firmware/imx/imx-scu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
index b3da2e193ad2..176ddd151375 100644
--- a/drivers/firmware/imx/imx-scu.c
+++ b/drivers/firmware/imx/imx-scu.c
@@ -314,6 +314,7 @@ static int imx_scu_probe(struct platform_device *pdev)
if (ret != -EPROBE_DEFER)
dev_err(dev, "Failed to request mbox chan %s
ret %d\n",
chan_name, ret);
+ kfree(chan_name);
return ret;
}
Re: [PATCH v2 1/6] kunit: Kconfig: enable a KUNIT_RUN_ALL fragment
On Tue, May 5, 2020 at 6:27 PM Anders Roxell wrote: > > Make it easier to enable all KUnit fragments. This is needed for kernel > test-systems, so its easy to get all KUnit tests enabled and if new gets > added they will be enabled as well. Fragments that has to be builtin > will be missed if CONFIG_KUNIT_RUN_ALL is set as a module. > > Signed-off-by: Anders Roxell > --- > lib/kunit/Kconfig | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig > index 95d12e3d6d95..537f37bc8400 100644 > --- a/lib/kunit/Kconfig > +++ b/lib/kunit/Kconfig > @@ -41,4 +41,10 @@ config KUNIT_EXAMPLE_TEST > is intended for curious hackers who would like to understand how to > use KUnit for kernel development. > > +config KUNIT_RUN_ALL > + tristate "KUnit run all test" I'm not 100% sure about this name and description. It only actually "runs" the tests if they're builtin (as modules, they'll only run when loaded). Would KUNIT_BUILD_ALL or KUNIT_ALL_TESTS or similar be better? It also, as mentioned, only really runs all available (i.e., with dependencies met in the current .config) tests (as distinct from the --alltests flag to kunit.py, which builds UML with allyesconfig), it might be good to add this to the description or help. Something like "Enable all KUnit tests" or "Enable all available KUnit tests" (or even something about "all KUnit tests with satisfied dependencies") might be clearer. > + help > + Enables all KUnit tests, if they can be enabled. > + That depends on if KUnit is enabled as a module or builtin. > + I like the first line here, but the second one could use a bit more explanation. Maybe copy some of the boilerplate text from other tests, e.g.: KUnit tests run during boot and output the results to the debug log in TAP format (http://testanything.org/). Only useful for kernel devs running the KUnit test harness, and not intended for inclusion into a production build. For more information on KUnit and unit tests in general please refer to the KUnit documentation in Documentation/dev-tools/kunit/. If unsure, say N. > endif # KUNIT > -- > 2.20.1 > Otherwise, this is looking good. I've done some quick testing, and it all seems to work for me. As long as it's clear what the difference between this and other ways of running "all tests" (like the --alltests kunit.py option), I'm all for including this in. Cheers, -- David
[PATCH RESEND] MAINTAINERS: adjust entries to moving CEC platform drivers
Commit 4be5e8648b0c ("media: move CEC platform drivers to a separate
directory") moved various files into a new directory structure, but did
not adjust the entries in MAINTAINERS.
Since then, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F: drivers/media/platform/s5p-cec/
warning: no file matches F: drivers/media/platform/tegra-cec/
warning: no file matches F: drivers/media/platform/cec-gpio/
warning: no file matches F: drivers/media/platform/meson/ao-cec-g12a.c
warning: no file matches F: drivers/media/platform/meson/ao-cec.c
warning: no file matches F: drivers/media/platform/seco-cec/seco-cec.c
warning: no file matches F: drivers/media/platform/seco-cec/seco-cec.h
warning: no file matches F: drivers/media/platform/sti/cec/
Update the MAINTAINERS entries to the new file locations.
Signed-off-by: Lukas Bulwahn
---
Mauro, please pick this non-urgent minor clean-up patch on top of the
CEC platform driver moves.
applies cleanly on next-20200417 and still on next-20200505 for this
resend.
v1 send here:
https://lore.kernel.org/lkml/20200418093630.6149-1-lukas.bulw...@gmail.com/
MAINTAINERS | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3083282134de..a708773e1af7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2373,7 +2373,7 @@ L:linux-samsung-...@vger.kernel.org (moderated
for non-subscribers)
L: linux-me...@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/media/s5p-cec.txt
-F: drivers/media/platform/s5p-cec/
+F: drivers/media/cec/platform/s5p/
ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT
M: Andrzej Pietrasiewicz
@@ -2518,7 +2518,7 @@ L:linux-te...@vger.kernel.org
L: linux-me...@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/media/tegra-cec.txt
-F: drivers/media/platform/tegra-cec/
+F: drivers/media/cec/platform/tegra/
ARM/TETON BGA MACHINE SUPPORT
M: "Mark F. Brown"
@@ -3932,7 +3932,7 @@ S:Supported
W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/cec-gpio.txt
-F: drivers/media/platform/cec-gpio/
+F: drivers/media/cec/platform/cec-gpio/
CELL BROADBAND ENGINE ARCHITECTURE
M: Arnd Bergmann
@@ -11027,8 +11027,7 @@ S: Supported
W: http://linux-meson.com/
T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml
-F: drivers/media/platform/meson/ao-cec-g12a.c
-F: drivers/media/platform/meson/ao-cec.c
+F: drivers/media/cec/platform/meson/
MESON NAND CONTROLLER DRIVER FOR AMLOGIC SOCS
M: Liang Yang
@@ -15063,8 +15062,7 @@ F: drivers/mmc/host/sdricoh_cs.c
SECO BOARDS CEC DRIVER
M: Ettore Chimenti
S: Maintained
-F: drivers/media/platform/seco-cec/seco-cec.c
-F: drivers/media/platform/seco-cec/seco-cec.h
+F: drivers/media/cec/platform/seco/
SECURE COMPUTING
M: Kees Cook
@@ -16089,7 +16087,7 @@ STI CEC DRIVER
M: Benjamin Gaignard
S: Maintained
F: Documentation/devicetree/bindings/media/stih-cec.txt
-F: drivers/media/platform/sti/cec/
+F: drivers/media/cec/platform/sti/
STK1160 USB VIDEO CAPTURE DRIVER
M: Ezequiel Garcia
--
2.17.1
Re: [PATCH 1/2] net: qed*: Reduce RX and TX default ring count when running inside kdump kernel
Hi David, On Wed, May 6, 2020 at 2:54 AM David Miller wrote: > > From: Bhupesh Sharma > Date: Wed, 6 May 2020 00:34:40 +0530 > > > -#define NUM_RX_BDS_DEF ((u16)BIT(10) - 1) > > +#define NUM_RX_BDS_DEF ((is_kdump_kernel()) ? ((u16)BIT(6) - > > 1) : ((u16)BIT(10) - 1)) > > These parenthesis are very excessive and unnecessary. At the > very least remove the parenthesis around is_kdump_kernel(). Thanks a lot for the review. Sure, will fix this in the v2. Regards, Bhupesh
Re: [PATCH 7/7] sysvipc_find_ipc should increase position index
On 5/5/20 7:13 PM, Andreas Schwab wrote: > I think this is causing this bug (seen on 5.6.8): thank you for reporting, yes, you are right, it's my fault patch incorrectly updated *new_pos in case of found entry > # ipcs -q > > -- Message Queues > keymsqid owner perms used-bytes messages > 0x7c982867 3 root 64400 > 0x7c982867 3 root 64400 > 0x7c982867 3 root 64400 > 0x7c982867 3 root 64400 Thank you, Vasily Averin
[PATCH v2] [media] mtk-mdp: Remove states for format checks
From: Francois Buergisser
The mtk-mdp driver uses states to check if the formats have been set
on the capture and output when turning the streaming on, setting
controls or setting the selection rectangles.
Those states are reset when 0 buffers are requested like when checking
capabilities.
This patch removes all format checks and set one by default as queues in
V4L2 are expected to always have a format set.
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-streamon.html
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-g-ctrl.html
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-g-selection.html
Signed-off-by: Francois Buergisser
Signed-off-by: Eizan Miyamoto
Reviewed-by: Enric Balletbo I Serra
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 2 -
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 90 +++
2 files changed, 34 insertions(+), 58 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
index bafcccd71f31..dd130cc218c9 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
@@ -28,8 +28,6 @@
#define MTK_MDP_FMT_FLAG_CAPTURE BIT(1)
#define MTK_MDP_VPU_INIT BIT(0)
-#define MTK_MDP_SRC_FMTBIT(1)
-#define MTK_MDP_DST_FMTBIT(2)
#define MTK_MDP_CTX_ERROR BIT(5)
/**
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index 821f2cf325f0..bb9caaf513bc 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -369,13 +369,6 @@ void mtk_mdp_ctx_state_lock_set(struct mtk_mdp_ctx *ctx,
u32 state)
mutex_unlock(>slock);
}
-static void mtk_mdp_ctx_state_lock_clear(struct mtk_mdp_ctx *ctx, u32 state)
-{
- mutex_lock(>slock);
- ctx->state &= ~state;
- mutex_unlock(>slock);
-}
-
static bool mtk_mdp_ctx_state_is_set(struct mtk_mdp_ctx *ctx, u32 mask)
{
bool ret;
@@ -726,11 +719,6 @@ static int mtk_mdp_m2m_s_fmt_mplane(struct file *file,
void *fh,
ctx->quant = pix_mp->quantization;
}
- if (V4L2_TYPE_IS_OUTPUT(f->type))
- mtk_mdp_ctx_state_lock_set(ctx, MTK_MDP_SRC_FMT);
- else
- mtk_mdp_ctx_state_lock_set(ctx, MTK_MDP_DST_FMT);
-
mtk_mdp_dbg(2, "[%d] type:%d, frame:%dx%d", ctx->id, f->type,
frame->width, frame->height);
@@ -742,13 +730,6 @@ static int mtk_mdp_m2m_reqbufs(struct file *file, void *fh,
{
struct mtk_mdp_ctx *ctx = fh_to_ctx(fh);
- if (reqbufs->count == 0) {
- if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
- mtk_mdp_ctx_state_lock_clear(ctx, MTK_MDP_SRC_FMT);
- else
- mtk_mdp_ctx_state_lock_clear(ctx, MTK_MDP_DST_FMT);
- }
-
return v4l2_m2m_reqbufs(file, ctx->m2m_ctx, reqbufs);
}
@@ -758,14 +739,6 @@ static int mtk_mdp_m2m_streamon(struct file *file, void
*fh,
struct mtk_mdp_ctx *ctx = fh_to_ctx(fh);
int ret;
- /* The source and target color format need to be set */
- if (V4L2_TYPE_IS_OUTPUT(type)) {
- if (!mtk_mdp_ctx_state_is_set(ctx, MTK_MDP_SRC_FMT))
- return -EINVAL;
- } else if (!mtk_mdp_ctx_state_is_set(ctx, MTK_MDP_DST_FMT)) {
- return -EINVAL;
- }
-
if (!mtk_mdp_ctx_state_is_set(ctx, MTK_MDP_VPU_INIT)) {
ret = mtk_mdp_vpu_init(>vpu);
if (ret < 0) {
@@ -899,24 +872,21 @@ static int mtk_mdp_m2m_s_selection(struct file *file,
void *fh,
frame = >d_frame;
/* Check to see if scaling ratio is within supported range */
- if (mtk_mdp_ctx_state_is_set(ctx, MTK_MDP_DST_FMT | MTK_MDP_SRC_FMT)) {
- if (V4L2_TYPE_IS_OUTPUT(s->type)) {
- ret = mtk_mdp_check_scaler_ratio(variant, new_r.width,
- new_r.height, ctx->d_frame.crop.width,
- ctx->d_frame.crop.height,
- ctx->ctrls.rotate->val);
- } else {
- ret = mtk_mdp_check_scaler_ratio(variant,
- ctx->s_frame.crop.width,
- ctx->s_frame.crop.height, new_r.width,
- new_r.height, ctx->ctrls.rotate->val);
- }
+ if (V4L2_TYPE_IS_OUTPUT(s->type))
+ ret = mtk_mdp_check_scaler_ratio(variant, new_r.width,
+ new_r.height, ctx->d_frame.crop.width,
+ ctx->d_frame.crop.height,
+ ctx->ctrls.rotate->val);
+ else
+ ret = mtk_mdp_check_scaler_ratio(variant,
+ ctx->s_frame.crop.width,
+
[PATCH v4 1/1] scsi: pm: Balance pm_only counter of request queue during system resume
During system resume, scsi_resume_device() decreases a request queue's
pm_only counter if the scsi device was quiesced before. But after that,
if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is
still held (non-zero). Current scsi resume hook only sets the RPM status
of the scsi device and its request queue to RPM_ACTIVE, but leaves the
pm_only counter unchanged. This may make the request queue's pm_only
counter remain non-zero after resume hook returns, hence those who are
waiting on the mq_freeze_wq would never be woken up. Fix this by calling
blk_post_runtime_resume() if a sdev's RPM status was RPM_SUSPENDED.
(struct request_queue)0xFF815B69E938
pm_only = (counter = 2),
rpm_status = 0,
dev = 0xFF815B0511A0,
((struct device)0xFF815B0511A0)).power
is_suspended = FALSE,
runtime_status = RPM_ACTIVE,
(struct scsi_device)0xff815b051000
request_queue = 0xFF815B69E938,
sdev_state = SDEV_RUNNING,
quiesced_by = 0x0,
B::v.f_/task_0xFF810C246940
-000|__switch_to(prev = 0xFF810C246940, next = 0xFF80A49357C0)
-001|context_switch(inline)
-001|__schedule(?)
-002|schedule()
-003|blk_queue_enter(q = 0xFF815B69E938, flags = 0)
-004|generic_make_request(?)
-005|submit_bio(bio = 0xFF80A8195B80)
Signed-off-by: Can Guo
---
Change since v3:
- Instead of relying on pm_only counter, rely on the runtime status of a sdev.
(Based on the discussion with Bart)
Change since v2:
- Rebased on 5.8-scsi-queue
Change since v1:
- Added more debugging context info
drivers/scsi/scsi_pm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 3717eea..5f0ad8b 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -80,6 +80,10 @@ static int scsi_dev_type_resume(struct device *dev,
dev_dbg(dev, "scsi resume: %d\n", err);
if (err == 0) {
+ bool was_runtime_suspended;
+
+ was_runtime_suspended = pm_runtime_suspended(dev);
+
pm_runtime_disable(dev);
err = pm_runtime_set_active(dev);
pm_runtime_enable(dev);
@@ -93,8 +97,10 @@ static int scsi_dev_type_resume(struct device *dev,
*/
if (!err && scsi_is_sdev_device(dev)) {
struct scsi_device *sdev = to_scsi_device(dev);
-
- blk_set_runtime_active(sdev->request_queue);
+ if (was_runtime_suspended)
+ blk_post_runtime_resume(sdev->request_queue, 0);
+ else
+ blk_set_runtime_active(sdev->request_queue);
}
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
Re: [PATCH 1/1] s390/dasd: remove ioctl_by_bdev from DASD driver
On Tue, May 05, 2020 at 05:09:56PM +0200, Stefan Haberland wrote: > OK, thanks for the hint.I did not have this in mind. And I still have > to look up how this is working at all. > But isn't this only a real issue for devices with more than 16 minors > or partitions? So it should not be a problem for DASDs with our limit > of 3 partitions and the fixed amount of minors, right? > > Just tested with CONFIG_DEBUG_BLOCK_EXT_DEVT enabled and about 1000 > unlabeled devices. Did not see an issue. > > While I see the SCSI devices with MAJOR 259 and quite a random MINOR > all the DASD devices keep their MAJOR 94 and ascending MINOR. Looks like it only changes the minors, and not the majors. Still checking for major and relying on a shared structure define in different places just doesn't look maintainable. > > And compared to all the complications I think the biodasdinfo method > > is the least of all those evils. > > Are you talking about your first patch suggestion?Then I disagree. > I still do not like to force the driver to be built in if there is an > alternative. No, I mean the series that I actually sent out: https://lkml.org/lkml/2020/4/21/66 https://lkml.org/lkml/2020/4/21/68 https://lkml.org/lkml/2020/4/21/69
Re: [PATCH net-next v3] net: phy: micrel: add phy-mode support for the KSZ9031 PHY
Hi Grygorii, On Tue, May 05, 2020 at 09:26:46PM +0300, Grygorii Strashko wrote: > > > On 22/04/2020 10:21, Oleksij Rempel wrote: > > Add support for following phy-modes: rgmii, rgmii-id, rgmii-txid, > > rgmii-rxid. > > > > This PHY has an internal RX delay of 1.2ns and no delay for TX. > > > > The pad skew registers allow to set the total TX delay to max 1.38ns and > > the total RX delay to max of 2.58ns (configurable 1.38ns + build in > > 1.2ns) and a minimal delay of 0ns. > > > > According to the RGMII v1.3 specification the delay provided by PCB traces > > should be between 1.5ns and 2.0ns. The RGMII v2.0 allows to provide this > > delay by MAC or PHY. So, we configure this PHY to the best values we can > > get by this HW: TX delay to 1.38ns (max supported value) and RX delay to > > 1.80ns (best calculated delay) > > > > The phy-modes can still be fine tuned/overwritten by *-skew-ps > > device tree properties described in: > > Documentation/devicetree/bindings/net/micrel-ksz90x1.txt > > > > Signed-off-by: Oleksij Rempel > > --- > > changes v3: > > - change delay on RX line to 1.80ns > > - add warning if *-skew-ps properties are used together with not rgmii > >mode. > > > > changes v2: > > - change RX_ID value from 0x1a to 0xa. The overflow bit was detected by > >FIELD_PREP() build check. > >Reported-by: kbuild test robot > > > > drivers/net/phy/micrel.c | 128 +-- > > 1 file changed, 123 insertions(+), 5 deletions(-) > > > > This patch broke networking on at least 5 TI boards: > am572x-idk > am571x-idk > am43xx-hsevm > am43xx-gpevm > am437x-idk > > am57xx I can fix. > > am437x need to investigate. Please try: phy-mode = "rgmii-txid" I assume your boards are using "rgmii" which should be used only if you boards have extra long clk traces. Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: PGP signature
[PATCH 1/2] net: qrtr: Add MHI transport layer
MHI is the transport layer used for communicating to the external modems.
Hence, this commit adds MHI transport layer support to QRTR for
transferring the QMI messages over IPC Router.
Reviewed-by: Bjorn Andersson
Signed-off-by: Manivannan Sadhasivam
---
net/qrtr/Kconfig | 7 +++
net/qrtr/Makefile | 2 +
net/qrtr/mhi.c| 127 ++
3 files changed, 136 insertions(+)
create mode 100644 net/qrtr/mhi.c
diff --git a/net/qrtr/Kconfig b/net/qrtr/Kconfig
index 63f89cc6e82c..8eb876471564 100644
--- a/net/qrtr/Kconfig
+++ b/net/qrtr/Kconfig
@@ -29,4 +29,11 @@ config QRTR_TUN
implement endpoints of QRTR, for purpose of tunneling data to other
hosts or testing purposes.
+config QRTR_MHI
+ tristate "MHI IPC Router channels"
+ depends on MHI_BUS
+ help
+ Say Y here to support MHI based ipcrouter channels. MHI is the
+ transport used for communicating to external modems.
+
endif # QRTR
diff --git a/net/qrtr/Makefile b/net/qrtr/Makefile
index 32d4e923925d..1b1411d158a7 100644
--- a/net/qrtr/Makefile
+++ b/net/qrtr/Makefile
@@ -5,3 +5,5 @@ obj-$(CONFIG_QRTR_SMD) += qrtr-smd.o
qrtr-smd-y := smd.o
obj-$(CONFIG_QRTR_TUN) += qrtr-tun.o
qrtr-tun-y := tun.o
+obj-$(CONFIG_QRTR_MHI) += qrtr-mhi.o
+qrtr-mhi-y := mhi.o
diff --git a/net/qrtr/mhi.c b/net/qrtr/mhi.c
new file mode 100644
index ..2a2abf5b070d
--- /dev/null
+++ b/net/qrtr/mhi.c
@@ -0,0 +1,127 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "qrtr.h"
+
+struct qrtr_mhi_dev {
+ struct qrtr_endpoint ep;
+ struct mhi_device *mhi_dev;
+ struct device *dev;
+};
+
+/* From MHI to QRTR */
+static void qcom_mhi_qrtr_dl_callback(struct mhi_device *mhi_dev,
+ struct mhi_result *mhi_res)
+{
+ struct qrtr_mhi_dev *qdev = dev_get_drvdata(_dev->dev);
+ int rc;
+
+ if (!qdev || mhi_res->transaction_status)
+ return;
+
+ rc = qrtr_endpoint_post(>ep, mhi_res->buf_addr,
+ mhi_res->bytes_xferd);
+ if (rc == -EINVAL)
+ dev_err(qdev->dev, "invalid ipcrouter packet\n");
+}
+
+/* From QRTR to MHI */
+static void qcom_mhi_qrtr_ul_callback(struct mhi_device *mhi_dev,
+ struct mhi_result *mhi_res)
+{
+ struct sk_buff *skb = (struct sk_buff *)mhi_res->buf_addr;
+
+ if (skb->sk)
+ sock_put(skb->sk);
+ consume_skb(skb);
+}
+
+/* Send data over MHI */
+static int qcom_mhi_qrtr_send(struct qrtr_endpoint *ep, struct sk_buff *skb)
+{
+ struct qrtr_mhi_dev *qdev = container_of(ep, struct qrtr_mhi_dev, ep);
+ int rc;
+
+ rc = skb_linearize(skb);
+ if (rc)
+ goto free_skb;
+
+ rc = mhi_queue_skb(qdev->mhi_dev, DMA_TO_DEVICE, skb, skb->len,
+ MHI_EOT);
+ if (rc)
+ goto free_skb;
+
+ if (skb->sk)
+ sock_hold(skb->sk);
+
+ return rc;
+
+free_skb:
+ kfree_skb(skb);
+
+ return rc;
+}
+
+static int qcom_mhi_qrtr_probe(struct mhi_device *mhi_dev,
+ const struct mhi_device_id *id)
+{
+ struct qrtr_mhi_dev *qdev;
+ int rc;
+
+ qdev = devm_kzalloc(_dev->dev, sizeof(*qdev), GFP_KERNEL);
+ if (!qdev)
+ return -ENOMEM;
+
+ qdev->mhi_dev = mhi_dev;
+ qdev->dev = _dev->dev;
+ qdev->ep.xmit = qcom_mhi_qrtr_send;
+
+ dev_set_drvdata(_dev->dev, qdev);
+ rc = qrtr_endpoint_register(>ep, QRTR_EP_NID_AUTO);
+ if (rc)
+ return rc;
+
+ dev_dbg(qdev->dev, "Qualcomm MHI QRTR driver probed\n");
+
+ return 0;
+}
+
+static void qcom_mhi_qrtr_remove(struct mhi_device *mhi_dev)
+{
+ struct qrtr_mhi_dev *qdev = dev_get_drvdata(_dev->dev);
+
+ qrtr_endpoint_unregister(>ep);
+ dev_set_drvdata(_dev->dev, NULL);
+}
+
+static const struct mhi_device_id qcom_mhi_qrtr_id_table[] = {
+ { .chan = "IPCR" },
+ {}
+};
+MODULE_DEVICE_TABLE(mhi, qcom_mhi_qrtr_id_table);
+
+static struct mhi_driver qcom_mhi_qrtr_driver = {
+ .probe = qcom_mhi_qrtr_probe,
+ .remove = qcom_mhi_qrtr_remove,
+ .dl_xfer_cb = qcom_mhi_qrtr_dl_callback,
+ .ul_xfer_cb = qcom_mhi_qrtr_ul_callback,
+ .id_table = qcom_mhi_qrtr_id_table,
+ .driver = {
+ .name = "qcom_mhi_qrtr",
+ },
+};
+
+module_mhi_driver(qcom_mhi_qrtr_driver);
+
+MODULE_AUTHOR("Chris Lew ");
+MODULE_AUTHOR("Manivannan Sadhasivam ");
+MODULE_DESCRIPTION("Qualcomm IPC-Router MHI interface driver");
+MODULE_LICENSE("GPL v2");
--
2.17.1
[PATCH 2/2] net: qrtr: Do not depend on ARCH_QCOM
IPC Router protocol is also used by external modems for exchanging the QMI messages. Hence, it doesn't always depend on Qualcomm platforms. One such instance is the QCA6390 WLAN device connected to x86 machine. Reviewed-by: Bjorn Andersson Signed-off-by: Manivannan Sadhasivam --- net/qrtr/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/net/qrtr/Kconfig b/net/qrtr/Kconfig index 8eb876471564..f362ca316015 100644 --- a/net/qrtr/Kconfig +++ b/net/qrtr/Kconfig @@ -4,7 +4,6 @@ config QRTR tristate "Qualcomm IPC Router support" - depends on ARCH_QCOM || COMPILE_TEST ---help--- Say Y if you intend to use Qualcomm IPC router protocol. The protocol is used to communicate with services provided by other -- 2.17.1
Re: [PATCH] serial: lantiq: Add x86 in Kconfig dependencies for Lantiq serial driver
On 5/5/2020 10:25 pm, Greg KH wrote: > On Mon, May 04, 2020 at 04:03:52PM +0800, Rahul Tanwar wrote: >> Lantiq serial driver/IP is reused for a x86 based SoC as well. >> Update the Kconfig accordingly. >> >> Signed-off-by: Rahul Tanwar >> --- >> drivers/tty/serial/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig >> index 0aea76cd67ff..4b0a7b98f8c7 100644 >> --- a/drivers/tty/serial/Kconfig >> +++ b/drivers/tty/serial/Kconfig >> @@ -1035,7 +1035,7 @@ config SERIAL_SIFIVE_CONSOLE >> >> config SERIAL_LANTIQ >> bool "Lantiq serial driver" >> -depends on LANTIQ >> +depends on (LANTIQ || X86) || COMPILE_TEST >> select SERIAL_CORE >> select SERIAL_CORE_CONSOLE >> select SERIAL_EARLYCON >> -- >> 2.11.0 >> > Any reason this can't also be a module? Thanks a lot for accepting the patch. This driver is also used for console during bootup so we always have it as built in. Regards, Rahul > thanks, > > greg k-h
Re: [PATCH v2] kcsan: Add test suite
On Wed, May 6, 2020 at 2:30 AM Marco Elver wrote: > > This adds KCSAN test focusing on behaviour of the integrated runtime. > Tests various race scenarios, and verifies the reports generated to > console. Makes use of KUnit for test organization, and the Torture > framework for test thread control. > > Signed-off-by: Marco Elver Thanks, this works much better on my setup: having an explicit error for there not being enough CPUs is a lot better than hanging. It'd still be nice to have these be "skipped" rather than "failed" at some stage, but that's a nice-to-have for the future once we've implemented such a thing in KUnit. I'm still a little hesitant about non-deterministic tests in general — even if they're only run when CONFIG_KCSAN is enabled, it's possible that a future CI system could run under KCSAN and report false breakages on unrelated patches. Given no such setup exists yet, though, I think it's probably a problem for the future rather than a blocker at the moment. Regardless, I hit no unexpected issues in my testing, so, Tested-by: David Gow -- David
Proper use for linking foo.o_shipped after 69ea912fda74 ("kbuild: remove unneeded link_multi_deps")?
Hi Masahiro, Michal,
While updating our systems from 4.9 to 5.4, we noticed that one of the
kernel modules that we build, which is done by linking an object that we
pre-compile out of Kbuild stopped working.
I bisected it down to:
commit 69ea912fda74a673d330d23595385e5b73e3a2b9 (refs/bisect/bad)
Author: Masahiro Yamada
Date: Thu Oct 4 13:25:19 2018 +0900
kbuild: remove unneeded link_multi_deps
Since commit c8589d1e9e01 ("kbuild: handle multi-objs dependency
appropriately"), $^ really represents all the prerequisite of the
composite object being built.
Hence, $(filter %.o,$^) contains all the objects to link together,
which is much simpler than link_multi_deps calculation.
Please note $(filter-out FORCE,$^) does not work here. When a single
object module is turned into a multi object module, $^ will contain
header files that were previously included for building the single
object, and recorded in the .*.cmd file. To filter out such headers,
$(filter %.o,$^) should be used here.
Signed-off-by: Masahiro Yamada
and the linker now fails with the following:
mkdir -p /home/florian/dev/lkm/.tmp_versions ; rm -f
/home/florian/dev/lkm/.tmp_versions/*
WARNING: Symbol version dump ./Module.symvers
is missing; modules will have no dependencies and modversions.
make -f ./scripts/Makefile.build obj=/home/florian/dev/lkm
(cat /dev/null; echo kernel//home/florian/dev/lkm/hello.ko;) >
/home/florian/dev/lkm/modules.order
ld -m elf_x86_64 -z max-page-size=0x20-r -o
/home/florian/dev/lkm/hello.o
ld: no input files
make[1]: *** [scripts/Makefile.build:492: /home/florian/dev/lkm/hello.o]
Error 1
make: *** [Makefile:1530: _module_/home/florian/dev/lkm] Error 2
and here are some steps to reproduce this:
Kbuild:
obj-m := hello.o
hello-y := test.o_shipped
test.c can be a simple hello world, and you can compile it using a
standard Kbuild file first, and then move test.o as test.o_shipped.
I am afraid I do not speak Kbuild fluently enough to recommend a fix for
that.
Thanks!
--
Florian
RE: [EXT] [PATCH] scsi: qedi: remove Comparison of 0/1 to bool variable
> -Original Message- > From: Jason Yan > Sent: Thursday, April 30, 2020 5:47 PM > To: qlogic-storage-upstr...@cavium.com; j...@linux.ibm.com; > martin.peter...@oracle.com; Manish Rangankar > ; linux-s...@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: Jason Yan > Subject: [EXT] [PATCH] scsi: qedi: remove Comparison of 0/1 to bool > variable > > External Email > > -- > Fix the following coccicheck warning: > > drivers/scsi/qedi/qedi_main.c:1309:5-25: WARNING: Comparison of 0/1 to > bool variable > drivers/scsi/qedi/qedi_main.c:1315:5-25: WARNING: Comparison of 0/1 to > bool variable > > Signed-off-by: Jason Yan > --- > drivers/scsi/qedi/qedi_main.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c > index 4dd965860c98..46584e16d635 100644 > --- a/drivers/scsi/qedi/qedi_main.c > +++ b/drivers/scsi/qedi/qedi_main.c > @@ -1306,13 +1306,13 @@ static irqreturn_t qedi_msix_handler(int irq, > void *dev_id) > "process already running\n"); > } > > - if (qedi_fp_has_work(fp) == 0) > + if (!qedi_fp_has_work(fp)) > qed_sb_update_sb_idx(fp->sb_info); > > /* Check for more work */ > rmb(); > > - if (qedi_fp_has_work(fp) == 0) > + if (!qedi_fp_has_work(fp)) > qed_sb_ack(fp->sb_info, IGU_INT_ENABLE, 1); > else > goto process_again; > -- Thanks, Acked-by: Manish Rangankar
Re: [PATCH] x86: bitops: fix build regression
On Tue, May 05, 2020 at 10:44:22AM -0700, Nick Desaulniers wrote:
> From: Sedat Dilek
>
> It turns out that if your config tickles __builtin_constant_p via
> differences in choices to inline or not, this now produces invalid
> assembly:
>
> $ cat foo.c
> long a(long b, long c) {
> asm("orb\t%1, %0" : "+q"(c): "r"(b));
> return c;
> }
> $ gcc foo.c
> foo.c: Assembler messages:
> foo.c:2: Error: `%rax' not allowed with `orb'
>
> The "q" constraint only has meanting on -m32 otherwise is treated as
> "r".
>
> This is easily reproducible via Clang+CONFIG_STAGING=y+CONFIG_VT6656=m,
> or Clang+allyesconfig.
For what it's worth, I don't see this with allyesconfig.
> Keep the masking operation to appease sparse (`make C=1`), add back the
> cast in order to properly select the proper 8b register alias.
>
> [Nick: reworded]
>
> Cc: sta...@vger.kernel.org
The offending commit was added in 5.7-rc1; we shouldn't need to
Cc stable since this should be picked up as an -rc fix.
> Cc: Jesse Brandeburg
> Link: https://github.com/ClangBuiltLinux/linux/issues/961
> Link: https://lore.kernel.org/lkml/20200504193524.ga221...@google.com/
> Fixes: 1651e700664b4 ("x86: Fix bitops.h warning with a moved cast")
> Reported-by: Sedat Dilek
> Reported-by: kernelci.org bot
> Suggested-by: Andy Shevchenko
> Suggested-by: Ilie Halip
Not to split hairs but this is Ilie's diff, he should probably be the
author with Sedat's Reported-by/Tested-by.
https://github.com/ClangBuiltLinux/linux/issues/961#issuecomment-608239458
But eh, it's all a team effort plus that can only happen with Ilie's
explicit consent for a Signed-off-by.
I am currently doing a set of builds with clang-11 with this patch on
top of 5.7-rc4 to make sure that all of the cases I have found work.
Once that is done, I'll comment back with a tag.
> Tested-by: Sedat Dilek
> Signed-off-by: Sedat Dilek
> Signed-off-by: Nick Desaulniers
> ---
> arch/x86/include/asm/bitops.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
> index b392571c1f1d..139122e5b25b 100644
> --- a/arch/x86/include/asm/bitops.h
> +++ b/arch/x86/include/asm/bitops.h
> @@ -54,7 +54,7 @@ arch_set_bit(long nr, volatile unsigned long *addr)
> if (__builtin_constant_p(nr)) {
> asm volatile(LOCK_PREFIX "orb %1,%0"
> : CONST_MASK_ADDR(nr, addr)
> - : "iq" (CONST_MASK(nr) & 0xff)
> + : "iq" ((u8)(CONST_MASK(nr) & 0xff))
> : "memory");
> } else {
> asm volatile(LOCK_PREFIX __ASM_SIZE(bts) " %1,%0"
> @@ -74,7 +74,7 @@ arch_clear_bit(long nr, volatile unsigned long *addr)
> if (__builtin_constant_p(nr)) {
> asm volatile(LOCK_PREFIX "andb %1,%0"
> : CONST_MASK_ADDR(nr, addr)
> - : "iq" (CONST_MASK(nr) ^ 0xff));
> + : "iq" ((u8)(CONST_MASK(nr) ^ 0xff)));
> } else {
> asm volatile(LOCK_PREFIX __ASM_SIZE(btr) " %1,%0"
> : : RLONG_ADDR(addr), "Ir" (nr) : "memory");
> --
> 2.26.2.526.g744177e7f7-goog
>
Cheers,
Nathan
Re: [PATCH 2/2] powerpc/perf: Add support for outputting extended regs in perf intr_regs
On 4/29/20 11:34 AM, Anju T Sudhakar wrote:
The capability flag PERF_PMU_CAP_EXTENDED_REGS, is used to indicate the
PMU which support extended registers. The generic code define the mask
of extended registers as 0 for non supported architectures.
Add support for extended registers in POWER9 architecture. For POWER9,
the extended registers are mmcr0, mmc1 and mmcr2.
REG_RESERVED mask is redefined to accommodate the extended registers.
With patch:
# perf record -I?
available registers: r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14
r15 r16 r17 r18 r19 r20 r21 r22 r23 r24 r25 r26 r27 r28 r29 r30 r31 nip
msr orig_r3 ctr link xer ccr softe trap dar dsisr sier mmcra mmcr0
mmcr1 mmcr2
Would prefer to have some flexibility in deciding what to expose
in as extended regs. Meaning say if we want to add extended regs
in power8 and if we dont want to show for ex say mmcr2 (just for example).
Maddy
# perf record -I ls
# perf script -D
PERF_RECORD_SAMPLE(IP, 0x1): 9019/9019: 0 period: 1 addr: 0
... intr regs: mask 0x ABI 64-bit
r00xc011b12c
r10xc03f9a98b930
r20xc1a32100
r30xc03f8fe9a800
r40xc03fd181
r50x3e32557150
r60xc03f9a98b908
r70xffc1cdae06ac
r80x818
[.]
r31 0xc03ffd047230
nip 0xc011b2c0
msr 0x90009033
orig_r3 0xc011b21c
ctr 0xc0119380
link 0xc011b12c
xer 0x0
ccr 0x2800
softe 0x1
trap 0xf00
dar 0x0
dsisr 0x800
sier 0x0
mmcra 0x800
mmcr0 0x82008090
mmcr1 0x1e00
mmcr2 0x0
... thread: perf:9019
Signed-off-by: Anju T Sudhakar
---
arch/powerpc/include/asm/perf_event_server.h | 5 +++
arch/powerpc/include/uapi/asm/perf_regs.h | 13 +++-
arch/powerpc/perf/core-book3s.c | 1 +
arch/powerpc/perf/perf_regs.c | 29 ++--
arch/powerpc/perf/power9-pmu.c| 1 +
.../arch/powerpc/include/uapi/asm/perf_regs.h | 13 +++-
tools/perf/arch/powerpc/include/perf_regs.h | 6 +++-
tools/perf/arch/powerpc/util/perf_regs.c | 33 +++
8 files changed, 95 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/perf_event_server.h
b/arch/powerpc/include/asm/perf_event_server.h
index 3e9703f44c7c..1d15953bd99e 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -55,6 +55,11 @@ struct power_pmu {
int *blacklist_ev;
/* BHRB entries in the PMU */
int bhrb_nr;
+ /*
+* set this flag with `PERF_PMU_CAP_EXTENDED_REGS` if
+* the pmu supports extended perf regs capability
+*/
+ int capabilities;
};
/*
diff --git a/arch/powerpc/include/uapi/asm/perf_regs.h
b/arch/powerpc/include/uapi/asm/perf_regs.h
index f599064dd8dc..604b831378fe 100644
--- a/arch/powerpc/include/uapi/asm/perf_regs.h
+++ b/arch/powerpc/include/uapi/asm/perf_regs.h
@@ -48,6 +48,17 @@ enum perf_event_powerpc_regs {
PERF_REG_POWERPC_DSISR,
PERF_REG_POWERPC_SIER,
PERF_REG_POWERPC_MMCRA,
- PERF_REG_POWERPC_MAX,
+ /* Extended registers */
+ PERF_REG_POWERPC_MMCR0,
+ PERF_REG_POWERPC_MMCR1,
+ PERF_REG_POWERPC_MMCR2,
+ PERF_REG_EXTENDED_MAX,
+ /* Max regs without the extended regs */
+ PERF_REG_POWERPC_MAX = PERF_REG_POWERPC_MMCRA + 1,
};
+
+#define PERF_REG_PMU_MASK ((1ULL << PERF_REG_POWERPC_MAX) - 1)
+#define PERF_REG_EXTENDED_MASK (((1ULL << (PERF_REG_EXTENDED_MAX)) \
+ - 1) - PERF_REG_PMU_MASK)
+
#endif /* _UAPI_ASM_POWERPC_PERF_REGS_H */
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 3dcfecf858f3..f56b77800a7b 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2276,6 +2276,7 @@ int register_power_pmu(struct power_pmu *pmu)
power_pmu.attr_groups = ppmu->attr_groups;
+ power_pmu.capabilities |= (ppmu->capabilities &
PERF_PMU_CAP_EXTENDED_REGS);
#ifdef MSR_HV
/*
* Use FCHV to ignore kernel events if MSR.HV is set.
diff --git a/arch/powerpc/perf/perf_regs.c b/arch/powerpc/perf/perf_regs.c
index a213a0aa5d25..57aa02568caf 100644
--- a/arch/powerpc/perf/perf_regs.c
+++ b/arch/powerpc/perf/perf_regs.c
@@ -15,7 +15,8 @@
#define PT_REGS_OFFSET(id, r) [id] = offsetof(struct pt_regs, r)
-#define REG_RESERVED (~((1ULL << PERF_REG_POWERPC_MAX) - 1))
+#define REG_RESERVED (~(PERF_REG_EXTENDED_MASK) & \
+ (~((1ULL << PERF_REG_POWERPC_MAX) - 1)))
static unsigned int pt_regs_offset[PERF_REG_POWERPC_MAX] = {
PT_REGS_OFFSET(PERF_REG_POWERPC_R0, gpr[0]),
@@ -69,10 +70,22 @@ static unsigned int pt_regs_offset[PERF_REG_POWERPC_MAX] = {
[PATCH v3 4/5] ntb_perf: increase sleep time from one milli sec to one sec
After trying to send commands for a maximum of MSG_TRIES
re-tries, link-up fails due to short sleep time(1ms) between
re-tries. Hence increasing the sleep time to one second providing
sufficient time for perf link-up.
Signed-off-by: Sanjay R Mehta
Signed-off-by: Arindam Nath
---
drivers/ntb/test/ntb_perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ntb/test/ntb_perf.c b/drivers/ntb/test/ntb_perf.c
index 1c93b9f..dbcfdaa 100644
--- a/drivers/ntb/test/ntb_perf.c
+++ b/drivers/ntb/test/ntb_perf.c
@@ -101,8 +101,8 @@ MODULE_DESCRIPTION("PCIe NTB Performance Measurement Tool");
#define DMA_MDELAY 10
#define MSG_TRIES 1000
-#define MSG_UDELAY_LOW 1000
-#define MSG_UDELAY_HIGH2000
+#define MSG_UDELAY_LOW 100
+#define MSG_UDELAY_HIGH200
#define PERF_BUF_LEN 1024
--
2.7.4
[PATCH v3 2/5] ntb_perf: pass correct struct device to dma_alloc_coherent
Currently, ntb->dev is passed to dma_alloc_coherent
and dma_free_coherent calls. The returned dma_addr_t
is the CPU physical address. This works fine as long
as IOMMU is disabled. But when IOMMU is enabled, we
need to make sure that IOVA is returned for dma_addr_t.
So the correct way to achieve this is by changing the
first parameter of dma_alloc_coherent() as ntb->pdev->dev
instead.
Fixes: 5648e56 ("NTB: ntb_perf: Add full multi-port NTB API support")
Signed-off-by: Logan Gunthorpe
Signed-off-by: Sanjay R Mehta
Signed-off-by: Arindam Nath
---
drivers/ntb/test/ntb_perf.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/ntb/test/ntb_perf.c b/drivers/ntb/test/ntb_perf.c
index 972f6d9..1c93b9f 100644
--- a/drivers/ntb/test/ntb_perf.c
+++ b/drivers/ntb/test/ntb_perf.c
@@ -557,7 +557,7 @@ static void perf_free_inbuf(struct perf_peer *peer)
return;
(void)ntb_mw_clear_trans(peer->perf->ntb, peer->pidx, peer->gidx);
- dma_free_coherent(>perf->ntb->dev, peer->inbuf_size,
+ dma_free_coherent(>perf->ntb->pdev->dev, peer->inbuf_size,
peer->inbuf, peer->inbuf_xlat);
peer->inbuf = NULL;
}
@@ -586,8 +586,9 @@ static int perf_setup_inbuf(struct perf_peer *peer)
perf_free_inbuf(peer);
- peer->inbuf = dma_alloc_coherent(>ntb->dev, peer->inbuf_size,
->inbuf_xlat, GFP_KERNEL);
+ peer->inbuf = dma_alloc_coherent(>ntb->pdev->dev,
+peer->inbuf_size, >inbuf_xlat,
+GFP_KERNEL);
if (!peer->inbuf) {
dev_err(>ntb->dev, "Failed to alloc inbuf of %pa\n",
>inbuf_size);
@@ -1554,4 +1555,3 @@ static void __exit perf_exit(void)
destroy_workqueue(perf_wq);
}
module_exit(perf_exit);
-
--
2.7.4
[PATCH v3 3/5] ntb_tool: pass correct struct device to dma_alloc_coherent
Currently, ntb->dev is passed to dma_alloc_coherent
and dma_free_coherent calls. The returned dma_addr_t
is the CPU physical address. This works fine as long
as IOMMU is disabled. But when IOMMU is enabled, we
need to make sure that IOVA is returned for dma_addr_t.
So the correct way to achieve this is by changing the
first parameter of dma_alloc_coherent() as ntb->pdev->dev
instead.
Fixes: 5648e56 ("NTB: ntb_perf: Add full multi-port NTB API support")
Signed-off-by: Sanjay R Mehta
Signed-off-by: Arindam Nath
---
drivers/ntb/test/ntb_tool.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/ntb/test/ntb_tool.c b/drivers/ntb/test/ntb_tool.c
index 69da758..9eaeb22 100644
--- a/drivers/ntb/test/ntb_tool.c
+++ b/drivers/ntb/test/ntb_tool.c
@@ -590,7 +590,7 @@ static int tool_setup_mw(struct tool_ctx *tc, int pidx, int
widx,
inmw->size = min_t(resource_size_t, req_size, size);
inmw->size = round_up(inmw->size, addr_align);
inmw->size = round_up(inmw->size, size_align);
- inmw->mm_base = dma_alloc_coherent(>ntb->dev, inmw->size,
+ inmw->mm_base = dma_alloc_coherent(>ntb->pdev->dev, inmw->size,
>dma_base, GFP_KERNEL);
if (!inmw->mm_base)
return -ENOMEM;
@@ -612,7 +612,7 @@ static int tool_setup_mw(struct tool_ctx *tc, int pidx, int
widx,
return 0;
err_free_dma:
- dma_free_coherent(>ntb->dev, inmw->size, inmw->mm_base,
+ dma_free_coherent(>ntb->pdev->dev, inmw->size, inmw->mm_base,
inmw->dma_base);
inmw->mm_base = NULL;
inmw->dma_base = 0;
@@ -629,7 +629,7 @@ static void tool_free_mw(struct tool_ctx *tc, int pidx, int
widx)
if (inmw->mm_base != NULL) {
ntb_mw_clear_trans(tc->ntb, pidx, widx);
- dma_free_coherent(>ntb->dev, inmw->size,
+ dma_free_coherent(>ntb->pdev->dev, inmw->size,
inmw->mm_base, inmw->dma_base);
}
--
2.7.4
[PATCH v3 5/5] ntb_perf: avoid false dma unmap of destination address
The DMA map and unmap of destination address is already being
done in perf_init_test() and perf_clear_test() functions.
Hence avoiding it by making necessary changes in perf_copy_chunk()
function.
Signed-off-by: Sanjay R Mehta
Signed-off-by: Arindam Nath
---
drivers/ntb/test/ntb_perf.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/ntb/test/ntb_perf.c b/drivers/ntb/test/ntb_perf.c
index dbcfdaa..95a0853 100644
--- a/drivers/ntb/test/ntb_perf.c
+++ b/drivers/ntb/test/ntb_perf.c
@@ -804,7 +804,7 @@ static int perf_copy_chunk(struct perf_thread *pthr,
dst_vaddr = dst;
dst_dma_addr = peer->dma_dst_addr + (dst_vaddr - vbase);
- unmap = dmaengine_get_unmap_data(dma_dev, 2, GFP_NOWAIT);
+ unmap = dmaengine_get_unmap_data(dma_dev, 1, GFP_NOWAIT);
if (!unmap)
return -ENOMEM;
@@ -817,15 +817,8 @@ static int perf_copy_chunk(struct perf_thread *pthr,
}
unmap->to_cnt = 1;
- unmap->addr[1] = dst_dma_addr;
- if (dma_mapping_error(dma_dev, unmap->addr[1])) {
- ret = -EIO;
- goto err_free_resource;
- }
- unmap->from_cnt = 1;
-
do {
- tx = dmaengine_prep_dma_memcpy(pthr->dma_chan, unmap->addr[1],
+ tx = dmaengine_prep_dma_memcpy(pthr->dma_chan, dst_dma_addr,
unmap->addr[0], len, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!tx)
msleep(DMA_MDELAY);
--
2.7.4
[PATCH v3 0/5] ntb perf, ntb tool and ntb-hw improvements
v3: - Increased ntb_perf command re-try sleep time - avoid false dma unmap of dst address. v2: Incorporated improvements suggested by Logan Gunthorpe Links of the review comments for v3: 1. https://lkml.org/lkml/2020/3/11/981 2. https://lkml.org/lkml/2020/3/10/1827 Logan Gunthorpe (1): ntb: hw: remove the code that sets the DMA mask Sanjay R Mehta (4): ntb_perf: pass correct struct device to dma_alloc_coherent ntb_tool: pass correct struct device to dma_alloc_coherent ntb_perf: increase sleep time from one milli sec to one sec ntb_perf: avoid false dma unmap of destination address drivers/ntb/hw/amd/ntb_hw_amd.c| 4 drivers/ntb/hw/idt/ntb_hw_idt.c| 6 -- drivers/ntb/hw/intel/ntb_hw_gen1.c | 4 drivers/ntb/test/ntb_perf.c| 23 --- drivers/ntb/test/ntb_tool.c| 6 +++--- 5 files changed, 11 insertions(+), 32 deletions(-) -- 2.7.4
[PATCH v3 1/5] ntb: hw: remove the code that sets the DMA mask
From: Logan Gunthorpe
This patch removes the code that sets the DMA mask as it no longer
makes sense to do this.
Fixes: 7f46c8b3a552 ("NTB: ntb_tool: Add full multi-port NTB API support")
Signed-off-by: Logan Gunthorpe
Tested-by: Alexander Fomichev
Signed-off-by: Sanjay R Mehta
---
drivers/ntb/hw/amd/ntb_hw_amd.c| 4
drivers/ntb/hw/idt/ntb_hw_idt.c| 6 --
drivers/ntb/hw/intel/ntb_hw_gen1.c | 4
3 files changed, 14 deletions(-)
diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
index 9e310e1..88e1db6 100644
--- a/drivers/ntb/hw/amd/ntb_hw_amd.c
+++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
@@ -1191,10 +1191,6 @@ static int amd_ntb_init_pci(struct amd_ntb_dev *ndev,
goto err_dma_mask;
dev_warn(>dev, "Cannot DMA consistent highmem\n");
}
- rc = dma_coerce_mask_and_coherent(>ntb.dev,
- dma_get_mask(>dev));
- if (rc)
- goto err_dma_mask;
ndev->self_mmio = pci_iomap(pdev, 0, 0);
if (!ndev->self_mmio) {
diff --git a/drivers/ntb/hw/idt/ntb_hw_idt.c b/drivers/ntb/hw/idt/ntb_hw_idt.c
index edae523..d54261f 100644
--- a/drivers/ntb/hw/idt/ntb_hw_idt.c
+++ b/drivers/ntb/hw/idt/ntb_hw_idt.c
@@ -2660,12 +2660,6 @@ static int idt_init_pci(struct idt_ntb_dev *ndev)
dev_warn(>dev,
"Cannot set consistent DMA highmem bit mask\n");
}
- ret = dma_coerce_mask_and_coherent(>ntb.dev,
- dma_get_mask(>dev));
- if (ret != 0) {
- dev_err(>dev, "Failed to set NTB device DMA bit mask\n");
- return ret;
- }
/*
* Enable the device advanced error reporting. It's not critical to
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen1.c
b/drivers/ntb/hw/intel/ntb_hw_gen1.c
index bb57ec2..e053012 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen1.c
+++ b/drivers/ntb/hw/intel/ntb_hw_gen1.c
@@ -1783,10 +1783,6 @@ static int intel_ntb_init_pci(struct intel_ntb_dev
*ndev, struct pci_dev *pdev)
goto err_dma_mask;
dev_warn(>dev, "Cannot DMA consistent highmem\n");
}
- rc = dma_coerce_mask_and_coherent(>ntb.dev,
- dma_get_mask(>dev));
- if (rc)
- goto err_dma_mask;
ndev->self_mmio = pci_iomap(pdev, 0, 0);
if (!ndev->self_mmio) {
--
2.7.4
Re: [PATCH v3 12/14] PCI: j721e: Add TI J721E PCIe driver
Hi Rob,
On 4/30/2020 7:41 AM, Rob Herring wrote:
> On Fri, Apr 17, 2020 at 06:27:51PM +0530, Kishon Vijay Abraham I wrote:
>> Add support for PCIe controller in J721E SoC. The controller uses the
>> Cadence PCIe core programmed by pcie-cadence*.c. The PCIe controller
>> will work in both host mode and device mode.
>> Some of the features of the controller are:
>> *) Supports both RC mode and EP mode
>> *) Supports MSI and MSI-X support
>> *) Supports upto GEN3 speed mode
>> *) Supports SR-IOV capability
>> *) Ability to route all transactions via SMMU (support will be added
>> in a later patch).
>>
>> Signed-off-by: Kishon Vijay Abraham I
>> ---
>> drivers/pci/controller/cadence/Kconfig| 23 +
>> drivers/pci/controller/cadence/Makefile | 1 +
>> drivers/pci/controller/cadence/pci-j721e.c| 500 ++
>> .../controller/cadence/pcie-cadence-host.c| 4 +-
>> drivers/pci/controller/cadence/pcie-cadence.h | 8 +
>> 5 files changed, 534 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/pci/controller/cadence/pci-j721e.c
>>
>> diff --git a/drivers/pci/controller/cadence/Kconfig
>> b/drivers/pci/controller/cadence/Kconfig
>> index b76b3cf55ce5..5d30564190e1 100644
>> --- a/drivers/pci/controller/cadence/Kconfig
>> +++ b/drivers/pci/controller/cadence/Kconfig
>> @@ -42,4 +42,27 @@ config PCIE_CADENCE_PLAT_EP
>>endpoint mode. This PCIe controller may be embedded into many
>>different vendors SoCs.
>>
>> +config PCI_J721E
>> +bool
>> +
>> +config PCI_J721E_HOST
>> +bool "TI J721E PCIe platform host controller"
>> +depends on OF
>> +select PCIE_CADENCE_HOST
>> +select PCI_J721E
>> +help
>> + Say Y here if you want to support the TI J721E PCIe platform
>> + controller in host mode. TI J721E PCIe controller uses Cadence PCIe
>> + core.
>> +
>> +config PCI_J721E_EP
>> +bool "TI J721E PCIe platform endpoint controller"
>> +depends on OF
>> +depends on PCI_ENDPOINT
>> +select PCIE_CADENCE_EP
>> +select PCI_J721E
>> +help
>> + Say Y here if you want to support the TI J721E PCIe platform
>> + controller in endpoint mode. TI J721E PCIe controller uses Cadence
>> PCIe
>> + core.
>> endmenu
>> diff --git a/drivers/pci/controller/cadence/Makefile
>> b/drivers/pci/controller/cadence/Makefile
>> index 232a3f20876a..9bac5fb2f13d 100644
>> --- a/drivers/pci/controller/cadence/Makefile
>> +++ b/drivers/pci/controller/cadence/Makefile
>> @@ -3,3 +3,4 @@ obj-$(CONFIG_PCIE_CADENCE) += pcie-cadence.o
>> obj-$(CONFIG_PCIE_CADENCE_HOST) += pcie-cadence-host.o
>> obj-$(CONFIG_PCIE_CADENCE_EP) += pcie-cadence-ep.o
>> obj-$(CONFIG_PCIE_CADENCE_PLAT) += pcie-cadence-plat.o
>> +obj-$(CONFIG_PCI_J721E) += pci-j721e.o
>> diff --git a/drivers/pci/controller/cadence/pci-j721e.c
>> b/drivers/pci/controller/cadence/pci-j721e.c
>> new file mode 100644
>> index ..eee619c6ffae
>> --- /dev/null
>> +++ b/drivers/pci/controller/cadence/pci-j721e.c
>> @@ -0,0 +1,500 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/**
>> + * pci-j721e - PCIe controller driver for TI's J721E SoCs
>> + *
>> + * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
>> + * Author: Kishon Vijay Abraham I
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "../../pci.h"
>> +#include "pcie-cadence.h"
>> +
>> +#define ENABLE_REG_SYS_20x108
>> +#define STATUS_REG_SYS_20x508
>> +#define STATUS_CLR_REG_SYS_20x708
>> +#define LINK_DOWN BIT(1)
>> +
>> +#define J721E_PCIE_USER_CMD_STATUS 0x4
>> +#define LINK_TRAINING_ENABLEBIT(0)
>> +
>> +#define J721E_PCIE_USER_LINKSTATUS 0x14
>> +#define LINK_STATUS GENMASK(1, 0)
>> +
>> +enum link_status {
>> +NO_RECEIVERS_DETECTED,
>> +LINK_TRAINING_IN_PROGRESS,
>> +LINK_UP_DL_IN_PROGRESS,
>> +LINK_UP_DL_COMPLETED,
>> +};
>> +
>> +#define J721E_MODE_RC BIT(7)
>> +#define LANE_COUNT_MASK BIT(8)
>> +#define LANE_COUNT(n) ((n) << 8)
>> +
>> +#define GENERATION_SEL_MASK GENMASK(1, 0)
>> +
>> +#define MAX_LANES 2
>> +
>> +struct j721e_pcie {
>> +struct device *dev;
>> +struct device_node *node;
>> +u32 mode;
>> +u32 num_lanes;
>> +struct cdns_pcie*cdns_pcie;
>> +void __iomem*user_cfg_base;
>> +void __iomem*intd_cfg_base;
>> +};
>> +
>> +enum j721e_pcie_mode {
>> +PCI_MODE_RC,
>> +PCI_MODE_EP,
>> +};
>> +
>> +struct j721e_pcie_data {
>> +enum j721e_pcie_modemode;
>> +};
>> +
>> +static inline u32 j721e_pcie_user_readl(struct j721e_pcie *pcie, u32 offset)
>> +{
>> +return readl(pcie->user_cfg_base + offset);
>> +}
>> +
>> +static
Re: [PATCH v8 1/5] dt-bindings: phy: Add binding for qcom,usb-snps-femto-v2
On 05-05-20, 12:38, Wesley Cheng wrote: > > > On 5/5/2020 6:34 AM, Rob Herring wrote: > > On Mon, 4 May 2020 16:54:23 -0700, Wesley Cheng wrote: > >> This binding shows the descriptions and properties for the > >> Synopsis Femto USB PHY V2 used on QCOM platforms. > >> > >> Signed-off-by: Wesley Cheng > >> Reviewed-by: Rob Herring > >> Reviewed-by: Stephen Boyd > >> --- > >> .../bindings/phy/qcom,usb-snps-femto-v2.yaml | 77 > >> ++ > >> 1 file changed, 77 insertions(+) > >> create mode 100644 > >> Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml > >> > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.example.dt.yaml: > > phy@88e2000: 'vdda-pll-supply' is a required property > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.example.dt.yaml: > > phy@88e2000: 'vdda18-supply' is a required property > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.example.dt.yaml: > > phy@88e2000: 'vdda33-supply' is a required property > > > > See https://patchwork.ozlabs.org/patch/1283143 > > > > If you already ran 'make dt_binding_check' and didn't see the above > > error(s), then make sure dt-schema is up to date: > > > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master > > --upgrade > > > > Please check and re-submit. > > > > Hi Rob, > > I updated the dt-schema version, and I can see the same error. Will fix > and resubmit. I also realized that the dt_binding_check doesn't stop if No, pls submit the fix against already applied patches and also give credit to Rob by adding a "Reported-by: ..." > errors are detected in the example DT checking phase, and that was > probably why I missed this initially. I'll pass the DT_SCHEMA_FILES > argument to my specific binding next time to help verify my file. > Thanks again! > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project -- ~Vinod
Re: KASAN: slab-out-of-bounds Read in gadget_dev_desc_UDC_store
On Fri, May 01, 2020 at 09:05:38AM +0200, Greg KH wrote: > On Thu, Apr 30, 2020 at 11:03:54PM -0400, Kyungtae Kim wrote: > > We report a bug (in linux-5.6.8) found by FuzzUSB (a modified version > > of syzkaller). > > > > This happened when the size of "name" buffer is smaller than that of > > "page" buffer > > (after function kstrdup executed at line 263). > > I guess it comes from the "page" buffer containing 0 value in the middle. > > So accessing the "name" buffer with "len" variable, which is used to > > indicate the size of "page" buffer, > > triggered memory access violation. > > To fix, it may need to check the size of name buffer, and try to use > > right index variable. > > Can you submit a patch for this as you have a reproducer to test the > issue? > > thanks, > > greg k-h I just submitted a patch after testing with the repro. Regards, Kyungtae
[PATCH] USB: gadget: fix illegal array access in binding with UDC
FuzzUSB (a variant of syzkaller) found an illegal array access using an incorrect index while binding a gadget with UDC. Reference: https://www.spinics.net/lists/linux-usb/msg194331.html This bug occurs when a size variable used for a buffer is misused to access its strcpy-ed buffer. Given a buffer along with its size variable (taken from user input), from which, a new buffer is created using kstrdup(). Due to the original buffer containing 0 value in the middle, the size of the kstrdup-ed buffer becomes smaller than that of the original. So accessing the kstrdup-ed buffer with the same size variable triggers memory access violation. The fix makes sure no zero value in the buffer, by comparing the strlen() of the orignal buffer with the size variable, so that the access to the kstrdup-ed buffer is safe. BUG: KASAN: slab-out-of-bounds in gadget_dev_desc_UDC_store+0x1ba/0x200 drivers/usb/gadget/configfs.c:266 Read of size 1 at addr 88806a55dd7e by task syz-executor.0/17208 CPU: 2 PID: 17208 Comm: syz-executor.0 Not tainted 5.6.8 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xce/0x128 lib/dump_stack.c:118 print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374 __kasan_report+0x131/0x1b0 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:641 __asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:132 gadget_dev_desc_UDC_store+0x1ba/0x200 drivers/usb/gadget/configfs.c:266 flush_write_buffer fs/configfs/file.c:251 [inline] configfs_write_file+0x2f1/0x4c0 fs/configfs/file.c:283 __vfs_write+0x85/0x110 fs/read_write.c:494 vfs_write+0x1cd/0x510 fs/read_write.c:558 ksys_write+0x18a/0x220 fs/read_write.c:611 __do_sys_write fs/read_write.c:623 [inline] __se_sys_write fs/read_write.c:620 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:620 do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Signed-off-by: Kyungtae Kim Reported-and-tested-by: Kyungtae Kim --- drivers/usb/gadget/configfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c index 32b637e3e1fa..6a9aa4413d64 100644 --- a/drivers/usb/gadget/configfs.c +++ b/drivers/usb/gadget/configfs.c @@ -260,6 +260,9 @@ static ssize_t gadget_dev_desc_UDC_store(struct config_item *item, char *name; int ret; + if (strlen(page) < len) + return -EOVERFLOW; + name = kstrdup(page, GFP_KERNEL); if (!name) return -ENOMEM; -- 2.17.1
Re: [PATCH 1/4] block: Move SECTORS_PER_PAGE and SECTORS_PER_PAGE_SHIFT definitions into
On 2020/5/5 20:10, Matthew Wilcox wrote:
> On Tue, May 05, 2020 at 07:55:40PM +0800, Zhen Lei wrote:
>> +#ifndef SECTORS_PER_PAGE_SHIFT
>> +#define SECTORS_PER_PAGE_SHIFT (PAGE_SHIFT - SECTOR_SHIFT)
>> +#endif
>> +#ifndef SECTORS_PER_PAGE
>> +#define SECTORS_PER_PAGE(1 << SECTORS_PER_PAGE_SHIFT)
>> #endif
>
> I find SECTORS_PER_PAGE_SHIFT quite hard to read. I had a quick skim
> of your other patches, and it seems to me that we could replace
> '<< SECTORS_PER_PAGE_SHIFT' with '* SECTORS_PER_PAGE' and it would be
> more readable in every case.
OK, I will delete SECTORS_PER_PAGE_SHIFT, and replace the shift with {*|/}
SECTORS_PER_PAGE if it's
not suitable to be replaced by sectors_to_page()/page_to_sectors().
>
> .
>
Re: [PATCH] securityfs: Add missing d_delete() call on removal
On Tue, May 05, 2020 at 08:28:33PM -0700, Kees Cook wrote: > On Wed, May 06, 2020 at 02:14:31AM +0100, Al Viro wrote: > > On Tue, May 05, 2020 at 04:40:35PM -0700, Kees Cook wrote: > > > After using simple_unlink(), a call to d_delete() is needed in addition > > > to dput(). > > > > > > Signed-off-by: Kees Cook > > > --- > > > Is this correct? I went looking around and there are a lot of variations > > > on the simple_unlink() pattern... > > > > > > Many using explicit locking and combinations of d_drop(), __d_drop(), etc. > > > > Quite a few of those should switch to simple_recursive_removal(). As for > > securityfs... d_drop() is _probably_ a saner variant, but looking at the > > callers of that thing... at least IMA ones seem to be garbage. > > Hmm, I dunno. I hadn't looked at these yet. I'm not sure what's needed > for those cases. > > Is my patch to add d_delete() correct, though? I'm trying to construct > the right set of calls for pstore's filesystem, and I noticed that most > will do simple_unlink(), d_delete(), dput(), but securityfs seemed to be > missing it. d_drop(). d_delete() is for the situations when you want the sucker to become a hashed negative, if at all possible. Re pstore: context, please.
Re: [PATCH v3 09/14] PCI: cadence: Add MSI-X support to Endpoint driver
Hi Rob,
On 4/30/2020 7:25 AM, Rob Herring wrote:
> On Fri, Apr 17, 2020 at 06:27:48PM +0530, Kishon Vijay Abraham I wrote:
>> From: Alan Douglas
>>
>> Implement ->set_msix() and ->get_msix() callback functions in order
>> to configure MSIX capability in the PCIe endpoint controller.
>>
>> Add cdns_pcie_ep_send_msix_irq() to send MSIX interrupts to Host.
>> cdns_pcie_ep_send_msix_irq() gets the MSIX table address (virtual
>> address) from "struct cdns_pcie_epf" that gets initialized in
>> ->set_bar() call back function.
>>
>> [kis...@ti.com: Re-implement MSIX support in accordance with the
>> re-designed core MSI-X interfaces]
>> Signed-off-by: Kishon Vijay Abraham I
>> Signed-off-by: Alan Douglas
>
> Your Sob should be last.
Will fix this!
Thanks
Kishon
>
>> ---
>> .../pci/controller/cadence/pcie-cadence-ep.c | 112 +-
>> drivers/pci/controller/cadence/pcie-cadence.h | 10 ++
>> 2 files changed, 121 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c
>> b/drivers/pci/controller/cadence/pcie-cadence-ep.c
>> index 14021d760482..c43340ca0630 100644
>> --- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
>> +++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
>> @@ -51,6 +51,7 @@ static int cdns_pcie_ep_set_bar(struct pci_epc *epc, u8 fn,
>> struct pci_epf_bar *epf_bar)
>> {
>> struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> +struct cdns_pcie_epf *epf = >epf[fn];
>> struct cdns_pcie *pcie = >pcie;
>> dma_addr_t bar_phys = epf_bar->phys_addr;
>> enum pci_barno bar = epf_bar->barno;
>> @@ -111,6 +112,8 @@ static int cdns_pcie_ep_set_bar(struct pci_epc *epc, u8
>> fn,
>> CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL(b, ctrl));
>> cdns_pcie_writel(pcie, reg, cfg);
>>
>> +epf->epf_bar[bar] = epf_bar;
>> +
>> return 0;
>> }
>>
>> @@ -118,6 +121,7 @@ static void cdns_pcie_ep_clear_bar(struct pci_epc *epc,
>> u8 fn,
>> struct pci_epf_bar *epf_bar)
>> {
>> struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> +struct cdns_pcie_epf *epf = >epf[fn];
>> struct cdns_pcie *pcie = >pcie;
>> enum pci_barno bar = epf_bar->barno;
>> u32 reg, cfg, b, ctrl;
>> @@ -139,6 +143,8 @@ static void cdns_pcie_ep_clear_bar(struct pci_epc *epc,
>> u8 fn,
>>
>> cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR0(fn, bar), 0);
>> cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR1(fn, bar), 0);
>> +
>> +epf->epf_bar[bar] = NULL;
>> }
>>
>> static int cdns_pcie_ep_map_addr(struct pci_epc *epc, u8 fn, phys_addr_t
>> addr,
>> @@ -224,6 +230,50 @@ static int cdns_pcie_ep_get_msi(struct pci_epc *epc, u8
>> fn)
>> return mme;
>> }
>>
>> +static int cdns_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)
>> +{
>> +struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> +struct cdns_pcie *pcie = >pcie;
>> +u32 cap = CDNS_PCIE_EP_FUNC_MSIX_CAP_OFFSET;
>> +u32 val, reg;
>> +
>> +reg = cap + PCI_MSIX_FLAGS;
>> +val = cdns_pcie_ep_fn_readw(pcie, func_no, reg);
>> +if (!(val & PCI_MSIX_FLAGS_ENABLE))
>> +return -EINVAL;
>> +
>> +val &= PCI_MSIX_FLAGS_QSIZE;
>> +
>> +return val;
>> +}
>> +
>> +static int cdns_pcie_ep_set_msix(struct pci_epc *epc, u8 fn, u16 interrupts,
>> + enum pci_barno bir, u32 offset)
>> +{
>> +struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> +struct cdns_pcie *pcie = >pcie;
>> +u32 cap = CDNS_PCIE_EP_FUNC_MSIX_CAP_OFFSET;
>> +u32 val, reg;
>> +
>> +reg = cap + PCI_MSIX_FLAGS;
>> +val = cdns_pcie_ep_fn_readw(pcie, fn, reg);
>> +val &= ~PCI_MSIX_FLAGS_QSIZE;
>> +val |= interrupts;
>> +cdns_pcie_ep_fn_writew(pcie, fn, reg, val);
>> +
>> +/* Set MSIX BAR and offset */
>> +reg = cap + PCI_MSIX_TABLE;
>> +val = offset | bir;
>> +cdns_pcie_ep_fn_writel(pcie, fn, reg, val);
>> +
>> +/* Set PBA BAR and offset. BAR must match MSIX BAR */
>> +reg = cap + PCI_MSIX_PBA;
>> +val = (offset + (interrupts * PCI_MSIX_ENTRY_SIZE)) | bir;
>> +cdns_pcie_ep_fn_writel(pcie, fn, reg, val);
>> +
>> +return 0;
>> +}
>> +
>> static void cdns_pcie_ep_assert_intx(struct cdns_pcie_ep *ep, u8 fn,
>> u8 intx, bool is_asserted)
>> {
>> @@ -330,6 +380,56 @@ static int cdns_pcie_ep_send_msi_irq(struct
>> cdns_pcie_ep *ep, u8 fn,
>> return 0;
>> }
>>
>> +static int cdns_pcie_ep_send_msix_irq(struct cdns_pcie_ep *ep, u8 fn,
>> + u16 interrupt_num)
>> +{
>> +u32 cap = CDNS_PCIE_EP_FUNC_MSIX_CAP_OFFSET;
>> +u32 tbl_offset, msg_data, reg, vec_ctrl;
>> +struct cdns_pcie *pcie = >pcie;
>> +struct pci_epf_msix_tbl *msix_tbl;
>> +struct pci_epf_bar *epf_bar;
>> +struct cdns_pcie_epf *epf;
>> +u64 pci_addr_mask = 0xff;
>> +u64 msg_addr;
>> +u16 flags;
>> +u8 bir;
>> +
RE: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive Unleashed A00 board.
Hi Palmer, > -Original Message- > From: Palmer Dabbelt > Sent: Wednesday, May 6, 2020 4:54 AM > To: Sagar Kadam > Cc: tudor.amba...@microchip.com; miquel.ray...@bootlin.com; > rich...@nod.at; vigne...@ti.com; Paul Walmsley > ; linux-ri...@lists.infradead.org; linux- > ker...@vger.kernel.org; linux-...@lists.infradead.org > Subject: RE: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive Unleashed > A00 board. > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Tue, 05 May 2020 00:18:45 PDT (-0700), sagar.ka...@sifive.com wrote: > > Hello Palmer, > > > >> -Original Message- > >> From: Palmer Dabbelt > >> Sent: Tuesday, May 5, 2020 3:40 AM > >> To: Sagar Kadam > >> Cc: tudor.amba...@microchip.com; miquel.ray...@bootlin.com; > >> rich...@nod.at; vigne...@ti.com; Paul Walmsley > >> ; linux-ri...@lists.infradead.org; linux- > >> ker...@vger.kernel.org; linux-...@lists.infradead.org; Sagar Kadam > >> > >> Subject: Re: [PATCH 1/2] riscv: defconfig: enable spi nor on Hifive > Unleashed > >> A00 board. > >> > >> [External Email] Do not click links or attachments unless you recognize > the > >> sender and know the content is safe > >> > >> On Thu, 30 Apr 2020 02:58:51 PDT (-0700), sagar.ka...@sifive.com > wrote: > >> > Enable MTD based SPI-NOR framework in order to use spi flash > available > >> > on HiFive Unleashed A00 board. > >> > > >> > Signed-off-by: Sagar Shrikant Kadam > >> > --- > >> > arch/riscv/configs/defconfig | 2 ++ > >> > 1 file changed, 2 insertions(+) > >> > > >> > diff --git a/arch/riscv/configs/defconfig > >> > b/arch/riscv/configs/defconfig index 4da4886..970580b 100644 > >> > --- a/arch/riscv/configs/defconfig > >> > +++ b/arch/riscv/configs/defconfig > >> > @@ -80,6 +80,8 @@ CONFIG_USB_STORAGE=y CONFIG_USB_UAS=y > >> CONFIG_MMC=y > >> > CONFIG_MMC_SPI=y > >> > +CONFIG_MTD=y > >> > +CONFIG_MTD_SPI_NOR=y > >> > CONFIG_RTC_CLASS=y > >> > CONFIG_VIRTIO_PCI=y > >> > CONFIG_VIRTIO_BALLOON=y > >> > >> From the second patch's description I'm assuming that MTD still > functions > >> correctly without that change? > > > > Yes Palmer, the second patch is to enable QUAD write to nor flash.. > > MTD function's correctly without second patch. > > > > Using the character interface (/dev/mtd0) mtd_utils (mtd_debug : > erase/read/write) work fine. > > We might require CONFIG_MTD_BLOCK, CONFIG_MTD_CMDLINE_PARTS > in order to use MTD partitioning. > > IMHO it can be at user's choice weather to use flash partitions or not, so I > have not enabled. Please let me > > know if I should enable these features as well. > > Looks like arm64 has these: > > arch/arm64/configs/defconfig:CONFIG_MTD=y > arch/arm64/configs/defconfig:CONFIG_MTD_BLOCK=y > arch/arm64/configs/defconfig:CONFIG_MTD_CFI=y > arch/arm64/configs/defconfig:CONFIG_MTD_CFI_ADV_OPTIONS=y > arch/arm64/configs/defconfig:CONFIG_MTD_CFI_INTELEXT=y > arch/arm64/configs/defconfig:CONFIG_MTD_CFI_AMDSTD=y > arch/arm64/configs/defconfig:CONFIG_MTD_CFI_STAA=y > arch/arm64/configs/defconfig:CONFIG_MTD_PHYSMAP=y > arch/arm64/configs/defconfig:CONFIG_MTD_PHYSMAP_OF=y > arch/arm64/configs/defconfig:CONFIG_MTD_DATAFLASH=y > arch/arm64/configs/defconfig:CONFIG_MTD_SST25L=y > arch/arm64/configs/defconfig:CONFIG_MTD_RAW_NAND=y > arch/arm64/configs/defconfig:CONFIG_MTD_NAND_DENALI_DT=y > arch/arm64/configs/defconfig:CONFIG_MTD_NAND_MARVELL=y > arch/arm64/configs/defconfig:CONFIG_MTD_NAND_FSL_IFC=y > arch/arm64/configs/defconfig:CONFIG_MTD_NAND_QCOM=y > arch/arm64/configs/defconfig:CONFIG_MTD_SPI_NOR=y > > so I think we're good with just what you have here: MTD_BLOCK doesn't > seem that > useful, and the rest are drivers. That said, these (along with SPI and > SPI_SIFIVE) should really be in Kconfig.socs rather than defconfig. Can you > send a patch that does that? > Yes sure, I will send a V2 series, where SPI, SPI_SIFIVE, MTD, and MTD_SPI_NOR will be a part of Kconfig.socs. Thanks & BR, Sagar Kadam > > > > To demonstrate a bit more with linux 5.7-rc3 > > > > Specify on U-boot prompt: > > # setenv bootargs "root=/dev/ram rw console=ttySIF0 > mtdparts=spi0.0:1024k(loader1),4096K(loader2),26M(rootfs)" > > > > After booting linux will enumerate mtd partitions: > > # cat /proc/mtd > > dev:size erasesize name > > mtd0: 0010 1000 "loader1" > > mtd1: 0040 1000 "loader2" > > mtd2: 01a0 1000 "rootfs" > > > > # cat /proc/partitions > > major minor #blocks name > > 310 1024 mtdblock0 > > 311 4096 mtdblock1 > > 312 26624 mtdblock2 > > > > #Format mtdblock2 with mkfs.ext3/4 and mount results in > > # mkfs.ext3 /dev/mtdblock2 > > mke2fs 1.44.5 (15-Dec-2018) > > /dev/mtdblock2 contains a ext3 file system > > last mounted on /mnt on Thu Jan 1 00:00:14 1970 > > Proceed anyway? (y,N) y > > Creating filesystem with 26624 1k blocks and 6656 inodes > > Filesystem UUID:
Re: [PATCH v3 14/14] MAINTAINERS: Add Kishon Vijay Abraham I for TI J721E SoC PCIe
Hi Joe, On 4/17/2020 8:49 PM, Joe Perches wrote: > On Fri, 2020-04-17 at 18:27 +0530, Kishon Vijay Abraham I wrote: >> Add Kishon Vijay Abraham I as MAINTAINER for TI J721E SoC PCIe. > [] >> diff --git a/MAINTAINERS b/MAINTAINERS > [] >> @@ -12968,13 +12968,15 @@ S: Maintained >> F: Documentation/devicetree/bindings/pci/designware-pcie.txt >> F: drivers/pci/controller/dwc/*designware* >> >> -PCI DRIVER FOR TI DRA7XX >> +PCI DRIVER FOR TI DRA7XX/J721E >> M: Kishon Vijay Abraham I >> L: linux-o...@vger.kernel.org >> L: linux-...@vger.kernel.org >> +L: linux-arm-ker...@lists.infradead.org >> S: Supported >> F: Documentation/devicetree/bindings/pci/ti-pci.txt >> F: drivers/pci/controller/dwc/pci-dra7xx.c >> +F: drivers/pci/controller/cadence/pci-j721e.c > > Please keep file patterns in alphabetic order by > moving this new cadence line up one line above dwc. Sure, will fix this up in my next revision. Thanks Kishon
Re: [PATCH v2] security: disable FORTIFY_SOURCE on clang
On Tue, May 05, 2020 at 07:54:09PM -0700, Kees Cook wrote:
> On Tue, May 05, 2020 at 06:14:53PM -0600, Jason A. Donenfeld wrote:
> > clang-10 has a broken optimization stage that doesn't allow the
> > compiler to prove at compile time that certain memcpys are within
> > bounds, and thus the outline memcpy is always called, resulting in
> > horrific performance, and in some cases, excessive stack frame growth.
> > Here's a simple reproducer:
> >
> > typedef unsigned long size_t;
> > void *c(void *dest, const void *src, size_t n) __asm__("memcpy");
> > extern inline __attribute__((gnu_inline)) void *memcpy(void *dest,
> > const void *src, size_t n) { return c(dest, src, n); }
> > void blah(char *a)
> > {
> > unsigned long long b[10], c[10];
> > int i;
> >
> > memcpy(b, a, sizeof(b));
> > for (i = 0; i < 10; ++i)
> > c[i] = b[i] ^ b[9 - i];
> > for (i = 0; i < 10; ++i)
> > b[i] = c[i] ^ a[i];
> > memcpy(a, b, sizeof(b));
> > }
> >
> > Compile this with clang-9 and clang-10 and observe:
> >
> > zx2c4@thinkpad /tmp/curve25519-hacl64-stack-frame-size-test $ clang-10
> > -Wframe-larger-than=0 -O3 -c b.c -o c10.o
> > b.c:5:6: warning: stack frame size of 104 bytes in function 'blah'
> > [-Wframe-larger-than=]
> > void blah(char *a)
> > ^
> > 1 warning generated.
> > zx2c4@thinkpad /tmp/curve25519-hacl64-stack-frame-size-test $ clang-9
> > -Wframe-larger-than=0 -O3 -c b.c -o c9.o
> >
> > Looking at the disassembly of c10.o and c9.o, one can see that c9.o is
> > properly optimized in the obvious way one would expect, while c10.o has
> > blown up and includes extern calls to memcpy.
> >
> > But actually, for versions of clang earlier than 10, fortify source
> > mostly does nothing. So, between being broken and doing nothing, it
> > probably doesn't make sense to pretend to offer this option. So, this
> > commit just disables it entirely when compiling with clang.
> >
> > Cc: Arnd Bergmann
> > Cc: LKML
> > Cc: clang-built-linux
> > Cc: Kees Cook
> > Cc: George Burgess
> > Cc: Nick Desaulniers
> > Link: https://bugs.llvm.org/show_bug.cgi?id=45802
> > Signed-off-by: Jason A. Donenfeld
>
> Grudgingly,
>
> Reviewed-by: Kees Cook
>
> --
> Kees Cook
>
I feel like you should finish your investigation into how broken this
actually is before we give it the hammer like this but if it is going
in regardless...
Reviewed-by: Nathan Chancellor
[PATCH] KVM: VMX: Explicitly clear RFLAGS.CF and RFLAGS.ZF in VM-Exit RSB path
Clear CF and ZF in the VM-Exit path after doing __FILL_RETURN_BUFFER so
that KVM doesn't interpret clobbered RFLAGS as a VM-Fail. Filling the
RSB has always clobbered RFLAGS, its current incarnation just happens
clear CF and ZF in the processs. Relying on the macro to clear CF and
ZF is extremely fragile, e.g. commit 089dd8e53126e ("x86/speculation:
Change FILL_RETURN_BUFFER to work with objtool") tweaks the loop such
that the ZF flag is always set.
Reported-by: Qian Cai
Cc: Rick Edgecombe
Cc: Peter Zijlstra (Intel)
Cc: Josh Poimboeuf
Cc: sta...@vger.kernel.org
Fixes: f2fde6a5bcfcf ("KVM: VMX: Move RSB stuffing to before the first RET
after VM-Exit")
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/vmenter.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kvm/vmx/vmenter.S b/arch/x86/kvm/vmx/vmenter.S
index 87f3f24fef37b..51d1a82742fd5 100644
--- a/arch/x86/kvm/vmx/vmenter.S
+++ b/arch/x86/kvm/vmx/vmenter.S
@@ -82,6 +82,9 @@ SYM_FUNC_START(vmx_vmexit)
/* IMPORTANT: Stuff the RSB immediately after VM-Exit, before RET! */
FILL_RETURN_BUFFER %_ASM_AX, RSB_CLEAR_LOOPS, X86_FEATURE_RETPOLINE
+ /* Clear RFLAGS.CF and RFLAGS.ZF to preserve VM-Exit, i.e. !VM-Fail. */
+ or $1, %_ASM_AX
+
pop %_ASM_AX
.Lvmexit_skip_rsb:
#endif
--
2.26.0
[PATCH] iio: sca3000: Remove an erroneous 'get_device()'
This looks really unusual to have a 'get_device()' hidden in a 'dev_err()'
call.
Remove it.
While at it add a missing \n at the end of the message.
Signed-off-by: Christophe JAILLET
---
This patch is purely speculative.
I've looked a bit arround and see no point for this get_device() but other
eyes are welcomed :)
---
drivers/iio/accel/sca3000.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/accel/sca3000.c b/drivers/iio/accel/sca3000.c
index 66d768d971e1..6e429072e44a 100644
--- a/drivers/iio/accel/sca3000.c
+++ b/drivers/iio/accel/sca3000.c
@@ -980,7 +980,7 @@ static int sca3000_read_data(struct sca3000_state *st,
st->tx[0] = SCA3000_READ_REG(reg_address_high);
ret = spi_sync_transfer(st->us, xfer, ARRAY_SIZE(xfer));
if (ret) {
- dev_err(get_device(>us->dev), "problem reading register");
+ dev_err(>us->dev, "problem reading register\n");
return ret;
}
--
2.25.1
Re: [PATCH 2/4] mm/swap: use SECTORS_PER_PAGE_SHIFT to clean up code
On 2020/5/6 9:33, Leizhen (ThunderTown) wrote: > > > On 2020/5/6 1:25, Matthew Wilcox wrote: >> On Tue, May 05, 2020 at 07:55:41PM +0800, Zhen Lei wrote: >>> +++ b/mm/swapfile.c >>> @@ -177,8 +177,8 @@ static int discard_swap(struct swap_info_struct *si) >>> >>> /* Do not discard the swap header page! */ >>> se = first_se(si); >>> - start_block = (se->start_block + 1) << (PAGE_SHIFT - 9); >>> - nr_blocks = ((sector_t)se->nr_pages - 1) << (PAGE_SHIFT - 9); >>> + start_block = (se->start_block + 1) << SECTORS_PER_PAGE_SHIFT; >>> + nr_blocks = ((sector_t)se->nr_pages - 1) << SECTORS_PER_PAGE_SHIFT; >> >> Thinking about this some more, wouldn't this look better? >> >> start_block = page_sectors(se->start_block + 1); >> nr_block = page_sectors(se->nr_pages - 1); >> > > OK，That's fine, it's clearer. And in this way, there won't be more than 80 > columns. Should we rename "page_sectors" to "page_to_sectors"? Because we may need to define "sectors_to_page" also. > >> >> . >>
Re: [PATCH] arm64: disable patchable function entry on big-endian clang builds
+ Fangrui, who implemented patchable_function_entry in LLVM/clang
On Tue, May 05, 2020 at 07:42:43PM +0200, Torsten Duwe wrote:
> Hi Arnd, Mark and others,
>
> this may not be worth arguing but I'm currently fighting excessive
> workarounds in another area and so this triggers me, so I have to make
> a remark ;-)
>
> On Tue, 5 May 2020 15:25:56 +0100
> Mark Rutland wrote:
>
> > On Tue, May 05, 2020 at 04:12:36PM +0200, Arnd Bergmann wrote:
> > > Clang only supports the patchable_function_entry attribute on
> > > little-endian arm64 builds, but not on big-endian:
> > >
> > > include/linux/kasan-checks.h:16:8: error: unknown attribute
> > > 'patchable_function_entry' ignored [-Werror,-Wunknown-attributes]
> > >
> > > Disable that configuration with another dependency. Unfortunately
> > > the existing check is not enough, as $(cc-option) at this point does
> > > not pass the -mbig-endian flag.
> >
> > Well that's unfortunate. :(
> >
> > Do we know if this is deliberate and/or likely to change in future?
I am not sure this is deliberate, I don't see anything about endianness
in the commits that added this:
https://github.com/llvm/llvm-project/commit/4d1e23e3b3cd7c72a8b24dc5acb7e13c58a8de37
https://github.com/llvm/llvm-project/commit/22467e259507f5ead2a87d989251b4c951a587e4
https://github.com/llvm/llvm-project/commit/06b8e32d4fd3f634f793e3bc0bc4fdb885e7a3ac
> > This practically rules out a BE distro kernel with things like PAC,
> > which isn't ideal.
To be fair, are there big endian AArch64 distros?
https://wiki.debian.org/Arm64Port: "There is also a big-endian version
of the architecture/ABI: aarch64_be-linux-gnu but we're not supporting
that in Debian (so there is no corresponding Debian architecture name)
and hopefully will never have to. Nevertheless you might want to check
for this by way of completeness in upstream code."
OpenSUSE and Fedora don't appear to have support for big endian.
> But still better than cumulating workarounds. If clang's flags aren't
> orthogonal then that's a bug in clang. If I get a vote here I'm against
> it.
>
> > > Fixes: 3b23e4991fb6 ("arm64: implement ftrace with regs")
> > > Signed-off-by: Arnd Bergmann
> >
> > This looks fine for now, and we can add a version check in future, so:
> ^^^
> see what I mean? And in the end another line of code you'll never again
> get rid of.
That's a rather pessimistic attitude to have. We've been rather good
about trying to fix stuff in the compiler rather than hacking up the
kernel.
> I suggest to get a quote from clang folks first about their schedule and
> regarded importance of patchable-function-entries on BE, and leave it as
> is: broken on certain clang configurations. It's not the kernel's fault.
We can file an upstream PR (https://bugs.llvm.org) to talk about this
(although I've CC'd Fangrui) but you would rather the kernel fail to
work properly than prevent the user from being able to select that
option? Why even have the "select" or "depends on" keyword then?
That said, I do think we should hold off on this patch until we hear
from the LLVM developers.
> > Acked-by: Mark Rutland
> >
> > Mark.
> >
> > > ---
> > > arch/arm64/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index 4b256fa6db7a..a33d6402b934 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -151,7 +151,7 @@ config ARM64
> > > select HAVE_DMA_CONTIGUOUS
> > > select HAVE_DYNAMIC_FTRACE
> > > select HAVE_DYNAMIC_FTRACE_WITH_REGS \
> > > - if $(cc-option,-fies on y=2)
> > > + if $(cc-option,-fpatchable-function-entry=2) &&
> > > !(CC_IS_CLANG && CPU_BIG_ENDIAN) select
> > > HAVE_EFFICIENT_UNALIGNED_ACCESS select HAVE_FAST_GUP
> > > select HAVE_FTRACE_MCOUNT_RECORD
> > > --
> > > 2.26.0
> > >
>
Cheers,
Nathan
callchain ABI change with commit 6cbc304f2f360
Hi,
I have received reports from users who have noticed a change of
behaviour caused by
commit:
6cbc304f2f360 ("perf/x86/intel: Fix unwind errors from PEBS entries (mk-II)")
When using PEBS sampling on Intel processors.
Doing simple profiling with:
$ perf record -g -e cycles:pp ...
Before:
1 1595951041120856 0x7f77f8 [0xe8]: PERF_RECORD_SAMPLE(IP, 0x4002):
795385/690513: 0x558aa66a9607 period: 1019 addr: 0
... FP chain: nr:22
. 0: fe00
. 1: 558aa66a9607
. 2: 558aa66a8751
. 3: 558a984a3d4f
Entry 1: matches sampled IP 0x558aa66a9607.
After:
3 487420973381085 0x2f797c0 [0x90]: PERF_RECORD_SAMPLE(IP, 0x4002):
349591/146458: 0x559dcd2ef889 period: 1019 addr: 0
... FP chain: nr:11
. 0: fe00
. 1: 559dcd2ef88b
. 2: 559dcd19787d
. 3: 559dcd1cf1be
entry 1 does not match sampled IP anymore.
Before the patch the kernel was stashing the sampled IP from PEBS into
the callchain. After the patch it is stashing the interrupted IP, thus
with the skid.
I am trying to understand whether this is an intentional change or not
for the IP.
It seems that stashing the interrupted IP would be more consistent across all
sampling modes, i.e., with and without PEBS. Entry 1: would always be
the interrupted IP.
The changelog talks about ORC unwinder being more happy this the
interrupted machine
state, but not about the ABI expectation here.
Could you clarify?
Thanks.
Re: [PATCH v2] security: disable FORTIFY_SOURCE on clang
On Tue, May 5, 2020 at 8:54 PM Kees Cook wrote:
>
> On Tue, May 05, 2020 at 06:14:53PM -0600, Jason A. Donenfeld wrote:
> > clang-10 has a broken optimization stage that doesn't allow the
> > compiler to prove at compile time that certain memcpys are within
> > bounds, and thus the outline memcpy is always called, resulting in
> > horrific performance, and in some cases, excessive stack frame growth.
> > Here's a simple reproducer:
> >
> > typedef unsigned long size_t;
> > void *c(void *dest, const void *src, size_t n) __asm__("memcpy");
> > extern inline __attribute__((gnu_inline)) void *memcpy(void *dest,
> > const void *src, size_t n) { return c(dest, src, n); }
> > void blah(char *a)
> > {
> > unsigned long long b[10], c[10];
> > int i;
> >
> > memcpy(b, a, sizeof(b));
> > for (i = 0; i < 10; ++i)
> > c[i] = b[i] ^ b[9 - i];
> > for (i = 0; i < 10; ++i)
> > b[i] = c[i] ^ a[i];
> > memcpy(a, b, sizeof(b));
> > }
> >
> > Compile this with clang-9 and clang-10 and observe:
> >
> > zx2c4@thinkpad /tmp/curve25519-hacl64-stack-frame-size-test $ clang-10
> > -Wframe-larger-than=0 -O3 -c b.c -o c10.o
> > b.c:5:6: warning: stack frame size of 104 bytes in function 'blah'
> > [-Wframe-larger-than=]
> > void blah(char *a)
> > ^
> > 1 warning generated.
> > zx2c4@thinkpad /tmp/curve25519-hacl64-stack-frame-size-test $ clang-9
> > -Wframe-larger-than=0 -O3 -c b.c -o c9.o
> >
> > Looking at the disassembly of c10.o and c9.o, one can see that c9.o is
> > properly optimized in the obvious way one would expect, while c10.o has
> > blown up and includes extern calls to memcpy.
> >
> > But actually, for versions of clang earlier than 10, fortify source
> > mostly does nothing. So, between being broken and doing nothing, it
> > probably doesn't make sense to pretend to offer this option. So, this
> > commit just disables it entirely when compiling with clang.
> >
> > Cc: Arnd Bergmann
> > Cc: LKML
> > Cc: clang-built-linux
> > Cc: Kees Cook
> > Cc: George Burgess
> > Cc: Nick Desaulniers
> > Link: https://bugs.llvm.org/show_bug.cgi?id=45802
> > Signed-off-by: Jason A. Donenfeld
>
> Grudgingly,
>
> Reviewed-by: Kees Cook
Do you want to take this into your tree to send to Linus? Seems like
security kconfig switches is in line with your usual submissions.
Re: Intel KVM entry failed, hardware error 0x0
On Tue, May 05, 2020 at 08:00:15PM -0700, Sean Christopherson wrote:
> On Tue, May 05, 2020 at 10:32:15PM -0400, Qian Cai wrote:
> > Today’s linux-next started to fail with this config,
> >
> > https://raw.githubusercontent.com/cailca/linux-mm/master/kcsan.config
> >
> > qemu-kvm-2.12.0-99.module+el8.2.0+5827+8c39933c.x86_64
> >
> > I believe it was working yesterday. Before I bury myself bisecting it, does
> > anyone have any thought?
>
> It reproduces for me as well with my vanilla config in a VM. I can debug
> and/or bisect, should be quite quick in a VM.
>
> VM is bailing on the EPT Violation at the reset vector, i.e. on the very
> first exit. Presumably KVM is incorrectly setting vmx->fail somewhere.
The __FILL_RETURN_BUFFER in the VM-Exit path was recently modified and
changed how it clobbered EFLAGS, which causes KVM to think VM-Enter failed.
Commit 089dd8e53126 ("x86/speculation: Change FILL_RETURN_BUFFER to work
with objtool") introduced the change, but this is really a bug in KVM. The
VM-Exit path shouldn't rely on __FILL_RETURN_BUFFER to set EFLAGS to a
specific state, i.e. EFLAGS was always being clobbered, it just happened to
work before now.
I'll get a patch sent out shortly.
RE: [PATCH net-next 1/1] net: stmmac: Add option for VLAN filter fail queue enable
> -Original Message- > From: netdev-ow...@vger.kernel.org On > Behalf Of David Miller > Sent: Friday, April 24, 2020 6:53 AM > To: Wong, Vee Khee > Cc: peppe.cavall...@st.com; alexandre.tor...@st.com; > joab...@synopsys.com; mcoquelin.st...@gmail.com; > net...@vger.kernel.org; linux-st...@st-md-mailman.stormreply.com; > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Ong, > Boon Leong ; Voon, Weifeng > > Subject: Re: [PATCH net-next 1/1] net: stmmac: Add option for VLAN filter fail > queue enable > > From: Wong Vee Khee > Date: Thu, 23 Apr 2020 15:00:26 +0800 > > > From: "Chuah, Kim Tatt" > > > > Add option in plat_stmmacenet_data struct to enable VLAN Filter Fail > > Queuing. This option allows packets that fail VLAN filter to be routed > > to a specific Rx queue when Receive All is also set. > > > > When this option is enabled: > > - Enable VFFQ only when entering promiscuous mode, because Receive All > > will pass up all rx packets that failed address filtering (similar to > > promiscuous mode). > > - VLAN-promiscuous mode is never entered to allow rx packet to fail VLAN > > filters and get routed to selected VFFQ Rx queue. > > > > Reviewed-by: Voon Weifeng > > Reviewed-by: Ong Boon Leong > > Signed-off-by: Chuah, Kim Tatt > > Signed-off-by: Ong Boon Leong > > Why would you be setting this with a platform attribute? Even if the > capability exists, wouldn't you want the user to be able to choose to opt out? Hi Jose/David Miller, 1/ In current implementation, TSN uses VLAN filter that can either accept/reject VLAN-tagged network packets. In some situation, we do not want to drop failed packets, but instead steer the packet to a VLAN Failed Queue Channel. 2/ VLAN Fail Queue Channel will be set to use the RxQ with higheset index as per HW IP configuration because that is the least priority channel. 3/ The way user will enable this feature is through promiscuous mode settings using ifconfig. (e.g. ifconfig enp0s30f4 promisc) 4/ VLAN Filter Fail Packets Queue feature is IP version specific (only applicable to DWMAC5). I would propose we add this under platform data (e.g. dwmac-intel), so that it can be built in according to hardware on a separate patch. Any thoughts?
Re: [PATCH] securityfs: Add missing d_delete() call on removal
On Wed, May 06, 2020 at 02:14:31AM +0100, Al Viro wrote: > On Tue, May 05, 2020 at 04:40:35PM -0700, Kees Cook wrote: > > After using simple_unlink(), a call to d_delete() is needed in addition > > to dput(). > > > > Signed-off-by: Kees Cook > > --- > > Is this correct? I went looking around and there are a lot of variations > > on the simple_unlink() pattern... > > > > Many using explicit locking and combinations of d_drop(), __d_drop(), etc. > > Quite a few of those should switch to simple_recursive_removal(). As for > securityfs... d_drop() is _probably_ a saner variant, but looking at the > callers of that thing... at least IMA ones seem to be garbage. Hmm, I dunno. I hadn't looked at these yet. I'm not sure what's needed for those cases. Is my patch to add d_delete() correct, though? I'm trying to construct the right set of calls for pstore's filesystem, and I noticed that most will do simple_unlink(), d_delete(), dput(), but securityfs seemed to be missing it. -- Kees Cook
[PATCH] i2c: puv3: Fix an error handling path in 'puv3_i2c_probe()'
There is a spurious 'put_device()' in the remove function.
A reference to 'pdev->dev' is taken in the probe function without a
corresponding 'get_device()' to increment the refcounted reference.
Add the missing 'get_device()' and update the error handling path
accordingly.
Fixes: d10e4a660d11 ("unicore32 machine related files: add i2c bus drivers for
pkunity-v3 soc")
Signed-off-by: Christophe JAILLET
---
This patch is provided as-is. It is not even compile tested because I don't
use cross-compiler.
It is purely speculative and based on what looks like an unbalanced
'put_device()' in the remove function.
---
drivers/i2c/busses/i2c-puv3.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-puv3.c b/drivers/i2c/busses/i2c-puv3.c
index 5cec5a36807d..62a4b860d3c0 100644
--- a/drivers/i2c/busses/i2c-puv3.c
+++ b/drivers/i2c/busses/i2c-puv3.c
@@ -203,18 +203,20 @@ static int puv3_i2c_probe(struct platform_device *pdev)
mem->start);
adapter->algo = _i2c_algorithm;
adapter->class = I2C_CLASS_HWMON;
- adapter->dev.parent = >dev;
+ adapter->dev.parent = get_device(>dev);
platform_set_drvdata(pdev, adapter);
adapter->nr = pdev->id;
rc = i2c_add_numbered_adapter(adapter);
if (rc)
- goto fail_add_adapter;
+ goto fail_put_device;
dev_info(>dev, "PKUnity v3 i2c bus adapter.\n");
return 0;
+fail_put_device:
+ put_device(>dev);
fail_add_adapter:
kfree(adapter);
fail_nomem:
--
2.25.1
RE: [GIT PULL] vhost: fixes
Hi Michael > -Original Message- > From: Michael S. Tsirkin > Sent: Monday, May 4, 2020 8:16 PM > To: Linus Torvalds > Cc: k...@vger.kernel.org; virtualizat...@lists.linux-foundation.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; Justin He > ; ldi...@redhat.com; m...@redhat.com; n...@live.com; > stefa...@redhat.com > Subject: [GIT PULL] vhost: fixes > > The following changes since commit > 6a8b55ed4056ea5559ebe4f6a4b247f627870d4c: > > Linux 5.7-rc3 (2020-04-26 13:51:02 -0700) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus > > for you to fetch changes up to > 0b841030625cde5f784dd62aec72d6a766faae70: > > vhost: vsock: kick send_pkt worker once device is started (2020-05-02 > 10:28:21 -0400) > > > virtio: fixes > > A couple of bug fixes. > > Signed-off-by: Michael S. Tsirkin > > > Jia He (1): > vhost: vsock: kick send_pkt worker once device is started Should this fix also be CC-ed to stable? Sorry I forgot to cc it to stable. -- Cheers, Justin (Jia He) > > Stefan Hajnoczi (1): > virtio-blk: handle block_device_operations callbacks after hot unplug > > drivers/block/virtio_blk.c | 86 > +- > drivers/vhost/vsock.c | 5 +++ > 2 files changed, 83 insertions(+), 8 deletions(-) IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: [PATCH v2 2/4] PCI: cadence: Use "dma-ranges" instead of "cdns,no-bar-match-nbits" property
Hi Robin, On 5/4/2020 6:23 PM, Kishon Vijay Abraham I wrote: > Hi Robin, > > On 5/4/2020 4:24 PM, Robin Murphy wrote: >> On 2020-05-04 9:44 am, Kishon Vijay Abraham I wrote: >>> Hi Robin, >>> >>> On 5/1/2020 9:24 PM, Robin Murphy wrote: On 2020-05-01 3:46 pm, Lorenzo Pieralisi wrote: > [+Robin - to check on dma-ranges intepretation] > > I would need RobH and Robin to review this. > > Also, An ACK from Tom is required - for the whole series. > > On Fri, Apr 17, 2020 at 05:13:20PM +0530, Kishon Vijay Abraham I wrote: >> Cadence PCIe core driver (host mode) uses "cdns,no-bar-match-nbits" >> property to configure the number of bits passed through from PCIe >> address to internal address in Inbound Address Translation register. >> >> However standard PCI dt-binding already defines "dma-ranges" to >> describe the address range accessible by PCIe controller. Parse >> "dma-ranges" property to configure the number of bits passed >> through from PCIe address to internal address in Inbound Address >> Translation register. >> >> Signed-off-by: Kishon Vijay Abraham I >> --- >> drivers/pci/controller/cadence/pcie-cadence-host.c | 13 +++-- >> 1 file changed, 11 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c >> b/drivers/pci/controller/cadence/pcie-cadence-host.c >> index 9b1c3966414b..60f912a657b9 100644 >> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c >> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c >> @@ -206,8 +206,10 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc) >> struct device *dev = rc->pcie.dev; >> struct platform_device *pdev = to_platform_device(dev); >> struct device_node *np = dev->of_node; >> + struct of_pci_range_parser parser; >> struct pci_host_bridge *bridge; >> struct list_head resources; >> + struct of_pci_range range; >> struct cdns_pcie *pcie; >> struct resource *res; >> int ret; >> @@ -222,8 +224,15 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc) >> rc->max_regions = 32; >> of_property_read_u32(np, "cdns,max-outbound-regions", >> >max_regions); >> - rc->no_bar_nbits = 32; >> - of_property_read_u32(np, "cdns,no-bar-match-nbits", >> >no_bar_nbits); >> + if (!of_pci_dma_range_parser_init(, np)) >> + if (of_pci_range_parser_one(, )) >> + rc->no_bar_nbits = ilog2(range.size); You probably want "range.pci_addr + range.size" here just in case the bottom of the window is ever non-zero. Is there definitely only ever a single inbound window to consider? >>> >>> Cadence IP has 3 inbound address translation registers, however we use only >>> 1 >>> inbound address translation register to map the entire 32 bit or 64 bit >>> address >>> region. >> >> OK, if anything that further strengthens the argument for deprecating a >> single >> "number of bits" property in favour of ranges that accurately describe the >> window(s). However it also suggests that other users in future might have >> some >> expectation that specifying "dma-ranges" with up to 3 entries should work to >> allow a more restrictive inbound configuration. Thus it would be desirable to >> make the code a little more robust here - even if we don't support multiple >> windows straight off, it would still be better to implement it in a way that >> can be cleanly extended later, and at least say something if more ranges are >> specified rather than just silently ignoring them. > > I looked at this further in the Cadence user doc. The three inbound ATU > entries > are for BAR0, BAR1 in RC configuration space and the third one is for NO MATCH > BAR when there is no matching found in RC BARs. Right now we always configure > the NO MATCH BAR. Would it be possible describe at BAR granularity in > dma-ranges? I was thinking if I could use something like dma-ranges = <0x0200 0x0 0x0 0x0 0x0 0x0 0x0>, //For BAR0 IB mapping <0x0200 0x0 0x0 0x0 0x0 0x0 0x0>, //For BAR1 IB mapping <0x0200 0x0 0x0 0x0 0x0 0x1 0x0>; //NO MATCH BAR This way the driver can tell the 1st tuple is for BAR0, 2nd is for BAR1 and last is for NO MATCH. In the above case both BAR0 and BAR1 is just empty and doesn't have valid values as we use only the NO MATCH BAR. However I'm not able to use for_each_of_pci_range() in Cadence driver to get the configuration for each BAR, since the for loop gets invoked only once since of_pci_range_parser_one() merges contiguous addresses. Do you think I should extend the flags cell to differentiate between BAR0, BAR1 and NO MATCH BAR? Can you suggest any other alternatives? Thanks Kishon >> I believe that pci_parse_request_of_pci_ranges() could do the actual
[PATCH -next] soundwire: qcom: Use IRQF_ONESHOT
Fixes coccicheck error:
drivers/soundwire/qcom.c:815:7-32: ERROR: Threaded IRQ with
no primary handler requested without IRQF_ONESHOT
Reported-by: Hulk Robot
Signed-off-by: Samuel Zou
---
drivers/soundwire/qcom.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
index e08a17c..a2a35f7 100644
--- a/drivers/soundwire/qcom.c
+++ b/drivers/soundwire/qcom.c
@@ -814,7 +814,8 @@ static int qcom_swrm_probe(struct platform_device *pdev)
ret = devm_request_threaded_irq(dev, ctrl->irq, NULL,
qcom_swrm_irq_handler,
- IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_RISING |
+ IRQF_ONESHOT,
"soundwire", ctrl);
if (ret) {
dev_err(dev, "Failed to request soundwire irq\n");
--
2.6.2
Re: [PATCH -next] iwlwifi: pcie: Use bitwise instead of arithmetic operator for flags
On Wed, 2020-05-06 at 11:07 +0800, Samuel Zou wrote: > This silences the following coccinelle warning: > > "WARNING: sum of probable bitmasks, consider |" I suggest instead ignoring bad and irrelevant warnings. PREFIX_LEN is 32 not 0x20 or BIT(5) PCI_DUMP_SIZE is 352 > diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c > b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c [] > @@ -109,9 +109,9 @@ void iwl_trans_pcie_dump_regs(struct iwl_trans *trans) > > /* Alloc a max size buffer */ > alloc_size = PCI_ERR_ROOT_ERR_SRC + 4 + PREFIX_LEN; > - alloc_size = max_t(u32, alloc_size, PCI_DUMP_SIZE + PREFIX_LEN); > - alloc_size = max_t(u32, alloc_size, PCI_MEM_DUMP_SIZE + PREFIX_LEN); > - alloc_size = max_t(u32, alloc_size, PCI_PARENT_DUMP_SIZE + PREFIX_LEN); > + alloc_size = max_t(u32, alloc_size, PCI_DUMP_SIZE | PREFIX_LEN); > + alloc_size = max_t(u32, alloc_size, PCI_MEM_DUMP_SIZE | PREFIX_LEN); > + alloc_size = max_t(u32, alloc_size, PCI_PARENT_DUMP_SIZE | PREFIX_LEN); > > buf = kmalloc(alloc_size, GFP_ATOMIC); > if (!buf)
Re: WARNING: proc registration bug in snmp6_register_dev
syzbot has found a reproducer for the following crash on: HEAD commit:ac935d22 Add linux-next specific files for 20200415 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=17006f4c10 kernel config: https://syzkaller.appspot.com/x/.config?x=bc498783097e9019 dashboard link: https://syzkaller.appspot.com/bug?extid=1d51c8b74efa4c44adeb compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=148e615010 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=115c379c10 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1d51c8b74efa4c44a...@syzkaller.appspotmail.com [ cut here ] proc_dir_entry 'dev_snmp6/hsr1' already registered WARNING: CPU: 0 PID: 7289 at fs/proc/generic.c:362 proc_register+0x40b/0x580 fs/proc/generic.c:362 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 7289 Comm: syz-executor779 Not tainted 5.7.0-rc1-next-20200415-syzkaller #0 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+0x188/0x20d lib/dump_stack.c:118 panic+0x2e3/0x75c kernel/panic.c:221 __warn.cold+0x2f/0x35 kernel/panic.c:582 report_bug+0x27b/0x2f0 lib/bug.c:195 fixup_bug arch/x86/kernel/traps.c:175 [inline] fixup_bug arch/x86/kernel/traps.c:170 [inline] do_error_trap+0x12b/0x220 arch/x86/kernel/traps.c:267 do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:286 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027 RIP: 0010:proc_register+0x40b/0x580 fs/proc/generic.c:362 Code: ff df 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 5c 01 00 00 48 8b 04 24 48 c7 c7 a0 7a 39 88 48 8b b0 d8 00 00 00 e8 4d 2d 61 ff <0f> 0b 48 c7 c7 a0 ac ac 89 e8 f7 5b f3 05 48 8b 4c 24 28 48 b8 00 RSP: 0018:c90005956cc8 EFLAGS: 00010282 RAX: RBX: 8880a9138ac8 RCX: RDX: RSI: 815ce211 RDI: f52000b2ad8b RBP: 8880a1ab3a80 R08: 888087c40340 R09: ed1015cc66b1 R10: 8880ae633587 R11: ed1015cc66b0 R12: R13: dc00 R14: 8880a6561240 R15: 0004 proc_create_single_data+0xdb/0x130 fs/proc/generic.c:631 snmp6_register_dev+0xbe/0x140 net/ipv6/proc.c:254 ipv6_add_dev net/ipv6/addrconf.c:408 [inline] ipv6_add_dev+0x54b/0x10b0 net/ipv6/addrconf.c:365 addrconf_notify+0x960/0x2310 net/ipv6/addrconf.c:3503 notifier_call_chain+0xc0/0x230 kernel/notifier.c:83 call_netdevice_notifiers_info net/core/dev.c:1948 [inline] call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1933 call_netdevice_notifiers_extack net/core/dev.c:1960 [inline] call_netdevice_notifiers net/core/dev.c:1974 [inline] register_netdevice+0xd70/0x10b0 net/core/dev.c:9423 hsr_dev_finalize+0x516/0x746 net/hsr/hsr_device.c:486 hsr_newlink+0x27c/0x520 net/hsr/hsr_netlink.c:83 __rtnl_newlink+0xf18/0x1590 net/core/rtnetlink.c: rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3391 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5454 netlink_rcv_skb+0x15a/0x410 net/netlink/af_netlink.c:2469 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] netlink_unicast+0x537/0x740 net/netlink/af_netlink.c:1329 netlink_sendmsg+0x882/0xe10 net/netlink/af_netlink.c:1918 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x6bf/0x7e0 net/socket.c:2362 ___sys_sendmsg+0x100/0x170 net/socket.c:2416 __sys_sendmsg+0xec/0x1b0 net/socket.c:2449 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x449409 Code: e8 cc 14 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 9b 0c fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fa3c088fdb8 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 006dfca8 RCX: 00449409 RDX: RSI: 2040 RDI: 000e RBP: 006dfca0 R08: 0014 R09: R10: 0001 R11: 0246 R12: 006dfcac R13: 7ffc318e2f1f R14: 7fa3c08909c0 R15: 006dfcac Kernel Offset: disabled Rebooting in 86400 seconds..
[PATCH -next] iwlwifi: pcie: Use bitwise instead of arithmetic operator for flags
This silences the following coccinelle warning: "WARNING: sum of probable bitmasks, consider |" Reported-by: Hulk Robot Signed-off-by: Samuel Zou --- drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c index a0daae0..6d9bf9f 100644 --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c @@ -109,9 +109,9 @@ void iwl_trans_pcie_dump_regs(struct iwl_trans *trans) /* Alloc a max size buffer */ alloc_size = PCI_ERR_ROOT_ERR_SRC + 4 + PREFIX_LEN; - alloc_size = max_t(u32, alloc_size, PCI_DUMP_SIZE + PREFIX_LEN); - alloc_size = max_t(u32, alloc_size, PCI_MEM_DUMP_SIZE + PREFIX_LEN); - alloc_size = max_t(u32, alloc_size, PCI_PARENT_DUMP_SIZE + PREFIX_LEN); + alloc_size = max_t(u32, alloc_size, PCI_DUMP_SIZE | PREFIX_LEN); + alloc_size = max_t(u32, alloc_size, PCI_MEM_DUMP_SIZE | PREFIX_LEN); + alloc_size = max_t(u32, alloc_size, PCI_PARENT_DUMP_SIZE | PREFIX_LEN); buf = kmalloc(alloc_size, GFP_ATOMIC); if (!buf) -- 2.6.2
Re: Intel KVM entry failed, hardware error 0x0
On Tue, May 05, 2020 at 10:32:15PM -0400, Qian Cai wrote: > Today’s linux-next started to fail with this config, > > https://raw.githubusercontent.com/cailca/linux-mm/master/kcsan.config > > qemu-kvm-2.12.0-99.module+el8.2.0+5827+8c39933c.x86_64 > > I believe it was working yesterday. Before I bury myself bisecting it, does > anyone have any thought? It reproduces for me as well with my vanilla config in a VM. I can debug and/or bisect, should be quite quick in a VM. VM is bailing on the EPT Violation at the reset vector, i.e. on the very first exit. Presumably KVM is incorrectly setting vmx->fail somewhere. > # /usr/libexec/qemu-kvm -name ubuntu-18.04-server-cloudimg -cpu host -smp 2 > -m 2G -hda ubuntu-18.04-server-cloudimg.qcow2 -cdrom > ubuntu-18.04-server-cloudimg.iso -nic user,hostfwd=tcp::-:22 -nographic > > KVM: entry failed, hardware error 0x0 > EAX= EBX= ECX= EDX=000306f2 > ESI= EDI= EBP= ESP= > EIP=fff0 EFL=00010002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES = 9300 > CS =f000 9b00 > SS = 9300 > DS = 9300 > FS = 9300 > GS = 9300 > LDT= 8200 > TR = 8b00 > GDT= > IDT= > CR0=6010 CR2= CR3= CR4= > DR0= DR1= DR2= > DR3= > DR6=0ff0 DR7=0400 > EFER= > > [28040.962363][T78789] *** Guest State *** > [28040.981990][T78789] CR0: actual=0x0030, > shadow=0x6010, gh_mask=fff7 > [28041.030248][T78789] CR4: actual=0x2040, > shadow=0x, gh_mask=e871 > [28041.075900][T78789] CR3 = 0x > [28041.096369][T78789] RSP = 0x RIP = 0xfff0 > [28041.127519][T78789] RFLAGS=0x00010002 DR7 = 0x0400 > [28041.158730][T78789] Sysenter RSP= > CS:RIP=: > [28041.193409][T78789] CS: sel=0xf000, attr=0x0009b, limit=0x, > base=0x > [28041.234135][T78789] DS: sel=0x, attr=0x00093, limit=0x, > base=0x > [28041.274796][T78789] SS: sel=0x, attr=0x00093, limit=0x, > base=0x > [28041.315631][T78789] ES: sel=0x, attr=0x00093, limit=0x, > base=0x > [28041.357025][T78789] FS: sel=0x, attr=0x00093, limit=0x, > base=0x > [28041.397808][T78789] GS: sel=0x, attr=0x00093, limit=0x, > base=0x > [28041.438806][T78789] GDTR: limit=0x, > base=0x > [28041.479557][T78789] LDTR: sel=0x, attr=0x00082, limit=0x, > base=0x > [28041.522599][T78789] IDTR: limit=0x, > base=0x > [28041.564289][T78789] TR: sel=0x, attr=0x0008b, limit=0x, > base=0x > [28041.604705][T78789] EFER = 0x PAT = 0x0007040600070406 > [28041.638146][T78789] DebugCtl = 0x DebugExceptions = > 0x > [28041.676235][T78789] Interruptibility = ActivityState = > [28041.709019][T78789] InterruptStatus = > [28041.728432][T78789] *** Host State *** > [28041.746774][T78789] RIP = 0xc05ab620 RSP = 0xb24ec6c9fb08 > [28041.777531][T78789] CS=0010 SS=0018 DS= ES= FS= GS= TR=0040 > [28041.811313][T78789] FSBase=7f697700 GSBase=8d799f98 > TRBase=fe1e > [28041.851017][T78789] GDTBase=fe1de000 IDTBase=fe00 > [28041.881294][T78789] CR0=80050033 CR3=0008802c8003 > CR4=001626e0 > [28041.917895][T78789] Sysenter RSP= > CS:RIP=: > [28041.953737][T78789] EFER = 0x0d01 PAT = 0x0007040600070406 > [28041.986043][T78789] *** Control State *** > [28042.006510][T78789] PinBased=00ff CPUBased=b5a06dfa > SecondaryExec=37eb > [28042.043823][T78789] EntryControls=d1ff ExitControls=002befff > [28042.074416][T78789] ExceptionBitmap=00060042 PFECmask= > PFECmatch= > [28042.110314][T78789] VMEntry: intr_info= errcode= > ilen= > [28042.144970][T78789] VMExit: intr_info= errcode= > ilen=0003 > [28042.178829][T78789] reason=0030 qualification=0184 > [28042.211619][T78789] IDTVectoring: info= errcode= > [28042.240511][T78789] TSC Offset = 0xbe0284927b21 > [28042.264284][T78789] SVI|RVI = 00|00 TPR Threshold = 0x00 > [28042.289414][T78789] APIC-access addr = 0x000e5dfc virt-APIC addr = > 0x000d2e76c000 >
Re: [PATCH] net: bareudp: avoid uninitialized variable warning
On Tue, May 05, 2020 at 07:22:14PM +0200, Arnd Bergmann wrote:
> clang points out that building without IPv6 would lead to returning
> an uninitialized variable if a packet with family!=AF_INET is
> passed into bareudp_udp_encap_recv():
>
> drivers/net/bareudp.c:139:6: error: variable 'err' is used uninitialized
> whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
> if (family == AF_INET)
> ^
> drivers/net/bareudp.c:146:15: note: uninitialized use occurs here
> if (unlikely(err)) {
> ^~~
> include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
> # define unlikely(x)__builtin_expect(!!(x), 0)
> ^
> drivers/net/bareudp.c:139:2: note: remove the 'if' if its condition is always
> true
> if (family == AF_INET)
> ^~
>
> This cannot happen in practice, so change the condition in a way that
> gcc sees the IPv4 case as unconditionally true here.
> For consistency, change all the similar constructs in this file the
> same way, using "if(IS_ENABLED())" instead of #if IS_ENABLED()".
>
> Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling
> different protocols like MPLS, IP, NSH etc.")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Nathan Chancellor
> ---
> drivers/net/bareudp.c| 18 --
> include/net/udp_tunnel.h | 2 --
> 2 files changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/bareudp.c b/drivers/net/bareudp.c
> index cc0703c3d57f..efd1a1d1f35e 100644
> --- a/drivers/net/bareudp.c
> +++ b/drivers/net/bareudp.c
> @@ -136,25 +136,21 @@ static int bareudp_udp_encap_recv(struct sock *sk,
> struct sk_buff *skb)
> oiph = skb_network_header(skb);
> skb_reset_network_header(skb);
>
> - if (family == AF_INET)
> + if (!IS_ENABLED(CONFIG_IPV6) || family == AF_INET)
> err = IP_ECN_decapsulate(oiph, skb);
> -#if IS_ENABLED(CONFIG_IPV6)
> else
> err = IP6_ECN_decapsulate(oiph, skb);
> -#endif
>
> if (unlikely(err)) {
> if (log_ecn_error) {
> - if (family == AF_INET)
> + if (!IS_ENABLED(CONFIG_IPV6) || family == AF_INET)
> net_info_ratelimited("non-ECT from %pI4 "
>"with TOS=%#x\n",
>&((struct iphdr
> *)oiph)->saddr,
>((struct iphdr
> *)oiph)->tos);
> -#if IS_ENABLED(CONFIG_IPV6)
> else
> net_info_ratelimited("non-ECT from %pI6\n",
>&((struct ipv6hdr
> *)oiph)->saddr);
> -#endif
> }
> if (err > 1) {
> ++bareudp->dev->stats.rx_frame_errors;
> @@ -350,7 +346,6 @@ static int bareudp_xmit_skb(struct sk_buff *skb, struct
> net_device *dev,
> return err;
> }
>
> -#if IS_ENABLED(CONFIG_IPV6)
> static int bareudp6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
>struct bareudp_dev *bareudp,
>const struct ip_tunnel_info *info)
> @@ -411,7 +406,6 @@ static int bareudp6_xmit_skb(struct sk_buff *skb, struct
> net_device *dev,
> dst_release(dst);
> return err;
> }
> -#endif
>
> static netdev_tx_t bareudp_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> @@ -435,11 +429,9 @@ static netdev_tx_t bareudp_xmit(struct sk_buff *skb,
> struct net_device *dev)
> }
>
> rcu_read_lock();
> -#if IS_ENABLED(CONFIG_IPV6)
> - if (info->mode & IP_TUNNEL_INFO_IPV6)
> + if (IS_ENABLED(CONFIG_IPV6) && info->mode & IP_TUNNEL_INFO_IPV6)
> err = bareudp6_xmit_skb(skb, dev, bareudp, info);
> else
> -#endif
> err = bareudp_xmit_skb(skb, dev, bareudp, info);
>
> rcu_read_unlock();
> @@ -467,7 +459,7 @@ static int bareudp_fill_metadata_dst(struct net_device
> *dev,
>
> use_cache = ip_tunnel_dst_cache_usable(skb, info);
>
> - if (ip_tunnel_info_af(info) == AF_INET) {
> + if (!IS_ENABLED(CONFIG_IPV6) || ip_tunnel_info_af(info) == AF_INET) {
> struct rtable *rt;
> __be32 saddr;
>
> @@ -478,7 +470,6 @@ static int bareudp_fill_metadata_dst(struct net_device
> *dev,
>
> ip_rt_put(rt);
> info->key.u.ipv4.src = saddr;
> -#if IS_ENABLED(CONFIG_IPV6)
> } else if (ip_tunnel_info_af(info) == AF_INET6) {
> struct dst_entry *dst;
> struct in6_addr saddr;
> @@ -492,7 +483,6 @@ static int bareudp_fill_metadata_dst(struct net_device
> *dev,
>
> dst_release(dst);
> info->key.u.ipv6.src = saddr;
> -#endif
> } else {
> return -EINVAL;
> }
> diff --git
Re: [PATCH v7 2/2] tty: add rpmsg driver
On Wed 25 Mar 09:57 PDT 2020, Arnaud POULIQUEN wrote:
> Hi Bjorn,
>
> On 3/24/20 9:52 PM, Bjorn Andersson wrote:
> > On Tue 24 Mar 10:04 PDT 2020, Arnaud Pouliquen wrote:
> > [..]
> >> diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
> >> index 020b1cd9294f..c2465e7ebc2a 100644
> >> --- a/drivers/tty/Makefile
> >> +++ b/drivers/tty/Makefile
> >> @@ -34,5 +34,6 @@ obj-$(CONFIG_PPC_EPAPR_HV_BYTECHAN) += ehv_bytechan.o
> >> obj-$(CONFIG_GOLDFISH_TTY)+= goldfish.o
> >> obj-$(CONFIG_MIPS_EJTAG_FDC_TTY) += mips_ejtag_fdc.o
> >> obj-$(CONFIG_VCC) += vcc.o
> >> +obj-$(CONFIG_RPMSG_TTY) += rpmsg_tty.o
> >>
> >> obj-y += ipwireless/
> >> diff --git a/drivers/tty/rpmsg_tty.c b/drivers/tty/rpmsg_tty.c
> > [..]
> >> +static struct rpmsg_device_id rpmsg_driver_tty_id_table[] = {
> >> + { .name = TTY_CH_NAME_RAW },
> >> + { .name = TTY_CH_NAME_WITH_CTS},
> >
> > I still don't like the idea that the tty devices are tied to channels by
> > fixed names.
>
> This point has been discussed with Xiang, he has the same kind of
> requirement.
> My proposal here is to do this in two steps. First a fixed name, then
> in a second step we can extend the naming using the implementation proposed
> by Mathieu Poirier:
>
> [1]https://lkml.org/lkml/2020/2/12/1083
>
> Is this patch could answer to your requirement?
>
> if requested i can I can integrate the Mathieu's patch in this patchset.
>
> >
> > This makes the driver unusable for communicating with any firmware out
> > there that provides tty-like data over a channel with a different name -
> > such as modems with channels providing an AT command interface (they are
> > not named "rpmsg-tty-raw").
>
> I'm not fixed on the naming, any proposal is welcome.
> If we use the patch [1], could be renamed
> "rpmsg-tty". then for AT command could be something like "rpmsg-tty-at"
>
> But here seems we are speaking about service over TTY and not over RPMsg.
>
> >
> > I also fail to see how you would distinguish ttys when the firmware
> > provides more than a single tty - e.g. say you have a modem-like device
> > that provides an AT command channel and a NMEA stream.
>
> Today it is a limitation. In fact this limitation is the same for all RPMsg
> devices with multi instance.
> The patch [1] will allow to retrieve the instance by identifying
> the service device name in /sys/class/tty/ttyRPMSG/device/name
>
> >
> >
> > These are the reasons why drivers/rpmsg/rpmsg_char registers a "control
> > device", from which you can spawn new char devices. As I've said before,
> > I really think the same approach should be taken for ttys - perhaps by
> > just extending the rpmsg_char to allow it to create tty devices in
> > addition to the "packet based" char device?
> >
> I'm not very familiar with the rpmsg_char so please correct me if i'm wrong:
>
> The rpmsg_char exposes to userland an interface to manage rpmsg channels
> (relying on a char device). This interface offers the possibility to create
> new channels/endpoints and send/received related messages.
>
> Thus, the application declares the RPMsg channels which is bound if they
> matches
> with the remote processor channel (similar behavior than a kernel rpmsg
> driver).
> There is no constrain on the service once same service is advertised by remote
> firmware.
>
> In addition, a limitation of the rpmsg_char device is that it needs to be
> associated with an existing device, as example the implementation in qcom_smd
> driver.
>
Correct, the rpmsg_char control device must be associated with a
transport instance, e.g. a virtio rpmsg instance sitting on a
remoteproc. This is necessary in order to be able to tie the dynamically
created rpmsg_char endpoints (i.e. the thing that is similar to your tty
devices) to a particular transport/remoteproc..
The reason why qcom_smd needs to be involved is because of the problem
that I want the control device to appear without depending on particular
channels being exposed by the firmware.
> If i try to figure out how to implement TTY using the rpmsg_char:
> I should create a rpmsg_char dev in the rpmsg tty driver. Then application
> will create channels related to its service. But in this case
> how to ensure that channels created are related to the TTY service?
>
My proposal/wish is that 1) rpmsg_char is implemented for virtio/rpmsg,
so that the control device is registered as virtio rpmsg is initiated
and 2) that rpmsg_char is extended to allow creating tty devices in
addition to the existing interface (if the existing read/write interface
isn't enough).
>
> I would also expect to manage RPMsg TTY such as a generic TTY: without
> extra interface and auto mounted as an USB TTY. this means that the
> /dev/ttyRMPSGx are created automatically at remote firmware startup
> (without any application action). For instance a generic application
> (e.g. minicom) could control an internal remote processor such as
> an external processor
Re: [PATCH v2] security: disable FORTIFY_SOURCE on clang
On Tue, May 05, 2020 at 06:14:53PM -0600, Jason A. Donenfeld wrote:
> clang-10 has a broken optimization stage that doesn't allow the
> compiler to prove at compile time that certain memcpys are within
> bounds, and thus the outline memcpy is always called, resulting in
> horrific performance, and in some cases, excessive stack frame growth.
> Here's a simple reproducer:
>
> typedef unsigned long size_t;
> void *c(void *dest, const void *src, size_t n) __asm__("memcpy");
> extern inline __attribute__((gnu_inline)) void *memcpy(void *dest, const
> void *src, size_t n) { return c(dest, src, n); }
> void blah(char *a)
> {
> unsigned long long b[10], c[10];
> int i;
>
> memcpy(b, a, sizeof(b));
> for (i = 0; i < 10; ++i)
> c[i] = b[i] ^ b[9 - i];
> for (i = 0; i < 10; ++i)
> b[i] = c[i] ^ a[i];
> memcpy(a, b, sizeof(b));
> }
>
> Compile this with clang-9 and clang-10 and observe:
>
> zx2c4@thinkpad /tmp/curve25519-hacl64-stack-frame-size-test $ clang-10
> -Wframe-larger-than=0 -O3 -c b.c -o c10.o
> b.c:5:6: warning: stack frame size of 104 bytes in function 'blah'
> [-Wframe-larger-than=]
> void blah(char *a)
> ^
> 1 warning generated.
> zx2c4@thinkpad /tmp/curve25519-hacl64-stack-frame-size-test $ clang-9
> -Wframe-larger-than=0 -O3 -c b.c -o c9.o
>
> Looking at the disassembly of c10.o and c9.o, one can see that c9.o is
> properly optimized in the obvious way one would expect, while c10.o has
> blown up and includes extern calls to memcpy.
>
> But actually, for versions of clang earlier than 10, fortify source
> mostly does nothing. So, between being broken and doing nothing, it
> probably doesn't make sense to pretend to offer this option. So, this
> commit just disables it entirely when compiling with clang.
>
> Cc: Arnd Bergmann
> Cc: LKML
> Cc: clang-built-linux
> Cc: Kees Cook
> Cc: George Burgess
> Cc: Nick Desaulniers
> Link: https://bugs.llvm.org/show_bug.cgi?id=45802
> Signed-off-by: Jason A. Donenfeld
Grudgingly,
Reviewed-by: Kees Cook
--
Kees Cook
Re: [PATCH] Kbuild: disable FORTIFY_SOURCE on clang-10
On Tue, May 05, 2020 at 04:36:49PM -0700, Nick Desaulniers wrote: > On Tue, May 5, 2020 at 4:22 PM Jason A. Donenfeld wrote: > > > > On Tue, May 5, 2020 at 5:19 PM Kees Cook wrote: > > > > > > (Though as was mentioned, it's likely that FORTIFY_SOURCE isn't working > > > _at all_ under Clang, so I may still send a patch to depend on !clang > > > just to avoid surprises until it's fixed, but I haven't had time to > > > chase down a solution yet.) > > Not good. If it's completely broken, turn it off, and we'll prioritize > fixing. The problem is what George mentioned: it's unclear how broken it is -- it may not be all uses. I haven't had time to finish the testing for it, but it's on the TODO list. :) -- Kees Cook
Re: [PATCH v5 1/5] powerpc: Move idle_loop_prolog()/epilog() functions to header file
On Tue, 2020-04-07 at 08:47:39 UTC, "Gautham R. Shenoy" wrote: > From: "Gautham R. Shenoy" > > Currently prior to entering an idle state on a Linux Guest, the > pseries cpuidle driver implement an idle_loop_prolog() and > idle_loop_epilog() functions which ensure that idle_purr is correctly > computed, and the hypervisor is informed that the CPU cycles have been > donated. > > These prolog and epilog functions are also required in the default > idle call, i.e pseries_lpar_idle(). Hence move these accessor > functions to a common header file and call them from > pseries_lpar_idle(). Since the existing header files such as > asm/processor.h have enough clutter, create a new header file > asm/idle.h. Finally rename idle_loop_prolog() and idle_loop_epilog() > to pseries_idle_prolog() and pseries_idle_epilog() as they are only > relavent for on pseries guests. > > Signed-off-by: Gautham R. Shenoy Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/e4a884cc28fa3f5d8b81de46998ffe29b4ad169e cheers
Re: [PATCH] powerpc/ps3: Move static keyword to the front of declaration
On Wed, 2020-04-29 at 10:00:48 UTC, Xiongfeng Wang wrote: > Move the static keyword to the front of declaration of 'vuart_bus_priv', > and resolve the following compiler warning that can be seen when > building with warnings enabled (W=1): > > drivers/ps3/ps3-vuart.c:867:1: warning: âstaticâ is not at beginning of > declaration [-Wold-style-declaration] > } static vuart_bus_priv; > ^ > > Reported-by: Hulk Robot > Signed-off-by: Xiongfeng Wang Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/43c8a496fa37187b54f7df71fb8262acc6bf6200 cheers
[PATCH -next] net: ethernet: ti: Use PTR_ERR_OR_ZERO() to simplify code
Fixes coccicheck warning:
drivers/net/ethernet/ti/am65-cpts.c:1017:1-3: WARNING: PTR_ERR_OR_ZERO can be
used
Reported-by: Hulk Robot
Signed-off-by: Samuel Zou
---
drivers/net/ethernet/ti/am65-cpts.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/am65-cpts.c
b/drivers/net/ethernet/ti/am65-cpts.c
index 370162c..51c94b2 100644
--- a/drivers/net/ethernet/ti/am65-cpts.c
+++ b/drivers/net/ethernet/ti/am65-cpts.c
@@ -1014,10 +1014,7 @@ static int am65_cpts_probe(struct platform_device *pdev)
return PTR_ERR(base);
cpts = am65_cpts_create(dev, base, node);
- if (IS_ERR(cpts))
- return PTR_ERR(cpts);
-
- return 0;
+ return PTR_ERR_OR_ZERO(cpts);
}
static const struct of_device_id am65_cpts_of_match[] = {
--
2.6.2
Re: [PATCH] leds: lm355x: avoid enum conversion warning
On Tue, May 05, 2020 at 04:19:17PM +0200, Arnd Bergmann wrote:
> clang points out that doing arithmetic between diffent enums is usually
^ different
> a mistake:
>
> drivers/leds/leds-lm355x.c:167:28: warning: bitwise operation between
> different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc')
> [-Wenum-enum-conversion]
> reg_val = pdata->pin_tx2 | pdata->ntc_pin;
> ~~ ^ ~~
> drivers/leds/leds-lm355x.c:178:28: warning: bitwise operation between
> different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc')
> [-Wenum-enum-conversion]
> reg_val = pdata->pin_tx2 | pdata->ntc_pin | pdata->pass_mode;
> ~~ ^ ~~
>
> In this driver, it is intentional, so add a cast to hide the false-positive
Not sure that I would call this a false positive. The warning is correct
that there is a bitwise operation between different enumeration types
but we do not care since we are just using the enumerated type for its
integer value in lieu of a #define VAR value.
> warning. It appears to be the only instance of this warning at the moment.
>
> Fixes: b98d13c72592 ("leds: Add new LED driver for lm355x chips")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/leds/leds-lm355x.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/leds/leds-lm355x.c b/drivers/leds/leds-lm355x.c
> index 11ce05249751..b2eb2e1e9c04 100644
> --- a/drivers/leds/leds-lm355x.c
> +++ b/drivers/leds/leds-lm355x.c
> @@ -164,18 +164,19 @@ static int lm355x_chip_init(struct lm355x_chip_data
> *chip)
> /* input and output pins configuration */
> switch (chip->type) {
> case CHIP_LM3554:
> - reg_val = pdata->pin_tx2 | pdata->ntc_pin;
> + reg_val = (u32)pdata->pin_tx2 | (u32)pdata->ntc_pin;
> ret = regmap_update_bits(chip->regmap, 0xE0, 0x28, reg_val);
> if (ret < 0)
> goto out;
> - reg_val = pdata->pass_mode;
> + reg_val = (u32)pdata->pass_mode;
Is this cast needed? I don't think there should be warning from going
from an enumerated type to unsigned int.
> ret = regmap_update_bits(chip->regmap, 0xA0, 0x04, reg_val);
> if (ret < 0)
> goto out;
> break;
>
> case CHIP_LM3556:
> - reg_val = pdata->pin_tx2 | pdata->ntc_pin | pdata->pass_mode;
> + reg_val = (u32)pdata->pin_tx2 | (u32)pdata->ntc_pin |
> + (u32)pdata->pass_mode;
> ret = regmap_update_bits(chip->regmap, 0x0A, 0xC4, reg_val);
> if (ret < 0)
> goto out;
> --
> 2.26.0
>
With those comments addressed, feel free to add:
Reviewed-by: Nathan Chancellor
Re: [PATCH] mtd: lpddr: fix excessive stack usage with clang
On Tue, May 05, 2020 at 04:01:16PM +0200, Arnd Bergmann wrote:
> Building lpddr2_nvm with clang can result in a giant stack usage
> in one function:
>
> drivers/mtd/lpddr/lpddr2_nvm.c:399:12: error: stack frame size of 1144 bytes
> in function 'lpddr2_nvm_probe' [-Werror,-Wframe-larger-than=]
>
> The problem is that clang decides to build a copy of the mtd_info
> structure on the stack and then do a memcpy() into the actual version. It
> shouldn't really do it that way, but it's not strictly a bug either.
>
> As a workaround, use a static const version of the structure to assign
> most of the members upfront and then only set the few members that
> require runtime knowledge at probe time.
>
> Fixes: 96ba9dd65788 ("mtd: lpddr: add driver for LPDDR2-NVM PCM memories")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Nathan Chancellor
> ---
> drivers/mtd/lpddr/lpddr2_nvm.c | 35 ++
> 1 file changed, 19 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mtd/lpddr/lpddr2_nvm.c b/drivers/mtd/lpddr/lpddr2_nvm.c
> index 0f1547f09d08..72f5c7b30079 100644
> --- a/drivers/mtd/lpddr/lpddr2_nvm.c
> +++ b/drivers/mtd/lpddr/lpddr2_nvm.c
> @@ -393,6 +393,17 @@ static int lpddr2_nvm_lock(struct mtd_info *mtd, loff_t
> start_add,
> return lpddr2_nvm_do_block_op(mtd, start_add, len, LPDDR2_NVM_LOCK);
> }
>
> +static const struct mtd_info lpddr2_nvm_mtd_info = {
> + .type = MTD_RAM,
> + .writesize = 1,
> + .flags = (MTD_CAP_NVRAM | MTD_POWERUP_LOCK),
> + ._read = lpddr2_nvm_read,
> + ._write = lpddr2_nvm_write,
> + ._erase = lpddr2_nvm_erase,
> + ._unlock= lpddr2_nvm_unlock,
> + ._lock = lpddr2_nvm_lock,
> +};
> +
> /*
> * lpddr2_nvm driver probe method
> */
> @@ -433,6 +444,7 @@ static int lpddr2_nvm_probe(struct platform_device *pdev)
> .pfow_base = OW_BASE_ADDRESS,
> .fldrv_priv = pcm_data,
> };
> +
> if (IS_ERR(map->virt))
> return PTR_ERR(map->virt);
>
> @@ -444,22 +456,13 @@ static int lpddr2_nvm_probe(struct platform_device
> *pdev)
> return PTR_ERR(pcm_data->ctl_regs);
>
> /* Populate mtd_info data structure */
> - *mtd = (struct mtd_info) {
> - .dev= { .parent = >dev },
> - .name = pdev->dev.init_name,
> - .type = MTD_RAM,
> - .priv = map,
> - .size = resource_size(add_range),
> - .erasesize = ERASE_BLOCKSIZE * pcm_data->bus_width,
> - .writesize = 1,
> - .writebufsize = WRITE_BUFFSIZE * pcm_data->bus_width,
> - .flags = (MTD_CAP_NVRAM | MTD_POWERUP_LOCK),
> - ._read = lpddr2_nvm_read,
> - ._write = lpddr2_nvm_write,
> - ._erase = lpddr2_nvm_erase,
> - ._unlock= lpddr2_nvm_unlock,
> - ._lock = lpddr2_nvm_lock,
> - };
> + *mtd = lpddr2_nvm_mtd_info;
> + mtd->dev.parent = >dev;
> + mtd->name = pdev->dev.init_name;
> + mtd->priv = map;
> + mtd->size = resource_size(add_range);
> + mtd->erasesize = ERASE_BLOCKSIZE * pcm_data->bus_width;
> + mtd->writebufsize = WRITE_BUFFSIZE * pcm_data->bus_width;
>
> /* Verify the presence of the device looking for PFOW string */
> if (!lpddr2_nvm_pfow_present(map)) {
> --
> 2.26.0
>
Re: [PATCH] ASoC: Intel: sst: ipc command timeout
On 4/22/20 12:16 AM, Lu, Brent wrote: Regs width difference between BDW and BYT comes from specification. BDW has IPC registers which are 32 wide. This fact ain't exactly the reason to modify sst_shim32_read64. I'm sharing Amadeo's point of view. Your change should slow down execution a bit - but that might be just what handlers needed to make everything work again. Debug prints also slow down the execution what could have prevented you from spotting the real problem. Let's ignore the memcpy stuff for a moment - could you focus on elaborating the scenario where such issue occurs? Your initial commit message also skips important bits such as platform used when reproducing and so on, please add them. Thanks, Czarek This issue is reported to happen on BYT Chrome book (rambi) on Chrome-v4.4 branch after changing toolchain from clang10 to clang11. The reproduce step is simple. Just run arecord multiple times (<10) then you will see error message for hw_params ioctl failure. $ arecord -D hw:1,0 -f S16_LE -c 2 /dev/null $ ctrl+c The error message suggests the stream commit (IPC_IA_ALLOC_STREAM, 0x20) IPC command failed due to timeout but the msg id field of ipcd read after the timeout is also 0x20. It seems to me that the command is success but the host driver does not know it for some reason. 2020-03-15T23:02:06.614151+00:00 ERR kernel: [ 852.023766] baytrail-pcm-audio baytrail-pcm-audio: ipc: --message timeout-- ipcx 0x2220 isr 0xf0020 ipcd 0x2220 imrx 0x0 2020-03-15T23:02:06.614209+00:00 ERR kernel: [ 852.023796] baytrail-pcm-audio baytrail-pcm-audio: ipc: error stream commit failed 2020-03-15T23:02:06.614218+00:00 ERR kernel: [ 852.023813] Baytrail Audio: PCM: failed stream commit -110 2020-03-15T23:02:06.614225+00:00 ERR kernel: [ 852.023832] baytrail-pcm-audio baytrail-pcm-audio: ASoC: baytrail-pcm-audio hw params failed: -110 I add some messages to make the log easier to read. You can check the gerrit link if you are interested: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2131507 In the test patch I read the SST_IPCD register in sst_byt_irq_thread() twice and found the value could be different. The IPC_IA_FREE_STREAM(0x21) seems to be the last IPC command sent in the pcm_release of previous arecord command. [ 125.009724] sound pcmC1D0c: snd_pcm_release: [ 125.009732] baytrail-pcm-audio baytrail-pcm-audio: ipc_tx_message: header 0x8221 wait 1 [ 125.009760] baytrail-pcm-audio baytrail-pcm-audio: byt_tx_msg: header 0x8226 [ 125.009803] baytrail-pcm-audio baytrail-pcm-audio: sst_byt_irq_thread: header 0x297 [ 125.009823] baytrail-pcm-audio baytrail-pcm-audio: byt_tx_msg: header 0x8221 [ 125.009872] baytrail-pcm-audio baytrail-pcm-audio: sst_byt_irq_thread: header 0x297 [ 125.010442] baytrail-pcm-audio baytrail-pcm-audio: sst_byt_irq_thread: header 0x800c2226 [ 125.010456] baytrail-pcm-audio baytrail-pcm-audio: sst_ipc_reply_find_msg: not match, msg header 0x8221 [ 125.010511] baytrail-pcm-audio baytrail-pcm-audio: sst_byt_irq_thread: header 0x8221 [ 125.011355] baytrail-pcm-audio baytrail-pcm-audio: tx_wait_done: ipc success, header 0x8221 [ 125.380506] sound pcmC1D0c: snd_pcm_capture_open: [ 125.380544] sound pcmC1D0c: snd_pcm_capture_ioctl1: INFO [ 125.380554] sound pcmC1D0c: snd_pcm_capture_ioctl1: PVERSION [ 125.380561] sound pcmC1D0c: snd_pcm_capture_ioctl1: TTSTAMP [ 125.380581] sound pcmC1D0c: snd_pcm_mmap: [ 125.380622] sound pcmC1D0c: snd_pcm_mmap: [ 125.380648] sound pcmC1D0c: snd_pcm_capture_ioctl1: INFO [ 125.380717] sound pcmC1D0c: snd_pcm_capture_ioctl1: HW_REFINE [ 125.380737] sound pcmC1D0c: snd_pcm_capture_ioctl1: HW_REFINE [ 125.380766] sound pcmC1D0c: snd_pcm_capture_ioctl1: HW_REFINE [ 125.380779] sound pcmC1D0c: snd_pcm_capture_ioctl1: HW_REFINE [ 125.380789] sound pcmC1D0c: snd_pcm_capture_ioctl1: HW_REFINE [ 125.380799] sound pcmC1D0c: snd_pcm_capture_ioctl1: HW_REFINE [ 125.380808] sound pcmC1D0c: snd_pcm_capture_ioctl1: HW_REFINE [ 125.380815] sound pcmC1D0c: snd_pcm_capture_ioctl1: HW_PARAMS [ 125.380839] baytrail-pcm-audio baytrail-pcm-audio: ipc_tx_message: header 0x80642220 wait 1 [ 125.380854] baytrail-pcm-audio baytrail-pcm-audio: byt_tx_msg: header 0x80642220 => write IPC_IA_ALLOC_STREAM message (0x20) to SST_IPCX [ 125.380931] baytrail-pcm-audio baytrail-pcm-audio: sst_byt_irq_thread: header 0x8221 => read message reply from SST_IPCD and an IPC_IA_FREE_STREAM(0x21) is returned [ 125.380942] baytrail-pcm-audio baytrail-pcm-audio: sst_byt_irq_thread: ipcd 0x80602220 => read SST_IPCD again, this time the message id is what we are expected (0x20) Looks there is race between the previous stream stop and the current stream start here. Can you help try changing the sst_byt_stream_start/stop() from 'nowait' mode to 'wait' mode, and see if the issue can be
Re: [PATCH 2/3] ASoC: fsl_esai: Add support for imx8qm
Hi On Fri, May 1, 2020 at 6:23 PM Mark Brown wrote: > > On Fri, May 01, 2020 at 04:12:05PM +0800, Shengjiu Wang wrote: > > The difference for esai on imx8qm is that DMA device is EDMA. > > > > EDMA requires the period size to be multiple of maxburst. Otherwise > > the remaining bytes are not transferred and thus noise is produced. > > If this constraint comes from the DMA controller then normally you'd > expect the DMA controller integration to be enforcing this - is there no > information in the DMA API that lets us know that this constraint is > there? No, I can't find one API for this. Do you have a recommendation? best regards wang shengjiu
Intel KVM entry failed, hardware error 0x0
Today’s linux-next started to fail with this config, https://raw.githubusercontent.com/cailca/linux-mm/master/kcsan.config qemu-kvm-2.12.0-99.module+el8.2.0+5827+8c39933c.x86_64 I believe it was working yesterday. Before I bury myself bisecting it, does anyone have any thought? # /usr/libexec/qemu-kvm -name ubuntu-18.04-server-cloudimg -cpu host -smp 2 -m 2G -hda ubuntu-18.04-server-cloudimg.qcow2 -cdrom ubuntu-18.04-server-cloudimg.iso -nic user,hostfwd=tcp::-:22 -nographic KVM: entry failed, hardware error 0x0 EAX= EBX= ECX= EDX=000306f2 ESI= EDI= EBP= ESP= EIP=fff0 EFL=00010002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 9b00 SS = 9300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= [28040.962363][T78789] *** Guest State *** [28040.981990][T78789] CR0: actual=0x0030, shadow=0x6010, gh_mask=fff7 [28041.030248][T78789] CR4: actual=0x2040, shadow=0x, gh_mask=e871 [28041.075900][T78789] CR3 = 0x [28041.096369][T78789] RSP = 0x RIP = 0xfff0 [28041.127519][T78789] RFLAGS=0x00010002 DR7 = 0x0400 [28041.158730][T78789] Sysenter RSP= CS:RIP=: [28041.193409][T78789] CS: sel=0xf000, attr=0x0009b, limit=0x, base=0x [28041.234135][T78789] DS: sel=0x, attr=0x00093, limit=0x, base=0x [28041.274796][T78789] SS: sel=0x, attr=0x00093, limit=0x, base=0x [28041.315631][T78789] ES: sel=0x, attr=0x00093, limit=0x, base=0x [28041.357025][T78789] FS: sel=0x, attr=0x00093, limit=0x, base=0x [28041.397808][T78789] GS: sel=0x, attr=0x00093, limit=0x, base=0x [28041.438806][T78789] GDTR: limit=0x, base=0x [28041.479557][T78789] LDTR: sel=0x, attr=0x00082, limit=0x, base=0x [28041.522599][T78789] IDTR: limit=0x, base=0x [28041.564289][T78789] TR: sel=0x, attr=0x0008b, limit=0x, base=0x [28041.604705][T78789] EFER = 0x PAT = 0x0007040600070406 [28041.638146][T78789] DebugCtl = 0x DebugExceptions = 0x [28041.676235][T78789] Interruptibility = ActivityState = [28041.709019][T78789] InterruptStatus = [28041.728432][T78789] *** Host State *** [28041.746774][T78789] RIP = 0xc05ab620 RSP = 0xb24ec6c9fb08 [28041.777531][T78789] CS=0010 SS=0018 DS= ES= FS= GS= TR=0040 [28041.811313][T78789] FSBase=7f697700 GSBase=8d799f98 TRBase=fe1e [28041.851017][T78789] GDTBase=fe1de000 IDTBase=fe00 [28041.881294][T78789] CR0=80050033 CR3=0008802c8003 CR4=001626e0 [28041.917895][T78789] Sysenter RSP= CS:RIP=: [28041.953737][T78789] EFER = 0x0d01 PAT = 0x0007040600070406 [28041.986043][T78789] *** Control State *** [28042.006510][T78789] PinBased=00ff CPUBased=b5a06dfa SecondaryExec=37eb [28042.043823][T78789] EntryControls=d1ff ExitControls=002befff [28042.074416][T78789] ExceptionBitmap=00060042 PFECmask= PFECmatch= [28042.110314][T78789] VMEntry: intr_info= errcode= ilen= [28042.144970][T78789] VMExit: intr_info= errcode= ilen=0003 [28042.178829][T78789] reason=0030 qualification=0184 [28042.211619][T78789] IDTVectoring: info= errcode= [28042.240511][T78789] TSC Offset = 0xbe0284927b21 [28042.264284][T78789] SVI|RVI = 00|00 TPR Threshold = 0x00 [28042.289414][T78789] APIC-access addr = 0x000e5dfc virt-APIC addr = 0x000d2e76c000 [28042.330409][T78789] PostedIntrVec = 0xf2 [28042.349513][T78789] EPT pointer = 0x00105a27005e [28042.372955][T78789] PLE Gap=0080 Window=1000 [28042.396744][T78789] Virtual processor ID = 0x0001 # lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 48 On-line CPU(s) list: 0-47 Thread(s) per core: 1 Core(s) per socket: 12 Socket(s): 4 NUMA node(s):4 Vendor ID: GenuineIntel CPU family: 6 Model:
[PATCH -next] powerpc/kernel/sysfs: Use ARRAY_SIZE instead of calculating the array size
fix coccinelle warning, use ARRAY_SIZE arch/powerpc/kernel/sysfs.c:853:34-35: WARNING: Use ARRAY_SIZE arch/powerpc/kernel/sysfs.c:860:33-34: WARNING: Use ARRAY_SIZE arch/powerpc/kernel/sysfs.c:868:28-29: WARNING: Use ARRAY_SIZE arch/powerpc/kernel/sysfs.c:947:34-35: WARNING: Use ARRAY_SIZE arch/powerpc/kernel/sysfs.c:954:33-34: WARNING: Use ARRAY_SIZE arch/powerpc/kernel/sysfs.c:962:28-29: WARNING: Use ARRAY_SIZE Reported-by: Hulk Robot Signed-off-by: Samuel Zou --- arch/powerpc/kernel/sysfs.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c index 571b325..13d2423 100644 --- a/arch/powerpc/kernel/sysfs.c +++ b/arch/powerpc/kernel/sysfs.c @@ -850,14 +850,14 @@ static int register_cpu_online(unsigned int cpu) #ifdef HAS_PPC_PMC_IBM case PPC_PMC_IBM: attrs = ibm_common_attrs; - nattrs = sizeof(ibm_common_attrs) / sizeof(struct device_attribute); + nattrs = ARRAY_SIZE(ibm_common_attrs); pmc_attrs = classic_pmc_attrs; break; #endif /* HAS_PPC_PMC_IBM */ #ifdef HAS_PPC_PMC_G4 case PPC_PMC_G4: attrs = g4_common_attrs; - nattrs = sizeof(g4_common_attrs) / sizeof(struct device_attribute); + nattrs = ARRAY_SIZE(g4_common_attrs); pmc_attrs = classic_pmc_attrs; break; #endif /* HAS_PPC_PMC_G4 */ @@ -865,7 +865,7 @@ static int register_cpu_online(unsigned int cpu) case PPC_PMC_PA6T: /* PA Semi starts counting at PMC0 */ attrs = pa6t_attrs; - nattrs = sizeof(pa6t_attrs) / sizeof(struct device_attribute); + nattrs = ARRAY_SIZE(pa6t_attrs); pmc_attrs = NULL; break; #endif @@ -944,14 +944,14 @@ static int unregister_cpu_online(unsigned int cpu) #ifdef HAS_PPC_PMC_IBM case PPC_PMC_IBM: attrs = ibm_common_attrs; - nattrs = sizeof(ibm_common_attrs) / sizeof(struct device_attribute); + nattrs = ARRAY_SIZE(ibm_common_attrs); pmc_attrs = classic_pmc_attrs; break; #endif /* HAS_PPC_PMC_IBM */ #ifdef HAS_PPC_PMC_G4 case PPC_PMC_G4: attrs = g4_common_attrs; - nattrs = sizeof(g4_common_attrs) / sizeof(struct device_attribute); + nattrs = ARRAY_SIZE(g4_common_attrs); pmc_attrs = classic_pmc_attrs; break; #endif /* HAS_PPC_PMC_G4 */ @@ -959,7 +959,7 @@ static int unregister_cpu_online(unsigned int cpu) case PPC_PMC_PA6T: /* PA Semi starts counting at PMC0 */ attrs = pa6t_attrs; - nattrs = sizeof(pa6t_attrs) / sizeof(struct device_attribute); + nattrs = ARRAY_SIZE(pa6t_attrs); pmc_attrs = NULL; break; #endif -- 2.6.2
Re: [PATCH v2] stacktrace: cleanup inconsistent variable type
On Wed, 2020-04-22 at 18:21 -0700, Bart Van Assche wrote: > On 4/20/20 6:35 PM, Walter Wu wrote: > > Modify the variable type of 'skip' member of struct stack_trace. > > In theory, the 'skip' variable type should be unsigned int. > > There are two reasons: > > - The 'skip' only has two situation, 1)Positive value, 2)Zero > > - The 'skip' of struct stack_trace has inconsistent type with struct > >stack_trace_data, it makes a bit confusion in the relationship between > >struct stack_trace and stack_trace_data. > > Reviewed-by: Bart Van Assche Hi Andrew, Would you know why not to be picked up this patch yet? Do I miss somethings? Thank you for your help. Walter
Re: cgroup pointed by sock is leaked on mode switch
On 2020/5/6 9:50, Yang Yingliang wrotee:
+cc lize...@huawei.com
On 2020/5/6 0:06, Tejun Heo wrote:
Hello, Yang.
On Sat, May 02, 2020 at 06:27:21PM +0800, Yang Yingliang wrote:
I find the number nr_dying_descendants is increasing:
linux-dVpNUK:~ # find /sys/fs/cgroup/ -name cgroup.stat -exec grep
'^nr_dying_descendants [^0]' {} +
/sys/fs/cgroup/unified/cgroup.stat:nr_dying_descendants 80
/sys/fs/cgroup/unified/system.slice/cgroup.stat:nr_dying_descendants 1
/sys/fs/cgroup/unified/system.slice/system-hostos.slice/cgroup.stat:nr_dying_descendants
1
/sys/fs/cgroup/unified/lxc/cgroup.stat:nr_dying_descendants 79
/sys/fs/cgroup/unified/lxc/5f1fdb8c54fa40c3e599613dab6e4815058b76ebada8a27bc1fe80c0d4801764/cgroup.stat:nr_dying_descendants
78
/sys/fs/cgroup/unified/lxc/5f1fdb8c54fa40c3e599613dab6e4815058b76ebada8a27bc1fe80c0d4801764/system.slice/cgroup.stat:nr_dying_descendants
78
Those numbers are nowhere close to causing oom issues. There are some
aspects of page and other cache draining which is being improved but unless
you're seeing numbers multiple orders of magnitude higher, this isn't the
source of your problem.
The situation is as same as the commit bd1060a1d671 ("sock, cgroup: add
sock->sk_cgroup") describes.
"On mode switch, cgroup references which are already being pointed to by
socks may be leaked."
I'm doubtful that you're hitting that issue. Mode switching means memcg
being switched between cgroup1 and cgroup2 hierarchies, which is unlikely to
be what's happening when you're launching docker containers.
The first step would be identifying where memory is going and finding out
whether memcg is actually being switched between cgroup1 and 2 - look at the
hierarchy number in /proc/cgroups, if that's switching between 0 and
someting not zero, it is switching.
I think there's a bug here which can lead to unlimited memory leak.
This should reproduce the bug:
# mount -t cgroup -o netprio xxx /cgroup/netprio
# mkdir /cgroup/netprio/xxx
# echo PID > /cgroup/netprio/xxx/tasks
/* this PID process starts to do some network thing and then exits */
# rmdir /cgroup/netprio/xxx
/* now this cgroup will never be freed */
Look at the code:
static inline void sock_update_netprioidx(struct sock_cgroup_data *skcd)
{
...
sock_cgroup_set_prioidx(skcd, task_netprioidx(current));
}
static inline void sock_cgroup_set_prioidx(struct sock_cgroup_data *skcd,
u16 prioidx)
{
...
if (sock_cgroup_prioidx(_buf) == prioidx)
return ;
...
skcd_buf.prioidx = prioidx;
WRITE_ONCE(skcd->val, skcd_buf.val);
}
task_netprioidx() will be the cgrp id of xxx which is not 1, but
sock_cgroup_prioidx(_buf) is 1 because it thought it's in v2 mode.
Now we have a memory leak.
I think the eastest fix is to do the mode switch here:
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index b905747..2397866 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -240,6 +240,8 @@ static void net_prio_attach(struct cgroup_taskset *tset)
struct task_struct *p;
struct cgroup_subsys_state *css;
+ cgroup_sk_alloc_disable();
+
cgroup_taskset_for_each(p, css, tset) {
void *v = (void *)(unsigned long)css->cgroup->id;
Re: [PATCH v4 0/3] Replace private domain with per-group default domain
On Wed, May 6, 2020 at 10:03 AM Lu Baolu wrote: > https://lkml.org/lkml/2020/4/14/616 > [This has been applied in iommu/next.] > > Hence, there is no need to keep the private domain implementation > in the Intel IOMMU driver. This patch series aims to remove it. I applied these patches on top of Joerg's branch and confirmed that they fix the issue discussed in the thread: [PATCH v2] iommu/vt-d: consider real PCI device when checking if mapping is needed (the patch there is no longer needed) Tested-by: Daniel Drake Thanks!
[PATCH v4 1/3] iommu/vt-d: Allow 32bit devices to uses DMA domain
Currently, if a 32bit device initially uses an identity domain, Intel
IOMMU driver will convert it forcibly to a DMA one if its address
capability is not enough for the whole system memory. The motivation was
to overcome the overhead caused by possible bounced buffer.
Unfortunately, this improvement has led to many problems. For example,
some 32bit devices are required to use an identity domain, forcing them
to use DMA domain will cause the device not to work anymore. On the
other hand, the VMD sub-devices share a domain but each sub-device might
have different address capability. Forcing a VMD sub-device to use DMA
domain blindly will impact the operation of other sub-devices without
any notification. Further more, PCI aliased devices (PCI bridge and all
devices beneath it, VMD devices and various devices quirked with
pci_add_dma_alias()) must use the same domain. Forcing one device to
switch to DMA domain during runtime will cause in-fligh DMAs for other
devices to abort or target to other memory which might cause undefind
system behavior.
With the last private domain usage in iommu_need_mapping() removed, all
private domain helpers are also cleaned in this patch. Otherwise, the
compiler will complain that some functions are defined but not used.
Cc: Daniel Drake
Cc: Derrick Jonathan
Cc: Jerry Snitselaar
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 291 +---
1 file changed, 1 insertion(+), 290 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 34e08fa2ce3a..16ba7add0f72 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -355,11 +355,6 @@ static void domain_exit(struct dmar_domain *domain);
static void domain_remove_dev_info(struct dmar_domain *domain);
static void dmar_remove_one_dev_info(struct device *dev);
static void __dmar_remove_one_dev_info(struct device_domain_info *info);
-static void domain_context_clear(struct intel_iommu *iommu,
-struct device *dev);
-static int domain_detach_iommu(struct dmar_domain *domain,
- struct intel_iommu *iommu);
-static bool device_is_rmrr_locked(struct device *dev);
static int intel_iommu_attach_device(struct iommu_domain *domain,
struct device *dev);
static phys_addr_t intel_iommu_iova_to_phys(struct iommu_domain *domain,
@@ -1930,65 +1925,6 @@ static inline int guestwidth_to_adjustwidth(int gaw)
return agaw;
}
-static int domain_init(struct dmar_domain *domain, struct intel_iommu *iommu,
- int guest_width)
-{
- int adjust_width, agaw;
- unsigned long sagaw;
- int ret;
-
- init_iova_domain(>iovad, VTD_PAGE_SIZE, IOVA_START_PFN);
-
- if (!intel_iommu_strict) {
- ret = init_iova_flush_queue(>iovad,
- iommu_flush_iova, iova_entry_free);
- if (ret)
- pr_info("iova flush queue initialization failed\n");
- }
-
- domain_reserve_special_ranges(domain);
-
- /* calculate AGAW */
- if (guest_width > cap_mgaw(iommu->cap))
- guest_width = cap_mgaw(iommu->cap);
- domain->gaw = guest_width;
- adjust_width = guestwidth_to_adjustwidth(guest_width);
- agaw = width_to_agaw(adjust_width);
- sagaw = cap_sagaw(iommu->cap);
- if (!test_bit(agaw, )) {
- /* hardware doesn't support it, choose a bigger one */
- pr_debug("Hardware doesn't support agaw %d\n", agaw);
- agaw = find_next_bit(, 5, agaw);
- if (agaw >= 5)
- return -ENODEV;
- }
- domain->agaw = agaw;
-
- if (ecap_coherent(iommu->ecap))
- domain->iommu_coherency = 1;
- else
- domain->iommu_coherency = 0;
-
- if (ecap_sc_support(iommu->ecap))
- domain->iommu_snooping = 1;
- else
- domain->iommu_snooping = 0;
-
- if (intel_iommu_superpage)
- domain->iommu_superpage = fls(cap_super_page_val(iommu->cap));
- else
- domain->iommu_superpage = 0;
-
- domain->nid = iommu->node;
-
- /* always allocate the top pgd */
- domain->pgd = (struct dma_pte *)alloc_pgtable_page(domain->nid);
- if (!domain->pgd)
- return -ENOMEM;
- __iommu_flush_cache(iommu, domain->pgd, PAGE_SIZE);
- return 0;
-}
-
static void domain_exit(struct dmar_domain *domain)
{
@@ -2704,94 +2640,6 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
return domain;
}
-static int get_last_alias(struct pci_dev *pdev, u16 alias, void *opaque)
-{
- *(u16 *)opaque = alias;
- return 0;
-}
-
-static struct dmar_domain *find_or_alloc_domain(struct device *dev, int gaw)
-{
- struct device_domain_info *info;
- struct dmar_domain
Re: [RFC 2/2] remoteproc: core: keep rproc in crash state in case of recovery failure
On Wed 11 Mar 03:54 PDT 2020, Loic Pallardy wrote: > When an error occurs during recovery procedure, internal rproc > variables may be unaligned: > - state is set to RPROC_OFFLINE > - power atomic not equal to 0 > which is normal as only rproc_stop() has been executed and not > rproc_shutdown() > > In such case, rproc_boot() can be re-executed by client to > reboot co-processor. > > This patch proposes to keep rproc in RPROC_CRASHED state in case > of recovery failure to be coherent with recovery disabled mode. > > Signed-off-by: Loic Pallardy > --- > drivers/remoteproc/remoteproc_core.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/remoteproc/remoteproc_core.c > b/drivers/remoteproc/remoteproc_core.c > index 7ac87a75cd1b..def4f9fc881d 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -1679,6 +1679,12 @@ int rproc_trigger_recovery(struct rproc *rproc) > release_firmware(firmware_p); > > unlock_mutex: > + /* > + * In case of error during recovery sequence restore rproc > + * state in CRASHED > + */ > + if (ret) > + rproc->state = RPROC_CRASHED; Got back to this after looking at Mathieu's synchronization series, I think it would be cleaner if we move the rproc->state update out of rproc_start() and rproc_stop(). That way we would leave the state in CRASHED state throughout the recovery process, which I think makes it easier to reason about the various states and their transitions. Regards, Bjorn > mutex_unlock(>lock); > return ret; > } > -- > 2.7.4 >
[PATCH v4 2/3] iommu/vt-d: Allow PCI sub-hierarchy to use DMA domain
Before commit fa954e6831789 ("iommu/vt-d: Delegate the dma domain
to upper layer"), Intel IOMMU started off with all devices in the
identity domain, and took them out later if it found they couldn't
access all of memory. This required devices behind a PCI bridge to
use a DMA domain at the beginning because all PCI devices behind
the bridge use the same source-id in their transactions and the
domain couldn't be changed at run-time.
Intel IOMMU driver is now aligned with the default domain framework,
there's no need to keep this requirement anymore.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 16ba7add0f72..af309e8fa6f5 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2857,31 +2857,6 @@ static int device_def_domain_type(struct device *dev)
if ((iommu_identity_mapping & IDENTMAP_GFX) &&
IS_GFX_DEVICE(pdev))
return IOMMU_DOMAIN_IDENTITY;
-
- /*
-* We want to start off with all devices in the 1:1 domain, and
-* take them out later if we find they can't access all of
memory.
-*
-* However, we can't do this for PCI devices behind bridges,
-* because all PCI devices behind the same bridge will end up
-* with the same source-id on their transactions.
-*
-* Practically speaking, we can't change things around for these
-* devices at run-time, because we can't be sure there'll be no
-* DMA transactions in flight for any of their siblings.
-*
-* So PCI devices (unless they're on the root bus) as well as
-* their parent PCI-PCI or PCIe-PCI bridges must be left _out_
of
-* the 1:1 domain, just in _case_ one of their siblings turns
out
-* not to be able to map all of memory.
-*/
- if (!pci_is_pcie(pdev)) {
- if (!pci_is_root_bus(pdev->bus))
- return IOMMU_DOMAIN_DMA;
- if (pdev->class >> 8 == PCI_CLASS_BRIDGE_PCI)
- return IOMMU_DOMAIN_DMA;
- } else if (pci_pcie_type(pdev) == PCI_EXP_TYPE_PCI_BRIDGE)
- return IOMMU_DOMAIN_DMA;
}
return 0;
--
2.17.1
