The pointer to an AFU in the adapter's list of AFUs can be null
if we're in the process of removing AFUs. The afu_list_lock
doesn't guard against this.
Say we have 2 slices, and we're in the process of removing cxl.
- We remove the AFUs in order (see cxl_remove). In cxl_remove_afu
for AFU 0, we take the lock, set adapter->afu[0] = NULL, and
release the lock.
- Then we get an slbia. In cxl_slbia we take the lock, and set
afu = adapter->afu[0], which is NULL.
- Therefore our attempt to check afu->enabled will blow up.
Therefore, check if afu is a null pointer before dereferencing it.
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Axtens <dja@axtens.net>
Acked-by: Michael Neuling <mikey@neuling.org>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Zoltan Boszormenyi reported this regression:
"There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID
1565:230e) network chip on the mainboard. After the r8169 driver loaded
the IRQs in the machine went berserk. Keyboard keypressed arrived with
considerable latency and duplicated, so no real work was possible.
The machine responded to the power button but didn't actually power
down. It just stuck at the powering down message. I had to press the
power button for 4 seconds to power it down.
The computer is a POS machine with a big battery inside. Because of this,
either ACPI or the Realtek chip kept the bad state and after rebooting,
the network chip didn't even show up in lspci. Not even the PXE ROM
announced itself during boot. I had to disconnect the battery to beat
some sense back to the computer.
The regression happens with 4.0.5, 4.1.0-rc8 and 4.1.0-final. 3.18.16 was
good."
The regression is caused by commit 593669c2ac (x86/PCI/ACPI: Use common
ACPI resource interfaces to simplify implementation). Since commit
593669c2ac, x86 PCI ACPI host bridge driver validates ACPI resources by
first converting an ACPI resource to a 'struct resource' structure and
then applying checks against the converted resource structure. The 'start'
and 'end' fields in 'struct resource' are defined to be type of
resource_size_t, which may be 32 bits or 64 bits depending on
CONFIG_PHYS_ADDR_T_64BIT.
This may cause incorrect resource validation results with 32-bit kernels
because 64-bit ACPI resource descriptors may get truncated when converting
to 32-bit 'start' and 'end' fields in 'struct resource'. It eventually
affects PCI resource allocation subsystem and makes some PCI devices and
the system behave abnormally due to incorrect resource assignment.
So enhance the ACPI resource parsing interfaces to ignore ACPI resource
descriptors with address/offset above 4G when running in 32-bit mode.
With the fix applied, the behavior of the machine was restored to how
3.18.16 worked, i.e. the memory range that is over 4GB is ignored again,
and lspci -vvxxx shows that everything is at the same memory window as
they were with 3.18.16.
Reported-and-tested-by: Boszormenyi Zoltan <zboszor@pr.hu>
Fixes: 593669c2ac (x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation)
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: 4.0+ <stable@vger.kernel.org> # 4.0+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Users of freq table may want to access it for any CPU from
policy->related_cpus mask. One such user is cpu-cooling layer. It gets a
list of 'clip_cpus' (equivalent to policy->related_cpus) during
registration and tries to get freq_table for the first CPU of this mask.
If the CPU, for which it tries to fetch freq_table, is offline,
cpufreq_frequency_get_table() fails. This happens because it relies on
cpufreq_cpu_get_raw() for its functioning which returns policy only for
online CPUs.
The fix is to access the policy data structure for the given CPU
directly (which also returns a valid policy for offline CPUs), but the
policy itself has to be active (meaning that at least one CPU using it
is online) for the frequency table to be returned.
Because we will be using 'cpufreq_cpu_data' now, which is internal to
the cpufreq core, move cpufreq_frequency_get_table() to cpufreq.c.
Reported-and-tested-by: Pi-Cheng Chen <pi-cheng.chen@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When all CPUs of a policy are hot-unplugged, we EXIT the governor but
don't mark policy->governor as NULL. This was done in order to keep last
used governor's information intact in sysfs, while the CPUs are offline.
But we also need to clear policy->governor when restoring the policy.
Because policy->governor still points to the last governor while policy
is restored, following sequence of event happens:
- cpufreq_init_policy() called while restoring policy
- find_governor() matches last_governor string for present governors and
returns last used governor's pointer, say ondemand. policy->governor
already has the same address, unless the governor was removed in
between.
- cpufreq_set_policy() is called with both old/new policies governor set
as ondemand.
- Because governors matched, we skip governor initialization and return
after calling __cpufreq_governor(CPUFREQ_GOV_LIMITS). Because the
governor wasn't initialized for this policy, it returned -EBUSY.
- cpufreq_init_policy() exits the policy on this error, but doesn't
destroy it properly (should be fixed separately).
- And so we enter a scenario where the policy isn't completely
initialized but used.
Fix this by setting policy->governor to NULL while restoring the policy.
Reported-and-tested-by: Pi-Cheng Chen <pi-cheng.chen@linaro.org>
Reported-and-tested-by: "Jon Medhurst (Tixy)" <tixy@linaro.org>
Reported-and-tested-by: Steven Rostedt <rostedt@goodmis.org>
Fixes: 18bf3a124e (cpufreq: Mark policy->governor = NULL for inactive policies)
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
except for a GPMC fix to not use names for probing devices. Also a
one liner clean-up to remove unecessary return from a void function.
The summary for the changes being:
- Fix probe for GPMC devices by reoving limitations based on device
name
- Remove unnecessary return from a void function
- Revert beaglebone RTC sleep fix, we now have a better fix merged
- Add am4372 EMIF node to fix a warning
- Add am57xx-beagle-x15 power supply to fix USB2 if USB1 is disabled
- Disable rfbi for am4372 as it does not have a driver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVnjdMAAoJEBvUPslcq6VzDKoP/jgmjk4PwILrpu7P94RFpT2L
Jp6mu8zg+LIJ+c/TtsDX/uVxw2VKfiXEjt4onLIPA4PyYJw+oj87dXIKooP8olCH
6qoBqGzs7EtM/u+HAMifgCI0hshRoH4SinPb6Pq96cNSpvBrnckJaV5ZZ/yBgJAG
uNUGZZKGs4RkKt6mybIaZgsDlrTMV0pQ+iSIYR9kHumnwq4PUMfFsECDfoI87W6I
2ug962Co4e9+BNGhqpzqq8Xa5SJJrVatMrVKeAC5Eg54F+FihbnjncMBdqW4cZfv
FYZDd//hIqDTE9t/2xy70+yHgtW7qgxmUCfNH62rdsMvVWsTzjcpaLw2G/bTALkz
n0X3dCSNdMInjaFBxun93C63kNJUBLEWzKZ1TiR9uQEcS2O9wiH2NzZ8dfDEse2L
qP+/G95M4mAQeePOZpTCcu3x6v3SA6AIgWepB8bat1kglL7OPaa08nO33RAIWfv+
1iyZ6XY+N8bNYy7fCt6X4byws8woApKU4Fp28rTDwbm/jRD0GWz/AHSXz1Xoimz1
R47IT3eyMrB4c6yDvIqm0ghKt+QXspblcElCVGuvV0iKfbKUrtwV00z3/dKCxMtc
gfJHQOkZobfro4fCpMvg4jeTOpqAX9g9UdqotrsEtV0xZfbwrfbSRpuSVbLHz3Io
dNG3MP164dB4SuxUWo7T
=uoa8
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.2/fixes-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Merge "omap fixes against v4.2-rc1" from Tony Lindgren:
Minor fixes for omaps against v4.2-rc1. Mostly just minor dts changes
except for a GPMC fix to not use names for probing devices. Also a
one liner clean-up to remove unecessary return from a void function.
The summary for the changes being:
- Fix probe for GPMC devices by reoving limitations based on device
name
- Remove unnecessary return from a void function
- Revert beaglebone RTC sleep fix, we now have a better fix merged
- Add am4372 EMIF node to fix a warning
- Add am57xx-beagle-x15 power supply to fix USB2 if USB1 is disabled
- Disable rfbi for am4372 as it does not have a driver
* tag 'omap-for-v4.2/fixes-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: am4372.dtsi: disable rfbi
ARM: dts: am57xx-beagle-x15: Provide supply for usb2_phy2
ARM: dts: am4372: Add emif node
Revert "ARM: dts: am335x-boneblack: disable RTC-only sleep"
ARM: OMAP2+: Remove unnessary return statement from the void function, omap2_show_dma_caps
memory: omap-gpmc: Fix parsing of devices
Eric Dumazet says:
====================
inet: timewait cleanups
Another round of patches to make tw handling simpler.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
inet_twsk_deschedule() calls are followed by inet_twsk_put().
Only particular case is in inet_twsk_purge() but there is no point
to defer the inet_twsk_put() after re-enabling BH.
Lets rename inet_twsk_deschedule() to inet_twsk_deschedule_put()
and move the inet_twsk_put() inside.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
timewait sockets have a complex refcounting logic.
Once we realize it should be similar to established and
syn_recv sockets, we can use sk_nulls_del_node_init_rcu()
and remove inet_twsk_unhash()
In particular, deferred inet_twsk_put() added in commit
13475a30b6 ("tcp: connect() race with timewait reuse")
looks unecessary : When removing a timewait socket from
ehash or bhash, caller must own a reference on the socket
anyway.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Kernel will crash the same if one of the pointer is NULL anyway.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A bunch of defconfig changes, and some patches to make the Allwinner H3 and
A33 boot properly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVmUC5AAoJEBx+YmzsjxAgc24P/Ah6q+SSSv68adzGQp6LGO8t
ru2OWZwlQn+w2gHJK9qAytmQdpSRqbbjB+8muLz9WwNNjHliDmJawUvBPdC2p03L
ZrugiVUSKBeQOzdqvG0B3vOO3xszDE06DA+i0PZaBWH2uXDVfohhCFQ2n2/oQsS7
eDSlBl1EHtZOKEHtuEi988YDJhYDnJeSG/SWwyUbW73QH5eYYl+9TnSXdwDKGmJS
JyfWkafIsI3EKWUYmOJ2NgUv13pYQU9k/we53n+PxeGevsPuenJH8r2j/N8pWtUl
srfZP82aEYCqlY4M6QL21k2KOPW8MIDMOOk9dh8l8k9nSC2oJXqsROJQpw2nrJRo
oPoT+gxWacc+AutX3Hz+XjXNsCIsE3q0Yd7yBfiszXroPtkIBslJGhdJRbh3VrxO
JS7lKVubJepePpARiWT4ginenWPgGPirDHWixSUcfgBnMN6fpdhOGpdDxWePy1IJ
7wox3lRThnBhhvI1HuLES92XEiRYhin21LA00juPbvCMbQKuG2W9fBryXTi3U3LC
g3RQfy3ViZbrEw/7iTjlm2MVYSRxSdA1SAQHNS5Q+4fem22XKeSlzHON/0izrCdV
10zWNUAlolESWhCyD3TMScFl7WG+KMrjaHE/02+q7wSA6sr1aMGfjL6buVA7R5bF
KiCWz4Sqp8p/a4RejDVl
=m0CY
-----END PGP SIGNATURE-----
Merge tag 'sunxi-late-for-4.2' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into fixes
Merge "Allwinner late changes for 4.2" from Maxime Ripard:
Allwinner late changes for 4.2
A bunch of defconfig changes, and some patches to make the Allwinner H3 and
A33 boot properly.
* tag 'sunxi-late-for-4.2' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
ARM: sunxi: Enable simplefb in the defconfig
ARM: Remove deprecated symbol from defconfig files
ARM: sunxi: Add Machine support for A33
ARM: sunxi: Introduce Allwinner H3 support
Documentation: sunxi: Update Allwinner SoC documentation
Oleg Nesterov says:
====================
net: pktgen: fix race between pktgen_thread_worker() and kthread_stop()
I am not familiar with this code and I have no idea how to test
these changes, so 2/2 comes as a separate change. 1/2 looks like
the obvious bugfix, and probably candidate for -stable.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
pktgen_thread_worker() doesn't need to wait for kthread_stop(), it
can simply exit. Just pktgen_create_thread() and pg_net_exit() should
do get_task_struct()/put_task_struct(). kthread_stop(dead_thread) is
fine.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
pktgen_thread_worker() is obviously racy, kthread_stop() can come
between the kthread_should_stop() check and set_current_state().
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Jan Stancek <jstancek@redhat.com>
Reported-by: Marcelo Leitner <mleitner@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
NCM specs are not actually mandating a specific position in the frame for
the NDP (Network Datagram Pointer). However, some Huawei devices will
ignore our aggregates if it is not placed after the datagrams it points
to. Add support for doing just this, in a per-device configurable way.
While at it, update NCM subdrivers, disabling this functionality in all of
them, except in huawei_cdc_ncm where it is enabled instead.
We aren't making any distinction between different Huawei NCM devices,
based on what the vendor driver does. Standard NCM devices are left
unaffected: if they are compliant, they should be always usable, still
stay on the safe side.
This change has been tested and working with a Huawei E3131 device (which
works regardless of NDP position), a Huawei E3531 (also working both
ways) and an E3372 (which mandates NDP to be after indexed datagrams).
V1->V2:
- corrected wrong NDP acronym definition
- fixed possible NULL pointer dereference
- patch cleanup
V2->V3:
- Properly account for the NDP size when writing new packets to SKB
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In commit 'c03abd8463 ("net: ethernet: cpsw: don't requests
IRQs we don't use")', common isr is split into tx and rx, but
in rx isr tx interrupt is also disabledi in cpsw_disable_irq().
So tx interrupts are not handled during rx interrupts and rx
napi completion and results in poor tx performance by 40Mbps.
Fixing by disabling only rx interrupt in rx isr.
Cc: Felipe Balbi <balbi@ti.com>
Cc: <stable@vger.kernel.org> # v4.0+
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use eth_hw_addr_random() instead of calling random_ether_addr().
Here, this change is setting addr_assign_type to NET_ADDR_RANDOM.
The Coccinelle semantic patch that performs this transformation
is as follows:
@@
identifier a,b;
@@
-random_ether_addr(a->b);
+eth_hw_addr_random(a);
Signed-off-by: Vaishali Thakkar <vthakkar1994@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
MV88E6320 and MV88E6321 are largely compatible to MV886352,
but are members of a different chip family.
Signed-off-by: Aleksey S. Kazantsev <ioctl@yandex.ru>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Yuchung Cheng says:
====================
tcp: fixes some congestion control corner cases
This patch series fixes corner cases of TCP congestion control.
First issue is to avoid continuing slow start when cwnd reaches ssthresh.
Second issue is incorrectly processing order of congestion state and
cwnd update when entering fast recovery or undoing cwnd.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The congestion state and cwnd can be updated in the wrong order.
For example, upon receiving a dubious ACK, we incorrectly raise
the cwnd first (tcp_may_raise_cwnd()/tcp_cong_avoid()) because
the state is still Open, then enter recovery state to reduce cwnd.
For another example, if the ACK indicates spurious timeout or
retransmits, we first revert the cwnd reduction and congestion
state back to Open state. But we don't raise the cwnd even though
the ACK does not indicate any congestion.
To fix this problem we should first call tcp_fastretrans_alert() to
process the dubious ACK and update the congestion state, then call
tcp_may_raise_cwnd() that raises cwnd based on the current state.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the original design slow start is only used to raise cwnd
when cwnd is stricly below ssthresh. It makes little sense
to slow start when cwnd == ssthresh: especially
when hystart has set ssthresh in the initial ramp, or after
recovery when cwnd resets to ssthresh. Not doing so will
also help reduce the buffer bloat slightly.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a helper to test the slow start condition in various congestion
control modules and other places. This is to prepare a slight improvement
in policy as to exactly when to slow start.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This change makes it so that the call skb_defer_rx_timestamp will first
check for a phydev before going in and manipulating the skb->data and
skb->len values. By doing this we can avoid unnecessary work on network
devices that don't support phydev. As a result we reduce the total
instruction count needed to process this on most devices.
Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
V1 of this patch contains Eric Dumazet's suggestion to move the per
dst RTAX_QUICKACK check into tcp_in_quickack_mode(). Thanks Eric.
I ran some tests and after setting the "ip route change quickack 1"
knob there were still many delayed ACKs sent. This occured
because when icsk_ack.quick=0 the !icsk_ack.pingpong value is
subsequently ignored as tcp_in_quickack_mode() checks both these
values. The condition for a quick ack to trigger requires
that both icsk_ack.quick != 0 and icsk_ack.pingpong=0. Currently
only icsk_ack.pingpong is controlled by the knob. But the
icsk_ack.quick value changes dynamically depending on heuristics.
The crux of the matter is that delayed acks still cannot be entirely
disabled even with the RTAX_QUICKACK per dst knob enabled. This
patch ensures that a quick ack is always sent when the RTAX_QUICKACK
per dst knob is turned on.
The "ip route change quickack 1" knob was recently added to enable
quickacks. It was modeled around the TCP_QUICKACK setsockopt() option.
This issue is that even with "ip route change quickack 1" enabled
we still see delayed ACKs under some conditions. It would be nice
to be able to completely disable delayed ACKs.
Here is an example:
# netstat -s|grep dela
3 delayed acks sent
For all routes enable the knob
# ip route change quickack 1
Generate some traffic across a slow link and we still see the delayed
acks.
# netstat -s|grep dela
106 delayed acks sent
1 delayed acks further delayed because of locked socket
The issue is that both the "ip route change quickack 1" knob and
the TCP_QUICKACK option set the icsk_ack.pingpong variable to 0.
However at the business end in the __tcp_ack_snd_check() routine,
tcp_in_quickack_mode() checks that both icsk_ack.quick != 0
and icsk_ack.pingpong=0 in order to trigger a quickack. As
icsk_ack.quick is determined by heuristics it can be 0. When
that occurs the icsk_ack.pingpong value is ignored and a delayed
ACK is sent regardless.
This patch moves the RTAX_QUICKACK per dst check into the
tcp_in_quickack_mode() routine which ensures that a quickack is
always sent when the quickack knob is enabled for that dst.
Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Put tick_freeze() under RCU_NONIDLE() to prevent RCU from complaining
about suspicious RCU usage in idle by trace_suspend_resume() called
from there.
While at it, fix a comment related to another usage of RCU_NONIDLE()
in enter_freeze_proper().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
e48453c386 ("block, cgroup: implement policy-specific per-blkcg
data") updated per-blkcg policy data to be dynamically allocated.
When a policy is registered, its policy data aren't created. Instead,
when the policy is activated on a queue, the policy data are allocated
if there are blkg's (blkcg_gq's) which are attached to a given blkcg.
This is buggy. Consider the following scenario.
1. A blkcg is created. No blkg's attached yet.
2. The policy is registered. No policy data is allocated.
3. The policy is activated on a queue. As the above blkcg doesn't
have any blkg's, it won't allocate the matching blkcg_policy_data.
4. An IO is issued from the blkcg and blkg is created and the blkcg
still doesn't have the matching policy data allocated.
With cfq-iosched, this leads to an oops.
It also doesn't free policy data on policy unregistration assuming
that freeing of all policy data on blkcg destruction should take care
of it; however, this also is incorrect.
1. A blkcg has policy data.
2. The policy gets unregistered but the policy data remains.
3. Another policy gets registered on the same slot.
4. Later, the new policy tries to allocate policy data on the previous
blkcg but the slot is already occupied and gets skipped. The
policy ends up operating on the policy data of the previous policy.
There's no reason to manage blkcg_policy_data lazily. The reason we
do lazy allocation of blkg's is that the number of all possible blkg's
is the product of cgroups and block devices which can reach a
surprising level. blkcg_policy_data is contrained by the number of
cgroups and shouldn't be a problem.
This patch makes blkcg_policy_data to be allocated for all existing
blkcg's on policy registration and freed on unregistration and removes
blkcg_policy_data handling from policy [de]activation paths. This
makes that blkcg_policy_data are created and removed with the policy
they belong to and fixes the above described problems.
Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: e48453c386 ("block, cgroup: implement policy-specific per-blkcg data")
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Arianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Add all_blkcgs list goes through blkcg->all_blkcgs_node and is
protected by blkcg_pol_mutex. This will be used to fix
blkcg_policy_data allocation bug.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Arianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
An entry in blkcg_policy[] is stable while there are non-bypassing
in-flight IOs on a request_queue which has the policy activated. This
is why most derefs of blkcg_policy[] don't need explicit locking;
however, blkcg_css_alloc() isn't invoked from IO path and thus doesn't
have this protection and may race policies being added and removed.
Fix it by adding explicit blkcg_pol_mutex protection around
blkcg_policy[] iteration in blkcg_css_alloc().
Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: e48453c386 ("block, cgroup: implement policy-specific per-blkcg data")
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Arianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
blkcg_pol_mutex primarily protects the blkcg_policy array. It also
protects cgroup file type [un]registration during policy addition /
removal. This puts blkcg_pol_mutex outside cgroup internal
synchronization and in turn makes it impossible to grab from blkcg's
cgroup methods as that leads to cyclic dependency.
Another problematic dependency arising from this is through cgroup
interface file deactivation. Removing a cftype requires removing all
files of the type which in turn involves draining all on-going
invocations of the file methods. This means that an interface file
implementation can't grab blkcg_pol_mutex as draining can lead to AA
deadlock.
blkcg_reset_stats() is already in this situation. It currently
trylocks blkcg_pol_mutex and then unwinds and retries the whole
operation on failure, which is cumbersome at best. It has a lengthy
comment explaining how cgroup internal synchronization is involved and
expected to be updated but as explained above this doesn't need cgroup
internal locking to deadlock. It's a self-contained AA deadlock.
The described circular dependencies can be easily broken by moving
cftype [un]registration out of blkcg_pol_mutex and protect them with
an outer mutex. This patch introduces blkcg_pol_register_mutex which
wraps entire policy [un]registration including cftype operations and
shrinks blkcg_pol_mutex critical section. This also makes the trylock
dancing in blkcg_reset_stats() unnecessary. Removed.
This patch is necessary for the following blkcg_policy_data allocation
bug fixes.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Arianna Avanzini <avanzini.arianna@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Merge hpfs updates from Mikulas Patocka.
Mainly fstrim support, with some minor other cleanups.
These were actually sent during the merge window, but I wanted to wait
for the FSTRIM compat handling cleanup before applying them. Mikulas
sent that earlier today.
* emailed patches from Mikulas Patocka <mikulas@twibright.com>:
hpfs: hpfs_error: Remove static buffer, use vsprintf extension %pV instead
hpfs: kstrdup() out of memory handling
hpfs: Remove unessary cast
hpfs: add fstrim support
There is a possibility of nothing being allocated to the new_opts in
case of memory pressure, therefore return ENOMEM for such case.
Signed-off-by: Sanidhya Kashyap <sanidhya.gatech@gmail.com>
Signed-off-by: Mikulas Patocka <mikulas@twibright.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch adds support for fstrim to the HPFS filesystem.
Signed-off-by: Mikulas Patocka <mikulas@twibright.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I am a high school student trying to become familiar with
Linux kernel development. The btrfs documentation in
Documentation/filesystems had a few typos and errors in
whitespace. This patch corrects both of these.
Signed-off-by: Daniel Grimshaw <grimshaw@linux.vnet.ibm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Mark (and unmark) device nodes with the POPULATE flag as appropriate.
This is required to avoid multi probing when using I2C and device
overlays containing a mux.
This patch is also more careful with the release of the adapter device
which caused a deadlock with muxes, and does not break the build
on !OF since the node flag accessors are not defined then.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Current code returns 0 if fails to read clock-frequency DT property,
fix it. Also add checking return value of clk_prepare_enable and
propagate return value of devm_request_irq.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Pull Ceph fixes from Sage Weil:
"There is a fix for CephFS and RBD when used within containers/namespaces,
and a fix for the address learning the client is supposed to do when
initially talking to the Ceph cluster.
There are also two patches updating MAINTAINERS. One breaks out the
common Ceph code shared by fs/ceph and drivers/block/rbd.c into a
separate entry with the appropriate maintainers listed. The second
adds a second reference to the github tree where the Ceph client
development takes place (before it is pushed to korg and then to you).
The goal here is to move closer to a situation where Ilya Dryomov or
one of the other maintainers can push things to you if I am
unavailable. Ilya has done most of the work preparing branches for
upstream recently; you should not be surprised to hear from him if I
am trapped in some internet-less wasteland or hit by a bus or
something. In the meantime, we'll work on getting him added to the
kernel web of trust"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
MAINTAINERS: add secondary tree for ceph modules
MAINTAINERS: update ceph entries
libceph: treat sockaddr_storage with uninitialized family as blank
libceph: enable ceph in a non-default network namespace
This fbdev restore mode was another corner case that was now
calling frontbuffer flip and flush and making we miss
screen updates with PSR enabled.
So let's also add the invalidate hack here while we don't have
a reliable dirty fbdev op.
v2: As pointed by Paulo: removed seg fault risk, used fb_helper
when possible and put brackets on if.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Testcase: igt/kms_fbcon_fbt/psr
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
fbdev_set_par is called when fbcon is taking over control.
In the past frontbuffer was being invalidated on
set_to_gtt_domain, but it moved to set_domain fixing that case,
but left this behind and broken in
commit 031b698a77
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jun 26 19:35:16 2015 +0200
drm/i915: Unconditionally do fb tracking invalidate in set_domain
Note that even before this commit it wasn't perfect since the
invalidate was omitted if the fbcon was already in the GTT domain,
which it usually was.
Since we are also invalidating in other fbdev cases this one
was masked here. At least until now that I found this corner
case: On boot with plymouth doing a splash screen
when returning to the console frontbuffer wans't being invalidated
causing missed screen updates with PSR enabled.
So this patch fixes this issue.
v2: Make invalidate directly and unconditionally and
fix commit message indicating the set_domain fix
as pointed out by Daniel.
v3: Remove unecessary if(obj) added by mistake
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Try to clarify commit message a bit and make it clear the
referenced commit made this worse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Idle frames the number of identical frames needed
before panel can enter PSR.
There are some panels that requires up to minimum of 4 idle
frames available on the market. For these cases usually
VBT should be used to configure the number of idle frames,
but unfortunately this isn't always true and VBT isn't being
set at all.
Let's trust VBT when it is set + 1 and use minimum of 4 + 1
when VBT isn't set. "+1" covers the "of-by-one" case.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By Spec we should only mask memup and hotplug detection
for hardware tracking cases. However we always masked
LPSP because with power well always enabled on audio
PSR was never being activated and residency was always
zeroed.
Apparently audio driver is tying power well management
and runtime PM for some reason. But with audio runtime
PM working or with audio completely out of picture
we should remove this mask, otherwise we have a high
risk of miss screen updates as faced by Matthew.
WARNING: With this patch if snd_intel_hda driver is
running and not releasing power well properly PSR will
constant Exit and Performance Counter will be 0.
But the best thing of this patch is that with one more
HW tracking working the risks of missed blank screen
are minimized at most.
This affects just core platforms where PSR exit are also
helped by HW tracking: Haswell, Broadwell and Skylake
for now.
v2: Fix commit message explanation. It has nothing to do
with runtime PM on i915 as previously advertised.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of accessing it directly, as it uses EXPORT_SYMBOL, that has
no meaning in tools/perf and because we removed the stubs for it, i.e.
we removed the tools/include/linux/export.h file.
This fixes the build for the detached tarball sources cases and removes
one more source of entanglement with the kernel sources.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-oyqx541o7apa2cskjhcxi6nx@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The python binding build process was still looking at the kernel
rbtree.c file, so, when doing a in-tree build it would work, but when
creating a tarball using tools/perf/MANIFEST as the contents list and
then trying to build the resulting detached sources, it failed.
Fix it by removing one level of indirection from rbtree.c in the
tools/perf/util/python-ext-sources file.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-8u83c2k5guyhxdlkaaqis8k4@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
As per datasheet,
Except LDO2, all other LDO's use bit [3:0] for VOUT select.
Current code uses wrong mask value of 0x1f, So this patch
fixes it to use 0xf.
Signed-off-by: Yi Zhang <yizhang@marvell.com>
[vaibhav.hiremath@linaro.org: Updated changelog with more detailed description]
Signed-off-by: Vaibhav Hiremath <vaibhav.hiremath@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
The FITRIM ioctl has the same arguments on 32-bit and 64-bit
architectures, so we can add it to the list of compatible ioctls and
drop it from compat_ioctl method of various filesystems.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Ted Ts'o <tytso@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
