[PATCH 4.4 19/30] usb: r8a66597-hcd: decrease timeout

[Greg Kroah-Hartman]

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Chris Brandt <chris....@renesas.com>

commit dd14a3e9b92ac6f0918054f9e3477438760a4fa6 upstream.

The timeout for BULK packets was 300ms which is a long time if other
endpoints or devices are waiting for their turn. Changing it to 50ms
greatly increased the overall performance for multi-endpoint devices.

Fixes: 5d3043586db4 ("usb: r8a66597-hcd: host controller driver for R8A6659")
Signed-off-by: Chris Brandt <chris....@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
drivers/usb/host/r8a66597-hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -1269,7 +1269,7 @@ static void set_td_timer(struct r8a66597
time = 30;
break;
default:
- time = 300;
+ time = 50;
break;
}

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 4.4.74 release.
There are 30 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Jun 21 15:20:21 UTC 2017.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.74-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <gre...@linuxfoundation.org>
Linux 4.4.74-rc1

Hugh Dickins <hu...@google.com>
mm: larger stack guard gap, between vmas

Thomas Gleixner <tg...@linutronix.de>
alarmtimer: Rate limit periodic intervals

Paul Burton <paul....@imgtec.com>
MIPS: Fix bnezc/jialc return address calculation

Shuah Khan <shu...@osg.samsung.com>
usb: dwc3: exynos fix axius clock error path to do cleanup

Thomas Gleixner <tg...@linutronix.de>
alarmtimer: Prevent overflow of relative timers

Heiner Kallweit <hkall...@gmail.com>
genirq: Release resources in __setup_irq() error path

Yu Zhao <yuz...@google.com>
swap: cond_resched in swap_cgroup_prepare()

James Morse <james...@arm.com>
mm/memory-failure.c: use compound_head() flags for huge pages

Alan Stern <st...@rowland.harvard.edu>
USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks

Corentin Labbe <clabbe....@gmail.com>
usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk

Dan Carpenter <dan.ca...@oracle.com>
drivers/misc/c2port/c2port-duramar2150.c: checking for NULL instead of IS_ERR()

Chris Brandt <chris....@renesas.com>
usb: r8a66597-hcd: decrease timeout

Chris Brandt <chris....@renesas.com>
usb: r8a66597-hcd: select a different endpoint on timeout

Johan Hovold <jo...@kernel.org>
USB: gadget: dummy_hcd: fix hub-descriptor removable fields

Arnd Bergmann <ar...@arndb.de>
pvrusb2: reduce stack usage pvr2_eeprom_analyze()

Anton Bondarenko <anton.bond...@gmail.com>
usb: core: fix potential memory leak in error path during hcd creation

Johan Hovold <jo...@kernel.org>
USB: hub: fix SS max number of ports

Matt Ranostay <matt.r...@konsulko.com>
iio: proximity: as3935: recalibrate RCO after resume

Dan Carpenter <dan.ca...@oracle.com>
staging: rtl8188eu: prevent an underflow in rtw_check_beacon_data()

Tony Lindgren <to...@atomide.com>
mfd: omap-usb-tll: Fix inverted bit use for USB TLL mode

Laura Abbott <lab...@redhat.com>
x86/mm/32: Set the '__vmalloc_start_set' flag in initmem_init()

Christophe JAILLET <christoph...@wanadoo.fr>
serial: efm32: Fix parity management in 'efm32_uart_console_get_options()'

Johannes Berg <johann...@intel.com>
mac80211: fix IBSS presp allocation size

Koen Vandeputte <koen.va...@ncentric.com>
mac80211: fix CSA in IBSS mode

Jason A. Donenfeld <Ja...@zx2c4.com>
mac80211/wpa: use constant time memory comparison for MACs

Emmanuel Grumbach <emmanuel...@intel.com>
mac80211: don't look at the PM bit of BAR frames

Christophe JAILLET <christoph...@wanadoo.fr>
vb2: Fix an off by one error in 'vb2_plane_vaddr'

Tomasz Wilczyński <twilc...@naver.com>
cpufreq: conservative: Allow down_threshold to take values from 1 to 10

Marc Kleine-Budde <m...@pengutronix.de>
can: gs_usb: fix memory leak in gs_cmd_reset()

Nicholas Bellinger <n...@linux-iscsi.org>
configfs: Fix race between create_link and configfs_rmdir


-------------

Diffstat:

