This fixes the following warning when default memory region crosses
0x80000000:
arch/xtensa/include/asm/processor.h:40:47: warning:
integer overflow in expression [-Woverflow]
#define TASK_SIZE (PLATFORM_DEFAULT_MEM_START + PLATFORM_DEFAULT_MEM_SIZE)
^
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
- make cache-related assembly macros empty if core doesn't have
corresponding cache type;
- don't initialize cache attributes in instruction/data TLB entries if
there's no corresponding cache type.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Build-time fixes:
- make lbeg/lend/lcount save/restore conditional on kernel entry;
- don't clear lcount in platform_restart functions unconditionally.
Run-time fixes:
- use correct end of range register in __endla paired with __loopt, not
the unused temporary register. This fixes .bss zero-initialization.
Update comments in asmmacro.h;
- don't clobber a10 in the usercopy that leads to access to unmapped
memory.
Cc: <stable@vger.kernel.org>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Now that we strictly forbid absolute relocations in libstub code,
make sure that we don't emit any when CONFIG_MODVERSIONS is enabled,
by stripping the kcrctab sections from the object file. This fixes
a build problem under CONFIG_MODVERSIONS=y.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The hash_accept call fails to work on sockets that have not received
any data. For some algorithm implementations it may cause crashes.
This patch fixes this by ensuring that we only export and import on
sockets that have received data.
Cc: stable@vger.kernel.org
Reported-by: Harsh Jain <harshjain.prof@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Stephan Mueller <smueller@chronox.de>
There is one important bug fix for a potential memory corruption
and/or guest errors for guests with 63 or 64 vCPUs. This fix would
qualify for 4.3 but is some days too late giving that we are
about to release 4.3.
Given that this patch is cc stable >= 3.15 anyway, we can handle
it via 4.4. merge window.
This pull reuqest also contains two cleanups.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iQIcBAABAgAGBQJWMjS5AAoJEBF7vIC1phx80FMP/Rbm+DOrPfAQJteIxTvm5TmM
LjZjdZ6xCuUH+css6mtziQmA3GX2n4wPgrh5oU7ZYewvvNf6KXfzSj8lh0Y40xvE
LELMrleip1A2E+lix3jcYrUnCtuGUVvbAlEbh3B51GeMuS55NdMbTJjDz+YCZS77
TVwvzXiTiV81SEE0g5F6ydAIHoa+qTwNtf9LOqP33DNonjqOZVIbxJpU7c1gvm/N
2GXMqds7SU/iI59cQCKdeoPcUfuq/tyQOaSQShfbwZ34yw10IBd+24roJp77jYo7
txBrlJEP1P7OjALrzT4PHieZ3rSUgxFPhdUvdgbgNI5YSIcSOWbKKFGXkQ0QJYJ2
dZh58qY12LFLkC5PJbJzEv9cz/wI+O27DT2dFluhvTNSgI09yeQ7yuMqYhwqBsSS
NPQdUQ+D/TF1oZh1UVEEIk4UVURB9wRhqrPMeeNTNcawEEqxYGtpBw19AdeacMCk
diSdPVgN3qQCoR7jR3LR0S28M1i24PyayQWeKwLWitm7wGp663bfjkpnJCOn9jXD
/LBPYJDQDCdzBd1ynoAj+BK7Uau++LiJUeozKf/ohek3c+N+N/bcFVY9liGnFFub
DVHIfGEztf3t6TXpqnJ4uxGjafonx/WsfPqGRdOnB6OZ1WVB7MZIAUJBAmLtFHvv
N0FkHKfrRSRTtsUb6g5e
=w01Y
-----END PGP SIGNATURE-----
Merge tag 'kvm-s390-next-20151028' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD
KVM: s390: Bugfix and cleanups
There is one important bug fix for a potential memory corruption
and/or guest errors for guests with 63 or 64 vCPUs. This fix would
qualify for 4.3 but is some days too late giving that we are
about to release 4.3.
Given that this patch is cc stable >= 3.15 anyway, we can handle
it via 4.4. merge window.
This pull request also contains two cleanups.
Now that we use memremap instead of ioremap, Use WRITE_ONCE / READ_ONCE
instead of iowrite / ioread.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Do this until we know how much MOB memory to allocate for these surfaces.
v2: Mask also non-DX multisample.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Per commit 2e586a7e01 "drm/vmwgfx: Map the fifo as cached" the driver
expects the fifo registers to be cacheable. In preparation for
deprecating ioremap_cache() convert its usage in vmwgfx to memremap().
Cc: David Airlie <airlied@linux.ie>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
I'm getting unclaimed register writes when checking the WM registers
after the crtc is disabled. So I would imagine those are guarded by
the crtc power well. Fix this by not reading out wm state when the
power well is off.
Cc: stable@vger.kernel.org # v4.3
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92181
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
ESS Allegro (marked ES1989S), [125d:1988] (rev 10) is mute after
loading snd-maestro3 and running alsactl restore. Touching master
volume or mute makes it work.
Looks like a bug in the AC'97 codec integrated into the chip.
Write AC97_MASTER register twice to work-around the problem.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Freescale updates from Scott:
"Highlights include 64-bit book3e kexec/kdump support, a rework of the
qoriq clock driver, device tree changes including qoriq fman nodes,
support for a new 85xx board, and some fixes.
Note that there is a trivial merge conflict with the clock tree's next
branch, in the clock Makefile."
Since xfsaild has been converted to kthread in 0030807c, it calls
try_to_freeze() during every AIL push iteration. It however doesn't set
itself as freezable, and therefore this try_to_freeze() will never do
anything.
Before (hopefully eventually) kthread freezing gets converted to fileystem
freezing, we'd rather mark xfsaild freezable (as it can generate I/O
during suspend).
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This patch tries to creates a common structure initialization
within the cpupower tool.
Previously the ``struct option`` was initialized
using `designated initializer` technique which was
not needed. There were conflicting initialization methods seen with
bench/main.c & others.
Signed-off-by: Sriram Raghunathan <sriram@marirs.net.in>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
cpupower idle-set -D <latency>
currently only disables all C-states that have a higher latency than the
specified <latency>. But if deep sleep states were already disabled and
have a lower latency, they should get enabled again.
For example:
This call:
cpupower idle-set -D 30
disables all C-states with a higher or equal latency than 30.
If one then calls:
cpupower idle-set -D 100
C-states with a latency between 30-99 will get enabled again with this patch
now. It is ensured that only C-states with a latency of 100 and higher are
disabled.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[root@hp-dl980g7-02 linux]# cpupower monitor
...
5472| 0| 1|******|******|******|******|| 0.00| 0.00| 0.00| 0.00| 0.00 *is offline
10567| 0| 159|******|******|******|******|| 0.00| 0.00| 0.00| 0.00| 0.00 *is offline
1661206560|859272560| 150|******|******|******|******|| 0.00| 0.00| 0.00| 0.00| 0.00 *is offline
1661206560|943093104| 140|******|******|******|******|| 0.00| 0.00| 0.00| 0.00| 0.00 *is offline
because of this cpupower also holds the incorrect value for the number
of physical packages in the machine
Changed cpupower to initialize the values of an offline cpu's socket and
core to -1, warn the user that one or more cpus is/are
offline and not print statistics for offline cpus.
This fix hides offlined cores where topology cannot be accessed.
With a recent kernel patch suggested from Prarit Bhargava it may be possible
that soft offlined cores' topology can still be parsed.
This patch would then show which cores in which package/socket are offline,
when sane toplogoy information is available.
Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In preparation for supporting IRQ-safe domains, allocate domain data
outside the domain locks. These functions are not called in an atomic
context, so we can always allocate memory using GFP_KERNEL. By
allocating memory before the locks, we can safely lock the domain using
spinlocks instead of mutexes.
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Remove check for driver of a device, for runtime PM. Device may be
suspended without an explicit driver. This check seems to be vestigial
and incorrect in the current context.
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It turns out that at least some versions of glibc end up reading
/proc/meminfo at every single startup, because glibc wants to know the
amount of memory the machine has. And while that's arguably insane,
it's just how things are.
And it turns out that it's not all that expensive most of the time, but
the vmalloc information statistics (amount of virtual memory used in the
vmalloc space, and the biggest remaining chunk) can be rather expensive
to compute.
The 'get_vmalloc_info()' function actually showed up on my profiles as
4% of the CPU usage of "make test" in the git source repository, because
the git tests are lots of very short-lived shell-scripts etc.
It turns out that apparently this same silly vmalloc info gathering
shows up on the facebook servers too, according to Dave Jones. So it's
not just "make test" for git.
We had two patches to just cache the information (one by me, one by
Ingo) to mitigate this issue, but the whole vmalloc information of of
rather dubious value to begin with, and people who *actually* want to
know what the situation is wrt the vmalloc area should just look at the
much more complete /proc/vmallocinfo instead.
In fact, according to my testing - and perhaps more importantly,
according to that big search engine in the sky: Google - there is
nothing out there that actually cares about those two expensive fields:
VmallocUsed and VmallocChunk.
So let's try to just remove them entirely. Actually, this just removes
the computation and reports the numbers as zero for now, just to try to
be minimally intrusive.
If this breaks anything, we'll obviously have to re-introduce the code
to compute this all and add the caching patches on top. But if given
the option, I'd really prefer to just remove this bad idea entirely
rather than add even more code to work around our historical mistake
that likely nobody really cares about.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
gov_queue_work() acquires cpufreq_governor_lock to allow
cpufreq_governor_stop() to drain delayed work items possibly scheduled
on CPUs that share the policy with a CPU being taken offline.
However, the same goal may be achieved in a more straightforward way if
the policy pointer in the struct cpu_dbs_info matching the policy CPU is
reset upfront by cpufreq_governor_stop() under the timer_mutex belonging
to it and checked against NULL, under the same lock, at the beginning of
dbs_timer().
In that case every instance of dbs_timer() run for a struct cpu_dbs_info
sharing the policy pointer in question after cpufreq_governor_stop() has
started will notice that that pointer is NULL and bail out immediately
without queuing up any new work items. In turn, gov_cancel_work()
called by cpufreq_governor_stop() before destroying timer_mutex will
wait for all of the delayed work items currently running on the CPUs
sharing the policy to drop the mutex, so it may be destroyed safely.
Make cpufreq_governor_stop() and dbs_timer() work as described and
modify gov_queue_work() so it does not acquire cpufreq_governor_lock any
more.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When booting an HWP enabled system the kernel displays one "HWP enabled"
message for each cpu. The messages are superfluous since HWP is globally
enabled across all CPUs. This patch also adds an informational message
when HWP is disabled via intel_pstate=no_hwp.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The check for correct frequency being set in bL_cpufreq_set_rate is
broken when the big.LITTLE switcher is active, for two reasons.
1. The 'new_rate' variable gets overwritten before the test by the
code calculating the frequency of the old cluster.
2. The frequency returned by bL_cpufreq_get_rate will be the virtual
frequency, not the actual one the intended version of new_rate contains.
This means the function always returns an error causing an endless
stream of: "cpufreq: __target_index: Failed to change cpu frequency: -5"
As the intent is to check for errors that clk_set_rate doesn't report
lets move the check to immediately after that and directly use
clk_get_rate, rather than the arm_big_little helpers which only confuse
matters. Also, update the comment to be hopefully clearer about the
purpose of the code.
Fixes: 0a95e630b4 (cpufreq: arm_big_little: check if the frequency is set correctly)
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Michael Turquette <mturquette@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Move all DT parsing for the power supplies to a single function, rather
than keeping them at separate places. This will help manage things
properly.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Clearly distinguish routines based on what version of bindings they
parse. We have already postfixed routines properly with _v2 for new
bindings. Postfix the older ones now with _v1.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
To identify OPP core's print messages easily, prefix them with
KBUILD_MODNAME.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge file descriptor allocation speedup.
Eric Dumazet has a test-case for a fairly common network deamon load
pattern: openign and closing a lot of sockets that each have very little
work done on them. It turns out that in that case, the cost of just
finding the correct file descriptor number can be a dominating factor.
We've long had a trivial optimization for allocating file descriptors
sequentially, but that optimization ends up being not very effective
when other file descriptors are being closed concurrently, and the fd
patterns are not some simple FIFO pattern. In such cases we ended up
spending a lot of time just scanning the bitmap of open file descriptors
in order to find the next file descriptor number to open.
This trivial patch-series mitigates that by simply introducing a
second-level bitmap of which words in the first bitmap are already fully
allocated. That cuts down the cost of scanning by an order of magnitude
in some pathological (but realistic) cases.
The second patch is an even more trivial patch to avoid unnecessarily
dirtying the cacheline for the close-on-exec bit array that normally
ends up being all empty.
* fs-file-descriptor-optimization:
vfs: conditionally clear close-on-exec flag
vfs: Fix pathological performance case for __alloc_fd()
The firmware of ESPRIMO Mobile M9410 has two video output devices that
have _BCM control method, one is the type of "External Digital Monitor"
while the other is the type of "Internal/Integrated Digital Flat Panel".
Only the 2nd video output device's _BCM control method works, but
since we have created two and the 1st one got picked up by user space,
the backlight functionality is broken. To solve this problem, only
register backlight interface for "Internal/Integrated Digital Flat Panel"
type video output device on this laptop.
Another problem of this laptop is that the IDs listed by the _DOD method
doesn't have bit 31 set, which means it doesn't follow the format
specified by ACPI spec. But the value indicates that it actually follows
that format so I've added a DMI quirk and a module level parameter to
force use the device_id_scheme so that we can get the video output
device's type to do the decision if we should register backlight
interface.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=104121
Suggested-by: Hans de Goede <hdegoede@redhat.com>
Reported-and-tested-by: Christian Scharl <zahlsum-kernelbugs@yahoo.de>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Just like the Dell XPS 15 (L521X) the Dell XPS 14 (L421X) needs to use
the acpi-video backlight interface rather then the native one for backlight
control to work, add a quirk for this.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1272633
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* pm-opp:
PM / OPP: passing NULL to PTR_ERR()
PM / OPP: Move cpu specific code to opp/cpu.c
PM / OPP: Move opp core to its own directory
PM / OPP: Prefix exported opp routines with dev_pm_opp_
PM / OPP: Rename opp init/free table routines
PM / OPP: reuse of_parse_phandle()
* pm-cpufreq:
cpufreq: postfix policy directory with the first CPU in related_cpus
cpufreq: create cpu/cpufreq/policyX directories
cpufreq: remove cpufreq_sysfs_{create|remove}_file()
cpufreq: create cpu/cpufreq at boot time
cpufreq: Use cpumask_copy instead of cpumask_or to copy a mask
cpufreq: ondemand: Drop unnecessary locks from update_sampling_rate()
cpufreq: intel_pstate: Fix intel_pstate powersave min_perf_pct value
cpufreq: intel_pstate: Avoid calculation for max/min
Documentation: kernel_parameters for Intel P state driver
cpufreq: intel_pstate: Use ACPI perf configuration
cpufreq: intel-pstate: Use separate max pstate for scaling
cpufreq: intel_pstate: get P1 from TAR when available
cpufreq: Drop redundant check for inactive policies
cpufreq : powernv: Report Pmax throttling if capped below nominal frequency
cpufreq: imx: update the clock switch flow to support imx6ul
cpufreq: tegra20: remove superfluous CONFIG_PM ifdefs
cpufreq: conservative: remove 'enable' field
cpufreq: integrator: Fix module autoload for OF platform driver
* pm-cpuidle:
cpuidle: mvebu: disable the bind/unbind attributes and use builtin_platform_driver
cpuidle: mvebu: clean up multiple platform drivers
* pm-sleep:
PM / hibernate: fix a comment typo
input: i8042: Avoid resetting controller on system suspend/resume
PM / PCI / ACPI: Kick devices that might have been reset by firmware
PM / sleep: Add flags to indicate platform firmware involvement
PM / sleep: Drop pm_request_idle() from pm_generic_complete()
PCI / PM: Avoid resuming more devices during system suspend
PM / wakeup: wakeup_source_create: use kstrdup_const
PM / sleep: Report interrupt that caused system wakeup
* acpi-processor:
ACPI / CPPC: Fix potential memory leak
ACPI / CPPC: signedness bug in register_pcc_channel()
ACPI: Allow selection of the ACPI processor driver for ARM64
CPPC: Probe for CPPC tables for each ACPI Processor object
ACPI: Add weak routines for ACPI CPU Hotplug
ACPI / CPPC: Add a CPUFreq driver for use with CPPC
ACPI: Introduce CPU performance controls using CPPC
* acpica:
ACPICA: Update version to 20150930
ACPICA: Debugger: Fix dead lock issue ocurred in single stepping mode
ACPI: Enable build of AML interpreter debugger
ACPICA: Debugger: Add thread ID support so that single step mode can only apply to the debugger thread
ACPICA: Debugger: Fix "terminate" command by cleaning up subsystem shutdown logic
ACPICA: Debugger: Fix "quit/exit" command by cleaning up user commands termination logic
ACPICA: Linuxize: Export debugger files to Linux
ACPICA: iASL: General cleanup of the file suffix #defines
ACPICA: Improve typechecking, both compile-time and runtime
ACPICA: Update NFIT table to rename a flags field
ACPICA: Debugger: Update mutexes used for multithreaded debugger
ACPICA: Update exception code for "file not found" error
ACPICA: iASL: Add symbolic operator support for Index() operator
ACPICA: Remove unnecessary conditional compilation
Pull memremap fix from Dan Williams:
"The new memremap() api introduced in the 4.3 cycle to unify/replace
ioremap_cache() and ioremap_wt() is mishandling the highmem case.
This patch has received a build success notification from a
0day-kbuild-robot run and has received an ack from Ard"
From the commit message:
"The impact of this bug is low for now since the pmem driver is the
only user of memremap(), but this is important to fix before more
conversions to memremap arrive in 4.4"
* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
memremap: fix highmem support
priv->hwts_*_en indicate if timestamping is enabled/disabled at run
time. But priv->dma_cap.time_stamp and priv->dma_cap.atime_stamp
indicates HW is support for PTPv1/PTPv2.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch changes the use of struct timespec in
dccp_probe to use struct timespec64 instead. timespec uses a 32-bit
seconds field which will overflow in the year 2038 and beyond. timespec64
uses a 64-bit seconds field. Note that the correctness of the code isn't
changed, since the original code only uses the timestamps to compute a
small elapsed interval. This patch is part of a larger attempt to remove
instances of 32-bit timekeeping structures (timespec, timeval, time_t)
from the kernel so it is easier to identify where the real 2038 issues
are.
Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Julian Anastasov says:
====================
ipv4: fix problems from the RTNH_F_LINKDOWN introduction
Fix two problems from the change that introduced RTNH_F_LINKDOWN
flag. The first patch deals with the removal of local route on
DOWN event. The second patch makes sure the RTNH_F_LINKDOWN
flag is properly updated on UP event because the DOWN event
sets it in all cases.
v2->v3:
- use bool for force var
v1->v2:
- forgot to add ifconfig dummy0 down in the test case
- split to 2 patches
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When nexthop is part of multipath route we should clear the
LINKDOWN flag when link goes UP or when first address is added.
This is needed because we always set LINKDOWN flag when DEAD flag
was set but now on UP the nexthop is not dead anymore. Examples when
LINKDOWN bit can be forgotten when no NETDEV_CHANGE is delivered:
- link goes down (LINKDOWN is set), then link goes UP and device
shows carrier OK but LINKDOWN remains set
- last address is deleted (LINKDOWN is set), then address is
added and device shows carrier OK but LINKDOWN remains set
Steps to reproduce:
modprobe dummy
ifconfig dummy0 192.168.168.1 up
here add a multipath route where one nexthop is for dummy0:
ip route add 1.2.3.4 nexthop dummy0 nexthop SOME_OTHER_DEVICE
ifconfig dummy0 down
ifconfig dummy0 up
now ip route shows nexthop that is not dead. Now set the sysctl var:
echo 1 > /proc/sys/net/ipv4/conf/dummy0/ignore_routes_with_linkdown
now ip route will show a dead nexthop because the forgotten
RTNH_F_LINKDOWN is propagated as RTNH_F_DEAD.
Fixes: 8a3d03166f ("net: track link-status of ipv4 nexthops")
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
When fib_netdev_event calls fib_disable_ip on NETDEV_DOWN event
we should not delete the local routes if the local address
is still present. The confusion comes from the fact that both
fib_netdev_event and fib_inetaddr_event use the NETDEV_DOWN
constant. Fix it by returning back the variable 'force'.
Steps to reproduce:
modprobe dummy
ifconfig dummy0 192.168.168.1 up
ifconfig dummy0 down
ip route list table local | grep dummy | grep host
local 192.168.168.1 dev dummy0 proto kernel scope host src 192.168.168.1
Fixes: 8a3d03166f ("net: track link-status of ipv4 nexthops")
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
