aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-01-10net: skb_flow_get_be16() can be staticEric Dumazet1-2/+2
Removes following sparse complain : net/core/flow_dissector.c:70:8: warning: symbol 'skb_flow_get_be16' was not declared. Should it be static? Fixes: 972d3876faa8 ("flow dissector: ICMP support") Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-01-10ibmvscsis: Fix srp_transfer_data fail return codeBryant G. Ly1-1/+1
If srp_transfer_data fails within ibmvscsis_write_pending, then the most likely scenario is that the client timed out the op and removed the TCE mapping. Thus it will loop forever retrying the op that is pretty much guaranteed to fail forever. A better return code would be EIO instead of EAGAIN. Cc: [email protected] Reported-by: Steven Royer <[email protected]> Tested-by: Steven Royer <[email protected]> Signed-off-by: Bryant G. Ly <[email protected]> Signed-off-by: Bart Van Assche <[email protected]>
2017-01-10usb: musb: fix runtime PM in debugfsBin Liu1-1/+19
MUSB driver now has runtime PM support, but the debugfs driver misses the PM _get/_put() calls, which could cause MUSB register access failure. Cc: [email protected] # 4.9+ Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Bin Liu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-01-10Merge branch 'r8152-fix-autosuspend'David S. Miller1-16/+64
Hayes Wang says: ==================== r8152: fix autosuspend issue Avoid rx is split into two parts when runtime suspend occurs. ==================== Signed-off-by: David S. Miller <[email protected]>
2017-01-10r8152: fix rx issue for runtime suspendhayeswang1-3/+28
Pause the rx and make sure the rx fifo is empty when the autosuspend occurs. If the rx data comes when the driver is canceling the rx urb, the host controller would stop getting the data from the device and continue it after next rx urb is submitted. That is, one continuing data is split into two different urb buffers. That let the driver take the data as a rx descriptor, and unexpected behavior happens. Signed-off-by: Hayes Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-01-10r8152: split rtl8152_suspend functionhayeswang1-17/+40
Split rtl8152_suspend() into rtl8152_system_suspend() and rtl8152_rumtime_suspend(). Signed-off-by: Hayes Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-01-10target: support XCOPY requests without parametersDavid Disseldorp1-0/+4
SPC4r37 6.4.1 EXTENDED COPY(LID4) states (also applying to LID1 reqs): A parameter list length of zero specifies that the copy manager shall not transfer any data or alter any internal state, and this shall not be considered an error. This behaviour can be tested using the libiscsi ExtendedCopy.ParamHdr test. Signed-off-by: David Disseldorp <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Bart Van Assche <[email protected]>
2017-01-10target: check for XCOPY parameter truncationDavid Disseldorp2-0/+15
Check for XCOPY header, CSCD descriptor and segment descriptor list truncation, and respond accordingly. SPC4r37 6.4.1 EXTENDED COPY(LID4) states (also applying to LID1 reqs): If the parameter list length causes truncation of the parameter list, then the copy manager shall transfer no data and shall terminate the EXTENDED COPY command with CHECK CONDITION status, with the sense key set to ILLEGAL REQUEST, and the additional sense code set to PARAMETER LIST LENGTH ERROR. This behaviour can be tested using the libiscsi ExtendedCopy.ParamHdr test. Signed-off-by: David Disseldorp <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Bart Van Assche <[email protected]>
2017-01-10target: use XCOPY segment descriptor CSCD IDsDavid Disseldorp1-31/+48
The XCOPY specification in SPC4r37 states that the XCOPY source and destination device(s) should be derived from the copy source and copy destination (CSCD) descriptor IDs in the XCOPY segment descriptor. The CSCD IDs are generally (for block -> block copies), indexes into the corresponding CSCD descriptor list, e.g. ================================= EXTENDED COPY Header ================================= CSCD Descriptor List - entry 0 + LU ID <--------------<------------------\ - entry 1 | + LU ID <______________<_____________ | ================================= | | Segment Descriptor List | | - segment 0 | | + src CSCD ID = 0 --------->---------+----/ + dest CSCD ID = 1 ___________>______| + len + src lba + dest lba ================================= Currently LIO completely ignores the src and dest CSCD IDs in the Segment Descriptor List, and instead assumes that the first entry in the CSCD list corresponds to the source, and the second to the destination. This commit removes this assumption, by ensuring that the Segment Descriptor List is parsed prior to processing the CSCD Descriptor List. CSCD Descriptor List processing is modified to compare the current list index with the previously obtained src and dest CSCD IDs. Additionally, XCOPY requests where the src and dest CSCD IDs refer to the CSCD Descriptor List entry can now be successfully processed. Fixes: cbf031f ("target: Add support for EXTENDED_COPY copy offload") Link: https://bugzilla.kernel.org/show_bug.cgi?id=191381 Signed-off-by: David Disseldorp <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Bart Van Assche <[email protected]>
2017-01-10target: check XCOPY segment descriptor CSCD IDsDavid Disseldorp2-0/+14
Ensure that the segment descriptor CSCD descriptor ID values correspond to CSCD descriptor entries located in the XCOPY command parameter list. SPC4r37 6.4.6.1 Table 150 specifies this range as 0000h to 07FFh, where the CSCD descriptor location in the parameter list can be located via: 16 + (id * 32) Signed-off-by: David Disseldorp <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> [ bvanassche: inserted "; " in the format string of an error message and also moved a "||" operator from the start of a line to the end of the previous line ] Signed-off-by: Bart Van Assche <[email protected]>
2017-01-10target: simplify XCOPY wwn->se_dev lookup helperDavid Disseldorp1-19/+9
target_xcopy_locate_se_dev_e4() is used to locate an se_dev, based on the WWN provided with the XCOPY request. Remove a couple of unneeded arguments, and rely on the caller for the src/dst test. Signed-off-by: David Disseldorp <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Bart Van Assche <[email protected]>
2017-01-10target: return UNSUPPORTED TARGET/SEGMENT DESC TYPE CODE senseDavid Disseldorp1-0/+4
Use UNSUPPORTED TARGET DESCRIPTOR TYPE CODE and UNSUPPORTED SEGMENT DESCRIPTOR TYPE CODE additional sense codes if a descriptor type in an XCOPY request is not supported, as specified in spc4r37 6.4.5 and 6.4.6. Signed-off-by: David Disseldorp <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Bart Van Assche <[email protected]>
2017-01-10target: bounds check XCOPY total descriptor list lengthDavid Disseldorp1-0/+6
spc4r37 6.4.3.5 states: If the combined length of the CSCD descriptors and segment descriptors exceeds the allowed value, then the copy manager shall terminate the command with CHECK CONDITION status, with the sense key set to ILLEGAL REQUEST, and the additional sense code set to PARAMETER LIST LENGTH ERROR. This functionality can be tested using the libiscsi ExtendedCopy.DescrLimits test. Signed-off-by: David Disseldorp <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Bart Van Assche <[email protected]>
2017-01-10target: bounds check XCOPY segment descriptor listDavid Disseldorp1-2/+12
Check the length of the XCOPY request segment descriptor list against the value advertised via the MAXIMUM SEGMENT DESCRIPTOR COUNT field in the RECEIVE COPY OPERATING PARAMETERS response. spc4r37 6.4.3.5 states: If the number of segment descriptors exceeds the allowed number, the copy manager shall terminate the command with CHECK CONDITION status, with the sense key set to ILLEGAL REQUEST, and the additional sense code set to TOO MANY SEGMENT DESCRIPTORS. This functionality is testable using the libiscsi ExtendedCopy.DescrLimits test. Signed-off-by: David Disseldorp <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Bart Van Assche <[email protected]>
2017-01-10target: use XCOPY TOO MANY TARGET DESCRIPTORS senseDavid Disseldorp1-1/+3
spc4r37 6.4.3.4 states: If the number of CSCD descriptors exceeds the allowed number, the copy manager shall terminate the command with CHECK CONDITION status, with the sense key set to ILLEGAL REQUEST, and the additional sense code set to TOO MANY TARGET DESCRIPTORS. LIO currently responds with INVALID FIELD IN PARAMETER LIST, which sees it fail the libiscsi ExtendedCopy.DescrLimits test. Signed-off-by: David Disseldorp <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Bart Van Assche <[email protected]>
2017-01-10target: add XCOPY target/segment desc sense codesDavid Disseldorp2-0/+28
As defined in http://www.t10.org/lists/asc-num.htm. To be used during validation of XCOPY target and segment descriptor lists. Signed-off-by: David Disseldorp <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Bart Van Assche <[email protected]>
2017-01-10net: socket: Make unnecessarily global sockfs_setattr() staticTobias Klauser1-1/+1
Make sockfs_setattr() static as it is not used outside of net/socket.c This fixes the following GCC warning: net/socket.c:534:5: warning: no previous prototype for ‘sockfs_setattr’ [-Wmissing-prototypes] Fixes: 86741ec25462 ("net: core: Add a UID field to struct sock.") Cc: Lorenzo Colitti <[email protected]> Signed-off-by: Tobias Klauser <[email protected]> Acked-by: Lorenzo Colitti <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-01-10Merge tag 'wireless-drivers-for-davem-2017-01-10' of ↵David S. Miller4-21/+31
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for 4.10 Only two fixes at this time. The rtlwifi fix is an important one as it fixes a reported oops and Linus was already asking about it. The orinoco fix is not tested on a real device, because it's old legacy hardware and hardly no-one use it, but it should fix a (theoretical) issue with VMAP_STACK. ==================== Signed-off-by: David S. Miller <[email protected]>
2017-01-10wusbcore: Fix one more crypto-on-the-stack bugAndy Lutomirski1-2/+1
The driver put a constant buffer of all zeros on the stack and pointed a scatterlist entry at it. This doesn't work with virtual stacks. Use ZERO_PAGE instead. Cc: [email protected] # 4.9 only Reported-by: Eric Biggers <[email protected]> Signed-off-by: Andy Lutomirski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2017-01-10USB: serial: kl5kusb105: fix line-state error handlingJohan Hovold1-4/+5
The current implementation failed to detect short transfers when attempting to read the line state, and also, to make things worse, logged the content of the uninitialised heap transfer buffer. Fixes: abf492e7b3ae ("USB: kl5kusb105: fix DMA buffers on stack") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2017-01-10Merge remote-tracking branches 'asoc/fix/nau8825', 'asoc/fix/rt5645', ↵Mark Brown5-9/+26
'asoc/fix/tlv320aic3x' and 'asoc/fix/topology' into asoc-linus
2017-01-10Merge remote-tracking branches 'asoc/fix/arizona', 'asoc/fix/dpcm', ↵Mark Brown5-41/+95
'asoc/fix/dwc', 'asoc/fix/fsl-ssi' and 'asoc/fix/hdmi-codec' into asoc-linus
2017-01-10Merge remote-tracking branch 'asoc/fix/rcar' into asoc-linusMark Brown1-3/+1
2017-01-10Merge remote-tracking branch 'asoc/fix/intel' into asoc-linusMark Brown3-4/+20
2017-01-10Merge remote-tracking branch 'asoc/fix/component' into asoc-linusMark Brown2-5/+8
2017-01-10ALSA: usb-audio: Add a quirk for Plantronics BT600Dennis Kadioglu1-0/+1
Plantronics BT600 does not support reading the sample rate which leads to many lines of "cannot get freq at ep 0x1" and "cannot get freq at ep 0x82". This patch adds the USB ID of the BT600 to quirks.c and avoids those error messages. Signed-off-by: Dennis Kadioglu <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2017-01-10tmpfs: clear S_ISGID when setting posix ACLsGu Zheng1-5/+4
This change was missed the tmpfs modification in In CVE-2016-7097 commit 073931017b49 ("posix_acl: Clear SGID bit when setting file permissions") It can test by xfstest generic/375, which failed to clear setgid bit in the following test case on tmpfs: touch $testfile chown 100:100 $testfile chmod 2755 $testfile _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile Signed-off-by: Gu Zheng <[email protected]> Signed-off-by: Al Viro <[email protected]>
2017-01-10dmaengine: omap-dma: Fix the port_window supportPeter Ujfalusi1-15/+16
We do not yet have users of port_window. The following errors were found when converting the tusb6010_omap.c musb driver: - The peripheral side must have SRC_/DST_PACKED disabled - when configuring the burst for the peripheral side the memory side configuration were overwritten: d->csdp = ... -> d->csdp |= ... - The EI and FI were configured for the wrong sides of the transfers. With these changes and the converted tus6010_omap.c I was able to verify that things are working as they expected to work. Fixes: 201ac4861c19 ("dmaengine: omap-dma: Support for slave devices with data port window") Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2017-01-10dmaengine: iota: ioat_alloc_chan_resources should not perform sleeping ↵Krister Johansen1-2/+2
allocations. On a kernel with DEBUG_LOCKS, ioat_free_chan_resources triggers an in_interrupt() warning. With PROVE_LOCKING, it reports detecting a SOFTIRQ-safe to SOFTIRQ-unsafe lock ordering in the same code path. This is because dma_generic_alloc_coherent() checks if the GFP flags permit blocking. It allocates from different subsystems if blocking is permitted. The free path knows how to return the memory to the correct allocator. If GFP_KERNEL is specified then the alloc and free end up going through cma_alloc(), which uses mutexes. Given that ioat_free_chan_resources() can be called in interrupt context, ioat_alloc_chan_resources() must specify GFP_NOWAIT so that the allocations do not block and instead use an allocator that uses spinlocks. Signed-off-by: Krister Johansen <[email protected]> Acked-by: Dave Jiang <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2017-01-10sysctl: Drop reference added by grab_header in proc_sys_readdirZhou Chengming1-1/+2
Fixes CVE-2016-9191, proc_sys_readdir doesn't drop reference added by grab_header when return from !dir_emit_dots path. It can cause any path called unregister_sysctl_table will wait forever. The calltrace of CVE-2016-9191: [ 5535.960522] Call Trace: [ 5535.963265] [<ffffffff817cdaaf>] schedule+0x3f/0xa0 [ 5535.968817] [<ffffffff817d33fb>] schedule_timeout+0x3db/0x6f0 [ 5535.975346] [<ffffffff817cf055>] ? wait_for_completion+0x45/0x130 [ 5535.982256] [<ffffffff817cf0d3>] wait_for_completion+0xc3/0x130 [ 5535.988972] [<ffffffff810d1fd0>] ? wake_up_q+0x80/0x80 [ 5535.994804] [<ffffffff8130de64>] drop_sysctl_table+0xc4/0xe0 [ 5536.001227] [<ffffffff8130de17>] drop_sysctl_table+0x77/0xe0 [ 5536.007648] [<ffffffff8130decd>] unregister_sysctl_table+0x4d/0xa0 [ 5536.014654] [<ffffffff8130deff>] unregister_sysctl_table+0x7f/0xa0 [ 5536.021657] [<ffffffff810f57f5>] unregister_sched_domain_sysctl+0x15/0x40 [ 5536.029344] [<ffffffff810d7704>] partition_sched_domains+0x44/0x450 [ 5536.036447] [<ffffffff817d0761>] ? __mutex_unlock_slowpath+0x111/0x1f0 [ 5536.043844] [<ffffffff81167684>] rebuild_sched_domains_locked+0x64/0xb0 [ 5536.051336] [<ffffffff8116789d>] update_flag+0x11d/0x210 [ 5536.057373] [<ffffffff817cf61f>] ? mutex_lock_nested+0x2df/0x450 [ 5536.064186] [<ffffffff81167acb>] ? cpuset_css_offline+0x1b/0x60 [ 5536.070899] [<ffffffff810fce3d>] ? trace_hardirqs_on+0xd/0x10 [ 5536.077420] [<ffffffff817cf61f>] ? mutex_lock_nested+0x2df/0x450 [ 5536.084234] [<ffffffff8115a9f5>] ? css_killed_work_fn+0x25/0x220 [ 5536.091049] [<ffffffff81167ae5>] cpuset_css_offline+0x35/0x60 [ 5536.097571] [<ffffffff8115aa2c>] css_killed_work_fn+0x5c/0x220 [ 5536.104207] [<ffffffff810bc83f>] process_one_work+0x1df/0x710 [ 5536.110736] [<ffffffff810bc7c0>] ? process_one_work+0x160/0x710 [ 5536.117461] [<ffffffff810bce9b>] worker_thread+0x12b/0x4a0 [ 5536.123697] [<ffffffff810bcd70>] ? process_one_work+0x710/0x710 [ 5536.130426] [<ffffffff810c3f7e>] kthread+0xfe/0x120 [ 5536.135991] [<ffffffff817d4baf>] ret_from_fork+0x1f/0x40 [ 5536.142041] [<ffffffff810c3e80>] ? kthread_create_on_node+0x230/0x230 One cgroup maintainer mentioned that "cgroup is trying to offline a cpuset css, which takes place under cgroup_mutex. The offlining ends up trying to drain active usages of a sysctl table which apprently is not happening." The real reason is that proc_sys_readdir doesn't drop reference added by grab_header when return from !dir_emit_dots path. So this cpuset offline path will wait here forever. See here for details: http://www.openwall.com/lists/oss-security/2016/11/04/13 Fixes: f0c3b5093add ("[readdir] convert procfs") Cc: [email protected] Reported-by: CAI Qian <[email protected]> Tested-by: Yang Shukui <[email protected]> Signed-off-by: Zhou Chengming <[email protected]> Acked-by: Al Viro <[email protected]> Signed-off-by: Eric W. Biederman <[email protected]>
2017-01-10pid: fix lockdep deadlock warning due to ucount_lockAndrei Vagin1-4/+6
========================================================= [ INFO: possible irq lock inversion dependency detected ] 4.10.0-rc2-00024-g4aecec9-dirty #118 Tainted: G W --------------------------------------------------------- swapper/1/0 just changed the state of lock: (&(&sighand->siglock)->rlock){-.....}, at: [<ffffffffbd0a1bc6>] __lock_task_sighand+0xb6/0x2c0 but this lock took another, HARDIRQ-unsafe lock in the past: (ucounts_lock){+.+...} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Chain exists of: &(&sighand->siglock)->rlock --> &(&tty->ctrl_lock)->rlock --> ucounts_lock Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(ucounts_lock); local_irq_disable(); lock(&(&sighand->siglock)->rlock); lock(&(&tty->ctrl_lock)->rlock); <Interrupt> lock(&(&sighand->siglock)->rlock); *** DEADLOCK *** This patch removes a dependency between rlock and ucount_lock. Fixes: f333c700c610 ("pidns: Add a limit on the number of pid namespaces") Cc: [email protected] Signed-off-by: Andrei Vagin <[email protected]> Acked-by: Al Viro <[email protected]> Signed-off-by: Eric W. Biederman <[email protected]>
2017-01-10libfs: Modify mount_pseudo_xattr to be clear it is not a userspace mountEric W. Biederman1-1/+2
Add MS_KERNMOUNT to the flags that are passed. Use sget_userns and force &init_user_ns instead of calling sget so that even if called from a weird context the internal filesystem will be considered to be in the intial user namespace. Luis Ressel reported that the the failure to pass MS_KERNMOUNT into mount_pseudo broke his in development graphics driver that uses the generic drm infrastructure. I am not certain the deriver was bug free in it's usage of that infrastructure but since mount_pseudo_xattr can never be triggered by userspace it is clearer and less error prone, and less problematic for the code to be explicit. Reported-by: Luis Ressel <[email protected]> Tested-by: Luis Ressel <[email protected]> Acked-by: Al Viro <[email protected]> Signed-off-by: "Eric W. Biederman" <[email protected]>
2017-01-10mnt: Protect the mountpoint hashtable with mount_lockEric W. Biederman2-21/+50
Protecting the mountpoint hashtable with namespace_sem was sufficient until a call to umount_mnt was added to mntput_no_expire. At which point it became possible for multiple calls of put_mountpoint on the same hash chain to happen on the same time. Kristen Johansen <[email protected]> reported: > This can cause a panic when simultaneous callers of put_mountpoint > attempt to free the same mountpoint. This occurs because some callers > hold the mount_hash_lock, while others hold the namespace lock. Some > even hold both. > > In this submitter's case, the panic manifested itself as a GP fault in > put_mountpoint() when it called hlist_del() and attempted to dereference > a m_hash.pprev that had been poisioned by another thread. Al Viro observed that the simple fix is to switch from using the namespace_sem to the mount_lock to protect the mountpoint hash table. I have taken Al's suggested patch moved put_mountpoint in pivot_root (instead of taking mount_lock an additional time), and have replaced new_mountpoint with get_mountpoint a function that does the hash table lookup and addition under the mount_lock. The introduction of get_mounptoint ensures that only the mount_lock is needed to manipulate the mountpoint hashtable. d_set_mounted is modified to only set DCACHE_MOUNTED if it is not already set. This allows get_mountpoint to use the setting of DCACHE_MOUNTED to ensure adding a struct mountpoint for a dentry happens exactly once. Cc: [email protected] Fixes: ce07d891a089 ("mnt: Honor MNT_LOCKED when detaching mounts") Reported-by: Krister Johansen <[email protected]> Suggested-by: Al Viro <[email protected]> Acked-by: Al Viro <[email protected]> Signed-off-by: "Eric W. Biederman" <[email protected]>
2017-01-09x86/microcode/intel: Use correct buffer size for saving microcode dataJunichi Nomura1-2/+3
In generic_load_microcode(), curr_mc_size is the size of the last allocated buffer and since we have this performance "optimization" there to vmalloc a new buffer only when the current one is bigger, curr_mc_size ends up becoming the size of the biggest buffer we've seen so far. However, we end up saving the microcode patch which matches our CPU and its size is not curr_mc_size but the respective mc_size during the iteration while we're staring at it. So save that mc_size into a separate variable and use it to store the previously found microcode buffer. Without this fix, we could get oops like this: BUG: unable to handle kernel paging request at ffffc9000e30f000 IP: __memcpy+0x12/0x20 ... Call Trace: ? kmemdup+0x43/0x60 __alloc_microcode_buf+0x44/0x70 save_microcode_patch+0xd4/0x150 generic_load_microcode+0x1b8/0x260 request_microcode_user+0x15/0x20 microcode_write+0x91/0x100 __vfs_write+0x34/0x120 vfs_write+0xc1/0x130 SyS_write+0x56/0xc0 do_syscall_64+0x6c/0x160 entry_SYSCALL64_slow_path+0x25/0x25 Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading") Signed-off-by: Jun'ichi Nomura <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-01-09x86/microcode/intel: Fix allocation size of struct ucode_patchJunichi Nomura1-1/+1
We allocate struct ucode_patch here. @size is the size of microcode data and used for kmemdup() later in this function. Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading") Signed-off-by: Jun'ichi Nomura <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-01-09x86/microcode/intel: Add a helper which gives the microcode revisionBorislav Petkov3-38/+31
Since on Intel we're required to do CPUID(1) first, before reading the microcode revision MSR, let's add a special helper which does the required steps so that we don't forget to do them next time, when we want to read the microcode revision. Signed-off-by: Borislav Petkov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-01-09x86/microcode: Use native CPUID to tickle out microcode revisionBorislav Petkov2-24/+4
Intel supplies the microcode revision value in MSR 0x8b (IA32_BIOS_SIGN_ID) after CPUID(1) has been executed. Execute it each time before reading that MSR. It used to do sync_core() which did do CPUID but c198b121b1a1 ("x86/asm: Rewrite sync_core() to use IRET-to-self") changed the sync_core() implementation so we better make the microcode loading case explicit, as the SDM documents it. Reported-and-tested-by: Jun'ichi Nomura <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-01-09x86/CPU: Add native CPUID variants returning a single datumBorislav Petkov1-0/+18
... similarly to the cpuid_<reg>() variants. Signed-off-by: Borislav Petkov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-01-09md/raid5: Use correct IS_ERR() variation on pointer checkJes Sorensen1-1/+1
This fixes a build error on certain architectures, such as ppc64. Fixes: 6995f0b247e("md: takeover should clear unrelated bits") Signed-off-by: Jes Sorensen <[email protected]> Signed-off-by: Shaohua Li <[email protected]>
2017-01-09xfs: don't print warnings when xfs_log_force failsChristoph Hellwig1-10/+2
There are only two reasons for xfs_log_force / xfs_log_force_lsn to fail: one is an I/O error, for which xlog_bdstrat already logs a warning, and the second is an already shutdown log due to a previous I/O errors. In the latter case we'll already have a previous indication for the actual error, but the large stream of misleading warnings from xfs_log_force will probably scroll it out of the message buffer. Simply removing the warnings thus makes the XFS log reporting significantly better. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Carlos Maiolino <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2017-01-09xfs: don't rely on ->total in xfs_alloc_space_availableChristoph Hellwig1-3/+4
->total is a bit of an odd parameter passed down to the low-level allocator all the way from the high-level callers. It's supposed to contain the maximum number of blocks to be allocated for the whole transaction [1]. But in xfs_iomap_write_allocate we only convert existing delayed allocations and thus only have a minimal block reservation for the current transaction, so xfs_alloc_space_available can't use it for the allocation decisions. Use the maximum of args->total and the calculated block requirement to make a decision. We probably should get rid of args->total eventually and instead apply ->minleft more broadly, but that will require some extensive changes all over. [1] which creates lots of confusion as most callers don't decrement it once doing a first allocation. But that's for a separate series. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Brian Foster <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2017-01-09xfs: adjust allocation length in xfs_alloc_space_availableChristoph Hellwig2-65/+18
We must decide in xfs_alloc_fix_freelist if we can perform an allocation from a given AG is possible or not based on the available space, and should not fail the allocation past that point on a healthy file system. But currently we have two additional places that second-guess xfs_alloc_fix_freelist: xfs_alloc_ag_vextent tries to adjust the maxlen parameter to remove the reservation before doing the allocation (but ignores the various minium freespace requirements), and xfs_alloc_fix_minleft tries to fix up the allocated length after we've found an extent, but ignores the reservations and also doesn't take the AGFL into account (and thus fails allocations for not matching minlen in some cases). Remove all these later fixups and just correct the maxlen argument inside xfs_alloc_fix_freelist once we have the AGF buffer locked. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Brian Foster <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2017-01-09xfs: fix bogus minleft manipulationsChristoph Hellwig3-22/+8
We can't just set minleft to 0 when we're low on space - that's exactly what we need minleft for: to protect space in the AG for btree block allocations when we are low on free space. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Brian Foster <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2017-01-09xfs: bump up reserved blocks in xfs_alloc_set_asideChristoph Hellwig1-4/+1
Setting aside 4 blocks globally for bmbt splits isn't all that useful, as different threads can allocate space in parallel. Bump it to 4 blocks per AG to allow each thread that is currently doing an allocation to dip into it separately. Without that we may no have enough reserved blocks if there are enough parallel transactions in an almost out space file system that all run into bmap btree splits. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Brian Foster <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2017-01-09tcp: do not export tcp_peer_is_proven()Eric Dumazet1-1/+0
After commit 1fb6f159fd21 ("tcp: add tcp_conn_request"), tcp_peer_is_proven() no longer needs to be exported. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-01-09net: phy: Add Meson GXL PHY hardware dependencyJean Delvare1-0/+1
As I understand it the Meson GXL PHY driver is only useful on one architecture so only make it visible on that architecture. Signed-off-by: Jean Delvare <[email protected]> Fixes: 7334b3e47aee ("net: phy: Add Meson GXL Internal PHY driver") Cc: Neil Armstrong <[email protected]> Cc: Florian Fainelli <[email protected]> Cc: Andrew Lunn <[email protected]> Cc: David S. Miller <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-01-09net/appletalk: Fix kernel memory disclosureVlad Tsyrklevich1-1/+1
ipddp_route structs contain alignment padding so kernel heap memory is leaked when they are copied to user space in ipddp_ioctl(SIOCFINDIPDDPRT). Change kmalloc() to kzalloc() to clear that memory. Signed-off-by: Vlad Tsyrklevich <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-01-09ipv4: make tcp_notsent_lowat sysctl knob behave as true unsigned intPavel Tikhomirov1-1/+1
> cat /proc/sys/net/ipv4/tcp_notsent_lowat -1 > echo 4294967295 > /proc/sys/net/ipv4/tcp_notsent_lowat -bash: echo: write error: Invalid argument > echo -2147483648 > /proc/sys/net/ipv4/tcp_notsent_lowat > cat /proc/sys/net/ipv4/tcp_notsent_lowat -2147483648 but in documentation we have "tcp_notsent_lowat - UNSIGNED INTEGER" v2: simplify to just proc_douintvec Signed-off-by: Pavel Tikhomirov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-01-09ipv6: fix typosAlexander Alemayhu1-2/+2
o s/approriate/appropriate o s/discouvery/discovery Signed-off-by: Alexander Alemayhu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-01-09Merge tag 'drm-fixes-for-v4.10-rc4' of ↵Linus Torvalds29-126/+211
git://people.freedesktop.org/~airlied/linux Pull drm fixes from Dave Airlie: "amdgpu, radeon, msm, meson, tilcdc, drm fixes. Just back online for a couple of days, gathered up the remaining fixes pull requests. This contains fixes for a few ARM platforms (msm, tilcdc, meson), and one core atomic fix. The AMD pull has some new hardware support (Polaris12) in it, but this is pretty limited to just hw enablement and shouldn't cause any problems" * tag 'drm-fixes-for-v4.10-rc4' of git://people.freedesktop.org/~airlied/linux: drm/amdgpu: drop verde dpm quirks drm/radeon: drop verde dpm quirks drm/radeon: update smc firmware selection for SI drm/amdgpu: update si kicker smc firmware drm/amd/powerplay: extend smu's response timeout time. drm/amdgpu: remove static integer for uvd pp state drm/amd/amdgpu: add Polaris12 PCI ID drm/amdgpu/powerplay: add Polaris12 support drm/amd/amdgpu: add Polaris12 support (v3) MAINTAINERS: Update mailing list for radeon and amdgpu drm/meson: Fix CVBS VDAC disable drm/meson: Fix CVBS initialization when HDMI is configured by bootloader drm: Clean up planes in atomic commit helper failure path drm: tilcdc: simplify the recovery from sync lost error on rev1 drm/meson: Fix plane atomic check when no crtc for the plane drm/msm: Verify that MSM_SUBMIT_BO_FLAGS are set drm/msm: Put back the vaddr in submit_reloc() drm/msm: Ensure that the hardware write pointer is valid
Powered by cgit, Gruvboxed by Blaster4385.