17 Feb, 2018
33 commits
-
commit fa59b92d299f2787e6bae1ff078ee0982e80211f upstream.
When the mcryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the mcryptd instance. This change
is necessary for mcryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 841a3ff329713f796a63356fef6e2f72e4a3f6a3 upstream.
When the cryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the cryptd instance. This change
is necessary for cryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba upstream.
Templates that use an shash spawn can use crypto_shash_alg_has_setkey()
to determine whether the underlying algorithm requires a key or not.
But there was no corresponding function for ahash spawns. Add it.Note that the new function actually has to support both shash and ahash
algorithms, since the ahash API can be used with either.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit f919dde0772a894c693a1eeabc77df69d6a9b937 upstream.
Add Intel Cannon Lake PCH-H PCI ID to the list of supported controllers.
Signed-off-by: Mika Westerberg
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 998008b779e424bd7513c434d0ab9c1268459009 upstream.
Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
SATA controllers. This commit is a preparation patch for allowing a
different default sata link powermanagement policy for mobile chipsets.Signed-off-by: Hans de Goede
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit ca1b4974bd237f2373b0e980b11957aac3499b56 upstream.
Intel uses different SATA PCI ids for the Desktop and Mobile SKUs of their
chipsets. For older models the comment describing which chipset the PCI id
is for, aksi indicates when we're dealing with a mobile SKU. Extend the
comments for recent chipsets to also indicate mobile SKUs.The information this commit adds comes from Intel's chipset datasheets.
This commit is a preparation patch for allowing a different default
sata link powermanagement policy for mobile chipsets.Signed-off-by: Hans de Goede
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit ba87977a49913129962af8ac35b0e13e0fa4382d upstream.
Commit b7ce40cff0b9 ("kernfs: cache atomic_write_len in
kernfs_open_file") changes type of local variable 'len' from ssize_t
to size_t. This change caused that the *ppos value is updated also
when the previous write callback failed.Mentioned snippet:
...
len = ops->write(...); 0)
Signed-off-by: Ivan Vecera
Signed-off-by: Al Viro
Signed-off-by: Greg Kroah-Hartman -
commit e231c6879cfd44e4fffd384bb6dd7d313249a523 upstream.
When locking the file in order to do O_DIRECT on it, we must unmap
any mmapped ranges on the pagecache so that we can flush out the
dirty data.Fixes: a5864c999de67 ("NFS: Do not serialise O_DIRECT reads and writes")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 49686cbbb3ebafe42e63868222f269d8053ead00 upstream.
nfs_idmap_legacy_upcall() is supposed to be called with 'aux' pointing
to a 'struct idmap', via the call to request_key_with_auxdata() in
nfs_idmap_request_key().However it can also be reached via the request_key() system call in
which case 'aux' will be NULL, causing a NULL pointer dereference in
nfs_idmap_prepare_pipe_upcall(), assuming that the key description is
valid enough to get that far.Fix this by making nfs_idmap_legacy_upcall() negate the key if no
auxdata is provided.As usual, this bug was found by syzkaller. A simple reproducer using
the command-line keyctl program is:keyctl request2 id_legacy uid:0 '' @s
Fixes: 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring")
Reported-by: syzbot+5dfdbcf7b3eb5912abbb@syzkaller.appspotmail.com
Signed-off-by: Eric Biggers
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 1b8d97b0a837beaf48a8449955b52c650a7114b4 upstream.
If some of the WRITE calls making up an O_DIRECT write syscall fail,
we neglect to commit, even if some of the WRITEs succeed.We also depend on the commit code to free the reference count on the
nfs_page taken in the "if (request_commit)" case at the end of
nfs_direct_write_completion(). The problem was originally noticed
because ENOSPC's encountered partway through a write would result in a
closed file being sillyrenamed when it should have been unlinked.Signed-off-by: J. Bruce Fields
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 7f1bda447c9bd48b415acedba6b830f61591601f upstream.
The commit list can get very large, and so we need a cond_resched()
in nfs_commit_release_pages() in order to ensure we don't hog the CPU
for excessive periods of time.Reported-by: Mike Galbraith
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit ba4a76f703ab7eb72941fdaac848502073d6e9ee upstream.
Currently when falling back to doing I/O through the MDS (via
pnfs_{read|write}_through_mds), the client frees the nfs_pgio_header
without releasing the reference taken on the dreq
via pnfs_generic_pg_{read|write}pages -> nfs_pgheader_init ->
nfs_direct_pgio_init. It then takes another reference on the dreq via
nfs_generic_pg_pgios -> nfs_pgheader_init -> nfs_direct_pgio_init and
as a result the requester will become stuck in inode_dio_wait. Once
that happens, other processes accessing the inode will become stuck as
well.Ensure that pnfs_read_through_mds() and pnfs_write_through_mds() clean
up correctly by calling hdr->completion_ops->completion() instead of
calling hdr->release() directly.This can be reproduced (sometimes) by performing "storage failover
takeover" commands on NetApp filer while doing direct I/O from a client.This can also be reproduced using SystemTap to simulate a failure while
doing direct I/O from a client (from Dave Wysochanski
):stap -v -g -e 'probe module("nfs_layout_nfsv41_files").function("nfs4_fl_prepare_ds").return { $return=NULL; exit(); }'
Suggested-by: Trond Myklebust
Signed-off-by: Scott Mayhew
Fixes: 1ca018d28d ("pNFS: Fix a memory leak when attempted pnfs fails")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit d8db5b1ca9d4c57e49893d0f78e6d5ce81450cc8 upstream.
The inode is not locked in init_xattrs when creating a new inode.
Without this patch, there will occurs assert when booting or creating
a new file, if the kernel config CONFIG_SECURITY_SMACK is enabled.Log likes:
UBIFS assert failed in ubifs_xattr_set at 298 (pid 1156)
CPU: 1 PID: 1156 Comm: ldconfig Tainted: G S 4.12.0-rc1-207440-g1e70b02 #2
Hardware name: MediaTek MT2712 evaluation board (DT)
Call trace:
[] dump_backtrace+0x0/0x238
[] show_stack+0x14/0x20
[] dump_stack+0x9c/0xc0
[] ubifs_xattr_set+0x374/0x5e0
[] init_xattrs+0x5c/0xb8
[] security_inode_init_security+0x110/0x190
[] ubifs_init_security+0x30/0x68
[] ubifs_mkdir+0x100/0x200
[] vfs_mkdir+0x11c/0x1b8
[] SyS_mkdirat+0x74/0xd0
[] __sys_trace_return+0x0/0x4Signed-off-by: Xiaolei Li
Signed-off-by: Richard Weinberger
Cc: stable@vger.kernel.org
(julia: massaged to apply to 4.9.y, which doesn't contain fscrypto support)
Signed-off-by: Julia Cartwright
Signed-off-by: Greg Kroah-Hartman -
commit 7f29ae9f977bcdc3654e68bc36d170223c52fd48 upstream.
This fixes a race with idr_alloc where gd->first_minor can be set to the
same value for two simultaneous calls to ubiblock_create. Each instance
calls device_add_disk with the same first_minor. device_add_disk calls
bdi_register_owner which generates several warnings.WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
sysfs_warn_dup+0x68/0x88
sysfs: cannot create duplicate filename '/devices/virtual/bdi/252:2'WARNING: CPU: 1 PID: 179 at kernel-source/lib/kobject.c:240
kobject_add_internal+0x1ec/0x2f8
kobject_add_internal failed for 252:2 with -EEXIST, don't try to
register things with the same name in the same directoryWARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
sysfs_warn_dup+0x68/0x88
sysfs: cannot create duplicate filename '/dev/block/252:2'However, device_add_disk does not error out when bdi_register_owner
returns an error. Control continues until reaching blk_register_queue.
It then BUGs.kernel BUG at kernel-source/fs/sysfs/group.c:113!
[] (internal_create_group) from []
(sysfs_create_group+0x20/0x24)
[] (sysfs_create_group) from []
(blk_trace_init_sysfs+0x18/0x20)
[] (blk_trace_init_sysfs) from []
(blk_register_queue+0xd8/0x154)
[] (blk_register_queue) from []
(device_add_disk+0x194/0x44c)
[] (device_add_disk) from []
(ubiblock_create+0x284/0x2e0)
[] (ubiblock_create) from []
(vol_cdev_ioctl+0x450/0x554)
[] (vol_cdev_ioctl) from [] (vfs_ioctl+0x30/0x44)
[] (vfs_ioctl) from [] (do_vfs_ioctl+0xa0/0x790)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x44/0x68)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x34)Locking idr_alloc/idr_remove removes the race and keeps gd->first_minor
unique.Fixes: 2bf50d42f3a4 ("UBI: block: Dynamically allocate minor numbers")
Signed-off-by: Bradley Bolen
Reviewed-by: Boris Brezillon
Signed-off-by: Richard Weinberger
Signed-off-by: Greg Kroah-Hartman -
commit f78e5623f45bab2b726eec29dc5cefbbab2d0b1c upstream.
The fastmap update code might erase the current fastmap anchor PEB
in case it doesn't find any new free PEB. When a power cut happens
in this situation we must not have any outdated fastmap anchor PEB
on the device, because that would be used to attach during next
boot.
The easiest way to make that sure is to erase all outdated fastmap
anchor PEBs synchronously during attach.Signed-off-by: Sascha Hauer
Reviewed-by: Richard Weinberger
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger
Signed-off-by: Greg Kroah-Hartman -
commit f4c6cd1a7f2275d5bc0e494b21fff26f8dde80f0 upstream.
When the requested ECC strength does not exactly match the strengths
supported by the ECC engine, the driver is selecting the closest
strength meeting the 'selected_strength > requested_strength'
constraint. Fix the fact that, in this particular case, ecc->strength
value was not updated to match the 'selected_strength'.For instance, one can encounter this issue when no ECC requirement is
filled in the device tree while the NAND chip minimum requirement is not
a strength/step_size combo natively supported by the ECC engine.Fixes: 1fef62c1423b ("mtd: nand: add sunxi NAND flash controller support")
Suggested-by: Boris Brezillon
Signed-off-by: Miquel Raynal
Signed-off-by: Boris Brezillon
Signed-off-by: Greg Kroah-Hartman -
commit 87e89ce8d0d14f573c068c61bec2117751fb5103 upstream.
Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in
OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a
negative error, and the MTD layer expected it.However, the trend for the NAND layer is now to return an error or a
positive number of bitflips. Deciding which status to return to the user
belongs to the MTD layer.Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
brought this logic to the mtd_read_oob() function while the return value
coming from nand_do_read_oob() (called by the ->_read_oob() hook) was
left unchanged.Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
Signed-off-by: Miquel Raynal
Signed-off-by: Boris Brezillon
Signed-off-by: Greg Kroah-Hartman -
commit f953f0f89663c39f08f4baaa8a4a881401b65654 upstream.
Brcm nand controller prefetch feature needs to be disabled
by default. Enabling affects performance on random reads as
well as dma reads.Signed-off-by: Kamal Dasu
Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
Acked-by: Florian Fainelli
Signed-off-by: Boris Brezillon
Signed-off-by: Greg Kroah-Hartman -
commit 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 upstream.
The map_word_() functions, dating back to linux-2.6.8, try to perform
bitwise operations on a 'map_word' structure. This may have worked
with compilers that were current then (gcc-3.4 or earlier), but end
up being rather inefficient on any version I could try now (gcc-4.4 or
higher). Specifically we hit a problem analyzed in gcc PR81715 where we
fail to reuse the stack space for local variables.This can be seen immediately in the stack consumption for
cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN)
can be up to 2200 bytes. Changing the inline functions into macros brings
this down to 1280 bytes. Without KASAN, the same problem exists, but
the stack consumption is lower to start with, my patch shrinks it from
920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around
1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word
structures for each call to one of these helpers.With the latest gcc-8 snapshot, the problem is fixed in upstream gcc,
but nobody uses that yet, so we should still work around it in mainline
kernels and probably backport the workaround to stable kernels as well.
We had a couple of other functions that suffered from the same gcc bug,
and all of those had a simpler workaround involving dummy variables
in the inline function. Unfortunately that did not work here, the
macro hack was the best I could come up with.It would also be helpful to have someone to a little performance testing
on the patch, to see how much it helps in terms of CPU utilitzation.Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann
Acked-by: Richard Weinberger
Signed-off-by: Boris Brezillon
Signed-off-by: Greg Kroah-Hartman -
commit c0f71bbb810237a38734607ca4599632f7f5d47f upstream.
Here, hdpvr_register_videodev() is responsible for setup and
register a video device. Also defining and initializing a worker.
hdpvr_register_videodev() is calling by hdpvr_probe at last.
So no need to flush any work here.
Unregister v4l2, free buffers and memory. If hdpvr_probe() will fail.Signed-off-by: Arvind Yadav
Reported-by: Andrey Konovalov
Tested-by: Andrey Konovalov
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Cc: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman -
commit 7bf7a7116ed313c601307f7e585419369926ab05 upstream.
When the tuner was split from m88rs2000 the attach function is in wrong
place.Move to dm04_lme2510_tuner to trap errors on failure and removing
a call to lme_coldreset.Prevents driver starting up without any tuner connected.
Fixes to trap for ts2020 fail.
LME2510(C): FE Found M88RS2000
ts2020: probe of 0-0060 failed with error -11
...
LME2510(C): TUN Found RS2000 tuner
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASANReported-by: Andrey Konovalov
Signed-off-by: Malcolm Priestley
Tested-by: Andrey Konovalov
Signed-off-by: Mauro Carvalho Chehab
Cc: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman -
commit 3d932ee27e852e4904647f15b64dedca51187ad7 upstream.
Warm start has no check as whether a genuine device has
connected and proceeds to next execution path.Check device should read 0x47 at offset of 2 on USB descriptor read
and it is the amount requested of 6 bytes.Fix for
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access asReported-by: Andrey Konovalov
Signed-off-by: Malcolm Priestley
Signed-off-by: Mauro Carvalho Chehab
Cc: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman -
commit 69c64866ce072dea1d1e59a0d61e0f66c0dffb76 upstream.
Whenever the sock object is in DCCP_CLOSED state,
dccp_disconnect() must free dccps_hc_tx_ccid and
dccps_hc_rx_ccid and set to NULL.Signed-off-by: Mohamed Ghannam
Reviewed-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 364f56653708ba8bcdefd4f0da2a42904baa8eeb upstream.
When issuing an IPI RT push, where an IPI is sent to each CPU that has more
than one RT task scheduled on it, it references the root domain's rto_mask,
that contains all the CPUs within the root domain that has more than one RT
task in the runable state. The problem is, after the IPIs are initiated, the
rq->lock is released. This means that the root domain that is associated to
the run queue could be freed while the IPIs are going around.Add a sched_get_rd() and a sched_put_rd() that will increment and decrement
the root domain's ref count respectively. This way when initiating the IPIs,
the scheduler will up the root domain's ref count before releasing the
rq->lock, ensuring that the root domain does not go away until the IPI round
is complete.Reported-by: Pavan Kondeti
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Peter Zijlstra (Intel)
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: 4bdced5c9a292 ("sched/rt: Simplify the IPI based RT balancing logic")
Link: http://lkml.kernel.org/r/CAEU1=PkiHO35Dzna8EQqNSKW1fr1y1zRQ5y66X117MG06sQtNA@mail.gmail.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit ad0f1d9d65938aec72a698116cd73a980916895e upstream.
When the rto_push_irq_work_func() is called, it looks at the RT overloaded
bitmask in the root domain via the runqueue (rq->rd). The problem is that
during CPU up and down, nothing here stops rq->rd from changing between
taking the rq->rd->rto_lock and releasing it. That means the lock that is
released is not the same lock that was taken.Instead of using this_rq()->rd to get the root domain, as the irq work is
part of the root domain, we can simply get the root domain from the irq work
that is passed to the routine:container_of(work, struct root_domain, rto_push_work)
This keeps the root domain consistent.
Reported-by: Pavan Kondeti
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Peter Zijlstra (Intel)
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: 4bdced5c9a292 ("sched/rt: Simplify the IPI based RT balancing logic")
Link: http://lkml.kernel.org/r/CAEU1=PkiHO35Dzna8EQqNSKW1fr1y1zRQ5y66X117MG06sQtNA@mail.gmail.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit c8cd751060b149997b9de53a494fb1490ded72c5 upstream.
Commit 76e0da34c7ce ("usb-gadget/uvc: use per-attribute show and store
methods") caused a stringification of an undefined macro argument "aname",
so three UVC parameters (streaming_interval, streaming_maxpacket and
streaming_maxburst) were named "aname".Add the definition of "aname" to the main macro and name the filenames as
originaly intended.Signed-off-by: Petr Cvek
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit cef31d9af908243421258f1df35a4a644604efbe upstream.
timer_create() specifies via sigevent->sigev_notify the signal delivery for
the new timer. The valid modes are SIGEV_NONE, SIGEV_SIGNAL, SIGEV_THREAD
and (SIGEV_SIGNAL | SIGEV_THREAD_ID).The sanity check in good_sigevent() is only checking the valid combination
for the SIGEV_THREAD_ID bit, i.e. SIGEV_SIGNAL, but if SIGEV_THREAD_ID is
not set it accepts any random value.This has no real effects on the posix timer and signal delivery code, but
it affects show_timer() which handles the output of /proc/$PID/timers. That
function uses a string array to pretty print sigev_notify. The access to
that array has no bound checks, so random sigev_notify cause access beyond
the array bounds.Add proper checks for the valid notify modes and remove the SIGEV_THREAD_ID
masking from various code pathes as SIGEV_NONE can never be set in
combination with SIGEV_THREAD_ID.Reported-by: Eric Biggers
Reported-by: Dmitry Vyukov
Reported-by: Alexey Dobriyan
Signed-off-by: Thomas Gleixner
Cc: John Stultz
Signed-off-by: Greg Kroah-Hartman -
Tobias noticed a compile error on 4.4.115, and it's the same on 4.9.80:
arch/x86/mm/kaiser.c: In function ‘kaiser_init’:
arch/x86/mm/kaiser.c:348:8: error: ‘vsyscall_pgprot’ undeclared
(first use in this function)It seems like his combination of kernel options doesn't work for KAISER.
X86_VSYSCALL_EMULATION is not set on his system, while LEGACY_VSYSCALL
is set to NONE (LEGACY_VSYSCALL_NONE=y). He managed to get things
compiling again, by moving the 'extern unsigned long vsyscall_pgprot'
outside of the preprocessor statement. This works because the optimizer
removes that code (vsyscall_enabled() is always false) - and that's how
it was done in some older backports.Reported-by: Tobias Jakobi
Signed-off-by: Hugh Dickins
Signed-off-by: Greg Kroah-Hartman -
commit 66b3bd2356e0a1531c71a3dcf96944621e25c17c upstream.
The type of arg passed to dmatest_callback is struct dmatest_done.
It refers to test_done in struct dmatest_thread, not done_wait.Fixes: 6f6a23a213be ("dmaengine: dmatest: move callback wait ...")
Signed-off-by: Yang Shunyong
Acked-by: Adam Wallis
Signed-off-by: Vinod Koul
Signed-off-by: Greg Kroah-Hartman -
commit 97f4b7276b829a8927ac903a119bef2f963ccc58 upstream.
also replaces memset()+kfree() by kzfree().
Signed-off-by: Aurelien Aptel
Signed-off-by: Steve French
Reviewed-by: Pavel Shilovsky
Signed-off-by: Greg Kroah-Hartman -
commit 9aca7e454415f7878b28524e76bebe1170911a88 upstream.
Autonegotiation gives a security settings mismatch error if the SMB
server selects an SMBv3 dialect that isn't SMB3.02. The exact error is
"protocol revalidation - security settings mismatch".
This can be tested using Samba v4.2 or by setting the global Samba
setting max protocol = SMB3_00.The check that fails in smb3_validate_negotiate is the dialect
verification of the negotiate info response. This is because it tries
to verify against the protocol_id in the global smbdefault_values. The
protocol_id in smbdefault_values is SMB3.02.
In SMB2_negotiate the protocol_id in smbdefault_values isn't updated,
it is global so it probably shouldn't be, but server->dialect is.This patch changes the check in smb3_validate_negotiate to use
server->dialect instead of server->vals->protocol_id. The patch works
with autonegotiate and when using a specific version in the vers mount
option.Signed-off-by: Daniel N Pettersson
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit f04a703c3d613845ae3141bfaf223489de8ab3eb upstream.
If cifs_zap_mapping() returned an error, we would return without putting
the xid that we got earlier. Restructure cifs_file_strict_mmap() and
cifs_file_mmap() to be more similar to each other and have a single
point of return that always puts the xid.Signed-off-by: Matthew Wilcox
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 1b689a95ce7427075f9ac9fb4aea1af530742b7f upstream.
Commit 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush
settings") uses u64 in asm/hvcall.h without including linux/types.hThis breaks hvcall.h users that do not include the header themselves.
Fixes: 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush settings")
Signed-off-by: Michal Suchanek
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
13 Feb, 2018
7 commits
-
commit 1f161f67a272cc4f29f27934dd3f74cb657eb5c4 upstream with adjustments.
On CPUs like AMD's Geode, for example, we shouldn't even try to load
microcode because they do not support the modern microcode loading
interface.However, we do the family check *after* the other checks whether the
loader has been disabled on the command line or whether we're running in
a guest.So move the family checks first in order to exit early if we're being
loaded on an unsupported family.Reported-and-tested-by: Sven Glodowski
Signed-off-by: Borislav Petkov
Cc: # 4.11..
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://bugzilla.suse.com/show_bug.cgi?id=1061396
Link: http://lkml.kernel.org/r/20171012112316.977-1-bp@alien8.de
Signed-off-by: Ingo Molnar
Signed-off-by: Rolf Neugebauer
Signed-off-by: Greg Kroah-Hartman -
commit 641307df71fe77d7b38a477067495ede05d47295 upstream.
When stopping the CRTC the driver must disable all planes and wait for
the change to take effect at the next vblank. Merely calling
drm_crtc_wait_one_vblank() is not enough, as the function doesn't
include any mechanism to handle the race with vblank interrupts.Replace the drm_crtc_wait_one_vblank() call with a manual mechanism that
handles the vblank interrupt race.Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: thongsyho
Signed-off-by: Nhan Nguyen
Signed-off-by: Greg Kroah-Hartman -
commit cbbb90b0c084d7dfb2ed8e3fecf8df200fbdd2a0 upstream.
When implementing support for interlaced modes, the driver switched from
reporting vblank events on the vertical blanking (VBK) interrupt to the
frame end interrupt (FRM). This incorrectly divided the reported refresh
rate by two. Fix it by moving back to the VBK interrupt.Fixes: 906eff7fcada ("drm: rcar-du: Implement support for interlaced modes")
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: thongsyho
Signed-off-by: Nhan Nguyen
Signed-off-by: Greg Kroah-Hartman -
commit e0936c3471a8411a5df327641fa3ffe12a2fb07b upstream.
commit 1f8754d4daea5f ("ASoC: rsnd: don't call free_irq() on
Parent SSI") fixed Parent SSI duplicate free_irq().
But on Renesas Sound, not only Parent SSI but also Multi SSI
have same issue.
This patch avoid duplicate free_irq() if it was not pure SSI.Fixes: 1f8754d4daea5f ("ASoC: rsnd: don't call free_irq() on Parent SSI")
Signed-off-by: Kuninori Morimoto
Signed-off-by: Mark Brown
Signed-off-by: thongsyho
Signed-off-by: Nhan Nguyen
Signed-off-by: Greg Kroah-Hartman -
commit 1f8754d4daea5f257370a52a30fcb22798c54516 upstream.
If SSI uses shared pin, some SSI will be used as parent SSI.
Then, normal SSI's remove and Parent SSI's remove
(these are same SSI) will be called when unbind or remove timing.
In this case, free_irq() will be called twice.
This patch solve this issue.Signed-off-by: Kuninori Morimoto
Tested-by: Hiroyuki Yokoyama
Reported-by: Hiroyuki Yokoyama
Signed-off-by: Mark Brown
Signed-off-by: thongsyho
Signed-off-by: Nhan Nguyen
Signed-off-by: Greg Kroah-Hartman -
commit 7ac45d1635a4cd2e99a4b11903d4a2815ca1b27b upstream.
In case cpu could not be found the error message would always refer to
/codec/ not being found in DT. Fix this by catching the cpu node not found
case explicitly.Signed-off-by: Julian Scheel
Signed-off-by: Mark Brown
Signed-off-by: thongsyho
Signed-off-by: Nhan Nguyen
Signed-off-by: Greg Kroah-Hartman
