* Re: [PATCH v2] cgroup: memcg: net: do not associate sock with unrelated cgroup
From: Shakeel Butt @ 2020-02-14 22:44 UTC (permalink / raw)
To: Roman Gushchin
Cc: Johannes Weiner, Eric Dumazet, Tejun Heo, Greg Thelen,
Michal Hocko, Vladimir Davydov, Andrew Morton, Cgroups, Linux MM,
LKML
In-Reply-To: <20200214223303.GA60585@carbon.dhcp.thefacebook.com>
On Fri, Feb 14, 2020 at 2:33 PM Roman Gushchin <guro@fb.com> wrote:
>
> On Fri, Feb 14, 2020 at 02:24:15PM -0800, Shakeel Butt wrote:
> > We are testing network memory accounting in our setup and noticed
> > inconsistent network memory usage and often unrelated cgroups network
> > usage correlates with testing workload. On further inspection, it
> > seems like mem_cgroup_sk_alloc() and cgroup_sk_alloc() are broken in
> > irq context specially for cgroup v1.
> >
> > mem_cgroup_sk_alloc() and cgroup_sk_alloc() can be called in irq context
> > and kind of assumes that this can only happen from sk_clone_lock()
> > and the source sock object has already associated cgroup. However in
> > cgroup v1, where network memory accounting is opt-in, the source sock
> > can be unassociated with any cgroup and the new cloned sock can get
> > associated with unrelated interrupted cgroup.
> >
> > Cgroup v2 can also suffer if the source sock object was created by
> > process in the root cgroup or if sk_alloc() is called in irq context.
> > The fix is to just do nothing in interrupt.
> >
> > Fixes: 2d7580738345 ("mm: memcontrol: consolidate cgroup socket tracking")
> > Fixes: d979a39d7242 ("cgroup: duplicate cgroup reference when cloning sockets")
> > Signed-off-by: Shakeel Butt <shakeelb@google.com>
> > ---
> >
> > Changes since v1:
> > - Fix cgroup_sk_alloc() too.
> >
> > kernel/cgroup/cgroup.c | 4 ++++
> > mm/memcontrol.c | 4 ++++
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> > index 9a8a5ded3c48..46e5f5518fba 100644
> > --- a/kernel/cgroup/cgroup.c
> > +++ b/kernel/cgroup/cgroup.c
> > @@ -6449,6 +6449,10 @@ void cgroup_sk_alloc(struct sock_cgroup_data *skcd)
> > return;
> > }
> >
> > + /* Do not associate the sock with unrelated interrupted task's memcg. */
> ^^^^^
> cgroup?
> > + if (in_interrupt())
> > + return;
> > +
> > rcu_read_lock();
> >
> > while (true) {
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 63bb6a2aab81..f500da82bfe8 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -6697,6 +6697,10 @@ void mem_cgroup_sk_alloc(struct sock *sk)
> > return;
> > }
>
> Can you, please, include the stacktrace into the commit log?
> Except a minor typo (see above),
> Reviewed-by: Roman Gushchin <guro@fb.com>
>
> A really good catch.
>
Thanks, I will add the stack trace and fix the typo.
Shakeel
^ permalink raw reply
* Re: [PATCH v2] cgroup: memcg: net: do not associate sock with unrelated cgroup
From: Shakeel Butt @ 2020-02-14 22:44 UTC (permalink / raw)
To: Roman Gushchin
Cc: Johannes Weiner, Eric Dumazet, Tejun Heo, Greg Thelen,
Michal Hocko, Vladimir Davydov, Andrew Morton, Cgroups, Linux MM,
LKML
In-Reply-To: <20200214223303.GA60585-cx5fftMpWqeCjSd+JxjunQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
On Fri, Feb 14, 2020 at 2:33 PM Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org> wrote:
>
> On Fri, Feb 14, 2020 at 02:24:15PM -0800, Shakeel Butt wrote:
> > We are testing network memory accounting in our setup and noticed
> > inconsistent network memory usage and often unrelated cgroups network
> > usage correlates with testing workload. On further inspection, it
> > seems like mem_cgroup_sk_alloc() and cgroup_sk_alloc() are broken in
> > irq context specially for cgroup v1.
> >
> > mem_cgroup_sk_alloc() and cgroup_sk_alloc() can be called in irq context
> > and kind of assumes that this can only happen from sk_clone_lock()
> > and the source sock object has already associated cgroup. However in
> > cgroup v1, where network memory accounting is opt-in, the source sock
> > can be unassociated with any cgroup and the new cloned sock can get
> > associated with unrelated interrupted cgroup.
> >
> > Cgroup v2 can also suffer if the source sock object was created by
> > process in the root cgroup or if sk_alloc() is called in irq context.
> > The fix is to just do nothing in interrupt.
> >
> > Fixes: 2d7580738345 ("mm: memcontrol: consolidate cgroup socket tracking")
> > Fixes: d979a39d7242 ("cgroup: duplicate cgroup reference when cloning sockets")
> > Signed-off-by: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > ---
> >
> > Changes since v1:
> > - Fix cgroup_sk_alloc() too.
> >
> > kernel/cgroup/cgroup.c | 4 ++++
> > mm/memcontrol.c | 4 ++++
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> > index 9a8a5ded3c48..46e5f5518fba 100644
> > --- a/kernel/cgroup/cgroup.c
> > +++ b/kernel/cgroup/cgroup.c
> > @@ -6449,6 +6449,10 @@ void cgroup_sk_alloc(struct sock_cgroup_data *skcd)
> > return;
> > }
> >
> > + /* Do not associate the sock with unrelated interrupted task's memcg. */
> ^^^^^
> cgroup?
> > + if (in_interrupt())
> > + return;
> > +
> > rcu_read_lock();
> >
> > while (true) {
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 63bb6a2aab81..f500da82bfe8 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -6697,6 +6697,10 @@ void mem_cgroup_sk_alloc(struct sock *sk)
> > return;
> > }
>
> Can you, please, include the stacktrace into the commit log?
> Except a minor typo (see above),
> Reviewed-by: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>
>
> A really good catch.
>
Thanks, I will add the stack trace and fix the typo.
Shakeel
^ permalink raw reply
* Re: [PATCH] staging: exfat: add exfat filesystem code to staging
From: Pali Rohár @ 2020-02-14 22:43 UTC (permalink / raw)
To: Valdis Klētnieks
Cc: Sasha Levin, Greg Kroah-Hartman, devel, linux-fsdevel,
linux-kernel, Sasha Levin, Christoph Hellwig
In-Reply-To: <86151.1581718578@turing-police>
On Friday 14 February 2020 17:16:18 Valdis Klētnieks wrote:
> On Thu, 13 Feb 2020 16:18:47 -0500, Sasha Levin said:
>
> > >> I was hoping that it would be possible to easily use secondary FAT table
> > >> (from TexFAT extension) for redundancy without need to implement full
> > >> TexFAT, which could be also backward compatible with systems which do
> > >> not implement TexFAT extension at all. Similarly like using FAT32 disk
> > >> with two FAT tables is possible also on system which use first FAT
> > >> table.
>
> OK.. maybe I'm not sufficiently caffeinated, but how do you use 2 FAT tables on
> a physical device and expect it to work properly on a system that uses just the
> first FAT table, if the device is set to "use second table" when you mount it?
> That sounds just too much like the failure modes of running fsck on a mounted
> filesystem....
Idea is simple. Expects that we have a clean filesystem in correct
state. We load primary/active/main FAT table (just call it FAT1) and all
changes to filesystem would be done via second non-active FAT table
(FAT2). At unmount or sync or flush buffer times, FAT2 would be copied
back to the FAT1 and filesystem would be back in clean state.
So this should not break support for implementations which use just
FAT1. And if above implementation which use both FAT1 and FAT2 "crash"
during write operations to FAT2 it may be possible to reconstruct and
repair some parts of filesystem from FAT1 (as it would contain previous
state of some filesystem parts).
Via dirty bit can be detected if proper unmount occurred or not, and
fsck implementation could do use this fact and try to do repairing
(possible by asking user what should do).
Of course if implementation use only FAT1 we cannot use FAT2 for
repairing and therefore fsck should really ask user if it should use
FAT2 for repair or not.
If implementation use only FAT1, does not crash and let filesystem in
clean/correct state then there should not be any problem for
implementation which can use both FATs as it reads main state from FAT1.
Therefore these two implementations should be compatible and problem can
happen only if they let filesystem in inconsistent state. (But if they
let it in inconsistent state, then any implementation may have troubles
and fsck is needed).
I hope that it is more clear now...
> > >By the chance, is there any possibility to release TexFAT specification?
> > >Usage of more FAT tables (even for Linux) could help with data recovery.
> >
> > This would be a major pain in the arse to pull off (even more that
> > releasing exFAT itself) because TexFAT is effectively dead and no one
> > here cares about it. It's not even the case that there are devices which
> > are now left unsupported, the whole TexFAT scheme is just dead and gone.
> >
> > Could I point you to the TexFAT patent instead
> > (https://patents.google.com/patent/US7613738B2/en)? It describes well
> > how TexFAT used to work.
>
> I don't think anybody wants the full TexFAT support - but having a backup copy
> of the FAT would be nice in some circumstances.
Main problem is that we do not know what "full TexFAT support" means as
currently it is secret.
My original question for TexFAT was also because of NumberOfFats set to
2 is according to released exFAT specification possible only for TexFAT
volumes.
And from reading whole exFAT specification I see that better data
recovery can be achieved only by having backup copy of FAT table (and
allocation bitmap), which is limited to (currently undocumented) TexFAT
extension.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* [PATCH 1/7] of/address: Move range parser code out of CONFIG_PCI
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
To: devicetree, Frank Rowand
Cc: linux-kernel, Linus Walleij, Robin Murphy, Christoph Hellwig,
Arnd Bergmann, Benjamin Herrenschmidt, linuxppc-dev,
Michael Ellerman, Michal Simek, Paul Mackerras
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>
In preparation to make the range parsing code work for non-PCI buses,
move the parsing functions out from the CONFIG_PCI #ifdef.
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/of/address.c | 215 ++++++++++++++++++++++---------------------
1 file changed, 109 insertions(+), 106 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index e8a39c3ec4d4..846045a48395 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -100,6 +100,28 @@ static unsigned int of_bus_default_get_flags(const __be32 *addr)
return IORESOURCE_MEM;
}
+static unsigned int of_bus_pci_get_flags(const __be32 *addr)
+{
+ unsigned int flags = 0;
+ u32 w = be32_to_cpup(addr);
+
+ if (!IS_ENABLED(CONFIG_PCI))
+ return 0;
+
+ switch((w >> 24) & 0x03) {
+ case 0x01:
+ flags |= IORESOURCE_IO;
+ break;
+ case 0x02: /* 32 bits */
+ case 0x03: /* 64 bits */
+ flags |= IORESOURCE_MEM;
+ break;
+ }
+ if (w & 0x40000000)
+ flags |= IORESOURCE_PREFETCH;
+ return flags;
+}
+
#ifdef CONFIG_PCI
/*
* PCI bus specific translator
@@ -125,25 +147,6 @@ static void of_bus_pci_count_cells(struct device_node *np,
*sizec = 2;
}
-static unsigned int of_bus_pci_get_flags(const __be32 *addr)
-{
- unsigned int flags = 0;
- u32 w = be32_to_cpup(addr);
-
- switch((w >> 24) & 0x03) {
- case 0x01:
- flags |= IORESOURCE_IO;
- break;
- case 0x02: /* 32 bits */
- case 0x03: /* 64 bits */
- flags |= IORESOURCE_MEM;
- break;
- }
- if (w & 0x40000000)
- flags |= IORESOURCE_PREFETCH;
- return flags;
-}
-
static u64 of_bus_pci_map(__be32 *addr, const __be32 *range, int na, int ns,
int pna)
{
@@ -234,93 +237,6 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
-static int parser_init(struct of_pci_range_parser *parser,
- struct device_node *node, const char *name)
-{
- const int na = 3, ns = 2;
- int rlen;
-
- parser->node = node;
- parser->pna = of_n_addr_cells(node);
- parser->np = parser->pna + na + ns;
- parser->dma = !strcmp(name, "dma-ranges");
-
- parser->range = of_get_property(node, name, &rlen);
- if (parser->range == NULL)
- return -ENOENT;
-
- parser->end = parser->range + rlen / sizeof(__be32);
-
- return 0;
-}
-
-int of_pci_range_parser_init(struct of_pci_range_parser *parser,
- struct device_node *node)
-{
- return parser_init(parser, node, "ranges");
-}
-EXPORT_SYMBOL_GPL(of_pci_range_parser_init);
-
-int of_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
- struct device_node *node)
-{
- return parser_init(parser, node, "dma-ranges");
-}
-EXPORT_SYMBOL_GPL(of_pci_dma_range_parser_init);
-
-struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
- struct of_pci_range *range)
-{
- const int na = 3, ns = 2;
-
- if (!range)
- return NULL;
-
- if (!parser->range || parser->range + parser->np > parser->end)
- return NULL;
-
- range->pci_space = be32_to_cpup(parser->range);
- range->flags = of_bus_pci_get_flags(parser->range);
- range->pci_addr = of_read_number(parser->range + 1, ns);
- if (parser->dma)
- range->cpu_addr = of_translate_dma_address(parser->node,
- parser->range + na);
- else
- range->cpu_addr = of_translate_address(parser->node,
- parser->range + na);
- range->size = of_read_number(parser->range + parser->pna + na, ns);
-
- parser->range += parser->np;
-
- /* Now consume following elements while they are contiguous */
- while (parser->range + parser->np <= parser->end) {
- u32 flags;
- u64 pci_addr, cpu_addr, size;
-
- flags = of_bus_pci_get_flags(parser->range);
- pci_addr = of_read_number(parser->range + 1, ns);
- if (parser->dma)
- cpu_addr = of_translate_dma_address(parser->node,
- parser->range + na);
- else
- cpu_addr = of_translate_address(parser->node,
- parser->range + na);
- size = of_read_number(parser->range + parser->pna + na, ns);
-
- if (flags != range->flags)
- break;
- if (pci_addr != range->pci_addr + range->size ||
- cpu_addr != range->cpu_addr + range->size)
- break;
-
- range->size += size;
- parser->range += parser->np;
- }
-
- return range;
-}
-EXPORT_SYMBOL_GPL(of_pci_range_parser_one);
-
/*
* of_pci_range_to_resource - Create a resource from an of_pci_range
* @range: the PCI range that describes the resource
@@ -775,6 +691,93 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
}
EXPORT_SYMBOL(of_get_address);
+static int parser_init(struct of_pci_range_parser *parser,
+ struct device_node *node, const char *name)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser->node = node;
+ parser->pna = of_n_addr_cells(node);
+ parser->np = parser->pna + na + ns;
+ parser->dma = !strcmp(name, "dma-ranges");
+
+ parser->range = of_get_property(node, name, &rlen);
+ if (parser->range == NULL)
+ return -ENOENT;
+
+ parser->end = parser->range + rlen / sizeof(__be32);
+
+ return 0;
+}
+
+int of_pci_range_parser_init(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ return parser_init(parser, node, "ranges");
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_init);
+
+int of_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ return parser_init(parser, node, "dma-ranges");
+}
+EXPORT_SYMBOL_GPL(of_pci_dma_range_parser_init);
+
+struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
+ struct of_pci_range *range)
+{
+ const int na = 3, ns = 2;
+
+ if (!range)
+ return NULL;
+
+ if (!parser->range || parser->range + parser->np > parser->end)
+ return NULL;
+
+ range->pci_space = be32_to_cpup(parser->range);
+ range->flags = of_bus_pci_get_flags(parser->range);
+ range->pci_addr = of_read_number(parser->range + 1, ns);
+ if (parser->dma)
+ range->cpu_addr = of_translate_dma_address(parser->node,
+ parser->range + na);
+ else
+ range->cpu_addr = of_translate_address(parser->node,
+ parser->range + na);
+ range->size = of_read_number(parser->range + parser->pna + na, ns);
+
+ parser->range += parser->np;
+
+ /* Now consume following elements while they are contiguous */
+ while (parser->range + parser->np <= parser->end) {
+ u32 flags;
+ u64 pci_addr, cpu_addr, size;
+
+ flags = of_bus_pci_get_flags(parser->range);
+ pci_addr = of_read_number(parser->range + 1, ns);
+ if (parser->dma)
+ cpu_addr = of_translate_dma_address(parser->node,
+ parser->range + na);
+ else
+ cpu_addr = of_translate_address(parser->node,
+ parser->range + na);
+ size = of_read_number(parser->range + parser->pna + na, ns);
+
+ if (flags != range->flags)
+ break;
+ if (pci_addr != range->pci_addr + range->size ||
+ cpu_addr != range->cpu_addr + range->size)
+ break;
+
+ range->size += size;
+ parser->range += parser->np;
+ }
+
+ return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_one);
+
static u64 of_translate_ioport(struct device_node *dev, const __be32 *in_addr,
u64 size)
{
--
2.20.1
^ permalink raw reply related
* [PATCH 3/7] powerpc: Drop using struct of_pci_range.pci_space field
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
To: devicetree, Frank Rowand
Cc: linux-kernel, Linus Walleij, Robin Murphy, Christoph Hellwig,
Arnd Bergmann, Benjamin Herrenschmidt, linuxppc-dev,
Michael Ellerman, Michal Simek, Paul Mackerras
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>
Let's use the struct of_pci_range.flags field instead so we can remove
the pci_space field.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/powerpc/kernel/pci-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index c6c03416a151..d0074ad73aa3 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -728,7 +728,7 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
range.cpu_addr, range.cpu_addr + range.size - 1,
range.pci_addr,
- (range.pci_space & 0x40000000) ?
+ (range.flags & IORESOURCE_PREFETCH) ?
"Prefetch" : "");
/* We support only 3 memory ranges */
--
2.20.1
^ permalink raw reply related
* [PATCH 4/7] of: Drop struct of_pci_range.pci_space field
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
To: devicetree, Frank Rowand
Cc: linux-kernel, Linus Walleij, Robin Murphy, Christoph Hellwig,
Arnd Bergmann, Benjamin Herrenschmidt, linuxppc-dev,
Michael Ellerman, Michal Simek, Paul Mackerras
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>
There's no more users of struct of_pci_range.pci_space field, so remove it.
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/of/address.c | 1 -
include/linux/of_address.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 846045a48395..5d608d7c10d6 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -736,7 +736,6 @@ struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
if (!parser->range || parser->range + parser->np > parser->end)
return NULL;
- range->pci_space = be32_to_cpup(parser->range);
range->flags = of_bus_pci_get_flags(parser->range);
range->pci_addr = of_read_number(parser->range + 1, ns);
if (parser->dma)
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index eac7ab109df4..8d12bf18e80b 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -16,7 +16,6 @@ struct of_pci_range_parser {
};
struct of_pci_range {
- u32 pci_space;
u64 pci_addr;
u64 cpu_addr;
u64 size;
--
2.20.1
^ permalink raw reply related
* [PATCH 6/7] of/address: use range parser for of_dma_get_range
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
To: devicetree, Frank Rowand
Cc: linux-kernel, Linus Walleij, Robin Murphy, Christoph Hellwig,
Arnd Bergmann, Benjamin Herrenschmidt, linuxppc-dev,
Michael Ellerman, Michal Simek, Paul Mackerras
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>
of_dma_get_range() does the same ranges parsing as
of_pci_range_parser_one(), so let's refactor of_dma_get_range() to use
it instead.
This commit is no functional change. Subsequent commits will parse more
than the 1st dma-ranges entry.
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/of/address.c | 38 +++++++++++++-------------------------
1 file changed, 13 insertions(+), 25 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 6d33f849f114..a2c45812a50e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -939,10 +939,11 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
{
struct device_node *node = of_node_get(np);
const __be32 *ranges = NULL;
- int len, naddr, nsize, pna;
+ int len;
int ret = 0;
bool found_dma_ranges = false;
- u64 dmaaddr;
+ struct of_range_parser parser;
+ struct of_range range;
while (node) {
ranges = of_get_property(node, "dma-ranges", &len);
@@ -967,33 +968,20 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
goto out;
}
- naddr = of_bus_n_addr_cells(node);
- nsize = of_bus_n_size_cells(node);
- pna = of_n_addr_cells(node);
- if ((len / sizeof(__be32)) % (pna + naddr + nsize)) {
- ret = -EINVAL;
- goto out;
- }
+ of_dma_range_parser_init(&parser, node);
+
+ for_each_of_range(&parser, &range) {
+ pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+ range.bus_addr, range.cpu_addr, range.size);
+
+ *dma_addr = range.bus_addr;
+ *paddr = range.cpu_addr;
+ *size = range.size;
- /* dma-ranges format:
- * DMA addr : naddr cells
- * CPU addr : pna cells
- * size : nsize cells
- */
- dmaaddr = of_read_number(ranges, naddr);
- *paddr = of_translate_dma_address(node, ranges + naddr);
- if (*paddr == OF_BAD_ADDR) {
- pr_err("translation of DMA address(%llx) to CPU address failed node(%pOF)\n",
- dmaaddr, np);
- ret = -EINVAL;
goto out;
}
- *dma_addr = dmaaddr;
-
- *size = of_read_number(ranges + naddr + pna, nsize);
- pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
- *dma_addr, *paddr, *size);
+ pr_err("translation of DMA ranges failed on node(%pOF)\n", np);
out:
of_node_put(node);
--
2.20.1
^ permalink raw reply related
* [PATCH 5/7] of/address: Rework of_pci_range parsing for non-PCI buses
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
To: devicetree, Frank Rowand
Cc: linux-kernel, Linus Walleij, Robin Murphy, Christoph Hellwig,
Arnd Bergmann, Benjamin Herrenschmidt, linuxppc-dev,
Michael Ellerman, Michal Simek, Paul Mackerras
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>
The only PCI specific part of of_pci_range_parser_one() is the handling
of the 3rd address cell. Rework it to work on regular 1 and 2 cell
addresses.
Use defines and a union to avoid a treewide renaming of the parsing
helpers and struct.
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/of/address.c | 33 +++++++++++++++++++++------------
include/linux/of_address.h | 12 +++++++++---
2 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5d608d7c10d6..6d33f849f114 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -694,12 +694,12 @@ EXPORT_SYMBOL(of_get_address);
static int parser_init(struct of_pci_range_parser *parser,
struct device_node *node, const char *name)
{
- const int na = 3, ns = 2;
int rlen;
parser->node = node;
parser->pna = of_n_addr_cells(node);
- parser->np = parser->pna + na + ns;
+ parser->na = of_bus_n_addr_cells(node);
+ parser->ns = of_bus_n_size_cells(node);
parser->dma = !strcmp(name, "dma-ranges");
parser->range = of_get_property(node, name, &rlen);
@@ -724,20 +724,28 @@ int of_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
return parser_init(parser, node, "dma-ranges");
}
EXPORT_SYMBOL_GPL(of_pci_dma_range_parser_init);
+#define of_dma_range_parser_init of_pci_dma_range_parser_init
struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
struct of_pci_range *range)
{
- const int na = 3, ns = 2;
+ int na = parser->na;
+ int ns = parser->ns;
+ int np = parser->pna + na + ns;
if (!range)
return NULL;
- if (!parser->range || parser->range + parser->np > parser->end)
+ if (!parser->range || parser->range + np > parser->end)
return NULL;
- range->flags = of_bus_pci_get_flags(parser->range);
- range->pci_addr = of_read_number(parser->range + 1, ns);
+ if (parser->na == 3)
+ range->flags = of_bus_pci_get_flags(parser->range);
+ else
+ range->flags = 0;
+
+ range->pci_addr = of_read_number(parser->range, na);
+
if (parser->dma)
range->cpu_addr = of_translate_dma_address(parser->node,
parser->range + na);
@@ -746,15 +754,16 @@ struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
parser->range + na);
range->size = of_read_number(parser->range + parser->pna + na, ns);
- parser->range += parser->np;
+ parser->range += np;
/* Now consume following elements while they are contiguous */
- while (parser->range + parser->np <= parser->end) {
- u32 flags;
+ while (parser->range + np <= parser->end) {
+ u32 flags = 0;
u64 pci_addr, cpu_addr, size;
- flags = of_bus_pci_get_flags(parser->range);
- pci_addr = of_read_number(parser->range + 1, ns);
+ if (parser->na == 3)
+ flags = of_bus_pci_get_flags(parser->range);
+ pci_addr = of_read_number(parser->range, na);
if (parser->dma)
cpu_addr = of_translate_dma_address(parser->node,
parser->range + na);
@@ -770,7 +779,7 @@ struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
break;
range->size += size;
- parser->range += parser->np;
+ parser->range += np;
}
return range;
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 8d12bf18e80b..763022ed3456 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -10,20 +10,27 @@ struct of_pci_range_parser {
struct device_node *node;
const __be32 *range;
const __be32 *end;
- int np;
+ int na;
+ int ns;
int pna;
bool dma;
};
+#define of_range_parser of_pci_range_parser
struct of_pci_range {
- u64 pci_addr;
+ union {
+ u64 pci_addr;
+ u64 bus_addr;
+ };
u64 cpu_addr;
u64 size;
u32 flags;
};
+#define of_range of_pci_range
#define for_each_of_pci_range(parser, range) \
for (; of_pci_range_parser_one(parser, range);)
+#define for_each_of_range for_each_of_pci_range
/* Translate a DMA address from device space to CPU space */
extern u64 of_translate_dma_address(struct device_node *dev,
@@ -142,4 +149,3 @@ static inline int of_pci_range_to_resource(struct of_pci_range *range,
#endif /* CONFIG_OF_ADDRESS && CONFIG_PCI */
#endif /* __OF_ADDRESS_H */
-
--
2.20.1
^ permalink raw reply related
* [PATCH 7/7] of/address: Support multiple 'dma-ranges' entries
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
To: devicetree, Frank Rowand
Cc: linux-kernel, Linus Walleij, Robin Murphy, Christoph Hellwig,
Arnd Bergmann, Benjamin Herrenschmidt, linuxppc-dev,
Michael Ellerman, Michal Simek, Paul Mackerras
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>
Currently, the DMA offset and mask for a device are set based only on the
first 'dma-ranges' entry. We should really be using all the entries. The
kernel doesn't yet support multiple offsets and sizes, so the best we can
do is to find the biggest size for a single offset. The algorithm is
copied from acpi_dma_get_range().
If there's different offsets from the first entry, then we warn and
continue. It really should be an error, but this will likely break
existing DTs.
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/of/address.c | 28 ++++++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index a2c45812a50e..8eea3f6e29a4 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -944,6 +944,7 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
bool found_dma_ranges = false;
struct of_range_parser parser;
struct of_range range;
+ u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
while (node) {
ranges = of_get_property(node, "dma-ranges", &len);
@@ -974,14 +975,33 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
range.bus_addr, range.cpu_addr, range.size);
- *dma_addr = range.bus_addr;
- *paddr = range.cpu_addr;
- *size = range.size;
+ if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset) {
+ pr_warn("Can't handle multiple dma-ranges with different offsets on node(%pOF)\n", node);
+ /* Don't error out as we'd break some existing DTs */
+ continue;
+ }
+ dma_offset = range.cpu_addr - range.bus_addr;
+
+ /* Take lower and upper limits */
+ if (range.bus_addr < dma_start)
+ dma_start = range.bus_addr;
+ if (range.bus_addr + range.size > dma_end)
+ dma_end = range.bus_addr + range.size;
+ }
+ if (dma_start >= dma_end) {
+ ret = -EINVAL;
+ pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
+ node);
goto out;
}
- pr_err("translation of DMA ranges failed on node(%pOF)\n", np);
+ *dma_addr = dma_start;
+ *size = dma_end - dma_start;
+ *paddr = dma_start + dma_offset;
+
+ pr_debug("final: dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+ *dma_addr, *paddr, *size);
out:
of_node_put(node);
--
2.20.1
^ permalink raw reply related
* [PATCH 2/7] microblaze: Drop using struct of_pci_range.pci_space field
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
To: devicetree, Frank Rowand
Cc: linux-kernel, Linus Walleij, Robin Murphy, Christoph Hellwig,
Arnd Bergmann, Benjamin Herrenschmidt, linuxppc-dev,
Michael Ellerman, Michal Simek, Paul Mackerras
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>
Let's use the struct of_pci_range.flags field instead so we can remove
the pci_space field.
Just drop the debug prints as there's plenty of debug output in
drivers/of/address.c which can be enabled.
Cc: Michal Simek <monstr@monstr.eu>
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/microblaze/pci/pci-common.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 58cc4965bd3e..60a58c0015f2 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -433,10 +433,6 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
pr_debug("Parsing ranges property...\n");
for_each_of_pci_range(&parser, &range) {
/* Read next ranges element */
- pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
- range.pci_space, range.pci_addr);
- pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
- range.cpu_addr, range.size);
/* If we failed translation or got a zero-sized region
* (some FW try to feed us with non sensical zero sized regions
@@ -486,7 +482,7 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
range.cpu_addr, range.cpu_addr + range.size - 1,
range.pci_addr,
- (range.pci_space & 0x40000000) ?
+ (range.flags & IORESOURCE_PREFETCH) ?
"Prefetch" : "");
/* We support only 3 memory ranges */
@@ -1121,4 +1117,3 @@ int early_find_capability(struct pci_controller *hose, int bus, int devfn,
{
return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
}
-
--
2.20.1
^ permalink raw reply related
* [PATCH bpf] bpf: Do not grab the bucket spinlock by default on htab batch ops
From: Brian Vazquez @ 2020-02-14 22:43 UTC (permalink / raw)
To: Brian Vazquez, Brian Vazquez, Alexei Starovoitov, Daniel Borkmann,
David S . Miller
Cc: linux-kernel, netdev, bpf, Yonghong Song
Grabbing the spinlock for every bucket even if it's empty, was causing
significant perfomance cost when traversing htab maps that have only a
few entries. This patch addresses the issue by checking first the
bucket_cnt, if the bucket has some entries then we go and grab the
spinlock and proceed with the batching.
Tested with a htab of size 50K and different value of populated entries.
Before:
Benchmark Time(ns) CPU(ns)
---------------------------------------------
BM_DumpHashMap/1 2759655 2752033
BM_DumpHashMap/10 2933722 2930825
BM_DumpHashMap/200 3171680 3170265
BM_DumpHashMap/500 3639607 3635511
BM_DumpHashMap/1000 4369008 4364981
BM_DumpHashMap/5k 11171919 11134028
BM_DumpHashMap/20k 69150080 69033496
BM_DumpHashMap/39k 190501036 190226162
After:
Benchmark Time(ns) CPU(ns)
---------------------------------------------
BM_DumpHashMap/1 202707 200109
BM_DumpHashMap/10 213441 210569
BM_DumpHashMap/200 478641 472350
BM_DumpHashMap/500 980061 967102
BM_DumpHashMap/1000 1863835 1839575
BM_DumpHashMap/5k 8961836 8902540
BM_DumpHashMap/20k 69761497 69322756
BM_DumpHashMap/39k 187437830 186551111
Fixes: 057996380a42 ("bpf: Add batch ops to all htab bpf map")
Cc: Yonghong Song <yhs@fb.com>
Signed-off-by: Brian Vazquez <brianvv@google.com>
---
kernel/bpf/hashtab.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 2d182c4ee9d99..fdbde28b0fe06 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -1260,6 +1260,7 @@ __htab_map_lookup_and_delete_batch(struct bpf_map *map,
struct hlist_nulls_head *head;
struct hlist_nulls_node *n;
unsigned long flags;
+ bool locked = false;
struct htab_elem *l;
struct bucket *b;
int ret = 0;
@@ -1319,15 +1320,25 @@ __htab_map_lookup_and_delete_batch(struct bpf_map *map,
dst_val = values;
b = &htab->buckets[batch];
head = &b->head;
- raw_spin_lock_irqsave(&b->lock, flags);
+ /* do not grab the lock unless need it (bucket_cnt > 0). */
+ if (locked)
+ raw_spin_lock_irqsave(&b->lock, flags);
bucket_cnt = 0;
hlist_nulls_for_each_entry_rcu(l, n, head, hash_node)
bucket_cnt++;
+ if (bucket_cnt && !locked) {
+ locked = true;
+ goto again_nocopy;
+ }
+
if (bucket_cnt > (max_count - total)) {
if (total == 0)
ret = -ENOSPC;
+ /* Note that since bucket_cnt > 0 here, it is implicit
+ * that the locked was grabbed, so release it.
+ */
raw_spin_unlock_irqrestore(&b->lock, flags);
rcu_read_unlock();
this_cpu_dec(bpf_prog_active);
@@ -1337,6 +1348,9 @@ __htab_map_lookup_and_delete_batch(struct bpf_map *map,
if (bucket_cnt > bucket_size) {
bucket_size = bucket_cnt;
+ /* Note that since bucket_cnt > 0 here, it is implicit
+ * that the locked was grabbed, so release it.
+ */
raw_spin_unlock_irqrestore(&b->lock, flags);
rcu_read_unlock();
this_cpu_dec(bpf_prog_active);
@@ -1379,7 +1393,10 @@ __htab_map_lookup_and_delete_batch(struct bpf_map *map,
dst_val += value_size;
}
- raw_spin_unlock_irqrestore(&b->lock, flags);
+ if (locked) {
+ raw_spin_unlock_irqrestore(&b->lock, flags);
+ locked = false;
+ }
/* If we are not copying data, we can go to next bucket and avoid
* unlocking the rcu.
*/
--
2.25.0.265.gbab2e86ba0-goog
^ permalink raw reply related
* Nested submodule checkout
From: Damien Robert @ 2020-02-14 22:42 UTC (permalink / raw)
To: git
Dear git developers,
I stumbled into this situation from which it was a bit painful to recover:
-> test script:
mkdir ploum
cd ploum
git init
echo 'foo' > foo
git add foo
git commit -m foo
git branch nosubmodules
mkdir plam
cd plam
git init
echo 'bar' > bar
git add bar
git commit -m bar
mkdir plim
cd plim
git init
echo 'baz' > baz
git add baz
git commit -m baz
cd ..
git submodule add ./plim
git commit -am 'Add submodule plim'
cd ..
git submodule add ./plam
git commit -am 'Add submodule plam'
git checkout nosubmodules
git checkout --recurse-submodules master
-> The result is as follow:
Initialized empty Git repository in /data/dams/var/tmp/ploum/.git/
[master (root-commit) ec7c09a] foo
1 file changed, 1 insertion(+)
create mode 100644 foo
Branch 'nosubmodules' set up to track local branch 'master'.
Initialized empty Git repository in /data/dams/var/tmp/ploum/plam/.git/
[master (root-commit) 35e6696] bar
1 file changed, 1 insertion(+)
create mode 100644 bar
Initialized empty Git repository in /data/dams/var/tmp/ploum/plam/plim/.git/
[master (root-commit) b4712c1] baz
1 file changed, 1 insertion(+)
create mode 100644 baz
Adding existing repo at 'plim' to the index
[master 989c11d] Add submodule plim
2 files changed, 4 insertions(+)
create mode 100644 .gitmodules
create mode 160000 plim
Adding existing repo at 'plam' to the index
[master 5b34041] Add submodule plam
2 files changed, 4 insertions(+)
create mode 100644 .gitmodules
create mode 160000 plam
Migrating git directory of 'plam' from
'/data/dams/var/tmp/ploum/plam/.git' to
'/data/dams/var/tmp/ploum/.git/modules/plam'
Migrating git directory of 'plam/plim' from
'/data/dams/var/tmp/ploum/plam/plim/.git' to
'/data/dams/var/tmp/ploum/.git/modules/plam/modules/plim'
Switched to branch 'nosubmodules'
Your branch is behind 'master' by 1 commit, and can be fast-forwarded.
(use "git pull" to update your local branch)
fatal: exec '--super-prefix=plam/plim/': cd to 'plim' failed: No such file or directory
error: Submodule 'plim' could not be updated.
error: Submodule 'plam/plim' cannot checkout new HEAD.
error: Submodule 'plam' could not be updated.
M plam
Switched to branch 'master'
As you can see, the nested plim submodules could not be recreated since the
folder does not exists yet in the 'nosubmodules' branch. This makes the
'plam' submodule update fails, and in the following state
Unstaged changes after reset:
D .gitmodules
D bar
D plim
-> To recover
In the folder plam, do a `git reset` followed by a `git reset --hard`
(`git reset --hard` directly does not work:
fatal: exec '--super-prefix=plim/': cd to 'plim' failed: No such file or directory)
Indeed the first reset, which puts .gitmodules back in the index, is what
allows to do the `git submodule update` implied by `git reset --hard`.
Since (from what I understand) the path is only read from .gitmodules and
not from the .git/config (where there are only the submodules name which
are distinct from the path), this explain the failures observed.
Note that I wasn't able to reproduce in this small examples, but when
trying to repair I also add some strange errors of the form
'.git is not a git directory' (where .git was a pseudo symlink
gitdir: ../.git/modules/plam).
-> Question
My usage is probably non standard (I have quite a lot of nested
submodules), so I had a hard time to recover from this checkout. Is there a
better way? Would it be possible to make nested submodules checkout of this
form work out of the box?
Thanks!
Damien Robert
^ permalink raw reply
* Re: [PATCH v6 0/4] arm64: meson: add support for A1 Power Domains
From: patchwork-bot+linux-amlogic @ 2020-02-14 22:41 UTC (permalink / raw)
To: Jianxin Pan; +Cc: linux-amlogic, khilman
In-Reply-To: <1579087831-94965-1-git-send-email-jianxin.pan@amlogic.com>
Hello:
This series was applied to khilman/linux-amlogic.git (refs/heads/for-next).
On Wed, 15 Jan 2020 19:30:27 +0800 you wrote:
> This patchset introduces a "Secure Power Doamin Controller". In A1/C1, power
> controller registers such as PWRCTRL_FOCRSTN, PWRCTRL_PWR_OFF, PWRCTRL_MEM_PD
> and PWRCTRL_ISO_EN, are in the secure domain, and should be accessed from ATF
> by smc.
>
> The secure-pwrc will not be probed before the secure watchdog patchset is merged
> at [6], which adds of_platform_default_populate() in meson_sm_probe().
>
> [...]
Here is a summary with links:
- [v6,1/4] firmware: meson_sm: Add secure power domain support
https://git.kernel.org/khilman/linux-amlogic/c/fe98d0ff5d5c43ee179e801275bb37641d398c6e
- [v6,2/4] dt-bindings: power: add Amlogic secure power domains bindings
https://git.kernel.org/khilman/linux-amlogic/c/165b5fb294e878f00015b7beb91cb00e36e4f8b8
- [v6,3/4] soc: amlogic: Add support for Secure power domains controller
https://git.kernel.org/khilman/linux-amlogic/c/b3dde5013e13d44799b3477cd0bf0c9ad34fe5e9
- [v6,4/4] arm64: dts: meson: a1: add secure power domain controller
https://git.kernel.org/khilman/linux-amlogic/c/86e00420426cf6b040e71de5d9aa48c371e9b3b7
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/pwbot
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson-sm1-sei610: add missing interrupt-names
From: patchwork-bot+linux-amlogic @ 2020-02-14 22:41 UTC (permalink / raw)
To: Guillaume La Roque; +Cc: linux-amlogic, khilman
In-Reply-To: <20200117133423.22602-1-glaroque@baylibre.com>
Hello:
This patch was applied to khilman/linux-amlogic.git (refs/heads/for-next).
On Fri, 17 Jan 2020 14:34:23 +0100 you wrote:
> add missing "host-wakeup interrupt names
>
> Fixes: 30388cc07572 ("arm64: dts: meson-sm1-sei610: add gpio bluetooth interrupt")
>
> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts | 1 +
> 1 file changed, 1 insertion(+)
Here is a summary with links:
- arm64: dts: meson-sm1-sei610: add missing interrupt-names
https://git.kernel.org/khilman/linux-amlogic/c/80a26ed452811d04b2eeaba0481a72bf00f97b89
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/pwbot
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [Xen-devel] [PATCH 14/30] x86/xen: Add missing annotation for xen_pte_lock()
From: Boris Ostrovsky @ 2020-02-14 22:40 UTC (permalink / raw)
To: Jules Irenge, linux-kernel
Cc: Juergen Gross, Stefano Stabellini, boqun.feng,
maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT, Ingo Molnar,
Borislav Petkov, H. Peter Anvin,
moderated list:XEN HYPERVISOR INTERFACE, Thomas Gleixner
In-Reply-To: <20200214204741.94112-15-jbi.octave@gmail.com>
On 2/14/20 3:47 PM, Jules Irenge wrote:
> Sparse reports warning at xen_pte_lock()
>
> warning: context imbalance in xen_pte_lock() - wrong count at exit
>
> The root cause is the missing annotation at xen_pte_lock()
> Add the missing __acquires(ptl) annotation
>
> Signed-off-by: Jules Irenge <jbi.octave@gmail.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
although I'd prefer this and the next patch to be merged into a single one.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [Xen-devel] [PATCH 14/30] x86/xen: Add missing annotation for xen_pte_lock()
From: Boris Ostrovsky @ 2020-02-14 22:40 UTC (permalink / raw)
To: Jules Irenge, linux-kernel
Cc: Juergen Gross, Stefano Stabellini, boqun.feng,
maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT, Ingo Molnar,
Borislav Petkov, H. Peter Anvin,
moderated list:XEN HYPERVISOR INTERFACE, Thomas Gleixner
In-Reply-To: <20200214204741.94112-15-jbi.octave@gmail.com>
On 2/14/20 3:47 PM, Jules Irenge wrote:
> Sparse reports warning at xen_pte_lock()
>
> warning: context imbalance in xen_pte_lock() - wrong count at exit
>
> The root cause is the missing annotation at xen_pte_lock()
> Add the missing __acquires(ptl) annotation
>
> Signed-off-by: Jules Irenge <jbi.octave@gmail.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
although I'd prefer this and the next patch to be merged into a single one.
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.5 155/542] drm/amdkfd: remove set but not used variable 'top_dev'
From: Greg KH @ 2020-02-14 21:44 UTC (permalink / raw)
To: Sasha Levin
Cc: dri-devel, Felix Kuehling, linux-kernel, stable, zhengbin,
Hulk Robot, amd-gfx, Alex Deucher
In-Reply-To: <20200214154854.6746-155-sashal@kernel.org>
On Fri, Feb 14, 2020 at 10:42:27AM -0500, Sasha Levin wrote:
> From: zhengbin <zhengbin13@huawei.com>
>
> [ Upstream commit d191bd678153307573d615bb42da4fcca19fe477 ]
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdkfd/kfd_iommu.c: In function kfd_iommu_device_init:
> drivers/gpu/drm/amd/amdkfd/kfd_iommu.c:65:30: warning: variable top_dev set but not used [-Wunused-but-set-variable]
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: 1ae99eab34f9 ("drm/amdkfd: Initialize HSA_CAP_ATS_PRESENT capability in topology codes")
> Signed-off-by: zhengbin <zhengbin13@huawei.com>
> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
> Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 3 ---
> 1 file changed, 3 deletions(-)
Unless all of these "unused bt set variable" patches are needed for
"real" fixes, there's no need to add them here as we are NOT building
the kernel with that option enabled any time soon from what I can tell.
So you can drop a ton of these patches from all of these AUTOSEL
branches please.
thanks,
greg kh
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH v2] cgroup: memcg: net: do not associate sock with unrelated cgroup
From: Eric Dumazet @ 2020-02-14 22:38 UTC (permalink / raw)
To: Shakeel Butt
Cc: Johannes Weiner, Tejun Heo, Greg Thelen, Michal Hocko,
Vladimir Davydov, Andrew Morton, cgroups, linux-mm,
Roman Gushchin, LKML
In-Reply-To: <20200214222415.181467-1-shakeelb@google.com>
On Fri, Feb 14, 2020 at 2:24 PM Shakeel Butt <shakeelb@google.com> wrote:
>
> We are testing network memory accounting in our setup and noticed
> inconsistent network memory usage and often unrelated cgroups network
> usage correlates with testing workload. On further inspection, it
> seems like mem_cgroup_sk_alloc() and cgroup_sk_alloc() are broken in
> irq context specially for cgroup v1.
>
> mem_cgroup_sk_alloc() and cgroup_sk_alloc() can be called in irq context
> and kind of assumes that this can only happen from sk_clone_lock()
> and the source sock object has already associated cgroup. However in
> cgroup v1, where network memory accounting is opt-in, the source sock
> can be unassociated with any cgroup and the new cloned sock can get
> associated with unrelated interrupted cgroup.
>
> Cgroup v2 can also suffer if the source sock object was created by
> process in the root cgroup or if sk_alloc() is called in irq context.
> The fix is to just do nothing in interrupt.
So, when will the association be done ?
At accept() time ?
Is it done already ?
Thanks
>
> Fixes: 2d7580738345 ("mm: memcontrol: consolidate cgroup socket tracking")
> Fixes: d979a39d7242 ("cgroup: duplicate cgroup reference when cloning sockets")
> Signed-off-by: Shakeel Butt <shakeelb@google.com>
> ---
>
> Changes since v1:
> - Fix cgroup_sk_alloc() too.
>
> kernel/cgroup/cgroup.c | 4 ++++
> mm/memcontrol.c | 4 ++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 9a8a5ded3c48..46e5f5518fba 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -6449,6 +6449,10 @@ void cgroup_sk_alloc(struct sock_cgroup_data *skcd)
> return;
> }
>
> + /* Do not associate the sock with unrelated interrupted task's memcg. */
> + if (in_interrupt())
> + return;
> +
> rcu_read_lock();
>
> while (true) {
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 63bb6a2aab81..f500da82bfe8 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -6697,6 +6697,10 @@ void mem_cgroup_sk_alloc(struct sock *sk)
> return;
> }
>
> + /* Do not associate the sock with unrelated interrupted task's memcg. */
> + if (in_interrupt())
> + return;
> +
> rcu_read_lock();
> memcg = mem_cgroup_from_task(current);
> if (memcg == root_mem_cgroup)
> --
> 2.25.0.265.gbab2e86ba0-goog
>
^ permalink raw reply
* Re: [PATCH v2] cgroup: memcg: net: do not associate sock with unrelated cgroup
From: Eric Dumazet @ 2020-02-14 22:38 UTC (permalink / raw)
To: Shakeel Butt
Cc: Johannes Weiner, Tejun Heo, Greg Thelen, Michal Hocko,
Vladimir Davydov, Andrew Morton, cgroups-u79uwXL29TY76Z2rM5mHXA,
linux-mm, Roman Gushchin, LKML
In-Reply-To: <20200214222415.181467-1-shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Fri, Feb 14, 2020 at 2:24 PM Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>
> We are testing network memory accounting in our setup and noticed
> inconsistent network memory usage and often unrelated cgroups network
> usage correlates with testing workload. On further inspection, it
> seems like mem_cgroup_sk_alloc() and cgroup_sk_alloc() are broken in
> irq context specially for cgroup v1.
>
> mem_cgroup_sk_alloc() and cgroup_sk_alloc() can be called in irq context
> and kind of assumes that this can only happen from sk_clone_lock()
> and the source sock object has already associated cgroup. However in
> cgroup v1, where network memory accounting is opt-in, the source sock
> can be unassociated with any cgroup and the new cloned sock can get
> associated with unrelated interrupted cgroup.
>
> Cgroup v2 can also suffer if the source sock object was created by
> process in the root cgroup or if sk_alloc() is called in irq context.
> The fix is to just do nothing in interrupt.
So, when will the association be done ?
At accept() time ?
Is it done already ?
Thanks
>
> Fixes: 2d7580738345 ("mm: memcontrol: consolidate cgroup socket tracking")
> Fixes: d979a39d7242 ("cgroup: duplicate cgroup reference when cloning sockets")
> Signed-off-by: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> ---
>
> Changes since v1:
> - Fix cgroup_sk_alloc() too.
>
> kernel/cgroup/cgroup.c | 4 ++++
> mm/memcontrol.c | 4 ++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 9a8a5ded3c48..46e5f5518fba 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -6449,6 +6449,10 @@ void cgroup_sk_alloc(struct sock_cgroup_data *skcd)
> return;
> }
>
> + /* Do not associate the sock with unrelated interrupted task's memcg. */
> + if (in_interrupt())
> + return;
> +
> rcu_read_lock();
>
> while (true) {
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 63bb6a2aab81..f500da82bfe8 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -6697,6 +6697,10 @@ void mem_cgroup_sk_alloc(struct sock *sk)
> return;
> }
>
> + /* Do not associate the sock with unrelated interrupted task's memcg. */
> + if (in_interrupt())
> + return;
> +
> rcu_read_lock();
> memcg = mem_cgroup_from_task(current);
> if (memcg == root_mem_cgroup)
> --
> 2.25.0.265.gbab2e86ba0-goog
>
^ permalink raw reply
* [meta-python][PATCH] python3-cffi: consolidate inc and bb files into a single bb file
From: Derek Straka @ 2020-02-14 22:37 UTC (permalink / raw)
To: openembedded-devel
Signed-off-by: Derek Straka <derek@asterius.io>
---
.../recipes-devtools/python/python-cffi.inc | 17 -----------------
.../python/python3-cffi_1.13.2.bb | 19 ++++++++++++++++++-
2 files changed, 18 insertions(+), 18 deletions(-)
delete mode 100644 meta-python/recipes-devtools/python/python-cffi.inc
diff --git a/meta-python/recipes-devtools/python/python-cffi.inc b/meta-python/recipes-devtools/python/python-cffi.inc
deleted file mode 100644
index a2b0c3bb0c..0000000000
--- a/meta-python/recipes-devtools/python/python-cffi.inc
+++ /dev/null
@@ -1,17 +0,0 @@
-SUMMARY = "Foreign Function Interface for Python calling C code"
-HOMEPAGE = "http://cffi.readthedocs.org/"
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=5677e2fdbf7cdda61d6dd2b57df547bf"
-DEPENDS += "libffi ${PYTHON_PN}-pycparser"
-
-SRC_URI[md5sum] = "652203cf99faa254efff7fab23c2f3a2"
-SRC_URI[sha256sum] = "599a1e8ff057ac530c9ad1778293c665cb81a791421f46922d80a86473c13346"
-
-RDEPENDS_${PN}_class-target = " \
- ${PYTHON_PN}-ctypes \
- ${PYTHON_PN}-io \
- ${PYTHON_PN}-pycparser \
- ${PYTHON_PN}-shell \
-"
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-python/recipes-devtools/python/python3-cffi_1.13.2.bb b/meta-python/recipes-devtools/python/python3-cffi_1.13.2.bb
index e888084347..6156081126 100644
--- a/meta-python/recipes-devtools/python/python3-cffi_1.13.2.bb
+++ b/meta-python/recipes-devtools/python/python3-cffi_1.13.2.bb
@@ -1,2 +1,19 @@
+SUMMARY = "Foreign Function Interface for Python calling C code"
+HOMEPAGE = "http://cffi.readthedocs.org/"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=5677e2fdbf7cdda61d6dd2b57df547bf"
+DEPENDS += "libffi ${PYTHON_PN}-pycparser"
+
+SRC_URI[md5sum] = "652203cf99faa254efff7fab23c2f3a2"
+SRC_URI[sha256sum] = "599a1e8ff057ac530c9ad1778293c665cb81a791421f46922d80a86473c13346"
+
inherit pypi setuptools3
-require python-cffi.inc
+
+RDEPENDS_${PN}_class-target = " \
+ ${PYTHON_PN}-ctypes \
+ ${PYTHON_PN}-io \
+ ${PYTHON_PN}-pycparser \
+ ${PYTHON_PN}-shell \
+"
+
+BBCLASSEXTEND = "native nativesdk"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 4/5] common/rc: add quirks for fuse-overlayfs device/mount point
From: Amir Goldstein @ 2020-02-14 22:37 UTC (permalink / raw)
To: Mauricio Faria de Oliveira
Cc: fstests, overlayfs, Miklos Szeredi, Vivek Goyal
In-Reply-To: <20200214151848.8328-5-mfo@canonical.com>
On Fri, Feb 14, 2020 at 5:18 PM Mauricio Faria de Oliveira
<mfo@canonical.com> wrote:
>
> On fuse-overlayfs the mount device is always reported as
> a "fuse-overlayfs" string, instead of the parent directory
> of the mount point (the string expected by overlay/scripts).
>
> Unfortunately, it seems that the fuse mount option 'fsname'
> doesn't set the filesystem source/device on fuse-overlayfs,
> so the easy fix of just adding it to mount options is gone.
>
> So two quirks are used to check for a fuse-overlayfs mount,
> that checks the mount point/directory in _check_mounted_on()
> and init_rc(); latter with the new helper _fs_type_dev_dir().
>
> With this, fuse-overlayfs can now keep going through tests!
>
> Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com>
> ---
> README.overlay | 1 +
> common/rc | 19 ++++++++++++++++++-
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/README.overlay b/README.overlay
> index 08a39b8830c9..7ef07ae6bbab 100644
> --- a/README.overlay
> +++ b/README.overlay
> @@ -53,4 +53,5 @@ OVERLAY_FSCK_OPTIONS will be used to check both test and scratch overlay.
>
> To test other filesystem types (experimental) configure the OVL_FSTYP variable:
>
> + OVL_FSTYP=fuse.fuse-overlayfs
> OVL_FSTYP=aufs
> diff --git a/common/rc b/common/rc
> index 5711eca2a1d2..6a4cb9b6d604 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -1481,6 +1481,14 @@ _check_mounted_on()
>
> # find $dev as the source, and print result in "$dev $mnt" format
> local mount_rec=`findmnt -rncv -S $dev -o SOURCE,TARGET`
> +
> + # fuse-overlayfs dev is not $dev, check via $mnt.
> + if [ -z "$mount_rec" -a "$FSTYP" = "overlay" -a \
> + "$OVL_FSTYP" = "fuse.fuse-overlayfs" ]; then
> + dev="fuse-overlayfs"
> + mount_rec=`findmnt -rncv -S $dev -T $mnt -o SOURCE,TARGET`
> + fi
> +
I guess if we have to do the quirk then we better do it before the
first findmnt.
I don't see the point of trying the first time.
But I wonder, how come this is not also problem for virtiofs?
Maybe there is a way to make fuse fsname mount option work
instead of these quirks?
> [ -n "$mount_rec" ] || return 1 # 1 = not mounted
>
> # if it's mounted, make sure its on $mnt
> @@ -3788,8 +3796,17 @@ init_rc()
> fi
>
> # if $TEST_DEV is not mounted, mount it now as XFS
> - if [ -z "`_fs_type $TEST_DEV`" ]
> + if [ -n "`_fs_type $TEST_DEV`" ]
> then
> + # $TEST_DEV is mounted
> + true
> + elif [ "$FSTYP" = "overlay" -a "$OVL_FSTYP" = "fuse.fuse-overlayfs" -a \
> + -n "`_fs_type_dev_dir fuse-overlayfs $TEST_DEV/$OVL_MNT`" ]
Somewhat simplified:
elif [ "$OVL_FSTYP" = "fuse.fuse-overlayfs" -a \
-n "`_fs_type_dev_dir fuse-overlayfs $TEST_DIR`" ]
Thanks,
Amir.
^ permalink raw reply
* [meta-python][PATCH] python3-certifi: consolidate inc and bb files into a single bb file
From: Derek Straka @ 2020-02-14 22:35 UTC (permalink / raw)
To: openembedded-devel
Signed-off-by: Derek Straka <derek@asterius.io>
---
.../recipes-devtools/python/python-certifi.inc | 13 -------------
.../python/python3-certifi_2019.11.28.bb | 15 ++++++++++++++-
2 files changed, 14 insertions(+), 14 deletions(-)
delete mode 100644 meta-python/recipes-devtools/python/python-certifi.inc
diff --git a/meta-python/recipes-devtools/python/python-certifi.inc b/meta-python/recipes-devtools/python/python-certifi.inc
deleted file mode 100644
index 98fa1f2889..0000000000
--- a/meta-python/recipes-devtools/python/python-certifi.inc
+++ /dev/null
@@ -1,13 +0,0 @@
-SUMMARY = "Python package for providing Mozilla's CA Bundle."
-DESCRIPTION = "This installable Python package contains a CA Bundle that you can reference in your \
-Python code. This is useful for verifying HTTP requests, for example. This is the same CA Bundle \
-which ships with the Requests codebase, and is derived from Mozilla Firefox's canonical set."
-HOMEPAGE = " http://certifi.io/"
-
-LICENSE = "ISC"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=f77f61d14ee6feac4228d3ebd26cc1f1"
-
-SRC_URI[md5sum] = "4d5229c4d9f0a4a79106f9e2c2cfd381"
-SRC_URI[sha256sum] = "25b64c7da4cd7479594d035c08c2d809eb4aab3a26e5a990ea98cc450c320f1f"
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-python/recipes-devtools/python/python3-certifi_2019.11.28.bb b/meta-python/recipes-devtools/python/python3-certifi_2019.11.28.bb
index 70f674b22c..c9e945f271 100644
--- a/meta-python/recipes-devtools/python/python3-certifi_2019.11.28.bb
+++ b/meta-python/recipes-devtools/python/python3-certifi_2019.11.28.bb
@@ -1,2 +1,15 @@
+SUMMARY = "Python package for providing Mozilla's CA Bundle."
+DESCRIPTION = "This installable Python package contains a CA Bundle that you can reference in your \
+Python code. This is useful for verifying HTTP requests, for example. This is the same CA Bundle \
+which ships with the Requests codebase, and is derived from Mozilla Firefox's canonical set."
+HOMEPAGE = " http://certifi.io/"
+
+LICENSE = "ISC"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=f77f61d14ee6feac4228d3ebd26cc1f1"
+
+SRC_URI[md5sum] = "4d5229c4d9f0a4a79106f9e2c2cfd381"
+SRC_URI[sha256sum] = "25b64c7da4cd7479594d035c08c2d809eb4aab3a26e5a990ea98cc450c320f1f"
+
inherit pypi setuptools3
-require python-certifi.inc
+
+BBCLASSEXTEND = "native nativesdk"
--
2.17.1
^ permalink raw reply related
* [PATCH 1/1] efi_loader: EFI_RNG_PROTOCOL
From: Heinrich Schuchardt @ 2020-02-14 22:34 UTC (permalink / raw)
To: u-boot
Do not use quotation marks for Kconfig help text.
Replace rng abbreviation by full words.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
lib/efi_loader/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index a7afa3f29e..84a4a35d80 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -127,7 +127,7 @@ config EFI_RNG_PROTOCOL
bool "EFI_RNG_PROTOCOL support"
depends on DM_RNG
help
- "Support for EFI_RNG_PROTOCOL implementation. Uses the rng
- device on the platform"
+ Provide a EFI_RNG_PROTOCOL implementation using the hardware random
+ number generator of the platform.
endif
--
2.25.0
^ permalink raw reply related
* [meta-python][PATCH] python3-cassandra-driver: consolidate inc and bb files into a single bb file
From: Derek Straka @ 2020-02-14 22:33 UTC (permalink / raw)
To: openembedded-devel
Signed-off-by: Derek Straka <derek@asterius.io>
---
.../python/python-cassandra-driver.inc | 33 -----------------
.../python/python3-cassandra-driver_3.14.0.bb | 35 ++++++++++++++++---
2 files changed, 31 insertions(+), 37 deletions(-)
delete mode 100644 meta-python/recipes-devtools/python/python-cassandra-driver.inc
diff --git a/meta-python/recipes-devtools/python/python-cassandra-driver.inc b/meta-python/recipes-devtools/python/python-cassandra-driver.inc
deleted file mode 100644
index 53ebfec337..0000000000
--- a/meta-python/recipes-devtools/python/python-cassandra-driver.inc
+++ /dev/null
@@ -1,33 +0,0 @@
-SUMMARY = "DataStax Python Driver for Apache Cassandra"
-DESCRIPTION = "A modern, feature-rich and highly-tunable Python client \
-library for Apache Cassandra (1.2+) and DataStax Enterprise (3.1+) using \
-exclusively Cassandra's binary protocol and Cassandra Query Language v3."
-HOMEPAGE = "https://github.com/datastax/python-driver"
-SECTION = "devel/python"
-LICENSE = "Apache-2.0"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=2ee41112a44fe7014dce33e26468ba93"
-SRCNAME = "cassandra-driver"
-
-SRC_URI[md5sum] = "c5bed026bf48c821424c1f6296193908"
-SRC_URI[sha256sum] = "b65218e2582277f5b77d1436e420db8616f63e3437a9e839cdcd7172d760e861"
-
-DISTUTILS_BUILD_ARGS += " \
- --no-libev \
-"
-DISTUTILS_INSTALL_ARGS += " \
- --no-libev \
-"
-
-inherit pypi
-
-RDEPENDS_${PN} += "\
- ${PYTHON_PN}-cython \
- ${PYTHON_PN}-multiprocessing \
- ${PYTHON_PN}-six \
- ${PYTHON_PN}-json \
- libevent \
-"
-
-DEPENDS += "\
- ${PYTHON_PN}-cython \
-"
diff --git a/meta-python/recipes-devtools/python/python3-cassandra-driver_3.14.0.bb b/meta-python/recipes-devtools/python/python3-cassandra-driver_3.14.0.bb
index 34f149d3f5..768e557b94 100644
--- a/meta-python/recipes-devtools/python/python3-cassandra-driver_3.14.0.bb
+++ b/meta-python/recipes-devtools/python/python3-cassandra-driver_3.14.0.bb
@@ -1,8 +1,35 @@
-inherit setuptools3
-require python-cassandra-driver.inc
+SUMMARY = "DataStax Python Driver for Apache Cassandra"
+DESCRIPTION = "A modern, feature-rich and highly-tunable Python client \
+library for Apache Cassandra (1.2+) and DataStax Enterprise (3.1+) using \
+exclusively Cassandra's binary protocol and Cassandra Query Language v3."
+HOMEPAGE = "https://github.com/datastax/python-driver"
+SECTION = "devel/python"
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=2ee41112a44fe7014dce33e26468ba93"
+SRCNAME = "cassandra-driver"
-# Requires concurrent which is currently in -misc
-RDEPENDS_${PN} += " \
+SRC_URI[md5sum] = "c5bed026bf48c821424c1f6296193908"
+SRC_URI[sha256sum] = "b65218e2582277f5b77d1436e420db8616f63e3437a9e839cdcd7172d760e861"
+
+DISTUTILS_BUILD_ARGS += " \
+ --no-libev \
+"
+DISTUTILS_INSTALL_ARGS += " \
+ --no-libev \
+"
+
+inherit pypi setuptools3
+
+RDEPENDS_${PN} += "\
+ ${PYTHON_PN}-cython \
+ ${PYTHON_PN}-json \
${PYTHON_PN}-misc \
+ ${PYTHON_PN}-multiprocessing \
${PYTHON_PN}-numbers \
+ ${PYTHON_PN}-six \
+ libevent \
+"
+
+DEPENDS += "\
+ ${PYTHON_PN}-cython \
"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2] cgroup: memcg: net: do not associate sock with unrelated cgroup
From: Roman Gushchin @ 2020-02-14 22:33 UTC (permalink / raw)
To: Shakeel Butt
Cc: Johannes Weiner, Eric Dumazet, Tejun Heo, Greg Thelen,
Michal Hocko, Vladimir Davydov, Andrew Morton, cgroups, linux-mm,
linux-kernel
In-Reply-To: <20200214222415.181467-1-shakeelb@google.com>
On Fri, Feb 14, 2020 at 02:24:15PM -0800, Shakeel Butt wrote:
> We are testing network memory accounting in our setup and noticed
> inconsistent network memory usage and often unrelated cgroups network
> usage correlates with testing workload. On further inspection, it
> seems like mem_cgroup_sk_alloc() and cgroup_sk_alloc() are broken in
> irq context specially for cgroup v1.
>
> mem_cgroup_sk_alloc() and cgroup_sk_alloc() can be called in irq context
> and kind of assumes that this can only happen from sk_clone_lock()
> and the source sock object has already associated cgroup. However in
> cgroup v1, where network memory accounting is opt-in, the source sock
> can be unassociated with any cgroup and the new cloned sock can get
> associated with unrelated interrupted cgroup.
>
> Cgroup v2 can also suffer if the source sock object was created by
> process in the root cgroup or if sk_alloc() is called in irq context.
> The fix is to just do nothing in interrupt.
>
> Fixes: 2d7580738345 ("mm: memcontrol: consolidate cgroup socket tracking")
> Fixes: d979a39d7242 ("cgroup: duplicate cgroup reference when cloning sockets")
> Signed-off-by: Shakeel Butt <shakeelb@google.com>
> ---
>
> Changes since v1:
> - Fix cgroup_sk_alloc() too.
>
> kernel/cgroup/cgroup.c | 4 ++++
> mm/memcontrol.c | 4 ++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index 9a8a5ded3c48..46e5f5518fba 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -6449,6 +6449,10 @@ void cgroup_sk_alloc(struct sock_cgroup_data *skcd)
> return;
> }
>
> + /* Do not associate the sock with unrelated interrupted task's memcg. */
^^^^^
cgroup?
> + if (in_interrupt())
> + return;
> +
> rcu_read_lock();
>
> while (true) {
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 63bb6a2aab81..f500da82bfe8 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -6697,6 +6697,10 @@ void mem_cgroup_sk_alloc(struct sock *sk)
> return;
> }
Can you, please, include the stacktrace into the commit log?
Except a minor typo (see above),
Reviewed-by: Roman Gushchin <guro@fb.com>
A really good catch.
Thank you!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.