- 12 Mar, 2017 38 commits
-
-
Wei Yongjun authored
commit 5939eaf4 upstream. Add the missing platform_driver_unregister() and remove the duplicate platform_device_unregister(force_pdev) in the error handling case. Fixes: 00194826 ("tpm_tis: Clean up the force=1 module parameter") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Reviewed-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Leonard Crestez authored
commit e42a46b6 upstream. It is allowed to call regulator_get with a NULL dev argument (_regulator_get explicitly checks for it) but this causes an error later when printing /sys/kernel/debug/regulator_summary. Fix this by explicitly handling "deviceless" consumers in the debugfs code. Signed-off-by:
Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Suzuki K Poulose authored
commit 4474f4c4 upstream. The stm is automatically enabled when an application sets the policy via ->link() call back by using coresight_enable(), which keeps the refcount of the current users of the STM. However, the unlink() callback issues stm_disable() directly, which leaves the STM turned off, without the coresight layer knowing about it. This prevents any further uses of the STM hardware as the coresight layer still thinks the STM is turned on and doesn't enable the hardware when required. Even manually enabling the STM via sysfs can't really enable the hw. e.g, $ echo 1 > $CS_DEVS/$ETR/enable_sink $ mkdir -p $CONFIG_FS/stp-policy/$source.0/stm_test/ $ echo 32768 65535 > $CONFIG_FS/stp-policy/$source.0/stm_test/channels $ echo 64 > $CS_DEVS/$source/traceid $ ./stm_app Sending 64000 byte blocks of pattern 0 at 0us intervals Success to map channel(32768~32783) to 0xffffa95fa000 Sending on channel 32768 $ dd if=/dev/$ETR of=~/trace.bin.1 597+1 records in 597+1 records out 305920 bytes (306 kB) copied, 0.399952 s, 765 kB/s $ ./stm_app Sending 64000 byte blocks of pattern 0 at 0us intervals Success to map channel(32768~32783) to 0xffff7e9e2000 Sending on channel 32768 $ dd if=/dev/$ETR of=~/trace.bin.2 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.0232083 s, 0.0 kB/s Note that we don't get any data from the ETR for the second session. Also dmesg shows : [ 77.520458] coresight-tmc 20800000.etr: TMC-ETR enabled [ 77.537097] coresight-replicator etr_replicator@20890000: REPLICATOR enabled [ 77.558828] coresight-replicator main_replicator@208a0000: REPLICATOR enabled [ 77.581068] coresight-funnel 208c0000.main_funnel: FUNNEL inport 0 enabled [ 77.602217] coresight-tmc 20840000.etf: TMC-ETF enabled [ 77.618422] coresight-stm 20860000.stm: STM tracing enabled [ 139.554252] coresight-stm 20860000.stm: STM tracing disabled # End of first tracing session [ 146.351135] coresight-tmc 20800000.etr: TMC read start [ 146.514486] coresight-tmc 20800000.etr: TMC read end # Note that the STM is not turned on via stm_generic_link()->coresight_enable() # and hence none of the components are turned on. [ 152.479080] coresight-tmc 20800000.etr: TMC read start [ 152.542632] coresight-tmc 20800000.etr: TMC read end This patch fixes the problem by balancing the unlink operation by using the coresight_disable(), keeping the coresight layer in sync with the hardware state and thus allowing normal usage of the STM component. Fixes: commit 237483aa ("coresight: stm: adding driver for CoreSight STM component") Cc: Pratik Patel <pratikp@codeaurora.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by:
Chunyan Zhang <zhang.chunyan@linaro.org> Reported-by:
Robert Walker <robert.walker@arm.com> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
-
Arnd Bergmann authored
commit 6e017006 upstream. gcc-7 detects that wlanhdr_to_ethhdr() in two drivers calls memcpy() with a destination argument that an earlier function call may have set to NULL: staging/rtl8188eu/core/rtw_recv.c: In function 'wlanhdr_to_ethhdr': staging/rtl8188eu/core/rtw_recv.c:1318:2: warning: argument 1 null where non-null expected [-Wnonnull] staging/rtl8712/rtl871x_recv.c: In function 'r8712_wlanhdr_to_ethhdr': staging/rtl8712/rtl871x_recv.c:649:2: warning: argument 1 null where non-null expected [-Wnonnull] I'm fixing this by adding a NULL pointer check and returning failure from the function, which is hopefully already handled properly. This seems to date back to when the drivers were originally added, so backporting the fix to stable seems appropriate. There are other related realtek drivers in the kernel, but none of them contain a function with a similar name or produce this warning. Fixes: 1cc18a22 ("staging: r8188eu: Add files for new driver - part 5") Fixes: 2865d42c ("staging: r8712u: Add the new driver to the mainline kernel") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Oleg Drokin authored
commit dc7ffefd upstream. This is unbreaking another of those "stealth" janitor patches that got in and subtly broke some things. sv_cpt_data is a pointer to pointer, so need to dereference it twice to allocate the correct structure size. Fixes: 9899cb68 ("Staging: lustre: rpc: Use sizeof type *pointer instead of sizeof type.") CC: Sandhya Bankar <bankarsandhya512@gmail.com> Signed-off-by:
Oleg Drokin <green@linuxhacker.ru> Reviewed-by:
James Simmons <jsimmons@infradead.org> Reviewed-by:
Doug Oucharek <doug.s.oucharek@intel.com> Signed-off-by:
-
Johan Hovold authored
commit 33b8807a upstream. The loopback driver allows the user to set a minimum delay of up to one second to be inserted between test iterations (i.e. request submissions). The delay is currently specified in microseconds and is implemented using udelay. Busy looping for long periods is not just anti-social; udelay must not be used for delays longer than a few milliseconds due to the risk of integer overflow. Replace the broken udelay with a usleep_range with a 100 us range for short delays (< 20 ms) and otherwise revert to using msleep. Fixes: b36f04fa ("greybus: loopback: Convert thread delay to microseconds") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Guenter Roeck authored
commit 82dbe987 upstream. If sensor attributes were never read, the pwm control data has not been initiialized, which can cause wrong driver behavior. Ensure that cached data is current before acting on it. Reported-by:
Kevin Folz <kfolz@evertz.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Guenter Roeck authored
commit 4c7b8ca1 upstream. In IT8620E, after setting pwm control to manual, it was observed that pwm values for fan 4..6 have reversed results (writing 0 results in fans running at full speed, writing 255 results in fans turned off). With the new PWM control, pwm polarity for pwm control 4..6 is specified in its pwm control registers. Those registers are overwritten when setting the pwm mode or the temperature mapping. Do not touch bit 2..6 of pwm control registers on register writes to fix the problem. Signed-off-by:
-
Hui Wang authored
commit 29693efc upstream. On this machine, the micmute button is connected to Line2 of the codec and the micmute led is connected to GPIO2 of the codec. After applying this quirk, both hotkey and led work well. Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 493de342 upstream. Dell Inspiron 17 7000 Gaming laptop needs a similar quirk like Inspiron 7599 to support its subwoofer speaker. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=194191Signed-off-by:
-
Takashi Iwai authored
commit f3ac9f73 upstream. The sequencer FIFO management has a bug that may lead to a corruption (shortage) of the cell linked list. When a sequencer client faces an error at the event delivery, it tries to put back the dequeued cell. When the first queue was put back, this forgot the tail pointer tracking, and the link will be screwed up. Although there is no memory corruption, the sequencer client may stall forever at exit while flushing the pending FIFO cells in snd_seq_pool_done(), as spotted by syzkaller. This patch addresses the missing tail pointer tracking at snd_seq_fifo_cell_putback(). Also the patch makes sure to clear the cell->enxt pointer at snd_seq_fifo_event_in() for avoiding a similar mess-up of the FIFO linked list. Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Takashi Iwai authored
commit 15c75b09 upstream. Currently ctxfi driver tries to set only the 64bit DMA mask on 64bit architectures, and bails out if it fails. This causes a problem on some platforms since the 64bit DMA isn't always guaranteed. We should fall back to the default 32bit DMA when 64bit DMA fails. Fixes: 6d74b86d ("ALSA: ctxfi - Allow 64bit DMA") Signed-off-by:
-
Takashi Iwai authored
commit 71321eb3 upstream. When a user sets a too small ticks with a fine-grained timer like hrtimer, the kernel tries to fire up the timer irq too frequently. This may lead to the condensed locks, eventually the kernel spinlock lockup with warnings. For avoiding such a situation, we define a lower limit of the resolution, namely 1ms. When the user passes a too small tick value that results in less than that, the kernel returns -EINVAL now. Reported-by:
-
Jaroslav Kysela authored
commit e7480b34 upstream. Like for Sunrise Point, the total stream number of Lewisburg's input and output stream exceeds 15 (GCAP is 0x9701), which will cause some streams do not work because of the overflow on SDxCTL.STRM field if using the legacy stream tag allocation method. Fixes: 5cf92c8b ("ALSA: hda - Add Intel Lewisburg device IDs Audio") Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Signed-off-by:
-
Kai-Heng Feng authored
commit 9f1bc2c4 upstream. The issue is the same as "dd9aa335 ALSA: hda/realtek - Can't adjust speaker's volume on a Dell AIO", the output requires to connect to a node with Amp-out capability. Applying the same fixup "ALC298_FIXUP_SPK_VOLUME" can fix the issue. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Alexandre Belloni authored
commit 78162d48 upstream. Enable DMA on uart1 to get a more reliable console. Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Alexandre Belloni authored
commit ef8d02d4 upstream. Enable DMA on usart3 to get a more reliable console. This is especially useful for automation and kernelci were a kernel with PROVE_LOCKING enabled is quite susceptible to character loss, resulting in tests failure. Acked-by:
-
Alexandre Belloni authored
commit e3f0a401 upstream. The Atmel MPDDR controller support LPDDR2 and LPDDR3 memories, add their types. Signed-off-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
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:
-
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:
-
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 2 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:
-
