Brian Foster [Wed, 16 Apr 2014 22:15:30 +0000 (08:15 +1000)]
xfs: fix tmpfile/selinux deadlock and initialize security
xfstests generic/004 reproduces an ilock deadlock using the tmpfile
interface when selinux is enabled. This occurs because
xfs_create_tmpfile() takes the ilock and then calls d_tmpfile(). The
latter eventually calls into xfs_xattr_get() which attempts to get the
lock again. E.g.:
xfs_vn_tmpfile() also fails to initialize security on the newly created
inode.
Pull the d_tmpfile() call up into xfs_vn_tmpfile() after the transaction
has been committed and the inode unlocked. Also, initialize security on
the inode based on the parent directory provided via the tmpfile call.
Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com>
At issue is the fact that if IO fails in xfs_buf_iorequest,
we'll queue completion unconditionally, and then call
xfs_buf_rele; but if IO failed, there are no IOs remaining,
and xfs_buf_rele will free the bp while work is still queued.
Fix this by not scheduling completion if the buffer has
an error on it; run it immediately. The rest is only comment
changes.
Thanks to dchinner for spotting the root cause.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
Dave Chinner [Wed, 16 Apr 2014 22:15:27 +0000 (08:15 +1000)]
xfs: wrong error sign conversion during failed DIO writes
We negate the error value being returned from a generic function
incorrectly. The code path that it is running in returned negative
errors, so there is no need to negate it to get the correct error
signs here.
This was uncovered by generic/019.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com>
Dave Chinner [Wed, 16 Apr 2014 22:15:26 +0000 (08:15 +1000)]
xfs: unmount does not wait for shutdown during unmount
And interesting situation can occur if a log IO error occurs during
the unmount of a filesystem. The cases reported have the same
signature - the update of the superblock counters fails due to a log
write IO error:
XFS (dm-16): xfs_do_force_shutdown(0x2) called from line 1170 of file fs/xfs/xfs_log.c. Return address = 0xffffffffa08a44a1
XFS (dm-16): Log I/O Error Detected. Shutting down filesystem
XFS (dm-16): Unable to update superblock counters. Freespace may not be correct on next mount.
XFS (dm-16): xfs_log_force: error 5 returned.
XFS (¿-¿¿¿): Please umount the filesystem and rectify the problem(s)
It can be seen that the last line of output contains a corrupt
device name - this is because the log and xfs_mount structures have
already been freed by the time this message is printed. A kernel
oops closely follows.
The issue is that the shutdown is occurring in a separate IO
completion thread to the unmount. Once the shutdown processing has
started and all the iclogs are marked with XLOG_STATE_IOERROR, the
log shutdown code wakes anyone waiting on a log force so they can
process the shutdown error. This wakes up the unmount code that
is doing a synchronous transaction to update the superblock
counters.
The unmount path now sees all the iclogs are marked with
XLOG_STATE_IOERROR and so never waits on them again, knowing that if
it does, there will not be a wakeup trigger for it and we will hang
the unmount if we do. Hence the unmount runs through all the
remaining code and frees all the filesystem structures while the
xlog_iodone() is still processing the shutdown. When the log
shutdown processing completes, xfs_do_force_shutdown() emits the
"Please umount the filesystem and rectify the problem(s)" message,
and xlog_iodone() then aborts all the objects attached to the iclog.
An iclog that has already been freed....
The real issue here is that there is no serialisation point between
the log IO and the unmount. We have serialisations points for log
writes, log forces, reservations, etc, but we don't actually have
any code that wakes for log IO to fully complete. We do that for all
other types of object, so why not iclogbufs?
Well, it turns out that we can easily do this. We've got xfs_buf
handles, and that's what everyone else uses for IO serialisation.
i.e. bp->b_sema. So, lets hold iclogbufs locked over IO, and only
release the lock in xlog_iodone() when we are finished with the
buffer. That way before we tear down the iclog, we can lock and
unlock the buffer to ensure IO completion has finished completely
before we tear it down.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Tested-by: Mike Snitzer <snitzer@redhat.com> Tested-by: Bob Mastors <bob.mastors@solidfire.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
Dave Chinner [Wed, 16 Apr 2014 22:15:25 +0000 (08:15 +1000)]
xfs: collapse range is delalloc challenged
FSX has been detecting data corruption after to collapse range
calls. The key observation is that the offset of the last extent in
the file was not being shifted, and hence when the file size was
adjusted it was truncating away data because the extents handled
been correctly shifted.
Tracing indicated that before the collapse, the extent list looked
like:
....
ino 0x5788 state idx 6 offset 26 block 195904 count 10 flag 0
ino 0x5788 state idx 7 offset 39 block 195917 count 35 flag 0
ino 0x5788 state idx 8 offset 86 block 195964 count 32 flag 0
and after the shift of 2 blocks:
ino 0x5788 state idx 6 offset 24 block 195904 count 10 flag 0
ino 0x5788 state idx 7 offset 37 block 195917 count 35 flag 0
ino 0x5788 state idx 8 offset 86 block 195964 count 32 flag 0
Note that the last extent did not change offset. After the changing
of the file size:
ino 0x5788 state idx 6 offset 24 block 195904 count 10 flag 0
ino 0x5788 state idx 7 offset 37 block 195917 count 35 flag 0
ino 0x5788 state idx 8 offset 86 block 195964 count 30 flag 0
You can see that the last extent had it's length truncated,
indicating that we've lost data.
The reason for this is that the xfs_bmap_shift_extents() loop uses
XFS_IFORK_NEXTENTS() to determine how many extents are in the inode.
This, unfortunately, doesn't take into account delayed allocation
extents - it's a count of physically allocated extents - and hence
when the file being collapsed has a delalloc extent like this one
does prior to the range being collapsed:
....
ino 0x5788 state idx 4 offset 11 block 4503599627239429 count 1 flag 0
....
it gets the count wrong and terminates the shift loop early.
Fix it by using the in-memory extent array size that includes
delayed allocation extents to determine the number of extents on the
inode.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Tested-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com>
Dave Chinner [Wed, 16 Apr 2014 22:15:19 +0000 (08:15 +1000)]
xfs: don't map ranges that span EOF for direct IO
Al Viro tracked down the problem that has caused generic/263 to fail
on XFS since the test was introduced. If is caused by
xfs_get_blocks() mapping a single extent that spans EOF without
marking it as buffer-new() so that the direct IO code does not zero
the tail of the block at the new EOF. This is a long standing bug
that has been around for many, many years.
Because xfs_get_blocks() starts the map before EOF, it can't set
buffer_new(), because that causes he direct IO code to also zero
unaligned sectors at the head of the IO. This would overwrite valid
data with zeros, and hence we cannot validly return a single extent
that spans EOF to direct IO.
Fix this by detecting a mapping that spans EOF and truncate it down
to EOF. This results in the the direct IO code doing the right thing
for unaligned data blocks before EOF, and then returning to get
another mapping for the region beyond EOF which XFS treats correctly
by setting buffer_new() on it. This makes direct Io behave correctly
w.r.t. tail block zeroing beyond EOF, and fsx is happy about that.
Again, thanks to Al Viro for finding what I couldn't.
[ dchinner: Fix for __divdi3 build error:
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com> Tested-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Mark Tinguely <tinguely@sgi.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com>
]
Signed-off-by: Dave Chinner <dchinner@redhat.com> Tested-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com>
serial: amba-pl011: fix regression, causing an Oops on rmmod
A recent commit ef2889f7ffee67f0aed49e854c72be63f1466759 "serial: pl011:
Move uart_register_driver call to device probe" introduced a regression,
causing the pl011 driver to Oops if more than 1 port have been probed. Fix
the Oops by only calling uart_unregister_driver() once after the last port
has been removed.
the leak is due to unreleased pid->count, which execute in function:
get_pid()(pid->count++) and put_pid()(pid->count--).
The race condition as following:
task[dumpsys] task[adbd]
in disassociate_ctty() in tty_signal_session_leader()
----------------------- -------------------------
tty = get_current_tty();
// tty is not NULL
...
spin_lock_irq(¤t->sighand->siglock);
put_pid(current->signal->tty_old_pgrp);
current->signal->tty_old_pgrp = NULL;
spin_unlock_irq(¤t->sighand->siglock);
in task[dumpsys], in disassociate_ctty(), tty is set NULL by task[adbd],
tty_signal_session_leader(), then it goto else branch and lack of
put_pid(), cause memleak.
move spin_unlock(sighand->siglock) after get_current_tty() can avoid
the race and fix the memleak.
ttyprintk: Fix wrong tty_unregister_driver() call in the error path
ttyprintk driver calls tty_unregister_driver() wrongly in the error
path of tty_register_driver(). Also, setting ttyprintk_driver to NULL
is utterly superfluous, so let's get rid of it, too.
Reported-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The 8250 driver now reports many of these:
serial8250: too much work for irq4
These messages turned out to be common these days with a use of
virtualization. I tried to increase the limit of processed characters
in commit e7328ae1848966181a7ac47e8ae6cddbd2cf55f3 (serial: 8250,
increase PASS_LIMIT) in 2011. It was raised from 256 to 512, but it is
still not enough, apparently.
So disable the warning unless somebody turns on DEBUG (or
DYNAMIC_DEBUG _and_ the message).
Tony Lindgren [Tue, 25 Mar 2014 18:48:47 +0000 (11:48 -0700)]
serial: omap: Fix missing pm_runtime_resume handling by simplifying code
The lack of pm_runtime_resume handling for the device state leads into
device wake-up interrupts not working after a while for runtime PM.
Also, serial-omap is confused about the use of device_may_wakeup.
The checks for device_may_wakeup should only be done for suspend and
resume, not for pm_runtime_suspend and pm_runtime_resume. The wake-up
events for PM runtime should always be enabled.
The lack of pm_runtime_resume handling leads into device wake-up
interrupts not working after a while for runtime PM.
Rather than try to patch over the issue of adding complex tests to
the pm_runtime_resume, let's fix the issues properly:
1. Make serial_omap_enable_wakeup deal with all internal PM state
handling so we don't need to test for up->wakeups_enabled elsewhere.
Later on once omap3 boots in device tree only mode we can also
remove the up->wakeups_enabled flag and rely on the wake-up
interrupt enable/disable state alone.
2. Do the device_may_wakeup checks in suspend and resume only,
for runtime PM the wake-up events need to be always enabled.
3. Finally just call serial_omap_enable_wakeup and make sure we
call it also in pm_runtime_resume.
4. Note that we also have to use disable_irq_nosync as serial_omap_irq
calls pm_runtime_get_sync.
Fixes: 2a0b965cfb6e (serial: omap: Add support for optional wake-up) Cc: stable@vger.kernel.org # v3.13+ Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a serial port is closed, uart_close() takes care of shutting down the
hardware, and powering it down.
When a serial port is unbound while in use, uart_close() bypasses all of
this, as this is supposed to be done through uart_hangup() (invoked via
tty_vhangup() in uart_remove_one_port()).
However, uart_hangup() does not set the hardware's power state, leaving it
powered up. This may also lead to unbounded nesting counts in clock and
power management, depending on their internal implementation.
Make sure to power down the port in uart_hangup(), except when the port is
used as a serial console.
For serial consoles, this operation must be postponed until after the port
becomes completely unused. This case is not fixed yet, as it depends on a
(future) fix for the tty->count vs. port->count imbalance on failed
uart_open().
After this, the module clock used by the sh-sci driver is disabled on
unbind while the serial port is in use.
serial: pl011: change Rx burst size to half of trigger level
The amba-pl011.c driver sets DMA burst size equal to FIFO trigger level.
If now exactly DMA burst size bytes are received, the DMAC will retrieve
them all and no Rx timeout interrupt will be generated. To fix that set
the burst size to half the FIFO trigger level.
Jean Delvare [Thu, 3 Apr 2014 09:36:22 +0000 (11:36 +0200)]
serial: timberdale: Depend on X86_32
As far as I know the Timberdale chip was only used as a companion for
Intel Atom E600 series processors. As such, its drivers are only
useful on X86_32.
Daniel Thompson [Fri, 28 Mar 2014 10:53:10 +0000 (10:53 +0000)]
serial: st-asc: Fix SysRq char handling
This driver, like several others, uses the upper bits of the character
to track both real and dummy state. Unfortunately it neglects to mask
these bits properly when passing the character data around. This means
neither break detection nor sysrq character handling work correctly.
This patch adds the requires masking and has been tested to confirm
that it correctly handles magic sysrq sequences on ST's B2020 board.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Seth Bollinger [Tue, 25 Mar 2014 17:55:37 +0000 (12:55 -0500)]
serial_core: Fix conditional start_tx on ring buffer not empty
If the serial_core ring buffer empties just as the tty layer receives
an XOFF, then start_tx will never be called when the tty layer
receives an XON as the serial_core ring buffer is empty. This will
possibly leave a few bytes trapped in the fifo for drivers that
disable the transmitter when flow controlled.
Uwe Kleine-König [Tue, 25 Mar 2014 14:53:12 +0000 (15:53 +0100)]
serial: efm32: use $vendor,$device scheme for compatible string
Wolfram Sang pointed out that "efm32,$device" is non-standard. So use the
common scheme and prefix device with "efm32-". The old compatible string
is left in place until arch/arm/boot/dts/efm32* is fixed.
Reported-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drivers: hv: vmbus: Negotiate version 3.0 when running on ws2012r2 hosts
Only ws2012r2 hosts support the ability to reconnect to the host on VMBUS. This functionality
is needed by kexec in Linux. To use this functionality we need to negotiate version 3.0 of the
VMBUS protocol.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Cc: <stable@vger.kernel.org> [3.9+] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joe Schultz [Thu, 3 Apr 2014 19:48:16 +0000 (14:48 -0500)]
vme_tsi148: Fix PCI address mapping assumption
Previously, tsi148_master_set() assumed the address contained in its
PCI bus resource represented the actual PCI bus address. This is a fine
assumption on some platforms. However, on platforms that don't use a
1:1 (CPU:PCI) mapping this results in the tsi148 driver configuring an
invalid master window translation.
This patch updates the vme_tsi148 driver to first convert the address
contained in the PCI bus resource into a PCI bus address before using
it.
[asierra: account for pcibios_resource_to_bus() prototype change] Signed-off-by: Joe Schultz <jschultz@xes-inc.com> Signed-off-by: Aaron Sierra <asierra@xes-inc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joe Schultz [Thu, 3 Apr 2014 19:47:55 +0000 (14:47 -0500)]
vme_tsi148: Fix typo in tsi148_slave_get()
This patch corrects a typo where "vme_base" was used instead of
"*vme_base". The typo resulted in an incorrect value being returned
to userspace (via vme_user).
It also removes the following compile warning on some platforms:
warning: cast from pointer to integer of different size
[asierra: commit title/log rewording] Signed-off-by: Joe Schultz <jschultz@xes-inc.com> Signed-off-by: Aaron Sierra <asierra@xes-inc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Fries [Wed, 16 Apr 2014 06:21:21 +0000 (01:21 -0500)]
w1: avoid recursive device_add
__w1_attach_slave_device calls device_add which calls w1_bus_notify
which calls the w1_bq27000 slave driver, which calls
platform_device_add and device_add and deadlocks on getting
&(&priv->bus_notifier)->rwsem as it is still held in the previous
device_add. This avoids the problem by processing the family
add/remove outside of the slave device_add call.
Commit 47eba33a0997fc7362a introduced this deadlock and added
a KOBJ_ADD, as the add was already reported in device_register two add
events were being sent. This change suppresses the device_register
add so that any slave device sysfs entries are setup before the add
goes out.
Belisko Marek reported this change fixed the deadlock he was seeing on
ARM device tree, while testing on my x86-64 system never saw the
deadlock.
Reported-by: Belisko Marek <marek.belisko@gmail.com> Signed-off-by: David Fries <David@Fries.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Fries [Wed, 9 Apr 2014 03:37:07 +0000 (22:37 -0500)]
w1: fix netlink refcnt leak on error path
If the message type is W1_MASTER_CMD or W1_SLAVE_CMD, then a reference
is taken when searching for the slave or master device. If there
isn't any following data m->len (mlen is a copy) is 0 and packing up
the message for later execution is skipped leaving nothing to
decrement the reference counts.
Way back when, m->len was checked before the search that increments the
reference count, but W1_LIST_MASTERS has no additional data, the check
was moved in 9be62e0b2fadaf5ff causing this bug.
This change reorders to put the check before the reference count is
incremented avoiding the problem.
Oliver Neukum [Fri, 28 Mar 2014 10:25:50 +0000 (11:25 +0100)]
uas: fix deadlocky memory allocations
There are also two allocations with GFP_KERNEL in the pre-/post_reset
code paths. That is no good because that is a part of the SCSI error handler.
Signed-off-by: Oliver Neukum <oliver@neukum.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oliver Neukum [Fri, 28 Mar 2014 10:29:25 +0000 (11:29 +0100)]
uas: fix error handling during scsi_scan()
intfdata is set only after scsi_scan(). uas_pre_reset() however
needs intfdata to be valid and will follow the NULL pointer
killing khubd. intfdata must be preemptively set before the
host is registered and undone in the error case.
Signed-off-by: Oliver Neukum <oliver@neukum.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Oliver Neukum <oliver@neukum.org> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ulbricht [Tue, 25 Mar 2014 09:34:18 +0000 (10:34 +0100)]
USB: cdc-acm: Remove Motorola/Telit H24 serial interfaces from ACM driver
By specifying NO_UNION_NORMAL the ACM driver does only use the first two
USB interfaces (modem data & control). The AT Port, Diagnostic and NMEA
interfaces are left to the USB serial driver.
Signed-off-by: Michael Ulbricht <michael.ulbricht@systec-electronic.com> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Oliver Neukum <oliver@neukum.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: ohci-jz4740: FEAT_POWER is a port feature, not a hub feature
Power control of hub ports target the CLEAR_FEATURE and SET_FEATURE
requests to ports, not to the hub. Fix the hub control function to
detect the request correctly.
Stephen Warren [Mon, 14 Apr 2014 21:21:23 +0000 (15:21 -0600)]
USB: EHCI: tegra: set txfill_tuning
To avoid memory fetch underflows with larger USB transfers, Tegra SoCs
need txfill_tuning's txfifothresh register field set to a non-default
value. Add a custom reset override in order to set this up.
These values are recommended practice for all Tegra chips. However,
I've only noticed practical problems when not setting them this way on
systems using Tegra124. Hence, CC: stable only for recent kernels which
actually support Tegra124.
Cc: <stable@vger.kernel.org> # 3.14+ Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: ehci-platform: Return immediately from suspend if ehci_suspend fails
Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race'
adds a check for possible race between suspend and wakeup interrupt,
and thereby it returns -EBUSY as error code if there's a wakeup
interrupt.
So the platform host controller should not proceed further with
its suspend callback, rather should return immediately to avoid
powering down the essential things, like phy.
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: ehci-exynos: Return immediately from suspend if ehci_suspend fails
Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race'
adds a check for possible race between suspend and wakeup interrupt,
and thereby it returns -EBUSY as error code if there's a wakeup
interrupt.
So the platform host controller should not proceed further with
its suspend callback, rather should return immediately to avoid
powering down the essential things, like phy.
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Mon, 14 Apr 2014 17:48:47 +0000 (13:48 -0400)]
USB: fix crash during hotplug of PCI USB controller card
The code in hcd-pci.c that matches up EHCI controllers with their
companion UHCI or OHCI controllers assumes that the private drvdata
fields don't get set too early. However, it turns out that this field
gets set by usb_create_hcd(), before hcd-pci expects it, and this can
result in a crash when two controllers are probed in parallel (as can
happen when a new controller card is hotplugged).
The companions_rwsem lock was supposed to prevent this sort of thing,
but usb_create_hcd() is called outside the scope of the rwsem.
A simple solution is to check that the root-hub pointer has been
initialized as well as the drvdata field. This doesn't happen until
usb_add_hcd() is called; that call and the check are both protected by
the rwsem.
This patch should be applied to stable kernels from 3.10 onward.
USB: cdc-acm: fix double usb_autopm_put_interface() in acm_port_activate()
If acm_submit_read_urbs() fails in acm_port_activate(), error handling
code calls usb_autopm_put_interface() while it is already called
before acm_submit_read_urbs(). The patch reorganizes error handling code
to avoid double decrement of USB interface's PM-usage counter.
Found by Linux Driver Verification project (linuxtesting.org).
Johan Hovold [Thu, 3 Apr 2014 11:06:46 +0000 (13:06 +0200)]
USB: usb_wwan: fix handling of missing bulk endpoints
Fix regression introduced by commit 8e493ca1767d ("USB: usb_wwan: fix
bulk-urb allocation") by making sure to require both bulk-in and out
endpoints during port probe.
The original option driver (which usb_wwan is based on) was written
under the assumption that either endpoint could be missing, but
evidently this cannot have been tested properly. Specifically, it would
handle opening a device without bulk-in (but would blow up during resume
which was implemented later), but not a missing bulk-out in write()
(although it is handled in some places such as write_room()).
Fortunately (?), the driver also got the test for missing endpoints
wrong so the urbs were in fact always allocated, although they would be
initialised using the wrong endpoint address (0) and any submission of
such an urb would fail.
The commit mentioned above fixed the test for missing endpoints but
thereby exposed the other bugs which would now generate null-pointer
exceptions rather than failed urb submissions.
The regression was introduced in v3.7, but the offending commit was also
marked for stable.
Larry Finger [Wed, 16 Apr 2014 19:49:34 +0000 (14:49 -0500)]
staging: r8188eu: Fix case where ethtype was never obtained and always be checked against 0
Zero-initializing ether_type masked that the ether type would never be
obtained for 8021x packets and the comparison against eapol_type
would always fail.
Larry Finger [Wed, 16 Apr 2014 19:49:33 +0000 (14:49 -0500)]
staging: r8712u: Fix case where ethtype was never obtained and always be checked against 0
Zero-initializing ether_type masked that the ether type would never be
obtained for 8021x packets and the comparison against eapol_type
would always fail.
mei: ignore client writing state during cb completion
Ignore client writing state during cb completion to fix a memory
leak.
When moving cbs to the completion list we should not look at
writing_state as this state can be already overwritten by next
write, the fact that a cb is on the write waiting list means
that it was already written to the HW and we can safely complete it.
Same pays for wait in poll handler, we do not have to check the state
wake is done after completion list processing.
Cc: stable@vger.kernel.org Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomas Winkler [Tue, 25 Mar 2014 19:25:18 +0000 (21:25 +0200)]
mei: me: do not load the driver if the FW doesn't support MEI interface
NM and SPS FW types that may run on ME device on server platforms
do not have valid MEI/HECI interface and driver should not
be bound to it as this might lead to system hung.
In practice not all BIOSes effectively hide such devices from the
OS and in some cases it is not possible.
We determine FW type by examining Host FW status registers in order to
unbind the driver.
In this patch we are adding check for ME on Cougar Point, Lynx Point
Devices
Cc: stable <stable@vger.kernel.org> # 3.10+ Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Tested-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Wed, 16 Apr 2014 11:25:16 +0000 (14:25 +0300)]
isdn: icn: buffer overflow in icn_command()
This buffer over was detected using static analysis:
drivers/isdn/icn/icn.c:1325 icn_command()
error: format string overflow. buf_size: 60 length: 98
The calculation for the length of the string is off because it assumes
that the dial[] buffer holds a 50 character string, but actually it is
at most 31 characters and NUL. I have removed the dial[] buffer because
it isn't needed.
The maximum length of the string is actually 79 characters and a NUL. I
have made the cbuf[] array large enough to hold it and changed the
sprintf() to an snprintf() as a further safety enhancement.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jan Glauber [Wed, 16 Apr 2014 07:32:48 +0000 (09:32 +0200)]
net: use SYSCALL_DEFINEx for sys_recv
Make sys_recv a first class citizen by using the SYSCALL_DEFINEx
macro. Besides being cleaner this will also generate meta data
for the system call so tracing tools like ftrace or LTTng can
resolve this system call.
Signed-off-by: Jan Glauber <jan.glauber@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Frank Haverkamp [Thu, 20 Mar 2014 14:11:05 +0000 (15:11 +0100)]
GenWQE: Fix multithreading problems
When being used in a multithreaded application there were problems
with memory pages/cachelines accessed by multiple threads/cpus at the
same time, while doing DMA transfers to/from those. To avoid such
situations this fix is creating a copy of the first and the last page
if it is not fully used. The data is copied from user-space into those
pages and results are copied back when the DDCB-request is
successfully finished.
Signed-off-by: Frank Haverkamp <haver@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Thu, 20 Mar 2014 14:11:04 +0000 (15:11 +0100)]
GenWQE: Ensure rc is not returning an uninitialized value
rc is not initialized, so genwqe_finish_queue() either returns -EIO or
garbage. Fortunately the return is not being checked by any callers,
so this has not yet caused any problems. Even so, it makes sense to
fix this small bug in case is is checked in future.
Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Frank Haverkamp <haver@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Wed, 16 Apr 2014 19:10:00 +0000 (15:10 -0400)]
Merge branch 'mdio-gpio'
Guenter Roeck says:
====================
net: mdio-gpio enhancements
The following series of patches adds support for active-low gpio pins
as well as for systems with separate MDI and MDO pins to the mdio-gpio
driver.
A board using those features is based on a COM Express CPU board.
The COM Express standard supports GPIO pins on its connector,
with one caveat: The pins on the connector have fixed direction
and are hard configured either as input or output pins.
The COM Express Design Guide [1] provides additional details.
The hardware uses three of the GPO/GPI pins from the COM Express board
to drive an MDIO bus. Connectivity between GPI/GPO pins and the MDIO bus
is as follows.
David S. Miller [Wed, 16 Apr 2014 19:05:39 +0000 (15:05 -0400)]
Merge branch 'fib_validate_loopback'
Cong Wang says:
====================
ipv4: fix flowi4_iif for input routing
This patchset fixes ->flowi4_iif for input routing and rp filter,
based on suggestion from Julian. See per patch for details.
v1 -> v2:
* merge the first two patches into one
* fix fib_check_nh() too
* add this cover letter
====================
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: Cong Wang <cwang@twopensource.com> Reviewed-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: David S. Miller <davem@davemloft.net>
Cong Wang [Tue, 15 Apr 2014 23:25:35 +0000 (16:25 -0700)]
ipv4, route: pass 0 instead of LOOPBACK_IFINDEX to fib_validate_source()
In my special case, when a packet is redirected from veth0 to lo,
its skb->dev->ifindex would be LOOPBACK_IFINDEX. Meanwhile we
pass the hard-coded LOOPBACK_IFINDEX to fib_validate_source()
in ip_route_input_slow(). This would cause the following check
in fib_validate_source() fail:
when rp_filter is disabeld on loopback. As suggested by Julian,
the caller should pass 0 here so that we will not end up by
calling __fib_validate_source().
Cc: Eric Biederman <ebiederm@xmission.com> Cc: Julian Anastasov <ja@ssi.bg> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: Cong Wang <cwang@twopensource.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Cong Wang [Tue, 15 Apr 2014 23:25:34 +0000 (16:25 -0700)]
ipv4, fib: pass LOOPBACK_IFINDEX instead of 0 to flowi4_iif
As suggested by Julian:
Simply, flowi4_iif must not contain 0, it does not
look logical to ignore all ip rules with specified iif.
because in fib_rule_match() we do:
if (rule->iifindex && (rule->iifindex != fl->flowi_iif))
goto out;
flowi4_iif should be LOOPBACK_IFINDEX by default.
We need to move LOOPBACK_IFINDEX to include/net/flow.h:
1) It is mostly used by flowi_iif
2) Fix the following compile error if we use it in flow.h
by the patches latter:
In file included from include/linux/netfilter.h:277:0,
from include/net/netns/netfilter.h:5,
from include/net/net_namespace.h:21,
from include/linux/netdevice.h:43,
from include/linux/icmpv6.h:12,
from include/linux/ipv6.h:61,
from include/net/ipv6.h:16,
from include/linux/sunrpc/clnt.h:27,
from include/linux/nfs_fs.h:30,
from init/do_mounts.c:32:
include/net/flow.h: In function ‘flowi4_init_output’:
include/net/flow.h:84:32: error: ‘LOOPBACK_IFINDEX’ undeclared (first use in this function)
Cc: Eric Biederman <ebiederm@xmission.com> Cc: Julian Anastasov <ja@ssi.bg> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: Cong Wang <cwang@twopensource.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This was part of a patch by Alexander Guller from Mellanox in 2011,
but it still isn't upstream.
Signed-off-by: Chris Mason <clm@fb.com>
cc: stable@vger.kernel.org Acked-By: Amir Vadai <amirv@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
kernfs: protect lazy kernfs_iattrs allocation with mutex
kernfs_iattrs is allocated lazily when operations which require it
take place; unfortunately, the lazy allocation and returning weren't
properly synchronized and when there are multiple concurrent
operations, it might end up returning kernfs_iattrs which hasn't
finished initialization yet or different copies to different callers.
Fix it by synchronizing with a mutex. This can be smarter with memory
barriers but let's go there if it actually turns out to be necessary.
Thomas Bächler [Thu, 3 Apr 2014 19:55:37 +0000 (21:55 +0200)]
fs: Don't return 0 from get_anon_bdev
Commit 9e30cc9595303b27b48 removed an internal mount. This
has the side-effect that rootfs now has FSID 0. Many
userspace utilities assume that st_dev in struct stat
is never 0, so this change breaks a number of tools in
early userspace.
Since we don't know how many userspace programs are affected,
make sure that FSID is at least 1.
References: http://article.gmane.org/gmane.linux.kernel/1666905
References: http://permalink.gmane.org/gmane.linux.utilities.util-linux-ng/8557 Cc: 3.14 <stable@vger.kernel.org> Signed-off-by: Thomas Bächler <thomas@archlinux.org> Acked-by: Tejun Heo <tj@kernel.org> Acked-by: H. Peter Anvin <hpa@zytor.com> Tested-by: Alexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steve French [Wed, 26 Mar 2014 00:46:36 +0000 (19:46 -0500)]
Return correct error on query of xattr on file with empty xattrs
xfstest 020 detected a problem with cifs xattr handling. When a file
had an empty xattr list, we returned success (with an empty xattr value)
on query of particular xattrs rather than returning ENODATA.
This patch fixes it so that query of an xattr returns ENODATA when the
xattr list is empty for the file.
Signed-off-by: Steve French <smfrench@gmail.com> Reviewed-by: Jeff Layton <jlayton@redhat.com>
Sachin Prabhu [Tue, 11 Mar 2014 16:11:47 +0000 (16:11 +0000)]
cifs: Wait for writebacks to complete before attempting write.
Problem reported in Red Hat bz 1040329 for strict writes where we cache
only when we hold oplock and write direct to the server when we don't.
When we receive an oplock break, we first change the oplock value for
the inode in cifsInodeInfo->oplock to indicate that we no longer hold
the oplock before we enqueue a task to flush changes to the backing
device. Once we have completed flushing the changes, we return the
oplock to the server.
There are 2 ways here where we can have data corruption
1) While we flush changes to the backing device as part of the oplock
break, we can have processes write to the file. These writes check for
the oplock, find none and attempt to write directly to the server.
These direct writes made while we are flushing from cache could be
overwritten by data being flushed from the cache causing data
corruption.
2) While a thread runs in cifs_strict_writev, the machine could receive
and process an oplock break after the thread has checked the oplock and
found that it allows us to cache and before we have made changes to the
cache. In that case, we end up with a dirty page in cache when we
shouldn't have any. This will be flushed later and will overwrite all
subsequent writes to the part of the file represented by this page.
Before making any writes to the server, we need to confirm that we are
not in the process of flushing data to the server and if we are, we
should wait until the process is complete before we attempt the write.
We should also wait for existing writes to complete before we process
an oplock break request which changes oplock values.
We add a version specific downgrade_oplock() operation to allow for
differences in the oplock values set for the different smb versions.
Cc: stable@vger.kernel.org Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Reviewed-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru> Signed-off-by: Steve French <smfrench@gmail.com>
Larry Finger [Wed, 9 Apr 2014 16:12:58 +0000 (11:12 -0500)]
staging: r8188eu: Calling rtw_get_stainfo() with a NULL sta_addr will return NULL
This makes the follow-on check for psta != NULL pointless and makes
the whole exercise rather pointless. This is another case of why
blindly zero-initializing variables when they are declared is bad.
To avoid the circular dependency, just try to get the lock in
`comedi_mmap()` instead of blocking. Since the comedi device's main mutex
is heavily used, do a down-read of its `attach_lock` rwsemaphore
instead. Trying to down-read `attach_lock` should only fail if
some task has down-write locked it, and that is only done while the
comedi device is being attached to or detached from a low-level hardware
device.
Unfortunately, acquiring the `attach_lock` doesn't prevent another
task replacing the comedi data buffer we are trying to mmap. The
details of the buffer are held in a `struct comedi_buf_map` and pointed
to by `s->async->buf_map` where `s` is the comedi subdevice whose buffer
we are trying to map. The `struct comedi_buf_map` is already reference
counted with a `struct kref`, so we can stop it being freed prematurely.
Modify `comedi_mmap()` to call new function
`comedi_buf_map_from_subdev_get()` to read the subdevice's current
buffer map pointer and increment its reference instead of accessing
`async->buf_map` directly. Call `comedi_buf_map_put()` to decrement the
reference once the buffer map structure has been dealt with. (Note that
`comedi_buf_map_put()` does nothing if passed a NULL pointer.)
`comedi_buf_map_from_subdev_get()` checks the subdevice's buffer map
pointer has been set and the buffer map has been initialized enough for
`comedi_mmap()` to deal with it (specifically, check the `n_pages`
member has been set to a non-zero value). If all is well, the buffer
map's reference is incremented and a pointer to it is returned. The
comedi subdevice's spin-lock is used to protect the checks. Also use
the spin-lock in `__comedi_buf_alloc()` and `__comedi_buf_free()` to
protect changes to the subdevice's buffer map structure pointer and the
buffer map structure's `n_pages` member. (This checking of `n_pages` is
a bit clunky and I [Ian Abbott] plan to deal with it in the future.)
staging: r8723au: Add missing initialization of change_inx in sort algorithm
drivers/staging/rtl8723au/core/rtw_wlan_util.c: In function ‘WMMOnAssocRsp23a’:
drivers/staging/rtl8723au/core/rtw_wlan_util.c:684: warning: ‘change_inx’ may be used uninitialized in this function
Depending on the uninitialized data on the stack, the array may not be
sorted correctly.
staging: speakup: fix misuse of kstrtol() in handle_goto()
A string of goto_buf has a number followed by x or y.
e.g. "3x" means move 3 lines down.
The kstrtol() returns an error(-EINVAL) with this string so
go_pos has unsigned a value of that error.
And also "*cp" has not expected value.
And fix sparse warnings:
drivers/staging/speakup/main.c:1901 handle_goto() warn: unsigned '(speakup_console[vc->vc_num]->go_pos)' is never less than zero.
drivers/staging/speakup/main.c:1911 handle_goto() warn: unsigned '(speakup_console[vc->vc_num]->go_pos)' is never less than zero.
If misc_register failed in goldfish_audio_probe, the already requested
IRQ wouldn't get freed. Add a call to free_irq() like there is in
goldfish_audio_remove().
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Wed, 16 Apr 2014 18:37:13 +0000 (14:37 -0400)]
Merge branch 'mvneta_qsgmii'
Thomas Petazzoni says:
====================
net: mvneta: fix usage as a module, and support QSGMII properly
This set of patches is a new attempt at fixing the operation of the
mvneta driver when built as a module. For the record, the previous
attempt, merged in commit e3a8786c10e75903f1269474e21fe8cb49c3a670
('net: mvneta: fix usage as a module on RGMII configurations') caused
problems for all RGMII configurations.
In fact, it turned out that the MAC to PHY connection on the Armada XP
GP, which was described as using RGMII-ID according to its Device
Tree, is in fact a QSGMII connection. And the RGMII and QSGMII
configurations have to be handled in a different way in the driver,
because the SERDES configuration is different in those two cases.
So, this patch series fixes that by:
* Adding minimal handling of a "qsgmii" connection type in the PHY
layer. Mainly to make sure that a "qsgmii" phy-mode in the Device
Tree is recognized, and handed over to the driver as
PHY_INTERFACE_QSGMII.
* Changing the mvneta driver to properly configure the RGMIIEn and
PCSEn bits in the GMAC_CTRL_2 register, and configure the SERDES
register, in the three possible cases: RGMII, SGMII and QSGMII.
* Updating the Device Tree of the Armada XP GP board to reflect the
fact that it uses a QSGMII MAC/PHY connection.
PATCH 1 and 2 would be merged by David Miller, through the net tree,
while PATCH 3 would be merged by the mach-mvebu maintainers, through
their tree and arm-soc.
This set of patches has been tested on:
* Armada XP GP (four QSGMII interfaces)
* Armada XP DB (two RGMII interfaces and two SGMII interfaces)
* Armada 370 Mirabox (two RGMII interfaces)
I've tested both the driver built-in, and compiled as a module.
Since the last attempt at fixing this was quite a fiasco, I'd like
this new attempt to be tested more widely before being applied. I'll
try to do some testing on other Armada boards I have, but independent
testing from other persons would also be appreciated.
Note that these patches apply after reverting the previous attempt,
obviously.
====================
Tested-by: Arnaud Ebalard <arno@natisbad.org> Tested-by: Willy Tarreau <w@1wt.eu> Signed-off-by: David S. Miller <davem@davemloft.net>
Thomas Petazzoni [Tue, 15 Apr 2014 13:50:20 +0000 (15:50 +0200)]
net: mvneta: properly configure the MAC <-> PHY connection in all situations
Commit 5445eaf309ff ('mvneta: Try to fix mvneta when compiled as
module') fixed the mvneta driver to make it work properly when loaded
as a module in SGMII configuration, which was tested successful by the
author on the Armada XP OpenBlocks AX3, which uses SGMII.
However, some other platforms, namely the Armada XP GP don't use
SGMII, but a QSGMII connection between the MAC and the PHY, and this
case was not supported by the mvneta driver, which was relying on
configuration put in place by the bootloader. While this works when
the mvneta driver is built-in (because clocks are not gated), it
breaks when mvneta is built as a module, because the clock is gated
(all configuration is lost) and then re-enabled when the mvneta driver
is loaded.
In order to support all of RGMII, SGMII and QSGMII, this commit
reworks how the PHY interface configuration is done, and simplifies
it: it removes the mvneta_port_sgmii_config() and
mvneta_gmac_rgmii_set() functions, which were strange because
mvneta_gmac_rgmii_set() was called in all cases, even for SGMII
configurations. Also, the mvneta_gmac_rgmii_set() function was taking
a boolean as argument, which was always true.
Instead, all the PHY interface configuration logic is moved into the
mvneta_port_power_up() function, in a much simpler 'switch' construct,
with four cases:
- QSGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
the SERDES is configured in QSGMII. Technically speaking,
configuring the SERDES of the first port would be sufficient, but
it is simpler to do it on all ports.
- SGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
the SERDES is configured as SGMII.
- RGMII: the RGMIIEn bit in GMAC_CTRL_2 is set. The PCSEn bit is kept
cleared, and no SERDES configuration is done, because RGMII is not
using SERDES lanes.
- other: an error is returned. For this reason, the
mvneta_port_power_up() now returns an int instead of nothing, and
the return value is checked by mvneta_probe().
This has been successfully tested on:
* Armada XP DB, which has two RGMII and two SGMII connections
* Armada XP GP, which uses QSGMII for its four interfaces
* Armada 370 Mirabox, which has two RGMII connections
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Thomas Petazzoni [Tue, 15 Apr 2014 13:50:19 +0000 (15:50 +0200)]
net: phy: add minimal support for QSGMII PHY
This commit adds the necessary definitions for the PHY layer to
recognize "qsgmii" as a valid PHY interface. A QSMII interface, as
defined at
http://en.wikipedia.org/wiki/Media_Independent_Interface#Quad_Serial_Gigabit_Media_Independent_Interface,
is "is a method of combining four SGMII lines into a 5Gbit/s
interface. QSGMII, like SGMII, uses LVDS signalling for the TX and RX
data and a single LVDS clock signal. QSGMII uses significantly fewer
signal lines than four SGMII busses."
This type of MAC <-> PHY connection might require special handling on
the MAC driver side, so it should be possible to express this type of
MAC <-> PHY connection, for example in the Device Tree.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: devicetree@vger.kernel.org Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Edward Cree [Wed, 16 Apr 2014 18:27:48 +0000 (19:27 +0100)]
sfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast)
When an MCDI command times out (whether or not we find it
completed when we poll), call efx_mcdi_abandon(), which tells
all subsequent MCDI calls to fail-fast, and queues up an FLR.
Because an FLR doesn't lead to receiving any reboot even from
the MC (unlike most other types of reset), we have to call
efx_ef10_reset_mc_allocations.
In efx_start_all(), if a reset (of any kind) is pending, we
bail out.
Without this, attempts to reconfigure (e.g. change mtu) can
cause driver/mc state inconsistency if the first MCDI call
triggers an FLR.
For similar reasons, on EF10, in
efx_reset_down(method=RESET_TYPE_MCDI_TIMEOUT), set the number
of active queues to zero before calling efx_stop_all().
And, on farch, in efx_reset_up(method=RESET_TYPE_MCDI_TIMEOUT),
set active_queues and flushes pending & outstanding to zero.
efx_mcdi_mode_{poll,event}() should not take us out of fail-fast
mode. Instead, this is done by efx_mcdi_reset() after the FLR
completes.
The new FLR reset_type RESET_TYPE_MCDI_TIMEOUT doesn't really
fit into the hierarchy of reset 'scopes' whereby efx_reset()
decides some resets subsume others. Thus, it uses separate logic.
Also, fixed up some inconsistency around RESET_TYPE_MC_BIST,
which was in the wrong place in that hierarchy.
Signed-off-by: Shradha Shah <sshah@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 patches from Martin Schwidefsky:
"An update to the oops output with additional information about the
crash. The renameat2 system call is enabled. Two patches in regard
to the PTR_ERR_OR_ZERO cleanup. And a bunch of bug fixes"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/sclp_cmd: replace PTR_RET with PTR_ERR_OR_ZERO
s390/sclp: replace PTR_RET with PTR_ERR_OR_ZERO
s390/sclp_vt220: Fix kernel panic due to early terminal input
s390/compat: fix typo
s390/uaccess: fix possible register corruption in strnlen_user_srst()
s390: add 31 bit warning message
s390: wire up sys_renameat2
s390: show_registers() should not map user space addresses to kernel symbols
s390/mm: print control registers and page table walk on crash
s390/smp: fix smp_stop_cpu() for !CONFIG_SMP
s390: fix control register update
Merge tag 'please-pull-ia64-erratum' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux
Pull itanium erratum fix from Tony Luck:
"Small workaround for a rare, but annoying, erratum #237"
* tag 'please-pull-ia64-erratum' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux:
[IA64] Change default PSR.ac from '1' to '0' (Fix erratum #237)
=========================================================================
237. Under a complex set of conditions, store to load forwarding for a
sub 8-byte load may complete incorrectly
Problem: A load instruction may complete incorrectly when a code sequence
using 4-byte or smaller load and store operations to the same address
is executed in combination with specific timing of all the following
concurrent conditions: store to load forwarding, alignment checking
enabled, a mis-predicted branch, and complex cache utilization activity.
Implication: The affected sub 8-byte instruction may complete
incorrectly resulting in unpredictable system behavior. There is an
extremely low probability of exposure due to the significant number of
complex microarchitectural concurrent conditions required to encounter
the erratum.
Workaround: Set PSR.ac = 0 to completely avoid the erratum. Disabling
Hyper-Threading will significantly reduce exposure to the conditions
that contribute to encountering the erratum.
Status: See the Summary Table of Changes for the affected steppings.
=========================================================================
[Table of changes essentially lists all models from McKinley to Tukwila]
The PSR.ac bit controls whether the processor will always generate
an unaligned reference trap (0x5a00) for a misaligned data access
(when PSR.ac=1) or if it will let the access succeed when running
on a cpu that implements logic to handle some unaligned accesses.
Way back in 2008 in commit b704882e70d87d7f56db5ff17e2253f3fa90e4f3
[IA64] Rationalize kernel mode alignment checking
we made the decision to always enable strict checking. We were
already doing so in trap/interrupt context because the common
preamble code set this bit - but the rest of supervisor code
(and by inheritance user code) ran with PSR.ac=0.
We now reverse that decision and set PSR.ac=0 everywhere in the
kernel (also inherited by user processes). This will avoid the
erratum using the method described in the Itanium specification
update. Net effect for users is that the processor will handle
unaligned access when it can (typically with a tiny performance
bubble in the pipeline ... but much less invasive than taking a
trap and having the OS perform the access).
Lucas Stach [Wed, 16 Apr 2014 16:24:32 +0000 (10:24 -0600)]
PCI: tegra: Use new OF interrupt mapping when possible
Use new OF interrupt mapping (of_irq_parse_and_map_pci()) when possible.
This is the recommended method of doing the IRQ mapping. For old
devicetrees we fall back to the previous practice.
This allows interrupts to be remapped across bridges.
Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
Lucas Stach [Wed, 16 Apr 2014 16:24:09 +0000 (10:24 -0600)]
PCI: rcar: Use new OF interrupt mapping when possible
Use new OF interrupt mapping (of_irq_parse_and_map_pci()) when possible.
This is the recommended method of doing the IRQ mapping. For old
devicetrees we fall back to the previous practice.
This allows interrupts to be remapped across bridges.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Simon Horman <horms+renesas@verge.net.au>
projects / mirror_ubuntu-artful-kernel.git / log