Move pci_get_hp_params() and related functions from
drivers/pci/hotplug/acpi_pcihp.c to drivers/pci/pci-acpi.c.
Previously, pci_get_hp_params() was used only by hotplug drivers. But
future changes will move this into the normal device enumeration process,
so it will be used even when CONFIG_HOTPLUG_PCI is not set.
No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
We configure cache line size and other settings of hot-added devices, e.g.,
based on ACPI _HPP or _HPX methods. Previously we skipped this for display
devices, but ACPI rev 5.0, sec 6.2.7 and 6.2.8 have no requirement to skip
them.
Remove the check so we configure display devices the same way we configure
other devices.
See also ac81860ea0 ("PCI: hotplug: pciehp: Removed check for hotplug of
display devices").
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
The ftrace_enabled variable is set to zero in the self tests to keep
delayed functions from being traced and messing with the checks. This
only needs to be done when the checks are being performed, otherwise,
if ftrace_enabled is off when calls back to the utility that is being
tested, it can cause errors to happen and the tests can fail with
false positives.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
When the last ftrace_ops is unregistered, all the function records should
have a zeroed flags value. Make sure that is the case when the last ftrace_ops
is unregistered.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
arm64.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJUE0aVAAoJEIlPj0hw4a6QG9oQAO1xew3cWPYpougi/Nd19R70
dawtzs19Edj9CDgUC9OQE1JC7J/jG5ElZb3qFc7ICQl90akgx/d7BTWO/6dMGEzw
PtLc60M1lFY60aNYN6T+DLjUxYtwfq74g6x2RjRI4jLaSREVlsOJnV7b0vo4bLpP
tTLc65+Zo35cWykzImoj7nu5JxBsoJYNPCrKWz3B6nOjDiRf99zRAz2yhEt54ajz
BIfg36WbwyvZie5Nxgxp46Ou1hTsmZHmv5MFHhLga0jHRIRfiWnbrEc2pppI64DA
l7sMkz0MwPXdu/Auq4hHstbnLw7OBqE4PfMvPqs4bK2SVQOPB48W3Q+QwhK59iS5
9ytw9j2EGvdEhTDhRs6FQmqaII/xbyvqMQDmdXwDpBzo/+az656RFMQ4eS5+zLDu
JG+ws9Ozt2WJRFQvWiC8zgYRBKiVBkR6SeEf44WiYjRp9HV9gxIXgAIo7AUoNNjQ
USNd4yEkzqMD4aILekNkFvUm5uu/gzCNdmb1N2iIk1gS9CWh4fEUTNRjUr5tqXiR
9iNacoR4Iz96DjE2ZSLnno+1eq1tRNm8nYo/NFe9+SohlfjiSmsnpTJg8FxmrIer
CeqAYTBgQtO+8HOJL/hM2IdFX5EcT+0TYs3DWmoqxqcgOyhK4AFM1XhUWNLpxquH
y6ojU5lRs/E/L8ycGAGg
=gWAc
-----END PGP SIGNATURE-----
Merge tag 'stable/for-linus-3.17-b-rc4-arm-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull Xen ARM bugfix from Stefano Stabellini:
"The patches fix the "xen_add_mach_to_phys_entry: cannot add" bug that
has been affecting xen on arm and arm64 guests since 3.16. They
require a few hypervisor side changes that just went in xen-unstable.
A couple of days ago David sent out a pull request with a few other
Xen fixes (it is already in master). Sorry we didn't synchronized
better among us"
* tag 'stable/for-linus-3.17-b-rc4-arm-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/arm: remove mach_to_phys rbtree
xen/arm: reimplement xen_dma_unmap_page & friends
xen/arm: introduce XENFEAT_grant_map_identity
The matches_pnp_id function from the synaptics driver is useful for other
drivers too. Make it a generic psmouse helper function.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
nstat->multicast refers to received packets, not transmitted as
is returned here. Change it so that received packet stats are
given.
Signed-off-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
John W. Linville says:
====================
pull request: wireless 2014-09-11
Please pull this batch of fixes intended for the 3.17 stream:
For the mac80211 bits, Johannes says:
"Two more fixes for mac80211 - one of them addresses a long-standing
issue that we only found when using vendor events more frequently;
the other addresses some bad information being reported in userspace
that people were starting to actually look at."
For the iwlwifi bits, Emmanuel says:
"I re-enable scheduled scan on firmware that contain the fix for
the bug that Linus reported. A few trivial fixes: endianity issues,
the same DTIM period fix that I did in mac80211. Eyal fixes a few
issues we identified with EAPOL, we now send them just as if they were
management frames, this solves interrop issues. Johannes has another
set of trivial fixes, while Luca fixes the way we configure the filters
in the firmware. Last but not least, a new device is added by Oren."
Emmanuel was traveling, resulting in his pull to be a bit larger than
I would have liked to see at this point. FWIW, I have asked Emmanuel
to be much more strict for any more pull requests in this cycle.
In addition to the above, Sujith Manoharan reverts an earlier ath9k
patch. The earlier change was found to allow for the device to sleep
too long and miss beacons.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When sending out a burst of packets across multiple descriptors,
it is sufficient to send one LDC "start" trigger for
the first descriptor, so do not send an LDC "start" for every
pass through vnet_start_xmit. Similarly, it is sufficient to send
one "DRING_STOPPED" trigger for the last dring (and if that
fails, hold off and send the trigger later).
Optimizations to the number of LDC messages helps avoid
filling up the LDC channel with superfluous LDC messages
that risk triggering flow-control on the channel,
and also boosts performance.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Acked-by: Raghuram Kothakota <raghuram.kothakota@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
calling ether_setup is redundant since alloc_etherdev calls
it.
Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlQRT78ACgkQjTAFq1RaXHPWdACeMBxR8SuasImK4tZSMZf7Sw7F
1bkAoJkftw6Aup9IV9uty4xohLb4pVgX
=kha5
-----END PGP SIGNATURE-----
Merge tag 'linux-can-fixes-for-3.17-20140911' of git://gitorious.org/linux-can/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2014-09-11
this is a pull request for the current release cycle of a single patch.
The patch by David Jander fixes a scheduling while atomic problem in the
flexcan driver, that was introduced by me in v3.14-rc6.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
It will use pr_info_one() to print the version info of the
driver in probe function only once. No need to use the static
variable here.
Signed-off-by: Varka Bhadram <varkab@cdac.in>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 2abb7cdc0d ("udp: Add support for doing checksum unnecessary
conversion") caused napi_gro_cb structs with the "flush" field zero to
take the "udp_gro_receive" path rather than the "set flush to 1" path
that they would previously take. As a result I saw booting from an NFS
root hang shortly after starting userspace, with "server not
responding" messages.
This change to the handling of "flush == 0" packets appears to be
incidental to the goal of adding new code in the case where
skb_gro_checksum_validate_zero_check() returns zero. Based on that and
the fact that it breaks things, I'm assuming that it is unintentional.
Fixes: 2abb7cdc0d ("udp: Add support for doing checksum unnecessary conversion")
Cc: Tom Herbert <therbert@google.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Duyck says:
====================
Address reference counting issues with sock_queue_err_skb
After looking over the code for skb_clone_sk after some comments made by
Eric Dumazet I have come to the conclusion that skb_clone_sk is taking the
correct approach in how to handle the sk_refcnt when creating a buffer that
is eventually meant to be returned to the socket via the sock_queue_err_skb
function.
However upon review of other callers I found what I believe to be a
possible reference count issue in the path for handling "wifi ack" packets.
To address this I have applied the same logic that is currently in place so
that the sk_refcnt will be forced to stay at least 1, or we will not
provide an skb to return in the sk_error_queue.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
There is a possible issue with the use, or lack thereof of sk_refcnt and
sk_wmem_alloc in the wifi ack status functionality.
Specifically if a socket were to request acknowledgements, and the socket
were to have sk_refcnt drop to 0 resulting in it waiting on sk_wmem_alloc
to reach 0 it would be possible to have sock_queue_err_skb orphan the last
buffer, resulting in __sk_free being called on the socket. After this the
buffer is enqueued on sk_error_queue, however the queue has already been
flushed resulting in at least a memory leak, if not a data corruption.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
This change adds some documentation to the call skb_clone_sk. This is
meant to help clarify the purpose of the function for other developers.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If we try to rmmod the driver for an interface while sockets with
setsockopt(JOIN_ANYCAST) are alive, some refcounts aren't cleaned up
and we get stuck on:
unregister_netdevice: waiting for ens3 to become free. Usage count = 1
If we LEAVE_ANYCAST/close everything before rmmod'ing, there is no
problem.
We need to perform a cleanup similar to the one for multicast in
addrconf_ifdown(how == 1).
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Beniamino Galvani says:
====================
net: arc_emac: fix tx issues
the patches below solve some issues found in the tx ring reclaim
strategy currently implemented in the arc_emac driver.
Without these patches a simple outgoing UDP flow blocks almost
immediately with the socket send buffer full, until some new rx
packets trigger a clean of the tx ring.
Everything seems to work fine on a Radxa Rock with this fix applied.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch changes the logic in tx path to ensure that tx descriptors
are reused for transmission only after they have been reclaimed by
arc_emac_tx_clean().
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the current implementation the cleaning of tx ring is done by the
NAPI poll handler, which is scheduled after rx interrupts. Thus, in
absence of received packets the reclaim of used tx buffers is never
executed, blocking further transmission.
This can be easily reproduced starting the transmission of a UDP flow
with iperf, which blocks almost immediately because skbs are not
returned to the stack and the socket send buffer becomes full.
The patch enables tx interrupts so that the tx reclaim is scheduled
after completed transmissions.
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
led_update_brightness helper function used to be exploited only locally
in the led-class.c module, where its result was being passed to the
brightness_show sysfs callback. With the introduction of v4l2-flash
subdevice the same functionality becomes required for reading current
brightness from a LED device. This patch adds checking of return value
of the brightness_get callback and moves the led_update_brightness()
function to the LED subsystem public API.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
So here's the header cleanup, rebased on top of drm-next. Two new header
files are created here:
- drivers/gpu/drm/drm_internal.h for non-legacy drm.ko private
declarations.
- include/drm/drm_legacy.h for legacy interfaces used by non-kms drivers.
And of course lots fo stuff gets shuffled into the already existing
drivers/gpu/drm/drm_legacy.h for drm.ko internal stuff.
topic branch smoke-tested in drm-intel-nightly for a bit. And the 0day
tester also worked through it (and found a few places I didn't add a
static to functions).
* tag 'topic/drm-header-rework-2014-09-12' of git://anongit.freedesktop.org/drm-intel:
drm: Move DRM_MAGIC_HASH_ORDER into drm_drv.c
drm: Move drm_class to drm_internal.h
drm: Move LOCK_TEST_WITH_RETURN to <drm/drm_legacy.h>
drm: Move legacy buffer structures to <drm/drm_legacy.h>
drm: Move drm_memory.c map support declarations to <drm/drm_legacy.h>
drm: Purge ioctl forward declarations from drmP.h
drm: unexport drm_global_mutex
drm: Move piles of functions from drmP.h to drm_internal.h
drm: Move vblank related module options into drm_irq.c
drm: Drop drm_sysfs_class from drmP.h
drm: Move __drm_pci_free to drm_legacy.h
drm: Create drm legacy driver header
drm: Move drm_legacy_vma_flush into drm_legacy.h
drm: Move sg functions into drm_legacy.h
drm: Move dma functions into drm_legacy.h
Locks the k_itimer's it_lock member when handling the alarm timer's
expiry callback.
The regular posix timers defined in posix-timers.c have this lock held
during timout processing because their callbacks are routed through
posix_timer_fn(). The alarm timers follow a different path, so they
ought to grab the lock somewhere else.
Cc: stable@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Sharvil Nanavati <sharvil@google.com>
Signed-off-by: Richard Larocque <rlarocque@google.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Avoids sending a signal to alarm timers created with sigev_notify set to
SIGEV_NONE by checking for that special case in the timeout callback.
The regular posix timers avoid sending signals to SIGEV_NONE timers by
not scheduling any callbacks for them in the first place. Although it
would be possible to do something similar for alarm timers, it's simpler
to handle this as a special case in the timeout.
Prior to this patch, the alarm timer would ignore the sigev_notify value
and try to deliver signals to the process anyway. Even worse, the
sanity check for the value of sigev_signo is skipped when SIGEV_NONE was
specified, so the signal number could be bogus. If sigev_signo was an
unitialized value (as it often would be if SIGEV_NONE is used), then
it's hard to predict which signal will be sent.
Cc: stable@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Sharvil Nanavati <sharvil@google.com>
Signed-off-by: Richard Larocque <rlarocque@google.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Returns the time remaining for an alarm timer, rather than the time at
which it is scheduled to expire. If the timer has already expired or it
is not currently scheduled, the it_value's members are set to zero.
This new behavior matches that of the other posix-timers and the POSIX
specifications.
This is a change in user-visible behavior, and may break existing
applications. Hopefully, few users rely on the old incorrect behavior.
Cc: stable@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Sharvil Nanavati <sharvil@google.com>
Signed-off-by: Richard Larocque <rlarocque@google.com>
[jstultz: minor style tweak]
Signed-off-by: John Stultz <john.stultz@linaro.org>
timeval_to_jiffies tried to round a timeval up to an integral number
of jiffies, but the logic for doing so was incorrect: intervals
corresponding to exactly N jiffies would become N+1. This manifested
itself particularly repeatedly stopping/starting an itimer:
setitimer(ITIMER_PROF, &val, NULL);
setitimer(ITIMER_PROF, NULL, &val);
would add a full tick to val, _even if it was exactly representable in
terms of jiffies_ (say, the result of a previous rounding.) Doing
this repeatedly would cause unbounded growth in val. So fix the math.
Here's what was wrong with the conversion: we essentially computed
(eliding seconds)
jiffies = usec * (NSEC_PER_USEC/TICK_NSEC)
by using scaling arithmetic, which took the best approximation of
NSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC =
x/(2^USEC_JIFFIE_SC), and computed:
jiffies = (usec * x) >> USEC_JIFFIE_SC
and rounded this calculation up in the intermediate form (since we
can't necessarily exactly represent TICK_NSEC in usec.) But the
scaling arithmetic is a (very slight) *over*approximation of the true
value; that is, instead of dividing by (1 usec/ 1 jiffie), we
effectively divided by (1 usec/1 jiffie)-epsilon (rounding
down). This would normally be fine, but we want to round timeouts up,
and we did so by adding 2^USEC_JIFFIE_SC - 1 before the shift; this
would be fine if our division was exact, but dividing this by the
slightly smaller factor was equivalent to adding just _over_ 1 to the
final result (instead of just _under_ 1, as desired.)
In particular, with HZ=1000, we consistently computed that 10000 usec
was 11 jiffies; the same was true for any exact multiple of
TICK_NSEC.
We could possibly still round in the intermediate form, adding
something less than 2^USEC_JIFFIE_SC - 1, but easier still is to
convert usec->nsec, round in nanoseconds, and then convert using
time*spec*_to_jiffies. This adds one constant multiplication, and is
not observably slower in microbenchmarks on recent x86 hardware.
Tested: the following program:
int main() {
struct itimerval zero = {{0, 0}, {0, 0}};
/* Initially set to 10 ms. */
struct itimerval initial = zero;
initial.it_interval.tv_usec = 10000;
setitimer(ITIMER_PROF, &initial, NULL);
/* Save and restore several times. */
for (size_t i = 0; i < 10; ++i) {
struct itimerval prev;
setitimer(ITIMER_PROF, &zero, &prev);
/* on old kernels, this goes up by TICK_USEC every iteration */
printf("previous value: %ld %ld %ld %ld\n",
prev.it_interval.tv_sec, prev.it_interval.tv_usec,
prev.it_value.tv_sec, prev.it_value.tv_usec);
setitimer(ITIMER_PROF, &prev, NULL);
}
return 0;
}
Cc: stable@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Paul Turner <pjt@google.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Reviewed-by: Paul Turner <pjt@google.com>
Reported-by: Aaron Jacobs <jacobsa@google.com>
Signed-off-by: Andrew Hunter <ahh@google.com>
[jstultz: Tweaked to apply to 3.17-rc]
Signed-off-by: John Stultz <john.stultz@linaro.org>
In the Dell XPS 13 9333, it appears that sometimes the bus get confused
and corrupts the incoming data. It fills the input report with the
sentinel value "ff". Synaptics told us that such behavior does not comes
from the touchpad itself, so we filter out such reports here.
Unfortunately, we can not simply discard the incoming data because they
may contain useful information. Most of the time, the misbehavior is
quite near the end of the report, so we can still use the valid part of
it.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1123584
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
DWC3 glue layer is hardware layer around Synopsys DesignWare
USB3 core. Its purpose is to supply Synopsys IP with required
clocks, voltages and interface it with the rest of the SoC.
Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
Signed-off-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This reverts commit c801e3cc19 ("ipv4: Clarify in docs that accept_local requires rp_filter.").
It is not needed anymore since commit 1dced6a854 ("ipv4: Restore accept_local behaviour in fib_validate_source()").
Suggested-by: Julian Anastasov <ja@ssi.bg>
Cc: Gregory Detal <gregory.detal@uclouvain.be>
Cc: Christoph Paasch <christoph.paasch@uclouvain.be>
Cc: Hannes Frederic Sowa <hannes@redhat.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
QCOM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration registers.
It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).
Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
Signed-off-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
create_singlethread_workqueue() is a compat interface for single
threaded workqueue which maps to ordered workqueue w/ rescuer in the
current implementation. create_singlethread_workqueue() currently
implemented by invoking alloc_workqueue() w/ appropriate parameters.
8719dceae2 ("workqueue: reject adjusting max_active or applying
attrs to ordered workqueues") introduced __WQ_ORDERED to protect
ordered workqueues against dynamic attribute changes which can break
ordering guarantees but forgot to apply it to
create_singlethread_workqueue(). This in itself is okay as nobody
currently uses dynamic attribute change on workqueues created with
create_singlethread_workqueue().
However, 4c16bd327c ("workqueue: implement NUMA affinity for unbound
workqueues") broke singlethreaded guarantee for ordered workqueues
through allocating a separate pool_workqueue on each NUMA node by
default. A later change 8a2b753844 ("workqueue: fix ordered
workqueues in NUMA setups") fixed it by allocating only one global
pool_workqueue if __WQ_ORDERED is set.
Combined, the __WQ_ORDERED omission in create_singlethread_workqueue()
became critical breaking its single threadedness and ordering
guarantee.
Let's make create_singlethread_workqueue() wrap
alloc_ordered_workqueue() instead so that it inherits __WQ_ORDERED and
can implicitly track future ordered_workqueue changes.
v2: I missed that __WQ_ORDERED now protects against pwq splitting
across NUMA nodes and incorrectly described the patch as a
nice-to-have fix to protect against future dynamic attribute
usages. Oleg pointed out that this is actually a critical
breakage due to 8a2b753844 ("workqueue: fix ordered workqueues
in NUMA setups").
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Mike Anderson <mike.anderson@us.ibm.com>
Cc: Oleg Nesterov <onestero@redhat.com>
Cc: Gustavo Luiz Duarte <gduarte@redhat.com>
Cc: Tomas Henzl <thenzl@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 4c16bd327c ("workqueue: implement NUMA affinity for unbound workqueues")
futex_wait_requeue_pi() calls futex_wait_setup(). If
futex_wait_setup() succeeds it returns with hb->lock held and
preemption disabled. Now the sanity check after this does:
if (match_futex(&q.key, &key2)) {
ret = -EINVAL;
goto out_put_keys;
}
which releases the keys but does not release hb->lock.
So we happily return to user space with hb->lock held and therefor
preemption disabled.
Unlock hb->lock before taking the exit route.
Reported-by: Dave "Trinity" Jones <davej@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1409112318500.4178@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Callers of d_splice_alias(dentry, inode) don't need iput(), neither
on success nor on failure. Either the reference to inode is stored
in a previously negative dentry, or it's dropped. In either case
inode reference the caller used to hold is consumed.
__gfs2_lookup() does iput() in case when d_splice_alias() has failed.
Double iput() if we ever hit that. And gfs2_create_inode() ends up
not only with double iput(), but with link count dropped to zero - on
an inode it has just found in directory.
Cc: stable@vger.kernel.org # v3.14+
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Here is one misc driver fix for 3.17-rc5. It resolves a kernel oops
that can happen in the lattice FPGA driver if the firmware isn't
present on the system.
It's been in the linux-next tree for a while now.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlQTOR4ACgkQMUfUDdst+ylXvACeKk2PemIzfaUoGTmgkGoOioX4
BIsAoLE2jr9/ivh9r+0hkudNGnmBzVI4
=PSdY
-----END PGP SIGNATURE-----
Merge tag 'char-misc-3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fix from Greg KH:
"Here is one misc driver fix for 3.17-rc5. It resolves a kernel oops
that can happen in the lattice FPGA driver if the firmware isn't
present on the system.
It's been in the linux-next tree for a while now"
* tag 'char-misc-3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
Lattice ECP3 FPGA: Check firmware pointer
Here are 3 tiny staging driver fixes for 3.17-rc5. Two are fixes for
the imx-drm driver, resolving issues that have been reported. The other
is a memory leak fix for the Android sync driver, due to changes that
went into 3.17-rc1.
All have been in linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlQTOKgACgkQMUfUDdst+ykAowCg1HK4Ur/8WFty0TQyaZiz3sTX
j0sAnRBGo8Cqe1hPk5D5WADTdyuTYVtv
=TvOc
-----END PGP SIGNATURE-----
Merge tag 'staging-3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fixes from Greg KH:
"Here are 3 tiny staging driver fixes for 3.17-rc5.
Two are fixes for the imx-drm driver, resolving issues that have been
reported. The other is a memory leak fix for the Android sync driver,
due to changes that went into 3.17-rc1.
All have been in linux-next for a while"
* tag 'staging-3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
android: fix reference leak in sync_fence_create
imx-drm: imx-ldb: fix NULL pointer in imx_ldb_unbind()
imx-drm: ipuv3-plane: fix ipu_plane_dpms()
Here are 3 patches for 3.17-rc5. Two serial driver fixes that resolve
some reported issues, and one new device id.
All have been in linux-next just fine.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlQTNocACgkQMUfUDdst+ylSFQCfcarOgwBv2UaO9rR7IxrBXL5P
z5AAnR5wa7Ip5UpfSyqhg67qg42ffq2J
=G50/
-----END PGP SIGNATURE-----
Merge tag 'tty-3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are 3 patches for 3.17-rc5. Two serial driver fixes that resolve
some reported issues, and one new device id.
All have been in linux-next just fine"
* tag 'tty-3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: xuartps: Fix tx_emtpy() callback
tty/serial: at91: BUG: disable interrupts when !UART_ENABLE_MS()
serial: 8250_dw: Add ACPI ID for Intel Braswell
Here are some USB and PHY fixes for 3.17-rc5.
Nothing major here, just a number of tiny fixes for reported issues, and
some new device ids as well.
All have been tested in linux-next.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlQTNfsACgkQMUfUDdst+yk2ZwCfQOF5dNNui7FbtSWWy6h82CBN
25YAoKXJtipABRJo5q+bztCIDYGk0PgA
=4Ial
-----END PGP SIGNATURE-----
Merge tag 'usb-3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some USB and PHY fixes for 3.17-rc5.
Nothing major here, just a number of tiny fixes for reported issues,
and some new device ids as well.
All have been tested in linux-next"
* tag 'usb-3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (46 commits)
xhci: fix oops when xhci resumes from hibernate with hw lpm capable devices
usb: xhci: Fix OOPS in xhci error handling code
xhci: Fix null pointer dereference if xhci initialization fails
storage: Add single-LUN quirk for Jaz USB Adapter
uas: Add missing le16_to_cpu calls to asm1051 / asm1053 usb-id check
usb: chipidea: msm: Initialize PHY on reset event
usb: chipidea: msm: Use USB PHY API to control PHY state
usb: hub: take hub->hdev reference when processing from eventlist
uas: Disable uas on ASM1051 devices
usb: dwc2/gadget: avoid disabling ep0
usb: dwc2/gadget: delay enabling irq once hardware is configured properly
usb: dwc2/gadget: do not call disconnect method in pullup
usb: dwc2/gadget: break infinite loop in endpoint disable code
usb: dwc2/gadget: fix phy initialization sequence
usb: dwc2/gadget: fix phy disable sequence
uwb: init beacon cache entry before registering uwb device
USB: ftdi_sio: Add support for GE Healthcare Nemo Tracker device
USB: document the 'u' flag for usb-storage quirks parameter
usb: host: xhci: fix compliance mode workaround
usb: dwc3: fix TRB completion when multiple TRBs are started
...
Pull btrfs fixes from Chris Mason:
"Filipe is doing a careful pass through fsync problems, and these are
the fixes so far. I'll have one more for rc6 that we're still
testing.
My big commit is fixing up some inode hash races that Al Viro found
(thanks Al)"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
Btrfs: use insert_inode_locked4 for inode creation
Btrfs: fix fsync data loss after a ranged fsync
Btrfs: kfree()ing ERR_PTRs
Btrfs: fix crash while doing a ranged fsync
Btrfs: fix corruption after write/fsync failure + fsync + log recovery
Btrfs: fix autodefrag with compression
Both blocks layout and objects layout want to use it to avoid CB_LAYOUTRECALL
but that should only happen if client is doing truncation to a smaller size.
For other cases, we let server decide if it wants to recall client's layouts.
Change PNFS_LAYOUTRET_ON_SETATTR to follow the logic and not to send
layoutreturn unnecessarily.
Cc: Christoph Hellwig <hch@lst.de>
Cc: Boaz Harrosh <boaz@plexistor.com>
Signed-off-by: Peng Tao <tao.peng@primarydata.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
This code is internal to the v3 module, so other parts of the client
shouldn't have any knowledge of it.
nfs3_getxattr(), nfs3_setxattr(), and nfs3_removexattr() no longer exist
anywhere so I remove the declarations while I'm here.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
This check is already performed by the module loading code - if the
module can't be found then -EPROTONOSUPPORT will be returned. Let's
handle v3 this way, too.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
I am generally against the "one big header file" approach, and
everything in the client includes this file. Let's move all the NFS v3
declarations into a v3-only header file.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
The goal is to create a generic NFS module with code that does not
depend on what versions of NFS are enabled.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
This code has been around for a while, but never was enabled, although
it is in a working shape.
Note that we implement NOTIFY_DEVICEID4_CHANGE identical to
NOTIFY_DEVICEID4_DELETE. Given that in either case we can't do anything
but preventing further lookups of a given device ID there isn't much difference
in semantics for the two. For the delete case the server MUST ensure that
there are no outstanding layouts, while for the change case it doesn't, but
that has little relevance to the client.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
This patches moves parsing of the GETDEVICEINFO XDR to kernel space, as well
as the management of complex devices. The reason for that is we might have
multiple outstanding complex devices after a NOTIFY_DEVICEID4_CHANGE, which
device mapper or md can't handle as they claim devices exclusively.
But as is turns out simple striping / concatenation is fairly trivial to
implement anyway, so we make our life simpler by reducing the reliance
on blkmapd. For now we still use blkmapd by feeding it synthetic SIMPLE
device XDR to translate device signatures to device numbers, but in the
long runs I have plans to eliminate it entirely.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Create a file to house all the rpc_pipefs boilerplate code instead of
sprinkling it over a few files.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Factor out a helper for all per-extent work, and merge the now trivial
functions for lseg allocation and parsing.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
