user/sven/linux.git, branch v4.9.159

Linux 4.9.159

2019-02-20T09:18:35Z

Revert "scsi: aic94xx: fix module loading"

2019-02-20T09:18:35Z

This reverts commit d26358590bb2be063453412cfeec5afefe55d030 which is commit 42caa0edabd6a0a392ec36a5f0943924e4954311 upstream. It's not needed in the 4.9.y tree, my fault for backporting it that far. Reported-by: James Bottomley Cc: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define

2019-02-20T09:18:35Z

commit da360299b6734135a5f66d7db458dcc7801c826a upstream. This fixes a compile problem of some user space applications by not including linux/libc-compat.h in uapi/if_ether.h. linux/libc-compat.h checks which "features" the header files, included from the libc, provide to make the Linux kernel uapi header files only provide no conflicting structures and enums. If a user application mixes kernel headers and libc headers it could happen that linux/libc-compat.h gets included too early where not all other libc headers are included yet. Then the linux/libc-compat.h would not prevent all the redefinitions and we run into compile problems. This patch removes the include of linux/libc-compat.h from uapi/if_ether.h to fix the recently introduced case, but not all as this is more or less impossible. It is no problem to do the check directly in the if_ether.h file and not in libc-compat.h as this does not need any fancy glibc header detection as glibc never provided struct ethhdr and should define __UAPI_DEF_ETHHDR by them self when they will provide this. The following test program did not compile correctly any more: #include #include #include int main(void) { return 0; } Fixes: 6926e041a892 ("uapi/if_ether.h: prevent redefinition of struct ethhdr") Reported-by: Guillaume Nault Cc: # 4.15 Signed-off-by: Hauke Mehrtens Signed-off-by: David S. Miller Cc: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

mm: stop leaking PageTables

2019-02-20T09:18:34Z

commit b0b9b3df27d100a975b4e8818f35382b64a5e35c upstream. 4.10-rc loadtest (even on x86, and even without THPCache) fails with "fork: Cannot allocate memory" or some such; and /proc/meminfo shows PageTables growing. Commit 953c66c2b22a ("mm: THP page cache support for ppc64") that got merged in rc1 removed the freeing of an unused preallocated pagetable after do_fault_around() has called map_pages(). This is usually a good optimization, so that the followup doesn't have to reallocate one; but it's not sufficient to shift the freeing into alloc_set_pte(), since there are failure cases (most commonly VM_FAULT_RETRY) which never reach finish_fault(). Check and free it at the outer level in do_fault(), then we don't need to worry in alloc_set_pte(), and can restore that to how it was (I cannot find any reason to pte_free() under lock as it was doing). And fix a separate pagetable leak, or crash, introduced by the same change, that could only show up on some ppc64: why does do_set_pmd()'s failure case attempt to withdraw a pagetable when it never deposited one, at the same time overwriting (so leaking) the vmf->prealloc_pte? Residue of an earlier implementation, perhaps? Delete it. Fixes: 953c66c2b22a ("mm: THP page cache support for ppc64") Cc: Aneesh Kumar K.V Cc: Kirill A. Shutemov Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Michael Neuling Cc: Paul Mackerras Cc: Balbir Singh Cc: Andrew Morton Signed-off-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Minchan Kim Signed-off-by: Greg Kroah-Hartman

pinctrl: msm: fix gpio-hog related boot issues

2019-02-20T09:18:34Z