Documentation/kernel-parameters.txt | 7 ++
Makefile | 4 +-
arch/arc/mm/mmap.c | 2 +-
arch/arm/mm/mmap.c | 4 +-
arch/frv/mm/elf-fdpic.c | 2 +-
arch/mips/kernel/branch.c | 4 +-
arch/mips/mm/mmap.c | 2 +-
arch/parisc/kernel/sys_parisc.c | 15 +--
arch/powerpc/mm/slice.c | 2 +-
arch/s390/mm/mmap.c | 4 +-
arch/sh/mm/mmap.c | 4 +-
arch/sparc/kernel/sys_sparc_64.c | 4 +-
arch/sparc/mm/hugetlbpage.c | 2 +-
arch/tile/mm/hugetlbpage.c | 2 +-
arch/x86/kernel/sys_x86_64.c | 4 +-
arch/x86/mm/hugetlbpage.c | 2 +-
arch/x86/mm/numa_32.c | 1 +
arch/xtensa/kernel/syscall.c | 2 +-
drivers/cpufreq/cpufreq_conservative.c | 4 +-
drivers/iio/proximity/as3935.c | 6 +-
drivers/media/usb/pvrusb2/pvrusb2-eeprom.c | 13 +--
drivers/media/v4l2-core/videobuf2-core.c | 2 +-
drivers/mfd/omap-usb-tll.c | 2 +-
drivers/misc/c2port/c2port-duramar2150.c | 4 +-
drivers/net/can/usb/gs_usb.c | 2 +
drivers/staging/rtl8188eu/core/rtw_ap.c | 2 +-
drivers/tty/serial/efm32-uart.c | 11 ++-
drivers/usb/core/hcd.c | 1 +
drivers/usb/core/hub.c | 8 +-
drivers/usb/dwc3/dwc3-exynos.c | 4 +-
drivers/usb/gadget/legacy/inode.c | 5 +-
drivers/usb/gadget/udc/dummy_hcd.c | 19 ++--
drivers/usb/gadget/udc/net2280.c | 9 +-
drivers/usb/host/r8a66597-hcd.c | 6 +-
drivers/usb/host/xhci-pci.c | 3 +
fs/configfs/symlink.c | 3 +-
fs/hugetlbfs/inode.c | 2 +-
fs/proc/task_mmu.c | 4 -
include/linux/mm.h | 55 +++++------
include/uapi/linux/usb/ch11.h | 3 +
kernel/irq/manage.c | 4 +-
kernel/time/alarmtimer.c | 14 ++-
mm/gup.c | 5 -
mm/memory-failure.c | 5 +-
mm/memory.c | 38 --------
mm/mmap.c | 147 +++++++++++++++++------------
mm/swap_cgroup.c | 3 +
net/mac80211/ibss.c | 6 +-
net/mac80211/rx.c | 6 +-
net/mac80211/wpa.c | 9 +-
50 files changed, 245 insertions(+), 227 deletions(-)

[Greg Kroah-Hartman]

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: James Morse <james...@arm.com>

commit 7258ae5c5a2ce2f5969e8b18b881be40ab55433d upstream.

memory_failure() chooses a recovery action function based on the page
flags. For huge pages it uses the tail page flags which don't have
anything interesting set, resulting in:

> Memory failure: 0x9be3b4: Unknown page state
> Memory failure: 0x9be3b4: recovery action for unknown page: Failed

Instead, save a copy of the head page's flags if this is a huge page,
this means if there are no relevant flags for this tail page, we use the
head pages flags instead. This results in the me_huge_page() recovery
action being called:

> Memory failure: 0x9b7969: recovery action for huge page: Delayed

For hugepages that have not yet been allocated, this allows the hugepage
to be dequeued.

Fixes: 524fca1e7356 ("HWPOISON: fix misjudgement of page_action() for errors on mlocked pages")
Link: http://lkml.kernel.org/r/20170524130204.21...@arm.com
Signed-off-by: James Morse <james...@arm.com>
Tested-by: Punit Agrawal <punit....@arm.com>
Acked-by: Punit Agrawal <punit....@arm.com>
Acked-by: Naoya Horiguchi <n-hor...@ah.jp.nec.com>
Signed-off-by: Andrew Morton <ak...@linux-foundation.org>
Signed-off-by: Linus Torvalds <torv...@linux-foundation.org>

Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---

