- 12 Mar, 2017 22 commits
-
-
Alexandre Belloni authored
commit e3f0a401 upstream. The Atmel MPDDR controller support LPDDR2 and LPDDR3 memories, add their types. Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Andi Shyti authored
commit 379f831a upstream. Commit a92e7c3d ("spi: s3c64xx: consider the case when the CS line is not connected") introduced an inconsistency between the binding, where the disconnected CS line was marked as 'no-cs-readback', and the driver. The driver is erroneously checking for that attribute with property name of 'broken-cs'. Check for 'no-cs-readback' in the driver as well. Fixes: a92e7c3d ("spi: s3c64xx: consider the case when the CS line is not connected") Signed-off-by:
Andi Shyti <andi.shyti@samsung.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Theodore Ts'o authored
commit c755e251 upstream. The xattr_sem deadlock problems fixed in commit 2e81a4ee: "ext4: avoid deadlock when expanding inode size" didn't include the use of xattr_sem in fs/ext4/inline.c. With the addition of project quota which added a new extra inode field, this exposed deadlocks in the inline_data code similar to the ones fixed by 2e81a4ee. The deadlock can be reproduced via: dmesg -n 7 mke2fs -t ext4 -O inline_data -Fq -I 256 /dev/vdc 32768 mount -t ext4 -o debug_want_extra_isize=24 /dev/vdc /vdc mkdir /vdc/a umount /vdc mount -t ext4 /dev/vdc /vdc echo foo > /vdc/a/foo and looks like this: [ 11.158815] [ 11.160276] ============================================= [ 11.161960] [ INFO: possible recursive locking detected ] [ 11.161960] 4.10.0-rc3-00015-g011b30a8a3cf #160 Tainted: G W [ 11.161960] --------------------------------------------- [ 11.161960] bash/2519 is trying to acquire lock: [ 11.161960] (&ei->xattr_sem){++++..}, at: [<c1225a4b>] ext4_expand_extra_isize_ea+0x3d/0x4cd [ 11.161960] [ 11.161960] but task is already holding lock: [ 11.161960] (&ei->xattr_sem){++++..}, at: [<c1227941>] ext4_try_add_inline_entry+0x3a/0x152 [ 11.161960] [ 11.161960] other info that might help us debug this: [ 11.161960] Possible unsafe locking scenario: [ 11.161960] [ 11.161960] CPU0 [ 11.161960] ---- [ 11.161960] lock(&ei->xattr_sem); [ 11.161960] lock(&ei->xattr_sem); [ 11.161960] [ 11.161960] *** DEADLOCK *** [ 11.161960] [ 11.161960] May be due to missing lock nesting notation [ 11.161960] [ 11.161960] 4 locks held by bash/2519: [ 11.161960] #0: (sb_writers#3){.+.+.+}, at: [<c11a2414>] mnt_want_write+0x1e/0x3e [ 11.161960] #1: (&type->i_mutex_dir_key){++++++}, at: [<c119508b>] path_openat+0x338/0x67a [ 11.161960] #2: (jbd2_handle){++++..}, at: [<c123314a>] start_this_handle+0x582/0x622 [ 11.161960] #3: (&ei->xattr_sem){++++..}, at: [<c1227941>] ext4_try_add_inline_entry+0x3a/0x152 [ 11.161960] [ 11.161960] stack backtrace: [ 11.161960] CPU: 0 PID: 2519 Comm: bash Tainted: G W 4.10.0-rc3-00015-g011b30a8a3cf #160 [ 11.161960] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1 04/01/2014 [ 11.161960] Call Trace: [ 11.161960] dump_stack+0x72/0xa3 [ 11.161960] __lock_acquire+0xb7c/0xcb9 [ 11.161960] ? kvm_clock_read+0x1f/0x29 [ 11.161960] ? __lock_is_held+0x36/0x66 [ 11.161960] ? __lock_is_held+0x36/0x66 [ 11.161960] lock_acquire+0x106/0x18a [ 11.161960] ? ext4_expand_extra_isize_ea+0x3d/0x4cd [ 11.161960] down_write+0x39/0x72 [ 11.161960] ? ext4_expand_extra_isize_ea+0x3d/0x4cd [ 11.161960] ext4_expand_extra_isize_ea+0x3d/0x4cd [ 11.161960] ? _raw_read_unlock+0x22/0x2c [ 11.161960] ? jbd2_journal_extend+0x1e2/0x262 [ 11.161960] ? __ext4_journal_get_write_access+0x3d/0x60 [ 11.161960] ext4_mark_inode_dirty+0x17d/0x26d [ 11.161960] ? ext4_add_dirent_to_inline.isra.12+0xa5/0xb2 [ 11.161960] ext4_add_dirent_to_inline.isra.12+0xa5/0xb2 [ 11.161960] ext4_try_add_inline_entry+0x69/0x152 [ 11.161960] ext4_add_entry+0xa3/0x848 [ 11.161960] ? __brelse+0x14/0x2f [ 11.161960] ? _raw_spin_unlock_irqrestore+0x44/0x4f [ 11.161960] ext4_add_nondir+0x17/0x5b [ 11.161960] ext4_create+0xcf/0x133 [ 11.161960] ? ext4_mknod+0x12f/0x12f [ 11.161960] lookup_open+0x39e/0x3fb [ 11.161960] ? __wake_up+0x1a/0x40 [ 11.161960] ? lock_acquire+0x11e/0x18a [ 11.161960] path_openat+0x35c/0x67a [ 11.161960] ? sched_clock_cpu+0xd7/0xf2 [ 11.161960] do_filp_open+0x36/0x7c [ 11.161960] ? _raw_spin_unlock+0x22/0x2c [ 11.161960] ? __alloc_fd+0x169/0x173 [ 11.161960] do_sys_open+0x59/0xcc [ 11.161960] SyS_open+0x1d/0x1f [ 11.161960] do_int80_syscall_32+0x4f/0x61 [ 11.161960] entry_INT80_32+0x2f/0x2f [ 11.161960] EIP: 0xb76ad469 [ 11.161960] EFLAGS: 00000286 CPU: 0 [ 11.161960] EAX: ffffffda EBX: 08168ac8 ECX: 00008241 EDX: 000001b6 [ 11.161960] ESI: b75e46bc EDI: b7755000 EBP: bfbdb108 ESP: bfbdafc0 [ 11.161960] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b Reported-by:
George Spelvin <linux@sciencehorizons.net> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Sakari Ailus authored
commit 98d85f3c upstream. When the functions replaced media entity types, the range which was allowed for the types was incorrect. This meant that media entity types for specific devices were not passed correctly to the userspace through MEDIA_IOC_ENUM_ENTITIES. Fix it. Fixes: commit b2cd2744 ("[media] media-device: map new functions into old types for legacy API") Reported-and-tested-by:
Antti Laakso <antti.laakso@intel.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Sean Young authored
commit bd291208 upstream. Since "273b902a [media] lirc_dev: use LIRC_CAN_REC() define" these ioctls no longer work. Signed-off-by:
Sean Young <sean@mess.org> Reviewed-by:
-
Mauro Carvalho Chehab authored
commit 43fab979 upstream. As reported by Marc Duponcheel <marc@offline.be>, firmware load on dvb-usb is using the stack, with is not allowed anymore on default Kernel configurations: [ 1025.958836] dvb-usb: found a 'WideView WT-220U PenType Receiver (based on ZL353)' in cold state, will try to load a firmware [ 1025.958853] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw' [ 1025.958855] dvb-usb: could not stop the USB controller CPU. [ 1025.958856] dvb-usb: error while transferring firmware (transferred size: -11, block size: 3) [ 1025.958856] dvb-usb: firmware download failed at 8 with -22 [ 1025.958867] usbcore: registered new interface driver dvb_usb_dtt200u [ 2.789902] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw' [ 2.789905] ------------[ cut here ]------------ [ 2.789911] WARNING: CPU: 3 PID: 2196 at drivers/usb/core/hcd.c:1584 usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore] [ 2.789912] transfer buffer not dma capable [ 2.789912] Modules linked in: btusb dvb_usb_dtt200u(+) dvb_usb_af9035(+) btrtl btbcm dvb_usb dvb_usb_v2 btintel dvb_core bluetooth rc_core rfkill x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd drm_kms_helper syscopyarea sysfillrect pcspkr i2c_i801 sysimgblt fb_sys_fops drm i2c_smbus i2c_core r8169 lpc_ich mfd_core mii thermal fan rtc_cmos video button acpi_cpufreq processor snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd crc32c_intel ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd usbcore usb_common dm_mirror dm_region_hash dm_log dm_mod [ 2.789936] CPU: 3 PID: 2196 Comm: systemd-udevd Not tainted 4.9.0-gentoo #1 [ 2.789937] Hardware name: ASUS All Series/H81I-PLUS, BIOS 0401 07/23/2013 [ 2.789938] ffffc9000339b690 ffffffff812bd397 ffffc9000339b6e0 0000000000000000 [ 2.789939] ffffc9000339b6d0 ffffffff81055c86 000006300339b6a0 ffff880116c0c000 [ 2.789941] 0000000000000000 0000000000000000 0000000000000001 ffff880116c08000 [ 2.789942] Call Trace: [ 2.789945] [<ffffffff812bd397>] dump_stack+0x4d/0x66 [ 2.789947] [<ffffffff81055c86>] __warn+0xc6/0xe0 [ 2.789948] [<ffffffff81055cea>] warn_slowpath_fmt+0x4a/0x50 [ 2.789952] [<ffffffffa006d460>] usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore] [ 2.789954] [<ffffffff814ed5a8>] ? io_schedule_timeout+0xd8/0x110 [ 2.789956] [<ffffffffa006e09c>] usb_hcd_submit_urb+0x9c/0x980 [usbcore] [ 2.789958] [<ffffffff812d0ebf>] ? copy_page_to_iter+0x14f/0x2b0 [ 2.789960] [<ffffffff81126818>] ? pagecache_get_page+0x28/0x240 [ 2.789962] [<ffffffff8118c2a0>] ? touch_atime+0x20/0xa0 [ 2.789964] [<ffffffffa006f7c4>] usb_submit_urb+0x2c4/0x520 [usbcore] [ 2.789967] [<ffffffffa006feca>] usb_start_wait_urb+0x5a/0xe0 [usbcore] [ 2.789969] [<ffffffffa007000c>] usb_control_msg+0xbc/0xf0 [usbcore] [ 2.789970] [<ffffffffa067903d>] usb_cypress_writemem+0x3d/0x40 [dvb_usb] [ 2.789972] [<ffffffffa06791cf>] usb_cypress_load_firmware+0x4f/0x130 [dvb_usb] [ 2.789973] [<ffffffff8109dbbe>] ? console_unlock+0x2fe/0x5d0 [ 2.789974] [<ffffffff8109e10c>] ? vprintk_emit+0x27c/0x410 [ 2.789975] [<ffffffff8109e40a>] ? vprintk_default+0x1a/0x20 [ 2.789976] [<ffffffff81124d76>] ? printk+0x43/0x4b [ 2.789977] [<ffffffffa0679310>] dvb_usb_download_firmware+0x60/0xd0 [dvb_usb] [ 2.789979] [<ffffffffa0679898>] dvb_usb_device_init+0x3d8/0x610 [dvb_usb] [ 2.789981] [<ffffffffa069e302>] dtt200u_usb_probe+0x92/0xd0 [dvb_usb_dtt200u] [ 2.789984] [<ffffffffa007420c>] usb_probe_interface+0xfc/0x270 [usbcore] [ 2.789985] [<ffffffff8138bf95>] driver_probe_device+0x215/0x2d0 [ 2.789986] [<ffffffff8138c0e6>] __driver_attach+0x96/0xa0 [ 2.789987] [<ffffffff8138c050>] ? driver_probe_device+0x2d0/0x2d0 [ 2.789988] [<ffffffff81389ffb>] bus_for_each_dev+0x5b/0x90 [ 2.789989] [<ffffffff8138b7b9>] driver_attach+0x19/0x20 [ 2.789990] [<ffffffff8138b33c>] bus_add_driver+0x11c/0x220 [ 2.789991] [<ffffffff8138c91b>] driver_register+0x5b/0xd0 [ 2.789994] [<ffffffffa0072f6c>] usb_register_driver+0x7c/0x130 [usbcore] [ 2.789994] [<ffffffffa06a5000>] ? 0xffffffffa06a5000 [ 2.789996] [<ffffffffa06a501e>] dtt200u_usb_driver_init+0x1e/0x20 [dvb_usb_dtt200u] [ 2.789997] [<ffffffff81000408>] do_one_initcall+0x38/0x140 [ 2.789998] [<ffffffff8116001c>] ? __vunmap+0x7c/0xc0 [ 2.789999] [<ffffffff81124fb0>] ? do_init_module+0x22/0x1d2 [ 2.790000] [<ffffffff81124fe8>] do_init_module+0x5a/0x1d2 [ 2.790002] [<ffffffff810c96b1>] load_module+0x1e11/0x2580 [ 2.790003] [<ffffffff810c68b0>] ? show_taint+0x30/0x30 [ 2.790004] [<ffffffff81177250>] ? kernel_read_file+0x100/0x190 [ 2.790005] [<ffffffff810c9ffa>] SyS_finit_module+0xba/0xc0 [ 2.790007] [<ffffffff814f13e0>] entry_SYSCALL_64_fastpath+0x13/0x94 [ 2.790008] ---[ end trace c78a74e78baec6fc ]--- So, allocate the structure dynamically. Signed-off-by:
-
Antti Palosaari authored
commit 0ffb94b6 upstream. Setting GPIOs during probe causes null pointer deference when GPIOLIB was not selected by Kconfig. Initialize driver private field before calling set gpios. It is regressing bug since 4.9. Fixes: 07fdf7d9 ("[media] cxd2820r: add I2C driver bindings") Reported-by:
Chris Rankin <rankincj@gmail.com> Tested-by:
Håkan Lennestål <hakan.lennestal@gmail.com> Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Randy Dunlap authored
commit e3bb3cdd upstream. Fix dm1105 build error when CONFIG_I2C_ALGOBIT=m and CONFIG_DVB_DM1105=y. drivers/built-in.o: In function `dm1105_probe': dm1105.c:(.text+0x2836e7): undefined reference to `i2c_bit_add_bus' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Guennadi Liakhovetski authored
commit 17c341ec upstream. Don't mix up UVC_BUF_STATE_* and VB2_BUF_STATE_* codes. Fixes: 6998b6fb ("[media] uvcvideo: Use videobuf2-vmalloc") Signed-off-by:
Guennadi Liakhovetski <guennadi.liakhovetski@intel.com> Signed-off-by:
-
Nicolas Iooss authored
commit 6ebf7577 upstream. In vpfe_s_fmt(), when the sensor format and the requested format were the same, bpp was assigned to vpfe->bpp without being initialized first. Grab the bpp value that is currently used by using __vpfe_get_format() instead of its wrapper, vpfe_try_fmt(). This use of uninitialized variable has been found by compiling the kernel with clang. Fixes: 417d2e50 ("[media] media: platform: add VPFE capture driver support for AM437X") Signed-off-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by:
-
Zhang Rui authored
commit e28d6f04 upstream. With commit 67bf5156 ("gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get()"), mmc_gpiod_request_cd() returns -EPROBE_DEFER if GPIO is not ready when sdhci-acpi driver is probed, and sdhci-acpi driver should be probed again later in this case. This fixes an order issue when both GPIO and sdhci-acpi drivers are built as modules. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177101Tested-by:
Jonas Aaberg <cja@gmx.net> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Paul Burton authored
commit 096a0de4 upstream. is_jump_ins() checks for plain jump ("j") instructions since commit e7438c4b ("MIPS: Fix sibling call handling in get_frame_info") but that commit didn't make the same change to the microMIPS code, leaving it inconsistent with the MIPS32/MIPS64 code. Handle the microMIPS encoding of the jump instruction too such that it behaves consistently. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Fixes: e7438c4b ("MIPS: Fix sibling call handling in get_frame_info") Cc: Tony Wu <tung7970@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14533/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Paul Burton authored
commit bb9bc468 upstream. get_frame_info() calculates the offset of the return address within a stack frame simply by dividing a the bottom 16 bits of the instruction, treated as a signed integer, by the size of a long. Whilst this works for MIPS32 & MIPS64 ISAs where the sw or sd instructions are used, it's incorrect for microMIPS where encodings differ. The result is that we typically completely fail to unwind the stack on microMIPS. Fix this by adjusting is_ra_save_ins() to calculate the return address offset, and take into account the various different encodings there in the same place as we consider whether an instruction is storing the ra/$31 register. With this we are now able to unwind the stack for kernels targetting the microMIPS ISA, for example we can produce: Call Trace: [<80109e1f>] show_stack+0x63/0x7c [<8011ea17>] __warn+0x9b/0xac [<8011ea45>] warn_slowpath_fmt+0x1d/0x20 [<8013fe53>] register_console+0x43/0x314 [<8067c58d>] of_setup_earlycon+0x1dd/0x1ec [<8067f63f>] early_init_dt_scan_chosen_stdout+0xe7/0xf8 [<8066c115>] do_early_param+0x75/0xac [<801302f9>] parse_args+0x1dd/0x308 [<8066c459>] parse_early_options+0x25/0x28 [<8066c48b>] parse_early_param+0x2f/0x38 [<8066e8cf>] setup_arch+0x113/0x488 [<8066c4f3>] start_kernel+0x57/0x328 ---[ end trace 0000000000000000 ]--- Whereas previously we only produced: Call Trace: [<80109e1f>] show_stack+0x63/0x7c ---[ end trace 0000000000000000 ]--- Signed-off-by:
-
Paul Burton authored
commit 67c75057 upstream. is_jump_ins() checks 16b instruction fields without verifying that the instruction is indeed 16b, as is done by is_ra_save_ins() & is_sp_move_ins(). Add the appropriate check. Signed-off-by:
-
Paul Burton authored
commit b6c7a324 upstream. get_frame_info() is meant to iterate over up to the first 128 instructions within a function, but for microMIPS kernels it will not reach that many instructions unless the function is 512 bytes long since we calculate the maximum number of instructions to check by dividing the function length by the 4 byte size of a union mips_instruction. In microMIPS kernels this won't do since instructions are variable length. Fix this by instead checking whether the pointer to the current instruction has reached the end of the function, and use max_insns as a simple constant to check the number of iterations against. Signed-off-by:
-
Paul Burton authored
commit a3552dac upstream. During stack unwinding we call a number of functions to determine what type of instruction we're looking at. The union mips_instruction pointer provided to them may be pointing at a 2 byte, but not 4 byte, aligned address & we thus cannot directly access the 4 byte wide members of the union mips_instruction. To avoid this is_ra_save_ins() copies the required half-words of the microMIPS instruction to a correctly aligned union mips_instruction on the stack, which it can then access safely. The is_jump_ins() & is_sp_move_ins() functions do not correctly perform this temporary copy, and instead attempt to directly dereference 4 byte fields which may be misaligned and lead to an address exception. Fix this by copying the instruction halfwords to a temporary union mips_instruction in get_frame_info() such that we can provide a 4 byte aligned union mips_instruction to the is_*_ins() functions and they do not need to deal with misalignment themselves. Signed-off-by:
-
Paul Burton authored
commit ccaf7caf upstream. get_frame_info() can be called in microMIPS kernels with the ISA bit already clear. For example this happens when unwind_stack_by_address() is called because we begin with a PC that has the ISA bit set & subtract the (odd) offset from the preceding symbol (which does not have the ISA bit set). Since get_frame_info() unconditionally subtracts 1 from the PC in microMIPS kernels it incorrectly misaligns the address it then attempts to access code at, leading to an address error exception. Fix this by using msk_isa16_mode() to clear the ISA bit, which allows get_frame_info() to function regardless of whether it is provided with a PC that has the ISA bit set or not. Signed-off-by:
-
Felix Fietkau authored
commit 774f0c64 upstream. Disabling ethernet during reboot (only to enable it again when the ethernet driver attaches) can put the chip into a faulty state where it corrupts the header of all incoming packets. This happens if packets arrive during the time window where the core is disabled, and it can be easily reproduced by rebooting while sending a flood ping to the broadcast address. Fixes: 95135bfa ("MIPS: Lantiq: Deactivate most of the devices by default") Signed-off-by:
Felix Fietkau <nbd@nbd.name> Acked-by:
John Crispin <john@phrozen.org> Cc: hauke.mehrtens@lantiq.com Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/15078/Signed-off-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
James Cowgill authored
commit 884b4269 upstream. If copy_from_user is called with a large buffer (>= 128 bytes) and the userspace buffer refers partially to unreadable memory, then it is possible for Octeon's copy_from_user to report the wrong number of bytes have been copied. In the case where the buffer size is an exact multiple of 128 and the fault occurs in the last 64 bytes, copy_from_user will report that all the bytes were copied successfully but leave some garbage in the destination buffer. The bug is in the main __copy_user_common loop in octeon-memcpy.S where in the middle of the loop, src and dst are incremented by 128 bytes. The l_exc_copy fault handler is used after this but that assumes that "src < THREAD_BUADDR($28)". This is not the case if src has already been incremented. Fix by adding an extra fault handler which rewinds the src and dst pointers 128 bytes before falling though to l_exc_copy. Thanks to the pwritev test from the strace test suite for originally highlighting this bug! Fixes: 5b3b1688 ("MIPS: Add Cavium OCTEON processor support ...") Signed-off-by:
James Cowgill <James.Cowgill@imgtec.com> Acked-by:
David Daney <david.daney@cavium.com> Reviewed-by:
-
Mirko Parthey authored
commit bdfdaf1a upstream. The Asus WL-500W buttons are active high, but the software treats them as active low. Fix the inverted logic. Fixes: 3be97255 ("MIPS: BCM47XX: Import buttons database from OpenWrt") Signed-off-by:
Mirko Parthey <mirko.parthey@web.de> Acked-by:
Rafał Miłecki <rafal@milecki.pl> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/15295/Signed-off-by:
-
Ralf Baechle authored
commit 66fd848c upstream. For certain arguments such as saddr = 0xc0a8fd60, daddr = 0xc0a8fda1, len = 80, proto = 17, sum = 0x7eae049d there will be a carry when folding the intermediate 64 bit checksum to 32 bit but the code doesn't add the carry back to the one's complement sum, thus an incorrect result will be generated. Reported-by:
Mark Zhang <bomb.zhang@gmail.com> Signed-off-by:
-
Purna Chandra Mandal authored
commit a726f1d2 upstream. Early clock API pic32_get_pbclk() is defined in early_clk.c and used by time.c and early_console.c. When CONFIG_EARLY_PRINTK isn't set, early_clk.c isn't compiled and time.c fails to link. Fix it by compiling early_clk.c always. Also sort files in alphabetical order. Fixes: 6e4ad1b4 ("MIPS: pic32mzda: fix getting timer clock rate.") Reported-by:
Harvey Hunt <harvey.hunt@imgtec.com> Signed-off-by:
Purna Chandra Mandal <purna.mandal@microchip.com> Reviewed-by:
-
- 26 Feb, 2017 18 commits
-
-
Greg Kroah-Hartman authored
-
Brian Foster authored
commit fa7f138a upstream. The buffered write failure handling code in xfs_file_iomap_end_delalloc() has a couple minor problems. First, if written == 0, start_fsb is not rounded down and it fails to kill off a delalloc block if the start offset is block unaligned. This results in a lingering delalloc block and broken delalloc block accounting detected at unmount time. Fix this by rounding down start_fsb in the unlikely event that written == 0. Second, it is possible for a failed overwrite of a delalloc extent to leave dirty pagecache around over a hole in the file. This is because is possible to hit ->iomap_end() on write failure before the iomap code has attempted to allocate pagecache, and thus has no need to clean it up. If the targeted delalloc extent was successfully written by a previous write, however, then it does still have dirty pages when ->iomap_end() punches out the underlying blocks. This ultimately results in writeback over a hole. To fix this problem, unconditionally punch out the pagecache from XFS before the associated delalloc range. Signed-off-by:
Brian Foster <bfoster@redhat.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
-
Michael Schenk authored
commit 575ddce0 upstream. In the function rtl_usb_start we pre-allocate a certain number of urbs for RX path but they will not be freed when calling rtl_usb_stop. This results in leaking urbs when doing ifconfig up and down. Eventually, the system has no available urbs. Signed-off-by:
Michael Schenk <michael.schenk@albis-elcon.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Tejun Heo authored
commit 5f478e4e upstream. When !CONFIG_CGROUP_WRITEBACK, bdi has single bdi_writeback_congested at bdi->wb_congested. cgwb_bdi_init() allocates it with kzalloc() and doesn't do further initialization. This usually works fine as the reference count gets bumped to 1 by wb_init() and the put from wb_exit() releases it. However, when wb_init() fails, it puts the wb base ref automatically freeing the wb and the explicit kfree() in cgwb_bdi_init() error path ends up trying to free the same pointer the second time causing a double-free. Fix it by explicitly initilizing the refcnt to 1 and putting the base ref from cgwb_bdi_destroy(). Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Dmitry Vyukov <dvyukov@google.com> Fixes: a13f35e8 ("writeback: don't embed root bdi_writeback_congested in bdi_writeback") Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Lv Zheng authored
commit ffab9188 upstream. ACPICA commit b59347d0b8b676cb555fe8da5cad08fcd4eeb0d3 The following commit cleans up compiler specific inclusions: Commit: 9fa1cebd Subject: ACPICA: OSL: Cleanup the inclusion order of the compiler-specific headers But breaks one thing due to the following old issue: Buidling Linux kernel with Intel compiler originally depends on acgcc.h not acintel.h. So after making Intel compiler build working in ACPICA upstream by correctly using acintel.h, it becomes unable to build Linux kernel using Intel compiler as there is no acintel.h in the kernel source tree. This patch releases acintel.h to Linux kernel and fixes its inclusion in acenv.h. Fixes: 9fa1cebd (ACPICA: OSL: Cleanup the inclusion order of the compiler-specific headers) Link: https://github.com/acpica/acpica/commit/b59347d0Tested-by:
Stepan M Mishura <stepan.m.mishura@intel.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Jiri Kosina authored
commit dfe75ff8 upstream. Commit 3bb398d9 ("netfilter: nf_ct_helper: disable automatic helper assignment") is causing behavior regressions in firewalls, as traffic handled by conntrack helpers is now by default not passed through even though it was before due to missing CT targets (which were not necessary before this commit). The default had to be switched off due to security reasons [1] [2] and therefore should stay the way it is, but let's be friendly to firewall admins and issue a warning the first time we're in situation where packet would be likely passed through with the old default but we're likely going to drop it on the floor now. Rewrite the code a little bit as suggested by Linus, so that we avoid spaghettiing the code even more -- namely the whole decision making process regarding helper selection (either automatic or not) is being separated, so that the whole logic can be simplified and code (condition) duplication reduced. [1] https://cansecwest.com/csw12/conntrack-attack.pdf [2] https://home.regit.org/netfilter-en/secure-use-of-helpers/Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Thomas Gleixner authored
commit 6cf18e69 upstream. This interrupt handler is broken in several ways: - It loops forever when the op code is not decodeable - It never returns IRQ_HANDLED because the only way to exit the loop returns IRQ_NONE unconditionally. The whole concept of this is broken. Creating devices in an interrupt handler is beyond any point of sanity. Make it at least behave halfways sane so accidental users do not have to deal with a hard to debug lockup. Fixes: e809c22b ("goldfish: add the goldfish virtual bus") Reported-by:
Gabriel C <nix.or.die@gmail.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Thomas Gleixner authored
commit 47512cfd upstream. The goldfish platform code registers the platform device unconditionally which causes havoc in several ways if the goldfish_pdev_bus driver is enabled: - Access to the hardcoded physical memory region, which is either not available or contains stuff which is completely unrelated. - Prevents that the interrupt of the serial port can be requested - In case of a spurious interrupt it goes into a infinite loop in the interrupt handler of the pdev_bus driver (which needs to be fixed seperately). Add a 'goldfish' command line option to make the registration opt-in when the platform is compiled in. I'm seriously grumpy about this engineering trainwreck, which has seven SOBs from Intel developers for 50 lines of code. And none of them figured out that this is broken. Impressive fail! Fixes: ddd70cf9 ("goldfish: platform device for x86") Reported-by:
-
Johan Hovold authored
commit 14816b16 upstream. Since commit 4a510969 ("tty: Make tty_files_lock per-tty") a new tty_struct spin lock is taken in the tty release path, but the USB-serial-console hack was never updated hence leaving the lock of its "fake" tty uninitialised. This was eventually detected by lockdep. Make sure to initialise the new lock also for the fake tty to address this regression. Yes, this code is a mess, but cleaning it up is left for another day. Fixes: 4a510969 ("tty: Make tty_files_lock per-tty") Reviewed-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit 9fef37d7 upstream. The current implementation failed to detect short transfers, something which could lead to bits of the uninitialised heap transfer buffer leaking to user space. Fixes: 149fc791 ("USB: ark3116: Setup some basic infrastructure for new ark3116 driver.") Fixes: f4c1e8d5 ("USB: ark3116: Make existing functions 16450-aware and add close and release functions.") Reviewed-by:
-
Johan Hovold authored
commit 2eee0502 upstream. The opticon driver used a control request at open to trigger a CTS status notification to be sent over the bulk-in pipe. When the driver was converted to using the generic read implementation, an inverted test prevented this request from being sent, something which could lead to TIOCMGET reporting an incorrect CTS state. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 7a6ee2b0 ("USB: opticon: switch to generic read implementation") Reviewed-by:
-
Johan Hovold authored
commit 5ed8d410 upstream. Make sure to detect short control transfers and return zero on success when retrieving the modem status. This fixes the TIOCMGET implementation which since e1ed212d ("USB: spcp8x5: add proper modem-status support") has returned TIOCM_LE on successful retrieval, and avoids leaking bits from the stack on short transfers. This also fixes the carrier-detect implementation which since the above mentioned commit unconditionally has returned true. Fixes: e1ed212d ("USB: spcp8x5: add proper modem-status support") Reviewed-by:
-
Johan Hovold authored
commit a6bb1e17 upstream. FTDI devices use a receive latency timer to periodically empty the receive buffer and report modem and line status (also when the buffer is empty). When a break or error condition is detected the corresponding status flags will be set on a packet with nonzero data payload and the flags are not updated until the break is over or further characters are received. In order to avoid over-reporting break and error conditions, these flags must therefore only be processed for packets with payload. This specifically fixes the case where after an overrun, the error condition is continuously reported and NULL-characters inserted until further data is received. Reported-by:
Michael Walle <michael@walle.cc> Fixes: 72fda3ca ("USB: serial: ftd_sio: implement sysrq handling on break") Fixes: 166ceb69 ("USB: ftdi_sio: clean up line-status handling") Signed-off-by:
-
Johan Hovold authored
commit c6dce262 upstream. Since commit 557aaa7f ("ft232: support the ASYNC_LOW_LATENCY flag") the FTDI driver has been using a receive latency-timer value of 1 ms instead of the device default of 16 ms. The latency timer is used to periodically empty a non-full receive buffer, but a status header is always sent when the timer expires including when the buffer is empty. This means that a two-byte bulk message is received every millisecond also for an otherwise idle port as long as it is open. Let's restore the pre-2009 behaviour which reduces the rate of the status messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to 62.5 Hz) by not setting ASYNC_LOW_LATENCY by default. Anyone willing to pay the price for the minimum-latency behaviour should set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool such as setserial (e.g. setserial /dev/ttyUSB0 low_latency). Note that since commit 0cbd81a9 ("USB: ftdi_sio: remove tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but to set a minimal latency timer. Reported-by:
Antoine Aubert <a.aubert@overkiz.com> Fixes: 557aaa7f ("ft232: support the ASYNC_LOW_LATENCY flag") Signed-off-by:
-
Johan Hovold authored
commit 427c3a95 upstream. Make sure to detect short responses when fetching the modem status in order to avoid parsing uninitialised buffer data and having bits of it leak to user space. Note that we still allow for short 1-byte responses. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reviewed-by:
-
Ken Lin authored
commit 9a593656 upstream. Add new USB IDs for cp2104/5 devices on Bx50v3 boards due to the design change. Signed-off-by:
Ken Lin <yungching0725@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 5182c2cf upstream. Fix another NULL-pointer dereference at open should a malicious device lack an interrupt-in endpoint. Note that the driver has a broken check for an interrupt-in endpoint which means that an interrupt URB has never even been submitted. Fixes: 3f542974 ("USB: Moschip 7840 USB-Serial Driver") Reviewed-by:
-
Javier Martinez Canillas authored
commit abe81f3b upstream. If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/tty/serial/msm_serial.ko | grep alias $ After this patch: $ modinfo drivers/tty/serial/msm_serial.ko | grep alias alias: of:N*T*Cqcom,msm-uartdmC* alias: of:N*T*Cqcom,msm-uartdm alias: of:N*T*Cqcom,msm-uartC* alias: of:N*T*Cqcom,msm-uart Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Acked-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
