- 14 Aug, 2018 37 commits
-
-
Hugh Dickins authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 145e1a71 upstream. George Boole would have noticed a slight error in 4.16 commit 69d763fc ("mm: pin address_space before dereferencing it while isolating an LRU page"). Fix it, to match both the comment above it, and the original behaviour. Although anonymous pages are not marked PageDirty at first, we have an old habit of calling SetPageDirty when a page is removed from swap cache: so there's a category of ex-swap pages that are easily migratable, but were inadvertently excluded from compaction's async migration in 4.16. Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1805302014001.12558@eggly.anvils Fixes: 69d763fc ("mm: pin address_space before dereferencing it while isolating an LRU page") Signed-off-by:
Hugh Dickins <hughd@google.com> Acked-by:
Minchan Kim <minchan@kernel.org> Acked-by:
Mel Gorman <mgorman@techsingularity.net> Reported-by:
Ivan Kalvachev <ikalvachev@gmail.com> Cc: "Huang, Ying" <ying.huang@intel.com> Cc: Jan Kara <jack@suse.cz> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Al Viro authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 4faa9996 upstream. If io_destroy() gets to cancelling everything that can be cancelled and gets to kiocb_cancel() calling the function driver has left in ->ki_cancel, it becomes vulnerable to a race with IO completion. At that point req is already taken off the list and aio_complete() does *NOT* spin until we (in free_ioctx_users()) releases ->ctx_lock. As the result, it proceeds to kiocb_free(), freing req just it gets passed to ->ki_cancel(). Fix is simple - remove from the list after the call of kiocb_cancel(). All instances of ->ki_cancel() already have to cope with the being called with iocb still on list - that's what happens in io_cancel(2). Cc: stable@kernel.org Fixes: 0460fef2 "aio: use cancellation list lazily" Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1776177 Commit "Kbuild: change CC_OPTIMIZE_FOR_SIZE definition" adds a new config option CC_OPTIMIZE_FOR_PERFORMANCE, so update the config files accordingly. Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 877417e6 upstream. CC_OPTIMIZE_FOR_SIZE disables the often useful -Wmaybe-unused warning, because that causes a ridiculous amount of false positives when combined with -Os. This means a lot of warnings don't show up in testing by the developers that should see them with an 'allmodconfig' kernel that has CC_OPTIMIZE_FOR_SIZE enabled, but only later in randconfig builds that don't. This changes the Kconfig logic around CC_OPTIMIZE_FOR_SIZE to make it a 'choice' statement defaulting to CC_OPTIMIZE_FOR_PERFORMANCE that gets added for this purpose. The allmodconfig and allyesconfig kernels now default to -O2 with the maybe-unused warning enabled. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Michal Marek <mmarek@suse.com> Cc: Nathan Chancellor <natechancellor@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Ondrej Zary authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit b3fb2273 upstream. Radiant P845 does not have LVDS, only VGA. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105468Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180309222204.4771-1-linux@rainbow-software.org (cherry picked from commit 7f7105f9) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 806e3087 upstream. Commit b5e2ced9 ("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: b5e2ced9 ("stm class: Use vmalloc for the master map") Reported-by:
kbuild test robot <lkp@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit b5e2ced9 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 <fengguang.wu@intel.com> Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> CC: stable@vger.kernel.org # v4.4+ Signed-off-by:
-
Bart Van Assche authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit c9ddf734 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/19 CPU: 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/0x30 Fixes: e68ca752 ("scsi_transport_srp: Reduce failover time") Signed-off-by:
Bart Van Assche <bart.vanassche@wdc.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Johannes Thumshirn <jthumshirn@suse.de> Cc: Jason Gunthorpe <jgg@mellanox.com> Cc: Doug Ledford <dledford@redhat.com> Cc: Laurence Oberman <loberman@redhat.com> Cc: stable@vger.kernel.org Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Maciej W. Rozycki authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 28e4213d 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. 288 Fixes: 9791554b ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS") Signed-off-by:
Maciej W. Rozycki <macro@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 4.0+ Patchwork: https://patchwork.linux-mips.org/patch/19327/Signed-off-by:
James Hogan <jhogan@kernel.org> Signed-off-by:
-
Maciej W. Rozycki authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit c7e81462 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 bbd426f5 ("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: bbd426f5 ("MIPS: Simplify FP context access") Signed-off-by:
-
Martin Kelly authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 3d13de4b upstream. Currently, the following causes a kernel OOPS in memcpy: echo 1073741825 > buffer/length echo 1 > buffer/enable Note 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 <mkelly@xevo.com> cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Yoshihiro Shimoda authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit d9f5efad upstream. This patch fixes an issue that list_for_each_entry() in usb_dmac_chan_terminate_all() is possible to cause endless loop because this will move own desc to the desc_freed. So, this driver should use list_for_each_entry_safe() instead of list_for_each_entry(). Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
Biju Das <biju.das@bp.renesas.com> Signed-off-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 52df445f upstream. If we don't clear START generation as soon as possible, it may cause another message to be generated, e.g. when receiving NACK in address phase. To keep the race window as small as possible, we clear it right at the beginning of the interrupt. We don't need any checks since we always want to stop START and STOP generation on the next occasion after we started it. This patch improves the situation but sadly does not completely fix it. It is still to be researched if we can do better given this HW design. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit c3be0af1 upstream. Due to the HW design, master IRQs are timing critical, so give them precedence over slave IRQ. Signed-off-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit d89667b1 upstream. The manual says (55.4.8.6) that HW does automatically send STOP after NACK was received. My measuerments confirm that. Signed-off-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit cc21d0b4 upstream. Setting up new messages was done in process context while handling a message was in interrupt context. Because of the HW design, this IP core is sensitive to timing, so the context switches were too expensive. Move this setup to interrupt context as well. In my test setup, this fixed the occasional 'data byte sent twice' issue which a number of people have seen. It also fixes to send REP_START after a read message which was wrongly send as a STOP + START sequence before. Signed-off-by:
Chris Paterson <Chris.Paterson2@renesas.com> Signed-off-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit b9d0684c upstream. We want to reuse this function later. Signed-off-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit ff2316b8 upstream. After making sure to reinit the HW and clear interrupts in the timeout case, we know that interrupts are always disabled in the sections protected by the spinlock. Thus, we can simply remove it which is a preparation for further refactoring. While here, rename the timeout variable to time_left which is way more readable. Signed-off-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 90f779e5 upstream. Signed-off-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 2c78cdc1 upstream. We don't need to init HW before every transfer since we know the HW state then. HW init at probe time is enough. While here, add setting the clock register which belongs to init HW. Also, set MDBS bit since not setting it is prohibited according to the manual. Signed-off-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit e43e0df1 upstream. When calculating the bus speed, the clock should be on, of course. Most bootloaders left them on, so this went unnoticed so far. Move the ioremapping out of this clock-enabled-block and prepare for adding hw initialization there, too. Reported-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 607065ba 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 <edumazet@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Acked-by:
Wei Wang <weiwan@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> [Backport: sysctl_tcp_rmem is not Namespace-ify'd in older kernels] Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit c9bd2823 upstream. irda_get_mtt() returns a hardcoded '10000' in some cases, and with gcc-7, we get a build error because this triggers a compile-time check in udelay(): drivers/net/irda/w83977af_ir.o: In function `w83977af_hard_xmit': w83977af_ir.c:(.text.w83977af_hard_xmit+0x14c): undefined reference to `__bad_udelay' Older compilers did not run into this because they either did not completely inline the irda_get_mtt() or did not consider the 10000 value a constant expression. The code has been wrong since the start of git history. Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 271ef65b 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 read Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Matthias Kaehlcke authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit fb239c12 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 <mka@chromium.org> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Eric Biggers authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 81459649 upstream. wiphy names were recently limited to 128 bytes by commit a7cfebcb ("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: a7cfebcb ("cfg80211: limit wiphy names to 128 bytes") Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Sachin Grover authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit efe3de79 upstream. Call trace: [<ffffff9203a8d7a8>] dump_backtrace+0x0/0x428 [<ffffff9203a8dbf8>] show_stack+0x28/0x38 [<ffffff920409bfb8>] dump_stack+0xd4/0x124 [<ffffff9203d187e8>] print_address_description+0x68/0x258 [<ffffff9203d18c00>] kasan_report.part.2+0x228/0x2f0 [<ffffff9203d1927c>] kasan_report+0x5c/0x70 [<ffffff9203d1776c>] check_memory_region+0x12c/0x1c0 [<ffffff9203d17cdc>] memcpy+0x34/0x68 [<ffffff9203d75348>] xattr_getsecurity+0xe0/0x160 [<ffffff9203d75490>] vfs_getxattr+0xc8/0x120 [<ffffff9203d75d68>] getxattr+0x100/0x2c8 [<ffffff9203d76fb4>] SyS_fgetxattr+0x64/0xa0 [<ffffff9203a83f70>] el0_svc_naked+0x24/0x28 If 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 <sgrover@codeaurora.org> Cc: stable@vger.kernel.org Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Steven Rostedt (VMware) authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 86b389ff upstream. If a instance has an event trigger enabled when it is freed, it could cause an access of free memory. Here's the case that crashes: # cd /sys/kernel/tracing # mkdir instances/foo # echo snapshot > instances/foo/events/initcall/initcall_start/trigger # rmdir instances/foo Would produce: general protection fault: 0000 [#1] PREEMPT SMP PTI Modules linked in: tun bridge ... CPU: 5 PID: 6203 Comm: rmdir Tainted: G W 4.17.0-rc4-test+ #933 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:clear_event_triggers+0x3b/0x70 RSP: 0018:ffffc90003783de0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b2b RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800c7130ba0 RBP: ffffc90003783e00 R08: ffff8801131993f8 R09: 0000000100230016 R10: ffffc90003783d80 R11: 0000000000000000 R12: ffff8800c7130ba0 R13: ffff8800c7130bd8 R14: ffff8800cc093768 R15: 00000000ffffff9c FS: 00007f6f4aa86700(0000) GS:ffff88011eb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6f4a5aed60 CR3: 00000000cd552001 CR4: 00000000001606e0 Call Trace: event_trace_del_tracer+0x2a/0xc5 instance_rmdir+0x15c/0x200 tracefs_syscall_rmdir+0x52/0x90 vfs_rmdir+0xdb/0x160 do_rmdir+0x16d/0x1c0 __x64_sys_rmdir+0x17/0x20 do_syscall_64+0x55/0x1a0 entry_SYSCALL_64_after_hwframe+0x49/0xbe This was due to the call the clears out the triggers when an instance is being deleted not removing the trigger from the link list. Cc: stable@vger.kernel.org Fixes: 85f2b082 ("tracing: Add basic event trigger framework") Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Benjamin Tissoires authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 40f7090b upstream. New ICs (like the one on the Lenovo T480s) answer to ETP_SMBUS_IAP_VERSION_CMD 4 bytes instead of 3. This corrupts the stack as i2c_smbus_read_block_data() uses the values returned by the i2c device to know how many data it need to return. i2c_smbus_read_block_data() can read up to 32 bytes (I2C_SMBUS_BLOCK_MAX) and there is no safeguard on how many bytes are provided in the return value. Ensure we always have enough space for any future firmware. Also 0-initialize the values to prevent any access to uninitialized memory. Cc: <stable@vger.kernel.org> # v4.4.x, v4.9.x, v4.14.x, v4.15.x, v4.16.x Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
KT Liao <kt.liao@emc.com.tw> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Brian Foster authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit a27ba260 upstream. The struct xfs_agfl v5 header was originally introduced with unexpected padding that caused the AGFL to operate with one less slot than intended. The header has since been packed, but the fix left an incompatibility for users who upgrade from an old kernel with the unpacked header to a newer kernel with the packed header while the AGFL happens to wrap around the end. The newer kernel recognizes one extra slot at the physical end of the AGFL that the previous kernel did not. The new kernel will eventually attempt to allocate a block from that slot, which contains invalid data, and cause a crash. This condition can be detected by comparing the active range of the AGFL to the count. While this detects a padding mismatch, it can also trigger false positives for unrelated flcount corruption. Since we cannot distinguish a size mismatch due to padding from unrelated corruption, we can't trust the AGFL enough to simply repopulate the empty slot. Instead, avoid unnecessarily complex detection logic and and use a solution that can handle any form of flcount corruption that slips through read verifiers: distrust the entire AGFL and reset it to an empty state. Any valid blocks within the AGFL are intentionally leaked. This requires xfs_repair to rectify (which was already necessary based on the state the AGFL was found in). The reset mitigates the side effect of the padding mismatch problem from a filesystem crash to a free space accounting inconsistency. The generic approach also means that this patch can be safely backported to kernels with or without a packed struct xfs_agfl. Check the AGF for an invalid freelist count on initial read from disk. If detected, set a flag on the xfs_perag to indicate that a reset is required before the AGFL can be used. In the first transaction that attempts to use a flagged AGFL, reset it to empty, warn the user about the inconsistency and allow the freelist fixup code to repopulate the AGFL with new blocks. The xfs_perag flag is cleared to eliminate the need for repeated checks on each block allocation operation. This allows kernels that include the packing fix commit 96f859d5 ("libxfs: pack the agfl header structure so XFS_AGFL_SIZE is correct") to handle older unpacked AGFL formats without a filesystem crash. Suggested-by:
Dave Chinner <david@fromorbit.com> Signed-off-by:
Brian Foster <bfoster@redhat.com> Reviewed-by:
Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by Dave Chiluk <chiluk+linuxxfs@indeed.com> Signed-off-by:
Dave Chiluk <chiluk+linuxxfs@indeed.com> Signed-off-by:
-
Yoshinori Sato authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 940d4113 upstream. New gcc (4.8 or later) used new shift helper functions. So we need added new helper to private libgcc. Signed-off-by:
Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by:
Rich Felker <dalias@libc.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Geert Uytterhoeven authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 009615ab upstream. On sparc32, tcflag_t is unsigned long, unlike all other architectures: drivers/usb/serial/cp210x.c: In function 'cp210x_get_termios': drivers/usb/serial/cp210x.c:717:3: warning: passing argument 2 of 'cp210x_get_termios_port' from incompatible pointer type cp210x_get_termios_port(tty->driver_data, ^ drivers/usb/serial/cp210x.c:35:13: note: expected 'unsigned int *' but argument is of type 'tcflag_t *' static void cp210x_get_termios_port(struct usb_serial_port *port, ^ Consistently use tcflag_t to fix this. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Michael Neuling authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit faf37c44 upstream. Clear the PCR (Processor Compatibility Register) on boot to ensure we are not running in a compatibility mode. We've seen this cause problems when a crash (and kdump) occurs while running compat mode guests. The kdump kernel then runs with the PCR set and causes problems. The symptom in the kdump kernel (also seen in petitboot after fast-reboot) is early userspace programs taking sigills on newer instructions (seen in libc). Signed-off-by:
Michael Neuling <mikey@neuling.org> Cc: stable@vger.kernel.org Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Will Deacon authored
BugLink: https://bugs.launchpad.net/bugs/1776177 commit 32c3fa7c upstream. For LSE atomics that read and write a register operand, we need to ensure that these operands are annotated as "early clobber" if the register is written before all of the input operands have been consumed. Failure to do so can result in the compiler allocating the same register to both operands, leading to splats such as: Unable to handle kernel paging request at virtual address 11111122222221 [...] x1 : 1111111122222222 x0 : 1111111122222221 Process swapper/0 (pid: 1, stack limit = 0x000000008209f908) Call trace: test_atomic64+0x1360/0x155c where x0 has been allocated as both the value to be stored and also the atomic_t pointer. This patch adds the missing clobbers. Cc: <stable@vger.kernel.org> Cc: Dave Martin <dave.martin@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Reported-by:
Mark Salter <msalter@redhat.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1776158Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1776158 This reverts commit 33cebc97 which is 03080e5e ("vti4: Don't override MTU passed on link creation via IFLA_MTU") upstream as it causes test failures. This commit should not have been backported to anything older than 4.16, despite what the changelog said as the mtu must be set in older kernels, unlike is needed in 4.16 and newer. Thanks to Alistair Strachan for the debugging help figuring this out, and for 'git bisect' for making my life a whole lot easier. Cc: Alistair Strachan <astrachan@google.com> Cc: Stefano Brivio <sbrivio@redhat.com> Cc: Sabrina Dubroca <sd@queasysnail.net> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by:Stefan Bader <stefan.bader@canonical.com>
-
- 09 Aug, 2018 3 commits
-
-
Stefan Bader authored
Signed-off-by: -
Eric Dumazet authored
In case an attacker feeds tiny packets completely out of order, tcp_collapse_ofo_queue() might scan the whole rb-tree, performing expensive copies, but not changing socket memory usage at all. 1) Do not attempt to collapse tiny skbs. 2) Add logic to exit early when too many tiny skbs are detected. We prefer not doing aggressive collapsing (which copies packets) for pathological flows, and revert to tcp_prune_ofo_queue() which will be less expensive. In the future, we might add the possibility of terminating flows that are proven to be malicious. Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
-
Eric Dumazet authored
Right after a TCP flow is created, receiving tiny out of order packets allways hit the condition : if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf) tcp_clamp_window(sk); tcp_clamp_window() increases sk_rcvbuf to match sk_rmem_alloc (guarded by tcp_rmem[2]) Calling tcp_collapse_ofo_queue() in this case is not useful, and offers a O(N^2) surface attack to malicious peers. Better not attempt anything before full queue capacity is reached, forcing attacker to spend lots of resource and allow us to more easily detect the abuse. Signed-off-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
-
