linux-toradex.git, branch v4.1.5

Linux 4.1.5

2015-08-10T19:22:34+00:00

perf symbols: Store if there is a filter in place

2015-08-10T19:22:00+00:00

commit 0bc2f2f7d080561cc484d2d0a162a9396bed3383 upstream.

When setting yup the symbols library we setup several filter lists,
for dsos, comms, symbols, etc, and there is code that, if there are
filters, do certain operations, like recalculate the number of non
filtered histogram entries in the top/report TUI.

But they were considering just the "Zoom" filters, when they need to
take into account as well the above mentioned filters (perf top --comms,
--dsos, etc).

So store in symbol_conf.has_filter true if any of those filters is in
place.

Cc: Adrian Hunter 
Cc: Borislav Petkov 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-f5edfmhq69vfvs1kmikq1wep@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Cc: Andre Tomt 
Signed-off-by: Greg Kroah-Hartman

xfs: remote attributes need to be considered data

2015-08-10T19:21:59+00:00

commit df150ed102baa0e78c06e08e975dfb47147dd677 upstream.

We don't log remote attribute contents, and instead write them
synchronously before we commit the block allocation and attribute
tree update transaction. As a result we are writing to the allocated
space before the allcoation has been made permanent.

As a result, we cannot consider this allocation to be a metadata
allocation. Metadata allocation can take blocks from the free list
and so reuse them before the transaction that freed the block is
committed to disk. This behaviour is perfectly fine for journalled
metadata changes as log recovery will ensure the free operation is
replayed before the overwrite, but for remote attribute writes this
is not the case.

Hence we have to consider the remote attribute blocks to contain
data and allocate accordingly. We do this by dropping the
XFS_BMAPI_METADATA flag from the block allocation. This means the
allocation will not use blocks that are on the busy list without
first ensuring that the freeing transaction has been committed to
disk and the blocks removed from the busy list. This ensures we will
never overwrite a freed block without first ensuring that it is
really free.

Signed-off-by: Dave Chinner 
Reviewed-by: Brian Foster 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman

xfs: remote attribute headers contain an invalid LSN

2015-08-10T19:21:59+00:00

commit e3c32ee9e3e747fec01eb38e6610a9157d44c3ea upstream.

In recent testing, a system that crashed failed log recovery on
restart with a bad symlink buffer magic number:

XFS (vda): Starting recovery (logdev: internal)
XFS (vda): Bad symlink block magic!
XFS: Assertion failed: 0, file: fs/xfs/xfs_log_recover.c, line: 2060

On examination of the log via xfs_logprint, none of the symlink
buffers in the log had a bad magic number, nor were any other types
of buffer log format headers mis-identified as symlink buffers.
Tracing was used to find the buffer the kernel was tripping over,
and xfs_db identified it's contents as:

000: 5841524d 00000000 00000346 64d82b48 8983e692 d71e4680 a5f49e2c b317576e
020: 00000000 00602038 00000000 006034ce d0020000 00000000 4d4d4d4d 4d4d4d4d
040: 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d
060: 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d 4d4d4d4d
.....

This is a remote attribute buffer, which are notable in that they
are not logged but are instead written synchronously by the remote
attribute code so that they exist on disk before the attribute
transactions are committed to the journal.

The above remote attribute block has an invalid LSN in it - cycle
0xd002000, block 0 - which means when log recovery comes along to
determine if the transaction that writes to the underlying block
should be replayed, it sees a block that has a future LSN and so
does not replay the buffer data in the transaction. Instead, it
validates the buffer magic number and attaches the buffer verifier
to it.  It is this buffer magic number check that is failing in the
above assert, indicating that we skipped replay due to the LSN of
the underlying buffer.

The problem here is that the remote attribute buffers cannot have a
valid LSN placed into them, because the transaction that contains
the attribute tree pointer changes and the block allocation that the
attribute data is being written to hasn't yet been committed. Hence
the LSN field in the attribute block is completely unwritten,
thereby leaving the underlying contents of the block in the LSN
field. It could have any value, and hence a future overwrite of the
block by log recovery may or may not work correctly.