mm/memory-failure.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1208,7 +1208,10 @@ int memory_failure(unsigned long pfn, in
* page_remove_rmap() in try_to_unmap_one(). So to determine page status
* correctly, we save a copy of the page flags at this time.
*/
- page_flags = p->flags;
+ if (PageHuge(p))
+ page_flags = hpage->flags;
+ else
+ page_flags = p->flags;

/*
* unpoison always clear PG_hwpoison inside page lock

[Greg Kroah-Hartman]

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Arnd Bergmann <ar...@arndb.de>

commit 6830733d53a4517588e56227b9c8538633f0c496 upstream.

The driver uses a relatively large data structure on the stack, which
showed up on my radar as we get a warning with the "latent entropy"
GCC plugin:

drivers/media/usb/pvrusb2/pvrusb2-eeprom.c:153:1: error: the frame size of 1376 bytes is larger than 1152 bytes [-Werror=frame-larger-than=]

The warning is usually hidden as we raise the warning limit to 2048
when the plugin is enabled, but I'd like to lower that again in the
future, and making this function smaller helps to do that without
build regressions.

Further analysis shows that putting an 'i2c_client' structure on
the stack is not really supported, as the embedded 'struct device'
is not initialized here, and we are only saved by the fact that
the function that is called here does not use the pointer at all.

Fixes: d855497edbfb ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18")

Signed-off-by: Arnd Bergmann <ar...@arndb.de>
Signed-off-by: Hans Verkuil <hans.v...@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mch...@s-opensource.com>

Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---

drivers/media/usb/pvrusb2/pvrusb2-eeprom.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)

--- a/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
@@ -123,15 +123,10 @@ int pvr2_eeprom_analyze(struct pvr2_hdw
memset(&tvdata,0,sizeof(tvdata));

eeprom = pvr2_eeprom_fetch(hdw);
- if (!eeprom) return -EINVAL;
+ if (!eeprom)
+ return -EINVAL;

- {
- struct i2c_client fake_client;
- /* Newer version expects a useless client interface */
- fake_client.addr = hdw->eeprom_addr;
- fake_client.adapter = &hdw->i2c_adap;
- tveeprom_hauppauge_analog(&fake_client,&tvdata,eeprom);
- }
+ tveeprom_hauppauge_analog(NULL, &tvdata, eeprom);

trace_eeprom("eeprom assumed v4l tveeprom module");
trace_eeprom("eeprom direct call results:");

[Guenter Roeck]

On 06/19/2017 08:20 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.74 release.
> There are 30 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jun 21 15:20:21 UTC 2017.
> Anything received after that time might be too late.
>

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 115 pass: 115 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

[Ben Hutchings]

On Mon, 2017-06-19 at 23:20 +0800, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Arnd Bergmann <ar...@arndb.de>
>
> commit 6830733d53a4517588e56227b9c8538633f0c496 upstream.
>
> The driver uses a relatively large data structure on the stack, which
> showed up on my radar as we get a warning with the "latent entropy"
> GCC plugin:
>
> drivers/media/usb/pvrusb2/pvrusb2-eeprom.c:153:1: error: the frame size of 1376 bytes is larger than 1152 bytes [-Werror=frame-larger-than=]
>
> The warning is usually hidden as we raise the warning limit to 2048
> when the plugin is enabled, but I'd like to lower that again in the
> future, and making this function smaller helps to do that without
> build regressions.
>
> Further analysis shows that putting an 'i2c_client' structure on
> the stack is not really supported, as the embedded 'struct device'
> is not initialized here, and we are only saved by the fact that
> the function that is called here does not use the pointer at all.

[...]

That is not true in 4.4-stable. This commit depends on:

commit 6037b3ca28f4258d913dbe77248fd77827702ae3
Author: Mauro Carvalho Chehab <mch...@s-opensource.com>
Date: Wed Nov 16 14:21:48 2016 -0200

[media] tveeprom: print log messages using pr_foo()

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.

[Greg Kroah-Hartman]

It does? I don't understand how the two are connected. Removing
i2c_client off of the stack is a good thing. Ah, I see how the pointer
is used in tveeprom_hauppauge_analog(), but this shouldn't matter here,
right?

thanks,

greg k-h

[Arnd Bergmann]

On Mon, Jul 3, 2017 at 9:31 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Thu, Jun 29, 2017 at 05:15:17PM +0100, Ben Hutchings wrote:
>> On Mon, 2017-06-19 at 23:20 +0800, Greg Kroah-Hartman wrote:
>> > 4.4-stable review patch. If anyone has any objections, please let me know.
>> >

>> > From: Arnd Bergmann <ar...@arndb.de>
>> >
>> > commit 6830733d53a4517588e56227b9c8538633f0c496 upstream.
>> >
>> > The driver uses a relatively large data structure on the stack, which
>> > showed up on my radar as we get a warning with the "latent entropy"
>> > GCC plugin:
>> >
>> > drivers/media/usb/pvrusb2/pvrusb2-eeprom.c:153:1: error: the frame size of 1376 bytes is larger than 1152 bytes [-Werror=frame-larger-than=]
>> >
>> > The warning is usually hidden as we raise the warning limit to 2048
>> > when the plugin is enabled, but I'd like to lower that again in the
>> > future, and making this function smaller helps to do that without
>> > build regressions.
>> >
>> > Further analysis shows that putting an 'i2c_client' structure on
>> > the stack is not really supported, as the embedded 'struct device'
>> > is not initialized here, and we are only saved by the fact that
>> > the function that is called here does not use the pointer at all.
>> [...]
>>
>> That is not true in 4.4-stable. This commit depends on:
>>
>> commit 6037b3ca28f4258d913dbe77248fd77827702ae3
>> Author: Mauro Carvalho Chehab <mch...@s-opensource.com>
>> Date: Wed Nov 16 14:21:48 2016 -0200
>>
>> [media] tveeprom: print log messages using pr_foo()
>
> It does? I don't understand how the two are connected. Removing
> i2c_client off of the stack is a good thing. Ah, I see how the pointer
> is used in tveeprom_hauppauge_analog(), but this shouldn't matter here,
> right?

