Merge branch 'topic/uek-4.1/sparc' of git://ca-git.us.oracle.com/linux-uek into uek/uek-4.1
* 'topic/uek-4.1/sparc' of git://ca-git.us.oracle.com/linux-uek:
sparc64: vdso: simplify cpu_relax
vdso: replace current_thread_info when building vDSO rather than diking it out
sparc64, vdso: Add gettimeofday() and clock_gettime().
sparc64, vdso: sparc64 vDSO implementation.
Merge branch 'topic/uek-4.1/uek-carry' of git://ca-git.us.oracle.com/linux-uek into uek/uek-4.1
* 'topic/uek-4.1/uek-carry' of git://ca-git.us.oracle.com/linux-uek:
bonding: If IP route look-up to send an ARP fails, mark in bonding structure as no ARP sent.
xen/fpu: stts() before the local_irq_enable(), and clts() after the local_irq_disable().
Revert "x86, fpu: Avoid possible error in math_state_restore()"
bonding: If IP route look-up to send an ARP fails, mark in bonding structure as no ARP sent.
During the creation of VLAN's atop bonding the underlying interfaces are
made part of VLAN's, and at the same bonding driver gets aware of that
VLAN's exists above it and hence would consult IP routing for every ARP to
be sent to determine the route which tells bonding driver the correct VLAN
tag to attach to the outgoing ARP packet. But, during the VLAN creation
when vlan driver puts the underlying interface into default vlan and actual
vlan in-between this if bonding driver consults the IP for a route, IP fails
to provide a correct route and upon which bonding driver drops the ARP
packet. ARP monitor when it comes aroung next time, sees no ARP response
and fails-over to the next available slave. To prevent this false fail-over,
when bonding dirver fails to send an ARP out it marks in its private
structure, bonding{}, not to expect an ARP response, and when ARP monitor
comes around next time ARP sending will be tried again.
xen/fpu: stts() before the local_irq_enable(), and clts() after the local_irq_disable().
The Linux scheduler FPU allocation for a new process is a two-stage
mechanism prior to Linux v4.2. When an task is scheduled that hasn't
demonstrated a need for an FPU it set CR0.TS=1. The CR0.TS=1
will trap (and the CPU won't execute it) any FPU operations that the
task encountered. It allows the OS to lazily allocate for the
'struct task' an memory where FPU registers will be saved/restored.
When the task performs an FPU operation (MMX/SSE/etc) the first time
with CR0.TS=1 set, the hardware will trigger an exception #NM
(do_device_not_available) - and the exception handler (
math_state_restore) will setup up the memory for the task FPU
registers. And then return back to application allowing it to
execute the FPU operation (so with CR0.TS=0). And so on.
Thereafter if the task that has used the FPU is loaded, the CR0.TS
is cleared (0) so that the task can execute FPU operations unhindered.
Any tasks that are scheduled that haven't used the FPU get the
CR0.TS set (1). The kernel uses an PF_USED_MATH flag to figure
this out.
The below example should help in cementing this knowledge.
For simplicity we assume the guest/baremetal use the lazy mechanism
not eager. That makes 'switch_fpu_prepare' (called by schedule()) effectively:
if (previous task had PF_USED_MATH set)
stts (CR0.TS=1)
else
;
And ignoring the case if the task had used the FPU more than
five times - where we do things a bit different.
The time diagram looks great at 132x42.
Lets assume that we have two tasks: A and B. Both haven't used
the FPU. This is on PVHVM (or baremetal):
However Xen PV ABI choose to do a shortcut. When Xen hypervisor receives
an #NM it immediately clears the CR0.TS bit and executes the PV kernel
do_device_not_available handler. Which would be OK if the exception handler
would immediately do 'clts' (CR0.TS=0). Which it does 99% except that
one time when:
* does a slab alloc which can sleep
*/
if (init_fpu(tsk)) {
which can end up calling 'schedule()' (and swapping to another task)
with the CR0.TS bit being cleared.
The scheduler can schedule-in an application that uses the FPU and
since nobody has marked the task with FP_USED_MATH we end up
reusing the FPU registers across all the tasks. Ouch.
The [*1] refers to the Xen scheduler. If any of the
syscalls that the user application called, ended in the Linux kernel
halt (xen_safe_halt) routine - we would deschedule the guest VCPU.
When that VCPU is re-scheduled, Xen would set CR0.TS=1 back
so the #NM would function again.
Not pretty - and again - only happening if the fpu_alloc() ends
up calling the schedule().
The FPU rewrite removed the dynamic allocations of 'struct fpu'.
But, this potentially wastes massive amounts of memory (2k per
task on systems that do not have AVX-512 for instance).
Instead of having a separate slab, this patch just appends the
space that we need to the 'task_struct' which we dynamically
allocate already. This saves from doing an extra slab
allocation at fork().
When Xen hypervisor calls the PV guests #NM ('do_device_not_available')
it does:
fpu__restore(¤t->thread.fpu); /* interrupts still off */
|+- fpu__activate_curr (which just inits the already allocated space)
| \- memset(state, 0, xstate_size);
|+- fpregs_activate
\- stts()
So no call to 'schedule()' and leaking the FPU across different
tasks.
This patch modifies (and only for Xen PV guests) the state of
the CR0.TS to be set when 'schedule()' may be called. And if
'schedule()' is not called (fpu_alloc had no trouble getting
memory)', we set the CR0.TS back to zero (which actually may
not even be needed as we do that later as well).
Due to the wonder of paravirt and multicall batching the
'stts', 'clts' are not dispatched until arch_end_context_switch
is called (which is done in __switch_next which 'schedule()' does).
What that means is:
- If fpu_alloc() (well, SLAB) ends up calling 'schedule()'
the CR0.TS will get set when 'schedule()' is ready to start
the new thread.
- If fpu_alloc() had no trouble and there was no need for
'schedule()' - then will flush out the multicall effectively
doing CR0.TS=1 followed by CR0.TS=0, followed by CR0.TS=0 again.
The end result is the same.
P.S.
Multicalls is a mechanism to put a bunch of hypercalls in on
hypercall. It can execute up to 32 hypercalls.
Oracle-Bug: 14768
Orabug: 20318090 Reported-and-Tested-by: Saar Maoz <Saar.Maoz@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
The patch does not fix the underlaying problem. The
patch "xen/fpu: stts() before the local_irq_enable(), and clts()
after the local_irq_disable()" fixes the issue.
Acked-by: Annie Li <annie.li@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Merge branch '4.1_sparc' of git://ca-git.us.oracle.com/linux-uek-apais into topic/uek-4.1/sparc
* '4.1_sparc' of git://ca-git.us.oracle.com/linux-uek-apais:
sparc64: vdso: simplify cpu_relax
vdso: replace current_thread_info when building vDSO rather than diking it out
sparc64, vdso: Add gettimeofday() and clock_gettime().
sparc64, vdso: sparc64 vDSO implementation.
When building the userspace parts of the vDSO code, we have to dike out things
from the various kernel headers we use that generate register relocations,
since we cannot handle relocations in the vDSO. The principal such thing is
current_thread_info(), which we used to dike out entirely -- but in the -rt
patchset, a lot of things in the headers reference this. So, instead,
simply have current_thread_info() generate nonsense code that doesn't emit
a relocation, so that its users still compile (though they would never
work -- but that's not important, since they are never used).
Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
(cherry picked from commit 4f9b3c6e7fe105ea04f89794007f97b43a63c897)
Nick Alcock [Mon, 8 Dec 2014 13:42:37 +0000 (13:42 +0000)]
sparc64, vdso: Add gettimeofday() and clock_gettime().
This commit adds gettimeofday() and clock_gettime() entry points to the SPARC64
vDSO: in conjunction with a suitably-modified glibc this provides a speedup to
gettimeofday(), time() and some clock_gettime() calls of on the order of
10--15x (the higher figure is for the coarse clock_gettime() clocks).
gettimeofday() and clock_gettime() use largely separate code paths: all
other approaches with less code duplication (e.g. doing all the work in
a struct timespec and only shifting it into a struct timeval before return)
turned out slower.
Tested on %stick-capable machines only: %tick codepaths untested.
Orabug: 20861959 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
(cherry picked from commit e8f9e5cfc9d297c7ebbc459b677ee0b8a3e45154)
Nick Alcock [Mon, 8 Dec 2014 13:32:19 +0000 (13:32 +0000)]
sparc64, vdso: sparc64 vDSO implementation.
This commit adds a vDSO similar to that used on x86: in this commit, that vDSO
is empty bar the ELF note used by glibc to verify that it knows about this vDSO.
The vDSO's location is somewhat randomized, so, as a consequence, tends to
randomize the locations of other shared libraries too. (The randomization
respects /proc/sys/kernel/randomize_va_space.)
It is derived from the implementation in recent kernels, in that it uses a C
generator to translate the vDSO shared library into C code and validate that it
contains no relocations and the like.
Notes for future improvement:
- There is no support for a vDSO in 32-bit userspace yet. This is just because
I want to get the sparc64 version working first: the compat vDSO
implementation adds significant complexity.
- The vDSO randomization process is ugly: we are calling get_unmapped_area()
twice, with a randomization in the middle. Eventually,
arch_get_unmapped_area() on SPARC64 should learn about PF_RANDOMIZE, as it
has on other arches.
Orabug: 20861959 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
(cherry picked from commit 2da875e6f5781dd196e9f055cd53a3ac0d80aaaa)
Merge branch 'topic/uek-4.1/rpm-build' of git://ca-git.us.oracle.com/linux-uek into uek/uek-4.1
* 'topic/uek-4.1/rpm-build' of git://ca-git.us.oracle.com/linux-uek:
sparc64: enable firmware build in kernel spec
sparc64: enable usb xhci/ehci pci configs
sparc64: enable a few configs required for proxyt
sparc64:perf: fix perf build crash
sparc64: enable dtrace support for sparc64 in the spec file
sparc64: kernel-uek.spec update to support sparc.
sparc64: uek4 debug config for sparc64
sparc64: uek4 config for sparc64
uek-rpm: config: add turbostat into kernel pakackage for OL6 and OL7
uek-rom: config: Unset CONFIG_NFS_USE_LEGACY_DNS for OL7
uek-rpm: configs: Enbale X86_SYSFB on OL7 too
Merge branch 'topic/uek-4.1/sparc' of git://ca-git.us.oracle.com/linux-uek into uek/uek-4.1
* 'topic/uek-4.1/sparc' of git://ca-git.us.oracle.com/linux-uek: (25 commits)
lib/iommu-common.c: do not use 0xffffffffffffffffl for computing align_mask
sparc64: use ENTRY/ENDPROC in VISsave
SPARC64: PORT LDOMS TO UEK4
Fix incorrect ASI_ST_BLKINIT_MRU_S value
sparc64: perf: Use UREG_FP rather than UREG_I6
sparc64: perf: Add sanity checking on addresses in user stack
sparc64: Convert BUG_ON to warning
sparc: perf: Disable pagefaults while walking userspace stacks
sparc: time: Replace update_persistent_clock() with CONFIG_RTC_SYSTOHC
PCI: Set under_pref for mem64 resource of pcie device
sparc/PCI: Add mem64 resource parsing for root bus
PCI: Add pci_bus_addr_t
sparc64: Fix userspace FPU register corruptions.
sparc64: using 2048 as default for number of CPUS (cherry picked from commit 578ddb2512a5c908cd17ef8cbc43ff78dd399afd)
sparc64: iommu-common build error fix (cherry picked from commit accb4c6276793b991c6382bf57a58b40ea17eb11)
sparc64: fix Setup sysfs to mark LDOM sockets build error (cherry picked from commit 59be02427bfcac6c904ddd1374c35d63155b82d4)
sparc64: mmap fixed and shared
sparc64: restore TIF_FREEZE flag for sparc
sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly
sparc: Revert generic IOMMU allocator.
...
Merge branch 'topic/uek-4.1/dtrace' of git://ca-git.us.oracle.com/linux-uek into uek/uek-4.1
* 'topic/uek-4.1/dtrace' of git://ca-git.us.oracle.com/linux-uek:
kallsyms: unbreak kallmodsyms after CONFIG_KALLMODSYMS addition
kallsyms: de-ifdef kallmodsyms
dtrace: use syscall_get_nr() to obtain syscall number
Merge branch 'topic/uek-4.1/ocfs2' of git://ca-git.us.oracle.com/linux-uek into uek/uek-4.1
* 'topic/uek-4.1/ocfs2' of git://ca-git.us.oracle.com/linux-uek:
add OCFS2_LOCK_RECURSIVE arg_flags to ocfs2_cluster_lock() to prevent hang
ocfs2: direct write will call ocfs2_rw_unlock() twice when doing aio+dio
ocfs2_iop_set/get_acl() are also called from the VFS so we must take inode lock
BUG_ON(lockres->l_level != DLM_LOCK_EX && !checkpointed) tripped in ocfs2_ci_checkpointed
Merge branch 'topic/uek-4.1/upstream-cherry-picks' of git://ca-git.us.oracle.com/linux-uek into uek/uek-4.1
* 'topic/uek-4.1/upstream-cherry-picks' of git://ca-git.us.oracle.com/linux-uek:
NVMe: Setup max hardware sector count to 512KB
intel_pstate: enable HWP per CPU
ib/core: init shared-pd ref count to 1, and add cleanup
When shpd is created it is already referred to by parent 'pd',
so shpd->shared should be '1' initially (and not '0');
otherwise, the 'shpd' memory may get freed/reallocated
while it is still being referred to by one last pd.
Additionally, add shared-pd cleanup to ucontext cleanup flow.
Allen Pais [Thu, 14 May 2015 17:30:21 +0000 (23:00 +0530)]
sparc64: enable dtrace support for sparc64 in the spec file
Signed-off-by: Allen Pais <allen.pais@oracle.com>
(cherry picked from commit 701b65eba862955a458ab6b1ebb4f82125d12d44) Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Allen Pais [Wed, 6 May 2015 14:32:43 +0000 (20:02 +0530)]
sparc64: kernel-uek.spec update to support sparc.
Signed-off-by: Allen Pais <allen.pais@oracle.com>
(cherry picked from commit 4ef9d973f49d3e451c56b32f2c7bdf1473d77d84) Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Allen Pais [Fri, 8 May 2015 13:32:58 +0000 (19:02 +0530)]
sparc64: uek4 debug config for sparc64
Signed-off-by: Allen Pais <allen.pais@oracle.com>
(cherry picked from commit 3a9940a9ebadb5e3c0e9722658a47ac8438acdb5) Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Allen Pais [Wed, 6 May 2015 14:29:24 +0000 (19:59 +0530)]
sparc64: uek4 config for sparc64
Signed-off-by: Allen Pais <allen.pais@oracle.com>
(cherry picked from commit 025a9097b06f5ef7a3a0a9333699c2623496dbce) Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Merge branch '4.1_sparc' of git://ca-git.us.oracle.com/linux-uek-apais into topic/uek-4.1/sparc
* '4.1_sparc' of git://ca-git.us.oracle.com/linux-uek-apais: (25 commits)
lib/iommu-common.c: do not use 0xffffffffffffffffl for computing align_mask
sparc64: use ENTRY/ENDPROC in VISsave
SPARC64: PORT LDOMS TO UEK4
Fix incorrect ASI_ST_BLKINIT_MRU_S value
sparc64: perf: Use UREG_FP rather than UREG_I6
sparc64: perf: Add sanity checking on addresses in user stack
sparc64: Convert BUG_ON to warning
sparc: perf: Disable pagefaults while walking userspace stacks
sparc: time: Replace update_persistent_clock() with CONFIG_RTC_SYSTOHC
PCI: Set under_pref for mem64 resource of pcie device
sparc/PCI: Add mem64 resource parsing for root bus
PCI: Add pci_bus_addr_t
sparc64: Fix userspace FPU register corruptions.
sparc64: using 2048 as default for number of CPUS (cherry picked from commit 578ddb2512a5c908cd17ef8cbc43ff78dd399afd)
sparc64: iommu-common build error fix (cherry picked from commit accb4c6276793b991c6382bf57a58b40ea17eb11)
sparc64: fix Setup sysfs to mark LDOM sockets build error (cherry picked from commit 59be02427bfcac6c904ddd1374c35d63155b82d4)
sparc64: mmap fixed and shared
sparc64: restore TIF_FREEZE flag for sparc
sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly
sparc: Revert generic IOMMU allocator.
...
Sowmini Varadhan [Thu, 6 Aug 2015 22:46:39 +0000 (15:46 -0700)]
lib/iommu-common.c: do not use 0xffffffffffffffffl for computing align_mask
Using a 64 bit constant generates "warning: integer constant is too
large for 'long' type" on 32 bit platforms. Instead use ~0ul and
BITS_PER_LONG.
Detected by Andrew Morton on ARMD.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: David S. Miller <davem@davemloft.net> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 447f6a95a9c80da7faaec3e66e656eab8f262640) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 73958c651fbf70d8d8bf2a60b871af5f7a2e3199) Signed-off-by: Allen Pais <allen.pais@oracle.com>
uek-rom: config: Unset CONFIG_NFS_USE_LEGACY_DNS for OL7
The userland nfs-utils needs the kernel to do resolver queries.
In order to enable this functionality, this config option needs to
match what RHCK uses (which is enabled on OL6, disabled on OL7).
Linux in box NVMe driver does not handle 0 MDTS as expected
•0 MDTS - the drive can accept any request size.
•The device driver set up max hardware sector size by
BLK_SAFE_MAX_SECTORS or 124KB.
•Every IO size greater than 124KB is splitted by 124KB and remainder.
David Ahern [Mon, 15 Jun 2015 20:15:45 +0000 (16:15 -0400)]
sparc64: perf: Add sanity checking on addresses in user stack
Processes are getting killed (sigbus or segv) while walking userspace
callchains when using perf. In some instances I have seen ufp = 0x7ff
which does not seem like a proper stack address.
This patch adds a function to run validity checks against the address
before attempting the copy_from_user. The checks are copied from the
x86 version as a start point with the addition of a 4-byte alignment
check.
David Ahern [Mon, 15 Jun 2015 20:15:44 +0000 (16:15 -0400)]
sparc64: Convert BUG_ON to warning
Pagefault handling has a BUG_ON path that panics the system. Convert it to
a warning instead. There is no need to bring down the system for this kind
of failure.
The following was hit while running:
perf sched record -g -- make -j 16
David Ahern [Mon, 15 Jun 2015 20:15:43 +0000 (16:15 -0400)]
sparc: perf: Disable pagefaults while walking userspace stacks
Page faults generated walking userspace stacks can call schedule to switch
out the task. When collecting callchains for scheduler tracepoints this
causes a deadlock as the tracepoints can be hit with the runqueue lock held:
[ 8138.159054] WARNING: CPU: 758 PID: 12488 at /opt/dahern/linux.git/arch/sparc/kernel/nmi.c:80 perfctr_irq+0x1f8/0x2b4()
[ 8138.203152] Watchdog detected hard LOCKUP on cpu 758
All the bridges 64-bit resource have pref bit, but the device resource does not
have pref set, then we can not find parent for the device resource,
as we can not put non-pref mem under pref mem.
According to pcie spec errta
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13, in some case it is ok to mark some as pref.
Only set pref for 64bit mmio when the entire path from the host to the adapter is
over PCI Express.
The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA
addresses, i.e., bus addresses returned via the DMA API (dma_map_single(),
etc.), while the PCI core assumed dma_addr_t could hold *any* bus address,
including raw BAR values. On sparc64, all DMA addresses fit in 32 bits, so
dma_addr_t is a 32-bit type. However, BAR values can be 64 bits wide, so
they don't fit in a dma_addr_t. d63e2e1f3df9 added new checking that
tripped over this mismatch.
Add pci_bus_addr_t, which is wide enough to hold any PCI bus address,
including both raw BAR values and DMA addresses. This will be 64 bits
on 64-bit platforms and on platforms with a 64-bit dma_addr_t. Then
dma_addr_t only needs to be wide enough to hold addresses from the DMA API.
If we have a series of events from userpsace, with %fprs=FPRS_FEF,
like follows:
ETRAP
ETRAP
VIS_ENTRY(fprs=0x4)
VIS_EXIT
RTRAP (kernel FPU restore with fpu_saved=0x4)
RTRAP
We will not restore the user registers that were clobbered by the FPU
using kernel code in the inner-most trap.
Traps allocate FPU save slots in the thread struct, and FPU using
sequences save the "dirty" FPU registers only.
This works at the initial trap level because all of the registers
get recorded into the top-level FPU save area, and we'll return
to userspace with the FPU disabled so that any FPU use by the user
will take an FPU disabled trap wherein we'll load the registers
back up properly.
But this is not how trap returns from kernel to kernel operate.
The simplest fix for this bug is to always save all FPU register state
for anything other than the top-most FPU save area.
Getting rid of the optimized inner-slot FPU saving code ends up
making VISEntryHalf degenerate into plain VISEntry.
Longer term we need to do something smarter to reinstate the partial
save optimizations. Perhaps the fundament error is having trap entry
and exit allocate FPU save slots and restore register state. Instead,
the VISEntry et al. calls should be doing that work.
This bug is about two decades old.
Reported-by: James Y Knight <jyknight@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b75513b0f1c734b1e084a6e9952ea6260d4724e3)
bob picco [Thu, 25 Jun 2015 00:10:18 +0000 (17:10 -0700)]
sparc64: mmap fixed and shared
Older sparc64 must have a VAC because there is concern that mmapping fixed
and shared with incorrect align would cause cache aliases. To my knowledge
this is not an issue for sun4v. I will eventually research this.
The patch appears required for uek4 too.
We will enforce the rigid alignment condition only for tlb_type != hypervisor.
sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly
The current sparc kernel has no representation for sockets though tools
like lscpu can pull this from sysfs. This patch walks the machine
description cache and socket hierarchy and marks sockets as well as cores
and threads such that a representative sysfs is created by
drivers/base/topology.c.
Before this patch:
$ lscpu
Architecture: sparc64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Big Endian
CPU(s): 1024
On-line CPU(s) list: 0-1023
Thread(s) per core: 8
Core(s) per socket: 1 <--- wrong
Socket(s): 128 <--- wrong
NUMA node(s): 4
NUMA node0 CPU(s): 0-255
NUMA node1 CPU(s): 256-511
NUMA node2 CPU(s): 512-767
NUMA node3 CPU(s): 768-1023
After this patch:
$ lscpu
Architecture: sparc64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Big Endian
CPU(s): 1024
On-line CPU(s) list: 0-1023
Thread(s) per core: 8
Core(s) per socket: 32
Socket(s): 4
NUMA node(s): 4
NUMA node0 CPU(s): 0-255
NUMA node1 CPU(s): 256-511
NUMA node2 CPU(s): 512-767
NUMA node3 CPU(s): 768-1023
Most of this patch was done by Chris with updates by David.
Signed-off-by: Chris Hyser <chris.hyser@oracle.com> Signed-off-by: David Ahern <david.ahern@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit acc455cffa75070d55e74fc7802b49edbc080e92)
Conflicts:
arch/sparc/include/asm/cpudata_64.h
arch/sparc/kernel/mdesc.c
arch/sparc/kernel/smp_64.c Signed-off-by: Allen Pais <allen.pais@oracle.com>
(cherry picked from commit bd1039234cf41d0afd35f8e9a302eac9c344d18d)
Allen Pais [Wed, 7 Jan 2015 12:36:22 +0000 (18:06 +0530)]
sparc64: Setup sysfs to mark LDOM sockets, cores and threads correctly.
The current sparc kernel has no representation for sockets (i.e. a 3rd level
cache shared by cores) though tools like lscpu can pull this from sysfs. This
patch walks the LDOM MD (machine description) cache hierarchy structure and
marks sockets as well as cores and threads such that a representative sysfs is
created by drivers/base/topology.c.
Allen Pais [Fri, 2 Jan 2015 05:47:00 +0000 (11:17 +0530)]
sparc64: prevent solaris control domain warnings about Domain Service handles
Solaris created its own protocol on top of domain service registration. This
matters because the control domain that linux is talking to is Solaris. The
hypervisor specs say that the handle used for service identification is simply
an opaque 64 bit number. The only constraint is that a handle never be used
twice (within a reasonable time frame) to prevent connection to a prior stale
registered handle. Solaris on the other hand reserves the bit 0x80000000 to
indicate what it calls client registration requests. These registration requests
are sent to the guest domain to prod it to send its own registration requests to
the control domain.
When a guest (linux in this case) sends its own registration requests with this
bit set, Solaris assumes that these come from clients running in the guest that
should not do this since there can only be one control domain. Linux not
knowing this uses the top 32 bits as a quick lookup index and sets the bottom 32
bits based off jiffies. Of course there are times when a handle is constructed
with the Solaris client bit not set and everything appears to work correctly
with no errors or warnings and times when the client bit is set and everything
works except the Solaris kernel puts a bunch of warnings into its dmesg buffer.
The fix is literally 1 character, changing the mask used to grab the bottom 32
bits of sched_clock() (jiffy based) to use only the bottom 31 bits. Halving the
roll-over time should not be an issue. Worse case additional jiffy bits can be
shifted into the upper 32 bits of the handle.
Domain service registration intermittently fails. Though using “reliable"
LDC communication, this only guarantees the data, not delivery. Analysis
indicated a timing issue that varies between boots. LDOM domain service
architecture is now sufficiently complicated that packets (domain service
registration requests in this case) do apparently get lost, the symptoms
being receiving neither an ACK or a NACK on the initial service registration
request.
This patch uses a timer and retries with delay up to N (currently 5) times
any requests that went unacknowledged, positively or negatively, before
reporting a failed registration attempt. Using timer with callback allows early
boot to progress as normal versus spinning in a loop. Also clean up of
./script/checkpatch.pl warnings and errors in ds.c.
Allen Pais [Fri, 2 Jan 2015 05:18:41 +0000 (10:48 +0530)]
sparc64: __init code no longer called during non __init
mdesc_update calling __init memory free code through a pointer at
non-init time. Since text page was already given back and reused
this results in an illegal instruction trap. Was not caught by
linker section mismatch checks due to pointer indirection.
This patch NULL's out mops pointer after __init time and then
checks for non-NULL before calling mops->free.
Signed-off-by: Chris Hyser <chris.hyser@oracle.com> Acked-by: Dave Kleikamp <dave.kleikamp@oracle.com> Acked-by: Bob Picco <bob.picco@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
(cherry picked from commit 6dbae4a0137d7855472c4845b5db11cffa32efc1)
(cherry picked from commit f0673a413f04de21963ab7f3912eb9a84c52c66e)
ocfs2_setattr called by chmod command holds cluster wide inode lock
(Orabug 21685187) when calling posix_acl_chmod. This
latter function in turn calls ocfs2_iop_get_acl and ocfs2_iop_set_acl.
These two are also called directly from vfs layer for getfacl/setfacl
commands and therefore acquire the cluster wide inode lock. If a remote
conversion request comes after the first inode lock in ocfs2_setattr,
OCFS2_LOCK_BLOCKED will be set in l_flags. This will cause the second
call to inode lock from the ocfs2_iop_get|set_acl() to block indefinetly.
The new flag OCFS2_LOCK_RECURSIVE will be used to prevent this blocking.
HWP previously was only enabled at driver load time, on the boot
CPU, however, HWP must be enabled per package. Move the code to
enable HWP to the cpufreq driver init path so that it will be
called per CPU.
Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Tested-by: David Zhuang <david.zhuang@oracle.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit ba88d4338f226766f510e207911dde8c1875e072) Signed-off-by: Brian Maly <brian.maly@oracle.com>
Conflicts:
drivers/cpufreq/intel_pstate.c Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Ryan Ding [Mon, 7 Sep 2015 05:38:00 +0000 (13:38 +0800)]
ocfs2: direct write will call ocfs2_rw_unlock() twice when doing aio+dio
ocfs2_file_write_iter() is usng the wrong return value ('written'). This
will cause ocfs2_rw_unlock() be called both in write_iter & end_io,
triggering a BUG_ON.
This issue was introduced by commit 7da839c47589 ("ocfs2: use
__generic_file_write_iter()").
Orabug: 21612107 Fixes: 7da839c47589 ("ocfs2: use __generic_file_write_iter()") Signed-off-by: Ryan Ding <ryan.ding@oracle.com> Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit aa1057b3dec478b20c77bad07442318ae36d893c)
This bug in mainline code is pointed out by Mark Fasheh. When ocfs2_iop_set_acl
and ocfs2_iop_ge_acl are entered from VFS layer, inode lock is not held. This
seems to be regression from older kernels. The patch is to fix that.
Some time ago, chmod command had been executed. As result, the following call
chain left the inode cluster lock in PR state, latter on causing the assert.
system_call_fastpath
-> my_chmod
-> sys_chmod
-> sys_fchmodat
-> notify_change
-> ocfs2_setattr
-> posix_acl_chmod
-> ocfs2_iop_set_acl
-> ocfs2_set_acl
-> ocfs2_acl_set_mode
Here is how.
1119 int ocfs2_setattr(struct dentry *dentry, struct iattr *attr)
1120 {
1247 ocfs2_inode_unlock(inode, 1); <<< WRONG thing to do.
..
1258 if (!status && attr->ia_valid & ATTR_MODE) {
1259 status = posix_acl_chmod(inode, inode->i_mode);
224 int ocfs2_set_acl(handle_t *handle,
225 struct inode *inode, ...
231 {
..
252 ret = ocfs2_acl_set_mode(inode, di_bh,
253 handle, mode);
168 static int ocfs2_acl_set_mode(struct inode *inode, struct buffer_head ...
170 {
183 if (handle == NULL) {
>>> BUG: inode lock not held in ex at this point <<<
184 handle = ocfs2_start_trans(OCFS2_SB(inode->i_sb),
185 OCFS2_INODE_UPDATE_CREDITS);
ocfs2_setattr.#1247 we unlock and at #1259 call posix_acl_chmod. When we reach
ocfs2_acl_set_mode.#181 and do trans, the inode cluster lock is not held in EX
mode (it should be). How this could have happended?
We are the lock master, were holding lock EX and have released it in
ocfs2_setattr.#1247. Note that there are no holders of this lock at
this point. Another node needs the lock in PR, and we downconvert from
EX to PR. So the inode lock is PR when do the trans in
ocfs2_acl_set_mode.#184. The trans stays in core (not flushed to disc).
Now another node want the lock in EX, downconvert thread gets kicked (the
one that tripped assert abovt), finds an unflushed trans but the lock is
not EX (it is PR). If the lock was at EX, it would have flushed the trans
ocfs2_ci_checkpointed -> ocfs2_start_checkpoint before downconverting (to NULL)
for the request.
ocfs2_setattr must not drop inode lock ex in this code path. If it does,
takes it again before the trans, say in ocfs2_set_acl, another cluster node can
get in between, execute another setattr, overwriting the one in progress
on this node, resulting in a mode acl size combo that is a mix of the two.
Merge branch 'topic/uek-4.1/ofed' of git://ca-git.us.oracle.com/linux-uek into uek/uek-4.1
* 'topic/uek-4.1/ofed' of git://ca-git.us.oracle.com/linux-uek:
IB/rds_rdma: unloading of ofed stack causes page fault panic
RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.
RDS-TCP: Make RDS-TCP work correctly when it is set up in a netns other than init_net
net: sk_clone_lock() should only do get_net() if the parent is not a kernel socket
net: Modify sk_alloc to not reference count the netns of kernel sockets.
net: Pass kern from net_proto_family.create to sk_alloc
net: Add a struct net parameter to sock_create_kern
Nick Alcock [Thu, 3 Sep 2015 15:42:09 +0000 (16:42 +0100)]
kallsyms: unbreak kallmodsyms after CONFIG_KALLMODSYMS addition
The recent addition of CONFIG_KALLMODSYMS In 28df3b99a7 had the effect
of entirely disabling all module info in /proc/kallmodsyms, thus
breaking all module-specific symbol lookups from DTrace.
This is because you can't use a CONFIG_ symbol in a HOSTCC-compiled
program without including autoconf.h by hand, and we weren't, so
scripts/kallsyms.c always acted as if CONFIG_KALLMODSYMS was turned
off and didn't populate the kallsyms_modules or kallsyms_symbol_modules
tables.
(Including autoconf.h in this context is safe, because kallsyms.c never
gets compiled until after some *config target has run. Other build
tools in a similar position, such as modpost, already do this.)
Orabug: 21539840 Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Acked-by: Kris Van Hees <kris.van.hees@oracle.com>
Nick Alcock [Sat, 15 Aug 2015 11:18:14 +0000 (12:18 +0100)]
kallsyms: de-ifdef kallmodsyms
CONFIG_KALLMODSYMS is a bit ugly because of the burden of ifdefs. It's
hard to remove them from scripts/kallsyms.c, but kernel/kallsyms.c doesn't
need any, since even when CONFIG_KALLMODSYMS is on it does not pull in any
extra build dependencies in and of itself: it just needs to arrange to not
create the kallmodsyms /proc node when the config option is turned off.
This will have the effect of disabling /proc/kallmodsyms when
CONFIG_KALLMODSYMS=n, without cluttering up the code with so many
ifdefs. (We still need one to populate the node in the first place.)
We also reverse the code motion we did earlier to make the other ifdefs
easier to insert.
Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Orabug: 21539840
dtrace: use syscall_get_nr() to obtain syscall number
Rather than trying to get the syscall number directly from %rax on
x86_64, which is error prone due to compiler changes causing that
register to get clobbered, we use the syscall_get_nr() function to
get the same information.
No need to use WARN_TAINT_ONCE to generate a such big noise if this is
not a critical error for kernel. DCA driver could print out a debug
messages then quit quietly.
If this is a real BIOS bug, please ignore this patch. Let's transfer
this issue to BIOS guys.
Merge branch 'topic/uek-4.1/ofed.rds-p2' into topic/uek-4.1/ofed
* topic/uek-4.1/ofed.rds-p2:
IB/rds_rdma: unloading of ofed stack causes page fault panic
RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.
RDS-TCP: Make RDS-TCP work correctly when it is set up in a netns other than init_net
Rama Nichanamatlu [Thu, 11 Jun 2015 17:43:54 +0000 (10:43 -0700)]
IB/rds_rdma: unloading of ofed stack causes page fault panic
This issue surfaced at the tail end of OFED functional automatic test suite
while unloading ofed modules resulting in following stack trace:
BUG: unable to handle kernel paging request at ffffffffa0abd1a0
IP: [<ffffffffa0abd1a0>] 0xffffffffa0abd1a0
Sowmini Varadhan [Fri, 28 Aug 2015 14:09:04 +0000 (10:09 -0400)]
RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.
Register pernet subsys init/stop functions that will set up
and tear down per-net RDS-TCP listen endpoints. Unregister
pernet subusys functions on 'modprobe -r' to clean up these
end points.
Enable keepalive on both accept and connect socket endpoints.
The keepalive timer expiration will ensure that client socket
endpoints will be removed as appropriate from the netns when
an interface is removed from a namespace.
Register a device notifier callback that will clean up all
sockets (and thus avoid the need to wait for keepalive timeout)
when the loopback device is unregistered from the netns indicating
that the netns is getting deleted.
Sowmini Varadhan [Fri, 28 Aug 2015 11:16:01 +0000 (07:16 -0400)]
RDS-TCP: Make RDS-TCP work correctly when it is set up in a netns other than init_net
Open the sockets calling sock_create_kern() with the correct struct net
pointer, and use that struct net pointer when verifying the
address passed to rds_bind().
Sowmini Varadhan [Fri, 28 Aug 2015 00:57:24 +0000 (20:57 -0400)]
net: sk_clone_lock() should only do get_net() if the parent is not a kernel socket
The newsk returned by sk_clone_lock should hold a get_net()
reference if, and only if, the parent is not a kernel socket
(making this similar to sk_alloc()).
E.g,. for the SYN_RECV path, tcp_v4_syn_recv_sock->..inet_csk_clone_lock
sets up the syn_recv newsk from sk_clone_lock. When the parent (listen)
socket is a kernel socket (defined in sk_alloc() as having
sk_net_refcnt == 0), then the newsk should also have a 0 sk_net_refcnt
and should not hold a get_net() reference.
Fixes: 26abe14379f8 ("net: Modify sk_alloc to not reference count the
netns of kernel sockets.")
Acked-by: Eric Dumazet <edumazet@google.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Sowmini Varadhan [Thu, 27 Aug 2015 23:23:26 +0000 (19:23 -0400)]
net: Modify sk_alloc to not reference count the netns of kernel sockets.
Now that sk_alloc knows when a kernel socket is being allocated modify
it to not reference count the network namespace of kernel sockets.
Keep track of if a socket needs reference counting by adding a flag to
struct sock called sk_net_refcnt.
Update all of the callers of sock_create_kern to stop using
sk_change_net and sk_release_kernel as those hacks are no longer
needed, to avoid reference counting a kernel socket.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Sowmini Varadhan [Thu, 27 Aug 2015 21:22:00 +0000 (17:22 -0400)]
net: Pass kern from net_proto_family.create to sk_alloc
In preparation for changing how struct net is refcounted
on kernel sockets pass the knowledge that we are creating
a kernel socket from sock_create_kern through to sk_alloc.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Santosh Shilimkar [Fri, 28 Aug 2015 17:56:32 +0000 (10:56 -0700)]
Merge branch 'topic/uek-4.1/drivers' of git://ca-git.us.oracle.com/linux-uek into uek/uek-4.1
* 'topic/uek-4.1/drivers' of git://ca-git.us.oracle.com/linux-uek: (61 commits)
i40e/i40evf: Bump version to 1.3.6 for i40e and 1.3.2 for i40evf
i40e: Refine an error message to avoid confusion
i40e/i40evf: Add support for pre-allocated pages for PD
i40evf: add MAC address filter in open, not init
i40evf: don't delete all the filters
i40e: un-disable VF after reset
i40e: do a proper reset when disabling a VF
i40e: correctly program filters for VFs
i40e/i40evf: Update the admin queue command header
i40e: Remove incorrect #ifdef's
i40e: ignore duplicate port VLAN requests
i40evf: Allow for an abundance of vectors
i40e/i40evf: improve Tx performance with a small tweak
i40e/i40evf: Update Flex-10 related device/function capabilities
i40e/i40evf: Add stats to track FD ATR and SB dynamic enable state
i40e: Implement ndo_features_check()
i40evf: don't configure unused RSS queues
i40evf: fix panic during MTU change
i40e: Bump version to 1.3.4
i40e/i40evf: remove time_stamp member
...
Santosh Shilimkar [Fri, 28 Aug 2015 17:56:10 +0000 (10:56 -0700)]
Merge branch 'topic/uek-4.1/upstream-cherry-picks' of git://ca-git.us.oracle.com/linux-uek into uek/uek-4.1
* 'topic/uek-4.1/upstream-cherry-picks' of git://ca-git.us.oracle.com/linux-uek:
nfs: take extra reference to fl->fl_file when running a LOCKU operation
mm: madvise allow remove operation for hugetlbfs
mmotm: build fix hugetlbfs fallocate if not CONFIG_NUMA
hugetlbfs: add hugetlbfs_fallocate()
hugetlbfs: New huge_add_to_page_cache helper routine
mm/hugetlb: alloc_huge_page handle areas hole punched by fallocate
mm/hugetlb: vma_has_reserves() needs to handle fallocate hole punch
mm/hugetlb.c: make vma_has_reserves() return bool
hugetlbfs: truncate_hugepages() takes a range of pages
hugetlbfs: hugetlb_vmtruncate_list() needs to take a range to delete
mm/hugetlb: expose hugetlb fault mutex for use by fallocate
mm/hugetlb: add region_del() to delete a specific range of entries
mm-hugetlb-add-cache-of-descriptors-to-resv_map-for-region_add-fix
mm/hugetlb: add cache of descriptors to resv_map for region_add
mm/hugetlb: handle races in alloc_huge_page and hugetlb_reserve_pages
mm/hugetlb: compute/return the number of regions added by region_add()
mm/hugetlb: document the reserve map/region tracking routines
The problem is almost exactly the same as the one fixed by feaff8e5b2cf.
We must take a reference to the struct file when running the LOCKU
compound to prevent the final fput from running until the operation is
complete.
Reported-by: Jean Spector <jean@primarydata.com> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Cc: stable@vger.kernel.org Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Orabug: 21687670
(cherry picked from mainline commit db2efec0caba4f81a22d95a34da640b86c313c8e) Acked-by: Chuck Anderson <chuck.anderson@oracle.com>
NFS on a 2 node ocfs2 cluster each node exporting dir. The lock causing
the hang is the global bit map inode lock. Node 1 is master, has
the lock granted in PR mode; Node 2 is in the converting list (PR ->
EX). There are no holders of the lock on the master node so it should
downconvert to NL and grant EX to node 2 but that does not happen.
BLOCKED + QUEUED in lock res are set and it is on osb blocked list.
Threads are waiting in __ocfs2_cluster_lock on BLOCKED. One thread wants
EX, rest want PR. So it is as though the downconvert thread needs to be
kicked to complete the conv.
The hang is caused by an EX req coming into __ocfs2_cluster_lock on
the heels of a PR req after it sets BUSY (drops l_lock, releasing EX
thread), forcing the incoming EX to wait on BUSY without doing anything.
PR has called ocfs2_dlm_lock, which sets the node 1 lock from NL ->
PR, queues ast.
At this time, upconvert (PR ->EX) arrives from node 2, finds conflict with
node 1 lock in PR, so the lock res is put on dlm thread's dirty listt.
After ret from ocf2_dlm_lock, PR thread now waits behind EX on BUSY till
awoken by ast.
Now it is dlm_thread that serially runs dlm_shuffle_lists, ast, bast,
in that order. dlm_shuffle_lists ques a bast on behalf of node 2
(which will be run by dlm_thread right after the ast). ast does its
part, sets UPCONVERT_FINISHING, clears BUSY and wakes its waiters. Next,
dlm_thread runs bast. It sets BLOCKED and kicks dc thread. dc thread
runs ocfs2_unblock_lock, but since UPCONVERT_FINISHING set, skips doing
anything and reques.
Inside of __ocfs2_cluster_lock, since EX has been waiting on BUSY ahead
of PR, it wakes up first, finds BLOCKED set and skips doing anything
but clearing UPCONVERT_FINISHING (which was actually "meant" for the
PR thread), and this time waits on BLOCKED. Next, the PR thread comes
out of wait but since UPCONVERT_FINISHING is not set, it skips updating
the l_ro_holders and goes straight to wait on BLOCKED. So there, we
have a hang! Threads in __ocfs2_cluster_lock wait on BLOCKED, lock
res in osb blocked list. Only when dc thread is awoken, it will run
ocfs2_unblock_lock and things will unhang.
One way to fix this is to wake the dc thread on the flag after clearing
UPCONVERT_FINISHING
Change-ID: I84573d9fa51effc5b29bf5b8c74e3cc8b2673f48 Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com> Tested-by: Jim Young <james.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 76945bf9ff8a2433f1efb777ec64475c1eec08ab) Signed-off-by: Brian Maly <brian.maly@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Change a warning message to indicate what may have really happened when
the init_shared_code call fails.
Change-ID: I616ace40fed120d0dec86dfc91ab2d7cde466904 Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com> Tested-by: Jim Young <james.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit b2a75c5819ec910f430a2ff12fec6cce202899a0) Signed-off-by: Brian Maly <brian.maly@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
The i40e_add_pd_table_entry() routine is being modified to handle both
cases where a backing page is passed and where backing page is allocated
in i40e_add_pd_table_entry().
For PBLE resource management, it is more efficient for it to manage its
backing pages. For VF, PBLE backing page addresses will be send to PF
driver for PBLE resource.
The i40e_remove_pd_bp() is also modified to not free pre-allocated pages and
free only ones which were allocated in i40e_add_pd_table_entry().
Change-ID: Ie673f0403f22979e9406f5a94048dceb91bcf9a8 Signed-off-by: Faisal Latif <faisal.latif@intel.com> Tested-by: Jim Young <james.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 3bbf0faa90cb8d541d8b2ce01610dcec6828bd00) Signed-off-by: Brian Maly <brian.maly@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
During close, all of the MAC filters are cleared, so the driver would be
unable to receive unicast packets after being closed and reopened.
Add the adapter's "hardware" MAC address filter in open, not init. This
ensures that the correct filter is present each time.
Change-ID: I51a11e9c1200139dab6f66a5353bd38c7d26f875 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Jim Young <james.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 44151cd32deb1074530f3beba51d535fa0887d9a) Signed-off-by: Brian Maly <brian.maly@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Due to an inverted conditional, the driver was marking all of its MAC
filters for deletion every time set_rx_mode was called. Depending upon
the timing of the calls to set_rx_mode and the processing of the admin
queue, the driver would (accidentally) end up with a varying number of
functional filters.
Correct this logic so that MAC filters are added and removed correctly.
Add a check for the driver's "hardware" MAC address so that this filter
doesn't get removed incorrectly.
Change-ID: Ib3e7c4a5b53df6835f164fe44cb778cb71f8aff8 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Jim Young <james.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 68ef169204e3a88ea4823645038d5496f66200f6) Signed-off-by: Brian Maly <brian.maly@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
When a VF is disabled, there is no way for it to recover until either
the PF driver is reloaded or SR-IOV is disabled and enabled. To correct
this, enable the VF after a successful reset.
Change-ID: I9e0788476c4d53d5407961b503febdfff2b8a7c6 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Jim Young <james.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 5b8f8505d37c63d492391e5fafcd43332671b36b) Signed-off-by: Brian Maly <brian.maly@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
The VF disable code was just whanging on the reset bit without properly
cleaning up the VF, which would leave the VF in an indeterminate state
from which it could not recover. Fix this by notifying the VF and then
by calling the normal VF reset routine.
Change-ID: I862b9dfa919368773cbdc212b805b520db2f7430 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Jim Young <james.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 54f455eeb56c0ab92db87bed6bd767d206d9e743) Signed-off-by: Brian Maly <brian.maly@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
MAC filters for VFs were being programmed with 0 for the VLAN value when
there was no VLAN assigned. This is incorrect and actually assigns the
VF to VLAN 0. Instead, we must use -1 to indicate that no VLAN is in
use. This change programs the filters correctly and gets rid of a bogus
error message when setting a port VLAN on an active VF.
Change-ID: Ica9a9906d768405377ff3308e27f7d0b5b2ea96e Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Jim Young <james.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit e995163cdcf9b70c7840a8d6a7ea7c0ce81c761b) Signed-off-by: Brian Maly <brian.maly@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Change-ID: Ib031c86cc6cab78e5aa44c64d8ce5474be8d7e42 Signed-off-by: Greg Rose <gregory.v.rose@intel.com> Tested-by: Jim Young <james.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit cb2f65bc0c64015e8fa45fe1065ad241bf31a994) Signed-off-by: Brian Maly <brian.maly@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
This patch removes some #ifdef's that should not be there. They
were stopping code that is needed from being compiled in.
With these #ifdef's removed, changes are needed in the driver
to fix some compile errors: adding missing parameters to
the definition of ndo_bridge_setlink and a ndo_dflt_brige_getlink call.
Change-ID: I5516614e1bc50b6bca0647cef971bc96161ba2de Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com> Tested-by: Jim Young <james.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 9df70b66418e284dc1e7f272ac445c1d1e990b97) Signed-off-by: Brian Maly <brian.maly@oracle.com>
Conflicts:
drivers/net/ethernet/intel/i40e/i40e_main.c Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
If user attempts to set a port VLAN on a VF that already has the same
port VLAN configured, the driver will go through a completely
unnecessary flurry of filter removals and filter adds. Just check for
this condition and return success instead of doing a bunch of busywork.
Change-ID: Ia1a9e83e6ed48b3f4658bc20dfc6af0cf525d54a Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Jim Young <james.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 85927ec1b369c880407aa82eba70d49c04c35062) Signed-off-by: Brian Maly <brian.maly@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
The driver currently only maps TX and RX queues to a single MSI-X vector
per queue pair if there are exactly enough vectors for this.
Unfortunately, if we have too many vectors it will fail and allocate
queues to vectors in a suboptimal manner. Change the condition check to
allow for excess vectors. In this case, the extras just won't be used.
Change-ID: I23e1e2955c64739c86612db88a25583e6a7e0b17 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Jim Young <james.m.young@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 973371da4d66b96736143bd3f2b2ff2331faae8f) Signed-off-by: Brian Maly <brian.maly@oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
projects / users / jedix / linux-maple.git / log