* [Ocfs2-devel] [PATCH v5 01/13] mm: Fix the return type of __do_page_cache_readahead
From: Matthew Wilcox @ 2020-02-14 19:50 UTC (permalink / raw)
To: ocfs2-devel
In-Reply-To: <20200211010348.6872-2-willy@infradead.org>
On Mon, Feb 10, 2020 at 05:03:36PM -0800, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> ra_submit() which is a wrapper around __do_page_cache_readahead() already
> returns an unsigned long, and the 'nr_to_read' parameter is an unsigned
> long, so fix __do_page_cache_readahead() to return an unsigned long,
> even though I'm pretty sure we're not going to readahead more than 2^32
> pages ever.
I was going through this and realised it's completely pointless -- the
returned value from ra_submit() and __do_page_cache_readahead() is
eventually ignored through all paths. So I'm replacing this patch with
one that makes everything return void.
^ permalink raw reply
* [Cluster-devel] [PATCH v5 01/13] mm: Fix the return type of __do_page_cache_readahead
From: Matthew Wilcox @ 2020-02-14 19:50 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <20200211010348.6872-2-willy@infradead.org>
On Mon, Feb 10, 2020 at 05:03:36PM -0800, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> ra_submit() which is a wrapper around __do_page_cache_readahead() already
> returns an unsigned long, and the 'nr_to_read' parameter is an unsigned
> long, so fix __do_page_cache_readahead() to return an unsigned long,
> even though I'm pretty sure we're not going to readahead more than 2^32
> pages ever.
I was going through this and realised it's completely pointless -- the
returned value from ra_submit() and __do_page_cache_readahead() is
eventually ignored through all paths. So I'm replacing this patch with
one that makes everything return void.
^ permalink raw reply
* Buffered IO async context overhead
From: Andres Freund @ 2020-02-14 19:50 UTC (permalink / raw)
To: io-uring, axboe
Hi,
For workloads where a lot of buffered IO is done, I see considerably
higher overhead when going through io_uring, then when just doing the IO
synchronously.
This example is on a samsung 970 pro nvme (i.e. decent, but not top
class). I've limited the amount of dirty buffers allowed to 2/4 GB to
keep the test times in check. This is with a relatively recent kernel,
33b40134e5cfbbccad7f3040d1919889537a3df7 .
fio --name=t --time_based=1 --runtime=100 --ioengine=io_uring --rw=write --bs=8k --filesize=300G --iodepth=1
Jobs: 1 (f=1): [W(1)][100.0%][w=1049MiB/s][w=134k IOPS][eta 00m:00s]
t: (groupid=0, jobs=1): err= 0: pid=46625: Fri Feb 14 11:22:05 2020
write: IOPS=73.4k, BW=573MiB/s (601MB/s)(55.0GiB/100001msec); 0 zone resets
slat (nsec): min=571, max=607779, avg=2927.18, stdev=1213.47
clat (nsec): min=40, max=1400.7k, avg=9947.92, stdev=2606.65
lat (usec): min=4, max=1403, avg=12.94, stdev= 3.28
clat percentiles (nsec):
| 1.00th=[ 4960], 5.00th=[ 6368], 10.00th=[ 8032], 20.00th=[ 8640],
| 30.00th=[ 9024], 40.00th=[ 9280], 50.00th=[ 9664], 60.00th=[10048],
| 70.00th=[10560], 80.00th=[11072], 90.00th=[11968], 95.00th=[13120],
| 99.00th=[21632], 99.50th=[23424], 99.90th=[26752], 99.95th=[28288],
| 99.99th=[35584]
bw ( KiB/s): min=192408, max=1031483, per=79.92%, avg=468998.16, stdev=108691.70, samples=199
iops : min=24051, max=128935, avg=58624.37, stdev=13586.54, samples=199
lat (nsec) : 50=0.01%, 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%
lat (nsec) : 1000=0.01%
lat (usec) : 2=0.01%, 4=0.01%, 10=56.98%, 20=41.67%, 50=1.32%
lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%
lat (msec) : 2=0.01%
cpu : usr=15.63%, sys=34.79%, ctx=7333387, majf=0, minf=41
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,7335827,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=573MiB/s (601MB/s), 573MiB/s-573MiB/s (601MB/s-601MB/s), io=55.0GiB (60.1GB), run=100001-100001msec
Disk stats (read/write):
nvme0n1: ios=0/49033, merge=0/12, ticks=0/1741787, in_queue=1717299, util=20.89%
During this most of the time there's a number of tasks with decent CPU usage
46627 root 20 0 0 0 0 R 99.7 0.0 1:07.74 io_wqe_worker-0
46625 root 20 0 756920 6708 1984 S 51.0 0.0 0:34.56 fio
42818 root 20 0 0 0 0 I 3.3 0.0 0:03.23 kworker/u82:6-flush-259:0
43338 root 20 0 0 0 0 I 1.3 0.0 0:02.06 kworker/u82:18-events_unbound
Comparing that to using sync:
fio --name=t --time_based=1 --runtime=100 --ioengine=sync --rw=write --bs=8k --filesize=300G --iodepth=1
Jobs: 1 (f=1): [W(1)][100.0%][w=1607MiB/s][w=206k IOPS][eta 00m:00s]
t: (groupid=0, jobs=1): err= 0: pid=46690: Fri Feb 14 11:24:17 2020
write: IOPS=234k, BW=1831MiB/s (1920MB/s)(179GiB/100001msec); 0 zone resets
clat (nsec): min=1612, max=6649.7k, avg=3913.39, stdev=3170.65
lat (nsec): min=1653, max=6649.7k, avg=3955.30, stdev=3172.59
clat percentiles (nsec):
| 1.00th=[ 2512], 5.00th=[ 2544], 10.00th=[ 2576], 20.00th=[ 2640],
| 30.00th=[ 2672], 40.00th=[ 2768], 50.00th=[ 3376], 60.00th=[ 3792],
| 70.00th=[ 4192], 80.00th=[ 4832], 90.00th=[ 5792], 95.00th=[ 7008],
| 99.00th=[11968], 99.50th=[15552], 99.90th=[22656], 99.95th=[26496],
| 99.99th=[40192]
bw ( MiB/s): min= 989, max= 2118, per=82.26%, avg=1506.28, stdev=169.56, samples=193
iops : min=126684, max=271118, avg=192803.37, stdev=21703.94, samples=193
lat (usec) : 2=0.01%, 4=66.33%, 10=32.14%, 20=1.34%, 50=0.19%
lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 1000=0.01%
lat (msec) : 2=0.01%, 10=0.01%
cpu : usr=8.35%, sys=91.55%, ctx=6183, majf=0, minf=74
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,23437892,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=1831MiB/s (1920MB/s), 1831MiB/s-1831MiB/s (1920MB/s-1920MB/s), io=179GiB (192GB), run=100001-100001msec
Disk stats (read/write):
nvme0n1: ios=0/152371, merge=0/587772, ticks=0/5657236, in_queue=5580764, util=67.57%
Tasks:
46690 root 20 0 756912 6524 1800 R 100.0 0.0 1:24.64 fio
2913 root 20 0 0 0 0 S 32.2 0.0 0:09.57 kswapd1
45683 root 20 0 0 0 0 I 13.2 0.0 0:08.57 kworker/u82:16-events_unbound
42816 root 20 0 0 0 0 I 11.2 0.0 0:09.71 kworker/u82:1-flush-259:0
36087 root 20 0 0 0 0 I 1.6 0.0 0:01.51 kworker/27:2-xfs-conv/nvme0n1
I.e. sync did about three times the throughput of io_uring.
It's possible to make io_uring perform better, by batching
submissions/completions:
fio --name=t --time_based=1 --runtime=100 --ioengine=io_uring --rw=write --bs=8k --filesize=300G --iodepth=64 --iodepth_batch_submit=32 --iodepth_batch_complete_min=16 --iodepth_low=16
t: (g=0): rw=write, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=io_uring, iodepth=64
fio-3.17
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][w=1382MiB/s][w=177k IOPS][eta 00m:00s]
t: (groupid=0, jobs=1): err= 0: pid=46849: Fri Feb 14 11:28:13 2020
write: IOPS=194k, BW=1513MiB/s (1587MB/s)(148GiB/100001msec); 0 zone resets
slat (usec): min=4, max=455, avg=48.09, stdev=18.20
clat (usec): min=6, max=25435, avg=164.91, stdev=104.69
lat (usec): min=66, max=25512, avg=213.03, stdev=101.19
clat percentiles (usec):
| 1.00th=[ 60], 5.00th=[ 68], 10.00th=[ 78], 20.00th=[ 94],
| 30.00th=[ 108], 40.00th=[ 127], 50.00th=[ 143], 60.00th=[ 180],
| 70.00th=[ 210], 80.00th=[ 227], 90.00th=[ 265], 95.00th=[ 302],
| 99.00th=[ 379], 99.50th=[ 441], 99.90th=[ 562], 99.95th=[ 611],
| 99.99th=[ 816]
bw ( MiB/s): min= 289, max= 1802, per=81.00%, avg=1225.72, stdev=173.92, samples=197
iops : min=37086, max=230692, avg=156891.42, stdev=22261.80, samples=197
lat (usec) : 10=0.01%, 50=0.09%, 100=25.74%, 250=60.50%, 500=13.46%
lat (usec) : 750=0.19%, 1000=0.01%
lat (msec) : 2=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
cpu : usr=31.80%, sys=26.04%, ctx=793383, majf=0, minf=1301
IO depths : 1=0.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=66.7%, >=64=33.3%
submit : 0=0.0%, 4=0.0%, 8=0.0%, 16=50.0%, 32=50.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=0.0%, 8=0.0%, 16=100.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued rwts: total=0,19369087,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
WRITE: bw=1513MiB/s (1587MB/s), 1513MiB/s-1513MiB/s (1587MB/s-1587MB/s), io=148GiB (159GB), run=100001-100001msec
Disk stats (read/write):
nvme0n1: ios=0/127095, merge=0/15, ticks=0/4936953, in_queue=4873341, util=55.82%
but that's still worse than the plain sync one. And doesn't work well
for reads.
Now, it's clear that there's some overhead in backgrounding small IOs to
the async context, but this seems awfully high. There's still a slowdown
when using considerably larger pieces of IO (128k).
For the 128k, iodepth 1 case I get:
sync:
- 97.77% 0.04% fio fio [.] fio_syncio_queue
97.73% fio_syncio_queue
- __libc_write
- __libc_write
- 97.50% entry_SYSCALL_64
- 97.31% do_syscall_64
- 97.25% ksys_write
- 97.10% vfs_write
- 96.91% new_sync_write
- 96.82% xfs_file_buffered_aio_write
- 96.13% iomap_file_buffered_write
- iomap_apply
- 95.52% iomap_write_actor
+ 37.66% iov_iter_copy_from_user_atomic
+ 26.83% iomap_write_begin
+ 26.64% iomap_write_end.isra.0
2.26% iov_iter_fault_in_readable
0.87% balance_dirty_pages_ratelimited
and --no-children shows:
+ 36.57% fio [kernel.vmlinux] [k] copy_user_enhanced_fast_string
+ 14.31% fio [kernel.vmlinux] [k] iomap_set_range_uptodate
+ 3.85% fio [kernel.vmlinux] [k] get_page_from_freelist
+ 3.34% fio [kernel.vmlinux] [k] queued_spin_lock_slowpath
+ 2.94% fio [kernel.vmlinux] [k] xas_load
+ 2.66% fio [kernel.vmlinux] [k] __add_to_page_cache_locked
+ 2.51% fio [kernel.vmlinux] [k] _raw_spin_lock_irqsave
+ 2.28% fio [kernel.vmlinux] [k] iov_iter_fault_in_readable
+ 1.87% fio [kernel.vmlinux] [k] __lru_cache_add
+ 1.80% fio [kernel.vmlinux] [k] __pagevec_lru_add_fn
+ 1.59% fio [kernel.vmlinux] [k] node_dirty_ok
+ 1.30% fio [kernel.vmlinux] [k] _raw_spin_lock_irq
+ 1.30% fio [kernel.vmlinux] [k] iomap_set_page_dirty
+ 1.25% fio fio [.] get_io_u
+ 1.18% fio [kernel.vmlinux] [k] xas_start
io_uring (the io_wqe_worker-0):
- 100.00% 22.64% io_wqe_worker-0 [kernel.vmlinux] [k] io_wqe_worker
- 77.36% io_wqe_worker
- 77.18% io_worker_handle_work
- 75.80% io_rw_async
- io_wq_submit_work
- 75.57% io_issue_sqe
- io_write
- 70.96% xfs_file_buffered_aio_write
- 70.37% iomap_file_buffered_write
- iomap_apply
- 70.08% iomap_write_actor
+ 30.05% iov_iter_copy_from_user_atomic
- 18.38% iomap_write_begin
- 17.64% grab_cache_page_write_begin
+ 16.73% pagecache_get_page
0.51% wait_for_stable_page
- 16.96% iomap_write_end.isra.0
8.72% iomap_set_range_uptodate
+ 7.35% iomap_set_page_dirty
3.45% iov_iter_fault_in_readable
0.56% balance_dirty_pages_ratelimited
- 4.36% kiocb_done
- 3.56% io_cqring_ev_posted
+ __wake_up_common_lock
0.61% io_cqring_add_event
0.56% io_free_req
--no-children:
+ 29.55% io_wqe_worker-0 [kernel.vmlinux] [k] copy_user_enhanced_fast_string
+ 22.64% io_wqe_worker-0 [kernel.vmlinux] [k] io_wqe_worker
+ 8.71% io_wqe_worker-0 [kernel.vmlinux] [k] iomap_set_range_uptodate
+ 3.41% io_wqe_worker-0 [kernel.vmlinux] [k] iov_iter_fault_in_readable
+ 2.50% io_wqe_worker-0 [kernel.vmlinux] [k] get_page_from_freelist
+ 2.24% io_wqe_worker-0 [kernel.vmlinux] [k] xas_load
+ 1.82% io_wqe_worker-0 [kernel.vmlinux] [k] queued_spin_lock_slowpath
+ 1.80% io_wqe_worker-0 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
+ 1.72% io_wqe_worker-0 [kernel.vmlinux] [k] __add_to_page_cache_locked
+ 1.58% io_wqe_worker-0 [kernel.vmlinux] [k] _raw_spin_lock_irq
+ 1.29% io_wqe_worker-0 [kernel.vmlinux] [k] __lru_cache_add
+ 1.27% io_wqe_worker-0 [kernel.vmlinux] [k] __pagevec_lru_add_fn
+ 1.08% io_wqe_worker-0 [kernel.vmlinux] [k] xas_start
So it seems the biggest difference is the cpu time in io_wqe_worker
itself. Which in turn appears to mostly be:
│ mov %rbp,%rdi
│ → callq io_worker_handle_work
│ mov $0x3e7,%eax
│ ↓ jmp 28c
│ rep_nop():
│ }
│
│ /* REP NOP (PAUSE) is a good thing to insert into busy-wait loops. */
│ static __always_inline void rep_nop(void)
│ {
│ asm volatile("rep; nop" ::: "memory");
74.50 │281: pause
│ io_worker_spin_for_work():
│ while (++i < 1000) {
11.15 │ sub $0x1,%eax
│ ↑ je 9b
│ __read_once_size():
│ __READ_ONCE_SIZE;
9.53 │28c: mov 0x8(%rbx),%rdx
│ io_wqe_run_queue():
│ if (!wq_list_empty(&wqe->work_list) &&
│ test %rdx,%rdx
2.68 │ ↓ je 29f
│ io_worker_spin_for_work():
With 8k it looks similar, but more extreme:
sync (fio itself):
+ 29.89% fio [kernel.vmlinux] [k] copy_user_enhanced_fast_string
+ 14.10% fio [kernel.vmlinux] [k] iomap_set_range_uptodate
+ 2.80% fio [kernel.vmlinux] [k] get_page_from_freelist
+ 2.66% fio [kernel.vmlinux] [k] queued_spin_lock_slowpath
+ 2.46% fio [kernel.vmlinux] [k] xas_load
+ 1.97% fio [kernel.vmlinux] [k] _raw_spin_lock_irqsave
+ 1.94% fio [kernel.vmlinux] [k] __add_to_page_cache_locked
+ 1.79% fio [kernel.vmlinux] [k] iomap_set_page_dirty
+ 1.64% fio [kernel.vmlinux] [k] iov_iter_fault_in_readable
+ 1.61% fio fio [.] __fio_gettime
+ 1.49% fio [kernel.vmlinux] [k] __pagevec_lru_add_fn
+ 1.39% fio [kernel.vmlinux] [k] __lru_cache_add
1.30% fio fio [.] get_io_u
+ 1.11% fio [kernel.vmlinux] [k] up_write
+ 1.10% fio [kernel.vmlinux] [k] node_dirty_ok
+ 1.09% fio [kernel.vmlinux] [k] down_write
io_uring (io_wqe_worker-0 again):
+ 54.13% io_wqe_worker-0 [kernel.vmlinux] [k] io_wqe_worker
+ 11.01% io_wqe_worker-0 [kernel.vmlinux] [k] copy_user_enhanced_fast_string
+ 2.70% io_wqe_worker-0 [kernel.vmlinux] [k] iomap_set_range_uptodate
+ 2.62% io_wqe_worker-0 [kernel.vmlinux] [k] iov_iter_fault_in_readable
+ 1.91% io_wqe_worker-0 [kernel.vmlinux] [k] __slab_free
+ 1.85% io_wqe_worker-0 [kernel.vmlinux] [k] _raw_spin_lock_irqsave
+ 1.66% io_wqe_worker-0 [kernel.vmlinux] [k] try_to_wake_up
+ 1.62% io_wqe_worker-0 [kernel.vmlinux] [k] io_cqring_fill_event
+ 1.55% io_wqe_worker-0 [kernel.vmlinux] [k] io_rw_async
+ 1.43% io_wqe_worker-0 [kernel.vmlinux] [k] __wake_up_common
+ 1.37% io_wqe_worker-0 [kernel.vmlinux] [k] _raw_spin_lock_irq
+ 1.20% io_wqe_worker-0 [kernel.vmlinux] [k] rw_verify_area
which I think is pretty clear evidence we're hitting fairly significant
contention on the queue lock.
I am hitting this in postgres originally, not fio, but I thought it's
easier to reproduce this way. There's obviously benefit to doing things
in the background - but it requires odd logic around deciding when to
use io_uring, and when not.
To be clear, none of this happens with DIO, but I don't forsee switching
to DIO for all IO by default ever (too high demands on accurate
configuration).
Greetings,
Andres Freund
^ permalink raw reply
* [PATCH 3/4] target/arm: Flush high bits of sve register after AdvSIMD ZIP/UZP/TRN
From: Richard Henderson @ 2020-02-14 19:46 UTC (permalink / raw)
To: qemu-devel; +Cc: peter.maydell, qemu-arm
In-Reply-To: <20200214194643.23317-1-richard.henderson@linaro.org>
Writes to AdvSIMD registers flush the bits above 128.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
target/arm/translate-a64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 096a854aed..b83d09dbcd 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -7054,6 +7054,7 @@ static void disas_simd_zip_trn(DisasContext *s, uint32_t insn)
tcg_temp_free_i64(tcg_resl);
write_vec_element(s, tcg_resh, rd, 1, MO_64);
tcg_temp_free_i64(tcg_resh);
+ clear_vec_high(s, true, rd);
}
/*
--
2.20.1
^ permalink raw reply related
* Re: [PATCH RFC] memory: Don't allow to resize RAM while migrating
From: Peter Xu @ 2020-02-14 19:44 UTC (permalink / raw)
To: David Hildenbrand
Cc: Eduardo Habkost, Juan Quintela, Michael S. Tsirkin,
Richard Henderson, qemu-devel, Shameerali Kolothum Thodi,
Dr. David Alan Gilbert, Shannon Zhao, Paolo Bonzini,
Igor Mammedov, Alex Bennée
In-Reply-To: <ab0c4b8f-c18b-cf02-282a-eb968bb6677e@redhat.com>
On Fri, Feb 14, 2020 at 07:26:59PM +0100, David Hildenbrand wrote:
> >>>> + if (!postcopy_is_running()) {
> >>>> + Error *err = NULL;
> >>>> +
> >>>> + /*
> >>>> + * Precopy code cannot deal with the size of ram blocks changing at
> >>>> + * random points in time. We're still running on the source, abort
> >>>> + * the migration and continue running here. Make sure to wait until
> >>>> + * migration was canceled.
> >>>> + */
> >>>> + error_setg(&err, "RAM resized during precopy.");
> >>>> + migrate_set_error(migrate_get_current(), err);
> >>>> + error_free(err);
> >>>> + migration_cancel();
> >>>> + } else {
> >>>> + /*
> >>>> + * Postcopy code cannot deal with the size of ram blocks changing at
> >>>> + * random points in time. We're running on the target. Fail hard.
> >>>> + *
> >>>> + * TODO: How to handle this in a better way?
> >>>> + */
> >>>> + error_report("RAM resized during postcopy.");
> >>>> + exit(-1);
> >>>
> >>> Now I'm rethinking the postcopy case....
> >>>
> >>> ram_dirty_bitmap_reload() should only happen during the postcopy
> >>> recovery, and when that happens the VM should be stopped on both
> >>> sides. Which means, ram resizing should not trigger there...
> >>
> >> But that guest got the chance to run for a bit and eventually reboot
> >> AFAIK. Also, there are other data races possible when used_length
> >> suddenly changes, this is just the most obvious one where things will;
> >> get screwed up.
> >
> > Right, the major one could be in ram_load_postcopy() where we call
> > host_from_ram_block_offset(). However if FW extension is the major
> > use case then it seems to still work (still better than crashing,
> > isn't it? :).
>
> "Let's close our eyes and hope it will never happen" ? :) No, I don't
> like that. This screams for a better solution long term, and until then
> a proper fencing IMHO. We're making here wild guesses about data races
> and why they might not be that bad in certain cases (did I mention
> load/store tearing? used_length is not an atomic value ...).
Yeah fencing is good, but crashing a VM while it wasn't going to crash
is another thing, imho. You can dump an error message if you really
like, but instead of exit() I really prefer we either still let the
old way to at least work or really fix it.
When I say "really fix it", I mean we can even start to think about
the shrinking case and how to support that for postcopy. For example,
in the above case host_from_ram_block_offset() will return NULL then,
and the fix could be that we drop that extra page because we don't
need that any more, instead of bailing out.
Thanks,
--
Peter Xu
^ permalink raw reply
* [PATCH] net: phy: restore mdio regs in the iproc mdio driver
From: Scott Branden @ 2020-02-14 19:48 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: Scott Branden, Ray Jui, Arun Parameswaran, Russell King,
linux-kernel, bcm-kernel-feedback-list, netdev, David S . Miller,
linux-arm-kernel
From: Arun Parameswaran <arun.parameswaran@broadcom.com>
The mii management register in iproc mdio block
does not have a reention register so it is lost on suspend.
Save and restore value of register while resuming from suspend.
Fixes: bb1a619735b4 ("net: phy: Initialize mdio clock at probe function")
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
drivers/net/phy/mdio-bcm-iproc.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/net/phy/mdio-bcm-iproc.c b/drivers/net/phy/mdio-bcm-iproc.c
index 7e9975d25066..f1ded03f0229 100644
--- a/drivers/net/phy/mdio-bcm-iproc.c
+++ b/drivers/net/phy/mdio-bcm-iproc.c
@@ -178,6 +178,23 @@ static int iproc_mdio_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+int iproc_mdio_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct iproc_mdio_priv *priv = platform_get_drvdata(pdev);
+
+ /* restore the mii clock configuration */
+ iproc_mdio_config_clk(priv->base);
+
+ return 0;
+}
+
+static const struct dev_pm_ops iproc_mdio_pm_ops = {
+ .resume = iproc_mdio_resume
+};
+#endif /* CONFIG_PM_SLEEP */
+
static const struct of_device_id iproc_mdio_of_match[] = {
{ .compatible = "brcm,iproc-mdio", },
{ /* sentinel */ },
@@ -188,6 +205,9 @@ static struct platform_driver iproc_mdio_driver = {
.driver = {
.name = "iproc-mdio",
.of_match_table = iproc_mdio_of_match,
+#ifdef CONFIG_PM_SLEEP
+ .pm = &iproc_mdio_pm_ops,
+#endif
},
.probe = iproc_mdio_probe,
.remove = iproc_mdio_remove,
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] qemuriscv64: Set the Xvisor platform
From: Alistair Francis @ 2020-02-14 19:42 UTC (permalink / raw)
To: openembedded-core
Set the platform information required to build Xvisor.
https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-extended/xvisor
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
meta/conf/machine/qemuriscv64.conf | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/conf/machine/qemuriscv64.conf b/meta/conf/machine/qemuriscv64.conf
index b45fdd556d..a753af0576 100644
--- a/meta/conf/machine/qemuriscv64.conf
+++ b/meta/conf/machine/qemuriscv64.conf
@@ -4,6 +4,8 @@
require conf/machine/include/riscv/qemuriscv.inc
+XVISOR_PLAT = "riscv/virt64"
+
EXTRA_IMAGEDEPENDS += "u-boot"
UBOOT_MACHINE = "qemu-riscv64_smode_defconfig"
UBOOT_ELF = "u-boot"
--
2.25.0
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 114/141] powerpc/sriov: Remove VF eeh_dev state when disabling SR-IOV
From: Sasha Levin @ 2020-02-14 16:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sam Bobroff, Oliver O'Halloran, linuxppc-dev, Sasha Levin
In-Reply-To: <20200214162122.19794-1-sashal@kernel.org>
From: Oliver O'Halloran <oohall@gmail.com>
[ Upstream commit 1fb4124ca9d456656a324f1ee29b7bf942f59ac8 ]
When disabling virtual functions on an SR-IOV adapter we currently do not
correctly remove the EEH state for the now-dead virtual functions. When
removing the pci_dn that was created for the VF when SR-IOV was enabled
we free the corresponding eeh_dev without removing it from the child device
list of the eeh_pe that contained it. This can result in crashes due to the
use-after-free.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Sam Bobroff <sbobroff@linux.ibm.com>
Tested-by: Sam Bobroff <sbobroff@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190821062655.19735-1-oohall@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/pci_dn.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci_dn.c b/arch/powerpc/kernel/pci_dn.c
index 5926934370702..c8f1b78fbd0e2 100644
--- a/arch/powerpc/kernel/pci_dn.c
+++ b/arch/powerpc/kernel/pci_dn.c
@@ -271,9 +271,22 @@ void remove_dev_pci_data(struct pci_dev *pdev)
continue;
#ifdef CONFIG_EEH
- /* Release EEH device for the VF */
+ /*
+ * Release EEH state for this VF. The PCI core
+ * has already torn down the pci_dev for this VF, but
+ * we're responsible to removing the eeh_dev since it
+ * has the same lifetime as the pci_dn that spawned it.
+ */
edev = pdn_to_eeh_dev(pdn);
if (edev) {
+ /*
+ * We allocate pci_dn's for the totalvfs count,
+ * but only only the vfs that were activated
+ * have a configured PE.
+ */
+ if (edev->pe)
+ eeh_rmv_from_parent_pe(edev);
+
pdn->edev = NULL;
kfree(edev);
}
--
2.20.1
^ permalink raw reply related
* [PATCH] net: phy: restore mdio regs in the iproc mdio driver
From: Scott Branden @ 2020-02-14 19:48 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit
Cc: Russell King, David S . Miller, Ray Jui, bcm-kernel-feedback-list,
netdev, linux-arm-kernel, linux-kernel, Arun Parameswaran,
Scott Branden
From: Arun Parameswaran <arun.parameswaran@broadcom.com>
The mii management register in iproc mdio block
does not have a reention register so it is lost on suspend.
Save and restore value of register while resuming from suspend.
Fixes: bb1a619735b4 ("net: phy: Initialize mdio clock at probe function")
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
drivers/net/phy/mdio-bcm-iproc.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/net/phy/mdio-bcm-iproc.c b/drivers/net/phy/mdio-bcm-iproc.c
index 7e9975d25066..f1ded03f0229 100644
--- a/drivers/net/phy/mdio-bcm-iproc.c
+++ b/drivers/net/phy/mdio-bcm-iproc.c
@@ -178,6 +178,23 @@ static int iproc_mdio_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+int iproc_mdio_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct iproc_mdio_priv *priv = platform_get_drvdata(pdev);
+
+ /* restore the mii clock configuration */
+ iproc_mdio_config_clk(priv->base);
+
+ return 0;
+}
+
+static const struct dev_pm_ops iproc_mdio_pm_ops = {
+ .resume = iproc_mdio_resume
+};
+#endif /* CONFIG_PM_SLEEP */
+
static const struct of_device_id iproc_mdio_of_match[] = {
{ .compatible = "brcm,iproc-mdio", },
{ /* sentinel */ },
@@ -188,6 +205,9 @@ static struct platform_driver iproc_mdio_driver = {
.driver = {
.name = "iproc-mdio",
.of_match_table = iproc_mdio_of_match,
+#ifdef CONFIG_PM_SLEEP
+ .pm = &iproc_mdio_pm_ops,
+#endif
},
.probe = iproc_mdio_probe,
.remove = iproc_mdio_remove,
--
2.17.1
^ permalink raw reply related
* Re: FYI nautilus branch is locked
From: Yuri Weinstein @ 2020-02-14 19:47 UTC (permalink / raw)
To: Yuri Weinstein, dev, Development, Ceph, Abhishek Lekshmanan,
Nathan Cutler, Casey Bodley, Patrick Donnelly, Neha Ojha,
Durgin, Josh, David Zafman, Weil, Sage, Ramana Venkatesh Raja,
Tamilarasi Muthamizhan, Dillaman, Jason, Sadeh-Weinraub, Yehuda,
Lekshmanan, Abhishek, Ilya Dryomov, Jeff Layton, ceph-qe-team,
Andrew Schoen
In-Reply-To: <CAMMFjmE4wyKcP0KkudhTu2zeZF+SswZ=kN_k-Xaq1aC6o4vWkQ@mail.gmail.com>
Sorry correction again - 14.2.8
On Fri, Feb 14, 2020 at 11:30 AM Yuri Weinstein <yweinste@redhat.com> wrote:
>
> We are getting ready to test 14.2.9 and nautilus branch is locked for
> merges until it's done.
>
> sah1 - 4d5b84085009968f557baaa4209183f1374773cd
>
> Nathan, Abhishek pls confirm.
>
> Thank you
> YuriW
^ permalink raw reply
* [meta-python][PATCH] python3-cachetools: consolidate inc and bb files into a single bb file
From: Derek Straka @ 2020-02-14 19:47 UTC (permalink / raw)
To: openembedded-devel
Signed-off-by: Derek Straka <derek@asterius.io>
---
.../python/python-cachetools.inc | 16 ----------------
.../python/python3-cachetools_4.0.0.bb | 18 ++++++++++++++++--
2 files changed, 16 insertions(+), 18 deletions(-)
delete mode 100644 meta-python/recipes-devtools/python/python-cachetools.inc
diff --git a/meta-python/recipes-devtools/python/python-cachetools.inc b/meta-python/recipes-devtools/python/python-cachetools.inc
deleted file mode 100644
index f3d3bc6bc5..0000000000
--- a/meta-python/recipes-devtools/python/python-cachetools.inc
+++ /dev/null
@@ -1,16 +0,0 @@
-SUMMARY = "Extensible memoizing collections and decorators"
-HOMEPAGE = "https://github.com/tkem/cachetools"
-DESCRIPTION = "This module provides various memoizing \
-collections and decorators, including variants of the \
-Python 3 Standard Library @lru_cache function decorator."
-SECTION = "devel/python"
-
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=27f7518eb6f7dc686d0f953b2f28dae5"
-
-inherit pypi
-
-SRC_URI[md5sum] = "6a88df13467e80eb61dd2bedad19b83c"
-SRC_URI[sha256sum] = "9a52dd97a85f257f4e4127f15818e71a0c7899f121b34591fcc1173ea79a0198"
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-python/recipes-devtools/python/python3-cachetools_4.0.0.bb b/meta-python/recipes-devtools/python/python3-cachetools_4.0.0.bb
index 76b2f6785c..50d0f25739 100644
--- a/meta-python/recipes-devtools/python/python3-cachetools_4.0.0.bb
+++ b/meta-python/recipes-devtools/python/python3-cachetools_4.0.0.bb
@@ -1,2 +1,16 @@
-inherit setuptools3
-require python-cachetools.inc
+SUMMARY = "Extensible memoizing collections and decorators"
+HOMEPAGE = "https://github.com/tkem/cachetools"
+DESCRIPTION = "This module provides various memoizing \
+collections and decorators, including variants of the \
+Python 3 Standard Library @lru_cache function decorator."
+SECTION = "devel/python"
+
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=27f7518eb6f7dc686d0f953b2f28dae5"
+
+inherit pypi setuptools3
+
+SRC_URI[md5sum] = "6a88df13467e80eb61dd2bedad19b83c"
+SRC_URI[sha256sum] = "9a52dd97a85f257f4e4127f15818e71a0c7899f121b34591fcc1173ea79a0198"
+
+BBCLASSEXTEND = "native nativesdk"
--
2.17.1
^ permalink raw reply related
* [PATCH 1/4] target/arm: Flush high bits of sve register after AdvSIMD EXT
From: Richard Henderson @ 2020-02-14 19:46 UTC (permalink / raw)
To: qemu-devel; +Cc: peter.maydell, qemu-arm
In-Reply-To: <20200214194643.23317-1-richard.henderson@linaro.org>
Writes to AdvSIMD registers flush the bits above 128.
Buglink: https://bugs.launchpad.net/bugs/1863247
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
target/arm/translate-a64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 7c26c3bfeb..620a429067 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -6895,6 +6895,7 @@ static void disas_simd_ext(DisasContext *s, uint32_t insn)
tcg_temp_free_i64(tcg_resl);
write_vec_element(s, tcg_resh, rd, 1, MO_64);
tcg_temp_free_i64(tcg_resh);
+ clear_vec_high(s, true, rd);
}
/* TBL/TBX
--
2.20.1
^ permalink raw reply related
* [PATCH v2 4.14] padata: Remove broken queue flushing
From: Daniel Jordan @ 2020-02-14 19:46 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin
Cc: Steffen Klassert, linux-kernel, Herbert Xu, stable, Daniel Jordan
In-Reply-To: <20200213151948.275124464@linuxfoundation.org>
From: Herbert Xu <herbert@gondor.apana.org.au>
[ Upstream commit 07928d9bfc81640bab36f5190e8725894d93b659 ]
The function padata_flush_queues is fundamentally broken because
it cannot force padata users to complete the request that is
underway. IOW padata has to passively wait for the completion
of any outstanding work.
As it stands flushing is used in two places. Its use in padata_stop
is simply unnecessary because nothing depends on the queues to
be flushed afterwards.
The other use in padata_replace is more substantial as we depend
on it to free the old pd structure. This patch instead uses the
pd->refcnt to dynamically free the pd structure once all requests
are complete.
Fixes: 2b73b07ab8a4 ("padata: Flush the padata queues actively")
Cc: <stable@vger.kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[dj: leave "pd->pinst = pinst" assignment in padata_alloc_pd()]
Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
---
kernel/padata.c | 45 ++++++++++++---------------------------------
1 file changed, 12 insertions(+), 33 deletions(-)
diff --git a/kernel/padata.c b/kernel/padata.c
index 87540ce72aea..528a251217df 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -34,6 +34,8 @@
#define MAX_OBJ_NUM 1000
+static void padata_free_pd(struct parallel_data *pd);
+
static int padata_index_to_cpu(struct parallel_data *pd, int cpu_index)
{
int cpu, target_cpu;
@@ -292,6 +294,7 @@ static void padata_serial_worker(struct work_struct *serial_work)
struct padata_serial_queue *squeue;
struct parallel_data *pd;
LIST_HEAD(local_list);
+ int cnt;
local_bh_disable();
squeue = container_of(serial_work, struct padata_serial_queue, work);
@@ -301,6 +304,8 @@ static void padata_serial_worker(struct work_struct *serial_work)
list_replace_init(&squeue->serial.list, &local_list);
spin_unlock(&squeue->serial.lock);
+ cnt = 0;
+
while (!list_empty(&local_list)) {
struct padata_priv *padata;
@@ -310,9 +315,12 @@ static void padata_serial_worker(struct work_struct *serial_work)
list_del_init(&padata->list);
padata->serial(padata);
- atomic_dec(&pd->refcnt);
+ cnt++;
}
local_bh_enable();
+
+ if (atomic_sub_and_test(cnt, &pd->refcnt))
+ padata_free_pd(pd);
}
/**
@@ -435,7 +443,7 @@ static struct parallel_data *padata_alloc_pd(struct padata_instance *pinst,
setup_timer(&pd->timer, padata_reorder_timer, (unsigned long)pd);
atomic_set(&pd->seq_nr, -1);
atomic_set(&pd->reorder_objects, 0);
- atomic_set(&pd->refcnt, 0);
+ atomic_set(&pd->refcnt, 1);
pd->pinst = pinst;
spin_lock_init(&pd->lock);
@@ -460,31 +468,6 @@ static void padata_free_pd(struct parallel_data *pd)
kfree(pd);
}
-/* Flush all objects out of the padata queues. */
-static void padata_flush_queues(struct parallel_data *pd)
-{
- int cpu;
- struct padata_parallel_queue *pqueue;
- struct padata_serial_queue *squeue;
-
- for_each_cpu(cpu, pd->cpumask.pcpu) {
- pqueue = per_cpu_ptr(pd->pqueue, cpu);
- flush_work(&pqueue->work);
- }
-
- del_timer_sync(&pd->timer);
-
- if (atomic_read(&pd->reorder_objects))
- padata_reorder(pd);
-
- for_each_cpu(cpu, pd->cpumask.cbcpu) {
- squeue = per_cpu_ptr(pd->squeue, cpu);
- flush_work(&squeue->work);
- }
-
- BUG_ON(atomic_read(&pd->refcnt) != 0);
-}
-
static void __padata_start(struct padata_instance *pinst)
{
pinst->flags |= PADATA_INIT;
@@ -498,10 +481,6 @@ static void __padata_stop(struct padata_instance *pinst)
pinst->flags &= ~PADATA_INIT;
synchronize_rcu();
-
- get_online_cpus();
- padata_flush_queues(pinst->pd);
- put_online_cpus();
}
/* Replace the internal control structure with a new one. */
@@ -522,8 +501,8 @@ static void padata_replace(struct padata_instance *pinst,
if (!cpumask_equal(pd_old->cpumask.cbcpu, pd_new->cpumask.cbcpu))
notification_mask |= PADATA_CPU_SERIAL;
- padata_flush_queues(pd_old);
- padata_free_pd(pd_old);
+ if (atomic_dec_and_test(&pd_old->refcnt))
+ padata_free_pd(pd_old);
if (notification_mask)
blocking_notifier_call_chain(&pinst->cpumask_change_notifier,
--
2.25.0
^ permalink raw reply related
* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstall
From: Patchwork @ 2020-02-14 19:47 UTC (permalink / raw)
To: Jani Nikula; +Cc: intel-gfx
In-Reply-To: <20200214135058.7580-1-jani.nikula@intel.com>
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstall
URL : https://patchwork.freedesktop.org/series/73469/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7942 -> Patchwork_16574
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16574/index.html
Known issues
------------
Here are the changes found in Patchwork_16574 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [PASS][1] -> [DMESG-FAIL][2] ([i915#877])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16574/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
#### Possible fixes ####
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8700k: [INCOMPLETE][3] ([i915#424]) -> [PASS][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16574/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
[i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
Participating hosts (47 -> 39)
------------------------------
Additional (4): fi-bsw-kefka fi-blb-e6850 fi-cfl-8109u fi-ilk-650
Missing (12): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-skl-lmem fi-bdw-samus fi-byt-n2820 fi-skl-6600u fi-kbl-r
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7942 -> Patchwork_16574
CI-20190529: 20190529
CI_DRM_7942: f4805f5a516d0a107438ff0f236c9f4187434819 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5442: 3f6080996885b997685f08ecb8b416b2dc485290 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16574: 8185da98b0f023ec8d2e2aeea5bf81d1a28af187 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8185da98b0f0 drm/i915: split i915_driver_modeset_remove() to pre/post irq uninstall
5b99455a74fd drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstall
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16574/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 2/4] target/arm: Flush high bits of sve register after AdvSIMD TBL/TBX
From: Richard Henderson @ 2020-02-14 19:46 UTC (permalink / raw)
To: qemu-devel; +Cc: peter.maydell, qemu-arm
In-Reply-To: <20200214194643.23317-1-richard.henderson@linaro.org>
Writes to AdvSIMD registers flush the bits above 128.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
target/arm/translate-a64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index 620a429067..096a854aed 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -6964,6 +6964,7 @@ static void disas_simd_tb(DisasContext *s, uint32_t insn)
tcg_temp_free_i64(tcg_resl);
write_vec_element(s, tcg_resh, rd, 1, MO_64);
tcg_temp_free_i64(tcg_resh);
+ clear_vec_high(s, true, rd);
}
/* ZIP/UZP/TRN
--
2.20.1
^ permalink raw reply related
* [PATCH 0/4] target/arm: fix some simd writes vs sve
From: Richard Henderson @ 2020-02-14 19:46 UTC (permalink / raw)
To: qemu-devel; +Cc: peter.maydell, qemu-arm
The launchpad bug only mentions EXT, but I found three more
via inspection. I really should extend RISU so that we can
do AdvSIMD testing with SVE enabled...
r~
Richard Henderson (4):
target/arm: Flush high bits of sve register after AdvSIMD EXT
target/arm: Flush high bits of sve register after AdvSIMD TBL/TBX
target/arm: Flush high bits of sve register after AdvSIMD ZIP/UZP/TRN
target/arm: Flush high bits of sve register after AdvSIMD INS
target/arm/translate-a64.c | 9 +++++++++
1 file changed, 9 insertions(+)
--
2.20.1
^ permalink raw reply
* [PATCH AUTOSEL 4.9 106/141] ide: remove set but not used variable 'hwif'
From: Sasha Levin @ 2020-02-14 16:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Wang Hai, linux-ide, Hulk Robot, linuxppc-dev,
David S . Miller
In-Reply-To: <20200214162122.19794-1-sashal@kernel.org>
From: Wang Hai <wanghai38@huawei.com>
[ Upstream commit 98949a1946d70771789def0c9dbc239497f9f138 ]
Fix the following gcc warning:
drivers/ide/pmac.c: In function pmac_ide_setup_device:
drivers/ide/pmac.c:1027:14: warning: variable hwif set but not used
[-Wunused-but-set-variable]
Fixes: d58b0c39e32f ("powerpc/macio: Rework hotplug media bay support")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/ide/pmac.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
index b20025a5a8d93..9c48ff85bbbbb 100644
--- a/drivers/ide/pmac.c
+++ b/drivers/ide/pmac.c
@@ -1024,7 +1024,6 @@ static int pmac_ide_setup_device(pmac_ide_hwif_t *pmif, struct ide_hw *hw)
struct device_node *np = pmif->node;
const int *bidp;
struct ide_host *host;
- ide_hwif_t *hwif;
struct ide_hw *hws[] = { hw };
struct ide_port_info d = pmac_port_info;
int rc;
@@ -1080,7 +1079,7 @@ static int pmac_ide_setup_device(pmac_ide_hwif_t *pmif, struct ide_hw *hw)
rc = -ENOMEM;
goto bail;
}
- hwif = pmif->hwif = host->ports[0];
+ pmif->hwif = host->ports[0];
if (on_media_bay(pmif)) {
/* Fixup bus ID for media bay */
--
2.20.1
^ permalink raw reply related
* Re: [Virtio-fs] fedora packages for virtiofsd
From: Dr. David Alan Gilbert @ 2020-02-14 19:44 UTC (permalink / raw)
To: Vivek Goyal, crobinso; +Cc: virtio-fs-list, Mrunal Patel
In-Reply-To: <20200214191753.GC18654@redhat.com>
* Vivek Goyal (vgoyal@redhat.com) wrote:
> Hi David,
>
> Are fedora packages for latest qemu with virtiofsd now available. Can one
> try it?
>
> Dan Walsh and Mrunal are looking for it (CCed in email).
>
> Keeping this thread on virtio-fs list as others might be interested as
> well.
Cole has got it into the virt-preview copr:
https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/virt-preview
Dave
> Thanks
> Vivek
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* Re: [PATCH rdma] IB/mlx5: Fix linkage failure on 32-bit arches
From: Alexander Lobakin @ 2020-02-14 19:44 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Leon Romanovsky, Doug Ledford, Yishai Hadas, Maxim Mikityanskiy,
linux-rdma, linux-kernel
In-Reply-To: <20200214192410.GW31668@ziepe.ca>
Jason Gunthorpe wrote 14.02.2020 22:24:
> On Fri, Feb 14, 2020 at 10:13:09PM +0300, Alexander Lobakin wrote:
>> Commit f164be8c0366 ("IB/mlx5: Extend caps stage to handle VAR
>> capabilities") introduced a straight "/" division of the u64
>> variable "bar_size", which emits an __udivdi3() libgcc call on
>> 32-bit arches and certain GCC versions:
>>
>> error: "__udivdi3" [drivers/infiniband/hw/mlx5/mlx5_ib.ko] undefined!
>> [1]
>>
>> Replace it with the corresponding div_u64() call.
>> Compile-tested on ARCH=mips 32r2el_defconfig BOARDS=ocelot.
>>
>> [1]
>> https://lore.kernel.org/linux-mips/CAMuHMdXM9S1VkFMZ8eDAyZR6EE4WkJY215Lcn2qdOaPeadF+EQ@mail.gmail.com/
>>
>> Fixes: f164be8c0366 ("IB/mlx5: Extend caps stage to handle VAR
>> capabilities")
>> Signed-off-by: Alexander Lobakin <alobakin@dlink.ru>
>> ---
>> drivers/infiniband/hw/mlx5/main.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Randy beat you too it..
>
> https://lore.kernel.org/linux-rdma/20200206143201.GF25297@ziepe.ca/
Ah, OK. Sorry for missing this one. I didn't see any fix over
git.kernel.org and thought it doesn't exist yet.
> But it seems patchwork missed this somehow.
>
> Applied now at least
Thanks!
> Jason
Regards,
ᚷ ᛖ ᚢ ᚦ ᚠ ᚱ
^ permalink raw reply
* [meta-oe][PATCH v2 1/1] spidev-test: Add initial version of recipe
From: Jonathan Richardson @ 2020-02-14 19:44 UTC (permalink / raw)
To: openembedded-devel; +Cc: Arun Parameswaran
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 | 29 +++++++++++++++++++
1 file changed, 29 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..662630291
--- /dev/null
+++ b/meta-oe/recipes-kernel/spidev-test/spidev-test.bb
@@ -0,0 +1,29 @@
+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"
+PROVIDES = "virtual/spidev-test"
+
+inherit bash-completion kernelsrc kernel-arch
+
+do_populate_lic[depends] += "virtual/kernel:do_patch"
+
+EXTRA_OEMAKE = "-C ${S}/tools/spi O=${B} CROSS=${TARGET_PREFIX} CC="${CC}" LD="${LD}" AR=${AR} ARCH=${ARCH}"
+
+do_configure[depends] += "virtual/kernel:do_shared_workdir"
+
+do_compile() {
+ oe_runmake
+}
+
+do_install() {
+ oe_runmake DESTDIR=${D} install
+}
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+python do_package_prepend() {
+ d.setVar('PKGV', d.getVar("KERNEL_VERSION", True).split("-")[0])
+}
+
+B = "${WORKDIR}/${BPN}-${PV}"
--
2.17.1
^ permalink raw reply related
* [PATCH v2] dt-bindings: net: mdio: remove compatible string from example
From: Grygorii Strashko @ 2020-02-14 19:44 UTC (permalink / raw)
To: Rob Herring, Simon Horman, Andrew Lunn, Florian Fainelli,
Mark Rutland, Heiner Kallweit, devicetree
Cc: David S . Miller, netdev, linux-kernel, Grygorii Strashko
Remove vendor specific compatible string from example, otherwise DT YAML
schemas validation may trigger warnings specific to TI ti,davinci_mdio
and not to the generic MDIO example.
For example, the "bus_freq" is required for davinci_mdio, but not required for
generic mdio example. As result following warning will be produced:
mdio.example.dt.yaml: mdio@5c030000: 'bus_freq' is a required property
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
Remove compatible string from example instead of changing it.
v1: https://patchwork.ozlabs.org/patch/1201674/
Documentation/devicetree/bindings/net/mdio.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/mdio.yaml b/Documentation/devicetree/bindings/net/mdio.yaml
index 5d08d2ffd4eb..50c3397a82bc 100644
--- a/Documentation/devicetree/bindings/net/mdio.yaml
+++ b/Documentation/devicetree/bindings/net/mdio.yaml
@@ -56,7 +56,6 @@ patternProperties:
examples:
- |
davinci_mdio: mdio@5c030000 {
- compatible = "ti,davinci_mdio";
reg = <0x5c030000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
--
2.17.1
^ permalink raw reply related
* [meta-python][PATCH] python3-booleanpy: consolidate inc and bb files into a single bb file
From: Derek Straka @ 2020-02-14 19:44 UTC (permalink / raw)
To: openembedded-devel
Signed-off-by: Derek Straka <derek@asterius.io>
---
.../recipes-devtools/python/python-booleanpy.inc | 14 --------------
.../python/python3-booleanpy_3.7.bb | 16 ++++++++++++++--
2 files changed, 14 insertions(+), 16 deletions(-)
delete mode 100644 meta-python/recipes-devtools/python/python-booleanpy.inc
diff --git a/meta-python/recipes-devtools/python/python-booleanpy.inc b/meta-python/recipes-devtools/python/python-booleanpy.inc
deleted file mode 100644
index 335d7d396d..0000000000
--- a/meta-python/recipes-devtools/python/python-booleanpy.inc
+++ /dev/null
@@ -1,14 +0,0 @@
-SUMMARY = "Define boolean algebras, create and parse boolean expressions and create custom boolean DSL"
-HOMEPAGE = "https://github.com/bastikr/boolean.py"
-
-LICENSE = "BSD-2-Clause"
-LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=e319747a5eb94cddf646037c01ddba47"
-
-SRC_URI[md5sum] = "1189d115a38f84f5df743014926a9159"
-SRC_URI[sha256sum] = "bd19b412435611ecc712603d0fd7d0e280e24698e7a6e3d5f610473870c5dd1e"
-
-PYPI_PACKAGE = "boolean.py"
-
-inherit pypi
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-python/recipes-devtools/python/python3-booleanpy_3.7.bb b/meta-python/recipes-devtools/python/python3-booleanpy_3.7.bb
index 5f8602d187..ebf7ba4e74 100644
--- a/meta-python/recipes-devtools/python/python3-booleanpy_3.7.bb
+++ b/meta-python/recipes-devtools/python/python3-booleanpy_3.7.bb
@@ -1,2 +1,14 @@
-inherit setuptools3
-require python-booleanpy.inc
+SUMMARY = "Define boolean algebras, create and parse boolean expressions and create custom boolean DSL"
+HOMEPAGE = "https://github.com/bastikr/boolean.py"
+
+LICENSE = "BSD-2-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=e319747a5eb94cddf646037c01ddba47"
+
+SRC_URI[md5sum] = "1189d115a38f84f5df743014926a9159"
+SRC_URI[sha256sum] = "bd19b412435611ecc712603d0fd7d0e280e24698e7a6e3d5f610473870c5dd1e"
+
+PYPI_PACKAGE = "boolean.py"
+
+inherit pypi setuptools3
+
+BBCLASSEXTEND = "native nativesdk"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v4 0/6] drm/virtio: rework batching
From: Chia-I Wu @ 2020-02-14 19:44 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: ML dri-devel, Gurchetan Singh
In-Reply-To: <20200214125535.26349-1-kraxel@redhat.com>
Series is
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Thanks!
On Fri, Feb 14, 2020 at 4:55 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> v4:
> - add patches #2 + #6.
> v3:
> - split into multiple patches.
>
> Gerd Hoffmann (6):
> drm/virtio: rework notification for better batching
> drm/virtio: notify before waiting
> drm/virtio: batch plane updates (pageflip)
> drm/virtio: batch resource creation
> drm/virtio: batch display query
> drm/virtio: move remaining virtio_gpu_notify calls
>
> drivers/gpu/drm/virtio/virtgpu_drv.h | 6 ++---
> drivers/gpu/drm/virtio/virtgpu_display.c | 2 ++
> drivers/gpu/drm/virtio/virtgpu_gem.c | 2 ++
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +++
> drivers/gpu/drm/virtio/virtgpu_kms.c | 5 ++++
> drivers/gpu/drm/virtio/virtgpu_object.c | 2 ++
> drivers/gpu/drm/virtio/virtgpu_plane.c | 7 +++--
> drivers/gpu/drm/virtio/virtgpu_vq.c | 33 ++++++++++--------------
> 8 files changed, 34 insertions(+), 27 deletions(-)
>
> --
> 2.18.2
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 03/12] MIPS: CI20: defconfig: configure for supporting modules
From: Paul Cercueil @ 2020-02-14 19:42 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Paul Boddie, Rob Herring, Mark Rutland, Ralf Baechle, Paul Burton,
David Airlie, Daniel Vetter, Andi Kleen, Miquel Raynal, Kees Cook,
devicetree, linux-mips, linux-kernel, dri-devel, letux-kernel,
kernel
In-Reply-To: <AD9439FF-9DEF-4B9A-8A01-F11B626708C1@goldelico.com>
Le ven., févr. 14, 2020 at 20:30, H. Nikolaus Schaller
<hns@goldelico.com> a écrit :
> Hi Paul,
>
>> Am 14.02.2020 um 20:10 schrieb Paul Cercueil <paul@crapouillou.net>:
>>
>> Hi Nikolaus,
>>
>> Patches 03-12 only touch the same two files - ci20.dts and
>> ci20_defconfig.
>>
>> Unless someone strongly disagrees, I'd suggest to squash all
>> patches that touch each file together (except the ones with a Fixes
>> tag), I don't think we really need that much granularity here.
>
> It comes more from having developed these things quite independently
> and only collected for submission...
>
> One patch I don't know how to handle: "MIPS: DTS: CI20: add DT node
> for IR sensor".
> It is from 2015 and has a different author (some Alex Smith but the
> mail address seems to be broken).
> This information and attribution will be lost if we squash them.
Ah, alright. Then I guess keep this one separate.
-Paul
>
> But I can do for V3 and will also fix the fixes tags by adding cc:
> stable :)
>
> BR and thanks,
> Nikolaus
>
>
>>
>> -Paul
>>
>>
>> Le ven., févr. 14, 2020 at 17:10, H. Nikolaus Schaller
>> <hns@goldelico.com> a écrit :
>>> Not all drivers need to be compiled into the kernel.
>>> Support building and loading of kernel modules.
>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>> ---
>>> arch/mips/configs/ci20_defconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>> diff --git a/arch/mips/configs/ci20_defconfig
>>> b/arch/mips/configs/ci20_defconfig
>>> index be41df2a81fb..e0d3c9d4c2ae 100644
>>> --- a/arch/mips/configs/ci20_defconfig
>>> +++ b/arch/mips/configs/ci20_defconfig
>>> @@ -1,4 +1,5 @@
>>> # CONFIG_LOCALVERSION_AUTO is not set
>>> +CONFIG_MODULES=y
>>> CONFIG_KERNEL_XZ=y
>>> CONFIG_SYSVIPC=y
>>> CONFIG_POSIX_MQUEUE=y
>>> --
>>> 2.23.0
>>
>>
>
^ permalink raw reply
* 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
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.