The posix_timers.c test has a loop that tries to keep it in
kernel space, repeatedly calling brk(). However, it doesn't
check the return value, which causes warnings.
This patch adds a err value which captures the return value
and modifies the test so it will quit if a failure occurs.
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Tested-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Pull USB fixes from Greg KH:
"Here's a round of USB fixes for 4.0-rc3.
Nothing major, the usual gadget, xhci and usb-serial fixes and a few
new device ids as well.
All have been in linux-next successfully"
* tag 'usb-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (36 commits)
xhci: Workaround for PME stuck issues in Intel xhci
xhci: fix reporting of 0-sized URBs in control endpoint
usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards
USB: ch341: set tty baud speed according to tty struct
USB: serial: cp210x: Adding Seletek device id's
USB: pl2303: disable break on shutdown
USB: mxuport: fix null deref when used as a console
USB: serial: clean up bus probe error handling
USB: serial: fix port attribute-creation race
USB: serial: fix tty-device error handling at probe
USB: serial: fix potential use-after-free after failed probe
USB: console: add dummy __module_get
USB: ftdi_sio: add PIDs for Actisense USB devices
Revert "USB: serial: make bulk_out_size a lower limit"
cdc-acm: Add support for Denso cradle CU-321
usb-storage: support for more than 8 LUNs
uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS539
USB: usbfs: don't leak kernel data in siginfo
xhci: Clear the host side toggle manually when endpoint is 'soft reset'
xhci: Allocate correct amount of scratchpad buffers
...
Pull tty/serial fixes from Greg KH:
"Here are some tty and serial driver fixes for 4.0-rc3.
Along with the atime fix that you know about, here are some other
serial driver bugfixes as well. Most notable is a wait_until_sent
bugfix that was traced back to being around since before 2.6.12 that
Johan has fixed up.
All have been in linux-next successfully"
* tag 'tty-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
TTY: fix tty_wait_until_sent maximum timeout
TTY: fix tty_wait_until_sent on 64-bit machines
USB: serial: fix infinite wait_until_sent timeout
TTY: bfin_jtag_comm: remove incorrect wait_until_sent operation
net: irda: fix wait_until_sent poll timeout
serial: uapi: Declare all userspace-visible io types
serial: core: Fix iotype userspace breakage
serial: sprd: Fix missing spin_unlock in sprd_handle_irq()
console: Fix console name size mismatch
tty: fix up atime/mtime mess, take four
serial: 8250_dw: Fix get_mctrl behaviour
serial:8250:8250_pci: delete unneeded quirk entries
serial:8250:8250_pci: fix redundant entry report for WCH_CH352_2S
Change email address for 8250_pci
serial: 8250: Revert "tty: serial: 8250_core: read only RX if there is something in the FIFO"
Revert "tty/serial: of_serial: add DT alias ID handling"
Pull char/misc driver fixes from Greg KH:
"Here are two char/misc fixes for 4.0-rc3.
One is a reported binder driver fix needed due to a change in the mm
core that happened in 4.0-rc1. Another is a mei driver fix that
resolves a reported issue in that driver.
Both have been in linux-next for a while"
* tag 'char-misc-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
mei: make device disabled on stop unconditionally
android: binder: fix binder mmap failures
Pull "code of conflict" from Greg KH:
"This file tries to set the rational basis for our code reviews, gives
some advice on how to conduct them, and provides an excalation channel
for any kernel developers if they so desire it"
[ Let's see how this works ]
* tag 'cc-4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
Code of Conflict
Pull i2c fixes from Wolfram Sang:
"A set of updates and bugfixes for the new designware-baytrail driver.
And a documentation bugfix"
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: imx: add required clocks property to binding
i2c: designware-baytrail: baytrail_i2c_acquire() might sleep
i2c: designware-baytrail: cross-check lock functions
i2c: designware-baytrail: fix sparse warnings
i2c: designware-baytrail: fix typo in error path
i2c: designware-baytrail: describe magic numbers
Pull arm64 fixes from Catalin Marinas:
"arm64 and generic kernel/module.c (acked by Rusty) fixes for
CONFIG_DEBUG_SET_MODULE_RONX"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
kernel/module.c: Update debug alignment after symtable generation
arm64: Don't use is_module_addr in setting page attributes
Currently tty_wait_until_sent may take up to twice as long as the
requested timeout while waiting for driver and hardware buffers to
drain.
Fix this by taking the remaining number of jiffies after waiting for
driver buffers to drain into account so that the timeout actually
becomes a maximum timeout as it is documented to be.
Note that this specifically implies tighter timings when closing a port
as a consequence of actually honouring the port closing-wait setting
for drivers relying on tty_wait_until_sent_from_close (e.g. via
tty_port_close_start).
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix overflow bug in tty_wait_until_sent on 64-bit machines, where an
infinite timeout (0) would be passed to the underlying tty-driver's
wait_until_sent-operation as a negative timeout (-1), causing it to
return immediately.
This manifests itself for example as tcdrain() returning immediately,
drivers not honouring the drain flags when setting terminal attributes,
or even dropped data on close as a requested infinite closing-wait
timeout would be ignored.
The first symptom was reported by Asier LLANO who noted that tcdrain()
returned prematurely when using the ftdi_sio usb-serial driver.
Fix this by passing 0 rather than MAX_SCHEDULE_TIMEOUT (LONG_MAX) to the
underlying tty driver.
Note that the serial-core wait_until_sent-implementation is not affected
by this bug due to a lucky chance (comparison to an unsigned maximum
timeout), and neither is the cyclades one that had an explicit check for
negative timeouts, but all other tty drivers appear to be affected.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Cc: stable <stable@vger.kernel.org> # v2.6.12
Reported-by: ZIV-Asier Llano Palacios <asier.llano@cgglobal.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure to handle an infinite timeout (0).
Note that wait_until_sent is currently never called with a 0-timeout
argument due to a bug in tty_wait_until_sent.
Fixes: dcf0105039 ("USB: serial: add generic wait_until_sent
implementation")
Cc: stable <stable@vger.kernel.org> # v3.10
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove incorrect and redundant wait_until_sent operation, which waits
for the driver buffer rather than any hardware buffers to drain,
something which is already taken care of by the tty layer (and
chars_in_buffer).
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In case an infinite timeout (0) is requested, the irda wait_until_sent
implementation would use a zero poll timeout rather than the default
200ms.
Note that wait_until_sent is currently never called with a 0-timeout
argument due to a bug in tty_wait_until_sent.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Cc: stable <stable@vger.kernel.org> # v2.6.12
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ioctl(TIOCGSERIAL|TIOCSSERIAL) report and can change the port->iotype.
UART drivers use the UPIO_* definitions, but the uapi header defines
parallel values and userspace uses these parallel values for ioctls;
thus the userspace values are definitive.
Define UPIO_* iotypes in terms of the uapi defines, SERIAL_IO_*;
extend the uapi defines to include all values in use by the serial
core.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3ffb1a8193 ("serial: core: Add big-endian iotype")
re-numbered userspace-dependent values; ioctl(TIOCSSERIAL) can
assign the port iotype (which is expected to match the selected
i/o accessors), so iotype values must not be changed.
Cc: Kevin Cernekee <cernekee@gmail.com>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Reviewed-by: Kevin Cernekee <cernekee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6ae9200f2c ("enlarge console.name") increased the storage
for the console name to 16 bytes, but not the corresponding
struct console_cmdline::name storage. Console names longer than
8 bytes cause read beyond end-of-string and failure to match
console; I'm not sure if there are other unexpected consequences.
Cc: <stable@vger.kernel.org> # 2.6.22+
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This problem was taken care of three times already in
* b0de59b573 (TTY: do not update
atime/mtime on read/write),
* 37b7f3c765 (TTY: fix atime/mtime
regression), and
* b0b885657b (tty: fix up atime/mtime
mess, take three)
But it still misses one point. As John Paul correctly points out, we
do not care about setting date. If somebody ever changes wall
time backwards (by mistake for example), tty timestamps are never
updated until the original wall time passes.
So check the absolute difference of times and if it large than "8
seconds or so", always update the time. That means we will update
immediatelly when changing time. Ergo, CAP_SYS_TIME can foul the
check, but it was always that way.
Thanks John for serving me this so nicely debugged.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-by: John Paul Perry <john_paul.perry@alcatel-lucent.com>
Cc: <stable@vger.kernel.org> # all, as b0b885657 was backported
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
