* sandbox: CONFIG_SYS_RELOC_GD_ENV_ADDR?
From: Tom Rini @ 2020-02-14 19:43 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ1rrPKK+rTBAO4wQAXjNX-G4q9P=j_wo-PY1FtDV1jehw@mail.gmail.com>
On Fri, Feb 14, 2020 at 12:16:33PM -0700, Simon Glass wrote:
> Hi AKASHI,
>
> On Thu, 13 Feb 2020 at 18:39, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> >
> > Tom, Simon,
> >
> > Is CONFIG_SYS_RELOC_GD_ENV_ADDR really needed on sandbox?
> >
> > When I try to have a variable environment on emulated SPI flash,
> > the U-Boot binary always crashes: (NOTE: assuming CONFIG_ENV_ADDR == 0)
> > $ dd if=/dev/zero of=./spi.bin bs=1M count=4
> > $ u-boot -T
> > U-Boot 2020.04-rc2-00015-gc9afef2b1938-dirty (Feb 14 2020 - 10:24:59 +0900)
> >
> > Model: sandbox
> > DRAM: 128 MiB
> > WDT: Started with servicing (60s timeout)
> > MMC: mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
> > Loading Environment from SPI Flash... SF: Detected m25p16 with page size 256 Bytes, erase size 64 KiB, total 2 MiB
> > *** Warning - bad CRC, using default environment
> >
> > Segmentation fault (core dumped)
> >
> > If this configuration is disabled, panic doesn't happen.
> > I think that it should be turned off in any sandbox*_defconfig.
> >
> > In addition, please update
> > - doc/arch/sandbox.rst
> > - doc/SPI/README.sandbox-spi
> > Both two still mention already-removed command line option, --spi_sf.
> > It is confusing.
>
> I'm not an expert on this, but I can't see any use for this in
> sandbox. One problem might be that it should be using map_sysmem()
> instead of a cast.
If the option needs to be dropped for things to work, we should just
drop it. When migrating some of the logic here in to CONFIG symbols I
did match, I'm pretty certain, the previous behavior. But there's been
a few other cases I got backwards, so this could have been another. So
long as 'make tests' is happy after the change, we should just do it.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200214/42a2ee13/attachment.sig>
^ permalink raw reply
* Re: [PATCH v2 01/19] tests/tcg: include a skip runner for pauth3 with plugins
From: Robert Foley @ 2020-02-14 19:41 UTC (permalink / raw)
To: Alex Bennée
Cc: fam, Peter Maydell, berrange, pbonzini, stefanb,
Richard Henderson, qemu-devel, robhenry, f4bug, marcandre.lureau,
aaron, cota, stefanha, kuhn.chenqun, Peter Puhov,
open list:ARM TCG CPUs, aurelien
In-Reply-To: <20200213225109.13120-2-alex.bennee@linaro.org>
On Thu, 13 Feb 2020 at 17:51, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> If we have plugins enabled we still need to have built the test to be
> able to run it.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Robert Foley <robert.foley@linaro.org>
^ permalink raw reply
* Re: BLKSECDISCARD ioctl and hung tasks
From: Salman Qazi @ 2020-02-14 19:42 UTC (permalink / raw)
To: Ming Lei
Cc: Bart Van Assche, Ming Lei, Jens Axboe, Christoph Hellwig,
Linux Kernel Mailing List, linux-block, Gwendal Grignou,
Jesse Barnes
In-Reply-To: <CACVXFVP114+QBhw1bXqwgKRw_s4tBM_ZkuvjdXEU7nwkbJuH1Q@mail.gmail.com>
On Fri, Feb 14, 2020 at 1:23 AM Ming Lei <tom.leiming@gmail.com> wrote:
>
> On Fri, Feb 14, 2020 at 1:50 PM Bart Van Assche <bvanassche@acm.org> wrote:
> >
> > On 2020-02-13 11:21, Salman Qazi wrote:
> > > AFAICT, This is not actually sufficient, because the issuer of the bio
> > > is waiting for the entire bio, regardless of how it is split later.
> > > But, also there isn't a good mapping between the size of the secure
> > > discard and how long it will take. If given the geometry of a flash
> > > device, it is not hard to construct a scenario where a relatively
> > > small secure discard (few thousand sectors) will take a very long time
> > > (multiple seconds).
> > >
> > > Having said that, I don't like neutering the hung task timer either.
> >
> > Hi Salman,
> >
> > How about modifying the block layer such that completions of bio
> > fragments are considered as task activity? I think that bio splitting is
> > rare enough for such a change not to affect performance of the hot path.
>
> Are you sure that the task hung warning won't be triggered in case of
> non-splitting?
I demonstrated a few emails ago that it doesn't take a very large
secure discard command to trigger this. So, I am sceptical that we
will be able to use splitting to solve this.
>
> >
> > How about setting max_discard_segments such that a discard always
> > completes in less than half the hung task timeout? This may make
> > discards a bit slower for one particular block driver but I think that's
> > better than hung task complaints.
>
> I am afraid you can't find a golden setting max_discard_segments working
> for every drivers. Even it is found, the performance may have been affected.
>
> So just wondering why not take the simple approach used in blk_execute_rq()?
My colleague Gwendal pointed out another issue which I had missed:
secure discard is an exclusive command: it monopolizes the device.
Even if we fix this via your approach, it will show up somewhere else,
because other operations to the drive will not make progress for that
length of time.
For Chromium OS purposes, if we had a blank slate, this is how I would solve it:
* Under the assumption that the truly sensitive data is not very big:
* Keep secure data on a separate partition to make sure that those
LBAs have controlled history
* Treat the files in that partition as immutable (i.e. no
overwriting the contents of the file without first secure erasing the
existing contents).
* By never letting more than one version of the file accumulate,
we can guarantee that the secure erase will always be fast for
moderate sized files.
But for all the existing machines with keys on them, we will need to
do something else.
>
> Thanks,
> Ming Lei
^ permalink raw reply
* Re: [PATCH nf-next v4 5/9] nf_tables: Add set type for arbitrary concatenation of ranges
From: Stefano Brivio @ 2020-02-14 19:42 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, Florian Westphal, Kadlecsik József,
Eric Garver, Phil Sutter
In-Reply-To: <20200214181634.cacy3elfwnankvop@salvia>
On Fri, 14 Feb 2020 19:16:34 +0100
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Mon, Feb 10, 2020 at 04:10:47PM +0100, Stefano Brivio wrote:
> > On Fri, 7 Feb 2020 12:23:08 +0100
> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> [...]
> > > Did you tests with 8-bits grouping instead of 4-bits?
> >
> > Yes, at the very beginning, not with the final implementation. It was
> > somewhat faster (on x86_64, I don't remember how much) for small
> > numbers of rules, then I thought we would use too much memory, because:
> >
> > > Assuming a concatenation of 12 bytes (each field 4 bytes, hence 3
> > > fields):
> > >
> > > * Using 4-bits groups: the number of buckets is 2^4 = 16 multiplied
> > > by the bucket word (assuming one long word, 8 bytes, 64 pipapo
> > > rules) is 16 * 8 = 128 bytes per group-row in the looking table. Then,
> > > the number of group-rows is 8 given that 32 bits, then 32 / 4 = 8
> > > group-rows.
> > >
> > > 8 * 128 bytes = 1024 bytes per lookup table.
> > >
> > > Assuming 3 fields, then this is 1024 * 3 = 3072 bytes.
> > >
> > > * Using 8-bits groups: 2^8 = 256, then 256 * 8 = 2048 bytes per
> > > group-row. Then, 32 / 8 = 4 group-rows in total.
> > >
> > > 4 * 2048 bytes = 8192 bytes per lookup table.
> > >
> > > Therefore, 3 * 8192 = 24576 bytes. Still rather small.
> > >
> > > This is missing the mapping table that links the lookup tables in the
> > > memory counting. And I'm assuming that the number of pipapo rules in
> > > the lookup table fits into 64-bits bucket long word.
> >
> > ...the (reasonable?) worst case I wanted to cover was two IPv6
> > addresses, one port, one MAC address (in ipset terms
> > "net,net,port,mac"), with 2 ^ 16 unique, non-overlapping entries each
> > (or ranges expanding to that amount of rules), because that's what
> > (single, non-concatenated) ipset "bitmap" types can do.
>
> I see, so you were considering the worst case. You're assuming each
> element takes exactly one pipapo rule, so it's 2^16 elements, correct?
Yes, right: the ranges I considered would be disjoint and of size one
(single, non-overlapping addresses). I start thinking my worst case is
nowhere close to being reasonable, actually. :)
> You refer to a property that says that you can split a range into a
> 2*n netmasks IIRC. Do you know what is the worst case when splitting
> ranges?
I'm not sure I got your question: that is exactly the worst case, i.e.
we can have _up to_ 2 * n netmasks (hence rules) given a range of n
bits. There's an additional upper bound on this, given by the address
space, but single fields in a concatenation can overlap.
For example, we can have up to 128 rules for an IPv6 range where at
least 64 bits differ between the endpoints, and which would contain
2 ^ 64 addresses. Or, say, the IPv4 range 1.2.3.4 - 255.255.0.2 is
expressed by 42 rules.
By the way, 0.0.0.1 - 255.255.255.254 takes 62 rules, so we can
*probably* say it's 2 * n - 2, but I don't have a formal proof for that.
I have a couple of ways in mind to get that down to n / 2, but it's not
straightforward and it will take me some time (assuming it makes
sense). For the n bound, we can introduce negations (proof in
literature), and I have some kind of ugly prototype. For the n / 2
bound, I'd need some auxiliary data structure to keep insertion
invertible.
In practice, the "average" case is much less, but to define it we would
first need to agree on what are the actual components of the
multivariate distribution... size and start? Is it a Poisson
distribution then? After spending some time on this and disagreeing
with myself I'd shyly recommend to skip the topic. :)
> There is no ipset set like this, but I agree usecase might happen.
Actually, for ipset, a "net,port,net,port" type was proposed
(netfilter-devel <20181216213039.399-1-oliver@uptheinter.net>), but when
József enquired about the intended use case, none was given. So maybe
this whole "net,net,port,mac" story makes even less sense.
> > Also ignoring the mapping table (it's "small"), with 4-bit buckets:
> >
> > - for the IPv6 addresses, we have 16 buckets, each 2 ^ 16
> > bits wide, and 32 groups (128 bits / 4 bits), that is, 8MiB in
> > total
> >
> > - for the MAC address, 16 buckets, each 2 ^ 16 bits wide, and 12
> > groups, 1.5MiB
> >
> > - for the port, 16 buckets, each 2 ^ 12 bits wide, 2 groups, 0.25MiB
> >
> > that is, 9.75MiB.
> >
> > With 8-bit buckets: we can just multiply everything by 8 (that is,
> > 2 ^ 8 / 2 ^ 4 / 2, because we have 2 ^ (8 - 4) times the buckets, with
> > half the groups), 78MiB.
>
> Yes, this is large. Compared to a hashtable with 2^16 entries, then
> it's 2^17 hashtable buckets and using struct hlist_head, this is 2
> MBytes. Then, each hlist_node is 16 bytes, so 2^16 * 16 ~= 1 MByte.
> That is 3 MBytes if my maths are fine.
Sounds correct to me as well.
> Just telling this to find what could be considered as reasonable
> amount of memory to be consumed. ~10 MBytes is slightly more than, but
> I agree you selected a reasonable worst through this "complex tuple".
>
> > And that started feeling like "a lot". However, I'm probably overdoing
> > with the worst case -- this was just to explain what brought me to the
> > 4-bit choice, now I start doubting about it.
> >
> > > Anyway, my understanding is that the more bits you use for grouping,
> > > the larger the lookup table becomes.
> > >
> > > Still, both look very small in terms of memory consumption for these
> > > days.
> > >
> > > I'm just telling this because the C implementation can probably get
> > > better numbers at the cost of consuming more memory? Probably do this
> > > at some point?
> >
> > Another topic is the additional amount of cachelines we would use. I
> > don't expect that effect to be visible, but I might be wrong.
> >
> > So yes, I think it's definitely worth a try, thanks for the hint! I'll
> > try to look into this soon and test it on a few archs (something with
> > small cachelines, say MIPS r2k, would be worth checking, too).
> >
> > We could even consider to dynamically adjust group size depending on
> > the set size, I don't know yet if that gets too convoluted.
>
> Yes, keeping this maintainable is a good idea.
>
> The per-cpu scratch index is only required if we cannot fit in the
> "result bitmap" into the stack, right?
Right.
> Probably up to 256 bytes result bitmap in the stack is reasonable?
> That makes 8192 pipapo rules. There will be no need to disable bh and
> make use of the percpu scratchpad area in that case.
Right -- the question is whether that would mean yet another
implementation for the lookup function.
> If adjusting the code to deal with variable length "pipapo word" size
> is not too convoluted, then you could just deal with the variable word
> size from the insert / delete / get (slow) path and register one
> lookup function for the version that is optimized for this pipapo word
> size.
Yes, I like this a lot -- we would also need one function to rebuild
tables when the word size changes, but that sounds almost trivial.
Changes for the slow path are actually rather simple.
Still, I start doubting quite heavily that my original worst case is
reasonable. If we stick to the one you mentioned, or even something in
between, it makes no sense to keep 4-bit buckets.
By the way, I went ahead and tried the 8-bit bucket version of the C
implementation only, on my usual x86_64 box (one thread, AMD Epyc 7351).
I think it's worth it:
4-bit 8-bit
net,port
1000 entries 2304165pps 2901299pps
port,net
100 entries 4131471pps 4751247pps
net6,port
1000 entries 1092557pps 1651037pps
port,proto
30000 entries 284147pps 449665pps
net6,port,mac
10 entries 2082880pps 2762291pps
net6,port,mac,proto
1000 entries 783810pps 1195823pps
net,mac
1000 entries 1279122pps 1934003pps
I would now proceed extending this to the AVX2 implementation and (once
I finish it) to the NEON one, I actually expect bigger gains there.
> Probably adding helper function to deal with pipapo words would help
> to prepare for such update in the future. There is the ->estimate
> function that allows to calculate for the best word size depending on
> all the information this gets from the set definition.
Hm, I really think it should be kind of painless to make this dynamic
on insertion/deletion.
--
Stefano
^ permalink raw reply
* Re: [PATCH 0/9] recipe updates, testing fixes
From: Khem Raj @ 2020-02-14 19:42 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: OE-core
In-Reply-To: <CANNYZj_bCoU-NzoKqzjTvjOr=g6LKECDPE7S7i2xpsrfYeHsKQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]
On Fri, Feb 14, 2020 at 11:21 AM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:
> I got to it finally. Normally /var/lib/rpm is absent when opkg is in use,
> but when /usr/bin/rpm is present, python3's ptest involves distutils test
> creating rpm packages (and presumably installing them too), which creates a
> database in /var/lib/rpm, which then triggers rpm tests to run and fail. So
> a check for /var/lib/rpm in rpm tests isn't always sufficient to determine
> which packaging system is in use, and there should be a stronger one.
>
> I'm fine with adjusting libsolv to not pull in rpm, but please use
> EXCLUDE_FROM_WORLD instead of PNBLACKLIST, so that just that specific
> problem is solved, rather than banning libdnf/dnf altogether from builds.
>
Blacklisting is superior since this will also catch accidental inclusion of
these packages when not using rpm backend where as EXCLUDE_FROM_WORLD will
only be effective on word target
> Making libdnf to not require rpm-enabled libsolv is not feasible sadly,
> it's basically built around that assumption.
>
Exactly
>
> Alex
>
> On Fri, 14 Feb 2020 at 13:19, Alexander Kanavin <alex.kanavin@gmail.com>
> wrote:
>
>> On Fri, 14 Feb 2020 at 08:15, Khem Raj <raj.khem@gmail.com> wrote:
>>
>>> local.conf I have
>>>
>>> DISTRO_FEATURES_append = " largefile opengl ptest multiarch wayland pam
>>> polkit "
>>> IMAGE_CLASSES += "testimage testsdk"
>>>
>>
>> Right, I'm running this now, it's a bit tricky because I have to do it on
>> the Yocto AB. Big company's bureaucracy is causing delays in getting me a
>> build machine :(
>>
>> Alex
>>
>
[-- Attachment #2: Type: text/html, Size: 3017 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/19] tests/tcg: include a skip runner for pauth3 with plugins
From: Robert Foley @ 2020-02-14 19:41 UTC (permalink / raw)
To: Alex Bennée
Cc: qemu-devel, cota, aaron, Peter Puhov, kuhn.chenqun, robhenry, fam,
berrange, f4bug, Richard Henderson, balrogg, aurelien, pbonzini,
stefanha, stefanb, marcandre.lureau, Peter Maydell,
open list:ARM TCG CPUs
In-Reply-To: <20200213225109.13120-2-alex.bennee@linaro.org>
On Thu, 13 Feb 2020 at 17:51, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> If we have plugins enabled we still need to have built the test to be
> able to run it.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Robert Foley <robert.foley@linaro.org>
^ permalink raw reply
* Re: [PATCH] libselinux: drop error return from is_selinux_enabled documentation
From: Stephen Smalley @ 2020-02-14 19:42 UTC (permalink / raw)
To: Christian Göttsche, selinux
In-Reply-To: <20200214184751.8211-1-cgzones@googlemail.com>
On 2/14/20 1:47 PM, Christian Göttsche wrote:
> Since commit e3cab998b48ab293a9962faf9779d70ca339c65d ("libselinux
> mountpoint changing patch.") for version 20120216 is_selinux_enabled()
> does never return -1; drop mentions in the man-page and header file.
>
> Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
> libselinux/include/selinux/selinux.h | 2 +-
> libselinux/man/man3/is_selinux_enabled.3 | 1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libselinux/include/selinux/selinux.h b/libselinux/include/selinux/selinux.h
> index 7922d96b..883d8b85 100644
> --- a/libselinux/include/selinux/selinux.h
> +++ b/libselinux/include/selinux/selinux.h
> @@ -8,7 +8,7 @@
> extern "C" {
> #endif
>
> -/* Return 1 if we are running on a SELinux kernel, or 0 if not or -1 if we get an error. */
> +/* Return 1 if we are running on a SELinux kernel, or 0 otherwise. */
> extern int is_selinux_enabled(void);
> /* Return 1 if we are running on a SELinux MLS kernel, or 0 otherwise. */
> extern int is_selinux_mls_enabled(void);
> diff --git a/libselinux/man/man3/is_selinux_enabled.3 b/libselinux/man/man3/is_selinux_enabled.3
> index df62c225..a887b48c 100644
> --- a/libselinux/man/man3/is_selinux_enabled.3
> +++ b/libselinux/man/man3/is_selinux_enabled.3
> @@ -15,7 +15,6 @@ is_selinux_mls_enabled \- check whether SELinux is enabled for (Multi Level Secu
> .SH "DESCRIPTION"
> .BR is_selinux_enabled ()
> returns 1 if SELinux is running or 0 if it is not.
> -On error, \-1 is returned.
>
> .BR is_selinux_mls_enabled ()
> returns 1 if SELinux is capable of running in MLS mode or 0 if it is not. To
>
^ permalink raw reply
* [PATCH AUTOSEL 4.9 081/141] soc: fsl: qe: remove set but not used variable 'mm_gc'
From: Sasha Levin @ 2020-02-14 16:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Chen Zhou, YueHaibing, Li Yang, Hulk Robot,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20200214162122.19794-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit 6e62bd36e9ad85a22d92b1adce6a0336ea549733 ]
drivers/soc/fsl/qe/gpio.c: In function qe_pin_request:
drivers/soc/fsl/qe/gpio.c:163:26: warning: variable mm_gc set but not used [-Wunused-but-set-variable]
commit 1e714e54b5ca ("powerpc: qe_lib-gpio: use gpiochip data pointer")
left behind this unused variable.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/soc/fsl/qe/gpio.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/gpio.c b/drivers/soc/fsl/qe/gpio.c
index b5a7107a9c0a9..de2c0b6f72a1f 100644
--- a/drivers/soc/fsl/qe/gpio.c
+++ b/drivers/soc/fsl/qe/gpio.c
@@ -137,7 +137,6 @@ struct qe_pin *qe_pin_request(struct device_node *np, int index)
{
struct qe_pin *qe_pin;
struct gpio_chip *gc;
- struct of_mm_gpio_chip *mm_gc;
struct qe_gpio_chip *qe_gc;
int err;
unsigned long flags;
@@ -163,7 +162,6 @@ struct qe_pin *qe_pin_request(struct device_node *np, int index)
goto err0;
}
- mm_gc = to_of_mm_gpio_chip(gc);
qe_gc = gpiochip_get_data(gc);
spin_lock_irqsave(&qe_gc->lock, flags);
--
2.20.1
^ permalink raw reply related
* Re: [Virtio-fs] One virtiofs daemon per exported dir requirement
From: Dr. David Alan Gilbert @ 2020-02-14 19:41 UTC (permalink / raw)
To: Vivek Goyal; +Cc: virtio-fs-list, Mrunal Patel, Miklos Szeredi
In-Reply-To: <20200214192705.GE18654@redhat.com>
* Vivek Goyal (vgoyal@redhat.com) wrote:
> Hi,
>
> Dan Walsh and Mrunal mentioned that one virtiofsd daemon per exported
> directory requirement sounds excessive. For container use case, they have
> atleast 2-3 more directories they need to export (secrets and /etc/host). And
> that means 3-4 virtiofsd running for each kata container.
>
> One option seems that bind mount all exports in one directory and export
> that directory using one virtiofsd. I am aware of atleast one problem
> with that configuraiton and that is possibility of inode number collision
> if bind mounts are coming from different devices. Not sure how many
> applications care though. Sergio is looking into solving this issue. It
> might take a while though.
I thought the bind mount setup was the normal setup seen under both Kata
and k8s?
Dave
> Any other thoughts?
>
> Thanks
> Vivek
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* [Intel-gfx] [PATCH i-g-t 4/4] lib/i915/gem_engine_topology.c - intel_get_current_engine invalid result
From: Chris Wilson @ 2020-02-14 19:40 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
In-Reply-To: <20200214194016.4054376-1-chris@chris-wilson.co.uk>
From: Dale B Stimson <dale.b.stimson@intel.com>
Function intel_get_current_engine() should return NULL (instead of
engine 0) if there are no engines.
Function intel_init_engine_list() should not store potential engine
data in the output structure unless the engine is present.
Function intel_init_engine_list() should arguably not filter the static
engine list with gem_has_ring if fd == -1, so that subtests can still
be individually invoked to show subtest FAIL instead of test notrun.
Symptom: A device open failure in gem_ctx_isolation resulted in
an endless __for_each_physical_engine "per-engine" loop with the
purported last potential engine being processed every time.
Diagnosis: device open (or debugfs open) failed, leaving fd == -1.
Control skipped the rest of the initial igt_fixture block, after
which an attempt was made to iterate through engines using macro
__for_each_physical_engine.
Macro __for_each_physical_engine called intel_init_engine_list()
to initialize the loop control data. Because fd == -1,
intel_init_engine_list() fell back to using __for_each_static_engine().
All of the engines in the static engine list are rejected due to
gem_has_ring returning false (because of fd == -1), leaving 0 engines.
That resulted in loop control data with engine_data.nengines == 0
and the data for the last engine considered stored at index 0.
Still in macro __for_each_physical_engine, intel_get_current_engine()
was called to get the engine to process. It should have returned NULL,
but instead returned the engine entry at index 0, which
had received information describing the last potential engine.
This happened without end.
Signed-off-by: Dale B Stimson <dale.b.stimson@intel.com>
Acked-by: Antonio Argenziano <antonio.argenziano@intel.com>
---
lib/i915/gem_engine_topology.c | 29 ++++++++++++++++-------------
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
index ca1c1fdb9..1f530bfa3 100644
--- a/lib/i915/gem_engine_topology.c
+++ b/lib/i915/gem_engine_topology.c
@@ -156,10 +156,10 @@ static void query_engine_list(int fd, struct intel_engine_data *ed)
struct intel_execution_engine2 *
intel_get_current_engine(struct intel_engine_data *ed)
{
- if (!ed->n)
- ed->current_engine = &ed->engines[0];
- else if (ed->n >= ed->nengines)
+ if (ed->n >= ed->nengines)
ed->current_engine = NULL;
+ else if (!ed->n)
+ ed->current_engine = &ed->engines[0];
return ed->current_engine;
}
@@ -211,18 +211,21 @@ struct intel_engine_data intel_init_engine_list(int fd, uint32_t ctx_id)
igt_debug("using pre-allocated engine list\n");
__for_each_static_engine(e2) {
- struct intel_execution_engine2 *__e2 =
- &engine_data.engines[engine_data.nengines];
-
- strcpy(__e2->name, e2->name);
- __e2->instance = e2->instance;
- __e2->class = e2->class;
- __e2->flags = e2->flags;
- __e2->is_virtual = false;
-
if (igt_only_list_subtests() ||
- gem_has_ring(fd, e2->flags))
+ (fd < 0) ||
+ gem_has_ring(fd, e2->flags)) {
+ struct intel_execution_engine2 *__e2 =
+ &engine_data.engines[
+ engine_data.nengines];
+
+ strcpy(__e2->name, e2->name);
+ __e2->instance = e2->instance;
+ __e2->class = e2->class;
+ __e2->flags = e2->flags;
+ __e2->is_virtual = false;
+
engine_data.nengines++;
+ }
}
return engine_data;
}
--
2.25.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [meta-oe] spidev-test: Add initial version of recipe
From: Jonathan Richardson @ 2020-02-14 19:41 UTC (permalink / raw)
To: openembedded-devel; +Cc: Arun Parameswaran
In-Reply-To: <20200213232346.109257-1-jonathan.richardson@broadcom.com>
-----Original Message-----
From: Jonathan Richardson [mailto:jonathan.richardson@broadcom.com]
Sent: Thursday, February 13, 2020 3:24 PM
To: openembedded-devel@lists.openembedded.org
Cc: Arun Parameswaran; Jonathan Richardson
Subject: [meta-oe] spidev-test: Add initial version of recipe
From: Arun Parameswaran <arun.parameswaran@broadcom.com>
Allows for testing SPI interface using spidev driver and is part of the
kernel tools.
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
---
.../recipes-kernel/spidev-test/spidev-test.bb | 30 +++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 meta-oe/recipes-kernel/spidev-test/spidev-test.bb
diff --git a/meta-oe/recipes-kernel/spidev-test/spidev-test.bb
b/meta-oe/recipes-kernel/spidev-test/spidev-test.bb
new file mode 100644
index 000000000..7dd199fe9
--- /dev/null
+++ b/meta-oe/recipes-kernel/spidev-test/spidev-test.bb
@@ -0,0 +1,30 @@
+SUMMARY = "Test SPI devices"
+DESCRIPTION = "SPI testing utility using the spidev driver"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6
"
+DEPENDS = "binutils elfutils"
Doesn't look like these dependencies aren't required. I'm going to remove
them.
^ permalink raw reply related
* Re: get-lore-mbox: quickly grab full threads from lore
From: Toke Høiland-Jørgensen @ 2020-02-14 19:40 UTC (permalink / raw)
To: Kevin Hilman, Konstantin Ryabitsev, workflows
In-Reply-To: <7hwo8p9db1.fsf@baylibre.com>
Kevin Hilman <khilman@baylibre.com> writes:
> Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:
>
>> I'd like your opinion on this quick helper script I wrote that uses any
>> message-id to grab a full thread from lore.kernel.org and save it as a
>> mbox file.
>
> This is very useful, thank you!
>
> One question/request: Is there a way for it to only grab a subset of a
> series? e.g. Some series contain patches that might end up going
> through a couple different trees (e.g. DT patches typically take a
> separate path than drivers) so as a maintainer for one of the
> subsystems, I might want to only get a subset of the series into an
> mbox, not the whole thing.
>
> IOW, Right now even if I pass a msgid from the middle of the series, it
> finds the whole series (which is cool!), but what if I want to apply
> just that single patch? Or even better, I might want to only apply
> patches 3-5 and 9 from a 10-patch series.
>
> Is this something do-able?
git am --interactive ?
-Toke
^ permalink raw reply
* [Intel-gfx] [PATCH i-g-t 1/4] i915/gem_ctx_engines: Exercise 0 engines[]
From: Chris Wilson @ 2020-02-14 19:40 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
Setup a context with no engines, and make sure we reject all execution
attempts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
tests/i915/gem_ctx_engines.c | 45 ++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index cb82f08ef..063140e0f 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -242,6 +242,48 @@ static void idempotent(int i915)
gem_context_destroy(i915, p.ctx_id);
}
+static uint32_t batch_create(int i915)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle = gem_create(i915, 4096);
+
+ gem_write(i915, handle, 0, &bbe, sizeof(bbe));
+ return handle;
+}
+
+static void none(int i915)
+{
+ struct i915_context_param_engines engines = {};
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(&engines),
+ .size = sizeof(engines),
+ };
+
+ gem_context_set_param(i915, &p);
+
+ {
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = batch_create(i915),
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&obj),
+ .buffer_count = 1,
+ .rsvd1 = p.ctx_id,
+ };
+
+ for (execbuf.flags = 0;
+ execbuf.flags <= I915_EXEC_RING_MASK;
+ execbuf.flags++)
+ igt_assert_eq(__gem_execbuf(i915, &execbuf), -EINVAL);
+
+ gem_close(i915, obj.handle);
+ }
+
+ gem_context_destroy(i915, p.ctx_id);
+}
+
static void execute_one(int i915)
{
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines , I915_EXEC_RING_MASK + 1);
@@ -527,6 +569,9 @@ igt_main
igt_subtest("idempotent")
idempotent(i915);
+ igt_subtest("none")
+ none(i915);
+
igt_subtest("execute-one")
execute_one(i915);
--
2.25.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Intel-gfx] [PATCH i-g-t 2/4] i915/gem_ctx_engine: Exercise for_each_context_engine() with custom engine[]
From: Chris Wilson @ 2020-02-14 19:40 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
In-Reply-To: <20200214194016.4054376-1-chris@chris-wilson.co.uk>
Set up a custom engine map with no engines, and check that the
for_each_context_engine() correctly iterates over nothing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
tests/i915/gem_ctx_engines.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index 063140e0f..6a2edd1e0 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -549,6 +549,31 @@ static void independent(int i915)
gem_context_destroy(i915, param.ctx_id);
}
+static void libapi(int i915)
+{
+ struct i915_context_param_engines engines = {};
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(&engines),
+ .size = sizeof(engines),
+ };
+ const struct intel_execution_engine2 *e;
+ unsigned int count = 0;
+
+ gem_context_set_param(i915, &p);
+
+ for_each_context_engine(i915, p.ctx_id, e)
+ count++;
+ igt_assert_eq(count, 0);
+
+ ____for_each_physical_engine(i915, p.ctx_id, e)
+ count++;
+ igt_assert_eq(count, 0);
+
+ gem_context_destroy(i915, p.ctx_id);
+}
+
igt_main
{
int i915 = -1;
@@ -584,6 +609,9 @@ igt_main
igt_subtest("independent")
independent(i915);
+ igt_subtest("libapi")
+ libapi(i915);
+
igt_fixture
igt_stop_hang_detector();
}
--
2.25.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH 08/62] x86/boot/compressed/64: Add IDT Infrastructure
From: Andi Kleen @ 2020-02-14 19:40 UTC (permalink / raw)
To: Joerg Roedel
Cc: x86, hpa, Andy Lutomirski, Dave Hansen, Peter Zijlstra,
Thomas Hellstrom, Jiri Slaby, Dan Williams, Tom Lendacky,
Juergen Gross, Kees Cook, linux-kernel, kvm, virtualization,
Joerg Roedel
In-Reply-To: <20200211135256.24617-9-joro@8bytes.org>
Joerg Roedel <joro@8bytes.org> writes:
> + addq $8, %rsp
> +
> + /*
> + * Make sure we return to __KERNEL_CS - the CS selector on
> + * the IRET frame might still be from an old BIOS GDT
> + */
> + movq $__KERNEL_CS, 8(%rsp)
This doesn't make sense. Either it's running on the correct CS
before the exception or not. Likely there's some other problem
here that you patched over with this hack.
-Andi
^ permalink raw reply
* Re: [PATCH] sched/isolation: Allow "isolcpus=" to skip unknown sub-parameters
From: Peter Xu @ 2020-02-14 19:40 UTC (permalink / raw)
To: linux-kernel
Cc: Ming Lei, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Luiz Capitulino, Thomas Gleixner
In-Reply-To: <20200204161639.267026-1-peterx@redhat.com>
On Tue, Feb 04, 2020 at 11:16:39AM -0500, Peter Xu wrote:
> The "isolcpus=" parameter allows sub-parameters to exist before the
> cpulist is specified, and if it sees unknown sub-parameters the whole
> parameter will be ignored. This design is incompatible with itself
> when we add more sub-parameters to "isolcpus=", because the old
> kernels will not recognize the new "isolcpus=" sub-parameters, then it
> will invalidate the whole parameter so the CPU isolation will not
> really take effect if we start to use the new sub-parameters while
> later we reboot into an old kernel. Instead we will see this when
> booting the old kernel:
>
> isolcpus: Error, unknown flag
>
> The better and compatible way is to allow "isolcpus=" to skip unknown
> sub-parameters, so that even if we add new sub-parameters to it the
> old kernel will still be able to behave as usual even if with the new
> sub-parameter is specified.
>
> Ideally this patch should be there when we introduce the first
> sub-parameter for "isolcpus=", so it's already a bit late. However
> late is better than nothing.
Ping - Hi, Thomas, do you have any further comment on this patch?
Thanks,
--
Peter Xu
^ permalink raw reply
* [igt-dev] [PATCH i-g-t 4/4] lib/i915/gem_engine_topology.c - intel_get_current_engine invalid result
From: Chris Wilson @ 2020-02-14 19:40 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
In-Reply-To: <20200214194016.4054376-1-chris@chris-wilson.co.uk>
From: Dale B Stimson <dale.b.stimson@intel.com>
Function intel_get_current_engine() should return NULL (instead of
engine 0) if there are no engines.
Function intel_init_engine_list() should not store potential engine
data in the output structure unless the engine is present.
Function intel_init_engine_list() should arguably not filter the static
engine list with gem_has_ring if fd == -1, so that subtests can still
be individually invoked to show subtest FAIL instead of test notrun.
Symptom: A device open failure in gem_ctx_isolation resulted in
an endless __for_each_physical_engine "per-engine" loop with the
purported last potential engine being processed every time.
Diagnosis: device open (or debugfs open) failed, leaving fd == -1.
Control skipped the rest of the initial igt_fixture block, after
which an attempt was made to iterate through engines using macro
__for_each_physical_engine.
Macro __for_each_physical_engine called intel_init_engine_list()
to initialize the loop control data. Because fd == -1,
intel_init_engine_list() fell back to using __for_each_static_engine().
All of the engines in the static engine list are rejected due to
gem_has_ring returning false (because of fd == -1), leaving 0 engines.
That resulted in loop control data with engine_data.nengines == 0
and the data for the last engine considered stored at index 0.
Still in macro __for_each_physical_engine, intel_get_current_engine()
was called to get the engine to process. It should have returned NULL,
but instead returned the engine entry at index 0, which
had received information describing the last potential engine.
This happened without end.
Signed-off-by: Dale B Stimson <dale.b.stimson@intel.com>
Acked-by: Antonio Argenziano <antonio.argenziano@intel.com>
---
lib/i915/gem_engine_topology.c | 29 ++++++++++++++++-------------
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
index ca1c1fdb9..1f530bfa3 100644
--- a/lib/i915/gem_engine_topology.c
+++ b/lib/i915/gem_engine_topology.c
@@ -156,10 +156,10 @@ static void query_engine_list(int fd, struct intel_engine_data *ed)
struct intel_execution_engine2 *
intel_get_current_engine(struct intel_engine_data *ed)
{
- if (!ed->n)
- ed->current_engine = &ed->engines[0];
- else if (ed->n >= ed->nengines)
+ if (ed->n >= ed->nengines)
ed->current_engine = NULL;
+ else if (!ed->n)
+ ed->current_engine = &ed->engines[0];
return ed->current_engine;
}
@@ -211,18 +211,21 @@ struct intel_engine_data intel_init_engine_list(int fd, uint32_t ctx_id)
igt_debug("using pre-allocated engine list\n");
__for_each_static_engine(e2) {
- struct intel_execution_engine2 *__e2 =
- &engine_data.engines[engine_data.nengines];
-
- strcpy(__e2->name, e2->name);
- __e2->instance = e2->instance;
- __e2->class = e2->class;
- __e2->flags = e2->flags;
- __e2->is_virtual = false;
-
if (igt_only_list_subtests() ||
- gem_has_ring(fd, e2->flags))
+ (fd < 0) ||
+ gem_has_ring(fd, e2->flags)) {
+ struct intel_execution_engine2 *__e2 =
+ &engine_data.engines[
+ engine_data.nengines];
+
+ strcpy(__e2->name, e2->name);
+ __e2->instance = e2->instance;
+ __e2->class = e2->class;
+ __e2->flags = e2->flags;
+ __e2->is_virtual = false;
+
engine_data.nengines++;
+ }
}
return engine_data;
}
--
2.25.0
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* [Intel-gfx] [PATCH i-g-t 3/4] lib/i915: Don't confuse param.size
From: Chris Wilson @ 2020-02-14 19:40 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
In-Reply-To: <20200214194016.4054376-1-chris@chris-wilson.co.uk>
If the context has no engines, it has no engines -- do not override the
user's setup.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
lib/i915/gem_engine_topology.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
index 9daa03df4..ca1c1fdb9 100644
--- a/lib/i915/gem_engine_topology.c
+++ b/lib/i915/gem_engine_topology.c
@@ -195,17 +195,6 @@ static int gem_topology_get_param(int fd,
if (__gem_context_get_param(fd, p))
return -1; /* using default engine map */
- if (!p->size)
- return 0;
-
- /* size will store the engine count */
- p->size = (p->size - sizeof(struct i915_context_param_engines)) /
- (offsetof(struct i915_context_param_engines,
- engines[1]) -
- sizeof(struct i915_context_param_engines));
-
- igt_assert_f(p->size <= GEM_MAX_ENGINES, "unsupported engine count\n");
-
return 0;
}
@@ -242,7 +231,13 @@ struct intel_engine_data intel_init_engine_list(int fd, uint32_t ctx_id)
query_engine_list(fd, &engine_data);
ctx_map_engines(fd, &engine_data, ¶m);
} else {
- /* param.size contains the engine count */
+ /* engine count can be inferred from size */
+ param.size -= sizeof(struct i915_context_param_engines);
+ param.size /= sizeof(struct i915_engine_class_instance);
+
+ igt_assert_f(param.size <= GEM_MAX_ENGINES,
+ "unsupported engine count\n");
+
for (i = 0; i < param.size; i++)
init_engine(&engine_data.engines[i],
engines.engines[i].engine_class,
--
2.25.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [igt-dev] [PATCH i-g-t 2/4] i915/gem_ctx_engine: Exercise for_each_context_engine() with custom engine[]
From: Chris Wilson @ 2020-02-14 19:40 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
In-Reply-To: <20200214194016.4054376-1-chris@chris-wilson.co.uk>
Set up a custom engine map with no engines, and check that the
for_each_context_engine() correctly iterates over nothing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
tests/i915/gem_ctx_engines.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index 063140e0f..6a2edd1e0 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -549,6 +549,31 @@ static void independent(int i915)
gem_context_destroy(i915, param.ctx_id);
}
+static void libapi(int i915)
+{
+ struct i915_context_param_engines engines = {};
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(&engines),
+ .size = sizeof(engines),
+ };
+ const struct intel_execution_engine2 *e;
+ unsigned int count = 0;
+
+ gem_context_set_param(i915, &p);
+
+ for_each_context_engine(i915, p.ctx_id, e)
+ count++;
+ igt_assert_eq(count, 0);
+
+ ____for_each_physical_engine(i915, p.ctx_id, e)
+ count++;
+ igt_assert_eq(count, 0);
+
+ gem_context_destroy(i915, p.ctx_id);
+}
+
igt_main
{
int i915 = -1;
@@ -584,6 +609,9 @@ igt_main
igt_subtest("independent")
independent(i915);
+ igt_subtest("libapi")
+ libapi(i915);
+
igt_fixture
igt_stop_hang_detector();
}
--
2.25.0
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* [igt-dev] [PATCH i-g-t 1/4] i915/gem_ctx_engines: Exercise 0 engines[]
From: Chris Wilson @ 2020-02-14 19:40 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
Setup a context with no engines, and make sure we reject all execution
attempts.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
tests/i915/gem_ctx_engines.c | 45 ++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index cb82f08ef..063140e0f 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -242,6 +242,48 @@ static void idempotent(int i915)
gem_context_destroy(i915, p.ctx_id);
}
+static uint32_t batch_create(int i915)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle = gem_create(i915, 4096);
+
+ gem_write(i915, handle, 0, &bbe, sizeof(bbe));
+ return handle;
+}
+
+static void none(int i915)
+{
+ struct i915_context_param_engines engines = {};
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(&engines),
+ .size = sizeof(engines),
+ };
+
+ gem_context_set_param(i915, &p);
+
+ {
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = batch_create(i915),
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&obj),
+ .buffer_count = 1,
+ .rsvd1 = p.ctx_id,
+ };
+
+ for (execbuf.flags = 0;
+ execbuf.flags <= I915_EXEC_RING_MASK;
+ execbuf.flags++)
+ igt_assert_eq(__gem_execbuf(i915, &execbuf), -EINVAL);
+
+ gem_close(i915, obj.handle);
+ }
+
+ gem_context_destroy(i915, p.ctx_id);
+}
+
static void execute_one(int i915)
{
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines , I915_EXEC_RING_MASK + 1);
@@ -527,6 +569,9 @@ igt_main
igt_subtest("idempotent")
idempotent(i915);
+ igt_subtest("none")
+ none(i915);
+
igt_subtest("execute-one")
execute_one(i915);
--
2.25.0
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* Re: [Letux-kernel] [PATCH v2] net: davicom: dm9000: allow to pass MAC address through mac_addr module parameter
From: H. Nikolaus Schaller @ 2020-02-14 19:38 UTC (permalink / raw)
To: Discussions about the Letux Kernel
Cc: Paul Cercueil, Andrew Lunn, netdev, linux-kernel, David S. Miller,
Richard Fontana, kernel, Petr Štetiar, Thomas Gleixner,
Heiner Kallweit
In-Reply-To: <996F2206-B261-46E3-9167-B48BA7D3C9FF@goldelico.com>
> Am 14.02.2020 um 20:24 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
>
>> Am 14.02.2020 um 19:47 schrieb Paul Cercueil <paul@crapouillou.net>:
>>
>> Hi Nikolaus,
>>
>> What I'd suggest is to write a NVMEM driver for the efuse and retrieve the MAC address cleanly with nvmem_get_mac_address().
>>
>> It shouldn't be hard to do (there's already code for it in the non-upstream 3.18 kernel for the CI20) and you remove the dependency on uboot.
>
> Interesting approach. I have found this:
>
> https://lore.kernel.org/patchwork/patch/868158/
>
> but it looks as if it was never finished (I could not locate a V3 or anything mainline?)
> and and it tries to solve other problems as well.
>
> And it looks to be much more complex than my "solution" to the immediate problem.
>
> I have to study it to know if I can write a nvmem_get_mac_address().
Another question is how to link this very jz4780 specific code to the generic davicom dm9000 driver?
And where should the new code live. In some jz4780 specific file or elsewhere?
>
> BR,
> Nikolaus
>
>>
>> -Paul
>>
>>
>> Le ven., févr. 14, 2020 at 17:07, H. Nikolaus Schaller <hns@goldelico.com> a écrit :
>>> The MIPS Ingenic CI20 board is shipped with a quite old u-boot
>>> (ci20-v2013.10 see https://elinux.org/CI20_Dev_Zone). This passes
>>> the MAC address through dm9000.mac_addr=xx:xx:xx:xx:xx:xx
>>> kernel module parameter to give the board a fixed MAC address.
>>> This is not processed by the dm9000 driver which assigns a random
>>> MAC address on each boot, making DHCP assign a new IP address
>>> each time.
>>> So we add a check for the mac_addr module parameter as a last
>>> resort before assigning a random one. This mechanism can also
>>> be used outside of u-boot to provide a value through modprobe
>>> config.
>>> To parse the MAC address in a new function get_mac_addr() we
>>> use an copy adapted from the ksz884x.c driver which provides
>>> the same functionality.
>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>> ---
>>> drivers/net/ethernet/davicom/dm9000.c | 42 +++++++++++++++++++++++++++
>>> 1 file changed, 42 insertions(+)
>>> diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
>>> index 1ea3372775e6..7402030b0352 100644
>>> --- a/drivers/net/ethernet/davicom/dm9000.c
>>> +++ b/drivers/net/ethernet/davicom/dm9000.c
>>> @@ -1409,6 +1409,43 @@ static struct dm9000_plat_data *dm9000_parse_dt(struct device *dev)
>>> return pdata;
>>> }
>>> +static char *mac_addr = ":";
>>> +module_param(mac_addr, charp, 0);
>>> +MODULE_PARM_DESC(mac_addr, "MAC address");
>>> +
>>> +static void get_mac_addr(struct net_device *ndev, char *macaddr)
>>> +{
>>> + int i = 0;
>>> + int j = 0;
>>> + int got_num = 0;
>>> + int num = 0;
>>> +
>>> + while (j < ETH_ALEN) {
>>> + if (macaddr[i]) {
>>> + int digit;
>>> +
>>> + got_num = 1;
>>> + digit = hex_to_bin(macaddr[i]);
>>> + if (digit >= 0)
>>> + num = num * 16 + digit;
>>> + else if (':' == macaddr[i])
>>> + got_num = 2;
>>> + else
>>> + break;
>>> + } else if (got_num) {
>>> + got_num = 2;
>>> + } else {
>>> + break;
>>> + }
>>> + if (got_num == 2) {
>>> + ndev->dev_addr[j++] = (u8)num;
>>> + num = 0;
>>> + got_num = 0;
>>> + }
>>> + i++;
>>> + }
>>> +}
>>> +
>>> /*
>>> * Search DM9000 board, allocate space and register it
>>> */
>>> @@ -1679,6 +1716,11 @@ dm9000_probe(struct platform_device *pdev)
>>> ndev->dev_addr[i] = ior(db, i+DM9000_PAR);
>>> }
>>> + if (!is_valid_ether_addr(ndev->dev_addr)) {
>>> + mac_src = "param";
>>> + get_mac_addr(ndev, mac_addr);
>>> + }
>>> +
>>> if (!is_valid_ether_addr(ndev->dev_addr)) {
>>> inv_mac_addr = true;
>>> eth_hw_addr_random(ndev);
>>> --
>>> 2.23.0
>>
>>
>
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel@openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
^ permalink raw reply
* Re: [PATCH] xfs: fix iclog release error check race with shutdown
From: Eric Sandeen @ 2020-02-14 19:38 UTC (permalink / raw)
To: Brian Foster, linux-xfs; +Cc: Zorro Lang
In-Reply-To: <20200214181528.24046-1-bfoster@redhat.com>
On 2/14/20 12:15 PM, Brian Foster wrote:
> Prior to commit df732b29c8 ("xfs: call xlog_state_release_iclog with
> l_icloglock held"), xlog_state_release_iclog() always performed a
> locked check of the iclog error state before proceeding into the
> sync state processing code. As of this commit, part of
> xlog_state_release_iclog() was open-coded into
> xfs_log_release_iclog() and as a result the locked error state check
> was lost.
>
> The lockless check still exists, but this doesn't account for the
> possibility of a race with a shutdown being performed by another
> task causing the iclog state to change while the original task waits
> on ->l_icloglock. This has reproduced very rarely via generic/475
> and manifests as an assert failure in __xlog_state_release_iclog()
> due to an unexpected iclog state.
>
> Restore the locked error state check in xlog_state_release_iclog()
> to ensure that an iclog state update via shutdown doesn't race with
> the iclog release state processing code.
>
> Reported-by: Zorro Lang <zlang@redhat.com>
> Signed-off-by: Brian Foster <bfoster@redhat.com>
On vacation* today so not thinking hard about reviews but if this goes in,
Darrick can you please add a:
Fixes: df732b29c8 ("xfs: call xlog_state_release_iclog with l_icloglock held")
Thanks,
-Eric
^ permalink raw reply
* Re: Pretty graphs
From: Brantley West @ 2020-02-14 19:38 UTC (permalink / raw)
To: fio
In-Reply-To: <CAC1jp5JZVRvhnFGFMyfsFnVh7CPcHrUJxnxnckXG_HC0_x0OJA@mail.gmail.com>
That's neat! On a similar note, I've had conversations with colleagues
recently about the need for, and novelty of, a Prometheus exporter for
fio. IMHO the ability to export histogram'd stats over time would be
especially useful.
-bw
^ permalink raw reply
* Re: [Virtio-fs] virtiofs on top of overlayfs
From: Dr. David Alan Gilbert @ 2020-02-14 19:38 UTC (permalink / raw)
To: Vivek Goyal; +Cc: Miklos Szeredi, eric.ernst, virtio-fs-list, Mrunal Patel
In-Reply-To: <20200214192050.GD18654@redhat.com>
* Vivek Goyal (vgoyal@redhat.com) wrote:
> Hi Eric,
>
> Was talking to Mrunal and he said you mentioned that virtiofs on top of
> overlayfs has some issues.
>
> I can't remember any issues and thought it should just work. Would you
> remember the specific issue you faced with this configuraiton.
>
> Have kata continaers tried using virtiofs on top overlayfs.
I know we've had it going on Kubernetes which has a pile of overlayfs;
I'm not sure how hard it's been pushed though.
Dave
> Thanks
> Vivek
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* [linux-next:master 1427/2449] ERROR: "__spi_register_driver" [sound/soc/codecs/snd-soc-wm0010.ko] undefined!
From: kbuild test robot @ 2020-02-14 19:37 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 9f01828e9e1655836fea88d0c8225d648850b33a
commit: ea00d95200d02ece71f5814d41b14f2eb16d598b [1427/2449] ASoC: Use imply for SND_SOC_ALL_CODECS
config: x86_64-randconfig-f003-20200214 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-4) 7.5.0
reproduce:
git checkout ea00d95200d02ece71f5814d41b14f2eb16d598b
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
Note: the linux-next/master HEAD 9f01828e9e1655836fea88d0c8225d648850b33a builds fine.
It may have been fixed somewhere.
All errors (new ones prefixed by >>):
>> ERROR: "__spi_register_driver" [sound/soc/codecs/snd-soc-wm0010.ko] undefined!
>> ERROR: "spi_async" [sound/soc/codecs/snd-soc-wm0010.ko] undefined!
>> ERROR: "spi_sync" [sound/soc/codecs/snd-soc-wm0010.ko] undefined!
>> ERROR: "__spi_register_driver" [sound/soc/codecs/snd-soc-adav801.ko] undefined!
>> ERROR: "__spi_register_driver" [sound/soc/codecs/snd-soc-adau1977-spi.ko] undefined!
>> ERROR: "spi_write_then_read" [sound/soc/codecs/snd-soc-adau1977-spi.ko] undefined!
>> ERROR: "spi_get_device_id" [sound/soc/codecs/snd-soc-adau1977-spi.ko] undefined!
>> ERROR: "__spi_register_driver" [sound/soc/codecs/snd-soc-adau1781-spi.ko] undefined!
>> ERROR: "spi_write_then_read" [sound/soc/codecs/snd-soc-adau1781-spi.ko] undefined!
>> ERROR: "spi_get_device_id" [sound/soc/codecs/snd-soc-adau1781-spi.ko] undefined!
>> ERROR: "__spi_register_driver" [sound/soc/codecs/snd-soc-ad193x-spi.ko] undefined!
>> ERROR: "spi_get_device_id" [sound/soc/codecs/snd-soc-ad193x-spi.ko] undefined!
>> ERROR: "__spi_register_driver" [sound/soc/codecs/snd-soc-ad1836.ko] undefined!
>> ERROR: "spi_get_device_id" [sound/soc/codecs/snd-soc-ad1836.ko] undefined!
>> ERROR: "abx500_set_register_interruptible" [sound/soc/codecs/snd-soc-ab8500-codec.ko] undefined!
>> ERROR: "abx500_get_register_interruptible" [sound/soc/codecs/snd-soc-ab8500-codec.ko] undefined!
>> ERROR: "spi_sync" [drivers/base/regmap/regmap-spi.ko] undefined!
>> ERROR: "spi_async" [drivers/base/regmap/regmap-spi.ko] undefined!
>> ERROR: "spi_write_then_read" [drivers/base/regmap/regmap-spi.ko] undefined!
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 46967 bytes --]
^ 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.