- 02 May, 2018 4 commits
-
-
Andy Lutomirski authored
CVE-2018-8897 There's nothing IST-worthy about #BP/int3. We don't allow kprobes in the small handful of places in the kernel that run at CPL0 with an invalid stack, and 32-bit kernels have used normal interrupt gates for #BP forever. Furthermore, we don't allow kprobes in places that have usergs while in kernel mode, so "paranoid" is also unnecessary. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org (backported from commit d8ba61ba) Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
Linus Torvalds authored
CVE-2018-1087 The undocumented 'icebp' instruction (aka 'int1') works pretty much like 'int3' in the absense of in-circuit probing equipment (except, obviously, that it raises #DB instead of raising #BP), and is used by some validation test-suites as such. But Andy Lutomirski noticed that his test suite acted differently in kvm than on bare hardware. The reason is that kvm used an inexact test for the icebp instruction: it just assumed that an all-zero VM exit qualification value meant that the VM exit was due to icebp. That is not unlike the guess that do_debug() does for the actual exception handling case, but it's purely a heuristic, not an absolute rule. do_debug() does it because it wants to ascribe _some_ reasons to the #DB that happened, and an empty %dr6 value means that 'icebp' is the most likely casue and we have no better information. But kvm can just do it right, because unlike the do_debug() case, kvm actually sees the real reason for the #DB in the VM-exit interruption information field. So instead of relying on an inexact heuristic, just use the actual VM exit information that says "it was 'icebp'". Right now the 'icebp' instruction isn't technically documented by Intel, but that will hopefully change. The special "privileged software exception" information _is_ actually mentioned in the Intel SDM, even though the cause of it isn't enumerated. Reported-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Linus Torvalds authored
CVE-2018-1000199 Annoyingly, modify_user_hw_breakpoint() unnecessarily complicates the modification of a breakpoint - simplify it and remove the pointless local variables. Also update the stale Docbook while at it. Signed-off-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit f67b1503) Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 23 Apr, 2018 3 commits
-
-
Stefan Bader authored
Signed-off-by: -
Sanjay Kumar Konduri authored
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1757435 We are disabling deep sleep before performing scan. In corner case, it's observed that probe request is downloaded to firmware before receiving deep sleep confirmation which leads to a scan stop issue Race is resolved in this patch by waiting for the confirmation from firmware Signed-off-by:
Sanjay Kumar Konduri <sanjay.konduri@redpinesignals.com> Signed-off-by:
Amitkumar Karwar <amit.karwar@redpinesignals.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 13 Apr, 2018 2 commits
-
-
Kleber Sacilotto de Souza authored
Signed-off-by: -
Paolo Pisati authored
BugLink: https://bugs.launchpad.net/bugs/1763644Signed-off-by:
Paolo Pisati <paolo.pisati@canonical.com> Acked-by:
-
- 12 Apr, 2018 1 commit
-
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:Kamal Mostafa <kamal@canonical.com>
-
- 05 Apr, 2018 5 commits
-
-
Kleber Sacilotto de Souza authored
Signed-off-by: -
Tim Chen authored
BugLink: https://bugs.launchpad.net/bugs/1759920 CVE-2017-5715 (Spectre v2 Intel) Flush indirect branches when switching into a process that marked itself non dumpable. This protects high value processes like gpg better, without having too high performance overhead. If done naïvely, we could switch to a kernel idle thread and then back to the original process, such as: process A -> idle -> process A In such scenario, we do not have to do IBPB here even though the process is non-dumpable, as we are switching back to the same process after a hiatus. To avoid the redundant IBPB, which is expensive, we track the last mm user context ID. The cost is to have an extra u64 mm context id to track the last mm we were using before switching to the init_mm used by idle. Avoiding the extra IBPB is probably worth the extra memory for this common scenario. For those cases where tlb_defer_switch_to_init_mm() returns true (non PCID), lazy tlb will defer switch to init_mm, so we will not be changing the mm for the process A -> idle -> process A switch. So IBPB will be skipped for this case. Thanks to the reviewers and Andy Lutomirski for the suggestion of using ctx_id which got rid of the problem of mm pointer recycling. Signed-off-by:
Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Signed-off-by:
-
Tyler Hicks authored
BugLink: https://bugs.launchpad.net/bugs/1759920 CVE-2017-5715 (Spectre v2 Intel) This reverts commit 3f21d934. Using a ptrace access check in the middle of a task switch was causing a hard lockup in some cases when the old task was confined by AppArmor. If the AppArmor policy for the the old task didn't allow the task to ptrace the new task, AppArmor would attempt to emit an audit message and deadlock on the task's pi_lock would occur. The fix is to revert this change and go with upstream's implementation that uses the task's dumpable state to determine if IBPB should be used. Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1760876 Out of tree builds utilise the kernel Makefiles and therefore we need to include all direct dependencies of those Makefiles. Now that we call out to the repoline extractor during builds we must carry the extractor with the headers. Move the extractor to the kernel scripts directory and ensure its name is unique. Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Juerg Haefliger <juerg.haefliger@canonical.com> Acked-by:
-
Seth Forshee authored
With the new support for removing known safe retpoline sequences from the ones which were detected it is now completely valid to end up with an empty retpoline file in the abi. Remove the check for empty retpoline files so this will not cause an error. BugLink: http://bugs.launchpad.net/bugs/1758856Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
- 04 Apr, 2018 25 commits
-
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1756860Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 16c3ada8 upstream. With CONFIG_KASAN, we get an overly long stack frame due to inlining the register access functions: drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7': drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] This is caused by a gcc bug that has now been fixed in gcc-8. To work around the problem, we can pass the register data through a local variable that older gcc versions can optimize out as well. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 5c103719 upstream. The ohci-hcd node has an interrupt number but no interrupt-parent, leading to a warning with current dtc versions: arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000 As seen from the related exynos dts files, the ohci and ehci controllers always share one interrupt number, and the number is the same here as well, so setting the same interrupt-parent is the reasonable solution here. Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 33436478 upstream. Without this tag, we get a build warning: WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o For completeness, I'm also adding author and description fields. Acked-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Linus Torvalds authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit c0eb027e upstream. Normal pathname lookup doesn't allow empty pathnames, but using AT_EMPTY_PATH (with name_to_handle_at() or fstatat(), for example) you can trigger an empty pathname lookup. And not only is the RCU lookup in that case entirely unnecessary (because we'll obviously immediately finalize the end result), it is actively wrong. Why? An empth path is a special case that will return the original 'dirfd' dentry - and that dentry may not actually be RCU-free'd, resulting in a potential use-after-free if we were to initialize the path lazily under the RCU read lock and depend on complete_walk() finalizing the dentry. Found by syzkaller and KASAN. Reported-by:
Dmitry Vyukov <dvyukov@google.com> Reported-by:
Vegard Nossum <vegard.nossum@gmail.com> Acked-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1756860 I ran into a 4.9 build warning in randconfig testing, starting with the KAISER patches: arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct': arch/x86/include/asm/pgtable_types.h:208:24: error: large integer implicitly truncated to unsigned type [-Werror=overflow] #define __PAGE_KERNEL (__PAGE_KERNEL_EXEC | _PAGE_NX) ^ arch/x86/kernel/ldt.c:81:6: note: in expansion of macro '__PAGE_KERNEL' __PAGE_KERNEL); ^~~~~~~~~~~~~ I originally ran into this last year when the patches were part of linux-next, and tried to work around it by using the proper 'pteval_t' types consistently, but that caused additional problems. This takes a much simpler approach, and makes the argument type of the dummy helper always 64-bit, which is wide enough for any page table layout and won't hurt since this call is just an empty stub anyway. Fixes: 8f0baadf ("kaiser: merged update") Signed-off-by:
Kees Cook <keescook@chromium.org> Acked-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
-
NeilBrown authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 8dd601fa upstream. dec_pending() is given an error status (possibly 0) to be recorded against a bio. It can be called several times on the one 'struct dm_io', and it is careful to only assign a non-zero error to io->status. However when it then assigned io->status to bio->bi_status, it is not careful and could overwrite a genuine error status with 0. This can happen when chained bios are in use. If a bio is chained beneath the bio that this dm_io is handling, the child bio might complete and set bio->bi_status before the dm_io completes. This has been possible since chained bios were introduced in 3.14, and has become a lot easier to trigger with commit 18a25da8 ("dm: ensure bio submission follows a depth-first tree walk") as that commit caused dm to start using chained bios itself. A particular failure mode is that if a bio spans an 'error' target and a working target, the 'error' fragment will complete instantly and set the ->bi_status, and the other fragment will normally complete a little later, and will clear ->bi_status. The fix is simply to only assign io_error to bio->bi_status when io_error is not zero. Reported-and-tested-by:
Milan Broz <gmazyland@gmail.com> Cc: stable@vger.kernel.org (v3.14+) Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 7ac8ff95 upstream. IPv6 doesn't work on the MacchiatoBIN board. It is caused by broken multicast address filter in the mvpp2 driver. The driver loads doesn't load any multicast entries if "allmulti" is not set. This condition should be reversed. The condition !netdev_mc_empty(dev) is useless (because netdev_for_each_mc_addr is nop if the list is empty). This patch also fixes a possible overflow of the multicast list - if mvpp2_prs_mac_da_accept fails, we set the allmulti flag and retry. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit d15d662e upstream. ALSA sequencer core initializes the event pool on demand by invoking snd_seq_pool_init() when the first write happens and the pool is empty. Meanwhile user can reset the pool size manually via ioctl concurrently, and this may lead to UAF or out-of-bound accesses since the function tries to vmalloc / vfree the buffer. A simple fix is to just wrap the snd_seq_pool_init() call with the recently introduced client->ioctl_mutex; as the calls for snd_seq_pool_init() from other side are always protected with this mutex, we can avoid the race. Reported-by:
范龙飞 <long7573@126.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Lassi Ylikojola authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 5e35dc03 upstream. Add quirk to ensure a sync endpoint is properly configured. This patch is a fix for same symptoms on Behringer UFX1204 as patch from Albertto Aquirre on Dec 8 2016 for Axe-Fx II. Signed-off-by:
Lassi Ylikojola <lassi.ylikojola@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jan-Marek Glogowski authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit fdcc968a upstream. These laptops have a combined jack to attach headsets, the U727 on the left, the U757 on the right, but a headsets microphone doesn't work. Using hdajacksensetest I found that pin 0x19 changed the present state when plugging the headset, in addition to 0x21, but didn't have the correct configuration (shown as "Not connected"). So this sets the configuration to the same values as the headphone pin 0x21 except for the device type microphone, which makes it work correctly. With the patch the configured pins for U727 are Pin 0x12 (Internal Mic, Mobile-In): present = No Pin 0x14 (Internal Speaker): present = No Pin 0x19 (Black Mic, Left side): present = No Pin 0x1d (Internal Aux): present = No Pin 0x21 (Black Headphone, Left side): present = No Signed-off-by:
Jan-Marek Glogowski <glogow@fbihome.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Kirill Marinushkin authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 447cae58 upstream. The layout of the UAC2 Control request and response varies depending on the request type. With the current implementation, only the Layout 2 Parameter Block (with the 2-byte sized RANGE attribute) is handled properly. For the Control requests with the 1-byte sized RANGE attribute (Bass Control, Mid Control, Tremble Control), the response is parsed incorrectly. This commit: * fixes the wLength field value in the request * fixes parsing the range values from the response Fixes: 23caaf19 ("ALSA: usb-mixer: Add support for Audio Class v2.0") Signed-off-by:
Kirill Marinushkin <k.marinushkin@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Hui Wang authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 3f2f7c55 upstream. One of them has the codec of alc256 and the other one has the codec of alc289. Cc: <stable@vger.kernel.org> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
Liu Bo authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 900c9981 upstream. The highest objectid, which is assigned to new inode, is decided at the time of initializing fs roots. However, in cases where log replay gets processed, the btree which fs root owns might be changed, so we have to search it again for the highest objectid, otherwise creating new inode would end up with -EEXIST. cc: <stable@vger.kernel.org> v4.4-rc6+ Fixes: f32e48e9 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots") Signed-off-by:
Liu Bo <bo.li.liu@oracle.com> Reviewed-by:
Josef Bacik <jbacik@fb.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Liu Bo authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 1846430c upstream. In cases that the whole fs flips into readonly status due to failures in critical sections, then log tree's blocks are still dirty, and this leads to a crash during umount time, the crash is about use-after-free, umount -> close_ctree -> stop workers -> iput(btree_inode) -> iput_final -> write_inode_now -> ... -> queue job on stop'd workers cc: <stable@vger.kernel.org> v3.12+ Fixes: 681ae509 ("Btrfs: cleanup reserved space when freeing tree log on error") Signed-off-by:
-
Liu Bo authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit e8916699 upstream. @cur_offset is not set back to what it should be (@cow_start) if btrfs_next_leaf() returns something wrong, and the range [cow_start, cur_offset) remains locked forever. cc: <stable@vger.kernel.org> Signed-off-by:
-
Larry Finger authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit c713fb07 upstream. There has been a coding error in rtl8821ae since it was first introduced, namely that an 8-bit register was read using a 16-bit read in _rtl8821ae_dbi_read(). This error was fixed with commit 40b368af ("rtlwifi: Fix alignment issues"); however, this change led to instability in the connection. To restore stability, this change was reverted in commit b8b8b163 ("rtlwifi: rtl8821ae: Fix connection lost problem"). Unfortunately, the unaligned access causes machine checks in ARM architecture, and we were finally forced to find the actual cause of the problem on x86 platforms. Following a suggestion from Pkshih <pkshih@realtek.com>, it was found that increasing the ASPM L1 latency from 0 to 7 fixed the instability. This parameter was varied to see if a smaller value would work; however, it appears that 7 is the safest value. A new symbol is defined for this quantity, thus it can be easily changed if necessary. Fixes: b8b8b163 ("rtlwifi: rtl8821ae: Fix connection lost problem") Cc: Stable <stable@vger.kernel.org> # 4.14+ Fix-suggested-by:
Pkshih <pkshih@realtek.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Tested-by: James Cameron <quozl@laptop.org> # x86_64 OLPC NL3 Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Nicolas Pitre authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 724ba8b3 upstream. When this method is set, the caller expects struct console_font fields to be properly initialized when it returns. Leave it unset otherwise nonsensical (leaked kernel stack) values are returned to user space. Signed-off-by:
Nicolas Pitre <nico@linaro.org> Cc: stable@vger.kernel.org Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 9cb18db0 upstream. Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent display node was also prematurely freed. Note that the display and timings node references are never put after a successful dt-initialisation so the nodes would leak on later probe deferrals and on driver unbind. Fixes: b985172b ("video: atmel_lcdfb: add device tree suport") Cc: stable <stable@vger.kernel.org> # 3.13 Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit af27d940 upstream. We get a warning about some slow configurations in randconfig kernels: mm/memory.c:83:2: error: #warning Unfortunate NUMA and NUMA Balancing config, growing page-frame for last_cpupid. [-Werror=cpp] The warning is reasonable by itself, but gets in the way of randconfig build testing, so I'm hiding it whenever CONFIG_COMPILE_TEST is set. The warning was added in 2013 in commit 75980e97 ("mm: fold page->_last_nid into page->flags where possible"). Cc: stable@vger.kernel.org Signed-off-by:
-
Ernesto A. Fernández authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 9f037248 upstream. The grpid option is currently described as being the same as nogrpid. Signed-off-by:
Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by:
-
Zhouyi Zhou authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 06f29cc8 upstream. In the function __ext4_grp_locked_error(), __save_error_info() is called to save error info in super block block, but does not sync that information to disk to info the subsequence fsck after reboot. This patch writes the error information to disk. After this patch, I think there is no obvious EXT4 error handle branches which leads to "Remounting filesystem read-only" will leave the disk partition miss the subsequence fsck. Signed-off-by:
Zhouyi Zhou <zhouzhouyi@gmail.com> Signed-off-by:
-
Stewart Smith authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 5b8b5806 upstream. According to the OPAL docs: skiboot-5.2.5/doc/opal-api/opal-rtc-read-3.txt skiboot-5.2.5/doc/opal-api/opal-rtc-write-4.txt OPAL_HARDWARE may be returned from OPAL_RTC_READ or OPAL_RTC_WRITE and this indicates either a transient or permanent error. Prior to this patch, Linux was not dealing with OPAL_HARDWARE being a permanent error particularly well, in that you could end up in a busy loop. This was not too hard to trigger on an AMI BMC based OpenPOWER machine doing a continuous "ipmitool mc reset cold" to the BMC, the result of that being that we'd get stuck in an infinite loop in opal_get_rtc_time(). We now retry a few times before returning the error higher up the stack. Fixes: 16b1d26e ("rtc/tpo: Driver to support rtc and wakeup on PowerNV platform") Cc: stable@vger.kernel.org # v3.19+ Signed-off-by:
Stewart Smith <stewart@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Julia Lawall authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 3a61b527 upstream. Check the variable that was most recently initialized. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x, y, f, g, e, m; statement S1,S2,S3,S4; @@ x = f(...); if (\(<+...x...+>\&e\)) S1 else S2 ( x = g(...); | m = g(...,&x,...); | y = g(...); *if (e) S3 else S4 ) // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Gustavo A. R. Silva authored
BugLink: http://bugs.launchpad.net/bugs/1756860 commit 24dbc600 upstream. Currently, x86_cache_size is of type int, which makes no sense as we will never have a valid cache size equal or less than 0. So instead of initializing this variable to -1, it can perfectly be initialized to 0 and use it as an unsigned variable instead. Suggested-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Addresses-Coverity-ID: 1464429 Link: http://lkml.kernel.org/r/20180213192208.GA26414@embeddedor.comSigned-off-by:
-