Fix this by always writing an invalid LSN to the remote attribute
block, as any buffer in log recovery that needs to write over the
remote attribute should occur. We are protected from having old data
written over the attribute by the fact that freeing the block before
the remote attribute is written will result in the buffer being
marked stale in the log and so all changes prior to the buffer stale
transaction will be cancelled by log recovery.

Hence it is safe to ignore the LSN in the case or synchronously
written, unlogged metadata such as remote attribute blocks, and to
ensure we do that correctly, we need to write an invalid LSN to all
remote attribute blocks to trigger immediate recovery of metadata
that is written over the top.

As a further protection for filesystems that may already have remote
attribute blocks with bad LSNs on disk, change the log recovery code
to always trigger immediate recovery of metadata over remote
attribute blocks.

Signed-off-by: Dave Chinner 
Reviewed-by: Brian Foster 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/drm/nv04-nv40/instmem: protect access to priv->heap by mutex

2015-08-10T19:21:59+00:00

commit 7512223b1ece29a5968ed8b67ccb891d21b7834b upstream.

This fixes the list_del corruption reported
at .

Signed-off-by: Kamil Dudka 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau: hold mutex when calling nouveau_abi16_fini()

2015-08-10T19:21:59+00:00

commit ac8c79304280da6ef05c348a9da03ab04898b994 upstream.

This was the only access to cli->abi16 without holding the mutex.

Signed-off-by: Kamil Dudka 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/kms/nv50-: guard against enabling cursor on disabled heads

2015-08-10T19:21:59+00:00

commit 697bb728d9e2367020aa0c5af7363809d7658e43 upstream.

Userspace has started doing this, which upsets the display class hw
error checking in various unpleasant ways.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/fbcon/nv11-: correctly account for ring space usage

2015-08-10T19:21:59+00:00

commit d108142c0840ce389cd9898aa76943b3fb430b83 upstream.

The RING_SPACE macro accounts how much space is used up so it's
important to ask it for the right amount. Incorrect accounting of this
can cause page faults down the line as writes are attempted outside of
the ring.

Signed-off-by: Ilia Mirkin 
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

qla2xxx: kill sessions/log out initiator on RSCN and port down events

2015-08-10T19:21:59+00:00

commit b2032fd567326ad0b2d443bb6d96d2580ec670a5 upstream.

To fix some issues talking to ESX, this patch modifies the qla2xxx driver
so that it never logs into remote ports.  This has the side effect of
getting rid of the "rports" entirely, which means we never log out of
initiators and never tear down sessions when an initiator goes away.

This is mostly OK, except that we can run into trouble if we have
initiator A assigned FC address X:Y:Z by the fabric talking to us, and
then initiator A goes away.  Some time (could be a long time) later,
initiator B comes along and also gets FC address X:Y:Z (which is
available again, because initiator A is gone).  If initiator B starts
talking to us, then we'll still have the session for initiator A, and
since we look up incoming IO based on the FC address X:Y:Z, initiator B
will end up using ACLs for initiator A.

Fix this by:

 1. Handling RSCN events somewhat differently; instead of completely
    skipping the processing of fcports, we look through the list, and if
    an fcport disappears, we tell the target code the tear down the
    session and tell the HBA FW to release the N_Port handle.

 2. Handling "port down" events by flushing all of our sessions.  The
    firmware was already releasing the N_Port handle but we want the
    target code to drop all the sessions too.

Signed-off-by: Roland Dreier 
Signed-off-by: Alexei Potashnik 
Acked-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

qla2xxx: fix command initialization in target mode.

2015-08-10T19:21:59+00:00

commit 9fce12540cb9f91e7f1f539a80b70f0b388bdae0 upstream.

Signed-off-by: Kanoj Sarcar 
Signed-off-by: Himanshu Madhani 
Reviewed-by: Nicholas Bellinger 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman