* Re: [PATCH 06/14] format-patch: allow --interdiff to apply to a lone-patch
From: Eric Sunshine @ 2018-07-23 19:46 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: Git List, Johannes Schindelin,
Ævar Arnfjörð Bjarmason, Stefan Beller
In-Reply-To: <CACsJy8Aw6R8-3kDfhCqunXziajCg9O_1WrEYc4rfKa+-=m1D5g@mail.gmail.com>
On Mon, Jul 23, 2018 at 12:22 PM Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Jul 22, 2018 at 11:58 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > + if (cmit_fmt_is_mail(ctx.fmt) && opt->idiff_oid1) {
>
> OK putting idiff stuff in rev_info is probably the right choice. But
> we all three fields prefixed with idiff_, maybe you could just add a
> new struct "idiff_options" to contain them and add a pointer to that
> struct in rev_info. Then "opt->idiff" is enough to know if idiff is
> requested instead of relying on idiff_oid1 (seems too random).
I have mixed feelings about this suggestion for the following reasons:
* 'struct rev_info' already contains a number of specialized fields
which apply in only certain use cases but not others, and those fields
often are grouped textually to show relationship rather than being
bundled in a struct.
* These new fields are very specific to this particular operation and
are unlikely to ever have wider use, so adding the extra level of
indirection/abstraction (whatever you'd call it) feels overkill and,
while nice theoretically, adds complexity without much practical
value.
* Bundling these fields in a struct might incorrectly imply to readers
that these items, collectively, can be used in some general-purpose
fashion, which isn't at all the case; they are very specific to this
operation and that struct would never be used elsewhere or for any
other purpose.
The upside of bundling them in a struct, as you mention, is that
"opt->idiff" would be slightly more obvious than "opt->idiff_oid1" as
a "should we print an interdiff?" conditional. On the other hand, this
case is so specific and narrow that I'm not sure it warrants such
generality.
^ permalink raw reply
* (no subject)
From: Marc Eshel @ 2018-07-23 18:43 UTC (permalink / raw)
To: Bruce Fields
Cc: Libtirpc-devel Mailing List, Linux NFS Mailing list,
linux-nfs-owner
In-Reply-To: <20180711152521.8238-1-steved@redhat.com>
Hi Bruce,
Do you know of any plans to add IETF RFC 8276 - File System Extended
Attributes in NFSv4 to the Linux NFS Client or Server?
Marc.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH for-3.0] tests/libqtest: Improve kill_qemu() assert
From: Eric Blake @ 2018-07-23 19:46 UTC (permalink / raw)
To: Peter Maydell
Cc: QEMU Developers, Michael S . Tsirkin, Richard Henderson,
Alex Bennée, Philippe Mathieu-Daudé, patches@linaro.org
In-Reply-To: <CAFEAcA-v_ntRi9rvAHP8_S+y45T5u02TVY4KdFVii6u6QJi=yg@mail.gmail.com>
On 07/23/2018 02:02 PM, Peter Maydell wrote:
> On 23 July 2018 at 19:59, Eric Blake <eblake@redhat.com> wrote:
>> In other words, why are we special-casing death-by-coredump, when ALL
>> non-zero exit status (whether or not a core dump was involved) is contrary
>> to the assumptions of the testsuite?
>
> Because we're trying to get as much actual information
> as we have out into the logs, not merely "die so the test
> fails"...
Fair enough; so I posted a v2 based on your starting point:
https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg04438.html
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* Re: rte_mbuf library likely()/unlikely()
From: Stephen Hemminger @ 2018-07-23 19:45 UTC (permalink / raw)
To: Morten Brørup; +Cc: Olivier Matz, dev
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B421F0@smartserver.smartshare.dk>
On Mon, 23 Jul 2018 20:59:29 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Monday, July 23, 2018 7:38 PM
> > To: Morten Brørup
> > Cc: Olivier Matz; dev@dpdk.org
> > Subject: Re: [dpdk-dev] rte_mbuf library likely()/unlikely()
> >
> > On Mon, 23 Jul 2018 15:53:42 +0200
> > Morten Brørup <mb@smartsharesystems.com> wrote:
> >
> > > Hi Olivier,
> > >
> > >
> > >
> > > I noticed that __rte_pktmbuf_read() could do with an unlikely(), so I
> > went through the entire library. Here are my suggested modifications.
> > >
> > >
> > >
> > >
> > >
> > > diff -bu rte_mbuf.c.orig rte_mbuf.c
> > >
> > > --- rte_mbuf.c.orig 2018-07-23 15:13:22.000000000 +0200
> > >
> > > +++ rte_mbuf.c 2018-07-23 15:32:53.000000000 +0200
> > >
> > > @@ -173,19 +173,19 @@
> > >
> > > {
> > >
> > > unsigned int nb_segs, pkt_len;
> > >
> > >
> > >
> > > - if (m == NULL)
> > >
> > > + if (unlikely(m == NULL))
> > >
> > > rte_panic("mbuf is NULL\n");
> > >
> > >
> >
> > Adding is unlikely is not necessary since rte_panic is marked with cold
> > attribute
> > which has the same effect.
>
> I was not aware of this. Although it is not visible from the source code files using rte_panic(), it probably means we shouldn't as so much as I thought. Here's an updated patch for rte_mbuf.c, where it is relevant. The other two suggested patches are unaffected.
>
> diff -bu rte_mbuf.c.orig rte_mbuf.c
> --- rte_mbuf.c.orig 2018-07-23 15:13:22.000000000 +0200
> +++ rte_mbuf.c 2018-07-23 20:52:35.000000000 +0200
> @@ -249,7 +249,7 @@
> const struct rte_mbuf *seg = m;
> uint32_t buf_off = 0, copy_len;
>
> - if (off + len > rte_pktmbuf_pkt_len(m))
> + if (unlikely(off + len > rte_pktmbuf_pkt_len(m)))
> return NULL;
>
> while (off >= rte_pktmbuf_data_len(seg)) {
> @@ -257,7 +257,7 @@
> seg = seg->next;
> }
>
> - if (off + len <= rte_pktmbuf_data_len(seg))
> + if (likely(off + len <= rte_pktmbuf_data_len(seg)))
> return rte_pktmbuf_mtod_offset(seg, char *, off);
>
> /* rare case: header is split among several segments */
> @@ -344,7 +344,7 @@
> unsigned int i;
> int ret;
>
> - if (buflen == 0)
> + if (unlikely(buflen == 0))
> return -1;
>
> buf[0] = '\0';
> @@ -355,9 +355,9 @@
> if (name == NULL)
> name = rx_flags[i].default_name;
> ret = snprintf(buf, buflen, "%s ", name);
> - if (ret < 0)
> + if (unlikely(ret < 0))
> return -1;
> - if ((size_t)ret >= buflen)
> + if (unlikely((size_t)ret >= buflen))
> return -1;
> buf += ret;
> buflen -= ret;
> @@ -440,7 +440,7 @@
> unsigned int i;
> int ret;
>
> - if (buflen == 0)
> + if (unlikely(buflen == 0))
> return -1;
>
> buf[0] = '\0';
> @@ -451,9 +451,9 @@
> if (name == NULL)
> name = tx_flags[i].default_name;
> ret = snprintf(buf, buflen, "%s ", name);
> - if (ret < 0)
> + if (unlikely(ret < 0))
> return -1;
> - if ((size_t)ret >= buflen)
> + if (unlikely((size_t)ret >= buflen))
> return -1;
> buf += ret;
> buflen -= ret;
>
>
> Med venlig hilsen / kind regards
> - Morten Brørup
Yes, this makes sense.
Please format patch with signed-off-by and submit according to
the contributing guidelines Creating Patches section.
https://doc.dpdk.org/guides/contributing/patches.html
^ permalink raw reply
* [Qemu-devel] [PULL 1/1] i386: Rename enum CacheType members
From: Eduardo Habkost @ 2018-07-23 19:45 UTC (permalink / raw)
To: Peter Maydell, qemu-devel
Cc: Paolo Bonzini, Eduardo Habkost, Marcel Apfelbaum,
Michael S. Tsirkin, Richard Henderson
In-Reply-To: <20180723194521.26831-1-ehabkost@redhat.com>
Rename DCACHE to DATA_CACHE and ICACHE to INSTRUCTION_CACHE.
This avoids conflict with Linux asm/cachectl.h macros and fixes
build failure on mips hosts.
Reported-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20180717194010.30096-1-ehabkost@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Acked-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Reviewed-by: Babu Moger <babu.moger@amd.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
target/i386/cpu.h | 4 +-
target/i386/cpu.c | 128 +++++++++++++++++++++++-----------------------
2 files changed, 66 insertions(+), 66 deletions(-)
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 2c5a0d90a6..194e2e6b92 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1050,8 +1050,8 @@ typedef enum TPRAccess {
/* Cache information data structures: */
enum CacheType {
- DCACHE,
- ICACHE,
+ DATA_CACHE,
+ INSTRUCTION_CACHE,
UNIFIED_CACHE
};
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index e0e2f2eea1..f454d4beb3 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -71,123 +71,123 @@ struct CPUID2CacheDescriptorInfo {
* From Intel SDM Volume 2A, CPUID instruction
*/
struct CPUID2CacheDescriptorInfo cpuid2_cache_descriptors[] = {
- [0x06] = { .level = 1, .type = ICACHE, .size = 8 * KiB,
+ [0x06] = { .level = 1, .type = INSTRUCTION_CACHE, .size = 8 * KiB,
.associativity = 4, .line_size = 32, },
- [0x08] = { .level = 1, .type = ICACHE, .size = 16 * KiB,
+ [0x08] = { .level = 1, .type = INSTRUCTION_CACHE, .size = 16 * KiB,
.associativity = 4, .line_size = 32, },
- [0x09] = { .level = 1, .type = ICACHE, .size = 32 * KiB,
+ [0x09] = { .level = 1, .type = INSTRUCTION_CACHE, .size = 32 * KiB,
.associativity = 4, .line_size = 64, },
- [0x0A] = { .level = 1, .type = DCACHE, .size = 8 * KiB,
+ [0x0A] = { .level = 1, .type = DATA_CACHE, .size = 8 * KiB,
.associativity = 2, .line_size = 32, },
- [0x0C] = { .level = 1, .type = DCACHE, .size = 16 * KiB,
+ [0x0C] = { .level = 1, .type = DATA_CACHE, .size = 16 * KiB,
.associativity = 4, .line_size = 32, },
- [0x0D] = { .level = 1, .type = DCACHE, .size = 16 * KiB,
+ [0x0D] = { .level = 1, .type = DATA_CACHE, .size = 16 * KiB,
.associativity = 4, .line_size = 64, },
- [0x0E] = { .level = 1, .type = DCACHE, .size = 24 * KiB,
+ [0x0E] = { .level = 1, .type = DATA_CACHE, .size = 24 * KiB,
.associativity = 6, .line_size = 64, },
- [0x1D] = { .level = 2, .type = UNIFIED_CACHE, .size = 128 * KiB,
+ [0x1D] = { .level = 2, .type = UNIFIED_CACHE, .size = 128 * KiB,
.associativity = 2, .line_size = 64, },
- [0x21] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
+ [0x21] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
.associativity = 8, .line_size = 64, },
/* lines per sector is not supported cpuid2_cache_descriptor(),
* so descriptors 0x22, 0x23 are not included
*/
- [0x24] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ [0x24] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
.associativity = 16, .line_size = 64, },
/* lines per sector is not supported cpuid2_cache_descriptor(),
* so descriptors 0x25, 0x20 are not included
*/
- [0x2C] = { .level = 1, .type = DCACHE, .size = 32 * KiB,
+ [0x2C] = { .level = 1, .type = DATA_CACHE, .size = 32 * KiB,
.associativity = 8, .line_size = 64, },
- [0x30] = { .level = 1, .type = ICACHE, .size = 32 * KiB,
+ [0x30] = { .level = 1, .type = INSTRUCTION_CACHE, .size = 32 * KiB,
.associativity = 8, .line_size = 64, },
- [0x41] = { .level = 2, .type = UNIFIED_CACHE, .size = 128 * KiB,
+ [0x41] = { .level = 2, .type = UNIFIED_CACHE, .size = 128 * KiB,
.associativity = 4, .line_size = 32, },
- [0x42] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
+ [0x42] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
.associativity = 4, .line_size = 32, },
- [0x43] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ [0x43] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
.associativity = 4, .line_size = 32, },
- [0x44] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ [0x44] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
.associativity = 4, .line_size = 32, },
- [0x45] = { .level = 2, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ [0x45] = { .level = 2, .type = UNIFIED_CACHE, .size = 2 * MiB,
.associativity = 4, .line_size = 32, },
- [0x46] = { .level = 3, .type = UNIFIED_CACHE, .size = 4 * MiB,
+ [0x46] = { .level = 3, .type = UNIFIED_CACHE, .size = 4 * MiB,
.associativity = 4, .line_size = 64, },
- [0x47] = { .level = 3, .type = UNIFIED_CACHE, .size = 8 * MiB,
+ [0x47] = { .level = 3, .type = UNIFIED_CACHE, .size = 8 * MiB,
.associativity = 8, .line_size = 64, },
- [0x48] = { .level = 2, .type = UNIFIED_CACHE, .size = 3 * MiB,
+ [0x48] = { .level = 2, .type = UNIFIED_CACHE, .size = 3 * MiB,
.associativity = 12, .line_size = 64, },
/* Descriptor 0x49 depends on CPU family/model, so it is not included */
- [0x4A] = { .level = 3, .type = UNIFIED_CACHE, .size = 6 * MiB,
+ [0x4A] = { .level = 3, .type = UNIFIED_CACHE, .size = 6 * MiB,
.associativity = 12, .line_size = 64, },
- [0x4B] = { .level = 3, .type = UNIFIED_CACHE, .size = 8 * MiB,
+ [0x4B] = { .level = 3, .type = UNIFIED_CACHE, .size = 8 * MiB,
.associativity = 16, .line_size = 64, },
- [0x4C] = { .level = 3, .type = UNIFIED_CACHE, .size = 12 * MiB,
+ [0x4C] = { .level = 3, .type = UNIFIED_CACHE, .size = 12 * MiB,
.associativity = 12, .line_size = 64, },
- [0x4D] = { .level = 3, .type = UNIFIED_CACHE, .size = 16 * MiB,
+ [0x4D] = { .level = 3, .type = UNIFIED_CACHE, .size = 16 * MiB,
.associativity = 16, .line_size = 64, },
- [0x4E] = { .level = 2, .type = UNIFIED_CACHE, .size = 6 * MiB,
+ [0x4E] = { .level = 2, .type = UNIFIED_CACHE, .size = 6 * MiB,
.associativity = 24, .line_size = 64, },
- [0x60] = { .level = 1, .type = DCACHE, .size = 16 * KiB,
+ [0x60] = { .level = 1, .type = DATA_CACHE, .size = 16 * KiB,
.associativity = 8, .line_size = 64, },
- [0x66] = { .level = 1, .type = DCACHE, .size = 8 * KiB,
+ [0x66] = { .level = 1, .type = DATA_CACHE, .size = 8 * KiB,
.associativity = 4, .line_size = 64, },
- [0x67] = { .level = 1, .type = DCACHE, .size = 16 * KiB,
+ [0x67] = { .level = 1, .type = DATA_CACHE, .size = 16 * KiB,
.associativity = 4, .line_size = 64, },
- [0x68] = { .level = 1, .type = DCACHE, .size = 32 * KiB,
+ [0x68] = { .level = 1, .type = DATA_CACHE, .size = 32 * KiB,
.associativity = 4, .line_size = 64, },
- [0x78] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ [0x78] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
.associativity = 4, .line_size = 64, },
/* lines per sector is not supported cpuid2_cache_descriptor(),
* so descriptors 0x79, 0x7A, 0x7B, 0x7C are not included.
*/
- [0x7D] = { .level = 2, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ [0x7D] = { .level = 2, .type = UNIFIED_CACHE, .size = 2 * MiB,
.associativity = 8, .line_size = 64, },
- [0x7F] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ [0x7F] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
.associativity = 2, .line_size = 64, },
- [0x80] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ [0x80] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
.associativity = 8, .line_size = 64, },
- [0x82] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
+ [0x82] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
.associativity = 8, .line_size = 32, },
- [0x83] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ [0x83] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
.associativity = 8, .line_size = 32, },
- [0x84] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ [0x84] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
.associativity = 8, .line_size = 32, },
- [0x85] = { .level = 2, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ [0x85] = { .level = 2, .type = UNIFIED_CACHE, .size = 2 * MiB,
.associativity = 8, .line_size = 32, },
- [0x86] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ [0x86] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
.associativity = 4, .line_size = 64, },
- [0x87] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ [0x87] = { .level = 2, .type = UNIFIED_CACHE, .size = 1 * MiB,
.associativity = 8, .line_size = 64, },
- [0xD0] = { .level = 3, .type = UNIFIED_CACHE, .size = 512 * KiB,
+ [0xD0] = { .level = 3, .type = UNIFIED_CACHE, .size = 512 * KiB,
.associativity = 4, .line_size = 64, },
- [0xD1] = { .level = 3, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ [0xD1] = { .level = 3, .type = UNIFIED_CACHE, .size = 1 * MiB,
.associativity = 4, .line_size = 64, },
- [0xD2] = { .level = 3, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ [0xD2] = { .level = 3, .type = UNIFIED_CACHE, .size = 2 * MiB,
.associativity = 4, .line_size = 64, },
- [0xD6] = { .level = 3, .type = UNIFIED_CACHE, .size = 1 * MiB,
+ [0xD6] = { .level = 3, .type = UNIFIED_CACHE, .size = 1 * MiB,
.associativity = 8, .line_size = 64, },
- [0xD7] = { .level = 3, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ [0xD7] = { .level = 3, .type = UNIFIED_CACHE, .size = 2 * MiB,
.associativity = 8, .line_size = 64, },
- [0xD8] = { .level = 3, .type = UNIFIED_CACHE, .size = 4 * MiB,
+ [0xD8] = { .level = 3, .type = UNIFIED_CACHE, .size = 4 * MiB,
.associativity = 8, .line_size = 64, },
- [0xDC] = { .level = 3, .type = UNIFIED_CACHE, .size = 1.5 * MiB,
+ [0xDC] = { .level = 3, .type = UNIFIED_CACHE, .size = 1.5 * MiB,
.associativity = 12, .line_size = 64, },
- [0xDD] = { .level = 3, .type = UNIFIED_CACHE, .size = 3 * MiB,
+ [0xDD] = { .level = 3, .type = UNIFIED_CACHE, .size = 3 * MiB,
.associativity = 12, .line_size = 64, },
- [0xDE] = { .level = 3, .type = UNIFIED_CACHE, .size = 6 * MiB,
+ [0xDE] = { .level = 3, .type = UNIFIED_CACHE, .size = 6 * MiB,
.associativity = 12, .line_size = 64, },
- [0xE2] = { .level = 3, .type = UNIFIED_CACHE, .size = 2 * MiB,
+ [0xE2] = { .level = 3, .type = UNIFIED_CACHE, .size = 2 * MiB,
.associativity = 16, .line_size = 64, },
- [0xE3] = { .level = 3, .type = UNIFIED_CACHE, .size = 4 * MiB,
+ [0xE3] = { .level = 3, .type = UNIFIED_CACHE, .size = 4 * MiB,
.associativity = 16, .line_size = 64, },
- [0xE4] = { .level = 3, .type = UNIFIED_CACHE, .size = 8 * MiB,
+ [0xE4] = { .level = 3, .type = UNIFIED_CACHE, .size = 8 * MiB,
.associativity = 16, .line_size = 64, },
- [0xEA] = { .level = 3, .type = UNIFIED_CACHE, .size = 12 * MiB,
+ [0xEA] = { .level = 3, .type = UNIFIED_CACHE, .size = 12 * MiB,
.associativity = 24, .line_size = 64, },
- [0xEB] = { .level = 3, .type = UNIFIED_CACHE, .size = 18 * MiB,
+ [0xEB] = { .level = 3, .type = UNIFIED_CACHE, .size = 18 * MiB,
.associativity = 24, .line_size = 64, },
- [0xEC] = { .level = 3, .type = UNIFIED_CACHE, .size = 24 * MiB,
+ [0xEC] = { .level = 3, .type = UNIFIED_CACHE, .size = 24 * MiB,
.associativity = 24, .line_size = 64, },
};
@@ -238,10 +238,10 @@ static uint8_t cpuid2_cache_descriptor(CPUCacheInfo *cache)
#define CACHE_COMPLEX_IDX (1 << 2)
/* Encode CacheType for CPUID[4].EAX */
-#define CACHE_TYPE(t) (((t) == DCACHE) ? CACHE_TYPE_D : \
- ((t) == ICACHE) ? CACHE_TYPE_I : \
- ((t) == UNIFIED_CACHE) ? CACHE_TYPE_UNIFIED : \
- 0 /* Invalid value */)
+#define CACHE_TYPE(t) (((t) == DATA_CACHE) ? CACHE_TYPE_D : \
+ ((t) == INSTRUCTION_CACHE) ? CACHE_TYPE_I : \
+ ((t) == UNIFIED_CACHE) ? CACHE_TYPE_UNIFIED : \
+ 0 /* Invalid value */)
/* Encode cache info for CPUID[4] */
@@ -538,7 +538,7 @@ static void encode_topo_cpuid8000001e(CPUState *cs, X86CPU *cpu,
/* L1 data cache: */
static CPUCacheInfo legacy_l1d_cache = {
- .type = DCACHE,
+ .type = DATA_CACHE,
.level = 1,
.size = 32 * KiB,
.self_init = 1,
@@ -551,7 +551,7 @@ static CPUCacheInfo legacy_l1d_cache = {
/*FIXME: CPUID leaf 0x80000005 is inconsistent with leaves 2 & 4 */
static CPUCacheInfo legacy_l1d_cache_amd = {
- .type = DCACHE,
+ .type = DATA_CACHE,
.level = 1,
.size = 64 * KiB,
.self_init = 1,
@@ -565,7 +565,7 @@ static CPUCacheInfo legacy_l1d_cache_amd = {
/* L1 instruction cache: */
static CPUCacheInfo legacy_l1i_cache = {
- .type = ICACHE,
+ .type = INSTRUCTION_CACHE,
.level = 1,
.size = 32 * KiB,
.self_init = 1,
@@ -578,7 +578,7 @@ static CPUCacheInfo legacy_l1i_cache = {
/*FIXME: CPUID leaf 0x80000005 is inconsistent with leaves 2 & 4 */
static CPUCacheInfo legacy_l1i_cache_amd = {
- .type = ICACHE,
+ .type = INSTRUCTION_CACHE,
.level = 1,
.size = 64 * KiB,
.self_init = 1,
@@ -1310,7 +1310,7 @@ struct X86CPUDefinition {
static CPUCaches epyc_cache_info = {
.l1d_cache = &(CPUCacheInfo) {
- .type = DCACHE,
+ .type = DATA_CACHE,
.level = 1,
.size = 32 * KiB,
.line_size = 64,
@@ -1322,7 +1322,7 @@ static CPUCaches epyc_cache_info = {
.no_invd_sharing = true,
},
.l1i_cache = &(CPUCacheInfo) {
- .type = ICACHE,
+ .type = INSTRUCTION_CACHE,
.level = 1,
.size = 64 * KiB,
.line_size = 64,
--
2.18.0.rc1.1.g3f1ff2140
^ permalink raw reply related
* Re: arch/arc/ allmodconfig
From: Randy Dunlap @ 2018-07-23 19:45 UTC (permalink / raw)
To: Ofer Levi(SW), Vineet Gupta, LKML,
linux-snps-arc@lists.infradead.org
Cc: Leon Romanovsky, Meir Lichtinger
In-Reply-To: <DB6PR05MB4597A63819F227B17652B5B2B2560@DB6PR05MB4597.eurprd05.prod.outlook.com>
On 07/23/2018 01:34 AM, Ofer Levi(SW) wrote:
> Hi Vineet, randy
>
> Indeed this structure is missing, following is a patch based on linux-4.17.9.
> Sorry about that.
>
> Thanks
>
>
> diff -uprN linux-4.17.9.org/arch/arc/plat-eznps/include/plat/ctop.h linux-4.17.9/arch/arc/plat-eznps/include/plat/ctop.h
> --- linux-4.17.9.org/arch/arc/plat-eznps/include/plat/ctop.h 2018-07-22 16:16:09.000000000 +0300
> +++ linux-4.17.9/arch/arc/plat-eznps/include/plat/ctop.h 2018-07-23 11:18:12.179402620 +0300
> @@ -143,6 +143,15 @@ struct nps_host_reg_gim_p_int_dst {
> };
>
> /* AUX registers definition */
> +struct nps_host_reg_aux_dpc {
> + union {
> + struct {
> + u32 ien:1, men:1, hen:1, reserved:29;
> + };
> + u32 value;
> + };
> +};
> +
> struct nps_host_reg_aux_udmc {
> union {
> struct {
>
Thanks, this fixes the build error.
I will not that outlook is not the best email client that you could use for
sending Linux patches. I don't know if you generated the patch with spaces
or tabs being used for indentation, but above, it contains all leading spaces
for indentation, which is Not Good.
--
~Randy
^ permalink raw reply
* [Qemu-devel] [PULL 0/1] Build fix for -rc2
From: Eduardo Habkost @ 2018-07-23 19:45 UTC (permalink / raw)
To: Peter Maydell, qemu-devel
Cc: Paolo Bonzini, Eduardo Habkost, Marcel Apfelbaum,
Michael S. Tsirkin, Richard Henderson
The following changes since commit 9ba7dd14355bb7957680d5ef764471ab102df099:
Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2018-07-23' into staging (2018-07-23 15:15:46 +0100)
are available in the Git repository at:
git://github.com/ehabkost/qemu.git tags/x86-next-pull-request
for you to fetch changes up to 5f00335aecafc9ad56592d943619d3252f8941f1:
i386: Rename enum CacheType members (2018-07-23 12:56:19 -0300)
----------------------------------------------------------------
Fix for -rc2
* Fix build failure on mips host
----------------------------------------------------------------
Eduardo Habkost (1):
i386: Rename enum CacheType members
target/i386/cpu.h | 4 +-
target/i386/cpu.c | 128 +++++++++++++++++++++++-----------------------
2 files changed, 66 insertions(+), 66 deletions(-)
--
2.18.0.rc1.1.g3f1ff2140
^ permalink raw reply
* arch/arc/ allmodconfig
From: Randy Dunlap @ 2018-07-23 19:45 UTC (permalink / raw)
To: linux-snps-arc
In-Reply-To: <DB6PR05MB4597A63819F227B17652B5B2B2560@DB6PR05MB4597.eurprd05.prod.outlook.com>
On 07/23/2018 01:34 AM, Ofer Levi(SW) wrote:
> Hi Vineet, randy
>
> Indeed this structure is missing, following is a patch based on linux-4.17.9.
> Sorry about that.
>
> Thanks
>
>
> diff -uprN linux-4.17.9.org/arch/arc/plat-eznps/include/plat/ctop.h linux-4.17.9/arch/arc/plat-eznps/include/plat/ctop.h
> --- linux-4.17.9.org/arch/arc/plat-eznps/include/plat/ctop.h 2018-07-22 16:16:09.000000000 +0300
> +++ linux-4.17.9/arch/arc/plat-eznps/include/plat/ctop.h 2018-07-23 11:18:12.179402620 +0300
> @@ -143,6 +143,15 @@ struct nps_host_reg_gim_p_int_dst {
> };
>
> /* AUX registers definition */
> +struct nps_host_reg_aux_dpc {
> + union {
> + struct {
> + u32 ien:1, men:1, hen:1, reserved:29;
> + };
> + u32 value;
> + };
> +};
> +
> struct nps_host_reg_aux_udmc {
> union {
> struct {
>
Thanks, this fixes the build error.
I will not that outlook is not the best email client that you could use for
sending Linux patches. I don't know if you generated the patch with spaces
or tabs being used for indentation, but above, it contains all leading spaces
for indentation, which is Not Good.
--
~Randy
^ permalink raw reply
* Re: [Xenomai] Cobalt Scheduling tasks on a single core
From: Jackson Jones @ 2018-07-23 19:44 UTC (permalink / raw)
To: xenomai, Philippe Gerum
In-Reply-To: <b16ed60f-31f2-3ef0-f7bc-a35de9629b51@xenomai.org>
We were using processor affinity and assigning the RT tasks to different
cores. The issue we ran into is that the application would lock up (causing
the whole system to freeze) after several hours of being idle
(approximately 8 hours). When we did not use processor affinity, our app
would not lock up (but then all RT task are on one core).
One thing I noticed is that currently we are designating all the CPUs to be
real time (passing xenomai.supported_cpus=0x0000000f). Could this be the
cause of the lockup? Should we leave one cpu out (of the real time group)?
We also discovered over this past weekend that if we enable these options
in the Linux kernel, our app does not lock up:
CONFIG_LOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
These options are not something we want to ship with, but it is interesting
that they seem to prevent the lockup.
On Sat, Jul 21, 2018 at 1:47 AM, Philippe Gerum <rpm@xenomai.org> wrote:
> On 07/21/2018 01:28 AM, Jackson Jones wrote:
> > We are running against xenomai 3.0.7 on a quad core arm (i.mx6). Xenomai
> > was configured with these arguments:
> >
> > #export CFLAGS=-O2 LIBS=-lposix
> > ./configure \
> > --with-core=cobalt \
> > --enable-smp \
> > --enable-registry \
> > --enable-pshared \
> > --enable-dlopen-libs \
> > --enable-sanity \
> > --disable-tls \
> > --enable-valgrind-client \
> > --disable-assert
> >
> > The main app spawns off several real time tasks. Cobalt is scheduling all
> > the real-time tasks on one core. Is this normal behavior for Cobalt? I
> > would expect it to take advantage of the multiple cores.
>
> Your application has to decide for this, CPU migration is costly in many
> ways, increases latency. For this reason, no Xenomai co-kernel ever has
> implemented any load balancing of any sort. On the contrary, it does pin
> each emerging thread to its current CPU precisely to prevent unexpected
> migration while the threads runs in secondary mode, before entering the
> rt processing loop - this CPU may of course be changed by the
> application afterwards.
>
> What you are seeing here is the default assignment of threads to CPUs:
> the regular kernel picked a base CPU for each newly created thread, then
> Cobalt pinned it there.
>
> The idea is to figure out the best placement of the rt threads among the
> CPUs available for rt processing, moving them accordingly using
> sched_setaffinity() during the init phase. This placement could be
> paired with setting xenomai.supported_cpus for restricting the CPUs
> dedicated to real-time duties to a subset of the available cores.
>
> --
> Philippe.
>
^ permalink raw reply
* Re: [PATCH v2] hwmon: (iio_hwmon) Use devm functions
From: Guenter Roeck @ 2018-07-23 18:42 UTC (permalink / raw)
To: Maxime Roussin-Bélanger; +Cc: Jean Delvare, linux-hwmon, Jonathan Cameron
In-Reply-To: <20180723033329.28213-1-maxime.roussinbelanger@gmail.com>
On Sun, Jul 22, 2018 at 11:33:29PM -0400, Maxime Roussin-Bélanger wrote:
> Use devm_iio_channel_get_all() to automatically release
> channels.
>
> Use devm_hwmon_device_register_with_groups() to
> automatically unregister the device.
>
> Signed-off-by: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com>
Applied, with a couple of additional changes (see below).
Thanks,
Guenter
> ---
> Changes in v2:
> - Remove unnecessary {}
>
> drivers/hwmon/iio_hwmon.c | 63 ++++++++++++---------------------------
> 1 file changed, 19 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/hwmon/iio_hwmon.c b/drivers/hwmon/iio_hwmon.c
> index a3a1d1cb2f27..44d7dfe9cb46 100644
> --- a/drivers/hwmon/iio_hwmon.c
> +++ b/drivers/hwmon/iio_hwmon.c
> @@ -73,44 +73,38 @@ static int iio_hwmon_probe(struct platform_device *pdev)
> if (dev->of_node && dev->of_node->name)
> name = dev->of_node->name;
>
> - channels = iio_channel_get_all(dev);
> + channels = devm_iio_channel_get_all(dev);
> if (IS_ERR(channels)) {
> if (PTR_ERR(channels) == -ENODEV)
> return -EPROBE_DEFER;
> return PTR_ERR(channels);
> }
>
> st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
> - if (st == NULL) {
> - ret = -ENOMEM;
> - goto error_release_channels;
> - }
> + if (st == NULL)
> + return -ENOMEM;
>
> st->channels = channels;
>
> /* count how many attributes we have */
> while (st->channels[st->num_channels].indio_dev)
> st->num_channels++;
>
> st->attrs = devm_kzalloc(dev,
> sizeof(*st->attrs) * (st->num_channels + 1),
> GFP_KERNEL);
> - if (st->attrs == NULL) {
> - ret = -ENOMEM;
> - goto error_release_channels;
> - }
> + if (st->attrs == NULL)
> + return -ENOMEM;
>
> for (i = 0; i < st->num_channels; i++) {
> a = devm_kzalloc(dev, sizeof(*a), GFP_KERNEL);
> - if (a == NULL) {
> - ret = -ENOMEM;
> - goto error_release_channels;
> - }
> + if (a == NULL)
> + return -ENOMEM;
>
> sysfs_attr_init(&a->dev_attr.attr);
> ret = iio_get_channel_type(&st->channels[i], &type);
> if (ret < 0)
> - goto error_release_channels;
> + return ret;
>
> switch (type) {
> case IIO_VOLTAGE:
> @@ -138,49 +132,31 @@ static int iio_hwmon_probe(struct platform_device *pdev)
> humidity_i++);
> break;
> default:
> - ret = -EINVAL;
> - goto error_release_channels;
> - }
> - if (a->dev_attr.attr.name == NULL) {
> - ret = -ENOMEM;
> - goto error_release_channels;
> + return -EINVAL;
> }
> + if (a->dev_attr.attr.name == NULL)
> + return -ENOMEM;
> +
> a->dev_attr.show = iio_hwmon_read_val;
> a->dev_attr.attr.mode = S_IRUGO;
> a->index = i;
> st->attrs[i] = &a->dev_attr.attr;
> }
>
> st->attr_group.attrs = st->attrs;
> st->groups[0] = &st->attr_group;
>
> sname = devm_kstrdup(dev, name, GFP_KERNEL);
> - if (!sname) {
> - ret = -ENOMEM;
> - goto error_release_channels;
> - }
> + if (!sname)
> + return -ENOMEM;
>
> strreplace(sname, '-', '_');
> - st->hwmon_dev = hwmon_device_register_with_groups(dev, sname, st,
> - st->groups);
> - if (IS_ERR(st->hwmon_dev)) {
> - ret = PTR_ERR(st->hwmon_dev);
> - goto error_release_channels;
> - }
> - platform_set_drvdata(pdev, st);
> - return 0;
> -
> -error_release_channels:
> - iio_channel_release_all(channels);
> - return ret;
> -}
> + st->hwmon_dev = devm_hwmon_device_register_with_groups(dev, sname, st,
> + st->groups);
st->hwmon_dev is now unnecessary. Changed to local variable.
> + if (IS_ERR(st->hwmon_dev))
> + return PTR_ERR(st->hwmon_dev);
>
> -static int iio_hwmon_remove(struct platform_device *pdev)
> -{
> - struct iio_hwmon_state *st = platform_get_drvdata(pdev);
> -
> - hwmon_device_unregister(st->hwmon_dev);
> - iio_channel_release_all(st->channels);
> + platform_set_drvdata(pdev, st);
This is now unnecessary. Dropped. With this, the simplified the code to
hwmon_dev = devm_hwmon_device_register_with_groups(dev, sname, st,
st->groups);
return PTR_ERR_OR_ZERO(hwmon_dev);
>
> return 0;
> }
> @@ -197,7 +173,6 @@ static struct platform_driver __refdata iio_hwmon_driver = {
> .of_match_table = iio_hwmon_of_match,
> },
> .probe = iio_hwmon_probe,
> - .remove = iio_hwmon_remove,
> };
>
> module_platform_driver(iio_hwmon_driver);
^ permalink raw reply
* Re: [PATCH v2 bpf 2/3] bpf: Replace [u]int32_t and [u]int64_t in libbpf
From: Martin KaFai Lau @ 2018-07-23 18:41 UTC (permalink / raw)
To: Yonghong Song; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <f9f7ad47-b53b-35c7-d0ab-119d01c2cf41@fb.com>
On Mon, Jul 23, 2018 at 11:04:34AM -0700, Yonghong Song wrote:
>
>
> On 7/21/18 11:20 AM, Martin KaFai Lau wrote:
> > This patch replaces [u]int32_t and [u]int64_t usage with
> > __[su]32 and __[su]64. The same change goes for [u]int16_t
> > and [u]int8_t.
> >
> > Fixes: 8a138aed4a80 ("bpf: btf: Add BTF support to libbpf")
> > Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> > ---
> > tools/lib/bpf/btf.c | 28 +++++++++++++---------------
> > tools/lib/bpf/btf.h | 8 ++++----
> > tools/lib/bpf/libbpf.c | 12 ++++++------
> > tools/lib/bpf/libbpf.h | 4 ++--
> > 4 files changed, 25 insertions(+), 27 deletions(-)
> >
> > diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> > index 8c54a4b6f187..ce77b5b57912 100644
> > --- a/tools/lib/bpf/btf.c
> > +++ b/tools/lib/bpf/btf.c
> > @@ -2,7 +2,6 @@
> > /* Copyright (c) 2018 Facebook */
> > #include <stdlib.h>
> > -#include <stdint.h>
> > #include <string.h>
> > #include <unistd.h>
> > #include <errno.h>
> > @@ -27,13 +26,13 @@ struct btf {
> > struct btf_type **types;
> > const char *strings;
> > void *nohdr_data;
> > - uint32_t nr_types;
> > - uint32_t types_size;
> > - uint32_t data_size;
> > + __u32 nr_types;
> > + __u32 types_size;
> > + __u32 data_size;
> > int fd;
> > };
> > -static const char *btf_name_by_offset(const struct btf *btf, uint32_t offset)
> > +static const char *btf_name_by_offset(const struct btf *btf, __u32 offset)
> > {
> > if (offset < btf->hdr->str_len)
> > return &btf->strings[offset];
> > @@ -151,7 +150,7 @@ static int btf_parse_type_sec(struct btf *btf, btf_print_fn_t err_log)
> > while (next_type < end_type) {
> > struct btf_type *t = next_type;
> > - uint16_t vlen = BTF_INFO_VLEN(t->info);
> > + __u16 vlen = BTF_INFO_VLEN(t->info);
> > int err;
> > next_type += sizeof(*t);
> > @@ -191,7 +190,7 @@ static int btf_parse_type_sec(struct btf *btf, btf_print_fn_t err_log)
> > }
> > static const struct btf_type *btf_type_by_id(const struct btf *btf,
> > - uint32_t type_id)
> > + __u32 type_id)
> > {
> > if (type_id > btf->nr_types)
> > return NULL;
> > @@ -226,12 +225,12 @@ static int64_t btf_type_size(const struct btf_type *t)
>
> Missing this one:
> static int64_t btf_type_size(const struct btf_type *t)
>
> There are a couple of instances of using u32 instead of __u32, better to use
> __u32 everywhere in the same file:
> u32 expand_by, new_size;
> u32 meta_left;
Thanks for pointing them out. Will make the changes.
>
>
> > #define MAX_RESOLVE_DEPTH 32
> > -int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id)
> > +__s64 btf__resolve_size(const struct btf *btf, __u32 type_id)
> > {
> > const struct btf_array *array;
> > const struct btf_type *t;
> > - uint32_t nelems = 1;
> > - int64_t size = -1;
> > + __u32 nelems = 1;
> > + __s64 size = -1;
> > int i;
> > t = btf_type_by_id(btf, type_id);
> > @@ -271,9 +270,9 @@ int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id)
> > return nelems * size;
> > }
> > -int32_t btf__find_by_name(const struct btf *btf, const char *type_name)
> > +__s32 btf__find_by_name(const struct btf *btf, const char *type_name)
> > {
> > - uint32_t i;
> > + __u32 i;
> > if (!strcmp(type_name, "void"))
> > return 0;
> > @@ -302,10 +301,9 @@ void btf__free(struct btf *btf)
> > free(btf);
> > }
> > -struct btf *btf__new(uint8_t *data, uint32_t size,
> > - btf_print_fn_t err_log)
> > +struct btf *btf__new(__u8 *data, __u32 size, btf_print_fn_t err_log)
> > {
> > - uint32_t log_buf_size = 0;
> > + __u32 log_buf_size = 0;
> > char *log_buf = NULL;
> > struct btf *btf;
> > int err;
> > diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
> > index 74bb344035bb..ed3a84370ccc 100644
> > --- a/tools/lib/bpf/btf.h
> > +++ b/tools/lib/bpf/btf.h
> > @@ -4,7 +4,7 @@
> > #ifndef __BPF_BTF_H
> > #define __BPF_BTF_H
> > -#include <stdint.h>
> > +#include <linux/types.h>
> > #define BTF_ELF_SEC ".BTF"
> > @@ -14,9 +14,9 @@ typedef int (*btf_print_fn_t)(const char *, ...)
> > __attribute__((format(printf, 1, 2)));
> > void btf__free(struct btf *btf);
> > -struct btf *btf__new(uint8_t *data, uint32_t size, btf_print_fn_t err_log);
> > -int32_t btf__find_by_name(const struct btf *btf, const char *type_name);
> > -int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id);
> > +struct btf *btf__new(__u8 *data, __u32 size, btf_print_fn_t err_log);
> > +__s32 btf__find_by_name(const struct btf *btf, const char *type_name);
> > +__s64 btf__resolve_size(const struct btf *btf, __u32 type_id);
> > int btf__fd(const struct btf *btf);
> > #endif
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index a1e96b5de5ff..6deb4fe4fffe 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -216,8 +216,8 @@ struct bpf_map {
> > size_t offset;
> > int map_ifindex;
> > struct bpf_map_def def;
> > - uint32_t btf_key_type_id;
> > - uint32_t btf_value_type_id;
> > + __u32 btf_key_type_id;
> > + __u32 btf_value_type_id;
> > void *priv;
> > bpf_map_clear_priv_t clear_priv;
> > };
> > @@ -1016,8 +1016,8 @@ static int bpf_map_find_btf_info(struct bpf_map *map, const struct btf *btf)
> > {
> > struct bpf_map_def *def = &map->def;
> > const size_t max_name = 256;
> > - int64_t key_size, value_size;
> > - int32_t key_id, value_id;
> > + __s64 key_size, value_size;
> > + __s32 key_id, value_id;
> > char name[max_name];
> > /* Find key type by name from BTF */
> > @@ -2089,12 +2089,12 @@ const char *bpf_map__name(struct bpf_map *map)
> > return map ? map->name : NULL;
> > }
> > -uint32_t bpf_map__btf_key_type_id(const struct bpf_map *map)
> > +__u32 bpf_map__btf_key_type_id(const struct bpf_map *map)
> > {
> > return map ? map->btf_key_type_id : 0;
> > }
> > -uint32_t bpf_map__btf_value_type_id(const struct bpf_map *map)
> > +__u32 bpf_map__btf_value_type_id(const struct bpf_map *map)
> > {
> > return map ? map->btf_value_type_id : 0;
> > }
> > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > index 09976531aa74..b33ae02f7d0e 100644
> > --- a/tools/lib/bpf/libbpf.h
> > +++ b/tools/lib/bpf/libbpf.h
> > @@ -244,8 +244,8 @@ bpf_map__next(struct bpf_map *map, struct bpf_object *obj);
> > int bpf_map__fd(struct bpf_map *map);
> > const struct bpf_map_def *bpf_map__def(struct bpf_map *map);
> > const char *bpf_map__name(struct bpf_map *map);
> > -uint32_t bpf_map__btf_key_type_id(const struct bpf_map *map);
> > -uint32_t bpf_map__btf_value_type_id(const struct bpf_map *map);
> > +__u32 bpf_map__btf_key_type_id(const struct bpf_map *map);
> > +__u32 bpf_map__btf_value_type_id(const struct bpf_map *map);
> > typedef void (*bpf_map_clear_priv_t)(struct bpf_map *, void *);
> > int bpf_map__set_priv(struct bpf_map *map, void *priv,
> >
^ permalink raw reply
* Re: [PATCH v2 bpf 3/3] bpf: Introduce BPF_ANNOTATE_KV_PAIR
From: Martin KaFai Lau @ 2018-07-23 18:41 UTC (permalink / raw)
To: Yonghong Song; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <bd832483-293f-0113-14fa-d7b5fef53f4d@fb.com>
On Mon, Jul 23, 2018 at 11:31:43AM -0700, Yonghong Song wrote:
>
>
> On 7/21/18 11:20 AM, Martin KaFai Lau wrote:
> > This patch introduces BPF_ANNOTATE_KV_PAIR to signal the
> > bpf loader about the btf key_type and value_type of a bpf map.
> > Please refer to the changes in test_btf_haskv.c for its usage.
> > Both iproute2 and libbpf loader will then have the same
> > convention to find out the map's btf_key_type_id and
> > btf_value_type_id from a map's name.
> >
> > Fixes: 8a138aed4a80 ("bpf: btf: Add BTF support to libbpf")
> > Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
> > Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> > ---
> > tools/lib/bpf/btf.c | 7 +-
> > tools/lib/bpf/btf.h | 2 +
> > tools/lib/bpf/libbpf.c | 75 +++++++++++---------
> > tools/testing/selftests/bpf/bpf_helpers.h | 9 +++
> > tools/testing/selftests/bpf/test_btf_haskv.c | 7 +-
> > 5 files changed, 56 insertions(+), 44 deletions(-)
> >
> > diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> > index ce77b5b57912..321a99e648ed 100644
> > --- a/tools/lib/bpf/btf.c
> > +++ b/tools/lib/bpf/btf.c
> > @@ -189,8 +189,7 @@ static int btf_parse_type_sec(struct btf *btf, btf_print_fn_t err_log)
> > return 0;
> > }
> > -static const struct btf_type *btf_type_by_id(const struct btf *btf,
> > - __u32 type_id)
> > +const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 type_id)
> > {
> > if (type_id > btf->nr_types)
> > return NULL;
> > @@ -233,7 +232,7 @@ __s64 btf__resolve_size(const struct btf *btf, __u32 type_id)
> > __s64 size = -1;
> > int i;
> > - t = btf_type_by_id(btf, type_id);
> > + t = btf__type_by_id(btf, type_id);
> > for (i = 0; i < MAX_RESOLVE_DEPTH && !btf_type_is_void_or_null(t);
> > i++) {
> > size = btf_type_size(t);
> > @@ -258,7 +257,7 @@ __s64 btf__resolve_size(const struct btf *btf, __u32 type_id)
> > return -EINVAL;
> > }
> > - t = btf_type_by_id(btf, type_id);
> > + t = btf__type_by_id(btf, type_id);
> > }
> > if (size < 0)
> > diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
> > index ed3a84370ccc..e2a09a155f84 100644
> > --- a/tools/lib/bpf/btf.h
> > +++ b/tools/lib/bpf/btf.h
> > @@ -9,6 +9,7 @@
> > #define BTF_ELF_SEC ".BTF"
> > struct btf;
> > +struct btf_type;
> > typedef int (*btf_print_fn_t)(const char *, ...)
> > __attribute__((format(printf, 1, 2)));
> > @@ -16,6 +17,7 @@ typedef int (*btf_print_fn_t)(const char *, ...)
> > void btf__free(struct btf *btf);
> > struct btf *btf__new(__u8 *data, __u32 size, btf_print_fn_t err_log);
> > __s32 btf__find_by_name(const struct btf *btf, const char *type_name);
> > +const struct btf_type *btf__type_by_id(const struct btf *btf, __u32 id);
> > __s64 btf__resolve_size(const struct btf *btf, __u32 type_id);
> > int btf__fd(const struct btf *btf);
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index 6deb4fe4fffe..d881d370616c 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -36,6 +36,7 @@
> > #include <linux/err.h>
> > #include <linux/kernel.h>
> > #include <linux/bpf.h>
> > +#include <linux/btf.h>
> > #include <linux/list.h>
> > #include <linux/limits.h>
> > #include <sys/stat.h>
> > @@ -1014,68 +1015,72 @@ bpf_program__collect_reloc(struct bpf_program *prog, GElf_Shdr *shdr,
> > static int bpf_map_find_btf_info(struct bpf_map *map, const struct btf *btf)
> > {
> > + const struct btf_type *container_type;
> > + const struct btf_member *key, *value;
> > struct bpf_map_def *def = &map->def;
> > const size_t max_name = 256;
> > + char container_name[max_name];
> > __s64 key_size, value_size;
> > - __s32 key_id, value_id;
> > - char name[max_name];
> > + __s32 container_id;
> > - /* Find key type by name from BTF */
> > - if (snprintf(name, max_name, "%s_key", map->name) == max_name) {
> > - pr_warning("map:%s length of BTF key_type:%s_key is too long\n",
> > + if (snprintf(container_name, max_name, "____btf_map_%s", map->name) ==
> > + max_name) {
> > + pr_warning("map:%s length of '____btf_map_%s' is too long\n",
> > map->name, map->name);
> > return -EINVAL;
> > }
> > - key_id = btf__find_by_name(btf, name);
> > - if (key_id < 0) {
> > - pr_debug("map:%s key_type:%s cannot be found in BTF\n",
> > - map->name, name);
> > - return key_id;
> > + container_id = btf__find_by_name(btf, container_name);
> > + if (container_id < 0) {
> > + pr_debug("map:%s container_name:%s cannot be found in BTF. Missing BPF_ANNOTATE_KV_PAIR?\n",
> > + map->name, container_name);
> > + return container_id;
> > }
> > - key_size = btf__resolve_size(btf, key_id);
> > - if (key_size < 0) {
> > - pr_warning("map:%s key_type:%s cannot get the BTF type_size\n",
> > - map->name, name);
> > - return key_size;
> > + container_type = btf__type_by_id(btf, container_id);
> > + if (!container_type) {
> > + pr_warning("map:%s cannot find BTF type for container_id:%u\n",
> > + map->name, container_id);
> > + return -EINVAL;
> > }
> > - if (def->key_size != key_size) {
> > - pr_warning("map:%s key_type:%s has BTF type_size:%u != key_size:%u\n",
> > - map->name, name, (unsigned int)key_size, def->key_size);
> > + if (BTF_INFO_KIND(container_type->info) != BTF_KIND_STRUCT ||
> > + BTF_INFO_VLEN(container_type->info) < 2) {
>
> Should "BTF_INFO_VLEN(container_type->info) < 2" be
> "BTF_INFO_VLEN(container_type->info) != 2"?
I intentionally use "<" in case we may want to extend
BPF_ANNOTATE_KV_PAIR in the future.
>
> > + pr_warning("map:%s container_name:%s is an invalid container struct\n",
> > + map->name, container_name);
> > return -EINVAL;
> > }
> > - /* Find value type from BTF */
> > - if (snprintf(name, max_name, "%s_value", map->name) == max_name) {
> > - pr_warning("map:%s length of BTF value_type:%s_value is too long\n",
> > - map->name, map->name);
> > - return -EINVAL;
> > + key = (struct btf_member *)(container_type + 1);
> > + value = key + 1;
> > +
> > + key_size = btf__resolve_size(btf, key->type);
> > + if (key_size < 0) {
> > + pr_warning("map:%s invalid BTF key_type_size\n",
> > + map->name);
> > + return key_size;
> > }
> > - value_id = btf__find_by_name(btf, name);
> > - if (value_id < 0) {
> > - pr_debug("map:%s value_type:%s cannot be found in BTF\n",
> > - map->name, name);
> > - return value_id;
> > + if (def->key_size != key_size) {
> > + pr_warning("map:%s btf_key_type_size:%u != map_def_key_size:%u\n",
> > + map->name, (__u32)key_size, def->key_size);
> > + return -EINVAL;
> > }
> > - value_size = btf__resolve_size(btf, value_id);
> > + value_size = btf__resolve_size(btf, value->type);
> > if (value_size < 0) {
> > - pr_warning("map:%s value_type:%s cannot get the BTF type_size\n",
> > - map->name, name);
> > + pr_warning("map:%s invalid BTF value_type_size\n", map->name);
> > return value_size;
> > }
> > if (def->value_size != value_size) {
> > - pr_warning("map:%s value_type:%s has BTF type_size:%u != value_size:%u\n",
> > - map->name, name, (unsigned int)value_size, def->value_size);
> > + pr_warning("map:%s btf_value_type_size:%u != map_def_value_size:%u\n",
> > + map->name, (__u32)value_size, def->value_size);
> > return -EINVAL;
> > }
> > - map->btf_key_type_id = key_id;
> > - map->btf_value_type_id = value_id;
> > + map->btf_key_type_id = key->type;
> > + map->btf_value_type_id = value->type;
> > return 0;
> > }
> > diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
> > index f2f28b6c8915..810de20e8e26 100644
> > --- a/tools/testing/selftests/bpf/bpf_helpers.h
> > +++ b/tools/testing/selftests/bpf/bpf_helpers.h
> > @@ -158,6 +158,15 @@ struct bpf_map_def {
> > unsigned int numa_node;
> > };
> > +#define BPF_ANNOTATE_KV_PAIR(name, type_key, type_val) \
> > + struct ____btf_map_##name { \
> > + type_key key; \
> > + type_val value; \
> > + }; \
> > + struct ____btf_map_##name \
> > + __attribute__ ((section(".maps." #name), used)) \
> > + ____btf_map_##name = { }
> > +
> > static int (*bpf_skb_load_bytes)(void *ctx, int off, void *to, int len) =
> > (void *) BPF_FUNC_skb_load_bytes;
> > static int (*bpf_skb_store_bytes)(void *ctx, int off, void *from, int len, int flags) =
> > diff --git a/tools/testing/selftests/bpf/test_btf_haskv.c b/tools/testing/selftests/bpf/test_btf_haskv.c
> > index 8c7ca096ecf2..b21b876f475d 100644
> > --- a/tools/testing/selftests/bpf/test_btf_haskv.c
> > +++ b/tools/testing/selftests/bpf/test_btf_haskv.c
> > @@ -10,11 +10,6 @@ struct ipv_counts {
> > unsigned int v6;
> > };
> > -typedef int btf_map_key;
> > -typedef struct ipv_counts btf_map_value;
> > -btf_map_key dumm_key;
> > -btf_map_value dummy_value;
> > -
> > struct bpf_map_def SEC("maps") btf_map = {
> > .type = BPF_MAP_TYPE_ARRAY,
> > .key_size = sizeof(int),
> > @@ -22,6 +17,8 @@ struct bpf_map_def SEC("maps") btf_map = {
> > .max_entries = 4,
> > };
> > +BPF_ANNOTATE_KV_PAIR(btf_map, int, struct ipv_counts);
> > +
> > struct dummy_tracepoint_args {
> > unsigned long long pad;
> > struct sock *sock;
> >
^ permalink raw reply
* Re: [PATCH 1/2] Add sw2_sw4 voltage table to cpcap regulator.
From: Peter Geis @ 2018-07-23 19:43 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Mark Brown, lgirdwood, robh+dt, mark.rutland, linux-kernel,
devicetree, linux-tegra
In-Reply-To: <3459086.gtf8SULmVS@dimapc>
On 07/23/2018 03:20 PM, Dmitry Osipenko wrote:
> On Monday, 23 July 2018 21:37:50 MSK Peter Geis wrote:
>> On 07/23/2018 02:13 PM, Mark Brown wrote:
>>> On Mon, Jul 23, 2018 at 01:58:26PM -0400, Peter Geis wrote:
>>>> SW2 and SW4 use a shared table to provide voltage to the cpu core and
>>>> devices on Tegra hardware.
>>>> Added this table to the cpcap regulator driver as the first step to
>>>> supporting this device on Tegra.
>>>
>>> This also doesn't apply against current code (though it does now parse
>>> OK), please check and resend - make sure you don't have other out of
>>> tree changes and are using an up to date kernel (ideally my regulator
>>> for-next branch) as a base.
>>
>> Good Afternoon,
>>
>> I thought it was my error in the patches being stripped, unfortunately
>> it seems to be a known Gmail behavior.
>> Any ideas on how to get around it?
>
> Use the "git send-email" instead of email client.
>
> You need to create and send out patches using git, that will be something like
> this:
>
> 1) "git format-patch -v1 -2 ..." to make patches
> 2) "git send-email --smtp-server=smtp.gmail.com --smtp-
> user=pgwipeout@gmail.com --smtp-encryption=tls --smtp-server-port=587 --
> suppress-cc=all --confirm=always --to 'Mark Brown <broonie@kernel.org>' --cc
> 'linux-tegra@vger.kernel.org' --cc 'linux-kernel@vger.kernel.org' ...
> 00*.patch" to send out the patches
>
As always, thanks Dmitry!
Resent through git this time.
^ permalink raw reply
* Re: [PATCH net] ip: hash fragments consistently
From: David Miller @ 2018-07-23 18:40 UTC (permalink / raw)
To: pabeni; +Cc: netdev, tom
In-Reply-To: <9b22fd3a35416b3145f1245466167b001925ce1a.1532357173.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Mon, 23 Jul 2018 16:50:48 +0200
> The skb hash for locally generated ip[v6] fragments belonging
> to the same datagram can vary in several circumstances:
> * for connected UDP[v6] sockets, the first fragment get its hash
> via set_owner_w()/skb_set_hash_from_sk()
> * for unconnected IPv6 UDPv6 sockets, the first fragment can get
> its hash via ip6_make_flowlabel()/skb_get_hash_flowi6(), if
> auto_flowlabel is enabled
>
> For the following frags the hash is usually computed via
> skb_get_hash().
> The above can cause OoO for unconnected IPv6 UDPv6 socket: in that
> scenario the egress tx queue can be selected on a per packet basis
> via the skb hash.
> It may also fool flow-oriented schedulers to place fragments belonging
> to the same datagram in different flows.
>
> Fix the issue by copying the skb hash from the head frag into
> the others at fragmentation time.
>
> Before this commit:
> perf probe -a "dev_queue_xmit skb skb->hash skb->l4_hash:b1@0/8 skb->sw_hash:b1@1/8"
> netperf -H $IPV4 -t UDP_STREAM -l 5 -- -m 2000 -n &
> perf record -e probe:dev_queue_xmit -e probe:skb_set_owner_w -a sleep 0.1
> perf script
> probe:dev_queue_xmit: (ffffffff8c6b1b20) hash=3713014309 l4_hash=1 sw_hash=0
> probe:dev_queue_xmit: (ffffffff8c6b1b20) hash=0 l4_hash=0 sw_hash=0
>
> After this commit:
> probe:dev_queue_xmit: (ffffffff8c6b1b20) hash=2171763177 l4_hash=1 sw_hash=0
> probe:dev_queue_xmit: (ffffffff8c6b1b20) hash=2171763177 l4_hash=1 sw_hash=0
>
> Fixes: b73c3d0e4f0e ("net: Save TX flow hash in sock and set in skbuf on xmit")
> Fixes: 67800f9b1f4e ("ipv6: Call skb_get_hash_flowi6 to get skb->hash in ip6_make_flowlabel")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Good catch!
Applied and queued up for -stable, thanks!
^ permalink raw reply
* ✓ Fi.CI.IGT: success for drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev2)
From: Patchwork @ 2018-07-23 19:41 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20180723145335.24579-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev2)
URL : https://patchwork.freedesktop.org/series/47067/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4529_full -> Patchwork_9749_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9749_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9749_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9749_full:
=== IGT changes ===
==== Warnings ====
igt@gem_mocs_settings@mocs-rc6-blt:
shard-kbl: PASS -> SKIP +1
igt@gem_mocs_settings@mocs-rc6-vebox:
shard-kbl: SKIP -> PASS +2
== Known issues ==
Here are the changes found in Patchwork_9749_full that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@gem_eio@execbuf:
shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359) +15
igt@gem_eio@in-flight-contexts-1us:
shard-kbl: PASS -> INCOMPLETE (fdo#103665) +14
igt@gem_eio@in-flight-contexts-immediate:
shard-hsw: PASS -> INCOMPLETE (fdo#103540) +14
igt@gem_eio@in-flight-immediate:
shard-apl: PASS -> INCOMPLETE (fdo#103927) +15
igt@gem_eio@in-flight-suspend:
shard-kbl: PASS -> INCOMPLETE (fdo#106702, fdo#103665)
igt@gem_eio@throttle:
shard-snb: PASS -> INCOMPLETE (fdo#105411) +16
fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
fdo#106702 https://bugs.freedesktop.org/show_bug.cgi?id=106702
k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133
== Participating hosts (5 -> 5) ==
No changes in participating hosts
== Build changes ==
* Linux: CI_DRM_4529 -> Patchwork_9749
CI_DRM_4529: f44f476c6bb735cb4067af0c4417c49d105bf419 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4571: 65fccc149b85968cdce4737266b056059c1510f3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9749: 9b348bfd231b38751c4d528a89d795745484c760 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9749/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: bisected: 4.18-rc* regression: x86-32 troubles (with timers?)
From: Daniel Borkmann @ 2018-07-23 19:41 UTC (permalink / raw)
To: Arnd Bergmann, Meelis Roos; +Cc: Linux Kernel list, Networking
In-Reply-To: <CAK8P3a19pCbn5Ns0jVqGTiSmGj4AOgjWL0CQtAA-sYRqY4Gvjw@mail.gmail.com>
Hello Meelis, Arnd,
On 07/23/2018 06:03 PM, Arnd Bergmann wrote:
> On Sat, Jul 21, 2018 at 1:01 AM, Meelis Roos <mroos@linux.ee> wrote:
>> Added netdev and Daniel Borkmann - please see
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1724795.html
>> for the original report. It seems to be about BPF instead.
>>
>> Meanwhile I have found more machines with the trouble. Still no clear
>> mark in the config - some x86-32 machines that have
>> CONFIG_BPF=y
>> CONFIG_BPF_SYSCALL=y
>> CONFIG_BPF_JIT_ALWAYS_ON=y
>> are working fine.
>>
>>> The new bisect seems to have also led me to a strange commit. This time
>>> I tried to be careful and tested most on two reboots before classifying
>>> as good.
>>>
>>> However, f4e3ec0d573e was suspicious - it failed to autoload e1000 but
>>> had no other errors. On both boots with this kernel, modprobe e1000 and
>>> ifup -a made the system work so I assumed it was good, while it might
>>> not have been. Will try bisecting with f4e3ec0d573e marked bad.
>>
>> Now this seems more relevant:
>>
>> mroos@rx100s2:~/linux$ nice git bisect good
>> 24dea04767e6e5175f4750770281b0c17ac6a2fb is the first bad commit
>> commit 24dea04767e6e5175f4750770281b0c17ac6a2fb
>> Author: Daniel Borkmann <daniel@iogearbox.net>
>> Date: Fri May 4 01:08:23 2018 +0200
>>
>> bpf, x32: remove ld_abs/ld_ind
>>
>> Since LD_ABS/LD_IND instructions are now removed from the core and
>> reimplemented through a combination of inlined BPF instructions and
>> a slow-path helper, we can get rid of the complexity from x32 JIT.
>
> This does seem much more likely than the previous bisection, given
> that you ended up in an x86-32 specific commit (the subject says x32,
> but that is a mistake). I also checked that systemd indeed does
> call into bpf in a number of places, possibly for the journald socket.
>
> OTOH, it's still hard to tell how that commit can have ended up
> corrupting the clock read function in systemd. To cross-check,
> could you try reverting that commit on the latest kernel and see
> if it still works?
I would be curious as well about that whether revert would make it
work. What's the value of sysctl net.core.bpf_jit_enable ? Does it
change anything if you set it to 0 (only interpreter) or 1 (JIT
enabled). Seems a bit strange to me that bisect ended at this commit
given the issue you have. The JIT itself was also new in this window
fwiw. In any case some more debug info would be great to have.
Thanks,
Daniel
^ permalink raw reply
* Re: KASAN: use-after-free Read in p9_fd_poll
From: syzbot @ 2018-07-23 19:41 UTC (permalink / raw)
To: davem, ericvh, linux-kernel, lucho, netdev, rminnich,
syzkaller-bugs, v9fs-developer
In-Reply-To: <000000000000afbebb0570be9bf3@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: d72e90f33aa4 Linux 4.18-rc6
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=161894c8400000
kernel config: https://syzkaller.appspot.com/x/.config?x=68af3495408deac5
dashboard link: https://syzkaller.appspot.com/bug?extid=0442e6e2f7e1e33b1037
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1569b51c400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16e7a978400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0442e6e2f7e1e33b1037@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
==================================================================
BUG: KASAN: use-after-free in p9_fd_poll+0x280/0x2b0 net/9p/trans_fd.c:238
Read of size 8 at addr ffff8801d6ddf340 by task kworker/0:2/26
CPU: 0 PID: 26 Comm: kworker/0:2 Not tainted 4.18.0-rc6+ #160
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events p9_poll_workfn
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
p9_fd_poll+0x280/0x2b0 net/9p/trans_fd.c:238
p9_poll_mux net/9p/trans_fd.c:617 [inline]
p9_poll_workfn+0x463/0x6d0 net/9p/trans_fd.c:1107
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
Allocated by task 4581:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
kmalloc include/linux/slab.h:513 [inline]
kzalloc include/linux/slab.h:707 [inline]
p9_fd_open net/9p/trans_fd.c:796 [inline]
p9_fd_create+0x1a7/0x3f0 net/9p/trans_fd.c:1036
p9_client_create+0x8ed/0x1770 net/9p/client.c:1063
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
mount_fs+0xae/0x328 fs/super.c:1277
vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
vfs_kern_mount fs/namespace.c:1027 [inline]
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x581/0x30e0 fs/namespace.c:2848
ksys_mount+0x12d/0x140 fs/namespace.c:3064
__do_sys_mount fs/namespace.c:3078 [inline]
__se_sys_mount fs/namespace.c:3075 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 4581:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
p9_fd_close+0x416/0x5b0 net/9p/trans_fd.c:893
p9_client_create+0xa9a/0x1770 net/9p/client.c:1077
v9fs_session_init+0x21a/0x1a80 fs/9p/v9fs.c:400
v9fs_mount+0x7c/0x900 fs/9p/vfs_super.c:135
mount_fs+0xae/0x328 fs/super.c:1277
vfs_kern_mount.part.34+0xdc/0x4e0 fs/namespace.c:1037
vfs_kern_mount fs/namespace.c:1027 [inline]
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x581/0x30e0 fs/namespace.c:2848
ksys_mount+0x12d/0x140 fs/namespace.c:3064
__do_sys_mount fs/namespace.c:3078 [inline]
__se_sys_mount fs/namespace.c:3075 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8801d6ddf340
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 0 bytes inside of
512-byte region [ffff8801d6ddf340, ffff8801d6ddf540)
The buggy address belongs to the page:
page:ffffea00075b77c0 count:1 mapcount:0 mapping:ffff8801da800940 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffffea0007398548 ffffea0006c59188 ffff8801da800940
raw: 0000000000000000 ffff8801d6ddf0c0 0000000100000006 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801d6ddf200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801d6ddf280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ffff8801d6ddf300: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8801d6ddf380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801d6ddf400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
^ permalink raw reply
* [Buildroot] [PATCH] package/binutils: add binutils version 2.31
From: Max Filippov @ 2018-07-23 19:40 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20180717130952.5b09ca40@windsurf>
On Tue, Jul 17, 2018 at 4:09 AM, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> The update to binutils 2.31 seems to be causing a regression: it cannot
> build uClibc anymore:
Thanks for the report, the issue is now fixed in the binutils
and a patch is posted to the buildroot.
> LD libthread_db-1.0.30.so
> /opt/xtensa-lx60--uclibc--bleeding-edge-2018.07-1/lib/gcc/xtensa-buildroot-linux-uclibc/8.1.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31 internal error, aborting at elf32-xtensa.c:3269 in elf_xtensa_finish_dynamic_sections
>
> /opt/xtensa-lx60--uclibc--bleeding-edge-2018.07-1/lib/gcc/xtensa-buildroot-linux-uclibc/8.1.0/../../../../xtensa-buildroot-linux-uclibc/bin/ld: Please report this bug.
>
> collect2: error: ld returned 1 exit status
> libpthread/nptl_db/Makefile.in:53: recipe for target 'lib/libthread_db.so' failed
> make[1]: *** [lib/libthread_db.so] Error 1
> make[1]: Leaving directory '/opt/output/build/uclibc-1.0.30'
>
> My previous build of toolchains, which was using binutils 2.30, went
> fine including on Xtensa.
>
> See
> https://gitlab.com/free-electrons/toolchains-builder/-/jobs/82264912
> for the build failure.
--
Thanks.
-- Max
^ permalink raw reply
* Re: [PATCH 0/5] Misc Coccinelle-related improvements
From: Junio C Hamano @ 2018-07-23 19:40 UTC (permalink / raw)
To: SZEDER Gábor
Cc: git, René Scharfe, Derrick Stolee,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20180723135100.24288-1-szeder.dev@gmail.com>
SZEDER Gábor <szeder.dev@gmail.com> writes:
> Just a couple of minor Coccinelle-related improvements:
>
> - The first two patches are small cleanups.
>
> - The last three could make life perhaps just a tad bit easier for
> devs running 'make coccicheck'.
Thanks. All 5 patches make sense.
Queued.
^ permalink raw reply
* [Bug 106441] Totem video playback stuttering and graphical artifacts
From: bugzilla-daemon @ 2018-07-23 19:40 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-106441-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 618 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=106441
--- Comment #6 from Richard B. Kreckel <kreckel@ginac.de> ---
(In reply to Richard B. Kreckel from comment #5)
> It must be Xorg.
>
> I've upgradee to Xorg 1.20 (without upgrading anything else) from
> Debian/experimental and this problem has disappeared for good.
...which is not to say that things work, now.
In a way it's worse than before but this seems to be another problem:
<https://gitlab.gnome.org/GNOME/totem/issues/241>.
(I'm posting this here for the record.)
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1564 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] drm/i915: Skip repeated calls to i915_gem_set_wedged()
From: Chris Wilson @ 2018-07-23 19:39 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20180723145335.24579-1-chris@chris-wilson.co.uk>
If we already wedged, i915_gem_set_wedged() becomes a complicated no-op.
v2: Make sure the double set-wedged is synchronous, a parallel call
should not return before the driver is indeed wedged.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107343
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_gem.c | 31 ++++++++++++++++++++++-----
drivers/gpu/drm/i915/i915_gpu_error.h | 3 ++-
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8b52cb768a67..832c65734c47 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3298,12 +3298,26 @@ static void nop_complete_submit_request(struct i915_request *request)
spin_unlock_irqrestore(&request->engine->timeline.lock, flags);
}
+static void wait_for_wedged(struct i915_gpu_error *error)
+{
+ DEFINE_WAIT_BIT(wq_entry, &error->flags, I915_WEDGED);
+
+ __wait_on_bit(&error->reset_queue,
+ &wq_entry, bit_wait, TASK_UNINTERRUPTIBLE);
+}
+
void i915_gem_set_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = &i915->gpu_error;
struct intel_engine_cs *engine;
enum intel_engine_id id;
- GEM_TRACE("start\n");
+ if (test_and_set_bit(I915_WEDGE_IN_PROGRESS, &error->flags)) {
+ wait_for_wedged(error);
+ return;
+ }
+ if (test_bit(I915_WEDGED, &error->flags))
+ return;
if (GEM_SHOW_DEBUG()) {
struct drm_printer p = drm_debug_printer(__func__);
@@ -3312,8 +3326,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_dump(engine, &p, "%s\n", engine->name);
}
- set_bit(I915_WEDGED, &i915->gpu_error.flags);
- smp_mb__after_atomic();
+ GEM_TRACE("start\n");
/*
* First, stop submission to hw, but do not yet complete requests by
@@ -3372,17 +3385,25 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
i915_gem_reset_finish_engine(engine);
}
+ smp_mb__before_atomic();
+ set_bit(I915_WEDGED, &error->flags);
+ clear_bit(I915_WEDGE_IN_PROGRESS, &error->flags);
+
GEM_TRACE("end\n");
- wake_up_all(&i915->gpu_error.reset_queue);
+ wake_up_all(&error->reset_queue);
}
bool i915_gem_unset_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = &i915->gpu_error;
struct i915_timeline *tl;
lockdep_assert_held(&i915->drm.struct_mutex);
- if (!test_bit(I915_WEDGED, &i915->gpu_error.flags))
+
+ if (test_bit(I915_WEDGE_IN_PROGRESS, &error->flags))
+ wait_for_wedged(error);
+ if (!test_bit(I915_WEDGED, &error->flags))
return true;
GEM_TRACE("start\n");
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h b/drivers/gpu/drm/i915/i915_gpu_error.h
index f893a4e8b783..1a78a8f330f2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -267,8 +267,9 @@ struct i915_gpu_error {
#define I915_RESET_BACKOFF 0
#define I915_RESET_HANDOFF 1
#define I915_RESET_MODESET 2
+#define I915_RESET_ENGINE 3
#define I915_WEDGED (BITS_PER_LONG - 1)
-#define I915_RESET_ENGINE (I915_WEDGED - I915_NUM_ENGINES)
+#define I915_WEDGE_IN_PROGRESS (I915_WEDGED - 1)
/** Number of times an engine has been reset */
u32 reset_engine_count[I915_NUM_ENGINES];
--
2.18.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH 2/2 v2] Add support for CPCAP regulators on Tegra devices.
From: Peter Geis @ 2018-07-23 19:38 UTC (permalink / raw)
To: broonie
Cc: lgirdwood, robh+dt, linux-kernel, devicetree, linux-tegra,
Peter Geis
In-Reply-To: <20180723193848.32491-1-pgwipeout@gmail.com>
Added support for the CPCAP power management regulator functions on
Tegra devices.
Added sw2_sw4 value tables, which provide power to the Tegra core and
aux devices.
Added the Tegra init tables and device tree compatibility match.
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
---
.../bindings/regulator/cpcap-regulator.txt | 1 +
drivers/regulator/cpcap-regulator.c | 80 +++++++++++++++++++
2 files changed, 81 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
index 675f4437ce92..3e2d33ab1731 100644
--- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
@@ -4,6 +4,7 @@ Motorola CPCAP PMIC voltage regulators
Requires node properties:
- "compatible" value one of:
"motorola,cpcap-regulator"
+ "motorola,tegra-cpcap-regulator"
"motorola,mapphone-cpcap-regulator"
Required regulator properties:
diff --git a/drivers/regulator/cpcap-regulator.c b/drivers/regulator/cpcap-regulator.c
index c0b1e04bd90f..cb3774be445d 100644
--- a/drivers/regulator/cpcap-regulator.c
+++ b/drivers/regulator/cpcap-regulator.c
@@ -412,6 +412,82 @@ static struct cpcap_regulator omap4_regulators[] = {
{ /* sentinel */ },
};
+static struct cpcap_regulator tegra_regulators[] = {
+ CPCAP_REG(SW1, CPCAP_REG_S1C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW1_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+ CPCAP_REG(SW2, CPCAP_REG_S2C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW2_SEL, sw2_sw4_val_tbl,
+ 0xf00, 0x7f, 0, 0x800, 0, 120),
+ CPCAP_REG(SW3, CPCAP_REG_S3C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW3_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+ CPCAP_REG(SW4, CPCAP_REG_S4C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW4_SEL, sw2_sw4_val_tbl,
+ 0xf00, 0x7f, 0, 0x900, 0, 100),
+ CPCAP_REG(SW5, CPCAP_REG_S5C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW5_SEL, sw5_val_tbl,
+ 0x2a, 0, 0, 0x22, 0, 0),
+ CPCAP_REG(SW6, CPCAP_REG_S6C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW6_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+ CPCAP_REG(VCAM, CPCAP_REG_VCAMC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VCAM_SEL, vcam_val_tbl,
+ 0x87, 0x30, 4, 0x7, 0, 420),
+ CPCAP_REG(VCSI, CPCAP_REG_VCSIC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VCSI_SEL, vcsi_val_tbl,
+ 0x47, 0x10, 4, 0x7, 0, 350),
+ CPCAP_REG(VDAC, CPCAP_REG_VDACC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VDAC_SEL, vdac_val_tbl,
+ 0x87, 0x30, 4, 0x3, 0, 420),
+ CPCAP_REG(VDIG, CPCAP_REG_VDIGC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VDIG_SEL, vdig_val_tbl,
+ 0x87, 0x30, 4, 0x5, 0, 420),
+ CPCAP_REG(VFUSE, CPCAP_REG_VFUSEC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VFUSE_SEL, vfuse_val_tbl,
+ 0x80, 0xf, 0, 0x80, 0, 420),
+ CPCAP_REG(VHVIO, CPCAP_REG_VHVIOC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VHVIO_SEL, vhvio_val_tbl,
+ 0x17, 0, 0, 0x2, 0, 0),
+ CPCAP_REG(VSDIO, CPCAP_REG_VSDIOC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VSDIO_SEL, vsdio_val_tbl,
+ 0x87, 0x38, 3, 0x2, 0, 420),
+ CPCAP_REG(VPLL, CPCAP_REG_VPLLC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VPLL_SEL, vpll_val_tbl,
+ 0x43, 0x18, 3, 0x1, 0, 420),
+ CPCAP_REG(VRF1, CPCAP_REG_VRF1C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRF1_SEL, vrf1_val_tbl,
+ 0xac, 0x2, 1, 0xc, 0, 10),
+ CPCAP_REG(VRF2, CPCAP_REG_VRF2C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRF2_SEL, vrf2_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 10),
+ CPCAP_REG(VRFREF, CPCAP_REG_VRFREFC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRFREF_SEL, vrfref_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 420),
+ CPCAP_REG(VWLAN1, CPCAP_REG_VWLAN1C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VWLAN1_SEL, vwlan1_val_tbl,
+ 0x47, 0x10, 4, 0x5, 0, 420),
+ CPCAP_REG(VWLAN2, CPCAP_REG_VWLAN2C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VWLAN2_SEL, vwlan2_val_tbl,
+ 0x20c, 0xc0, 6, 0x8, 0, 420),
+ CPCAP_REG(VSIM, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
+ 0xffff, vsim_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 420),
+ CPCAP_REG(VSIMCARD, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
+ 0xffff, vsimcard_val_tbl,
+ 0x1e80, 0x8, 3, 0x1e00, 0, 420),
+ CPCAP_REG(VVIB, CPCAP_REG_VVIBC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VVIB_SEL, vvib_val_tbl,
+ 0x1, 0xc, 2, 0, 0x1, 500),
+ CPCAP_REG(VUSB, CPCAP_REG_VUSBC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VUSB_SEL, vusb_val_tbl,
+ 0x11c, 0x40, 6, 0xc, 0, 0),
+ CPCAP_REG(VAUDIO, CPCAP_REG_VAUDIOC, CPCAP_REG_ASSIGN4,
+ CPCAP_BIT_VAUDIO_SEL, vaudio_val_tbl,
+ 0x16, 0x1, 0, 0x4, 0, 0),
+ { /* sentinel */ },
+};
+
static const struct of_device_id cpcap_regulator_id_table[] = {
{
.compatible = "motorola,cpcap-regulator",
@@ -420,6 +496,10 @@ static const struct of_device_id cpcap_regulator_id_table[] = {
.compatible = "motorola,mapphone-cpcap-regulator",
.data = omap4_regulators,
},
+ {
+ .compatible = "motorola,tegra-cpcap-regulator",
+ .data = tegra_regulators,
+ },
{},
};
MODULE_DEVICE_TABLE(of, cpcap_regulator_id_table);
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2 v2] Add sw2_sw4 voltage table to cpcap regulator.
From: Peter Geis @ 2018-07-23 19:38 UTC (permalink / raw)
To: broonie
Cc: lgirdwood, robh+dt, linux-kernel, devicetree, linux-tegra,
Peter Geis
In-Reply-To: <20180723193848.32491-1-pgwipeout@gmail.com>
SW2 and SW4 use a shared table to provide voltage to the cpu core and
devices on Tegra hardware.
Added this table to the cpcap regulator driver as the first step to
supporting this device on Tegra.
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
---
drivers/regulator/cpcap-regulator.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/regulator/cpcap-regulator.c b/drivers/regulator/cpcap-regulator.c
index bd910fe123d9..c0b1e04bd90f 100644
--- a/drivers/regulator/cpcap-regulator.c
+++ b/drivers/regulator/cpcap-regulator.c
@@ -271,6 +271,29 @@ static struct regulator_ops cpcap_regulator_ops = {
};
static const unsigned int unknown_val_tbl[] = { 0, };
+static const unsigned int sw2_sw4_val_tbl[] = { 612500, 625000, 637500,
+ 650000, 662500, 675000,
+ 687500, 700000, 712500,
+ 725000, 737500, 750000,
+ 762500, 775000, 787500,
+ 800000, 812500, 825000,
+ 837500, 850000, 862500,
+ 875000, 887500, 900000,
+ 912500, 925000, 937500,
+ 950000, 962500, 975000,
+ 987500, 1000000, 1012500,
+ 1025000, 1037500, 1050000,
+ 1062500, 1075000, 1087500,
+ 1100000, 1112500, 1125000,
+ 1137500, 1150000, 1162500,
+ 1175000, 1187500, 1200000,
+ 1212500, 1225000, 1237500,
+ 1250000, 1262500, 1275000,
+ 1287500, 1300000, 1312500,
+ 1325000, 1337500, 1350000,
+ 1362500, 1375000, 1387500,
+ 1400000, 1412500, 1425000,
+ 1437500, 1450000, 1462500, };
static const unsigned int sw5_val_tbl[] = { 0, 5050000, };
static const unsigned int vcam_val_tbl[] = { 2600000, 2700000, 2800000,
2900000, };
--
2.17.1
^ permalink raw reply related
* [PATCH 0/2 v2] Add support for cpcap regulators on Tegra devices.
From: Peter Geis @ 2018-07-23 19:38 UTC (permalink / raw)
To: broonie
Cc: lgirdwood, robh+dt, linux-kernel, devicetree, linux-tegra,
Peter Geis
Good Afternoon,
I am re-sending the whole patch set again.
I have sent this to myself, and confirmed it still patches cleanly.
I apologize once again.
The CPCAP regulator driver can support various devices, but currently only supports Omap4 devices.
Adds the sw2 and sw4 voltage tables, which power the Tegra core, and a DT match for the Tegra device.
Tested on the Motorola Xoom MZ602.
v2:
Stopped reinventing the wheel, using git email now.
Rebased against regulator for-next branch.
v1:
Fix conversion of tabulation to spaces.
Peter Geis (2):
Add sw2_sw4 voltage table to cpcap regulator.
Add support for CPCAP regulators on Tegra devices.
.../bindings/regulator/cpcap-regulator.txt | 1 +
drivers/regulator/cpcap-regulator.c | 103 ++++++++++++++++++
2 files changed, 104 insertions(+)
--
2.17.1
^ permalink raw reply
* [Buildroot] [PATCH] package/binutils: fix xtensa linker relaxation regression in 2.31.1
From: Max Filippov @ 2018-07-23 19:37 UTC (permalink / raw)
To: buildroot
Fix the following xtensa ld error observed when building uClibc-ng
libthread_db with binutils-2.31:
BFD (GNU Binutils) 2.31 internal error, aborting at
elf32-xtensa.c:3269 in elf_xtensa_finish_dynamic_sections
Fixes: https://gitlab.com/free-electrons/toolchains-builder/-/jobs/82264912
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
...relaxation-of-undefined-weak-references-i.patch | 48 ++++++++++++
...-dynamic-relocations-sections-consistency.patch | 90 ++++++++++++++++++++++
2 files changed, 138 insertions(+)
create mode 100644 package/binutils/2.31.1/0010-xtensa-fix-relaxation-of-undefined-weak-references-i.patch
create mode 100644 package/binutils/2.31.1/0011-xtensa-move-dynamic-relocations-sections-consistency.patch
diff --git a/package/binutils/2.31.1/0010-xtensa-fix-relaxation-of-undefined-weak-references-i.patch b/package/binutils/2.31.1/0010-xtensa-fix-relaxation-of-undefined-weak-references-i.patch
new file mode 100644
index 000000000000..660d30c38925
--- /dev/null
+++ b/package/binutils/2.31.1/0010-xtensa-fix-relaxation-of-undefined-weak-references-i.patch
@@ -0,0 +1,48 @@
+From 5d3a462f05cba5b0c0c96de899b84fb84155c760 Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+Date: Sun, 22 Jul 2018 13:52:28 -0700
+Subject: [PATCH] xtensa: fix relaxation of undefined weak references in
+ shared objects
+
+The change c451bb34ae8b ("xtensa: don't emit dynamic relocation for weak
+undefined symbol") didn't properly handle shrinking of relocation
+sections due to coalescing of references to a dynamic undefined weak
+symbol in a shared object, which resulted in the following assertion
+failure in ld when linking uClibc-ng libthread_db for xtensa:
+
+ BFD (GNU Binutils) 2.31 internal error, aborting at elf32-xtensa.c:3269
+ in elf_xtensa_finish_dynamic_sections
+
+Shrink dynamic relocations section for dynamic undefined weak symbols
+when linking a shared object.
+
+bfd/
+2018-07-23 Max Filippov <jcmvbkbc@gmail.com>
+
+ * elf32-xtensa.c (shrink_dynamic_reloc_sections): Shrink dynamic
+ relocations section for dynamic undefined weak symbols when
+ linking a shared object.
+
+Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
+Backported from: 5d3a462f05cba5b0c0c96de899b84fb84155c760
+---
+ bfd/elf32-xtensa.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/bfd/elf32-xtensa.c b/bfd/elf32-xtensa.c
+index f7f569d0c086..a4b046e445f1 100644
+--- a/bfd/elf32-xtensa.c
++++ b/bfd/elf32-xtensa.c
+@@ -10022,7 +10022,8 @@ shrink_dynamic_reloc_sections (struct bfd_link_info *info,
+ if ((r_type == R_XTENSA_32 || r_type == R_XTENSA_PLT)
+ && (input_section->flags & SEC_ALLOC) != 0
+ && (dynamic_symbol || bfd_link_pic (info))
+- && (!h || h->root.type != bfd_link_hash_undefweak))
++ && (!h || h->root.type != bfd_link_hash_undefweak
++ || (dynamic_symbol && bfd_link_dll (info))))
+ {
+ asection *srel;
+ bfd_boolean is_plt = FALSE;
+--
+2.11.0
+
diff --git a/package/binutils/2.31.1/0011-xtensa-move-dynamic-relocations-sections-consistency.patch b/package/binutils/2.31.1/0011-xtensa-move-dynamic-relocations-sections-consistency.patch
new file mode 100644
index 000000000000..2c12ce3db1d9
--- /dev/null
+++ b/package/binutils/2.31.1/0011-xtensa-move-dynamic-relocations-sections-consistency.patch
@@ -0,0 +1,90 @@
+From f82863d797e461b936dff2b659a3aa65088ee87e Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+Date: Sun, 22 Jul 2018 18:59:11 -0700
+Subject: [PATCH] xtensa: move dynamic relocations sections consistency
+ check
+
+The function elf_xtensa_finish_dynamic_sections checks that sizes of
+sections .rela.dyn and .rela.plt match number of corresponding relocation
+records, but the check is only done when .rela.plt is non-empty, so, e.g.
+it is never run for the static PIE.
+Rearrange the test so that .rela.dyn and .rela.plt are checked always.
+
+bfd/
+2018-07-23 Max Filippov <jcmvbkbc@gmail.com>
+
+ * elf32-xtensa.c (elf_xtensa_finish_dynamic_sections): Move
+ relocation sections consistency check to always check both
+ .rela.dyn and .rela.plt when they exist. Rearrange variable
+ definition and assignment places.
+
+Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
+Backported from: f82863d797e461b936dff2b659a3aa65088ee87e
+---
+ bfd/elf32-xtensa.c | 22 +++++++++++-----------
+ 1 file changed, 11 insertions(+), 11 deletions(-)
+
+diff --git a/bfd/elf32-xtensa.c b/bfd/elf32-xtensa.c
+index a4b046e445f1..cf085b7b0751 100644
+--- a/bfd/elf32-xtensa.c
++++ b/bfd/elf32-xtensa.c
+@@ -3156,7 +3156,7 @@ elf_xtensa_finish_dynamic_sections (bfd *output_bfd,
+ {
+ struct elf_xtensa_link_hash_table *htab;
+ bfd *dynobj;
+- asection *sdyn, *srelplt, *sgot, *sxtlit, *sgotloc;
++ asection *sdyn, *srelplt, *srelgot, *sgot, *sxtlit, *sgotloc;
+ Elf32_External_Dyn *dyncon, *dynconend;
+ int num_xtlit_entries = 0;
+
+@@ -3186,15 +3186,15 @@ elf_xtensa_finish_dynamic_sections (bfd *output_bfd,
+ }
+
+ srelplt = htab->elf.srelplt;
++ srelgot = htab->elf.srelgot;
+ if (srelplt && srelplt->size != 0)
+ {
+- asection *sgotplt, *srelgot, *spltlittbl;
++ asection *sgotplt, *spltlittbl;
+ int chunk, plt_chunks, plt_entries;
+ Elf_Internal_Rela irela;
+ bfd_byte *loc;
+ unsigned rtld_reloc;
+
+- srelgot = htab->elf.srelgot;
+ spltlittbl = htab->spltlittbl;
+ BFD_ASSERT (srelgot != NULL && spltlittbl != NULL);
+
+@@ -3260,14 +3260,6 @@ elf_xtensa_finish_dynamic_sections (bfd *output_bfd,
+ spltlittbl->contents + (chunk * 8) + 4);
+ }
+
+- /* All the dynamic relocations have been emitted at this point.
+- Make sure the relocation sections are the correct size. */
+- if (srelgot->size != (sizeof (Elf32_External_Rela)
+- * srelgot->reloc_count)
+- || srelplt->size != (sizeof (Elf32_External_Rela)
+- * srelplt->reloc_count))
+- abort ();
+-
+ /* The .xt.lit.plt section has just been modified. This must
+ happen before the code below which combines adjacent literal
+ table entries, and the .xt.lit.plt contents have to be forced to
+@@ -3282,6 +3274,14 @@ elf_xtensa_finish_dynamic_sections (bfd *output_bfd,
+ spltlittbl->flags &= ~SEC_HAS_CONTENTS;
+ }
+
++ /* All the dynamic relocations have been emitted at this point.
++ Make sure the relocation sections are the correct size. */
++ if ((srelgot && srelgot->size != (sizeof (Elf32_External_Rela)
++ * srelgot->reloc_count))
++ || (srelplt && srelplt->size != (sizeof (Elf32_External_Rela)
++ * srelplt->reloc_count)))
++ abort ();
++
+ /* Combine adjacent literal table entries. */
+ BFD_ASSERT (! bfd_link_relocatable (info));
+ sxtlit = bfd_get_section_by_name (output_bfd, ".xt.lit");
+--
+2.11.0
+
--
2.11.0
^ permalink raw reply related
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.