- 11 Aug, 2017 40 commits
-
-
Levin, Alexander authored
[ Upstream commit 98de4e0e ] ifr name is assumed to be a valid string by the kernel, but nothing was forcing username to pass a valid string. In turn, this would cause panics as we tried to access the string past it's valid memory. Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alexander Potapenko authored
[ Upstream commit 18bcf290 ] KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(), which originated from the TCP request socket created in cookie_v6_check(): ================================================================== BUG: KMSAN: use of uninitialized memory in tcp_transmit_skb+0xf77/0x3ec0 CPU: 1 PID: 2949 Comm: syz-execprog Not tainted 4.11.0-rc5+ #2931 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 TCP: request_sock_TCPv6: Possible SYN flooding on port 20028. Sending cookies. Check SNMP counters. Call Trace: <IRQ> __dump_stack lib/dump_stack.c:16 dump_stack+0x172/0x1c0 lib/dump_stack.c:52 kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:927 __msan_warning_32+0x61/0xb0 mm/kmsan/kmsan_instr.c:469 skb_set_hash_from_sk ./include/net/sock.h:2011 tcp_transmit_skb+0xf77/0x3ec0 net/ipv4/tcp_output.c:983 tcp_send_ack+0x75b/0x830 net/ipv4/tcp_output.c:3493 tcp_delack_timer_handler+0x9a6/0xb90 net/ipv4/tcp_timer.c:284 tcp_delack_timer+0x1b0/0x310 net/ipv4/tcp_timer.c:309 call_timer_fn+0x240/0x520 kernel/time/timer.c:1268 expire_timers kernel/time/timer.c:1307 __run_timers+0xc13/0xf10 kernel/time/timer.c:1601 run_timer_softirq+0x36/0xa0 kernel/time/timer.c:1614 __do_softirq+0x485/0x942 kernel/softirq.c:284 invoke_softirq kernel/softirq.c:364 irq_exit+0x1fa/0x230 kernel/softirq.c:405 exiting_irq+0xe/0x10 ./arch/x86/include/asm/apic.h:657 smp_apic_timer_interrupt+0x5a/0x80 arch/x86/kernel/apic/apic.c:966 apic_timer_interrupt+0x86/0x90 arch/x86/entry/entry_64.S:489 RIP: 0010:native_restore_fl ./arch/x86/include/asm/irqflags.h:36 RIP: 0010:arch_local_irq_restore ./arch/x86/include/asm/irqflags.h:77 RIP: 0010:__msan_poison_alloca+0xed/0x120 mm/kmsan/kmsan_instr.c:440 RSP: 0018:ffff880024917cd8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10 RAX: 0000000000000246 RBX: ffff8800224c0000 RCX: 0000000000000005 RDX: 0000000000000004 RSI: ffff880000000000 RDI: ffffea0000b6d770 RBP: ffff880024917d58 R08: 0000000000000dd8 R09: 0000000000000004 R10: 0000160000000000 R11: 0000000000000000 R12: ffffffff85abf810 R13: ffff880024917dd8 R14: 0000000000000010 R15: ffffffff81cabde4 </IRQ> poll_select_copy_remaining+0xac/0x6b0 fs/select.c:293 SYSC_select+0x4b4/0x4e0 fs/select.c:653 SyS_select+0x76/0xa0 fs/select.c:634 entry_SYSCALL_64_fastpath+0x13/0x94 arch/x86/entry/entry_64.S:204 RIP: 0033:0x4597e7 RSP: 002b:000000c420037ee0 EFLAGS: 00000246 ORIG_RAX: 0000000000000017 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004597e7 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 000000c420037ef0 R08: 000000c420037ee0 R09: 0000000000000059 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000042dc20 R13: 00000000000000f3 R14: 0000000000000030 R15: 0000000000000003 chained origin: save_stack_trace+0x37/0x40 arch/x86/kernel/stacktrace.c:59 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:302 kmsan_save_stack mm/kmsan/kmsan.c:317 kmsan_internal_chain_origin+0x12a/0x1f0 mm/kmsan/kmsan.c:547 __msan_store_shadow_origin_4+0xac/0x110 mm/kmsan/kmsan_instr.c:259 tcp_create_openreq_child+0x709/0x1ae0 net/ipv4/tcp_minisocks.c:472 tcp_v6_syn_recv_sock+0x7eb/0x2a30 net/ipv6/tcp_ipv6.c:1103 tcp_get_cookie_sock+0x136/0x5f0 net/ipv4/syncookies.c:212 cookie_v6_check+0x17a9/0x1b50 net/ipv6/syncookies.c:245 tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:989 tcp_v6_do_rcv+0xdd8/0x1c60 net/ipv6/tcp_ipv6.c:1298 tcp_v6_rcv+0x41a3/0x4f00 net/ipv6/tcp_ipv6.c:1487 ip6_input_finish+0x82f/0x1ee0 net/ipv6/ip6_input.c:279 NF_HOOK ./include/linux/netfilter.h:257 ip6_input+0x239/0x290 net/ipv6/ip6_input.c:322 dst_input ./include/net/dst.h:492 ip6_rcv_finish net/ipv6/ip6_input.c:69 NF_HOOK ./include/linux/netfilter.h:257 ipv6_rcv+0x1dbd/0x22e0 net/ipv6/ip6_input.c:203 __netif_receive_skb_core+0x2f6f/0x3a20 net/core/dev.c:4208 __netif_receive_skb net/core/dev.c:4246 process_backlog+0x667/0xba0 net/core/dev.c:4866 napi_poll net/core/dev.c:5268 net_rx_action+0xc95/0x1590 net/core/dev.c:5333 __do_softirq+0x485/0x942 kernel/softirq.c:284 origin: save_stack_trace+0x37/0x40 arch/x86/kernel/stacktrace.c:59 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:302 kmsan_internal_poison_shadow+0xb1/0x1a0 mm/kmsan/kmsan.c:198 kmsan_kmalloc+0x7f/0xe0 mm/kmsan/kmsan.c:337 kmem_cache_alloc+0x1c2/0x1e0 mm/slub.c:2766 reqsk_alloc ./include/net/request_sock.h:87 inet_reqsk_alloc+0xa4/0x5b0 net/ipv4/tcp_input.c:6200 cookie_v6_check+0x4f4/0x1b50 net/ipv6/syncookies.c:169 tcp_v6_cookie_check net/ipv6/tcp_ipv6.c:989 tcp_v6_do_rcv+0xdd8/0x1c60 net/ipv6/tcp_ipv6.c:1298 tcp_v6_rcv+0x41a3/0x4f00 net/ipv6/tcp_ipv6.c:1487 ip6_input_finish+0x82f/0x1ee0 net/ipv6/ip6_input.c:279 NF_HOOK ./include/linux/netfilter.h:257 ip6_input+0x239/0x290 net/ipv6/ip6_input.c:322 dst_input ./include/net/dst.h:492 ip6_rcv_finish net/ipv6/ip6_input.c:69 NF_HOOK ./include/linux/netfilter.h:257 ipv6_rcv+0x1dbd/0x22e0 net/ipv6/ip6_input.c:203 __netif_receive_skb_core+0x2f6f/0x3a20 net/core/dev.c:4208 __netif_receive_skb net/core/dev.c:4246 process_backlog+0x667/0xba0 net/core/dev.c:4866 napi_poll net/core/dev.c:5268 net_rx_action+0xc95/0x1590 net/core/dev.c:5333 __do_softirq+0x485/0x942 kernel/softirq.c:284 ================================================================== Similar error is reported for cookie_v4_check(). Fixes: 58d607d3 ("tcp: provide skb->hash to synack packets") Signed-off-by:
Alexander Potapenko <glider@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Neal Cardwell authored
[ Upstream commit 32984565 ] Fixes the following behavior: for connections that had no RTT sample at the time of initializing congestion control, BBR was initializing the pacing rate to a high nominal rate (based an a guess of RTT=1ms, in case this is LAN traffic). Then BBR never adjusted the pacing rate downward upon obtaining an actual RTT sample, if the connection never filled the pipe (e.g. all sends were small app-limited writes()). This fix adjusts the pacing rate upon obtaining the first RTT sample. Fixes: 0f8782ea ("tcp_bbr: add BBR congestion control") Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
-
Neal Cardwell authored
[ Upstream commit 1d3648eb ] Fix a corner case noticed by Eric Dumazet, where BBR's setting sk->sk_pacing_rate to 0 during initialization could theoretically cause packets in the sending host to hang if there were packets "in flight" in the pacing infrastructure at the time the BBR congestion control state is initialized. This could occur if the pacing infrastructure happened to race with bbr_init() in a way such that the pacer read the 0 rather than the immediately following non-zero pacing rate. Fixes: 0f8782ea ("tcp_bbr: add BBR congestion control") Reported-by:
-
Neal Cardwell authored
[ Upstream commit 79135b89 ] Introduce a helper to initialize the BBR pacing rate unconditionally, based on the current cwnd and RTT estimate. This is a pure refactor, but is needed for two following fixes. Fixes: 0f8782ea ("tcp_bbr: add BBR congestion control") Signed-off-by:
-
Neal Cardwell authored
[ Upstream commit f19fd62d ] Introduce a helper to convert a BBR bandwidth and gain factor to a pacing rate in bytes per second. This is a pure refactor, but is needed for two following fixes. Fixes: 0f8782ea ("tcp_bbr: add BBR congestion control") Signed-off-by:
-
Neal Cardwell authored
[ Upstream commit 4aea287e ] In bbr_set_pacing_rate(), which decides whether to cut the pacing rate, there was some code that considered exiting STARTUP to be equivalent to the notion of filling the pipe (i.e., bbr_full_bw_reached()). Specifically, as the code was structured, exiting STARTUP and going into PROBE_RTT could cause us to cut the pacing rate down to something silly and low, based on whatever bandwidth samples we've had so far, when it's possible that all of them have been small app-limited bandwidth samples that are not representative of the bandwidth available in the path. (The code was correct at the time it was written, but the state machine changed without this spot being adjusted correspondingly.) Fixes: 0f8782ea ("tcp_bbr: add BBR congestion control") Signed-off-by:
-
Xin Long authored
[ Upstream commit 10b3bf54 ] Marcelo noticed an array overflow caused by commit c28445c3 ("sctp: add reconf_enable in asoc ep and netns"), in which sctp would add SCTP_CID_RECONF into extensions when reconf_enable is set in sctp_make_init and sctp_make_init_ack. Then now when all ext chunks are set, 4 ext chunk ids can be put into extensions array while extensions array size is 3. It would cause a kernel panic because of this overflow. This patch is to fix it by defining extensions array size is 4 in both sctp_make_init and sctp_make_init_ack. Fixes: c28445c3 ("sctp: add reconf_enable in asoc ep and netns") Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Steven Toth authored
commit 6fb05e0d upstream. Avoid a double fetch by reusing the values from the prior transfer. Originally reported via https://bugzilla.kernel.org/show_bug.cgi?id=195559 Thanks to Pengfei Wang <wpengfeinudt@gmail.com> for reporting. Signed-off-by:
Steven Toth <stoth@kernellabs.com> Reported-by:
Pengfei Wang <wpengfeinudt@gmail.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Cc: Eduardo Valentin <eduval@amazon.com> Signed-off-by:
-
Christoph Hellwig authored
commit 765e40b6 upstream. The blk-mq code lacks support for looking at the rpm_status field, tracking active requests and the RQF_PM flag. Due to the default switch to blk-mq for scsi people start to run into suspend / resume issue due to this fact, so make sure we disable the runtime PM functionality until it is properly implemented. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Cc: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by:
-
Christoph Hellwig authored
commit 4b855ad3 upstream. Currently we only create hctx for online CPUs, which can lead to a lot of churn due to frequent soft offline / online operations. Instead allocate one for each present CPU to avoid this and dramatically simplify the code. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Oleksandr Natalenko <oleksandr@natalenko.name> Cc: Mike Galbraith <efault@gmx.de> Signed-off-by:
-
Christoph Hellwig authored
commit 5f042e7c upstream. This way we get a nice distribution independent of the current cpu online / offline state. Signed-off-by:
-
Omar Sandoval authored
commit 17024ad0 upstream. If a lot of metadata is reserved for outstanding delayed allocations, we rely on shrink_delalloc() to reclaim metadata space in order to fulfill reservation tickets. However, shrink_delalloc() has a shortcut where if it determines that space can be overcommitted, it will stop early. This made sense before the ticketed enospc system, but now it means that shrink_delalloc() will often not reclaim enough space to fulfill any tickets, leading to an early ENOSPC. (Reservation tickets don't care about being able to overcommit, they need every byte accounted for.) Fix it by getting rid of the shortcut so that shrink_delalloc() reclaims all of the metadata it is supposed to. This fixes early ENOSPCs we were seeing when doing a btrfs receive to populate a new filesystem, as well as early ENOSPCs Christoph saw when doing a big cp -r onto Btrfs. Fixes: 957780eb ("Btrfs: introduce ticketed enospc infrastructure") Tested-by:
Christoph Anton Mitterer <mail@christoph.anton.mitterer.name> Reviewed-by:
Josef Bacik <jbacik@fb.com> Signed-off-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
Nikolay Borisov <nborisov@suse.com> Signed-off-by:
-
Jan Kara authored
commit a3bb2d55 upstream. When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group. Fix the problem by moving posix_acl_update_mode() out of __ext4_set_acl() into ext4_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway. Fixes: 07393101Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
-
Ernesto A. Fernández authored
commit 397e4341 upstream. When changing a file's acl mask, __ext4_set_acl() will first set the group bits of i_mode to the value of the mask, and only then set the actual extended attribute representing the new acl. If the second part fails (due to lack of space, for example) and the file had no acl attribute to begin with, the system will from now on assume that the mask permission bits are actual group permission bits, potentially granting access to the wrong users. Prevent this by only changing the inode mode after the acl has been set. Signed-off-by:
Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com> Signed-off-by:
-
Xiubo Li authored
commit b3743c71 upstream. For all the entries allocated from the ring cmd area, the memory is something like the stack memory, which will always reserve the old data, so the entry->req.iov_bidi_cnt maybe none zero. On some environments, the crash could be reproduce very easy and some not. The following is the crash core trace as reported by Damien: [ 240.143969] CPU: 0 PID: 1285 Comm: iscsi_trx Not tainted 4.12.0-rc1+ #3 [ 240.150607] Hardware name: ASUS All Series/H87-PRO, BIOS 2104 10/28/2014 [ 240.157331] task: ffff8807de4f5800 task.stack: ffffc900047dc000 [ 240.163270] RIP: 0010:memcpy_erms+0x6/0x10 [ 240.167377] RSP: 0018:ffffc900047dfc68 EFLAGS: 00010202 [ 240.172621] RAX: ffffc9065db85540 RBX: ffff8807f7980000 RCX: 0000000000000010 [ 240.179771] RDX: 0000000000000010 RSI: ffff8807de574fe0 RDI: ffffc9065db85540 [ 240.186930] RBP: ffffc900047dfd30 R08: ffff8807de41b000 R09: 0000000000000000 [ 240.194088] R10: 0000000000000040 R11: ffff8807e9b726f0 R12: 00000006565726b0 [ 240.201246] R13: ffffc90007612ea0 R14: 000000065657d540 R15: 0000000000000000 [ 240.208397] FS: 0000000000000000(0000) GS:ffff88081fa00000(0000) knlGS:0000000000000000 [ 240.216510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 240.222280] CR2: ffffc9065db85540 CR3: 0000000001c0f000 CR4: 00000000001406f0 [ 240.229430] Call Trace: [ 240.231887] ? tcmu_queue_cmd+0x83c/0xa80 [ 240.235916] ? target_check_reservation+0xcd/0x6f0 [ 240.240725] __target_execute_cmd+0x27/0xa0 [ 240.244918] target_execute_cmd+0x232/0x2c0 [ 240.249124] ? __local_bh_enable_ip+0x64/0xa0 [ 240.253499] iscsit_execute_cmd+0x20d/0x270 [ 240.257693] iscsit_sequence_cmd+0x110/0x190 [ 240.261985] iscsit_get_rx_pdu+0x360/0xc80 [ 240.267565] ? iscsi_target_rx_thread+0x54/0xd0 [ 240.273571] iscsi_target_rx_thread+0x9a/0xd0 [ 240.279413] kthread+0x113/0x150 [ 240.284120] ? iscsi_target_tx_thread+0x1e0/0x1e0 [ 240.290297] ? kthread_create_on_node+0x40/0x40 [ 240.296297] ret_from_fork+0x2e/0x40 [ 240.301332] Code: 90 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 [ 240.321751] RIP: memcpy_erms+0x6/0x10 RSP: ffffc900047dfc68 [ 240.328838] CR2: ffffc9065db85540 [ 240.333667] ---[ end trace b7e5354cfb54d08b ]--- To fix this, just memset all the entry memory before using it, and also to be more readable we adjust the bidi code. Fixed: fe25cc34(tcmu: Recalculate the tcmu_cmd size to save cmd area memories) Reported-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Tested-by:
Damien Le Moal <damien.lemoal@wdc.com> Tested-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
Xiubo Li <lixiubo@cmss.chinamobile.com> Cc: <stable@vger.kernel.org> # 4.12+ Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Xiubo Li authored
commit 9d62bc0e upstream. When feeding the tcmu's cmd ring, we need to flush the dcache page for the cmd entry to make sure these kernel stores are visible to user space mappings of that page. For the none PAD cmd entry, this will be flushed at the end of the tcmu_queue_cmd_ring(). Signed-off-by:
-
Anton Blanchard authored
commit cc20ba4e upstream. The ir-spi driver has 2 issues which prevents it from working with lirc: 1. The ir-spi driver uses 16 bits of SPI data to create one cycle of the waveform. As such our SPI clock needs to be 16x faster than the carrier frequency. The driver is inconsistent in how it currently handles this. It initializes it to the carrier frequency: But the commit message has some example code which initialises it to 16x the carrier frequency: val = 608000; ret = ioctl(fd, LIRC_SET_SEND_CARRIER, &val); To maintain compatibility with lirc, always do the frequency adjustment in the driver. 2. lirc presents pulses in microseconds, but the ir-spi driver treats them as cycles of the carrier. Similar to other lirc drivers, do the conversion with DIV_ROUND_CLOSEST(). Fixes: fe052da4 ("[media] rc: add support for IR LEDs driven through SPI") Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Prabhakar Lad authored
commit da05d52d upstream. this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works for vpfe_capture driver with a minimal patch suitable for backporting. - This ioctl was never in public api and was only defined in kernel header. - The function set_params constantly mixes up pointers and phys_addr_t numbers. - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is described as an 'experimental ioctl that will change in future kernels'. - The code to allocate the table never gets called after we copy_from_user the user input over the kernel settings, and then compare them for inequality. - We then go on to use an address provided by user space as both the __user pointer for input and pass it through phys_to_virt to come up with a kernel pointer to copy the data to. This looks like a trivially exploitable root hole. Due to these reasons we make sure this ioctl now returns -EINVAL and backport this patch as far as possible. Fixes: 5f15fbb6 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver") Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Sean Young authored
commit 9f5039ba upstream. Since commit e8f48188 ("[media] lirc: advertise LIRC_CAN_GET_REC_RESOLUTION and improve") lircd uses the ioctl LIRC_GET_REC_RESOLUTION to determine the shortest pulse or space that the hardware can detect. This breaks decoding in lirc because lircd expects the answer in microseconds, but nanoseconds is returned. Reported-by:
Derek <user.vdr@gmail.com> Tested-by:
-
Hans Verkuil authored
commit 9b7c0c47 upstream. The persistent_config option is used to make the CEC settings persistent by using the eeprom inside the device to store this information. This was on by default, which caused confusion since this device now behaves differently from other CEC devices which all come up unconfigured. Another reason for doing this now is that I hope a more standard way of selecting persistent configuration will be created in the future. And for that to work all CEC drivers should behave the same and come up unconfigured by default. None of the open source CEC applications are using this CEC framework at the moment so change this behavior before it is too late. Signed-off-by:
-
Marc Gonzalez authored
commit 985333b0 upstream. RX and TX clock delays are required. Request them explicitly. Fixes: cad008b8 ("ARM: dts: tango4: Initial device trees") Signed-off-by:
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Gregory CLEMENT authored
commit 8d451417 upstream. As written in the datasheet the PCA955 can only handle low level irq and not edge irq. Without this fix the interrupt is not usable for pca955: the gpio-pca953x driver already set the irq type as low level which is incompatible with edge type, then the kernel prevents using the interrupt: "irq: type mismatch, failed to map hwirq-18 for /soc/internal-regs/gpio@18100!" Fixes: 928413bd ("ARM: mvebu: Add Armada 388 General Purpose Development Board support") Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Gregory CLEMENT authored
commit 76127d6f upstream. As we already did for Armada XP switch from virt_to_phys() to __pa_symbol(). The reason for it was well explained by Mark Rutland so let's quote him: "virt_to_phys() is intended to operate on the linear/direct mapping of RAM. __pa_symbol() is intended to operate on the kernel mapping, which may not be in the linear/direct mapping on all architectures. e.g. arm64 and x86_64 map the kernel image and RAM separately. On 32-bit ARM the kernel image mapping is tied to the linear/direct mapping, so that works, but as it's semantically wrong (and broken for generic code), the DEBUG_VIRTUAL checks complain." Fixes: db889778 ("arm: mvebu: support for SMP on 98DX3336 SoC") Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by:
-
Maxime Ripard authored
commit 9735ee9e upstream. The current CPU clock is missing the option to change the rate of its parents, leading to improper rates calculated by cpufreq, and eventually crashes. Fixes: 5e737617 ("clk: sunxi-ng: Add sun5i CCU driver") Reported-by:
Kevin Hilman <khilman@baylibre.com> Acked-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Harvey Hunt authored
commit e3ccf1d1 upstream. Previously, <linux/module.h> was included before ralink_regs.h in all ralink files - leading to <linux/io.h> being implicitly included. After commit 26dd3e4f ("MIPS: Audit and remove any unnecessary uses of module.h") removed the inclusion of module.h from multiple places, some ralink platforms failed to build with the following error: In file included from arch/mips/ralink/mt7620.c:17:0: ./arch/mips/include/asm/mach-ralink/ralink_regs.h: In function ‘rt_sysc_w32’: ./arch/mips/include/asm/mach-ralink/ralink_regs.h:38:2: error: implicit declaration of function ‘__raw_writel’ [-Werror=implicit-function-declaration] __raw_writel(val, rt_sysc_membase + reg); ^ ./arch/mips/include/asm/mach-ralink/ralink_regs.h: In function ‘rt_sysc_r32’: ./arch/mips/include/asm/mach-ralink/ralink_regs.h:43:2: error: implicit declaration of function ‘__raw_readl’ [-Werror=implicit-function-declaration] return __raw_readl(rt_sysc_membase + reg); Fix this by including <linux/io.h>. Signed-off-by:
Harvey Hunt <harvey.hunt@imgtec.com> Fixes: 26dd3e4f ("MIPS: Audit and remove any unnecessary uses of module.h") Cc: John Crispin <john@phrozen.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/16780/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Jerry Lee authored
commit aec51758 upstream. On a 32-bit platform, the value of n_blcoks_count may be wrong during the file system is resized to size larger than 2^32 blocks. This may caused the superblock being corrupted with zero blocks count. Fixes: 1c6bd717Signed-off-by:
Jerry Lee <jerrylee@qnap.com> Signed-off-by:
-
Jan Kara authored
commit fcf5ea10 upstream. ext4_find_unwritten_pgoff() does not properly handle a situation when starting index is in the middle of a page and blocksize < pagesize. The following command shows the bug on filesystem with 1k blocksize: xfs_io -f -c "falloc 0 4k" \ -c "pwrite 1k 1k" \ -c "pwrite 3k 1k" \ -c "seek -a -r 0" foo In this example, neither lseek(fd, 1024, SEEK_HOLE) nor lseek(fd, 2048, SEEK_DATA) will return the correct result. Fix the problem by neglecting buffers in a page before starting offset. Reported-by:
-
Bartosz Golaszewski authored
commit df1e76f2 upstream. The previous fix for filtering out of unwatched events was not entirely correct. Instead of skipping the events we don't want, they are now interpreted as events with opposing edge. In order to fix it: always read the GPIO line value on interrupt and only emit the event if it corresponds with the event type we requested. Fixes: ad537b82 ("gpiolib: fix filtering out unwanted events") Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Gregory CLEMENT authored
commit d7a65c49 upstream. The number of pins in South Bridge is 30 and not 29. There is a fix for the driver for the pinctrl, but a fix is also need at device tree level for the GPIO. Fixes: afda007f ("ARM64: dts: marvell: Add pinctrl nodes for Armada 3700") Signed-off-by:
-
Suravee Suthikulpanit authored
commit efe6f241 upstream. IRTE[GALogIntr] bit should set when enabling guest_mode, which enables IOMMU to generate entry in GALog when IRTE[IsRun] is not set, and send an interrupt to notify IOMMU driver. Signed-off-by:
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Cc: Joerg Roedel <jroedel@suse.de> Fixes: d98de49a ('iommu/amd: Enable vAPIC interrupt remapping mode by default') Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Nicholas Piggin authored
commit 3db40c31 upstream. If the decrementer wraps again and de-asserts the decrementer exception while hard-disabled, __check_irq_replay() has a test to notice the wrap when interrupts are re-enabled. The decrementer check must be done when clearing the PACA_IRQ_HARD_DIS flag, not when the PACA_IRQ_DEC flag is tested. Previously this worked because the decrementer interrupt was always the first one checked after clearing the hard disable flag, but HMI check was moved ahead of that, which introduced this bug. This can cause a missed decrementer interrupt if we soft-disable interrupts then take an HMI which is recorded in irq_happened, then hard-disable interrupts for > 4s to wrap the decrementer. Fixes: e0e0d6b7 ("powerpc/64: Replay hypervisor maintenance interrupt first") Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Gustavo Romero authored
commit cd63f3cf upstream. Currently flush_tmregs_to_thread() does not save the TM SPRs (TFHAR, TFIAR, TEXASR) to the thread struct, unless the process is currently inside a suspended transaction. If the process is core dumping, and the TM SPRs have changed since the last time the process was context switched, then we will save stale values of the TM SPRs to the core dump. Fix it by saving the live register state to the thread struct in that case. Fixes: 08e1c01d ("powerpc/ptrace: Enable support for TM SPR state") Signed-off-by:
Gustavo Romero <gromero@linux.vnet.ibm.com> Reviewed-by:
Cyril Bur <cyrilbur@gmail.com> Signed-off-by:
-
Matija Glavinic Pecotic authored
commit 34f41c03 upstream. For e.g. HZ=100, timer being 430 jiffies in the future, and 32 bit unsigned int, there is an overflow on unsigned int right-hand side of the expression which results with wrong values being returned. Type cast the multiplier to 64bit to avoid that issue. Fixes: 46c8f0b0 ("timers: Fix get_next_timer_interrupt() computation") Signed-off-by:
Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com> Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Cc: khilman@baylibre.com Cc: akpm@linux-foundation.org Link: http://lkml.kernel.org/r/a7900f04-2a21-c9fd-67be-ab334d459ee5@nokia.comSigned-off-by:
-
Wanpeng Li authored
commit 337c017c upstream. WARNING: CPU: 5 PID: 1242 at kernel/rcu/tree_plugin.h:323 rcu_note_context_switch+0x207/0x6b0 CPU: 5 PID: 1242 Comm: unity-settings- Not tainted 4.13.0-rc2+ #1 RIP: 0010:rcu_note_context_switch+0x207/0x6b0 Call Trace: __schedule+0xda/0xba0 ? kvm_async_pf_task_wait+0x1b2/0x270 schedule+0x40/0x90 kvm_async_pf_task_wait+0x1cc/0x270 ? prepare_to_swait+0x22/0x70 do_async_page_fault+0x77/0xb0 ? do_async_page_fault+0x77/0xb0 async_page_fault+0x28/0x30 RIP: 0010:__d_lookup_rcu+0x90/0x1e0 I encounter this when trying to stress the async page fault in L1 guest w/ L2 guests running. Commit 9b132fbe (Add rcu user eqs exception hooks for async page fault) adds rcu_irq_enter/exit() to kvm_async_pf_task_wait() to exit cpu idle eqs when needed, to protect the code that needs use rcu. However, we need to call the pair even if the function calls schedule(), as seen from the above backtrace. This patch fixes it by informing the RCU subsystem exit/enter the irq towards/away from idle for both n.halted and !n.halted. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by:
Wanpeng Li <wanpeng.li@hotmail.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Suzuki K Poulose authored
commit 7e5a6722 upstream. The mmu_notifier_release() callback of KVM triggers cleaning up the stage2 page table on kvm-arm. However there could be other notifier callbacks in parallel with the mmu_notifier_release(), which could cause the call backs ending up in an empty stage2 page table. Make sure we check it for all the notifier callbacks. Fixes: commit 293f2936 ("kvm-arm: Unmap shadow pagetables properly") Reported-by:
Alex Graf <agraf@suse.de> Reviewed-by:
Christoffer Dall <cdall@linaro.org> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Banajit Goswami authored
commit b1cd2e34 upstream. Multiple frontend dailinks may be connected to a backend dailink at the same time. When one of frontend dailinks is closed, the associated backend dailink should not be closed if it is connected to other active frontend dailinks. Change ensures that backend dailink is closed only after all connected frontend dailinks are closed. Signed-off-by:
Gopikrishnaiah Anandan <agopik@codeaurora.org> Signed-off-by:
Banajit Goswami <bgoswami@codeaurora.org> Signed-off-by:
Patrick Lai <plai@codeaurora.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit 651e9268 upstream. This reverts commit f1013cde ("ASoC: ux500: drop platform DAI assignments"), which seems to have been based on a misunderstanding and prevents the platform driver callbacks from being made (e.g. to preallocate DMA memory). The real culprit for the warnings about attempts to create duplicate procfs entries was commit 99b04f4c ("ASoC: add Component level pcm_new/pcm_free" that broke PCM creation on systems that use more than one platform component. Fixes: f1013cde ("ASoC: ux500: drop platform DAI assignments") Signed-off-by:
Johan Hovold <johan@kernel.org> Reviewed-by:
-
Johan Hovold authored
commit c641e5b2 upstream. This reverts commit 99b04f4c ("ASoC: add Component level pcm_new/pcm_free"), which started calling the pcm_new callback for every component in a *card* when creating a new pcm, something which does not seem to make any sense. This specifically led to memory leaks in systems with more than one platform component and where DMA memory is allocated in the platform-driver callback. For example, when both mcasp devices are being used on an am335x board, DMA memory would be allocated twice for every DAI link during probe. When CONFIG_SND_VERBOSE_PROCFS was set this fortunately also led to warnings such as: WARNING: CPU: 0 PID: 565 at ../fs/proc/generic.c:346 proc_register+0x110/0x154 proc_dir_entry 'sub0/prealloc' already registered Since there seems to be no users of the new component callbacks, and the current implementation introduced a regression, let's revert the offending commit for now. Fixes: 99b04f4c ("ASoC: add Component level pcm_new/pcm_free") Signed-off-by:
-
Jean Delvare authored
commit 5694785c upstream. As I was staring at the si_init_golden_registers code, I noticed that the Pitcairn initialization silently falls through the Cape Verde initialization, and the Oland initialization falls through the Hainan initialization. However there is no comment stating that this is intentional, and the radeon driver doesn't have any such fallthrough, so I suspect this is not supposed to happen. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Fixes: 62a37553 ("drm/amdgpu: add si implementation v10") Cc: Ken Wang <Qingqing.Wang@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Marek Olšák" <maraeo@gmail.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Flora Cui <Flora.Cui@amd.com> Reviewed-by:
Marek Olšák <marek.olsak@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
