aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-02-04kbuild: fix the document to use extra-y for vmlinux.ldsMasahiro Yamada1-2/+2
The difference between "always" and "extra-y" is that the targets listed in $(always) are always built, whereas the ones in $(extra-y) are built only when KBUILD_BUILTIN is set. So, "make modules" does not build the targets in $(extra-y). vmlinux.lds is only needed for linking vmlinux. So, adding it to extra-y is more correct. In fact, arch/x86/kernel/Makefile does this. Fix the example code. Signed-off-by: Masahiro Yamada <[email protected]>
2020-02-04kconfig: fix broken dependency in randconfig-generated .configMasahiro Yamada1-1/+1
Running randconfig on arm64 using KCONFIG_SEED=0x40C5E904 (e.g. on v5.5) produces the .config with CONFIG_EFI=y and CONFIG_CPU_BIG_ENDIAN=y, which does not meet the !CONFIG_CPU_BIG_ENDIAN dependency. This is because the user choice for CONFIG_CPU_LITTLE_ENDIAN vs CONFIG_CPU_BIG_ENDIAN is set by randomize_choice_values() after the value of CONFIG_EFI is calculated. When this happens, the has_changed flag should be set. Currently, it takes the result from the last iteration. It should accumulate all the results of the loop. Fixes: 3b9a19e08960 ("kconfig: loop as long as we changed some symbols in randconfig") Reported-by: Vincenzo Frascino <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2020-02-03platform/chrome: cros_ec: Match implementation with headersEnric Balletbo i Serra8-10/+30
The 'cros_ec' core driver is the common interface for the cros_ec transport drivers to do the shared operations to register, unregister, suspend, resume and handle_event. The interface is provided by including the header 'include/linux/platform_data/cros_ec_proto.h', however, instead of have the implementation of these functions in cros_ec_proto.c, it is in 'cros_ec.c', which is a different kernel module. Apart from being a bad practice, this can induce confusions allowing the users of the cros_ec protocol to call these functions. The register, unregister, suspend, resume and handle_event functions *should* only be called by the different transport drivers (i2c, spi, lpc, etc.), so make this a bit less confusing by moving these functions from the public in-kernel space to a private include in platform/chrome, and then, the interface for cros_ec module and for the cros_ec_proto module is clean. Signed-off-by: Enric Balletbo i Serra <[email protected]> Signed-off-by: Benson Leung <[email protected]>
2020-02-03NFS: remove unused macrosAlex Shi1-2/+0
MNT_fhs_status_sz/MNT_fhandle3_sz are never used after they were introduced. So better to remove them. Signed-off-by: Alex Shi <[email protected]> Cc: Trond Myklebust <[email protected]> Cc: Anna Schumaker <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Anna Schumaker <[email protected]>
2020-02-03Merge tag 'char-misc-5.6-rc1-2' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc fix from Greg KH: "Here is a single patch, that fixes up a commit that came in the previous char/misc merge. It fixes a bug in the hpet driver that everyone keeps tripping over in their automated testing. Good thing is, people are catching it. Bad thing it wasn't caught by anyone testing before this. Oh well... This has been in linux-next for a few days with no reported issues" * tag 'char-misc-5.6-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: char: hpet: Fix out-of-bounds read bug
2020-02-03Merge tag 'backlight-next-5.6' of ↵Linus Torvalds4-12/+18
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight Pull backlight updates from Lee Jones: "Fix-ups: - Remove superfluous code in ams369fg06 - Convert over to GPIO descriptor (gpiod) in bd6107 Bug Fixes: - Fix unsigned comparison to less than zero in qcom-wled" * tag 'backlight-next-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight: backlight: qcom-wled: Fix unsigned comparison to zero backlight: bd6107: Convert to use GPIO descriptor backlight: ams369fg06: Drop GPIO include
2020-02-03Merge tag 'mfd-next-5.6' of ↵Linus Torvalds47-416/+2810
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "New Drivers: - Add support for ROHM BD71828 PMICs and GPIOs - Add support for Qualcomm Aqstic Audio Codecs WCD9340 and WCD9341 New Device Support: - Add support for BD71828 to BD70528 RTC driver - Add support for Intel's Jasper Lake to LPSS PCI New Functionality: - Add support for Power Key to ROHM BD71828 - Add support for Clocks to ROHM BD71828 - Add support for GPIOs to Dialog DA9062 - Add support for USB PD Notify to ChromiumOS EC - Allow callers to specify args when requesting regmap lookup; syscon Fix-ups: - Improve error handling and sanity checking; atmel-hlcdc, dln2 - Device Tree support/documentation; bd71828, da9062, xylon,logicvc, ab8500, max14577, atmel-usart - Match devices using platform IDs; bd7xxxx - Refactor BD718x7 regulator component; bd718x7-regulator - Use standard interfaces/helpers; syscon, sm501 - Trivial (whitespace, spelling, etc); ab8500-core, Kconfig - Remove unused code; db8500-prcmu, tqmx86 - Wait until boot has finished before accessing registers; madera-core - Provide missing register value defaults; cs47l15-tables - Allow more time for hardware to reset; madera-core Bug Fixes: - Fix erroneous register values; rohm-bd70528 - Fix register volatility; axp20x, rn5t618 - Fix Kconfig dependencies; MFD_MAX77650 - Fix incorrect compatible string; da9062-core - Fix syscon_regmap_lookup_by_phandle_args() stub; syscon" * tag 'mfd-next-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (41 commits) mfd: syscon: Fix syscon_regmap_lookup_by_phandle_args() dummy mfd: wcd934x: Add support to wcd9340/wcd9341 codec mfd: syscon: Add arguments support for syscon reference mfd: rn5t618: Mark ADC control register volatile dt-bindings: atmel-usart: Add microchip,sam9x60-{usart, dbgu} dt-bindings: atmel-usart: Remove wildcard mfd: cros_ec: Add cros-usbpd-notify subdevice mfd: da9062: Fix watchdog compatible string mfd: madera: Allow more time for hardware reset mfd: cs47l15: Add missing register default mfd: madera: Wait for boot done before accessing any other registers mfd: Kconfig: Rename Samsung to lowercase mfd: tqmx86: remove set but not used variable 'i2c_ien' mfd: dbx500-prcmu: Drop DSI pll clock functions mfd: dbx500-prcmu: Drop set_display_clocks() mfd: max77650: Select REGMAP_IRQ in Kconfig mfd: axp20x: Mark AXP20X_VBUS_IPSOUT_MGMT as volatile mfd: ab8500: Fix ab8500-clk typo mfd: intel-lpss: Add Intel Jasper Lake PCI IDs dt-bindings: mfd: max14577: Add reference to max14040_battery.txt descriptions ...
2020-02-03Merge tag 'hyperv-next-signed' of ↵Linus Torvalds15-108/+574
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull Hyper-V updates from Sasha Levin: - Most of the commits here are work to enable host-initiated hibernation support by Dexuan Cui. - Fix for a warning shown when host sends non-aligned balloon requests by Tianyu Lan. * tag 'hyperv-next-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: hv_utils: Add the support of hibernation hv_utils: Support host-initiated hibernation request hv_utils: Support host-initiated restart request Tools: hv: Reopen the devices if read() or write() returns errors video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs. Drivers: hv: vmbus: Ignore CHANNELMSG_TL_CONNECT_RESULT(23) video: hyperv_fb: Fix hibernation for the deferred IO feature Input: hyperv-keyboard: Add the support of hibernation hv_balloon: Balloon up according to request page number
2020-02-03block, bfq: clarify the goal of bfq_split_bfqq()Paolo Valente1-0/+2
The exact, general goal of the function bfq_split_bfqq() is not that apparent. Add a comment to make it clear. Tested-by: Oleksandr Natalenko <[email protected]> Signed-off-by: Paolo Valente <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-02-03block, bfq: get a ref to a group when adding it to a service treePaolo Valente3-3/+12
BFQ schedules generic entities, which may represent either bfq_queues or groups of bfq_queues. When an entity is inserted into a service tree, a reference must be taken, to make sure that the entity does not disappear while still referred in the tree. Unfortunately, such a reference is mistakenly taken only if the entity represents a bfq_queue. This commit takes a reference also in case the entity represents a group. Tested-by: Oleksandr Natalenko <[email protected]> Tested-by: Chris Evich <[email protected]> Signed-off-by: Paolo Valente <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-02-03block, bfq: remove ifdefs from around gets/puts of bfq groupsPaolo Valente3-5/+6
ifdefs around gets and puts of bfq groups reduce readability, remove them. Tested-by: Oleksandr Natalenko <[email protected]> Reported-by: Jens Axboe <[email protected]> Signed-off-by: Paolo Valente <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-02-03block, bfq: extend incomplete name of field on_stPaolo Valente4-7/+10
The flag on_st in the bfq_entity data structure is true if the entity is on a service tree or is in service. Yet the name of the field, confusingly, does not mention the second, very important case. Extend the name to mention the second case too. Tested-by: Oleksandr Natalenko <[email protected]> Signed-off-by: Paolo Valente <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-02-03block, bfq: get extra ref to prevent a queue from being freed during a group ↵Paolo Valente1-0/+8
move In bfq_bfqq_move(), the bfq_queue, say Q, to be moved to a new group may happen to be deactivated in the scheduling data structures of the source group (and then activated in the destination group). If Q is referred only by the data structures in the source group when the deactivation happens, then Q is freed upon the deactivation. This commit addresses this issue by getting an extra reference before the possible deactivation, and releasing this extra reference after Q has been moved. Tested-by: Chris Evich <[email protected]> Tested-by: Oleksandr Natalenko <[email protected]> Signed-off-by: Paolo Valente <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-02-03block, bfq: do not insert oom queue into position treePaolo Valente1-0/+4
BFQ maintains an ordered list, implemented with an RB tree, of head-request positions of non-empty bfq_queues. This position tree, inherited from CFQ, is used to find bfq_queues that contain I/O close to each other. BFQ merges these bfq_queues into a single shared queue, if this boosts throughput on the device at hand. There is however a special-purpose bfq_queue that does not participate in queue merging, the oom bfq_queue. Yet, also this bfq_queue could be wrongly added to the position tree. So bfqq_find_close() could return the oom bfq_queue, which is a source of further troubles in an out-of-memory situation. This commit prevents the oom bfq_queue from being inserted into the position tree. Tested-by: Patrick Dung <[email protected]> Tested-by: Oleksandr Natalenko <[email protected]> Signed-off-by: Paolo Valente <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-02-03block, bfq: do not plug I/O for bfq_queues with no proc refsPaolo Valente1-0/+12
Commit 478de3380c1c ("block, bfq: deschedule empty bfq_queues not referred by any process") fixed commit 3726112ec731 ("block, bfq: re-schedule empty queues if they deserve I/O plugging") by descheduling an empty bfq_queue when it remains with not process reference. Yet, this still left a case uncovered: an empty bfq_queue with not process reference that remains in service. This happens for an in-service sync bfq_queue that is deemed to deserve I/O-dispatch plugging when it remains empty. Yet no new requests will arrive for such a bfq_queue if no process sends requests to it any longer. Even worse, the bfq_queue may happen to be prematurely freed while still in service (because there may remain no reference to it any longer). This commit solves this problem by preventing I/O dispatch from being plugged for the in-service bfq_queue, if the latter has no process reference (the bfq_queue is then prevented from remaining in service). Fixes: 3726112ec731 ("block, bfq: re-schedule empty queues if they deserve I/O plugging") Tested-by: Oleksandr Natalenko <[email protected]> Reported-by: Patrick Dung <[email protected]> Tested-by: Patrick Dung <[email protected]> Signed-off-by: Paolo Valente <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-02-03fibmap: Reject negative block numbersCarlos Maiolino1-0/+3
FIBMAP receives an integer from userspace which is then implicitly converted into sector_t to be passed to bmap(). No check is made to ensure userspace didn't send a negative block number, which can end up in an underflow, and returning to userspace a corrupted block address. As a side-effect, the underflow caused by a negative block here, will trigger the WARN() in iomap_bmap_actor(), which is how this issue was first discovered. Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Al Viro <[email protected]>
2020-02-03fibmap: Use bmap instead of ->bmap method in ioctl_fibmapCarlos Maiolino1-10/+20
Now we have the possibility of proper error return in bmap, use bmap() function in ioctl_fibmap() instead of calling ->bmap method directly. Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Al Viro <[email protected]>
2020-02-03ecryptfs: drop direct calls to ->bmapCarlos Maiolino1-10/+6
Replace direct ->bmap calls by bmap() method. Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Al Viro <[email protected]>
2020-02-03cachefiles: drop direct usage of ->bmap method.Carlos Maiolino1-13/+14
Replace the direct usage of ->bmap method by a bmap() call. Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Al Viro <[email protected]>
2020-02-03fs: Enable bmap() function to properly return errorsCarlos Maiolino6-36/+70
By now, bmap() will either return the physical block number related to the requested file offset or 0 in case of error or the requested offset maps into a hole. This patch makes the needed changes to enable bmap() to proper return errors, using the return value as an error return, and now, a pointer must be passed to bmap() to be filled with the mapped physical block. It will change the behavior of bmap() on return: - negative value in case of error - zero on success or map fell into a hole In case of a hole, the *block will be zero too Since this is a prep patch, by now, the only error return is -EINVAL if ->bmap doesn't exist. Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Al Viro <[email protected]>
2020-02-03drm/nouveau/kms/gv100-: avoid sending a core update until the first modesetBen Skeggs2-6/+2
The OR routing logic in NVKM does not expect to receive supervisor interrupts until the DD has provided consistent information on the ORs it's using and the EVO/NVD assembly state to match. The combination of changing window ownership + core channel update during display init triggered a situation where we'd disconnect an OR from the pad it was meant to still be driving on some systems. Signed-off-by: Ben Skeggs <[email protected]>
2020-02-03drm/nouveau/kms/gv100-: move window ownership setup into modesetting pathBen Skeggs4-6/+44
For various complicated reasons, we need to avoid sending a core update method during display init. Something, which we've been required to do on GV100 and up because we've been assigning windows to heads there and the HW is rather picky about when that's allowed. This moves window assignment into the modesetting path at a point where it's much safer to send our first update methods to NVDisplay. Signed-off-by: Ben Skeggs <[email protected]>
2020-02-03drm/nouveau/disp/gv100-: halt NV_PDISP_FE_RM_INTR_STAT_CTRL_DISP_ERROR stormsBen Skeggs1-0/+6
Signed-off-by: Ben Skeggs <[email protected]>
2020-02-03i2c: designware: Add ACPI HID for Hisilicon Hip08-Lite I2C controllerHanjun Guo1-0/+1
Add ACPI HID HISI02A3 for Hisilicon Hip08 Lite, which has different clock frequency from Hip08 for I2C controller. Tested-by: Sheng Feng <[email protected]> Signed-off-by: Hanjun Guo <[email protected]> Acked-by: Nikula <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-02-03ACPI / APD: Add clock frequency for Hisilicon Hip08-Lite I2C controllerHanjun Guo1-0/+6
I2C clock frequency of Designware ip for Hisilicon Hip08 Lite is 125M, use a new ACPI HID to enable it. Tested-by: Sheng Feng <[email protected]> Signed-off-by: Hanjun Guo <[email protected]> Reviewed-by: Jarkko Nikula <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-02-03Documentation: admin-guide: PM: Update sleep states documentationRafael J. Wysocki2-96/+59
There is some information in Documentation/power/interface.rst that is still missing from Documentation/admin-guide/pm/sleep-states.rst and really should be present in there, so update the latter by adding that information to it and delete the former (as it becomes redundant after that and it is somewhat outdated). While at it, clean up some assorted pieces of sleep-states.rst a bit. Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-02-03intel_idle: Introduce 'states_off' module parameterRafael J. Wysocki2-4/+38
In certain system configurations it may not be desirable to use some C-states assumed to be available by intel_idle and the driver needs to be prevented from using them even before the cpuidle sysfs interface becomes accessible to user space. Currently, the only way to achieve that is by setting the 'max_cstate' module parameter to a value lower than the index of the shallowest of the C-states in question, but that may be overly intrusive, because it effectively makes all of the idle states deeper than the 'max_cstate' one go away (and the C-state to avoid may be in the middle of the range normally regarded as available). To allow that limitation to be overcome, introduce a new module parameter called 'states_off' to represent a list of idle states to be disabled by default in the form of a bitmask and update the documentation to cover it. Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-02-03intel_idle: Introduce 'use_acpi' module parameterRafael J. Wysocki2-6/+18
For diagnostics, it is generally useful to be able to make intel_idle take the system's ACPI tables into consideration even if that is not required for the processor model in there, so introduce a new module parameter, 'use_acpi', to make that happen and update the documentation to cover it. While at it, fix the 'no_acpi' module parameter name in the documentation. Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-02-03ovl: fix lseek overflow on 32bitMiklos Szeredi1-1/+1
ovl_lseek() is using ssize_t to return the value from vfs_llseek(). On a 32-bit kernel ssize_t is a 32-bit signed int, which overflows above 2 GB. Assign the return value of vfs_llseek() to loff_t to fix this. Reported-by: Boris Gjenero <[email protected]> Fixes: 9e46b840c705 ("ovl: support stacked SEEK_HOLE/SEEK_DATA") Cc: <[email protected]> # v4.19 Signed-off-by: Miklos Szeredi <[email protected]>
2020-02-03rxrpc: Fix NULL pointer deref due to call->conn being cleared on disconnectDavid Howells5-24/+15
When a call is disconnected, the connection pointer from the call is cleared to make sure it isn't used again and to prevent further attempted transmission for the call. Unfortunately, there might be a daemon trying to use it at the same time to transmit a packet. Fix this by keeping call->conn set, but setting a flag on the call to indicate disconnection instead. Remove also the bits in the transmission functions where the conn pointer is checked and a ref taken under spinlock as this is now redundant. Fixes: 8d94aa381dab ("rxrpc: Calls shouldn't hold socket refs") Signed-off-by: David Howells <[email protected]>
2020-02-03irqchip/gic-v3-its: Reference to its_invall_cmd descriptor when building INVALLZenghui Yu1-1/+1
It looks like an obvious mistake to use its_mapc_cmd descriptor when building the INVALL command block. It so far worked by luck because both its_mapc_cmd.col and its_invall_cmd.col sit at the same offset of the ITS command descriptor, but we should not rely on it. Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Signed-off-by: Zenghui Yu <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-02-03mfd: syscon: Fix syscon_regmap_lookup_by_phandle_args() dummyGeert Uytterhoeven1-1/+1
If CONFIG_MFD_SYSCON=n: include/linux/mfd/syscon.h:54:23: warning: ‘syscon_regmap_lookup_by_phandle_args’ defined but not used [-Wunused-function] Fix this by adding the missing inline keyword. Fixes: 6a24f567af4accef ("mfd: syscon: Add arguments support for syscon reference") Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Lee Jones <[email protected]>
2020-02-03m68knommu: fix memcpy() out of bounds warning in get_user()Greg Ungerer1-8/+11
Newer versions of gcc are giving warnings in the non-MMU m68k version of the get_user() macro: ./arch/m68k/include/asm/string.h:72:25: warning: ‘__builtin_memcpy’ forming offset [3, 4] is out of the bounds [0, 2] of object ‘__gu_val’ with type ‘short unsigned int’ [-Warray-bounds] The warnings are generated when smaller sized variables are used as the result of user space pointers to larger values. For example a short/2-byte variable stores the result of a user space int (4-byte) pointer. The warning is in the 8-byte branch of get_user() - even though that branch is not the taken branch in the warning cases. Refactor the 8-byte branch of get_user() so that it uses a correctly formed union type to read and write the source and destination objects. Keep using the memcpy() just in case the user space pointer is not naturaly aligned (not required for ColdFire, but needed for early 68000). Signed-off-by: Greg Ungerer <[email protected]>
2020-02-03dmaengine: Cleanups for the slave <-> channel symlink supportPeter Ujfalusi1-9/+9
No need to use goto to jump over the return chan ? chan : ERR_PTR(-EPROBE_DEFER); We can just revert the check and return right there. Do not fail the channel request if the chan->name allocation fails, but print a warning about it. Change the dev_err to dev_warn if sysfs_create_link() fails as it is not fatal. Only attempt to remove the DMA_SLAVE_NAME symlink if it is created - or it was attempted to be created. Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-02-03dmaengine: fix null ptr check for __dma_async_device_channel_register()Dave Jiang1-0/+3
Add check to pointer after assignment before accessing members. Fixes: d2fb0a043838: ("dmaengine: break out channel registration") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/158049351973.45445.3291586905226032744.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <[email protected]>
2020-02-03dmaengine: idxd: fix boolconv.cocci warningskbuild test robot1-1/+1
Remove unneeded conversion to bool Generated by: scripts/coccinelle/misc/boolconv.cocci CC: Dave Jiang <[email protected]> Signed-off-by: kbuild test robot <[email protected]> Signed-off-by: Julia Lawall <[email protected]> Acked-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2001301543150.7476@hadrien Signed-off-by: Vinod Koul <[email protected]>
2020-02-02Merge branch 'Fix-reconnection-latency-caused-by-FIN-ACK-handling-race'Jakub Kicinski5-1/+196
SeongJae Park says: ==================== Fix reconnection latency caused by FIN/ACK handling race The first patch fixes the problem by adjusting the first resend delay of the SYN in the case. The second one adds a user space test to reproduce this problem. From v2 (https://lore.kernel.org/linux-kselftest/[email protected]/) - Use TCP_TIMEOUT_MIN as reduced delay (Neal Cardwall) - Add Reviewed-by and Signed-off-by from Eric Dumazet From v1 (https://lore.kernel.org/linux-kselftest/[email protected]/) - Drop the trivial comment fix patch (Eric Dumazet) - Limit the delay adjustment to only the first SYN resend (Eric Dumazet) - selftest: Avoid use of hard-coded port number (Eric Dumazet) - Explain RST/ACK and FIN/ACK has no big difference (Neal Cardwell) ==================== Signed-off-by: Jakub Kicinski <[email protected]>
2020-02-02selftests: net: Add FIN_ACK processing order related latency spike testSeongJae Park4-0/+189
This commit adds a test for FIN_ACK process races related reconnection latency spike issues. The issue has described and solved by the previous commit ("tcp: Reduce SYN resend delay if a suspicous ACK is received"). The test program is configured with a server and a client process. The server creates and binds a socket to a port that dynamically allocated, listen on it, and start a infinite loop. Inside the loop, it accepts connection, reads 4 bytes from the socket, and closes the connection. The client is constructed as an infinite loop. Inside the loop, it creates a socket with LINGER and NODELAY option, connect to the server, send 4 bytes data, try read some data from server. After the read() returns, it measure the latency from the beginning of this loop to this point and if the latency is larger than 1 second (spike), print a message. Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: SeongJae Park <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-02-02tcp: Reduce SYN resend delay if a suspicous ACK is receivedSeongJae Park1-1/+7
When closing a connection, the two acks that required to change closing socket's status to FIN_WAIT_2 and then TIME_WAIT could be processed in reverse order. This is possible in RSS disabled environments such as a connection inside a host. For example, expected state transitions and required packets for the disconnection will be similar to below flow. 00 (Process A) (Process B) 01 ESTABLISHED ESTABLISHED 02 close() 03 FIN_WAIT_1 04 ---FIN--> 05 CLOSE_WAIT 06 <--ACK--- 07 FIN_WAIT_2 08 <--FIN/ACK--- 09 TIME_WAIT 10 ---ACK--> 11 LAST_ACK 12 CLOSED CLOSED In some cases such as LINGER option applied socket, the FIN and FIN/ACK will be substituted to RST and RST/ACK, but there is no difference in the main logic. The acks in lines 6 and 8 are the acks. If the line 8 packet is processed before the line 6 packet, it will be just ignored as it is not a expected packet, and the later process of the line 6 packet will change the status of Process A to FIN_WAIT_2, but as it has already handled line 8 packet, it will not go to TIME_WAIT and thus will not send the line 10 packet to Process B. Thus, Process B will left in CLOSE_WAIT status, as below. 00 (Process A) (Process B) 01 ESTABLISHED ESTABLISHED 02 close() 03 FIN_WAIT_1 04 ---FIN--> 05 CLOSE_WAIT 06 (<--ACK---) 07 (<--FIN/ACK---) 08 (fired in right order) 09 <--FIN/ACK--- 10 <--ACK--- 11 (processed in reverse order) 12 FIN_WAIT_2 Later, if the Process B sends SYN to Process A for reconnection using the same port, Process A will responds with an ACK for the last flow, which has no increased sequence number. Thus, Process A will send RST, wait for TIMEOUT_INIT (one second in default), and then try reconnection. If reconnections are frequent, the one second latency spikes can be a big problem. Below is a tcpdump results of the problem: 14.436259 IP 127.0.0.1.45150 > 127.0.0.1.4242: Flags [S], seq 2560603644 14.436266 IP 127.0.0.1.4242 > 127.0.0.1.45150: Flags [.], ack 5, win 512 14.436271 IP 127.0.0.1.45150 > 127.0.0.1.4242: Flags [R], seq 2541101298 /* ONE SECOND DELAY */ 15.464613 IP 127.0.0.1.45150 > 127.0.0.1.4242: Flags [S], seq 2560603644 This commit mitigates the problem by reducing the delay for the next SYN if the suspicous ACK is received while in SYN_SENT state. Following commit will add a selftest, which can be also helpful for understanding of this issue. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: SeongJae Park <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-02-02MAINTAINERS: correct entries for ISDN/mISDN sectionLukas Bulwahn1-2/+4
Commit 6d97985072dc ("isdn: move capi drivers to staging") cleaned up the isdn drivers and split the MAINTAINERS section for ISDN, but missed to add the terminal slash for the two directories mISDN and hardware. Hence, all files in those directories were not part of the new ISDN/mISDN SUBSYSTEM, but were considered to be part of "THE REST". Rectify the situation, and while at it, also complete the section with two further build files that belong to that subsystem. This was identified with a small script that finds all files belonging to "THE REST" according to the current MAINTAINERS file, and I investigated upon its output. Fixes: 6d97985072dc ("isdn: move capi drivers to staging") Signed-off-by: Lukas Bulwahn <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-02-02Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds1-2/+2
Pull sparc fix from David Miller: "adjtimex regression fix from Arnd" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc64: fix adjtimex regression
2020-02-02Merge tag 'leds-5.6-rc1' of ↵Linus Torvalds13-94/+425
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds Pull LED updates from Pavel Machek: - New driver for TI TPS6105X - Add managed API to get a LED from a device driver - Misc fixes and updates * tag 'leds-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: (22 commits) leds: lm3692x: Disable chip on brightness 0 leds: lm3692x: Split out lm3692x_leds_disable leds: lm3692x: Move lm3692x_init and rename to lm3692x_leds_enable leds: lm3692x: Make sure we don't exceed the maximum LED current dt: bindings: lm3692x: Add led-max-microamp property leds: lm3692x: Allow to configure over voltage protection dt: bindings: lm3692x: Add ti,ovp-microvolt property leds: populate the device's of_node leds: Add managed API to get a LED from a device driver leds: Add of_led_get() and led_put() leds: lm3532: add pointer to documentation and fix typo leds: lm3532: use extended registration so that LED can be used for backlight leds: lm3642: remove warnings for bad strtol, cleanup gotos leds: rb532: cleanup whitespace ledtrig-pattern: fix email address quoting in MODULE_AUTHOR() dt-bindings: mfd: update TI tps6105x chip bindings leds: tps6105x: add driver for MFD chip LED mode led: max77650: add of_match table leds: bd2802: Convert to use GPIO descriptors leds: pca963x: Fix open-drain initialization ...
2020-02-02Merge branch 'pcmcia-next' of ↵Linus Torvalds2-348/+311
git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux Pull pcmcia updates from Dominik Brodowski: "This is a series co-developed by Simon Geis and Lukas Panzer to clean up the i82092 PCMCIA device driver" * 'pcmcia-next' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux: PCMCIA/i82092: remove #if 0 block PCMCIA/i82092: delete enter/leave macro PCMCIA/i82092: include <linux/io.h> instead of <asm/io.h> PCMCIA/i82092: shorten the lines with over 80 characters PCMCIA/i82092: move assignment out of if condition PCMCIA/i82092: change code indentation PCMCIA/i82092: insert blank line after declarations PCMCIA/i82092: remove braces around single statement blocks PCMCIA/i82092: add/remove spaces to improve readability PCMCIA/i82092: use dev_<level> instead of printk
2020-02-02btrfs: do not zero f_bavail if we have available spaceJosef Bacik1-1/+9
There was some logic added a while ago to clear out f_bavail in statfs() if we did not have enough free metadata space to satisfy our global reserve. This was incorrect at the time, however didn't really pose a problem for normal file systems because we would often allocate chunks if we got this low on free metadata space, and thus wouldn't really hit this case unless we were actually full. Fast forward to today and now we are much better about not allocating metadata chunks all of the time. Couple this with d792b0f19711 ("btrfs: always reserve our entire size for the global reserve") which now means we'll easily have a larger global reserve than our free space, we are now more likely to trip over this while still having plenty of space. Fix this by skipping this logic if the global rsv's space_info is not full. space_info->full is 0 unless we've attempted to allocate a chunk for that space_info and that has failed. If this happens then the space for the global reserve is definitely sacred and we need to report b_avail == 0, but before then we can just use our calculated b_avail. Reported-by: Martin Steigerwald <[email protected]> Fixes: ca8a51b3a979 ("btrfs: statfs: report zero available if metadata are exhausted") CC: [email protected] # 4.5+ Reviewed-by: Qu Wenruo <[email protected]> Tested-By: Martin Steigerwald <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2020-02-02ASoC: tegra: Revert 24 and 32 bit supportJon Hunter1-20/+5
Commit f3ee99087c8ca0ecfdd549ef5a94f557c42d5428 ("ASoC: tegra: Allow 24bit and 32bit samples") added 24-bit and 32-bit support for to the Tegra30 I2S driver. However, there are two additional commits that are also needed to get 24-bit and 32-bit support to work correctly. These commits are not yet applied because there are still some review comments that need to be addressed. With only this change applied, 24-bit and 32-bit support is advertised by the I2S driver, but it does not work and the audio is distorted. Therefore, revert this patch for now until the other changes are also ready. Furthermore, a clock issue with 24-bit support has been identified with this change and so if we revert this now, we can also fix that in the updated version. Reported-by: Dmitry Osipenko <[email protected]> Signed-off-by: Jon Hunter <[email protected]> Tested-by: Dmitry Osipenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Cc: [email protected]
2020-02-02ASoC: SOF: Intel: add PCI ID for JasperLakeYong Zhi1-0/+2
Mirror ID added for legacy HDaudio. Signed-off-by: Yong Zhi <[email protected]> Signed-off-by: Divagar Mohandass <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-02-02sparc64: fix adjtimex regressionArnd Bergmann1-2/+2
Anatoly Pugachev reported one of the y2038 patches to introduce a fatal bug from a stupid typo: [ 96.384129] watchdog: BUG: soft lockup - CPU#8 stuck for 22s! ... [ 96.385624] [0000000000652ca4] handle_mm_fault+0x84/0x320 [ 96.385668] [0000000000b6f2bc] do_sparc64_fault+0x43c/0x820 [ 96.385720] [0000000000407754] sparc64_realfault_common+0x10/0x20 [ 96.385769] [000000000042fa28] __do_sys_sparc_clock_adjtime+0x28/0x80 [ 96.385819] [00000000004307f0] sys_sparc_clock_adjtime+0x10/0x20 [ 96.385866] [0000000000406294] linux_sparc_syscall+0x34/0x44 Fix the code to dereference the correct pointer again. Reported-by: Anatoly Pugachev <[email protected]> Tested-by: Anatoly Pugachev <[email protected]> Fixes: 251ec1c159e4 ("y2038: sparc: remove use of struct timex") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-02-02efi/x86: Fix boot regression on systems with invalid memmap entriesArd Biesheuvel1-1/+1
In efi_clean_memmap(), we do a pass over the EFI memory map to remove bogus entries that may be returned on certain systems. This recent commit: 1db91035d01aa8bf ("efi: Add tracking for dynamically allocated memmaps") refactored this code to pass the input to efi_memmap_install() via a temporary struct on the stack, which is populated using an initializer which inadvertently defines the value of its size field in terms of its desc_size field, which value cannot be relied upon yet in the initializer itself. Fix this by using efi.memmap.desc_size instead, which is where we get the value for desc_size from in the first place. Reported-by: Jörg Otte <[email protected]> Tested-by: Jörg Otte <[email protected]> Tested-by: Dan Williams <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lore.kernel.org/r/[email protected]
2020-02-02ALSA: hdsp: Make the firmware loading ioctl a bit more readableTakashi Iwai1-4/+3
The firmware loading ioctl that is implemented for hdsp hwdep device takes the reference of the address pointer, hence the current code is rather confusing. Also, due to the recent change in uapi header, sparse also complains about the cast. This patch tries to improve the readability by converting the straightforward copy_from_user of the whole struct (which contains only the pointer). Fixes: d63e63d42107 ("ALSA: hdsp: Make uapi/hdsp.h compilable again") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-02-02ALSA: emu10k1: Fix annotation and cast for the recent uapi header changeTakashi Iwai1-79/+101
The recent sound/emu10k1.h uapi header change by the commit 2e4688676392 ("ALSA: emu10k1: Make uapi/emu10k1.h compilable again") made sparse angry because of the inconsistency of __user annotation and the own ctl id struct that were changed in uapi header. This patch addresses those by adjusting the cast and annotations properly again. Fixes: 2e4688676392 ("ALSA: emu10k1: Make uapi/emu10k1.h compilable again") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.