My reading of the two patches is that we actually need at least one
of them to avoid interpreting uninitialized dev->class/bus: With just my
6830733d53a patch, we replace the uninitialized data with a NULL
pointer, which is handled gracefully in __dev_printk(), while the
6037b3ca28 patch by itself will avoid using the 'dev' pointer completely,
and give a saner output (no "(NULL device)" string or worse).

I think we probably want both of them backported to 4.4, but I don't see a
dependency between them.

Arnd

[Arnd Bergmann]

On Mon, Jul 3, 2017 at 3:37 PM, Ben Hutchings
<ben.hu...@codethink.co.uk> wrote:

> On Mon, 2017-07-03 at 09:47 +0200, Arnd Bergmann wrote:
>> On Mon, Jul 3, 2017 at 9:31 AM, Greg Kroah-Hartman
>>

>> I think we probably want both of them backported to 4.4, but I don't see a
>> dependency between them.
>

> Sorry, I mixed up two commits. The one actually needed to avoid a null
> dereference is:
>
> commit 7cda4c5bae46ffca3abeadc4c1882d9325ee3102

> Author: Mauro Carvalho Chehab <mch...@s-opensource.com>

> Date: Thu Oct 13 10:51:20 2016 -0300
>
> [media] tveeprom: use dev_foo() for printk messages
>
> Then "[media] tveeprom: print log messages using pr_foo()" is cleanup on
> top of that.

Ah, I see now. We do indeed need both of Mauro's patches before we
can apply mine then.

Arnd

[Ben Hutchings]

On Mon, 2017-07-03 at 09:47 +0200, Arnd Bergmann wrote:

> On Mon, Jul 3, 2017 at 9:31 AM, Greg Kroah-Hartman
> <gre...@linuxfoundation.org> wrote:
> > On Thu, Jun 29, 2017 at 05:15:17PM +0100, Ben Hutchings wrote:
> >> On Mon, 2017-06-19 at 23:20 +0800, Greg Kroah-Hartman wrote:
> >> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >> >
> >> > From: Arnd Bergmann <ar...@arndb.de>
> >> >
> >> > commit 6830733d53a4517588e56227b9c8538633f0c496 upstream.

[...]

> >> > Further analysis shows that putting an 'i2c_client' structure on
> >> > the stack is not really supported, as the embedded 'struct device'
> >> > is not initialized here, and we are only saved by the fact that
> >> > the function that is called here does not use the pointer at all.
> >> [...]
> >>
> >> That is not true in 4.4-stable. This commit depends on:
> >>
> >> commit 6037b3ca28f4258d913dbe77248fd77827702ae3
> >> Author: Mauro Carvalho Chehab <mch...@s-opensource.com>
> >> Date: Wed Nov 16 14:21:48 2016 -0200
> >>
> >> [media] tveeprom: print log messages using pr_foo()
> >
> > It does? I don't understand how the two are connected. Removing
> > i2c_client off of the stack is a good thing. Ah, I see how the pointer
> > is used in tveeprom_hauppauge_analog(), but this shouldn't matter here,
> > right?
>
> My reading of the two patches is that we actually need at least one
> of them to avoid interpreting uninitialized dev->class/bus: With just my
> 6830733d53a patch, we replace the uninitialized data with a NULL
> pointer, which is handled gracefully in __dev_printk(), while the
> 6037b3ca28 patch by itself will avoid using the 'dev' pointer completely,
> and give a saner output (no "(NULL device)" string or worse).
>
> I think we probably want both of them backported to 4.4, but I don't see a
> dependency between them.

Sorry, I mixed up two commits. The one actually needed to avoid a null
dereference is:

commit 7cda4c5bae46ffca3abeadc4c1882d9325ee3102

Author: Mauro Carvalho Chehab <mch...@s-opensource.com>

Date: Thu Oct 13 10:51:20 2016 -0300

[media] tveeprom: use dev_foo() for printk messages

Then "[media] tveeprom: print log messages using pr_foo()" is cleanup on
top of that.