Paolo Bonzini [Tue, 1 Oct 2019 13:33:07 +0000 (15:33 +0200)]
KVM: x86: omit "impossible" pmu MSRs from MSR list
INTEL_PMC_MAX_GENERIC is currently 32, which exceeds the 18
contiguous MSR indices reserved by Intel for event selectors.
Since some machines actually have MSRs past the reserved range,
filtering them against x86_pmu.num_counters_gp may have false
positives. Cut the list to 18 entries to avoid this.
Paul Burton [Thu, 3 Oct 2019 22:46:36 +0000 (22:46 +0000)]
MIPS: pmcs-msp71xx: Remove unused addr variable
The addr variable in prom_free_prom_memory() has been unused since
commit b3c948e2c00f ("MIPS: msp: Record prom memory"), causing a warning
& build failure due to -Werror. Remove the unused variable.
Commit b3c948e2c00f ("MIPS: msp: Record prom memory") introduced use of
a MAX_PROM_MEM value but didn't define it. A bounds check in
prom_meminit() suggests its value was supposed to be 5, so define it as
such & adjust the bounds check to use the macro rather than a magic
number.
Eric Sandeen [Wed, 2 Oct 2019 21:17:54 +0000 (16:17 -0500)]
vfs: Fix EOVERFLOW testing in put_compat_statfs64
Today, put_compat_statfs64() disallows nearly any field value over
2^32 if f_bsize is only 32 bits, but that makes no sense.
compat_statfs64 is there for the explicit purpose of providing 64-bit
fields for f_files, f_ffree, etc. And f_bsize is always only 32 bits.
As a result, 32-bit userspace gets -EOVERFLOW for i.e. large file
counts even with -D_FILE_OFFSET_BITS=64 set.
In reality, only f_bsize and f_frsize can legitimately overflow
(fields like f_type and f_namelen should never be large), so test
only those fields.
This bug was discussed at length some time ago, and this is the proposal
Al suggested at https://lkml.org/lkml/2018/8/6/640. It seemed to get
dropped amid the discussion of other related changes, but this
part seems obviously correct on its own, so I've picked it up and
sent it, for expediency.
Fixes: 64d2ab32efe3 ("vfs: fix put_compat_statfs64() does not handle errors") Signed-off-by: Eric Sandeen <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Randy Dunlap [Thu, 3 Oct 2019 02:23:15 +0000 (19:23 -0700)]
block: sed-opal: fix sparse warning: convert __be64 data
sparse warns about incorrect type when using __be64 data.
It is not being converted to CPU-endian but it should be.
Fixes these sparse warnings:
../block/sed-opal.c:375:20: warning: incorrect type in assignment (different base types)
../block/sed-opal.c:375:20: expected unsigned long long [usertype] align
../block/sed-opal.c:375:20: got restricted __be64 const [usertype] alignment_granularity
../block/sed-opal.c:376:25: warning: incorrect type in assignment (different base types)
../block/sed-opal.c:376:25: expected unsigned long long [usertype] lowest_lba
../block/sed-opal.c:376:25: got restricted __be64 const [usertype] lowest_aligned_lba
Oleksij Rempel [Thu, 3 Oct 2019 08:21:12 +0000 (10:21 +0200)]
net: phy: at803x: add ar9331 support
Mostly this hardware can work with generic PHY driver, but this change
is needed to provided interrupt handling support.
Tested with dsa ar9331-switch driver.
Several userspace clients (modesetting ddx and mutter+wayland at least)
handle encoder.possible_crtcs incorrectly. What they essentially do is
the following:
Ie. they calculate the intersection of the possible_crtcs
for the connector when they really should be calculating the
union instead.
In our case each MST encoder now has just one unique bit set,
and so the intersection is always zero. The end result is that
MST connectors can't be lit up because no crtc can be found to
drive them.
I've submitted a fix for the modesetting ddx [1], and complained
on #wayland about mutter, so hopefully the situation will improve
in the future. In the meantime we have regression, and so must go
back to the old way of misconfiguring possible_crtcs in the kernel.
Petr Machata [Thu, 3 Oct 2019 05:44:49 +0000 (08:44 +0300)]
mlxsw: PCI: Send EMAD traffic on a separate queue
Currently mlxsw distributes sent traffic among all the available send
queues. That includes control traffic as well as EMADs, which are used for
configuration of the device.
However because all the queues have the same traffic class of 3, they all
end up being directed to the same traffic class buffer. If the control
traffic in the buffer cannot be serviced quickly enough, the EMAD traffic
might be shut out, which causes transient failures, typically in FDB
maintenance, counter upkeep and other periodic work.
To address this issue, dedicate SDQ 0 to EMAD traffic, with TC 0.
Distribute the control traffic among the remaining queues, which are left
with their current TC 3.
usercopy: Add parentheses around assignment in test_copy_struct_from_user
Clang warns:
lib/test_user_copy.c:96:10: warning: using the result of an assignment
as a condition without parentheses [-Wparentheses]
if (ret |= test(umem_src == NULL, "kmalloc failed"))
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/test_user_copy.c:96:10: note: place parentheses around the
assignment to silence this warning
if (ret |= test(umem_src == NULL, "kmalloc failed"))
^
( )
lib/test_user_copy.c:96:10: note: use '!=' to turn this compound
assignment into an inequality comparison
if (ret |= test(umem_src == NULL, "kmalloc failed"))
^~
!=
Add the parentheses as it suggests because this is intentional.
Ka-Cheong Poon [Thu, 3 Oct 2019 04:11:08 +0000 (21:11 -0700)]
net/rds: Use DMA memory pool allocation for rds_header
Currently, RDS calls ib_dma_alloc_coherent() to allocate a large piece
of contiguous DMA coherent memory to store struct rds_header for
sending/receiving packets. The memory allocated is then partitioned
into struct rds_header. This is not necessary and can be costly at
times when memory is fragmented. Instead, RDS should use the DMA
memory pool interface to handle this. The DMA addresses of the pre-
allocated headers are stored in an array. At send/receive ring
initialization and refill time, this arrary is de-referenced to get
the DMA addresses. This array is not accessed at send/receive packet
processing.
Eric Dumazet [Thu, 3 Oct 2019 03:19:59 +0000 (20:19 -0700)]
tcp: fix slab-out-of-bounds in tcp_zerocopy_receive()
Apparently a refactoring patch brought a bug, that was caught
by syzbot [1]
Original code was correct, do not try to be smarter than the
compiler :/
[1]
BUG: KASAN: slab-out-of-bounds in tcp_zerocopy_receive net/ipv4/tcp.c:1807 [inline]
BUG: KASAN: slab-out-of-bounds in do_tcp_getsockopt.isra.0+0x2c6c/0x3120 net/ipv4/tcp.c:3654
Read of size 4 at addr ffff8880943cf188 by task syz-executor.2/17508
David S. Miller [Thu, 3 Oct 2019 19:00:56 +0000 (12:00 -0700)]
Merge branch 'stmmac-eam'
Thierry Reding says:
====================
net: stmmac: Enhanced addressing mode for DWMAC 4.10
The DWMAC 4.10 supports the same enhanced addressing mode as later
generations. Parse this capability from the hardware feature registers
and set the EAME (Enhanced Addressing Mode Enable) bit when necessary.
====================
Thierry Reding [Wed, 2 Oct 2019 14:52:58 +0000 (16:52 +0200)]
net: stmmac: Support enhanced addressing mode for DWMAC 4.10
The address width of the controller can be read from hardware feature
registers much like on XGMAC. Add support for parsing the ADDR64 field
so that the DMA mask can be set accordingly.
This avoids getting swiotlb involved for DMA on Tegra186 and later.
Also make sure that the upper 32 bits of the DMA address are written to
the DMA descriptors when enhanced addressing mode is used. Similarily,
for each channel, the upper 32 bits of the DMA descriptor ring's base
address also need to be programmed to make sure the correct memory can
be fetched when the DMA descriptor ring is located beyond the 32-bit
boundary.
Thierry Reding [Wed, 2 Oct 2019 14:52:57 +0000 (16:52 +0200)]
net: stmmac: Only enable enhanced addressing mode when needed
Enhanced addressing mode is only required when more than 32 bits need to
be addressed. Add a DMA configuration parameter to enable this mode only
when needed.
Linus Torvalds [Thu, 3 Oct 2019 18:17:57 +0000 (11:17 -0700)]
Merge tag 'kgdb-5.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux
Pull kgdb update from Daniel Thompson:
"This is just a single patch adding a new reviewer for kgdb. New
reviewers will be a big help so I decided to consider this to be a
fix!
I'm looking forward to working more closely with Doug"
* tag 'kgdb-5.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux:
MAINTAINERS: kgdb: Add myself as a reviewer for kgdb/kdb
Randy Dunlap [Thu, 3 Oct 2019 00:08:18 +0000 (17:08 -0700)]
lib: textsearch: fix escapes in example code
This textsearch code example does not need the '\' escapes and they can
be misleading to someone reading the example. Also, gcc and sparse warn
that the "\%d" is an unknown escape sequence.
Prashant Malani [Wed, 2 Oct 2019 21:09:33 +0000 (14:09 -0700)]
r8152: Add identifier names for function pointers
Checkpatch throws warnings for function pointer declarations which lack
identifier names.
An example of such a warning is:
WARNING: function definition argument 'struct r8152 *' should
also have an identifier name
739: FILE: drivers/net/usb/r8152.c:739:
+ void (*init)(struct r8152 *);
So, fix those warnings by adding the identifier names.
While we are at it, also fix a character limit violation which was
causing another checkpatch warning.
Josh Hunt [Wed, 2 Oct 2019 17:29:23 +0000 (13:29 -0400)]
udp: only do GSO if # of segs > 1
Prior to this change an application sending <= 1MSS worth of data and
enabling UDP GSO would fail if the system had SW GSO enabled, but the
same send would succeed if HW GSO offload is enabled. In addition to this
inconsistency the error in the SW GSO case does not get back to the
application if sending out of a real device so the user is unaware of this
failure.
With this change we only perform GSO if the # of segments is > 1 even
if the application has enabled segmentation. I've also updated the
relevant udpgso selftests.
Josh Hunt [Wed, 2 Oct 2019 17:29:22 +0000 (13:29 -0400)]
udp: fix gso_segs calculations
Commit dfec0ee22c0a ("udp: Record gso_segs when supporting UDP segmentation offload")
added gso_segs calculation, but incorrectly got sizeof() the pointer and
not the underlying data type. In addition let's fix the v6 case.
Fixes: bec1f6f69736 ("udp: generate gso with UDP_SEGMENT") Fixes: dfec0ee22c0a ("udp: Record gso_segs when supporting UDP segmentation offload") Signed-off-by: Josh Hunt <[email protected]> Reviewed-by: Alexander Duyck <[email protected]> Acked-by: Willem de Bruijn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Douglas Anderson [Fri, 20 Sep 2019 17:44:47 +0000 (10:44 -0700)]
MAINTAINERS: kgdb: Add myself as a reviewer for kgdb/kdb
I'm interested in kdb / kgdb and have sent various fixes over the
years. I'd like to get CCed on patches so I can be aware of them and
also help review.
Eric Dumazet [Wed, 2 Oct 2019 16:38:55 +0000 (09:38 -0700)]
ipv6: drop incoming packets having a v4mapped source address
This began with a syzbot report. syzkaller was injecting
IPv6 TCP SYN packets having a v4mapped source address.
After an unsuccessful 4-tuple lookup, TCP creates a request
socket (SYN_RECV) and calls reqsk_queue_hash_req()
reqsk_queue_hash_req() calls sk_ehashfn(sk)
At this point we have AF_INET6 sockets, and the heuristic
used by sk_ehashfn() to either hash the IPv4 or IPv6 addresses
is to use ipv6_addr_v4mapped(&sk->sk_v6_daddr)
For the particular spoofed packet, we end up hashing V4 addresses
which were not initialized by the TCP IPv6 stack, so KMSAN fired
a warning.
I first fixed sk_ehashfn() to test both source and destination addresses,
but then faced various problems, including user-space programs
like packetdrill that had similar assumptions.
Instead of trying to fix the whole ecosystem, it is better
to admit that we have a dual stack behavior, and that we
can not build linux kernels without V4 stack anyway.
The dual stack API automatically forces the traffic to be IPv4
if v4mapped addresses are used at bind() or connect(), so it makes
no sense to allow IPv6 traffic to use the same v4mapped class.
KVM: nVMX: Fix consistency check on injected exception error code
Current versions of Intel's SDM incorrectly state that "bits 31:15 of
the VM-Entry exception error-code field" must be zero. In reality, bits
31:16 must be zero, i.e. error codes are 16-bit values.
The bogus error code check manifests as an unexpected VM-Entry failure
due to an invalid code field (error number 7) in L1, e.g. when injecting
a #GP with error_code=0x9f00.
Nadav previously reported the bug[*], both to KVM and Intel, and fixed
the associated kvm-unit-test.
Paolo Bonzini [Tue, 1 Oct 2019 13:18:26 +0000 (15:18 +0200)]
KVM: x86: omit absent pmu MSRs from MSR list
INTEL_PMC_MAX_GENERIC is currently 32, which exceeds the 18 contiguous
MSR indices reserved by Intel for event selectors. Since some machines
actually have MSRs past the reserved range, these may survive the
filtering of msrs_to_save array and would be rejected by KVM_GET/SET_MSR.
To avoid this, cut the list to whatever CPUID reports for the host's
architectural PMU.
Shuah Khan [Wed, 2 Oct 2019 23:14:30 +0000 (17:14 -0600)]
selftests: kvm: Fix libkvm build error
Fix the following build error from "make TARGETS=kvm kselftest":
libkvm.a(assert.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
This error is seen when build is done from the main Makefile using
kselftest target. In this case KBUILD_CPPFLAGS and CC_OPTION_CFLAGS
are defined.
When build is invoked using:
"make -C tools/testing/selftests/kvm" KBUILD_CPPFLAGS and CC_OPTION_CFLAGS
aren't defined.
There is no need to pass in KBUILD_CPPFLAGS and CC_OPTION_CFLAGS for the
check to determine if --no-pie is necessary, which is the case when these
two aren't defined when "make -C tools/testing/selftests/kvm" runs.
Fix it by simplifying the no-pie-option logic. With this change, both
build variations work.
Tomi Valkeinen [Wed, 2 Oct 2019 12:25:42 +0000 (15:25 +0300)]
drm/omap: fix max fclk divider for omap36xx
The OMAP36xx and AM/DM37x TRMs say that the maximum divider for DSS fclk
(in CM_CLKSEL_DSS) is 32. Experimentation shows that this is not
correct, and using divider of 32 breaks DSS with a flood or underflows
and sync losts. Dividers up to 31 seem to work fine.
There is another patch to the DT files to limit the divider correctly,
but as the DSS driver also needs to know the maximum divider to be able
to iteratively find good rates, we also need to do the fix in the DSS
driver.
Ville Syrjälä [Mon, 30 Sep 2019 18:30:45 +0000 (21:30 +0300)]
drm/i915: Fix g4x sprite scaling stride check with GTT remapping
I forgot to update the g4x sprite scaling stride check when GTT
remapping was introduced. The stride of the original framebuffer
is irrelevant when remapping is used and instead we want to check
the stride of the remapped view.
Also drop the duplicate width_bytes check. We already check that
a few lines earlier.
There was a integer wraparound when mode_clock became too high,
and we didn't correct for the FEC overhead factor when dividing,
with the calculations breaking at HBR3.
As a result our calculated bpp was way too high, and the link width
limitation never came into effect.
Print out the resulting bpp calcululations as a sanity check, just
in case we ever have to debug it later on again.
We also used the wrong factor for FEC. While bspec mentions 2.4%,
all the calculations use 1/0.972261, and the same ratio should be
applied to data M/N as well, so use it there when FEC is enabled.
This fixes the FIFO underrun we are seeing with FEC enabled.
Changes since v2:
- Handle fec_enable in intel_link_compute_m_n, so only data M/N is adjusted. (Ville)
- Fix initial hardware readout for FEC. (Ville)
Changes since v3:
- Remove bogus fec_to_mode_clock. (Ville)
Changes since v4:
- Use the correct register for icl. (Ville)
- Split hw readout to a separate patch.
Thierry Reding [Wed, 2 Oct 2019 14:49:46 +0000 (16:49 +0200)]
net: stmmac: Avoid deadlock on suspend/resume
The stmmac driver will try to acquire its private mutex during suspend
via phylink_resolve() -> stmmac_mac_link_down() -> stmmac_eee_init().
However, the phylink configuration is updated with the private mutex
held already, which causes a deadlock during suspend.
Fix this by moving the phylink configuration updates out of the region
of code protected by the private mutex.
Fixes: 19e13cb27b99 ("net: stmmac: Hold rtnl lock in suspend/resume callbacks") Suggested-by: Bitan Biswas <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Matteo Croce [Wed, 2 Oct 2019 21:49:04 +0000 (23:49 +0200)]
mvpp2: remove misleading comment
Recycling in mvpp2 has gone long time ago, but two comment still refers
to it. Remove those two misleading comments as they generate confusion.
Fixes: 7ef7e1d949cd ("net: mvpp2: drop useless fields in mvpp2_bm_pool and related code") Signed-off-by: Matteo Croce <[email protected]> Signed-off-by: David S. Miller <[email protected]>
and honestly, sparse is correct to warn. The return type of
free_percpu_irq() is 'void', while free_irq() returns a 'const void *'
that is the devname argument passed in to the request_irq().
You can't mix a void type with a non-void types in a conditional
expression according to the C standard. It so happens that gcc seems to
accept it - and the resulting type of the expression is void - but
there's really no reason for the kernel to have this kind of
non-standard expression with no real upside.
The natural way to write that expression is with an if-statement:
if (of_irq->percpu)
free_percpu_irq(of_irq->irq, clkevt);
else
free_irq(of_irq->irq, clkevt);
which is more legible anyway.
I'm not sure why that timer-of code seems to have this odd pattern. It
does the same at allocation time, but at least there the types match,
and it makes sense as an expression.
Linus Torvalds [Wed, 2 Oct 2019 22:54:19 +0000 (15:54 -0700)]
Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fix from Ingo Molnar:
"Fix a broadcast-timer handling race that can result in spuriously and
indefinitely delayed hrtimers and even RCU stalls if the system is
otherwise quiet"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tick: broadcast-hrtimer: Fix a race in bc_set_next
David S. Miller [Wed, 2 Oct 2019 21:47:52 +0000 (14:47 -0700)]
Merge branch 'CAIF-Kconfig-fixes'
Randy Dunlap says:
====================
CAIF Kconfig fixes
This series of patches cleans up the CAIF Kconfig menus in
net/caif/Kconfig and drivers/net/caif/Kconfig and also puts the
CAIF Transport drivers into their own sub-menu.
====================
Eric Dumazet [Tue, 1 Oct 2019 21:02:36 +0000 (14:02 -0700)]
net_sched: remove need_resched() from qdisc_run()
The introduction of this schedule point was done in commit 2ba2506ca7ca ("[NET]: Add preemption point in qdisc_run")
at a time the loop was not bounded.
Then later in commit d5b8aa1d246f ("net_sched: fix dequeuer fairness")
we added a limit on the number of packets.
Now is the time to remove the schedule point, since the default
limit of 64 packets matches the number of packets a typical NAPI
poll can process in a row.
This solves a latency problem for most TCP receivers under moderate load :
1) host receives a packet.
NET_RX_SOFTIRQ is raised by NIC hard IRQ handler
2) __do_softirq() does its first loop, handling NET_RX_SOFTIRQ
and calling the driver napi->loop() function
3) TCP stores the skb in socket receive queue:
4) TCP calls sk->sk_data_ready() and wakeups a user thread
waiting for EPOLLIN (as a result, need_resched() might now be true)
5) TCP cooks an ACK and sends it.
6) qdisc_run() processes one packet from qdisc, and sees need_resched(),
this raises NET_TX_SOFTIRQ (even if there are no more packets in
the qdisc)
Then we go back to the __do_softirq() in 2), and we see that new
softirqs were raised. Since need_resched() is true, we end up waking
ksoftirqd in this path :
if (pending) {
if (time_before(jiffies, end) && !need_resched() &&
--max_restart)
goto restart;
wakeup_softirqd();
}
So we have many wakeups of ksoftirqd kernel threads,
and more calls to qdisc_run() with associated lock overhead.
Note that another way to solve the issue would be to change TCP
to first send the ACK packet, then signal the EPOLLIN,
but this changes P99 latencies, as sending the ACK packet
can add a long delay.
Yizhuo [Tue, 1 Oct 2019 20:24:39 +0000 (13:24 -0700)]
net: hisilicon: Fix usage of uninitialized variable in function mdio_sc_cfg_reg_write()
In function mdio_sc_cfg_reg_write(), variable "reg_value" could be
uninitialized if regmap_read() fails. However, "reg_value" is used
to decide the control flow later in the if statement, which is
potentially unsafe.
Vladimir Oltean [Tue, 1 Oct 2019 19:12:50 +0000 (22:12 +0300)]
net: dsa: Remove unused __DSA_SKB_CB macro
The struct __dsa_skb_cb is supposed to span the entire 48-byte skb
control block, while the struct dsa_skb_cb only the portion of it which
is used by the DSA core (the rest is available as private data to
drivers).
The DSA_SKB_CB and __DSA_SKB_CB helpers are supposed to help retrieve
this pointer based on a skb, but it turns out there is nobody directly
interested in the struct __dsa_skb_cb in the kernel. So remove it.
MIPS: init: Prevent adding memory before PHYS_OFFSET
On some SGI machines (IP28 and IP30) a small region of memory is mirrored
to pyhsical address 0 for exception vectors while rest of the memory
is reachable at a higher physical address. ARC PROM marks this
region as reserved, but with commit a94e4f24ec83 ("MIPS: init: Drop
boot_mem_map") this chunk is used, when searching for start of ram,
which breaks at least IP28 and IP30 machines. To fix this
add_region_memory() checks for start address < PHYS_OFFSET and ignores
these chunks.
Paul Burton [Wed, 2 Oct 2019 17:46:36 +0000 (17:46 +0000)]
MIPS: VDSO: Fix build for binutils < 2.25
Versions of binutils prior to 2.25 are unable to link our VDSO due to an
unsupported R_MIPS_PC32 relocation generated by the ".word _start - ."
line of the inline asm in get_vdso_base(). As such, the intent is that
when building with binutils older than 2.25 we don't build code for
gettimeofday() & friends in the VDSO that rely upon get_vdso_base().
Commit 24640f233b46 ("mips: Add support for generic vDSO") converted us
to using generic VDSO infrastructure, and as part of that the
gettimeofday() functionality moved to a new vgettimeofday.c file. The
check for binutils < 2.25 wasn't updated to handle this new filename,
and so it continues trying to remove the old unused filename from the
build. The end result is that we try to include the gettimeofday() code
in builds that will fail to link.
Fix this by updating the binutils < 2.25 case to remove vgettimeofday.c
from obj-vdso-y, rather than gettimeofday.c.
Paul Burton [Wed, 2 Oct 2019 18:59:49 +0000 (18:59 +0000)]
MIPS: Wire up clone3 syscall
Wire up the new clone3 syscall for MIPS, using save_static_function() to
generate a wrapper that saves registers $s0-$s7 prior to invoking the
generic sys_clone3 function just like we do for plain old clone.
Tested atop 64r6el_defconfig using o32, n32 & n64 builds of the simple
test program from:
Linus Torvalds [Wed, 2 Oct 2019 20:53:48 +0000 (13:53 -0700)]
Merge tag 'erofs-for-5.4-rc2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs
Pull erofs fixes from Gao Xiang:
"Three patches to address regressions due to recent cleanups, mainly
found by stress test on latest mainline kernel (no more regression out
compared with older kernels for more than a week)
One additional patch updates sub-entries in MAINTAINERS.
Summary:
- Fix error handling in erofs_read_superblock
- Fix locking in erofs_get_meta_page
- Fix inplace behavior due to decompression frontend cleanup
- Update sub-entries in MAINTAINERS in order to better blame"
* tag 'erofs-for-5.4-rc2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs:
erofs: fix mis-inplace determination related with noio chain
erofs: fix erofs_get_meta_page locking due to a cleanup
MAINTAINERS: erofs: complete sub-entries for erofs
erofs: fix return value check in erofs_read_superblock()
Borislav Petkov [Tue, 1 Oct 2019 17:50:23 +0000 (19:50 +0200)]
char/random: Add a newline at the end of the file
On Tue, Oct 01, 2019 at 10:14:40AM -0700, Linus Torvalds wrote:
> The previous state of the file didn't have that 0xa at the end, so you get that
>
>
> -EXPORT_SYMBOL_GPL(add_bootloader_randomness);
> \ No newline at end of file
> +EXPORT_SYMBOL_GPL(add_bootloader_randomness);
>
> which is "the '-' line doesn't have a newline, the '+' line does" marker.
Aaha, that makes total sense, thanks for explaining. Oh well, let's fix
it then so that people don't scratch heads like me.
Juergen Gross [Tue, 1 Oct 2019 15:03:55 +0000 (17:03 +0200)]
xen/xenbus: fix self-deadlock after killing user process
In case a user process using xenbus has open transactions and is killed
e.g. via ctrl-C the following cleanup of the allocated resources might
result in a deadlock due to trying to end a transaction in the xenbus
worker thread:
Maxime Ripard [Wed, 2 Oct 2019 14:46:40 +0000 (16:46 +0200)]
dt-bindings: phy: lantiq: Fix Property Name
The binding has a typo where resets-names should read reset-names, which in
turn leads to a warning when the example is validated, since reset-names is
being used, and the binding prevent the usage of any property that isn't
described.
Fixes: 088e88be5a38 ("dt-bindings: phy: add binding for the Lantiq VRX200 and ARX300 PCIe PHYs") Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Rob Herring <[email protected]>
Maxime Ripard [Wed, 2 Oct 2019 14:45:42 +0000 (16:45 +0200)]
dt-bindings: iio: ad7192: Fix DTC warning in the example
The example contains an SPI bus and device, but doesn't have the
appropriate size and address cells size.
This creates a DTC warning when the example is compiled since the default
ones will not match what the device uses. Let's add them to remove that
warning.
Fixes: f7356e47032c ("dt-bindings: iio: adc: ad7192: Add binding documentation for AD7192") Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Rob Herring <[email protected]>
The AD7192 binding describes two regulator properties, avdd-supply and
dvdd-supply, but describes it as a constant string that must be avdd and
dvdd. This is wrong since a *-supply property is actually a phandle, and
results in warnings when the example is validated (or any device tree using
that device, for that matter).
Let's remove that requirement.
Fixes: f7356e47032c ("dt-bindings: iio: adc: ad7192: Add binding documentation for AD7192") Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Rob Herring <[email protected]>
Maxime Ripard [Wed, 2 Oct 2019 14:42:04 +0000 (16:42 +0200)]
dt-bindings: dsp: Fix fsl,dsp example
The fsl,dsp binding requires a memory-region, yet its example doesn't have
one which results in a warning. Let's add a memory-region phandle to the
example.
Fixes: 7db2f2dfc701 ("dt-bindings: dsp: fsl: Add DSP core binding support") Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Daniel Baluta <[email protected]> Signed-off-by: Rob Herring <[email protected]>
The type definition for 'uint' clashes with the generic kernel
headers:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:43:22: error: redefinition of typedef 'uint' is a C11 feature [-Werror,-Wtypedef-redefinition]
include/linux/types.h:92:23: note: previous definition is here
Just remove this type and use plain 'unsigned int' consistently,
as it is already use almost everywhere in this file.
Arnd Bergmann [Wed, 2 Oct 2019 12:01:23 +0000 (14:01 +0200)]
drm/amdgpu: hide another #warning
An earlier patch of mine disabled some #warning statements
that get in the way of build testing, but then another
instance was added around the same time.
Remove that as well.
Fixes: b5203d16aef4 ("drm/amd/amdgpu: hide #warning for missing DC config") Fixes: e1c14c43395c ("drm/amdgpu: Enable DC on Renoir") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Arnd Bergmann [Wed, 2 Oct 2019 12:01:22 +0000 (14:01 +0200)]
drm/amdgpu: make pmu support optional, again
When CONFIG_PERF_EVENTS is disabled, we cannot compile the pmu
portion of the amdgpu driver:
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:48:38: error: no member named 'hw' in 'struct perf_event'
struct hw_perf_event *hwc = &event->hw;
~~~~~ ^
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:51:13: error: no member named 'attr' in 'struct perf_event'
if (event->attr.type != event->pmu->type)
~~~~~ ^
...
The same bug was already fixed by commit d155bef0636e ("amdgpu: make pmu
support optional") but broken again by what looks like an incorrectly
rebased patch.
Navid Emamdoost [Wed, 2 Oct 2019 03:46:07 +0000 (22:46 -0500)]
drm/amdgpu: fix multiple memory leaks in acp_hw_init
In acp_hw_init there are some allocations that needs to be released in
case of failure:
1- adev->acp.acp_genpd should be released if any allocation attemp for
adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
2- all of those allocations should be released if
mfd_add_hotplug_devices or pm_genpd_add_device fail.
3- Release is needed in case of time out values expire.
Kevin Wang [Thu, 26 Sep 2019 08:22:13 +0000 (16:22 +0800)]
drm/amd/powerplay: add sensor lock support for smu
when multithreading access sysfs of amdgpu_pm_info at the sametime.
the swsmu driver cause smu firmware hang.
eg:
single thread access:
Message A + Param A ==> right
Message B + Param B ==> right
Message C + Param C ==> right
multithreading access:
Message A + Param B ==> error
Message B + Param A ==> error
Message C + Param C ==> right
the patch will add sensor lock(mutex) to avoid this error.
Paul Burton [Tue, 1 Oct 2019 21:56:37 +0000 (21:56 +0000)]
MIPS: octeon: Include required header; fix octeon ethernet build
Commit 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS") moved
the inclusion of a bunch of headers by various files in the Octeon
ethernet driver into a common header, but in doing so it changed the
order in which those headers are included.
Prior to the referenced commit drivers/staging/octeon/ethernet.c
included asm/octeon/cvmx-pip.h before asm/octeon/cvmx-ipd.h, which makes
use of the CVMX_PIP_SFT_RST definition pulled in by the former. After
commit 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS") we
pull in asm/octeon/cvmx-ipd.h first & builds fail with:
In file included from drivers/staging/octeon/octeon-ethernet.h:27,
from drivers/staging/octeon/ethernet.c:22:
arch/mips/include/asm/octeon/cvmx-ipd.h: In function 'cvmx_ipd_free_ptr':
arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: error: storage size of
'pip_sft_rst' isn't known
union cvmx_pip_sft_rst pip_sft_rst;
^~~~~~~~~~~
arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: error: 'CVMX_PIP_SFT_RST'
undeclared (first use in this function); did you mean 'CVMX_CIU_SOFT_RST'?
pip_sft_rst.u64 = cvmx_read_csr(CVMX_PIP_SFT_RST);
^~~~~~~~~~~~~~~~
CVMX_CIU_SOFT_RST
arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: note: each undeclared
identifier is reported only once for each function it appears in
arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: warning: unused variable
'pip_sft_rst' [-Wunused-variable]
union cvmx_pip_sft_rst pip_sft_rst;
^~~~~~~~~~~
make[4]: *** [scripts/Makefile.build:266: drivers/staging/octeon/ethernet.o]
Error 1
make[3]: *** [scripts/Makefile.build:509: drivers/staging/octeon] Error 2
Fix this by having asm/octeon/cvmx-ipd.h include the
asm/octeon/cvmx-pip-defs.h header that it is reliant upon, rather than
requiring its users to pull in that header before it.
Vladimir Oltean [Tue, 1 Oct 2019 19:18:01 +0000 (22:18 +0300)]
net: dsa: sja1105: Rename sja1105_spi_send_packed_buf to sja1105_xfer_buf
The most commonly called function in the driver is long due for a
rename. The "packed" word is redundant (it doesn't make sense to
transfer an unpacked structure, since that is in CPU endianness yadda
yadda), and the "spi" word is also redundant since argument 2 of the
function is SPI_READ or SPI_WRITE.
As for the sja1105_spi_send_long_packed_buf function, it is only being
used from sja1105_spi.c, so remove its global prototype.
Vladimir Oltean [Tue, 1 Oct 2019 19:18:00 +0000 (22:18 +0300)]
net: dsa: sja1105: Replace sja1105_spi_send_int with sja1105_xfer_{u32, u64}
Having a function that takes a variable number of unpacked bytes which
it generically calls an "int" is confusing and makes auditing patches
next to impossible.
We only use spi_send_int with the int sizes of 32 and 64 bits. So just
make the spi_send_int function less generic and replace it with the
appropriate two explicit functions, which can now type-check the int
pointer type.
Note that there is still a small weirdness in the u32 function, which
has to convert it to a u64 temporary. This is because of how the packing
API works at the moment, but the weirdness is at least hidden from
callers of sja1105_xfer_u32 now.
Vladimir Oltean [Tue, 1 Oct 2019 19:07:01 +0000 (22:07 +0300)]
ptp_qoriq: Initialize the registers' spinlock before calling ptp_qoriq_settime
Because ptp_qoriq_settime is being called prior to spin_lock_init, the
following stack trace can be seen at driver probe time:
[ 2.269117] the code is fine but needs lockdep annotation.
[ 2.274569] turning off the locking correctness validator.
[ 2.280027] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc7-01478-g01eaa67a4797 #263
[ 2.288073] Hardware name: Freescale LS1021A
[ 2.292337] [<c0313cb4>] (unwind_backtrace) from [<c030e11c>] (show_stack+0x10/0x14)
[ 2.300045] [<c030e11c>] (show_stack) from [<c1219440>] (dump_stack+0xcc/0xf8)
[ 2.307235] [<c1219440>] (dump_stack) from [<c03b9b44>] (register_lock_class+0x730/0x73c)
[ 2.315372] [<c03b9b44>] (register_lock_class) from [<c03b6190>] (__lock_acquire+0x78/0x270c)
[ 2.323856] [<c03b6190>] (__lock_acquire) from [<c03b90cc>] (lock_acquire+0xe0/0x22c)
[ 2.331649] [<c03b90cc>] (lock_acquire) from [<c123c310>] (_raw_spin_lock_irqsave+0x54/0x68)
[ 2.340048] [<c123c310>] (_raw_spin_lock_irqsave) from [<c0e73fe4>] (ptp_qoriq_settime+0x38/0x80)
[ 2.348878] [<c0e73fe4>] (ptp_qoriq_settime) from [<c0e746d4>] (ptp_qoriq_init+0x1f8/0x484)
[ 2.357189] [<c0e746d4>] (ptp_qoriq_init) from [<c0e74aac>] (ptp_qoriq_probe+0xd0/0x184)
[ 2.365243] [<c0e74aac>] (ptp_qoriq_probe) from [<c0b0a07c>] (platform_drv_probe+0x48/0x9c)
[ 2.373555] [<c0b0a07c>] (platform_drv_probe) from [<c0b07a14>] (really_probe+0x1c4/0x400)
[ 2.381779] [<c0b07a14>] (really_probe) from [<c0b07e28>] (driver_probe_device+0x78/0x1b8)
[ 2.390003] [<c0b07e28>] (driver_probe_device) from [<c0b081d0>] (device_driver_attach+0x58/0x60)
[ 2.398832] [<c0b081d0>] (device_driver_attach) from [<c0b082d4>] (__driver_attach+0xfc/0x160)
[ 2.407402] [<c0b082d4>] (__driver_attach) from [<c0b05a84>] (bus_for_each_dev+0x68/0xb4)
[ 2.415539] [<c0b05a84>] (bus_for_each_dev) from [<c0b06b68>] (bus_add_driver+0x104/0x20c)
[ 2.423763] [<c0b06b68>] (bus_add_driver) from [<c0b0909c>] (driver_register+0x78/0x10c)
[ 2.431815] [<c0b0909c>] (driver_register) from [<c030313c>] (do_one_initcall+0x8c/0x3ac)
[ 2.439954] [<c030313c>] (do_one_initcall) from [<c1f013f4>] (kernel_init_freeable+0x468/0x548)
[ 2.448610] [<c1f013f4>] (kernel_init_freeable) from [<c12344d8>] (kernel_init+0x8/0x10c)
[ 2.456745] [<c12344d8>] (kernel_init) from [<c03010b4>] (ret_from_fork+0x14/0x20)
[ 2.464273] Exception stack(0xea89ffb0 to 0xea89fff8)
[ 2.469297] ffa0: 00000000000000000000000000000000
[ 2.477432] ffc0: 0000000000000000000000000000000000000000000000000000000000000000
[ 2.485566] ffe0: 000000000000000000000000000000000000001300000000
Fixes: ff54571a747b ("ptp_qoriq: convert to use ptp_qoriq_init/free") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
David S. Miller [Wed, 2 Oct 2019 16:19:53 +0000 (12:19 -0400)]
Merge branch 'SJA1105-DSA-locking-fixes-for-PTP'
Vladimir Oltean says:
====================
SJA1105 DSA locking fixes for PTP
This series fixes the locking API usage problems spotted when compiling
the kernel with CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_DEBUG_SPINLOCK=y.
====================
Vladimir Oltean [Tue, 1 Oct 2019 18:58:19 +0000 (21:58 +0300)]
net: dsa: sja1105: Fix sleeping while atomic in .port_hwtstamp_set
Currently this stack trace can be seen with CONFIG_DEBUG_ATOMIC_SLEEP=y:
[ 41.568348] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:909
[ 41.576757] in_atomic(): 1, irqs_disabled(): 0, pid: 208, name: ptp4l
[ 41.583212] INFO: lockdep is turned off.
[ 41.587123] CPU: 1 PID: 208 Comm: ptp4l Not tainted 5.3.0-rc6-01445-ge950f2d4bc7f-dirty #1827
[ 41.599873] [<c0313d7c>] (unwind_backtrace) from [<c030e13c>] (show_stack+0x10/0x14)
[ 41.607584] [<c030e13c>] (show_stack) from [<c1212d50>] (dump_stack+0xd4/0x100)
[ 41.614863] [<c1212d50>] (dump_stack) from [<c037dfc8>] (___might_sleep+0x1c8/0x2b4)
[ 41.622574] [<c037dfc8>] (___might_sleep) from [<c122ea90>] (__mutex_lock+0x48/0xab8)
[ 41.630368] [<c122ea90>] (__mutex_lock) from [<c122f51c>] (mutex_lock_nested+0x1c/0x24)
[ 41.638340] [<c122f51c>] (mutex_lock_nested) from [<c0c6fe08>] (sja1105_static_config_reload+0x30/0x27c)
[ 41.647779] [<c0c6fe08>] (sja1105_static_config_reload) from [<c0c7015c>] (sja1105_hwtstamp_set+0x108/0x1cc)
[ 41.657562] [<c0c7015c>] (sja1105_hwtstamp_set) from [<c0feb650>] (dev_ifsioc+0x18c/0x330)
[ 41.665788] [<c0feb650>] (dev_ifsioc) from [<c0febbd8>] (dev_ioctl+0x320/0x6e8)
[ 41.673064] [<c0febbd8>] (dev_ioctl) from [<c0f8b1f4>] (sock_ioctl+0x334/0x5e8)
[ 41.680340] [<c0f8b1f4>] (sock_ioctl) from [<c05404a8>] (do_vfs_ioctl+0xb0/0xa10)
[ 41.687789] [<c05404a8>] (do_vfs_ioctl) from [<c0540e3c>] (ksys_ioctl+0x34/0x58)
[ 41.695151] [<c0540e3c>] (ksys_ioctl) from [<c0301000>] (ret_fast_syscall+0x0/0x28)
[ 41.702768] Exception stack(0xe8495fa8 to 0xe8495ff0)
[ 41.707796] 5fa0: beff4a8c0000000100000011000089b0beff4a8cbeff4a80
[ 41.715933] 5fc0: beff4a8c000000010000000c00000036b6fa98c8004e19c10000000100000000
[ 41.724069] 5fe0: 004dcedcbeff4a6c004c0738b6e7af4c
[ 41.729860] BUG: scheduling while atomic: ptp4l/208/0x00000002
[ 41.735682] INFO: lockdep is turned off.
Enabling RX timestamping will logically disturb the fastpath (processing
of meta frames). Replace bool hwts_rx_en with a bit that is checked
atomically from the fastpath and temporarily unset from the sleepable
context during a change of the RX timestamping process (a destructive
operation anyways, requires switch reset).
If found unset, the fastpath (net/dsa/tag_sja1105.c) will just drop any
received meta frame and not take the meta_lock at all.
Fixes: a602afd200f5 ("net: dsa: sja1105: Expose PTP timestamping ioctls to userspace") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Vladimir Oltean [Tue, 1 Oct 2019 18:58:18 +0000 (21:58 +0300)]
net: dsa: sja1105: Initialize the meta_lock
Otherwise, with CONFIG_DEBUG_SPINLOCK=y, this stack trace gets printed
when enabling RX timestamping and receiving a PTP frame:
[ 318.537078] INFO: trying to register non-static key.
[ 318.542040] the code is fine but needs lockdep annotation.
[ 318.547500] turning off the locking correctness validator.
[ 318.552972] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-13257-g0825b0669811-dirty #1962
[ 318.561283] Hardware name: Freescale LS1021A
[ 318.565566] [<c03144bc>] (unwind_backtrace) from [<c030e164>] (show_stack+0x10/0x14)
[ 318.573289] [<c030e164>] (show_stack) from [<c11b9f50>] (dump_stack+0xd4/0x100)
[ 318.580579] [<c11b9f50>] (dump_stack) from [<c03b9b40>] (register_lock_class+0x728/0x734)
[ 318.588731] [<c03b9b40>] (register_lock_class) from [<c03b60c4>] (__lock_acquire+0x78/0x25cc)
[ 318.597227] [<c03b60c4>] (__lock_acquire) from [<c03b8ef8>] (lock_acquire+0xd8/0x234)
[ 318.605033] [<c03b8ef8>] (lock_acquire) from [<c11db934>] (_raw_spin_lock+0x44/0x54)
[ 318.612755] [<c11db934>] (_raw_spin_lock) from [<c1164370>] (sja1105_rcv+0x1f8/0x4e8)
[ 318.620561] [<c1164370>] (sja1105_rcv) from [<c115d7cc>] (dsa_switch_rcv+0x80/0x204)
[ 318.628283] [<c115d7cc>] (dsa_switch_rcv) from [<c0f58c80>] (__netif_receive_skb_one_core+0x50/0x6c)
[ 318.637386] [<c0f58c80>] (__netif_receive_skb_one_core) from [<c0f58f04>] (netif_receive_skb_internal+0xac/0x264)
[ 318.647611] [<c0f58f04>] (netif_receive_skb_internal) from [<c0f59e98>] (napi_gro_receive+0x1d8/0x338)
[ 318.656887] [<c0f59e98>] (napi_gro_receive) from [<c0c298a4>] (gfar_clean_rx_ring+0x328/0x724)
[ 318.665472] [<c0c298a4>] (gfar_clean_rx_ring) from [<c0c29e60>] (gfar_poll_rx_sq+0x34/0x94)
[ 318.673795] [<c0c29e60>] (gfar_poll_rx_sq) from [<c0f5b40c>] (net_rx_action+0x128/0x4f8)
[ 318.681860] [<c0f5b40c>] (net_rx_action) from [<c03022f0>] (__do_softirq+0x148/0x5ac)
[ 318.689666] [<c03022f0>] (__do_softirq) from [<c0355af4>] (irq_exit+0x160/0x170)
[ 318.697040] [<c0355af4>] (irq_exit) from [<c03c6818>] (__handle_domain_irq+0x60/0xb4)
[ 318.704847] [<c03c6818>] (__handle_domain_irq) from [<c07e9440>] (gic_handle_irq+0x58/0x9c)
[ 318.713172] [<c07e9440>] (gic_handle_irq) from [<c0301a70>] (__irq_svc+0x70/0x98)
[ 318.720622] Exception stack(0xc2001f18 to 0xc2001f60)
[ 318.725656] 1f00: 0000000100000006
[ 318.733805] 1f20: 00000000c20165c0ffffe000c2010cacc2010cf40000000100000000c2010c88
[ 318.741955] 1f40: c1f7a5a80000000000000000c2001f68c03ba140c030a288200e0013ffffffff
[ 318.750110] [<c0301a70>] (__irq_svc) from [<c030a288>] (arch_cpu_idle+0x24/0x3c)
[ 318.757486] [<c030a288>] (arch_cpu_idle) from [<c038a480>] (do_idle+0x1b8/0x2a4)
[ 318.764859] [<c038a480>] (do_idle) from [<c038a94c>] (cpu_startup_entry+0x18/0x1c)
[ 318.772407] [<c038a94c>] (cpu_startup_entry) from [<c1e00f10>] (start_kernel+0x4cc/0x4fc)
Fixes: 844d7edc6a34 ("net: dsa: sja1105: Add a global sja1105_tagger_data structure") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Dotan Barak [Tue, 1 Oct 2019 17:21:02 +0000 (10:21 -0700)]
net/rds: Fix error handling in rds_ib_add_one()
rds_ibdev:ipaddr_list and rds_ibdev:conn_list are initialized
after allocation some resources such as protection domain.
If allocation of such resources fail, then these uninitialized
variables are accessed in rds_ib_dev_free() in failure path. This
can potentially crash the system. The code has been updated to
initialize these variables very early in the function.
David S. Miller [Wed, 2 Oct 2019 16:15:15 +0000 (12:15 -0400)]
Merge branch 'SMB-rootfs'
Paulo Alcantara says:
====================
Experimental SMB rootfs support
This patch series enables Linux to mount root file systems over the
network by utilizing SMB protocol.
Upstream commit 8eecd1c2e5bc ("cifs: Add support for root file
systems") introduced a new CONFIG_CIFS_ROOT option, a virtual device
(Root_CIFS) and a kernel cmdline parameter "cifsroot=" which tells the
kernel to actually mount the root filesystem over a SMB share.
The feature relies on ipconfig to set up the network prior to mounting
the rootfs, so when it is set along with "cifsroot=" parameter:
(1) cifs_root_setup() parses all necessary data out of "cifsroot="
parameter for the init process know how to mount the SMB rootfs
(e.g. SMB server address, mount options).
(2) If DHCP failed for some reason in ipconfig, we keep retrying
forever as we have nowhere to go for NFS or SMB root
filesystems (see PATCH 2/2). Otherwise go to (3).
(3) mount_cifs_root() is then called by mount_root() (ROOT_DEV ==
Root_CIFS), retrieves early parsed data from (1), then attempt to
mount SMB rootfs by CIFSROOT_RETRY_MAX times at most (see PATCH
1/2).
(4) If all attempts failed, fall back to floppy drive, otherwise
continue the boot process with rootfs mounted over a SMB share.
My idea was to keep the same behavior of nfsroot - as it seems to work
for most users so far.
For more information on how this feature works, see
Documentation/filesystems/cifs/cifsroot.txt.
====================
The experimental root file system support in cifs.ko relies on
ipconfig to set up the network stack and then accessing the SMB share
that contains the rootfs files.
Add a new virtual device named /dev/cifs (0xfe) to tell the kernel to
mount the root file system over the network by using SMB protocol.
cifs_root_data() will be responsible to retrieve the parsed
information of the new command-line option (cifsroot=) and then call
do_mount_root() with the appropriate mount options for cifs.ko.
Shannon Nelson [Tue, 1 Oct 2019 03:03:26 +0000 (20:03 -0700)]
ionic: add lif_quiesce to wait for queue activity to stop
Even though we've already turned off the queue activity with
the ionic_qcq_disable(), we need to wait for any device queues
that are processing packets to drain down before we try to
flush our packets and tear down the queues.
Shannon Nelson [Tue, 1 Oct 2019 03:03:24 +0000 (20:03 -0700)]
ionic: report users coalesce request
The user's request for an interrupt coalescing value gets
translated into a hardware value to be used with the NIC,
and was getting reported back based on the hw value, which,
due to hw tic resolution, could be reported as a different
number than what the user originally asked for. This code
now tracks both the user request and what was put into the
hardware so we can report back to the user what they
requested.
projects / linux.git / log