commit a86caa9ba5d70696ceb35d1d39caa20d8b641387 upstream. Sven Eckelmann reported an issue with the current IPQ4019 pinctrl. Setting up any gpio-hog in the device-tree for his device would "kill the bootup completely": | [ 0.477838] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe | [ 0.499828] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferring probe | [ 1.298883] requesting hog GPIO enable USB2 power (chip 1000000.pinctrl, offset 58) failed, -517 | [ 1.299609] gpiochip_add_data: GPIOs 0..99 (1000000.pinctrl) failed to register | [ 1.308589] ipq4019-pinctrl 1000000.pinctrl: Failed register gpiochip | [ 1.316586] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe | [ 1.322415] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferri This was also verified on a RT-AC58U (IPQ4018) which would no longer boot, if a gpio-hog was specified. (Tried forcing the USB LED PIN (GPIO0) to high.). The problem is that Pinctrl+GPIO registration is currently peformed in the following order in pinctrl-msm.c: 1. pinctrl_register() 2. gpiochip_add() 3. gpiochip_add_pin_range() The actual error code -517 == -EPROBE_DEFER is coming from pinctrl_get_device_gpio_range(), which is called through: gpiochip_add of_gpiochip_add of_gpiochip_scan_gpios gpiod_hog gpiochip_request_own_desc __gpiod_request chip->request gpiochip_generic_request pinctrl_gpio_request pinctrl_get_device_gpio_range pinctrl_get_device_gpio_range() is unable to find any valid pin ranges, since nothing has been added to the pinctrldev_list yet. so the range can't be found, and the operation fails with -EPROBE_DEFER. This patch fixes the issue by adding the "gpio-ranges" property to the pinctrl device node of all upstream Qcom SoC. The pin ranges are then added by the gpio core. In order to remain compatible with older, existing DTs (and ACPI) a check for the "gpio-ranges" property has been added to msm_gpio_init(). This prevents the driver of adding the same entry to the pinctrldev_list twice. Reported-by: Sven Eckelmann Tested-by: Sven Eckelmann [ipq4019] Reviewed-by: Bjorn Andersson Signed-off-by: Christian Lamparter Signed-off-by: Linus Walleij Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman

netfilter: nf_tables: fix mismatch in big-endian system

2019-02-20T09:18:34Z

commit 10596608c4d62cb8c1c2b806debcbd32fe657e71 upstream. Currently, there are two different methods to store an u16 integer to the u32 data register. For example: u32 *dest = ®s->data[priv->dreg]; 1. *dest = 0; *(u16 *) dest = val_u16; 2. *dest = val_u16; For method 1, the u16 value will be stored like this, either in big-endian or little-endian system: 0 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+ | Value | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+ For method 2, in little-endian system, the u16 value will be the same as listed above. But in big-endian system, the u16 value will be stored like this: 0 15 31 +-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Value | +-+-+-+-+-+-+-+-+-+-+-+-+ So later we use "memcmp(®s->data[priv->sreg], data, 2);" to do compare in nft_cmp, nft_lookup expr ..., method 2 will get the wrong result in big-endian system, as 0~15 bits will always be zero. For the similar reason, when loading an u16 value from the u32 data register, we should use "*(u16 *) sreg;" instead of "(u16)*sreg;", the 2nd method will get the wrong value in the big-endian system. So introduce some wrapper functions to store/load an u8 or u16 integer to/from the u32 data register, and use them in the right place. Signed-off-by: Liping Zhang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

usb: dwc2: Remove unnecessary kfree

2019-02-20T09:18:34Z

commit cd4b1e34655d46950c065d9284b596cd8d7b28cd upstream. This shouldn't be freed by the HCD as it is owned by the core and allocated with devm_kzalloc. Signed-off-by: John Youn Signed-off-by: Felipe Balbi Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

kaweth: use skb_cow_head() to deal with cloned skbs

2019-02-20T09:18:34Z

commit 39fba7835aacda65284a86e611774cbba71dac20 upstream. We can use skb_cow_head() to properly deal with clones, especially the ones coming from TCP stack that allow their head being modified. This avoids a copy. Signed-off-by: Eric Dumazet Cc: James Hughes Signed-off-by: David S. Miller Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

ch9200: use skb_cow_head() to deal with cloned skbs

2019-02-20T09:18:34Z

commit 6bc6895bdd6744e0136eaa4a11fbdb20a7db4e40 upstream. We need to ensure there is enough headroom to push extra header, but we also need to check if we are allowed to change headers. skb_cow_head() is the proper helper to deal with this. Fixes: 4a476bd6d1d9 ("usbnet: New driver for QinHeng CH9200 devices") Signed-off-by: Eric Dumazet Cc: James Hughes Cc: Matthew Garrett Signed-off-by: David S. Miller Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

smsc95xx: Use skb_cow_head to deal with cloned skbs

2019-02-20T09:18:33Z

commit e9156cd26a495a18706e796f02a81fee41ec14f4 upstream. The driver was failing to check that the SKB wasn't cloned before adding checksum data. Replace existing handling to extend/copy the header buffer with skb_cow_head. Signed-off-by: James Hughes Acked-by: Eric Dumazet Acked-by: Woojung Huh Signed-off-by: David S. Miller Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman