When both the parent and send snapshots have a directory inode with the
same number but different generations (therefore they are different
inodes) and both have an entry with the same name, an incremental send
stream will contain an invalid rmdir operation that refers to the
orphanized name of the inode from the parent snapshot.
The following example scenario shows how this happens.
Parent snapshot:
.
|---- d259_old/ (ino 259, gen 9)
| |---- d1/ (ino 258, gen 9)
|
|---- f (ino 257, gen 9)
Send snapshot:
.
|---- d258/ (ino 258, gen 7)
|---- d259/ (ino 259, gen 7)
|---- d1/ (ino 257, gen 7)
When the kernel is processing inode 258 it notices that in both snapshots
there is an inode numbered 259 that is a parent of an inode 258. However
it ignores the fact that the inodes numbered 259 have different generations
in both snapshots, which means they are effectively different inodes.
Then it checks that both inodes 259 have a dentry named "d1" and because
of that it issues a rmdir operation with orphanized name of the inode 258
from the parent snapshot. This happens at send.c:process_record_refs(),
which calls send.c:did_overwrite_first_ref() that returns true and because
of that later on at process_recorded_refs() such rmdir operation is issued
because the inode being currently processed (258) is a directory and it
was deleted in the send snapshot (and replaced with another inode that has
the same number and is a directory too).
Fix this issue by comparing the generations of parent directory inodes
that have the same number and make send.c:did_overwrite_first_ref() when
the generations are different.
$ mkfs.btrfs -f /dev/sdc
$ mount /dev/sdc /mnt
$ mkdir /mnt/d1
$ mkdir /mnt/dir258
$ mkdir /mnt/dir259
$ mv /mnt/d1 /mnt/dir259/d1
$ btrfs subvolume snapshot -r /mnt /mnt/snap2
$ btrfs receive /mnt/ -f /tmp/1.snap
# Take note that once the filesystem is created, its current
# generation has value 7 so the inodes from the second snapshot all have
# a generation value of 7. And after receiving the first snapshot
# the filesystem is at a generation value of 10, because the call to
# create the second snapshot bumps the generation to 8 (the snapshot
# creation ioctl does a transaction commit), the receive command calls
# the snapshot creation ioctl to create the first snapshot, which bumps
# the filesystem's generation to 9, and finally when the receive
# operation finishes it calls an ioctl to transition the first snapshot
# (snap1) from RW mode to RO mode, which does another transaction commit
# and bumps the filesystem's generation to 10. This means all the inodes
# in the first snapshot (snap1) have a generation value of 9.
$ rm -f /tmp/1.snap
$ btrfs send /mnt/snap1 -f /tmp/1.snap
$ btrfs send -p /mnt/snap1 /mnt/snap2 -f /tmp/2.snap
$ umount /mnt
Signed-off-by: Robbie Ko <robbieko@synology.com> Reviewed-by: Filipe Manana <fdmanana@suse.com>
[Rewrote changelog to be more precise and clear] Signed-off-by: Filipe Manana <fdmanana@suse.com>
(cherry picked from commit 0191410158840d6176de3267daa4604ad6a773fb) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
The upstream commit 8e3b21b6dbf0 (x86/platform/uv/BAU: Cleanup
bau_operations declaration and instances) has declared the
bau_operations ops instance with __ro_after_init. It can be safely
removed now as "ops" is an already existing variable and also the code that
supports this "read-only after init" feature is not pulled in yet.
The upstream commit c74ba8b3480d (arch: Introduce post-init read-only
memory) and several of its associated commits introduce this feature
from 4.6 kernel. When this feature is pulled in, this commit can be
reverted to make "bau_operations ops" read-only.
Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Remove the WARNING message associated with multiple NMI handlers as
there are at least two that are legitimate. These are the KGDB and the
UV handlers and both want to be called if the NMI has not been claimed
by any other NMI handler.
Use of the UNKNOWN NMI call chain dramatically lowers the NMI call rate
when high frequency NMI tools are in use, notably the perf tools. It is
required on systems that cannot sustain a high NMI call rate without
adversely affecting the system operation.
Signed-off-by: Mike Travis <mike.travis@hpe.com> Reviewed-by: Dimitri Sivanich <dimitri.sivanich@hpe.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Russ Anderson <russ.anderson@hpe.com> Cc: Frank Ramsay <frank.ramsay@hpe.com> Cc: Tony Ernst <tony.ernst@hpe.com> Link: http://lkml.kernel.org/r/20170307210841.730959611@asylum.americas.sgi.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 0d443b70cc92d741cbc1dcbf1079897b3d8bc3cc) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
UV4 does not employ a software-timeout as in previous generations so a new
wait_completion routine without this logic is required. Certain completion
statuses require the AUX status bit in addition to ERROR and BUSY.
Add the read_status routine to construct the full completion status. Use
read_status in the uv4_wait_completion routine to handle all possible
completion statuses.
Signed-off-by: Andrew Banman <abanman@hpe.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: sivanich@hpe.com Cc: rja@hpe.com Cc: akpm@linux-foundation.org Link: http://lkml.kernel.org/r/1489077734-111753-7-git-send-email-abanman@hpe.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 2f2a033fb5819c393d65da9b6233e095f3690f15) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Remove the present wait_completion routine and add a function pointer by
the same name to the bau_operations struct. Rather than switching on the
UV hub version during message processing, set the architecture-specific
uv*_wait_completion during initialization.
The uv123_bau_ops struct must be split into uv1 and uv2_3 versions to
accommodate the corresponding wait_completion routines.
Signed-off-by: Andrew Banman <abanman@hpe.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: sivanich@hpe.com Cc: rja@hpe.com Cc: akpm@linux-foundation.org Link: http://lkml.kernel.org/r/1489077734-111753-6-git-send-email-abanman@hpe.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 2620bbbf1f4f187952fb35861f4473860c432728) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
The location of the ERROR and BUSY status bits depends on the descriptor
index, i.e. the CPU, of the message. Since this index does not change,
there is no need to calculate the mmr and index location during message
processing. The less work we do in the hot path the better.
Add status_mmr and status_index fields to bau_control and compute their
values during initialization. Add kerneldoc descriptions for the new
fields. Update uv*_wait_completion to use these fields rather than
receiving the information as parameters.
Signed-off-by: Andrew Banman <abanman@hpe.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: sivanich@hpe.com Cc: rja@hpe.com Cc: akpm@linux-foundation.org Link: http://lkml.kernel.org/r/1489077734-111753-5-git-send-email-abanman@hpe.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit dfeb28f068ff9cc4f714c7d1edaf61597ea1768b) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Move the bau_operations declaration after bau struct declarations so the
bau structs can be referenced when adding new functions to
bau_operations. That way we avoid forward declarations of the bau
structs.
Likewise, move uv*_bau_ops structs down to avoid forward declarations of
new functions defined in the same file. Declare these structs __initconst
since they are only used during initialization. Similarly, declare the
bau_operations ops instance __ro_after_init as it is read-only after
initialization.
This is a preparatory patch for adding wait_completion to bau_operations.
Signed-off-by: Andrew Banman <abanman@hpe.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: sivanich@hpe.com Cc: rja@hpe.com Cc: akpm@linux-foundation.org Link: http://lkml.kernel.org/r/1489077734-111753-4-git-send-email-abanman@hpe.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 8e3b21b6dbf0318d5b3a598572acc23f07189c40) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
On UV4, the destination agent verifies each message by checking the
descriptor qualifier field of the message payload. Messages without this
field set to 0x534749 will cause a hub error to assert. Split
bau_message_payload into uv1_2_3 and uv4 versions to account for the
different payload formats.
Enforce the size of each field by using the appropriate u** integer type.
Replace extraneous comments with KernelDoc comment.
Signed-off-by: Andrew Banman <abanman@hpe.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: sivanich@hpe.com Cc: rja@hpe.com Cc: akpm@linux-foundation.org Link: http://lkml.kernel.org/r/1489077734-111753-3-git-send-email-abanman@hpe.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit e9be36443cecda1be20b2cc3b891676ff2af9dff) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Writing to the software acknowledge clear register when there are no
pending messages causes a HUB error to assert. The original intent of this
write was to clear the pending bits before start of operation, but this is
an incorrect method and has been determined to be unnecessary.
Signed-off-by: Andrew Banman <abanman@hpe.com> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: akpm@linux-foundation.org Cc: rja@hpe.com Cc: sivanich@hpe.com Link: http://lkml.kernel.org/r/1487351269-181133-1-git-send-email-abanman@hpe.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 1b17c6df852851b40c3c27c66b8fa2fd99cf25d8) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
The IO and Abort latency counter count the time taken to complete
the IO and abort command into broad buckets. It is not intend for
performance measurement, just a debug stat.
current_max_io_time tries to keep tarck of the maximun time an IO
has taken to complete if it > 30sec, it just another debug stat.
Just a simple counter of number of check conditions encountered on
that host.
Signed-off-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
If SCSI-ML has already issued abort on a command i.e
FNIC_IOREQ_ABTS_PENDING is set and we get a IO completion avoid
this being flagged as out-of-order completion by setting the
FNIC_IO_DONE flag in fnic_fcpio_icmnd_cmpl_handler
Signed-off-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Vivek Goyal [Fri, 20 May 2016 13:04:26 +0000 (09:04 -0400)]
ovl: Do d_type check only if work dir creation was successful
d_type check requires successful creation of workdir as iterates
through work dir and expects work dir to be present in it. If that's
not the case, this check will always return d_type not supported even
if underlying filesystem might be supporting it.
So don't do this check if work dir creation failed in previous step.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
(cherry picked from commit 21765194cecf2e4514ad75244df459f188140a0f) Signed-off-by: Divya Indi <divya.indi@oracle.com>
Orabug: 25802620
Vivek Goyal [Mon, 22 Feb 2016 14:28:34 +0000 (09:28 -0500)]
ovl: Ensure upper filesystem supports d_type
In some instances xfs has been created with ftype=0 and there if a file
on lower fs is removed, overlay leaves a whiteout in upper fs but that
whiteout does not get filtered out and is visible to overlayfs users.
And reason it does not get filtered out because upper filesystem does
not report file type of whiteout as DT_CHR during iterate_dir().
So it seems to be a requirement that upper filesystem support d_type for
overlayfs to work properly. Do this check during mount and fail if d_type
is not supported.
Suggested-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
(cherry picked from commit 45aebeaf4f67468f76bedf62923a576a519a9b68) Signed-off-by: Divya Indi <divya.indi@oracle.com>
Orabug: 25802620
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Reviewed-by: Khalid Aziz <khalid.aziz@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Dave Aldridge [Fri, 3 Feb 2017 10:24:54 +0000 (02:24 -0800)]
sparc64: Stop performance counter before updating
This commit takes the fix as implemented in commit b36dd4d8040c and applies it to M8 devices. Original commit
message:
In order to reliably clear the PCRx.ov bit when updating a
performance counter value, we need to stop it counting first.
If we do not do this, then we can miss performance counter
overflow events.
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Dave Aldridge [Fri, 3 Feb 2017 14:38:46 +0000 (06:38 -0800)]
sparc64: Fix a race condition when stopping performance counters
This commit takes the fix as implemented in commit e5b7619e1de2 and applies it to M8 devices. Original commit
message:
When stopping a performance counter that is close to overflowing,
there is a race condition that can occur between writing to the
PCRx register to stop the counter (and also clearing the PCRx.ov
bit at the same time) vs the performance counter overflowing and
setting the PCRx.ov bit in the PCRx register.
The result of this race condition is that we occasionally miss
a performance counter overflow interrupt, which in turn leads
to incorrect event counting.
This race condition has been observed when counting cpu cycles.
To fix this issue when stopping a performance counter,
we simply allow it to continue counting and overflow before
stopping it. This allows the performance counter overflow
interrupt to be generated and acted upon.
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Allen Pais [Mon, 15 May 2017 13:46:23 +0000 (19:16 +0530)]
arch/sparc: Use new misaligned load instructions for memcpy and copy_from_user
Use the new instructions for Load Misaligned Integer and Load Misaligned
Integer Alternate space for M8 architecture.
Decide when to use FP or ldm based on the following condition.
In case of FP load/alignaddr logic, there is a fixed overhead of
FP save/restore regardless of memcpy length. But the overhead due to the
ldm instruction grows with the size of memcpy. With our tests noticed
that up to length about 4096, the ldm instructions performs significanty
better than the FP alignaddr/load logic. With that into consideration,
use the new ldm instructions for length of 4096 or less. For lengths
above 4096, we will continue to use FP alignaddr/load logic.
Added the fix noticed crypto key corruption while running AES crypto tests.
This is the same problem reported in NG4memcpy. The commit f4da3628dc7c
("sparc64: Fix FPU register corruption with AES crypto offload.") fixes
the problem. Ported these changes to M8memcpy and verified the fix.
TODO: Encoded the ldmx and ldmxa instruction for now. Our build servers
are not updated with latest M8 instruction set yet. We need to decode it
back to assembly mnemonics when these instructions are available.
Allen Pais [Mon, 15 May 2017 12:48:34 +0000 (18:18 +0530)]
arch/sparc: Add a separate kernel memcpy functions for M8
Add a dedicated kernel memory copy functions for M8 architecture.
Use M7memcpy functions from M7 architecture and update affected functions
to take advantage of new Load Misaligned load/store instructions.
Following functions are going to be affected.
memcpy, copy_from_user and copy_to_user.
Following functions will not change. Will remain same as M7.
clear_page, clear_user_page, memset and bzero.
Dave Aldridge [Fri, 2 Dec 2016 16:50:44 +0000 (08:50 -0800)]
sparc64: perf: make sure we do not set the 'picnht' bit in the PCR
Testing with the perf_fuzzer tool revealed an issue when the 'picnht' bit
was set in the Performance Control Register. Setting this bit means that
privileged software cannot access the PIC counter and we eventually end up
with messages of the form shown below, being reported.
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Dave Aldridge [Fri, 7 Oct 2016 14:57:50 +0000 (07:57 -0700)]
sparc64: perf: Fix the mapping between perf events and perf counters
Up until now, perf event[0] has been counted on perf counter[0],
perf event[1] on perf counter[1] etc. However, there is no reason why
this has to be the case. Infact, on SPARC-M8 some events can only be
counted on a sub set of the available perf counters, rather than all
the available perf counters. Whilst adding these perf counter
constraints for the SPARC-M8 it became apparent that some confusion
had crept into the existing code.
Some functions were making the assumption that the perf event index was
equivalent to the perf counter index. This commit fixes these assumptions,
and allows for the case where perf event[0] is not counted on
perf counter[0] etc.
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Allen Pais [Tue, 16 May 2017 07:14:47 +0000 (12:44 +0530)]
SPARC64: Enable IOMMU bypass for IB
This change enables IOMMU bypass for Infiniband devices to workaround
the rds-stress performance issue. The performance slowdown is only
seen with rds-stress test. This test generates rigorous amount of dma
map/unmap calls. Investigation shows that somewhere IOMMU/ATU code
doesn't scale and appears to be a bottleneck.
This is for uek4 only and not for upstream. When IOMMU/ATU issue gets
resolved, this workaround will be reverted.
Waiman Long [Wed, 2 Dec 2015 18:41:50 +0000 (13:41 -0500)]
sched/fair: Disable the task group load_avg update for the root_task_group
Currently, the update_tg_load_avg() function attempts to update the
tg's load_avg value whenever the load changes even for root_task_group
where the load_avg value will never be used. This patch will disable
the load_avg update when the given task group is the root_task_group.
Running a Java benchmark with noautogroup and a 4.3 kernel on a
16-socket IvyBridge-EX system, the amount of CPU time (as reported by
perf) consumed by task_tick_fair() which includes update_tg_load_avg()
decreased from 0.71% to 0.22%, a more than 3X reduction. The Max-jOPs
results also increased slightly from 983015 to 986449.
Atish Patra [Wed, 22 Mar 2017 22:22:01 +0000 (16:22 -0600)]
sched/fair: Move the cache-hot 'load_avg' variable into its own cacheline
If a system with large number of sockets was driven to full
utilization, it was found that the clock tick handling occupied a
rather significant proportion of CPU time when fair group scheduling
and autogroup were enabled.
Running a java benchmark on a 16-socket IvyBridge-EX system, the perf
profile looked like:
In particular, the high CPU time consumed by update_cfs_shares()
was mostly due to contention on the cacheline that contained the
task_group's load_avg statistical counter. This cacheline may also
contains variables like shares, cfs_rq & se which are accessed rather
frequently during clock tick processing.
This patch moves the load_avg variable into another cacheline
separated from the other frequently accessed variables. It also
creates a cacheline aligned kmemcache for task_group to make sure
that all the allocated task_group's are cacheline aligned.
Waiman Long [Wed, 25 Nov 2015 19:09:38 +0000 (14:09 -0500)]
sched/fair: Avoid redundant idle_cpu() call in update_sg_lb_stats()
Part of the responsibility of the update_sg_lb_stats() function is to
update the idle_cpus statistical counter in struct sg_lb_stats. This
check is done by calling idle_cpu(). The idle_cpu() function, in
turn, checks a number of fields within the run queue structure such
as rq->curr and rq->nr_running.
With the current layout of the run queue structure, rq->curr and
rq->nr_running are in separate cachelines. The rq->curr variable is
checked first followed by nr_running. As nr_running is also accessed
by update_sg_lb_stats() earlier, it makes no sense to load another
cacheline when nr_running is not 0 as idle_cpu() will always return
false in this case.
This patch eliminates this redundant cacheline load by checking the
cached nr_running before calling idle_cpu().
Atish Patra [Wed, 22 Mar 2017 21:55:24 +0000 (15:55 -0600)]
sched/fair: Clean up load average references
For cfs_rq, we have load.weight, runnable_load_avg, and load_avg.
Clean up how they are used:
- First, as group sched_entity already largely uses load_avg, we now expand
to use load_avg in all cases.
- Second, for CPU-wide load balancing, we choose to use runnable_load_avg
in all cases, which is the same as before this series.
[Atish]:
Here is the conflict in this patch.
<<<<<<< HEAD
unsigned long nr_running = ACCESS_ONCE(rq->cfs.h_nr_running);
unsigned long load_avg = rq->cfs.avg.load_avg;
=======
unsigned long nr_running = READ_ONCE(rq->cfs.h_nr_running);
unsigned long load_avg = weighted_cpuload(cpu);
>>>>>>> 7ea241a... sched/fair: Clean up load average references
ACCESS_ONCE is replaced with READ_ONCE by the upstream patch 316c1608d15c7.
As this patch is not in UEK4, ACCESS_ONCE is kept as it is.
Yuyang Du [Wed, 15 Jul 2015 00:04:41 +0000 (08:04 +0800)]
sched/fair: Provide runnable_load_avg back to cfs_rq
The cfs_rq's load_avg is composed of runnable_load_avg and blocked_load_avg.
Before this series, sometimes the runnable_load_avg is used, and sometimes
the load_avg is used. Completely replacing all uses of runnable_load_avg
with load_avg may be too big a leap, i.e., the blocked_load_avg is concerned
to result in overrated load. Therefore, we get runnable_load_avg back.
The new cfs_rq's runnable_load_avg is improved to be updated with all of the
runnable sched_eneities at the same time, so the one sched_entity updated and
the others stale problem is solved.
Yuyang Du [Wed, 15 Jul 2015 00:04:40 +0000 (08:04 +0800)]
sched/fair: Remove task and group entity load when they are dead
When task exits or group is destroyed, the entity's load should be
removed from its parent cfs_rq's load. Otherwise, it will take time
for the parent cfs_rq to decay the dead entity's load to 0, which
is not desired.
Yuyang Du [Wed, 15 Jul 2015 00:04:39 +0000 (08:04 +0800)]
sched/fair: Init cfs_rq's sched_entity load average
The runnable load and utilization averages of cfs_rq's sched_entity
were not initiated. Like done to a task, give new cfs_rq' sched_entity
start values to heavy its load in infant time.
Atish Patra [Wed, 22 Mar 2017 20:51:40 +0000 (14:51 -0600)]
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
[Atish:]
This patch moved some of the conflicting functions from proc.c to
fair.c and removed the corresponding declarations from sched.h.
The upstream patch 3289bdb42988 moved these functions from proc.c to
fair.c in addition to lot of other code restructure. Porting 3289bdb42988
breaks KABI for UEK4. That's why I have to hack around it.
Khalid Aziz [Mon, 8 May 2017 22:17:43 +0000 (16:17 -0600)]
sparc64: Allow enabling ADI on hugepages only
Since kernel provides only limted support for ADI on regular pages,
mprotect() should not allow enabling ADI on any pages other than
hugepages until rest of the support is complete.
Orabug: 25969377 Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Khalid Aziz [Thu, 27 Apr 2017 17:40:04 +0000 (11:40 -0600)]
sparc64: Save ADI tags on ADI enabled platforms only
When a page is ready to be swapped out or migrated, kernel saves the
ADI tags associated with it. To determine if ADI tags need to be saved
for a page, it checks if TTE.MCD bit is set for the page. M7 and newer
processors chose to reuse the TTE.CV bit from older processors for
TTE.MCD. When the kernel is running on non-ADI capable processors,
TTE.MCD bit is actually TTE.CV and it is set on older processors by
default for older processors by kernel. This causes kernel to
attempt to save the ADI tags for the page using MCD ASIs which are
not available on older processors. This causes a data access exception.
This patch adds a conditional to save ADI tags only on ADI capable
platforms.
Some larger applications require a TSB size of magnitude not required by a
vast majority of processes. This commit enables the TSB to be expanded
to a size up to MAX_ORDER - 1, limited by TSB size order encoding and
finally limited by MMU hardware. The large TSB page order allocations are
not included in a kmem cache like current TSB sizes. The improvement is
done for tlb_type hypervisor and limited to recent sun4v. This patch should
not impact performance of other sparc64 core chip types.
Signed-off-by: Bob Picco <bob.picco@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Thomas Tai [Thu, 6 Apr 2017 17:29:03 +0000 (10:29 -0700)]
sparc64: fix intermittent LDom hang waiting for vdc_port_up
When LDom boots, sunvdc probes the disk using the LDC channel.
If the channel was previously configured, we need to wait until
we have received a packet from the other end to ensure the
the LDC reset was fully completed; otherwise, the primary domain
will send out NACK when vdc tries to connect. The NACK causes
ldc_reset and flushes the receive queue which may contain the
version info. The unexpected loss of version info causes
the vdc handshake to wait forever.
This patch is to workaround the ldc_reset not handling
reconnection after receiving a NACK. This patch can be
reverted after ldc_reset is properly implemented.
Signed-off-by: Thomas Tai <thomas.tai@oracle.com> Reviewed-by: Tom Saeger <tom.saeger@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Reviewed-by: Babu Moger <babu.moger@oracle.com> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Vijay Kumar [Mon, 23 Jan 2017 17:53:03 +0000 (09:53 -0800)]
sparc64:block/sunvdc: Renamed bio variable name from req to bio
Changed bio variable name from req to bio for better readability.
This is just a cosmetic change.
Signed-off-by: Vijay Kumar <vijay.ac.kumar@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Orabug: 25128265 Signed-off-by: Allen Pais <allen.pais@oracle.com>
Vijay Kumar [Wed, 18 Jan 2017 16:10:12 +0000 (08:10 -0800)]
sparc64:block/sunvdc: Added io stats accounting for bio based vdisk
As vdisk now bypass block layer and directly submits IO, iostats does
not get accounted (which happens at block). Added IO accounting at bio
layer for vdisk block device.
Signed-off-by: Vijay Kumar <vijay.ac.kumar@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Orabug: 25128265 Signed-off-by: Allen Pais <allen.pais@oracle.com>
chris hyser [Wed, 15 Mar 2017 17:51:34 +0000 (10:51 -0700)]
sparc64: Remove node restriction from PRIQ MSI assignments
The current design of PRIQ only allows MSI routing to CPUs within the same
I/O node. At best this prevents certain types of CPU add/removals as well
as various affinity assignments and at worst can result in dropped
interrupts with CPU DR.
This prior design used a per-node hash table with collision chain (and RCU
synchronization) shared among the root complexes. While it would be
possible to support moving these records between the node hash tables this
is needlessly complicated when a single global table could be used instead
assuming the hashing mechanism was modified to limit the potential for
performance degradation through potentially longer collision chains and
more lookups.
The new design for MSI uses the bottom N bits of the device handle as a
hash versus hashing device handle and msidata together as before. This
exploits the existing numbering scheme to result in zero collisions (even
in an exactly sized hash table). If the numbering scheme is changed on a
future system, that system will still be functional though presumably
with some performance loss. The MSI data is then used as an index into a
array as has been done for prior linux sun4v interrupt model support. Given
the very small number of INTX interrupts, their handling remains
essentially unchanged (now uses a single global hash table, versus per I/O
node as before).
chris hyser [Fri, 3 Mar 2017 21:24:22 +0000 (13:24 -0800)]
blk-mq: Clean up all_q_list on request_queue deletion
Entries were not being removed from all_q_list when corresponding request
queue structs were freed with subsequent embedded list pointers being
trashed when the queue memory was re-allocated. Additionally, due to use of
cached allocation pool (kmem_cache_alloc_node), the same data structure
would be reinserted into the same list twice which cannot work given the
kernel linked list implementation.
Signed-off-by: Chris Hyser <chris.hyser@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com>
Orabug: 25569331 Signed-off-by: Allen Pais <allen.pais@oracle.com>
I encountered this bug when using /proc/kcore to examine the kernel. Plus a
coworker inquired about debugging tools. We computed pa but did
not use it during the maximum physical address bits test. Instead we used
the identity mapped virtual address which will always fail this test.
I believe the defect came in here:
[bpicco@zareason linus.git]$ git describe --contains bb4e6e85daa52
v3.18-rc1~87^2~4
.
Signed-off-by: Bob Picco <bob.picco@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Chuck Anderson [Fri, 5 May 2017 16:57:23 +0000 (09:57 -0700)]
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: (32 commits)
sparc64: Detect DAX ra+pgsz when hvapi minor doesn't indicate it
sparc64: DAX memory will use RA+PGSZ feature in HV
sparc64: Disable DAX flow control
sparc64: Add DAX hypervisor services
sparc64: DAX memory needs persistent mappings
sparc64: Fix incorrect error print in DAX driver when validating ccb
sparc64: DAX request for non 4MB memory should return with unique errno
Revert "sparc64: DAX request for non 4MB memory should return with unique errno"
sparc64: DAX request to mmap non 4MB memory should fail with a debug print
sparc64: DAX request for non 4MB memory should return with unique errno
sparc64: Incorrect print by DAX driver when old driver API is used
sparc64: DAX request to dequeue half of a long CCB should not succeed
sparc64: dax_overflow_check reports incorrect data
sparc64: Ignored DAX ref count causes lockup
sparc64: disable dax page range checking on RA
sparc64: Oracle Data Analytics Accelerator (DAX) driver
sparc64: fix an issue when trying to bring hotplug cpus online
sparc64: Fix memory corruption when THP is enabled
sparc64: Fix address range for page table free Orabug: 25704426
sparc64: Add support for 2G hugepages
...
The RA+PGSZ HV API feature is detected via a controlled experiment.
The experiment constructs a small DAX request and places the output
buffer at the very end of an 8k page. Then it checks to see if the 8k
page boundary was honored, and if so, then we've got the ability to pass
the page size along with a real address. Once the HV API minor number
is bumped to 1, this will be the primary method of detection.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com>
(cherry picked from commit 013d5b9909e804817dcd939f50f242f09237feac) Signed-off-by: Allen Pais <allen.pais@oracle.com>
The reported kernel panics and "other oddities" are caused by
corruption of kernel memory by DAX output. This is happening due to an
apparent change between UEK2 and UEK4, whereby the underlying h/w page
size for memory acquired via kmalloc has changed. UEK2 used 4mb pages,
which the dax driver used to limit the output from the coprocessor,
who refuses to cross "page boundaries". But in UEK4 it appears that a
more intelligent approach to memory is used, and kernel memory may be
backed by a variety of huge h/w page sizes, ie, 256mb and 2gb. This
now allows DAX to produce output up to this much larger page size,
thus going beyond the actual allocation. We do not have any way to
kmalloc memory with a certain backing page size, and we cannot feed
DAX a virtual address if we are not certain of its page size.
Recent hypervisor f/w has provided a powerful new feature: the ability
to convey page size bits along with a real address (RA). This gives us
the opportunity to avoid using the TLB/TSB as a parameter passing
mechanism and we can use this to avoid using virtual addresses at all
in a DAX ccb. We now use this mechanism to set the page size for
dax_alloc memory to 4mb even if the underlying h/w page size for the
memory is much larger. Memory allocated by the application via
conventional methods is not affected.
This HV feature is available on M7 f/w with minor number 1, so this is
used to determine if the driver can provide the memory allocation
service. If the feature is not available, DAX will still work, but all
the responsibility for memory allocation falls back to the
application.
The sudden ENOACCESS errors are a result of another hypervisor change.
Newest HV firmware has begun to enforce the privileged flag (bit 14)
in arg2 of the ccb_submit hypercall. This flag is described in the API
wiki as "CCB virtual addresses are treated as privileged" and in the
VM spec as "Virtual addresses within CCBs are translated in privileged
context". The explanation given later in the VM spec is that if a CCB
contains any virtual address whose TTE has the priv bit set
(_PAGE_P_4V), then the priv flag in the ccb_submit api must also be
set, or else the hypervisor will refuse to perform the translation,
and an ENOACCESS error will be thrown. Since privileged virtual
addresses are no longer used as a result of this very commit, this
problem simply disappears.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
The flow control feature of DAX only works for output buffers
and it doesn't appear to be possible to calculate the exact
size in bytes of an input buffer. So we have no way to bound
the amount of data that DAX reads as input. This has correctness
and security implications, so until we figure out something better
to do, the temporary workaround is to disable flow control completely
and fall back to 4Mb virtual page backed dax_alloc memory, which
will allow page boundaries to limit the size of all buffers. A new
module parameter "flow_enable" is provided to allow this decision
to be reverted at module load time if needed.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com> Reviewed-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Reviewed-by: Bob Picco <bob.picco@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
fpu_activate is called outside of vcpu_load(), which means it should not
touch VMCS, but fpu_activate needs to. Avoid the call by moving it to a
point where we know that the guest needs eager FPU and VMCS is loaded.
Memory allocated on behalf of dax_alloc() is mapped by two
distinct MMU translations, one set for userland, which is backed by
regular 8k virtual pages, and another set for feeding to the
hypervisor, and these are kernel virtual addresses backed
by 4Mb pages. These latter translations are only used when
the memory is allocated/deallocated and when a dax transaction
is submitted. So the translations are unlikely to be in the TLB,
and eventually may be evicted from the kernel TSB after some time.
This leads to ENOMAP errors reported by the hypervisor. In order
to avoid this, we "touch" such pages just before dax_submit
which will fault translations into the tlb/tsb if necessary.
A future performance optimization is to take advantage of the "real
address has pagesize" feature which is available in very recent
versions of hypervisor f/w. In this case we can convert the address
in the ccb to a real address with the correct bits to specify
a 4Mb pagesize, and change the address type to real. Then the
memory touch would be unnecessary and the HV would not need to
probe the tlb/tsb at all.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: HÃ¥kon Bugge <haakon.bugge@oracle.com> Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
This fixes an incorrect stringification in a macro that prints
invalid address type in a CCB.
Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
With this change libdax can detect that mmap failed due to lack of flow
control in DAX HW and it can proceed with dax_subpage allocation.
Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
When the dax flow control is disabled, dax_alloc_mem(...) only allows 4MB
allocation in the driver. Any other requests are reported as an error
with an error print to the kernel log. We now have a dax subpage
allocator in libdax which gets triggered when the driver reports the
above said failure. In other words it is a normal use case for the driver
to report this. So make this a debug print.
Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
With this change libdax can detect that mmap failed due to lack of flow
control in DAX HW and it can proceed with dax_subpage allocation.
Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
If an old dax driver API is used, it is the driver API version
that is old, irrespective of the libdax version.
Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
When a dequeue call is made to the driver such that the last CCB in the
request is the first half of a long ccb, the driver does not report an
error and releases the BIP buffer for the CCBs dequeued up until then.
This was detected by a ioctl_test23 written by Stanislav specifically to
validate the above scenario.
This bug fix addresses both the above issues.
Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
The range reported for a page overflow is incorrect when
the address is page_size aligned. Add 1 to the address so
that it always reports the next page_size boundary.
Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
The dax_mm structure has a reference count that respresents
the number of dax_vma structures that point to it. The reference
count is duly incremented and decremented each time memory is
allocated via the dax_alloc/mmap path. However, the reference
count is never used for its intended purpose, which is to
prevent the dax_mm structure from being freed while there
are references to it. The result of this is that if dax_free
is called after the process's dax_mm is cleaned up, the dax_vma
will have a reference to the freed object, leading to panics
due to null pointers and/or lockups due to inalid spinlock state.
Code changed to actually check the reference count before freeing
a dax_mm.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
This fix is to address a hypervisor f/w change which affects
T7 machines with 3.0 cpu and T8 machines. Newer HV f/w
pays attention to the page size field in real addresses.
This is not a bug; I asked them to implement this long ago.
A value of zero here means 8k, so RA buffers are restricted
to one page when running on newer firmware. The PRM defines a page
size of 0xF to mean "disable page range checking". We set this
value for all real addresses. Old f/w will overwrite this field
anyway, so it's safe for us to always set it.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
DAX is a coprocessor which resides on the SPARC M7 processor chip, and
has direct access to the CPU's L3 caches as well as physical
memory. It can perform several operations on data streams with
various input and output formats. The driver is merely a transport
mechanism and does not have knowledge of the various opcodes and data
formats. A user space library provides high level services and
translates these into low level commands which are then passed into
the driver and subsequently the hypervisor and the coprocessor.
See Documentation/sparc/dax.txt for more details.
Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Reviewed-by: David Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com> Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Dave Aldridge [Fri, 24 Mar 2017 12:01:00 +0000 (06:01 -0600)]
sparc64: fix an issue when trying to bring hotplug cpus online
When booting the kernel with maxcpus= on the command line
and then subsequently trying to bring cpus online using:
echo 1 > /sys/devices/system/cpu/cpu[n]/online
messages of the form:
ldom_startcpu_cpuid: sun4v_cpu_start() gives error 6
Processor[n] is stuck
were being reported on the console.
This commit fixes this issue by ensuring that any cpus not
booted during initial kernel boot are explicitly stopped.
This then allows them to be successfully brought online later
if required.
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Reviewed-by: Allen Pais <allen.pais@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Reported-by: David S. Miller <davem@davemloft.net> Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Reviewed-by: Bijan Mottahedeh <bijan.mottahedeh@oracle.com> Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
George Kennedy [Wed, 22 Mar 2017 17:39:32 +0000 (13:39 -0400)]
SPARC64: Virtual Disk Device (vdsdev) Read-Only Option (options=ro) not working
Add read-only (options=ro) support to virtual disk server (VDS).
Signed-off-by: George Kennedy <george.kennedy@oracle.com> Reviewed-by: Alexandre Chartre <Alexandre.Chartre@oracle.com>
Orabug: 23623853 Signed-off-by: Allen Pais <allen.pais@oracle.com>
Babu Moger [Tue, 7 Mar 2017 22:19:55 +0000 (14:19 -0800)]
arch/sparc: Fix FPU register corruption with AES crypto test on M7
We noticed crypto key corruption while running AES crypto tests
with M7 memcpy changes. Investigating further, we found that this
was the same problem reported previously with NG4memcpy. The commit f4da3628dc7c ("sparc64: Fix FPU register corruption with AES crypto
offload") fixes the problem. Ported these changes to M7memcpy.
Signed-off-by: Babu Moger <babu.moger@oracle.com> Tested-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Shannon Nelson [Tue, 14 Mar 2017 17:24:43 +0000 (10:24 -0700)]
sunvnet: xoff not needed when removing port link
The sunvnet netdev is connected to the controlling ldom's vswitch
for network bridging. However, for higher performance between ldoms,
there also is a channel between each client ldom. These connections are
represented in the sunvnet driver by a queue for each ldom. The driver
uses select_queue to tell the stack which queue to use by tracking the mac
addresses on the other end of each port. When a connected ldom shuts down,
the driver receives an LDC_EVENT_RESET and the port is removed from the
driver, thus a queue with no ldom on the other end will never be selected
for Tx.
The driver was trying to reinforce the "don't use this queue" notion with
netif_tx_stop_queue() and netif_tx_wake_queue(), which really should only
be used to signal a Tx queue is full (aka XOFF). This misuse of queue
state resulted in NETDEV WATCHDOG messages and lots of unnecessary calls
into the driver's tx_timeout handler. Simply removing these takes care
of the problem.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry-picked from commit 9c5a3a1f9388100d4b03e85faf0cce8264985302)
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry-picked from commit b12a96f5cd04583f45a1b6554b8f3786b26db913)
Shannon Nelson [Tue, 14 Mar 2017 17:24:41 +0000 (10:24 -0700)]
sunvnet: track port queues correctly
Track our used and unused queue indexies correctly. Otherwise, as ports
dropped out and returned, they all eventually ended up with the same
queue index.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry-picked from commit e1f1e5f711265ee9d881afd12ff252b2d01e1174)
Shannon Nelson [Tue, 14 Mar 2017 17:24:40 +0000 (10:24 -0700)]
sunvnet: add stats to track ldom to ldom packets and bytes
In this driver, there is a "port" created for the connection to each of
the other ldoms; a netdev queue is mapped to each port, and they are
collected under a single netdev. The generic netdev statistics show
us all the traffic in and out of our network device, but don't show
individual queue/port stats. This patch breaks out the traffic counts
for the individual ports and gives us a little view into the state of
those connections.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry-picked from commit 0f512c84544b9a8f8de53b6f4bc0c372c45d8693)
Shannon Nelson [Tue, 14 Mar 2017 17:24:39 +0000 (10:24 -0700)]
ldmvsw: better use of link up and down on ldom vswitch
When an ldom VM is bound, the network vswitch infrastructure is set up for
it, but was being forced 'UP' by the userland switch configuration script.
When 'UP' but not actually connected to a running VM, the ipv6 neighbor
probes fail (not a horrible thing) and start cluttering up the kernel logs.
Funny thing: these are debug messages that never actually show up, but
we do see the net_ratelimited messages that say N callbacks were
suppressed.
This patch defers the netif_carrier_on() until an actual link has been
established with the VM, as indicated by receiving an LDC_EVENT_UP from
the underlying LDC protocol. Similarly, we take the link down when we
see the LDC_EVENT_RESET. Now when we see the ndo_open(), we reset the
link to get things talking again.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry-picked from commit 867fa150f8f7ee6e9e5a9ab768e2d0dc675a968b)
Chuck Anderson [Thu, 6 Apr 2017 07:17:44 +0000 (00:17 -0700)]
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: (28 commits)
megaraid: Fix unaligned warning
sparc64: Restrict number of processes
SPARC64: vds_blk_rw() does not handle drives with q->limits.chunk_sectors > 0
sparc64: Improve boot time by per cpu map update
arch/sparc: memblock resizes are not handled properly
SPARC64: LDOM vnet "Got unexpected MCAST reply"
ldmvsw: disable tso and gso for bridge operations
ldmvsw: update and simplify version string
sunvnet: remove extra rcu_read_unlocks
sunvnet: straighten up message event handling logic
sunvnet: add memory barrier before check for tx enable
sunvnet: update version and version printing
sunvnet: remove unused variable in maybe_tx_wakeup
sunvnet: make sunvnet common code dynamically loadable
hwrng: n2 - update version info
hwrng: n2 - support new hardware register layout
hwrng: n2 - add device data descriptions
hwrng: n2 - limit error spewage when self-test fails
hwrng: n2 - Attach on T5/M5, T7/M7 SPARC CPUs
tcp: fix tcp_fastopen unaligned access complaints on sparc
...
Allen Pais [Wed, 29 Mar 2017 08:51:58 +0000 (14:21 +0530)]
megaraid: Fix unaligned warning
The MegaRAID userland descriptor structures do not properly align
pointers on their natural boundaries. This causes warnings to be issued
when storcli or the SNMP daemon are in use.
Quiesce the warning until the user-kernel interface has been fixed.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 069af368ac74dc0130f91836b9f85f7cd5b18749) Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
If the number of processes exceeds the number of supported context IDs
then there are random segfaults seen in the user programs.
The data collected when debugging this bug showed that two processes
with the same context IDs were present in the TLB shared between them
thus resulting in incorrect translations. Since the bug occurs after the
kernel hits the max context ID supported by the processor, the context
wraparound code found in get_new_mmu_context(...) and
smp_new_mmu_context_version_client(...) are under suspicion.
The plan is that this will get fixed when we implement "context domain"
feature for sparc in the kernel. For now this patch temporarily
restricts the number of processes allowed by the kernel based on the
number of context IDs supported by the processor. This way we never reach
that condition of having incorrect translations.
For non root users fork will fail if the number of existing processes is
greater than (max_user_nctx - 100). Where max_user_nctx is the maximum
number of context IDs supported by the processor. For root user the fork
will fail if the the number of existing processes reaches max_user_nctx.
Extra context IDs are given to root to recover the system if users reach
their limit and cannot recover the system (i.e cannot even execute
'kill' to reduce the number of processes).
Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
George Kennedy [Wed, 15 Feb 2017 20:17:58 +0000 (15:17 -0500)]
SPARC64: vds_blk_rw() does not handle drives with q->limits.chunk_sectors > 0
Drives with q->limits.chunk_sectors > 0 are not properly handled by
vds_blk_rw(). Drives such as NVME set chunk_sectors to indicate a performance
boundary (see call to blk_queue_chunk_sectors() in nvme_alloc_ns()). Currently,
when vds_blk_rw() calls bio_add_page() and the chunk_sectors boundary would be
crossed, bio_add_page() returns zero and vds_blk_rw() fails with -EIO.
The proposed fix now adds an additional check to vds_blk_rw() when
bio_add_page() returns zero that checks for bio->bi_iter.bi_size != 0. If
bi_size != 0, it indicates that a page or pages have been successfully added by
bio_add_page(). When this added condition has been hit, exit the for loop in
vds_blk_rw() and submit the outstanding IOs and continue.
Signed-off-by: George Kennedy <george.kennedy@oracle.com> Reviewed-By: Bijan Mottahedeh <bijan.mottahedeh@oracle.com> Reviewed-By: Liam Merwick <Liam.Merwick@oracle.com>
Orabug: 25373818 Signed-off-by: Allen Pais <allen.pais@oracle.com>
Atish Patra [Mon, 13 Feb 2017 02:32:58 +0000 (19:32 -0700)]
sparc64: Improve boot time by per cpu map update
Currently, smp_fill_in_sib_core_maps is invoked during cpu_up to setup
all the core/sibling map correctly. This happens in the order of O(n^2)
as it iterates over all the online cpus twice when each cpu comes online.
This increases smp_init() execution time exponentially leading to a
higher boot time.
Optimize the code path by comparing only the current cpu with online
cpus and set the maps for both the cpus simultaneously. Take this
opportunity to merge all three for loops into one as well. Here is
the smp_init() time after and before the fix.
Number of cpus: before fix: after the fix:
512 2.30s .283s
1024 14.23s .493s
Signed-off-by: Atish Patra <atish.patra@oracle.com> Reviewed-by: Pavel Tatashin <pasha.tatashin@oracle.com> Reviewed-by: Allen Pais <allen.pais@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Pavel Tatashin [Wed, 8 Feb 2017 21:02:39 +0000 (16:02 -0500)]
arch/sparc: memblock resizes are not handled properly
In add_node_ranges() when memblock resize happens, the iterator keeps using
the previous freed array. This bug cause hangs on machine where there are
over 128 memory blocks during boot. For example, on machines where memory
interleaving is small.
The problem is seen on T4-4 because it cant have 2T of memory, and memory
is interleaved at 8G. So we have 2T/8G = 256 regions to set node IDs. The
starting size of regions array is 128. Thus, we have to double at least one
time (actually we have to double twice because some memory is already
reserved and thus we need more than 256 regions). We start using an
incorrect pointer to the array after the first doubling.
George Kennedy [Wed, 8 Feb 2017 01:37:37 +0000 (20:37 -0500)]
SPARC64: LDOM vnet "Got unexpected MCAST reply"
Handle unexpected MCAST reply as a debug warning the same as is done in
Solaris 12. Please see bug 24954702 for details.
Signed-off-by: George Kennedy <george.kennedy@oracle.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Orabug: 24954702 Signed-off-by: Allen Pais <allen.pais@oracle.com>
Shannon Nelson [Mon, 13 Feb 2017 18:57:04 +0000 (10:57 -0800)]
ldmvsw: disable tso and gso for bridge operations
The ldmvsw driver is specifically for supporting the ldom virtual
networking by running in the primary ldom and using the LDC to connect
the remaining ldoms to the outside world via a bridge. With TSO and GSO
supported while connected the bridge, things tend to misbehave as seen
in our case by delayed packets, enough to begin triggering retransmits
and affecting overall throughput. By turning off advertised support for
TSO and GSO we restore stable traffic flow through the bridge.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit bc221a34ac473b444a7cfdd0c152b4c71f79326b) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 7602011f59cc32ebc3a5f9058d6ba11b096c8c50) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Shannon Nelson [Mon, 13 Feb 2017 18:57:02 +0000 (10:57 -0800)]
sunvnet: remove extra rcu_read_unlocks
The RCU read lock is grabbed first thing in sunvnet_start_xmit_common()
so it always needs to be released. This removes the conditional release
in the dropped packet error path and removes a couple of superfluous
calls in the middle of the code.
Reported-by: Bijan Mottahedeh <bijan.mottahedeh@oracle.com> Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit daa86e50f649fccadafc53994ddc4254d75a008b) Signed-off-by: Allen Pais <allen.pais@oracle.com>
Shannon Nelson [Mon, 13 Feb 2017 18:57:01 +0000 (10:57 -0800)]
sunvnet: straighten up message event handling logic
The use of gotos for handling the incoming events made this code
harder to read and support than it should be. This patch straightens
out and clears up the logic.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit bf091f3f362b3c562a18bbf7a2d3e2f3a36eba1d) Signed-off-by: Allen Pais <allen.pais@oracle.com>
projects / users / jedix / linux-maple.git / log