| Age | Commit message (Collapse) | Author |
|---|
|
In the past, readdir assumed that the user buffer will be large enough
that all entries from the server will fit. If this was not true,
entries would be skipped.
Since it works now, request 512 entries rather than 96 per server
operation.
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
|
|
Since orangefs_lookup calls orangefs_iget which calls
orangefs_inode_getattr, getattr_time will get set.
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
|
|
Also don't check flags as this has been validated by the VFS already.
Fix an off-by-one error in the max size checking.
Stop logging just because userspace wants to write attributes which do
not fit.
This and the previous commit fix xfstests generic/020.
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
|
|
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
|
|
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
|
|
The Ethernet link on an interrupt driven PHY was not coming up if the Ethernet
cable was plugged before the Ethernet interface was brought up.
The patch trigger PHY state machine to update link state if PHY was requested to
do auto-negotiation and auto-negotiation complete flag already set.
During power-up cycle the PHY do auto-negotiation, generate interrupt and set
auto-negotiation complete flag. Interrupt is handled by PHY state machine but
doesn't update link state because PHY is in PHY_READY state. After some time
MAC bring up, start and request PHY to do auto-negotiation. If there are no new
settings to advertise genphy_config_aneg() doesn't start PHY auto-negotiation.
PHY continue to stay in auto-negotiation complete state and doesn't fire
interrupt. At the same time PHY state machine expect that PHY started
auto-negotiation and is waiting for interrupt from PHY and it won't get it.
Fixes: 321beec5047a ("net: phy: Use interrupts when available in NOLINK state")
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
Cc: stable <stable@vger.kernel.org> # v4.9+
Tested-by: Roger Quadros <rogerq@ti.com>
Tested-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
No need to pollute util.h with this.
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/n/tip-kec0chbdtgrd71o3oi2kz2zt@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
This is a perl specific hack, so move it from util.h to where perl
headers are used.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-4igctbinuom2sr6g4b03jqht@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
In the past, SRCU was simple enough that there was little point in
making the rcutorture writer stall messages print the SRCU grace-period
number state. With the advent of Tree SRCU, this has changed. This
commit therefore makes Classic, Tiny, and Tree SRCU report this state
to rcutorture as needed.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Mike Galbraith <efault@gmx.de>
|
|
The current Tree SRCU implementation schedules a workqueue for every
srcu_data covered by a given leaf srcu_node structure having callbacks,
even if only one of those srcu_data structures actually contains
callbacks. This is clearly inefficient for workloads that don't feature
callbacks everywhere all the time. This commit therefore adds an array
of masks that are used by the leaf srcu_node structures to track exactly
which srcu_data structures contain callbacks.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Mike Galbraith <efault@gmx.de>
|
|
If the client receives a fatal server error from nfs_pageio_add_request(),
then we should always truncate the page on which the error occurred.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
|
|
EACCES, EDQUOT, EFBIG and ESTALE are all fatal errors as far as NFS
I/O is concerned. They need to be reported back to the application.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
|
|
On 32-bit machines, we can't divide 64-bit integers:
drivers/gpu/drm/arm/malidp_crtc.o: In function `malidp_crtc_atomic_check':
malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3c0): undefined reference to `__aeabi_uldivmod'
malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3dc): undefined reference to `__aeabi_uldivmod'
This calls the div_u64 function explicitly instead.
Fixes: 4cea4e9f6690 ("drm: mali-dp: Add plane upscaling support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Since we got a bonus week, let me try to screw a few pending fixes.
A slightly large fix is the locking fix in ASoC STI driver, but it's
pretty board-specific, and the risk is fairly low.
All the rest are small / trivial fixes, mostly marked as stable, for
ALSA sequencer core, ASoC topology, ASoC Intel bytcr and Firewire
drivers"
* tag 'sound-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: intel: Fix PM and non-atomic crash in bytcr drivers
ALSA: firewire-lib: fix inappropriate assignment between signed/unsigned type
ALSA: seq: Don't break snd_use_lock_sync() loop by timeout
ASoC: topology: Fix to store enum text values
ASoC: STI: Fix null ptr deference in IRQ handler
ALSA: oxfw: fix regression to handle Stanton SCS.1m/1d
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
all architectures converted
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
'uaccess.arm64', 'uaccess.avr32', 'uaccess.bfin', 'uaccess.c6x', 'uaccess.cris', 'uaccess.frv', 'uaccess.h8300', 'uaccess.hexagon', 'uaccess.ia64', 'uaccess.m32r', 'uaccess.m68k', 'uaccess.metag', 'uaccess.microblaze', 'uaccess.mips', 'uaccess.mn10300', 'uaccess.nios2', 'uaccess.openrisc', 'uaccess.parisc', 'uaccess.powerpc', 'uaccess.s390', 'uaccess.score', 'uaccess.sh', 'uaccess.sparc', 'uaccess.tile', 'uaccess.um', 'uaccess.unicore32', 'uaccess.x86' and 'uaccess.xtensa' into work.uaccess
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
This patch implements SAI ASoC driver for STM32.
Signed-off-by: olivier moysan <olivier.moysan@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patch adds documentation of device tree bindings for the
STM32 SAI ASoC driver.
Signed-off-by: olivier moysan <olivier.moysan@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently when there are buffered writes that were not yet flushed and
they fall within allocated ranges of the file (that is, not in holes or
beyond eof assuming there are no prealloc extents beyond eof), btrfs
simply reports an incorrect number of used blocks through the stat(2)
system call (or any of its variants), regardless of mount options or
inode flags (compress, compress-force, nodatacow). This is because the
number of blocks used that is reported is based on the current number
of bytes in the vfs inode plus the number of dealloc bytes in the btrfs
inode. The later covers bytes that both fall within allocated regions
of the file and holes.
Example scenarios where the number of reported blocks is wrong while the
buffered writes are not flushed:
$ mkfs.btrfs -f /dev/sdc
$ mount /dev/sdc /mnt/sdc
$ xfs_io -f -c "pwrite -S 0xaa 0 64K" /mnt/sdc/foo1
wrote 65536/65536 bytes at offset 0
64 KiB, 16 ops; 0.0000 sec (259.336 MiB/sec and 66390.0415 ops/sec)
$ sync
$ xfs_io -c "pwrite -S 0xbb 0 64K" /mnt/sdc/foo1
wrote 65536/65536 bytes at offset 0
64 KiB, 16 ops; 0.0000 sec (192.308 MiB/sec and 49230.7692 ops/sec)
# The following should have reported 64K...
$ du -h /mnt/sdc/foo1
128K /mnt/sdc/foo1
$ sync
# After flushing the buffered write, it now reports the correct value.
$ du -h /mnt/sdc/foo1
64K /mnt/sdc/foo1
$ xfs_io -f -c "falloc -k 0 128K" -c "pwrite -S 0xaa 0 64K" /mnt/sdc/foo2
wrote 65536/65536 bytes at offset 0
64 KiB, 16 ops; 0.0000 sec (520.833 MiB/sec and 133333.3333 ops/sec)
$ sync
$ xfs_io -c "pwrite -S 0xbb 64K 64K" /mnt/sdc/foo2
wrote 65536/65536 bytes at offset 65536
64 KiB, 16 ops; 0.0000 sec (260.417 MiB/sec and 66666.6667 ops/sec)
# The following should have reported 128K...
$ du -h /mnt/sdc/foo2
192K /mnt/sdc/foo2
$ sync
# After flushing the buffered write, it now reports the correct value.
$ du -h /mnt/sdc/foo2
128K /mnt/sdc/foo2
So the number of used file blocks is simply incorrect, unlike in other
filesystems such as ext4 and xfs for example, but only while the buffered
writes are not flushed.
Fix this by tracking the number of delalloc bytes that fall within holes
and beyond eof of a file, and use instead this new counter when reporting
the number of used blocks for an inode.
Another different problem that exists is that the delalloc bytes counter
is reset when writeback starts (by clearing the EXTENT_DEALLOC flag from
the respective range in the inode's iotree) and the vfs inode's bytes
counter is only incremented when writeback finishes (through
insert_reserved_file_extent()). Therefore while writeback is ongoing we
simply report a wrong number of blocks used by an inode if the write
operation covers a range previously unallocated. While this change does
not fix this problem, it does minimizes it a lot by shortening that time
window, as the new dealloc bytes counter (new_delalloc_bytes) is only
decremented when writeback finishes right before updating the vfs inode's
bytes counter. Fully fixing this second problem is not trivial and will
be addressed later by a different patch.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
|
|
Normally we don't have inline extents followed by regular extents, but
there's currently at least one harmless case where this happens. For
example, when the page size is 4Kb and compression is enabled:
$ mkfs.btrfs -f /dev/sdb
$ mount -o compress /dev/sdb /mnt
$ xfs_io -f -c "pwrite -S 0xaa 0 4K" -c "fsync" /mnt/foobar
$ xfs_io -c "pwrite -S 0xbb 8K 4K" -c "fsync" /mnt/foobar
In this case we get a compressed inline extent, representing 4Kb of
data, followed by a hole extent and then a regular data extent. The
inline extent was not expanded/converted to a regular extent exactly
because it represents 4Kb of data. This does not cause any apparent
problem (such as the issue solved by commit e1699d2d7bf6
("btrfs: add missing memset while reading compressed inline extents"))
except trigger an unexpected case in the incremental send code path
that makes us issue an operation to write a hole when it's not needed,
resulting in more writes at the receiver and wasting space at the
receiver.
So teach the incremental send code to deal with this particular case.
The issue can be currently triggered by running fstests btrfs/137 with
compression enabled (MOUNT_OPTIONS="-o compress" ./check btrfs/137).
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
|
|
If the call to btrfs_qgroup_reserve_data() failed, we were leaking an
extent map structure. The failure can happen either due to an -ENOMEM
condition or, when quotas are enabled, due to -EDQUOT for example.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
|
|
When using compression, if we fail to insert an inline extent we
incorrectly end up attempting to free the reserved data space twice,
once through extent_clear_unlock_delalloc(), because we pass it the
flag EXTENT_DO_ACCOUNTING, and once through a direct call to
btrfs_free_reserved_data_space_noquota(). This results in a trace
like the following:
[ 834.576240] ------------[ cut here ]------------
[ 834.576825] WARNING: CPU: 2 PID: 486 at fs/btrfs/extent-tree.c:4316 btrfs_free_reserved_data_space_noquota+0x60/0x9f [btrfs]
[ 834.579501] Modules linked in: btrfs crc32c_generic xor raid6_pq ppdev i2c_piix4 acpi_cpufreq psmouse tpm_tis parport_pc pcspkr serio_raw tpm_tis_core sg parport evdev i2c_core tpm button loop autofs4 ext4 crc16 jbd2 mbcache sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix virtio_pci libata virtio_ring virtio scsi_mod e1000 floppy [last unloaded: btrfs]
[ 834.592116] CPU: 2 PID: 486 Comm: kworker/u32:4 Not tainted 4.10.0-rc8-btrfs-next-37+ #2
[ 834.593316] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
[ 834.595273] Workqueue: btrfs-delalloc btrfs_delalloc_helper [btrfs]
[ 834.596103] Call Trace:
[ 834.596103] dump_stack+0x67/0x90
[ 834.596103] __warn+0xc2/0xdd
[ 834.596103] warn_slowpath_null+0x1d/0x1f
[ 834.596103] btrfs_free_reserved_data_space_noquota+0x60/0x9f [btrfs]
[ 834.596103] compress_file_range.constprop.42+0x2fa/0x3fc [btrfs]
[ 834.596103] ? submit_compressed_extents+0x3a7/0x3a7 [btrfs]
[ 834.596103] async_cow_start+0x32/0x4d [btrfs]
[ 834.596103] btrfs_scrubparity_helper+0x187/0x3e7 [btrfs]
[ 834.596103] btrfs_delalloc_helper+0xe/0x10 [btrfs]
[ 834.596103] process_one_work+0x273/0x4e4
[ 834.596103] worker_thread+0x1eb/0x2ca
[ 834.596103] ? rescuer_thread+0x2b6/0x2b6
[ 834.596103] kthread+0x100/0x108
[ 834.596103] ? __list_del_entry+0x22/0x22
[ 834.596103] ret_from_fork+0x2e/0x40
[ 834.611656] ---[ end trace 719902fe6bdef08f ]---
So fix this by not calling directly btrfs_free_reserved_data_space_noquota()
if an error happened.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
|
|
When attempting to COW a file range (we are starting writeback and doing
COW), if we manage to reserve an extent for the range we will write into
but fail after reserving it and before creating the respective ordered
extent, we end up in an error path where we attempt to decrement the
data space's bytes_may_use counter after we already did it while
reserving the extent, leading to a warning/trace like the following:
[ 847.621524] ------------[ cut here ]------------
[ 847.625441] WARNING: CPU: 5 PID: 4905 at fs/btrfs/extent-tree.c:4316 btrfs_free_reserved_data_space_noquota+0x60/0x9f [btrfs]
[ 847.633704] Modules linked in: btrfs crc32c_generic xor raid6_pq acpi_cpufreq i2c_piix4 ppdev psmouse tpm_tis serio_raw pcspkr parport_pc tpm_tis_core i2c_core sg
[ 847.644616] CPU: 5 PID: 4905 Comm: xfs_io Not tainted 4.10.0-rc8-btrfs-next-37+ #2
[ 847.648601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
[ 847.648601] Call Trace:
[ 847.648601] dump_stack+0x67/0x90
[ 847.648601] __warn+0xc2/0xdd
[ 847.648601] warn_slowpath_null+0x1d/0x1f
[ 847.648601] btrfs_free_reserved_data_space_noquota+0x60/0x9f [btrfs]
[ 847.648601] btrfs_clear_bit_hook+0x140/0x258 [btrfs]
[ 847.648601] clear_state_bit+0x87/0x128 [btrfs]
[ 847.648601] __clear_extent_bit+0x222/0x2b7 [btrfs]
[ 847.648601] clear_extent_bit+0x17/0x19 [btrfs]
[ 847.648601] extent_clear_unlock_delalloc+0x3b/0x6b [btrfs]
[ 847.648601] cow_file_range.isra.39+0x387/0x39a [btrfs]
[ 847.648601] run_delalloc_nocow+0x4d7/0x70e [btrfs]
[ 847.648601] ? arch_local_irq_save+0x9/0xc
[ 847.648601] run_delalloc_range+0xa7/0x2b5 [btrfs]
[ 847.648601] writepage_delalloc.isra.31+0xb9/0x15c [btrfs]
[ 847.648601] __extent_writepage+0x249/0x2e8 [btrfs]
[ 847.648601] extent_write_cache_pages.constprop.33+0x28b/0x36c [btrfs]
[ 847.648601] ? arch_local_irq_save+0x9/0xc
[ 847.648601] ? mark_lock+0x24/0x201
[ 847.648601] extent_writepages+0x4b/0x5c [btrfs]
[ 847.648601] ? btrfs_writepage_start_hook+0xed/0xed [btrfs]
[ 847.648601] btrfs_writepages+0x28/0x2a [btrfs]
[ 847.648601] do_writepages+0x23/0x2c
[ 847.648601] __filemap_fdatawrite_range+0x5a/0x61
[ 847.648601] filemap_fdatawrite_range+0x13/0x15
[ 847.648601] btrfs_fdatawrite_range+0x20/0x46 [btrfs]
[ 847.648601] start_ordered_ops+0x19/0x23 [btrfs]
[ 847.648601] btrfs_sync_file+0x136/0x42c [btrfs]
[ 847.648601] vfs_fsync_range+0x8c/0x9e
[ 847.648601] vfs_fsync+0x1c/0x1e
[ 847.648601] do_fsync+0x31/0x4a
[ 847.648601] SyS_fsync+0x10/0x14
[ 847.648601] entry_SYSCALL_64_fastpath+0x18/0xad
[ 847.648601] RIP: 0033:0x7f5b05200800
[ 847.648601] RSP: 002b:00007ffe204f71c8 EFLAGS: 00000246 ORIG_RAX: 000000000000004a
[ 847.648601] RAX: ffffffffffffffda RBX: ffffffff8109637b RCX: 00007f5b05200800
[ 847.648601] RDX: 00000000008bd0a0 RSI: 00000000008bd2e0 RDI: 0000000000000003
[ 847.648601] RBP: ffffc90001d67f98 R08: 000000000000ffff R09: 000000000000001f
[ 847.648601] R10: 00000000000001f6 R11: 0000000000000246 R12: 0000000000000046
[ 847.648601] R13: ffffc90001d67f78 R14: 00007f5b054be740 R15: 00007f5b054be740
[ 847.648601] ? trace_hardirqs_off_caller+0x3f/0xaa
[ 847.685787] ---[ end trace 2a4a3e15382508e8 ]---
So fix this by not attempting to decrement the data space info's
bytes_may_use counter if we already reserved the extent and an error
happened before creating the ordered extent. We are already correctly
freeing the reserved extent if an error happens, so there's no additional
measure needed.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
|
|
[BUG]
If run_delalloc_range() returns error and there is already some ordered
extents created, btrfs will be hanged with the following backtrace:
Call Trace:
__schedule+0x2d4/0xae0
schedule+0x3d/0x90
btrfs_start_ordered_extent+0x160/0x200 [btrfs]
? wake_atomic_t_function+0x60/0x60
btrfs_run_ordered_extent_work+0x25/0x40 [btrfs]
btrfs_scrubparity_helper+0x1c1/0x620 [btrfs]
btrfs_flush_delalloc_helper+0xe/0x10 [btrfs]
process_one_work+0x2af/0x720
? process_one_work+0x22b/0x720
worker_thread+0x4b/0x4f0
kthread+0x10f/0x150
? process_one_work+0x720/0x720
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x2e/0x40
[CAUSE]
|<------------------ delalloc range --------------------------->|
| OE 1 | OE 2 | ... | OE n |
|<>| |<---------- cleanup range --------->|
||
\_=> First page handled by end_extent_writepage() in __extent_writepage()
The problem is caused by error handler of run_delalloc_range(), which
doesn't handle any created ordered extents, leaving them waiting on
btrfs_finish_ordered_io() to finish.
However after run_delalloc_range() returns error, __extent_writepage()
won't submit bio, so btrfs_writepage_end_io_hook() won't be triggered
except the first page, and btrfs_finish_ordered_io() won't be triggered
for created ordered extents either.
So OE 2~n will hang forever, and if OE 1 is larger than one page, it
will also hang.
[FIX]
Introduce btrfs_cleanup_ordered_extents() function to cleanup created
ordered extents and finish them manually.
The function is based on existing
btrfs_endio_direct_write_update_ordered() function, and modify it to
act just like btrfs_writepage_endio_hook() but handles specified range
other than one page.
After fix, delalloc error will be handled like:
|<------------------ delalloc range --------------------------->|
| OE 1 | OE 2 | ... | OE n |
|<>|<-------- ----------->|<------ old error handler --------->|
|| ||
|| \_=> Cleaned up by cleanup_ordered_extents()
\_=> First page handled by end_extent_writepage() in __extent_writepage()
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
|
|
[BUG]
When btrfs_reloc_clone_csum() reports error, it can underflow metadata
and leads to kernel assertion on outstanding extents in
run_delalloc_nocow() and cow_file_range().
BTRFS info (device vdb5): relocating block group 12582912 flags data
BTRFS info (device vdb5): found 1 extents
assertion failed: inode->outstanding_extents >= num_extents, file: fs/btrfs//extent-tree.c, line: 5858
Currently, due to another bug blocking ordered extents, the bug is only
reproducible under certain block group layout and using error injection.
a) Create one data block group with one 4K extent in it.
To avoid the bug that hangs btrfs due to ordered extent which never
finishes
b) Make btrfs_reloc_clone_csum() always fail
c) Relocate that block group
[CAUSE]
run_delalloc_nocow() and cow_file_range() handles error from
btrfs_reloc_clone_csum() wrongly:
(The ascii chart shows a more generic case of this bug other than the
bug mentioned above)
|<------------------ delalloc range --------------------------->|
| OE 1 | OE 2 | ... | OE n |
|<----------- cleanup range --------------->|
|<----------- ----------->|
\/
btrfs_finish_ordered_io() range
So error handler, which calls extent_clear_unlock_delalloc() with
EXTENT_DELALLOC and EXTENT_DO_ACCOUNT bits, and btrfs_finish_ordered_io()
will both cover OE n, and free its metadata, causing metadata under flow.
[Fix]
The fix is to ensure after calling btrfs_add_ordered_extent(), we only
call error handler after increasing the iteration offset, so that
cleanup range won't cover any created ordered extent.
|<------------------ delalloc range --------------------------->|
| OE 1 | OE 2 | ... | OE n |
|<----------- ----------->|<---------- cleanup range --------->|
\/
btrfs_finish_ordered_io() range
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
|
|
spi-next
|
|
'spi/topic/sunxi', 'spi/topic/tegra' and 'spi/topic/test' into spi-next
|
|
'spi/topic/omap2-mcspi', 'spi/topic/orion', 'spi/topic/pl022' and 'spi/topic/sc18is602' into spi-next
|
|
'spi/topic/fsl-dspi', 'spi/topic/imx' and 'spi/topic/lantiq' into spi-next
|
|
'spi/topic/cadence' and 'spi/topic/davinci' into spi-next
|
|
|
|
'spi/fix/pl022' into spi-linus
|
|
For automatic module loading (e.g. as it is used with cryptsetup)
an alias "paes" for the paes_s390 kernel module is needed.
Correct the paes_s390 module alias from "aes-all" to "paes".
Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
|
Kabylake platform expects modules in a library manifest. After loading
base firmware library manifest is loaded using load library IPC. This is
followed by module load using load multiple modules IPC.
Signed-off-by: Sodhi, VunnyX <vunnyx.sodhi@intel.com>
Signed-off-by: G Kranthi <gudishax.kranthikumar@intel.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Kabylake uses code loader dma and wait on notification instead of ipc
reply for load library ipc status. So modify the argument of
skl_sst_ipc_load_library to check on flag to wait for ipc reply.
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
For audio kabylake is same as skylake except the module load approach.
This patch registers different dsp_fw_ops for kabylake and next patch
adds the module load support for kabylake.
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Kabylake also uses code loader dma for module load and library load.
skl_transfer_module can be reused. Modify the arguments to include
library index to be passed to lib load ipc and module/lib check to use
correct ipc for lib/module load.
Signed-off-by: G Kranthi <gudishax.kranthikumar@intel.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
request firmware, strip extended manifest and release library changes
are common to kabylake and APL.
So move these common code to utils to be reused in later patches for
kabylake library load.
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Some skl sst context are not dependent of platform and initializing them
independently for each platform can lead to errors. So optimize by
moving them to a helper function and platform specific init code can
call this.
Signed-off-by: G Kranthi <gudishax.kranthikumar@intel.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add driver for NAU88L24.
Signed-off-by: John Hsu <KCHSU0@nuvoton.com>
Signed-off-by: John Hsu <supercraig0719@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Remove .owner field if calls are used which set it automatically.
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
This adds support for using GPIOs for chipselects as described by the
default dt-bindings.
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The caller only looks at the scsi_request result field anyway.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
ide_pm_execute_rq exectures a PM request synchronously, and in the failure
case where it calls __blk_end_request_all it never checks the error field
passed to the end_io callback, so don't bother setting it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
The SAS transport queues are only used by bsg, and bsg always looks at
the scsi_request results and never add the error passed in the end_io
callback.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
Although we do check the completion-status of the request before
actually adding a wait on it (either to its submit fence or its
completion dma-fence), we currently do not check before adding it to the
dependency lists.
In fact, without checking for a completed request we may try to use the
signaler after it has been retired and its dependency tree freed:
[ 60.044057] BUG: KASAN: use-after-free in __list_add_valid+0x1d/0xd0 at addr ffff880348c9e6a0
[ 60.044118] Read of size 8 by task gem_exec_fence/530
[ 60.044164] CPU: 1 PID: 530 Comm: gem_exec_fence Tainted: G E 4.11.0-rc7+ #46
[ 60.044226] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2
[ 60.044290] Call Trace:
[ 60.044337] dump_stack+0x4d/0x6a
[ 60.044383] kasan_object_err+0x21/0x70
[ 60.044435] kasan_report+0x225/0x4e0
[ 60.044488] ? __list_add_valid+0x1d/0xd0
[ 60.044534] ? kasan_kmalloc+0xad/0xe0
[ 60.044587] __asan_load8+0x5e/0x70
[ 60.044639] __list_add_valid+0x1d/0xd0
[ 60.044788] __i915_priotree_add_dependency+0x67/0x130 [i915]
[ 60.044895] i915_gem_request_await_request+0xa8/0x370 [i915]
[ 60.044974] i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[ 60.045049] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[ 60.045077] ? save_stack+0xb1/0xd0
[ 60.045105] ? save_stack_trace+0x1b/0x20
[ 60.045132] ? save_stack+0x46/0xd0
[ 60.045158] ? kasan_kmalloc+0xad/0xe0
[ 60.045184] ? __kmalloc+0xd8/0x670
[ 60.045229] ? drm_ioctl+0x359/0x640 [drm]
[ 60.045256] ? SyS_ioctl+0x41/0x70
[ 60.045330] ? i915_vma_move_to_active+0x540/0x540 [i915]
[ 60.045360] ? tty_insert_flip_string_flags+0xa1/0xf0
[ 60.045387] ? tty_flip_buffer_push+0x63/0x70
[ 60.045414] ? remove_wait_queue+0xa9/0xc0
[ 60.045441] ? kasan_unpoison_shadow+0x35/0x50
[ 60.045467] ? kasan_kmalloc+0xad/0xe0
[ 60.045494] ? kasan_check_write+0x14/0x20
[ 60.045568] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.045616] drm_ioctl+0x359/0x640 [drm]
[ 60.045705] ? i915_gem_execbuffer+0x5a0/0x5a0 [i915]
[ 60.045751] ? drm_version+0x150/0x150 [drm]
[ 60.045778] ? compat_start_thread+0x60/0x60
[ 60.045805] ? plist_del+0xda/0x1a0
[ 60.045833] do_vfs_ioctl+0x12e/0x910
[ 60.045860] ? ioctl_preallocate+0x130/0x130
[ 60.045886] ? pci_mmcfg_check_reserved+0xc0/0xc0
[ 60.045913] ? vfs_write+0x196/0x240
[ 60.045939] ? __fget_light+0xa7/0xc0
[ 60.045965] SyS_ioctl+0x41/0x70
[ 60.045991] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.046017] RIP: 0033:0x7feb2baefc47
[ 60.046042] RSP: 002b:00007fff56d28e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 60.046075] RAX: ffffffffffffffda RBX: 00007fff56d290a8 RCX: 00007feb2baefc47
[ 60.046102] RDX: 00007fff56d29050 RSI: 00000000c0406469 RDI: 0000000000000003
[ 60.046129] RBP: 00007fff56d29050 R08: 000055ecc4cd27d0 R09: 00007feb2bda8600
[ 60.046154] R10: 0000000000000073 R11: 0000000000000246 R12: 00000000c0406469
[ 60.046177] R13: 0000000000000003 R14: 000000000000000f R15: 0000000000000099
[ 60.046203] Object at ffff880348c9e680, in cache i915_dependency size: 64
[ 60.046225] Allocated:
[ 60.046246] PID = 530
[ 60.046269] save_stack_trace+0x1b/0x20
[ 60.046292] save_stack+0x46/0xd0
[ 60.046318] kasan_kmalloc+0xad/0xe0
[ 60.046343] kasan_slab_alloc+0x12/0x20
[ 60.046368] kmem_cache_alloc+0xab/0x650
[ 60.046445] i915_gem_request_await_request+0x88/0x370 [i915]
[ 60.046559] i915_gem_request_await_dma_fence+0x129/0x140 [i915]
[ 60.046705] i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
[ 60.046849] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.046936] drm_ioctl+0x359/0x640 [drm]
[ 60.046987] do_vfs_ioctl+0x12e/0x910
[ 60.047038] SyS_ioctl+0x41/0x70
[ 60.047090] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.047139] Freed:
[ 60.047179] PID = 530
[ 60.047223] save_stack_trace+0x1b/0x20
[ 60.047269] save_stack+0x46/0xd0
[ 60.047317] kasan_slab_free+0x72/0xc0
[ 60.047366] kmem_cache_free+0x39/0x160
[ 60.047512] i915_gem_request_retire+0x83f/0x930 [i915]
[ 60.047657] i915_gem_request_alloc+0x166/0x600 [i915]
[ 60.047799] i915_gem_do_execbuffer.isra.37+0xad8/0x26b0 [i915]
[ 60.047897] i915_gem_execbuffer2+0xdb/0x2a0 [i915]
[ 60.047942] drm_ioctl+0x359/0x640 [drm]
[ 60.047968] do_vfs_ioctl+0x12e/0x910
[ 60.047993] SyS_ioctl+0x41/0x70
[ 60.048019] entry_SYSCALL_64_fastpath+0x17/0x98
[ 60.048044] Memory state around the buggy address:
[ 60.048066] ffff880348c9e580: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048105] ffff880348c9e600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048138] >ffff880348c9e680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[ 60.048170] ^
[ 60.048191] ffff880348c9e700: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[ 60.048225] ffff880348c9e780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
Note to hit the use-after-free requires us to be passed back a request
via a fence-array, that is from explicit fencing accumulated into a
sync-file fence-array.
Fixes: 52e542090701 ("drm/i915/scheduler: Record all dependencies upon request construction")
Testcase: igt/gem_exec_fence/expired-history
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170422081537.6468-1-chris@chris-wilson.co.uk
(cherry picked from commit ade0b0c965f59176daddbef9c4717354034f9bce)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The busy-spin, as the first stage of intel_wait_for_register(), is
currently under suspicion for causing:
[ 62.034926] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
[ 62.034928] Modules linked in: i2c_dev i915 intel_gtt drm_kms_helper prime_numbers
[ 62.034932] CPU: 1 PID: 183 Comm: kworker/1:2 Not tainted 4.11.0-rc7+ #471
[ 62.034933] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[ 62.034934] Workqueue: pm pm_runtime_work
[ 62.034936] task: ffff880275a04ec0 task.stack: ffffc900002d8000
[ 62.034936] RIP: 0010:__intel_wait_for_register_fw+0x77/0x1a0 [i915]
[ 62.034937] RSP: 0018:ffffc900002dbc38 EFLAGS: 00000082
[ 62.034939] RAX: ffffc90003530094 RBX: 0000000000130094 RCX: 0000000000000001
[ 62.034940] RDX: 00000000000000a1 RSI: ffff88027fd15e58 RDI: 0000000000000000
[ 62.034941] RBP: ffffc900002dbc78 R08: 0000000000000002 R09: 0000000000000000
[ 62.034942] R10: ffffc900002dbc18 R11: ffff880276429dd0 R12: ffff8802707c0000
[ 62.034943] R13: 00000000000000a0 R14: 0000000000000000 R15: 00000000fffefc10
[ 62.034945] FS: 0000000000000000(0000) GS:ffff88027fd00000(0000) knlGS:0000000000000000
[ 62.034945] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 62.034947] CR2: 00007ffd3cd98ff8 CR3: 0000000274c19000 CR4: 00000000001006e0
[ 62.034947] Call Trace:
[ 62.034948] intel_wait_for_register+0x77/0x140 [i915]
[ 62.034949] vlv_suspend_complete+0x23/0x5b0 [i915]
[ 62.034950] intel_runtime_suspend+0x16c/0x2a0 [i915]
[ 62.034950] pci_pm_runtime_suspend+0x50/0x180
[ 62.034951] ? pci_pm_runtime_resume+0xa0/0xa0
[ 62.034952] __rpm_callback+0xc5/0x210
[ 62.034953] rpm_callback+0x1f/0x80
[ 62.034953] ? pci_pm_runtime_resume+0xa0/0xa0
[ 62.034954] rpm_suspend+0x118/0x580
[ 62.034955] pm_runtime_work+0x64/0x90
[ 62.034956] process_one_work+0x1bb/0x3e0
[ 62.034956] worker_thread+0x46/0x4f0
[ 62.034957] ? __schedule+0x18b/0x610
[ 62.034958] kthread+0xff/0x140
[ 62.034958] ? process_one_work+0x3e0/0x3e0
[ 62.034959] ? kthread_create_on_node+
and related hard lockups in CI for byt and bsw.
Note this effectively reverts commits 41ce405e6894 and b27366958869
("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
v2: Convert bool allow into a u32 mask for clarity and repeat the
comment on vlv rc6 timing to justify the 3ms timeout used for the wait (Ville)
Fixes: 41ce405e6894 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
Fixes: b27366958869 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100718
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170421135815.11897-1-chris@chris-wilson.co.uk
Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
(cherry picked from commit 3dd14c04d77d7d702de5aa7157df4cc9417329f3)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Avoid having too large a stack by creating the fake struct inode/file on
the heap instead.
drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file':
drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file_free':
drivers/gpu/drm/i915/selftests/mock_drm.c:54:1: error: the frame size of 1312 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
Reported-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 66d9cb5d805a ("drm/i915: Mock the GEM device for self-testing")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170419094143.16922-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 2310b3c952c5dc56c2e08f71b907b8e23ab3270d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
