12 Jun, 2018
6 commits
-
commit 2ae89c7a82ea9d81a19b4fc2df23bef4b112f24e upstream.
In file included from scripts/kconfig/zconf.tab.c:2485:
scripts/kconfig/confdata.c: In function ‘conf_write’:
scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
sprintf(newname, "%s%s", dirname, basename);
^~
scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes
sprintf(newname, "%s%s", dirname, basename);
^~~~~~
scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097
sprintf(newname, "%s%s", dirname, basename);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
^~~~~~~~~~~
scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097
sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Increase the size of tmpname and newname to make GCC happy.
Signed-off-by: Nathan Chancellor
Signed-off-by: Masahiro Yamada
Signed-off-by: Greg Kroah-Hartman -
commit e2731e55884f2138a252b0a3d7b24d57e49c3c59 upstream.
btrfs-progs uses super flag bit BTRFS_SUPER_FLAG_METADUMP_V2 (1ULL << 34).
So just define that in kernel so that we know its been used.Signed-off-by: Anand Jain
Reviewed-by: David Sterba
Signed-off-by: David Sterba
Signed-off-by: Greg Kroah-Hartman -
commit 423913ad4ae5b3e8fb8983f70969fb522261ba26 upstream.
Commit be83bbf80682 ("mmap: introduce sane default mmap limits") was
introduced to catch problems in various ad-hoc character device drivers
doing mmap and getting the size limits wrong. In the process, it used
"known good" limits for the normal cases of mapping regular files and
block device drivers.It turns out that the "s_maxbytes" limit was less "known good" than I
thought. In particular, /proc doesn't set it, but exposes one regular
file to mmap: /proc/vmcore. As a result, that file got limited to the
default MAX_INT s_maxbytes value.This went unnoticed for a while, because apparently the only thing that
needs it is the s390 kernel zfcpdump, but there might be other tools
that use this too.Vasily suggested just changing s_maxbytes for all of /proc, which isn't
wrong, but makes me nervous at this stage. So instead, just make the
new mmap limit always be MAX_LFS_FILESIZE for regular files, which won't
affect anything else. It wasn't the regular file case I was worried
about.I'd really prefer for maxsize to have been per-inode, but that is not
how things are today.Fixes: be83bbf80682 ("mmap: introduce sane default mmap limits")
Reported-by: Vasily Gorbik
Cc: Al Viro
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit be83bbf806822b1b89e0a0f23cd87cddc409e429 upstream.
The internal VM "mmap()" interfaces are based on the mmap target doing
everything using page indexes rather than byte offsets, because
traditionally (ie 32-bit) we had the situation that the byte offset
didn't fit in a register. So while the mmap virtual address was limited
by the word size of the architecture, the backing store was not.So we're basically passing "pgoff" around as a page index, in order to
be able to describe backing store locations that are much bigger than
the word size (think files larger than 4GB etc).But while this all makes a ton of sense conceptually, we've been dogged
by various drivers that don't really understand this, and internally
work with byte offsets, and then try to work with the page index by
turning it into a byte offset with "pgoff << PAGE_SHIFT".Which obviously can overflow.
Adding the size of the mapping to it to get the byte offset of the end
of the backing store just exacerbates the problem, and if you then use
this overflow-prone value to check various limits of your device driver
mmap capability, you're just setting yourself up for problems.The correct thing for drivers to do is to do their limit math in page
indices, the way the interface is designed. Because the generic mmap
code _does_ test that the index doesn't overflow, since that's what the
mmap code really cares about.HOWEVER.
Finding and fixing various random drivers is a sisyphean task, so let's
just see if we can just make the core mmap() code do the limiting for
us. Realistically, the only "big" backing stores we need to care about
are regular files and block devices, both of which are known to do this
properly, and which have nice well-defined limits for how much data they
can access.So let's special-case just those two known cases, and then limit other
random mmap users to a backing store that still fits in "unsigned long".
Realistically, that's not much of a limit at all on 64-bit, and on
32-bit architectures the only worry might be the GPU drivers, which can
have big physical address spaces.To make it possible for drivers like that to say that they are 64-bit
clean, this patch does repurpose the "FMODE_UNSIGNED_OFFSET" bit in the
file flags to allow drivers to mark their file descriptors as safe in
the full 64-bit mmap address space.[ The timing for doing this is less than optimal, and this should really
go in a merge window. But realistically, this needs wide testing more
than it needs anything else, and being main-line is the only way to do
that.So the earlier the better, even if it's outside the proper development
cycle - Linus ]Cc: Kees Cook
Cc: Dan Carpenter
Cc: Al Viro
Cc: Willy Tarreau
Cc: Dave Airlie
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit ccce20fc7968d546fb1e8e147bf5cdc8afc4278a upstream.
Since SCSI scanning occurs asynchronously, since sd_revalidate_disk() is
called from sd_probe_async() and since sd_revalidate_disk() calls
sd_zbc_read_zones() it can happen that sd_zbc_read_zones() is called
concurrently with blkdev_report_zones() and/or blkdev_reset_zones(). That can
cause these functions to fail with -EIO because sd_zbc_read_zones() e.g. sets
q->nr_zones to zero before restoring it to the actual value, even if no drive
characteristics have changed. Avoid that this can happen by making the
following changes:- Protect the code that updates zone information with blk_queue_enter()
and blk_queue_exit().
- Modify sd_zbc_setup_seq_zones_bitmap() and sd_zbc_setup() such that
these functions do not modify struct scsi_disk before all zone
information has been obtained.Note: since commit 055f6e18e08f ("block: Make q_usage_counter also track
legacy requests"; kernel v4.15) the request queue freezing mechanism also
affects legacy request queues.Fixes: 89d947561077 ("sd: Implement support for ZBC devices")
Signed-off-by: Bart Van Assche
Cc: Jens Axboe
Cc: Damien Le Moal
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: stable@vger.kernel.org # v4.16
Reviewed-by: Damien Le Moal
Signed-off-by: Martin K. Petersen
Signed-off-by: Damien Le Moal
Signed-off-by: Greg Kroah-Hartman -
commit 4b433924b2755a94f99258c178684a0e05c344de upstream.
Rework sd_zbc_check_zone_size() to avoid a memory leak due to an early
return if sd_zbc_report_zones() fails.Reported-by: David.butterfield
Signed-off-by: Damien Le Moal
Cc: stable@vger.kernel.org
Reviewed-by: Bart Van Assche
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
05 Jun, 2018
34 commits
-
commit aa0ab02ba992eb956934b21373e0138211486ddd upstream.
On the 8xx, the page size is set in the PMD entry and applies to
all pages of the page table pointed by the said PMD entry.When an app has some regular pages allocated (e.g. see below) and tries
to mmap() a huge page at a hint address covered by the same PMD entry,
the kernel accepts the hint allthough the 8xx cannot handle different
page sizes in the same PMD entry.10000000-10001000 r-xp 00000000 00:0f 2597 /root/malloc
10010000-10011000 rwxp 00000000 00:0f 2597 /root/mallocmmap(0x10080000, 524288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0) = 0x10080000This results the app remaining forever in do_page_fault()/hugetlb_fault()
and when interrupting that app, we get the following warning:[162980.035629] WARNING: CPU: 0 PID: 2777 at arch/powerpc/mm/hugetlbpage.c:354 hugetlb_free_pgd_range+0xc8/0x1e4
[162980.035699] CPU: 0 PID: 2777 Comm: malloc Tainted: G W 4.14.6 #85
[162980.035744] task: c67e2c00 task.stack: c668e000
[162980.035783] NIP: c000fe18 LR: c00e1eec CTR: c00f90c0
[162980.035830] REGS: c668fc20 TRAP: 0700 Tainted: G W (4.14.6)
[162980.035854] MSR: 00029032 CR: 24044224 XER: 20000000
[162980.036003]
[162980.036003] GPR00: c00e1eec c668fcd0 c67e2c00 00000010 c6869410 10080000 00000000 77fb4000
[162980.036003] GPR08: ffff0001 0683c001 00000000 ffffff80 44028228 10018a34 00004008 418004fc
[162980.036003] GPR16: c668e000 00040100 c668e000 c06c0000 c668fe78 c668e000 c6835ba0 c668fd48
[162980.036003] GPR24: 00000000 73ffffff 74000000 00000001 77fb4000 100fffff 10100000 10100000
[162980.036743] NIP [c000fe18] hugetlb_free_pgd_range+0xc8/0x1e4
[162980.036839] LR [c00e1eec] free_pgtables+0x12c/0x150
[162980.036861] Call Trace:
[162980.036939] [c668fcd0] [c00f0774] unlink_anon_vmas+0x1c4/0x214 (unreliable)
[162980.037040] [c668fd10] [c00e1eec] free_pgtables+0x12c/0x150
[162980.037118] [c668fd40] [c00eabac] exit_mmap+0xe8/0x1b4
[162980.037210] [c668fda0] [c0019710] mmput.part.9+0x20/0xd8
[162980.037301] [c668fdb0] [c001ecb0] do_exit+0x1f0/0x93c
[162980.037386] [c668fe00] [c001f478] do_group_exit+0x40/0xcc
[162980.037479] [c668fe10] [c002a76c] get_signal+0x47c/0x614
[162980.037570] [c668fe70] [c0007840] do_signal+0x54/0x244
[162980.037654] [c668ff30] [c0007ae8] do_notify_resume+0x34/0x88
[162980.037744] [c668ff40] [c000dae8] do_user_signal+0x74/0xc4
[162980.037781] Instruction dump:
[162980.037821] 7fdff378 81370000 54a3463a 80890020 7d24182e 7c841a14 712a0004 4082ff94
[162980.038014] 2f890000 419e0010 712a0ff0 408200e0 54a9000a 7f984840 419d0094
[162980.038216] ---[ end trace c0ceeca8e7a5800a ]---
[162980.038754] BUG: non-zero nr_ptes on freeing mm: 1
[162985.363322] BUG: non-zero nr_ptes on freeing mm: -1In order to fix this, this patch uses the address space "slices"
implemented for BOOK3S/64 and enhanced to support PPC32 by the
preceding patch.This patch modifies the context.id on the 8xx to be in the range
[1:16] instead of [0:15] in order to identify context.id == 0 as
not initialised contexts as done on BOOK3SThis patch activates CONFIG_PPC_MM_SLICES when CONFIG_HUGETLB_PAGE is
selected for the 8xxAlltough we could in theory have as many slices as PMD entries, the
current slices implementation limits the number of low slices to 16.
This limitation is not preventing us to fix the initial issue allthough
it is suboptimal. It will be cured in a subsequent patch.Fixes: 4b91428699477 ("powerpc/8xx: Implement support of hugepages")
Signed-off-by: Christophe Leroy
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit db3a528db41caaa6dfd4c64e9f5efb1c81a80467 upstream.
In preparation for the following patch which will fix an issue on
the 8xx by re-using the 'slices', this patch enhances the
'slices' implementation to support 32 bits CPUs.On PPC32, the address space is limited to 4Gbytes, hence only the low
slices will be used.The high slices use bitmaps. As bitmap functions are not prepared to
handle bitmaps of size 0, this patch ensures that bitmap functions
are called only when SLICE_NUM_HIGH is not nul.Signed-off-by: Christophe Leroy
Reviewed-by: Nicholas Piggin
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit a3286f05bc5a5bc7fc73a9783ec89de78fcd07f8 upstream.
In preparation for the following patch which will enhance 'slices'
for supporting PPC32 in order to fix an issue on hugepages on 8xx,
this patch takes out of page*.h all bits related to 'slices' and put
them into newly created slice.h header files.
While common parts go into asm/slice.h, subarch specific
parts go into respective books3s/64/slice.c and nohash/64/slice.c
'slices'Signed-off-by: Christophe Leroy
Reviewed-by: Nicholas Piggin
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit 326691ad4f179e6edc7eb1271e618dd673e4736d upstream.
bitmap_or() and bitmap_andnot() can work properly with dst identical
to src1 or src2. There is no need of an intermediate result bitmap
that is copied back to dst in a second step.Signed-off-by: Christophe Leroy
Reviewed-by: Aneesh Kumar K.V
Reviewed-by: Nicholas Piggin
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit b3fb22733ae61050f8d10a1d6a8af176c5c5db1a upstream.
Radiant P845 does not have LVDS, only VGA.
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105468
Signed-off-by: Ondrej Zary
Signed-off-by: Ville Syrjälä
Link: https://patchwork.freedesktop.org/patch/msgid/20180309222204.4771-1-linux@rainbow-software.org
(cherry picked from commit 7f7105f99b75aca4f8c2a748ed6b82c7f8be3293)
Signed-off-by: Joonas Lahtinen
Signed-off-by: Greg Kroah-Hartman -
commit b9eb9c92899a509fe258d38dd6c214b1de69eee0 upstream.
Delay registering ourselves with the acpi lid notification mechanism
until we are registering the connectors after initialisation is
complete. This prevents a possibility of trying to handle the lid
notification before we are ready with the danger of chasing
uninitialised function pointers.BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
IP: (null)
PGD 0 P4D 0
Oops: 0010 [#1] PREEMPT SMP PTI
Modules linked in: arc4(+) iwldvm(+) i915(+) mac80211 i2c_algo_bit coretemp mei_wdt iwlwifi drm_kms_helper kvm_intel wmi_bmof iTCO_wdt iTCO_vendor_support kvm snd_hda_codec_conexant snd_hda_codec_generic drm psmouse cfg80211 irqbypass input_leds pcspkr i2c_i801 snd_hda_intel snd_hda_codec thinkpad_acpi snd_hda_core mei_me lpc_ich snd_hwdep e1000e wmi nvram snd_pcm mei snd_timer shpchp ptp pps_core rfkill syscopyarea snd intel_agp sysfillrect intel_gtt soundcore sysimgblt battery led_class fb_sys_fops ac rtc_cmos agpgart evdev mac_hid acpi_cpufreq ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto crypto_simd glue_helper cryptd aes_x86_64 xts algif_skcipher af_alg dm_crypt dm_mod sd_mod uas usb_storage serio_raw atkbd libps2 ahci libahci uhci_hcd libata scsi_mod ehci_pci
ehci_hcd usbcore usb_common i8042 serio
CPU: 1 PID: 378 Comm: systemd-logind Not tainted 4.16.8-1-ARCH #1
Hardware name: LENOVO 7454CTO/7454CTO, BIOS 6DET72WW (3.22 ) 10/25/2012
RIP: 0010: (null)
RSP: 0018:ffffaf4580c33a18 EFLAGS: 00010287
RAX: 0000000000000000 RBX: ffff947533558000 RCX: 000000000000003e
RDX: ffffffffc0aa80c0 RSI: ffffaf4580c33a3c RDI: ffff947534e4c000
RBP: ffff947533558338 R08: ffff947534598930 R09: ffffffffc0a928b1
R10: ffffd8f181d5fd40 R11: 0000000000000000 R12: ffffffffc0a928b1
R13: ffff947533558368 R14: ffffffffc0a928a9 R15: ffff947534e4c000
FS: 00007f3dc4ddb940(0000) GS:ffff947539280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000006e214000 CR4: 00000000000406e0
Call Trace:
? intel_modeset_setup_hw_state+0x385/0xf60 [i915]
? __intel_display_resume+0x1e/0xc0 [i915]
? intel_display_resume+0xcc/0x120 [i915]
? intel_lid_notify+0xbc/0xc0 [i915]
? notifier_call_chain+0x47/0x70
? blocking_notifier_call_chain+0x3e/0x60
? acpi_lid_notify_state+0x8f/0x1d0
? acpi_lid_update_state+0x49/0x70
? acpi_lid_input_open+0x60/0x90
? input_open_device+0x5d/0xa0
? evdev_open+0x1ba/0x1e0 [evdev]
? chrdev_open+0xa3/0x1b0
? cdev_put.part.0+0x20/0x20
? do_dentry_open+0x14c/0x300
? path_openat+0x30c/0x1240
? current_time+0x16/0x60
? do_filp_open+0x93/0x100
? __check_object_size+0xfb/0x180
? do_sys_open+0x186/0x210
? do_syscall_64+0x74/0x190
? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Code: Bad RIP value.
RIP: (null) RSP: ffffaf4580c33a18
CR2: 0000000000000000Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106559
Fixes: c1c7af608920 ("drm/i915: force mode set at lid open time")
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Daniel Vetter
Reviewed-by: Jani Nikula
Link: https://patchwork.freedesktop.org/patch/msgid/20180518074840.16194-1-chris@chris-wilson.co.uk
Cc: stable@vger.kernel.org
(cherry picked from commit e578a570dc7c20475774d1ff993825e3bd7a7011)
Signed-off-by: Joonas Lahtinen
Signed-off-by: Greg Kroah-Hartman -
commit bdcc02cf1bb508fc700df7662f55058f651f2621 upstream.
Entry corresponding to 220 us setup time was missing. I am not aware of
any specific bug this fixes, but this could potentially result in enabling
PSR on a panel with a higher setup time requirement than supported by the
hardware.I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a.
Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()")
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä
Cc: Jose Roberto de Souza
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: José Roberto de Souza
Reviewed-by: Tarun Vyas
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Jani Nikula
Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-3-dhinakaran.pandiyan@intel.com
Signed-off-by: Greg Kroah-Hartman -
commit 0ed2424b911f3a058dfea01b78817abed767433d upstream.
Commit d5c435df4a890 ("intel_th: msu: Use the real device in case of IOMMU
domain allocation") changes dma buffer allocation to use the actual
underlying device, but forgets to change the deallocation path, which leads
to (if you've got CAP_SYS_RAWIO):> # echo 0,0 > /sys/bus/intel_th/devices/0-msc0/nr_pages
> ------------[ cut here ]------------
> kernel BUG at ../linux/drivers/iommu/intel-iommu.c:3670!
> CPU: 3 PID: 231 Comm: sh Not tainted 4.17.0-rc1+ #2729
> RIP: 0010:intel_unmap+0x11e/0x130
...
> Call Trace:
> intel_free_coherent+0x3e/0x60
> msc_buffer_win_free+0x100/0x160 [intel_th_msu]This patch fixes the buffer deallocation code to use the correct device.
Signed-off-by: Alexander Shishkin
Fixes: d5c435df4a890 ("intel_th: msu: Use the real device in case of IOMMU domain allocation")
Reported-by: Baofeng Tian
CC: stable@vger.kernel.org # v4.14+
Signed-off-by: Greg Kroah-Hartman -
commit 52a192362932f333a7ebafd581c4d9b81da2fec8 upstream.
This reverts commit fb47ada8dc3c30c8e7b415da155742b49536c61e.
In some situations when we set TXOP_BACKOFF, the probe frame is
not sent at all. What it worse then sending probe frame as part
of AMPDU and can degrade 11n performance to 11g rates.Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit 2d077d4b59924acd1f5180c6fb73b57f4771fde6 upstream.
Swapping load on huge=always tmpfs (with khugepaged tuned up to be very
eager, but I'm not sure that is relevant) soon hung uninterruptibly,
waiting for page lock in shmem_getpage_gfp()'s find_lock_entry(), most
often when "cp -a" was trying to write to a smallish file. Debug showed
that the page in question was not locked, and page->mapping NULL by now,
but page->index consistent with having been in a huge page before.Reproduced in minutes on a 4.15 kernel, even with 4.17's 605ca5ede764
("mm/huge_memory.c: reorder operations in __split_huge_page_tail()") added
in; but took hours to reproduce on a 4.17 kernel (no idea why).The culprit proved to be the __ClearPageDirty() on tails beyond i_size in
__split_huge_page(): the non-atomic __bitoperation may have been safe when
4.8's baa355fd3314 ("thp: file pages support for split_huge_page()")
introduced it, but liable to erase PageWaiters after 4.10's 62906027091f
("mm: add PageWaiters indicating tasks are waiting for a page bit").Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1805291841070.3197@eggly.anvils
Fixes: 62906027091f ("mm: add PageWaiters indicating tasks are waiting for a page bit")
Signed-off-by: Hugh Dickins
Acked-by: Kirill A. Shutemov
Cc: Konstantin Khlebnikov
Cc: Nicholas Piggin
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit a840c93ca7582bb6c88df2345a33f979b7a67874 upstream.
When a GID entry is invalid EAGAIN is returned. This is an incorrect error
code, there is nothing that will make this GID entry valid again in
bounded time.Some user space tools fail incorrectly if EAGAIN is returned here, and
this represents a small ABI change from earlier kernels.The first patch in the Fixes list makes entries that were valid before
to become invalid, allowing this code to trigger, while the second patch
in the Fixes list introduced the wrong EAGAIN.Therefore revert the return result to EINVAL which matches the historical
expectations of the ibv_query_gid_type() API of the libibverbs user space
library.Cc:
Fixes: 598ff6bae689 ("IB/core: Refactor GID modify code for RoCE")
Fixes: 03db3a2d81e6 ("IB/core: Add RoCE GID table management")
Reviewed-by: Daniel Jurgens
Signed-off-by: Parav Pandit
Signed-off-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
Signed-off-by: Greg Kroah-Hartman -
commit 806e30873f0e74d9d41b0ef761bd4d3e55c7d510 upstream.
Commit b5e2ced9bf81 ("stm class: Use vmalloc for the master map") caused
a build error on some arches as vmalloc.h was not explicitly included.Fix that by adding it to the list of includes.
Fixes: b5e2ced9bf81 ("stm class: Use vmalloc for the master map")
Reported-by: kbuild test robot
Cc: Alexander Shishkin
Signed-off-by: Greg Kroah-Hartman -
commit b5e2ced9bf81393034072dd4d372f6b430bc1f0a upstream.
Fengguang is running into a warning from the buddy allocator:
> swapper/0: page allocation failure: order:9, mode:0x14040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.17.0-rc1 #262
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
> Call Trace:
...
> __kmalloc+0x14b/0x180: ____cache_alloc at mm/slab.c:3127
> stm_register_device+0xf3/0x5c0: stm_register_device at drivers/hwtracing/stm/core.c:695
...Which is basically a result of the stm class trying to allocate ~512kB
for the dummy_stm with its default parameters. There's no reason, however,
for it not to be vmalloc()ed instead, which is what this patch does.Reported-by: Fengguang Wu
Signed-off-by: Alexander Shishkin
CC: stable@vger.kernel.org # v4.4+
Signed-off-by: Greg Kroah-Hartman -
commit c9ddf73476ff4fffb7a87bd5107a0705bf2cf64b upstream.
Since an SRP remote port is attached as a child to shost->shost_gendev
and as the only child, the translation from the shost pointer into an
rport pointer must happen by looking up the shost child that is an
rport. This patch fixes the following KASAN complaint:BUG: KASAN: slab-out-of-bounds in srp_timed_out+0x57/0x110 [scsi_transport_srp]
Read of size 4 at addr ffff880035d3fcc0 by task kworker/1:0H/19CPU: 1 PID: 19 Comm: kworker/1:0H Not tainted 4.16.0-rc3-dbg+ #1
Workqueue: kblockd blk_mq_timeout_work
Call Trace:
dump_stack+0x85/0xc7
print_address_description+0x65/0x270
kasan_report+0x231/0x350
srp_timed_out+0x57/0x110 [scsi_transport_srp]
scsi_times_out+0xc7/0x3f0 [scsi_mod]
blk_mq_terminate_expired+0xc2/0x140
bt_iter+0xbc/0xd0
blk_mq_queue_tag_busy_iter+0x1c7/0x350
blk_mq_timeout_work+0x325/0x3f0
process_one_work+0x441/0xa50
worker_thread+0x76/0x6c0
kthread+0x1b2/0x1d0
ret_from_fork+0x24/0x30Fixes: e68ca75200fe ("scsi_transport_srp: Reduce failover time")
Signed-off-by: Bart Van Assche
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
Cc: Jason Gunthorpe
Cc: Doug Ledford
Cc: Laurence Oberman
Cc: stable@vger.kernel.org
Reviewed-by: Johannes Thumshirn
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman -
commit 28e4213dd331e944e7fca1954a946829162ed9d4 upstream.
Having PR_FP_MODE_FRE (i.e. Config5.FRE) set without PR_FP_MODE_FR (i.e.
Status.FR) is not supported as the lone purpose of Config5.FRE is to
emulate Status.FR=0 handling on FPU hardware that has Status.FR=1
hardwired[1][2]. Also we do not handle this case elsewhere, and assume
throughout our code that TIF_HYBRID_FPREGS and TIF_32BIT_FPREGS cannot
be set both at once for a task, leading to inconsistent behaviour if
this does happen.Return unsuccessfully then from prctl(2) PR_SET_FP_MODE calls requesting
PR_FP_MODE_FRE to be set with PR_FP_MODE_FR clear. This corresponds to
modes allowed by `mips_set_personality_fp'.References:
[1] "MIPS Architecture For Programmers, Vol. III: MIPS32 / microMIPS32
Privileged Resource Architecture", Imagination Technologies,
Document Number: MD00090, Revision 6.02, July 10, 2015, Table 9.69
"Config5 Register Field Descriptions", p. 262[2] "MIPS Architecture For Programmers, Volume III: MIPS64 / microMIPS64
Privileged Resource Architecture", Imagination Technologies,
Document Number: MD00091, Revision 6.03, December 22, 2015, Table
9.72 "Config5 Register Field Descriptions", p. 288Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Signed-off-by: Maciej W. Rozycki
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: # 4.0+
Patchwork: https://patchwork.linux-mips.org/patch/19327/
Signed-off-by: James Hogan
Signed-off-by: Greg Kroah-Hartman -
commit c7e814628df65f424fe197dde73bfc67e4a244d7 upstream.
Use 64-bit accesses for 64-bit floating-point general registers with
PTRACE_PEEKUSR, removing the truncation of their upper halves in the
FR=1 mode, caused by commit bbd426f542cb ("MIPS: Simplify FP context
access"), which inadvertently switched them to using 32-bit accesses.The PTRACE_POKEUSR side is fine as it's never been broken and continues
using 64-bit accesses.Fixes: bbd426f542cb ("MIPS: Simplify FP context access")
Signed-off-by: Maciej W. Rozycki
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/19334/
Signed-off-by: James Hogan
Signed-off-by: Greg Kroah-Hartman -
commit 32795631e67e16141aa5e065c28ba03bf17abb90 upstream.
While doing a global software reset, these bits are not cleared and let
some bootloader fail to initialise the GPHYs. The bootloader don't
expect the GPHYs in reset, as they aren't during power on.The asserts were a workaround for a wrong syscon-reboot mask. With a
mask set which includes the GPHY resets, these resets aren't required
any more.Fixes: 126534141b45 ("MIPS: lantiq: Add a GPHY driver which uses the RCU syscon-mfd")
Signed-off-by: Mathias Kresin
Acked-by: Martin Blumenstingl
Acked-by: Hauke Mehrtens
Cc: John Crispin
Cc: linux-mips@linux-mips.org
Cc: # 4.14+
Patchwork: https://patchwork.linux-mips.org/patch/19003/
[jhogan@kernel.org: Fix build warnings]
Signed-off-by: James Hogan
Signed-off-by: Greg Kroah-Hartman -
commit 76974ef9d1bf397b7bb97892a3b3bc516a1fc2c2 upstream.
We need to select the buffer code, otherwise we get build errors
with undefined functions on the trigger and buffer,
if we select just IIO and then AT91_SAMA5D2_ADC from menuconfigThis adds a Kconfig 'select' statement like other ADC
drivers have it already.Fixes: 5e1a1da0f8c9 ("iio: adc: at91-sama5d2_adc: add hw trigger and buffer support")
Signed-off-by: Eugen Hristev
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 3d13de4b027d5f6276c0f9d3a264f518747d83f2 upstream.
Currently, the following causes a kernel OOPS in memcpy:
echo 1073741825 > buffer/length
echo 1 > buffer/enableNote that using 1073741824 instead of 1073741825 causes "write error:
Cannot allocate memory" but no OOPS.This is because 1073741824 == 2^30 and 1073741825 == 2^30+1. Since kfifo
rounds up to the nearest power of 2, it will actually call kmalloc with
roundup_pow_of_two(length) * bytes_per_datum.Using length == 1073741825 and bytes_per_datum == 2, we get:
kmalloc(roundup_pow_of_two(1073741825) * 2
or kmalloc(2147483648 * 2)
or kmalloc(4294967296)
or kmalloc(UINT_MAX + 1)so this overflows to 0, causing kmalloc to return ZERO_SIZE_PTR and
subsequent memcpy to fail once the device is enabled.Fix this by checking for overflow prior to allocating a kfifo. With this
check added, the above code returns -EINVAL when enabling the buffer,
rather than causing an OOPS.Signed-off-by: Martin Kelly
cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit c043ec1ca5baae63726aae32abbe003192bc6eec upstream.
Currently, we use int for buffer length and bytes_per_datum. However,
kfifo uses unsigned int for length and size_t for element size. We need
to make sure these matches or we will have bugs related to overflow (in
the range between INT_MAX and UINT_MAX for length, for example).In addition, set_bytes_per_datum uses size_t while bytes_per_datum is an
int, which would cause bugs for large values of bytes_per_datum.Change buffer length to use unsigned int and bytes_per_datum to use
size_t.Signed-off-by: Martin Kelly
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 490fba90a90eb7b741f57fefd2bcf2c1e11eb471 upstream.
This commit is a follow-up to changes made to ad_sigma_delta.h
in staging: iio: ad7192: implement IIO_CHAN_INFO_SAMP_FREQ
which broke ad7793 as it was not altered to match those changes.This driver predates the availability of IIO_CHAN_INFO_SAMP_FREQ
attribute wherein usage has some advantages like it can be accessed by
in-kernel consumers as well as reduces the code size.Therefore, use IIO_CHAN_INFO_SAMP_FREQ to implement the
sampling_frequency attribute instead of using IIO_DEV_ATTR_SAMP_FREQ()
macro.Move code from the functions associated with IIO_DEV_ATTR_SAMP_FREQ()
into respective read and write hooks with the mask set to
IIO_CHAN_INFO_SAMP_FREQ.Fixes: a13e831fcaa7 ("staging: iio: ad7192: implement IIO_CHAN_INFO_SAMP_FREQ")
Signed-off-by: Michael Nosthoff
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 607065bad9931e72207b0cac365d7d4abc06bd99 upstream.
When using large tcp_rmem[2] values (I did tests with 500 MB),
I noticed overflows while computing rcvwin.Lets fix this before the following patch.
Signed-off-by: Eric Dumazet
Acked-by: Soheil Hassas Yeganeh
Acked-by: Wei Wang
Acked-by: Neal Cardwell
Signed-off-by: David S. Miller
[Backport: sysctl_tcp_rmem is not Namespace-ify'd in older kernels]
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 0a5f41767444cc3b4fc5573921ab914b4f78baaa upstream.
Currently, GCC disables -Wunused-const-variable, but not
-Wunused-variable, so warns unused variables if they are
non-constant.While, Clang does not warn unused variables at all regardless of
the const qualifier because -Wno-unused-const-variable is implied
by the stronger option -Wno-unused-variable.Disable -Wunused-const-variable instead of -Wunused-variable so that
GCC and Clang work in the same way.Signed-off-by: Prasad Sodagudi
Signed-off-by: Masahiro Yamada
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit d3b56c566d4ba8cae688baf3cca94425d57ea783 upstream.
Pointer request is being assigned but never used, so remove it. Cleans
up the clang warning:drivers/platform/chrome/cros_ec_lpc.c:68:2: warning: Value stored to
'request' is never readSigned-off-by: Colin Ian King
Signed-off-by: Benson Leung
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 271ef65b5882425d500e969e875c98e47a6b0c86 upstream.
The pointer dma_dev_name is assigned but never read, it is redundant
and can therefore be removed.Cleans up clang warning:
sound/soc/intel/common/sst-firmware.c:288:3: warning: Value stored to
'dma_dev_name' is never readSigned-off-by: Colin Ian King
Acked-by: Pierre-Louis Bossart
Signed-off-by: Mark Brown
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit fb239c1209bb0f0b4830cc72507cc2f2d63fadbd upstream.
In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal
is assigned to itself in an if ... else statement, apparently only to
document that the branch condition is handled and that a previously read
value should be returned unmodified. The self-assignment causes clang to
raise the following warning:drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13:
error: explicitly assigning value of variable of type 'u32'
(aka 'unsigned int') to itself [-Werror,-Wself-assign]
writeVal = writeVal;Delete the branch with the self-assignment.
Signed-off-by: Matthias Kaehlcke
Acked-by: Larry Finger
Reviewed-by: Guenter Roeck
Signed-off-by: Kalle Valo
Signed-off-by: Greg Kroah-Hartman -
commit 42b5122e828a6ccd9952ad3116343dc032d33efe upstream.
In several locations the driver uses AMD_CG_STATE_UNGATE (type enum
amd_clockgating_state) instead of AMD_PG_STATE_UNGATE (type enum
amd_powergating_stat) and vice versa. Both constants have the same
value, so this doesn't cause any problems, but we still want to pass
the correct type.Fixing the mismatch resolves multiple warnings like this when building
with clang:drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_clockpowergating.c:169:7:
error: implicit conversion from enumeration type 'enum
amd_powergating_state' to different enumeration type 'enum
amd_clockgating_state' [-Werror,-Wenum-conversion]
AMD_PG_STATE_UNGATE);Reviewed-by: Guenter Roeck
Signed-off-by: Matthias Kaehlcke
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 531beb067c6185aceabfdee0965234c6a8fd133b upstream.
sg_table is being initialized and is never read before it is updated
again later on, hence making the initialization redundant. Remove
the initialization.Detected by clang scan-build:
"warning: Value stored to 'sg_table' during its initialization is
never read"Signed-off-by: Colin Ian King
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
Link: https://patchwork.freedesktop.org/patch/msgid/20170914230516.6056-1-colin.king@canonical.com
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit cad9946c2a4375386062131858881cfd30fc1b8f upstream.
When we do a locked idle we know that afterwards all requests have been
completed and the engines have been cleared of tasks. For whatever
reason, this doesn't always happen and we may go into a suspend with
ELSP still full, and this causes an issue upon resume as we get very,
very confused.If the engines refuse to idle, mark the device as wedged. In the process
we get rid of the maybe unused open-coded version of wait_for_engines
reported by Nick Desaulniers and Matthias Kaehlcke.v2: Suppress the -EIO before suspend, but keep it for seqno wrap.
References: https://bugs.freedesktop.org/show_bug.cgi?id=101891
References: https://bugs.freedesktop.org/show_bug.cgi?id=102456
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Cc: Matthias Kaehlcke
Link: https://patchwork.freedesktop.org/patch/msgid/20170826110935.10237-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen
Reviewed-by: Mika Kuoppala
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit df16aaac26e92e97ab7234d3f93c953466adc4b5 upstream.
When compiling with `make CC=clang HOSTCC=clang`, I was seeing warnings
that clang did not recognize -fno-delete-null-pointer-checks for HOSTCC
targets. These were added in commit 61163efae020 ("kbuild: LLVMLinux:
Add Kbuild support for building kernel with Clang").Clang does not support -fno-delete-null-pointer-checks, so adding it to
HOSTCFLAGS if HOSTCC is clang does not make sense.It's not clear why the other warnings were disabled, and just for
HOSTCFLAGS, but I can remove them, add -Werror to HOSTCFLAGS and compile
with clang just fine.Suggested-by: Masahiro Yamada
Signed-off-by: Nick Desaulniers
Signed-off-by: Masahiro Yamada
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 814596495dd2b9d4aab92d8f89cf19060d25d2ea upstream.
wiphy names were recently limited to 128 bytes by commit a7cfebcb7594
("cfg80211: limit wiphy names to 128 bytes"). As it turns out though,
this isn't sufficient because dev_vprintk_emit() needs the syslog header
string "SUBSYSTEM=ieee80211\0DEVICE=+ieee80211:$devname" to fit into 128
bytes. This triggered the "device/subsystem name too long" WARN when
the device name was >= 90 bytes. As before, this was reproduced by
syzbot by sending an HWSIM_CMD_NEW_RADIO command to the MAC80211_HWSIM
generic netlink family.Fix it by further limiting wiphy names to 64 bytes.
Reported-by: syzbot+e64565577af34b3768dc@syzkaller.appspotmail.com
Fixes: a7cfebcb7594 ("cfg80211: limit wiphy names to 128 bytes")
Signed-off-by: Eric Biggers
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman -
commit efe3de79e0b52ca281ef6691480c8c68c82a4657 upstream.
Call trace:
[] dump_backtrace+0x0/0x428
[] show_stack+0x28/0x38
[] dump_stack+0xd4/0x124
[] print_address_description+0x68/0x258
[] kasan_report.part.2+0x228/0x2f0
[] kasan_report+0x5c/0x70
[] check_memory_region+0x12c/0x1c0
[] memcpy+0x34/0x68
[] xattr_getsecurity+0xe0/0x160
[] vfs_getxattr+0xc8/0x120
[] getxattr+0x100/0x2c8
[] SyS_fgetxattr+0x64/0xa0
[] el0_svc_naked+0x24/0x28If user get root access and calls security.selinux setxattr() with an
embedded NUL on a file and then if some process performs a getxattr()
on that file with a length greater than the actual length of the string,
it would result in a panic.To fix this, add the actual length of the string to the security context
instead of the length passed by the userspace process.Signed-off-by: Sachin Grover
Cc: stable@vger.kernel.org
Signed-off-by: Paul Moore
Signed-off-by: Greg Kroah-Hartman -
commit 2824f5033248600673e3e126a4d135363cbfd9ac upstream.
The snapshot trigger currently only affects the main ring buffer, even when
it is used by the instances. This can be confusing as the snapshot trigger
is listed in the instance.> # cd /sys/kernel/tracing
> # mkdir instances/foo
> # echo snapshot > instances/foo/events/syscalls/sys_enter_fchownat/trigger
> # echo top buffer > trace_marker
> # echo foo buffer > instances/foo/trace_marker
> # touch /tmp/bar
> # chown rostedt /tmp/bar
> # cat instances/foo/snapshot
# tracer: nop
#
#
# * Snapshot is freed *
#
# Snapshot commands:
# echo 0 > snapshot : Clears and frees snapshot buffer
# echo 1 > snapshot : Allocates snapshot buffer, if not already allocated.
# Takes a snapshot of the main buffer.
# echo 2 > snapshot : Clears snapshot buffer (but does not allocate or free)
# (Doesn't have to be '2' works with any number that
# is not a '0' or '1')> # cat snapshot
# tracer: nop
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
bash-1189 [000] .... 111.488323: tracing_mark_write: top bufferNot only did the snapshot occur in the top level buffer, but the instance
snapshot buffer should have been allocated, and it is still free.Cc: stable@vger.kernel.org
Fixes: 85f2b08268c01 ("tracing: Add basic event trigger framework")
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Greg Kroah-Hartman
