When file auditing is enabled, during a low memory situation, a memory
allocation with __GFP_FS can lead to pruning the inode cache.  Which can,
in turn lead to audit_tree_freeing_mark() being called.  This can call
audit_schedule_prune(), that tries to fork a pruning thread, and
waits until the thread is created.  But forking needs memory, and the
memory allocations there are done with __GFP_FS.

So we are waiting merrily for some __GFP_FS memory allocations to complete,
while holding some filesystem locks.  This can take a while ...

This patch creates a single thread for pruning the tree from
audit_add_tree_rule(), and thus avoids the deadlock that the on-demand
thread creation can cause.

Reported-by: Matt Wilson <[email protected]>
Cc: Matt Wilson <[email protected]>
Signed-off-by: Imre Palik <[email protected]>
Reviewed-by: Richard Guy Briggs <[email protected]>
Signed-off-by: Paul Moore <[email protected]>

…_start()

Copy the set wait time to a working value to avoid losing the set
value if the queue overflows.

Signed-off-by: Richard Guy Briggs <[email protected]>
Signed-off-by: Paul Moore <[email protected]>

During a queue overflow condition while we are waiting for auditd to drain the
queue to make room for regular messages, we don't want a successful auditd that
has bypassed the queue check to reset the backlog wait time.

Signed-off-by: Richard Guy Briggs <[email protected]>
Signed-off-by: Paul Moore <[email protected]>

Fixed a coding style issue (unnecessary parentheses , unnecessary braces)

Signed-off-by: Ameen-Ali <[email protected]>
[PM: tweaked subject line]
Signed-off-by: Paul Moore <[email protected]>

This patch adds a audit_log_d_path_exe() helper function
to share how we handle auditing of the exe_file's path.
Used by both audit and auditsc. No functionality is changed.

Signed-off-by: Davidlohr Bueso <[email protected]>
[PM: tweaked subject line]
Signed-off-by: Paul Moore <[email protected]>

The mm->exe_file is currently serialized with mmap_sem (shared)
in order to both safely (1) read the file and (2) audit it via
audit_log_d_path(). Good users will, on the other hand, make use
of the more standard get_mm_exe_file(), requiring only holding
the mmap_sem to read the value, and relying on reference counting
to make sure that the exe file won't dissapear underneath us.

Additionally, upon NULL return of get_mm_exe_file, we also call
audit_log_format(ab, " exe=(null)").

Signed-off-by: Davidlohr Bueso <[email protected]>
[PM: tweaked subject line]
Signed-off-by: Paul Moore <[email protected]>

Ensures that block2mtd is triggered after the block devices are enumerated
at boot time.
This issue is seen on BCM2835 (Raspberry Pi) systems when mounting JFFS2
block2mtd filesystems, probably because of the delay on enumerating a USB
MMC card reader.

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: Rodrigo Freire <[email protected]>
Signed-off-by: Herton Krzesinski <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

Signed-off-by: Baruch Siach <[email protected]>
Acked-by: Boris Brezillon <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

Change the handling of the data stage in the driver : don't pump data in
the top-half interrupt, but rather schedule a thread for non dma cases.

This will enable latencies in the data pumping, especially if delays are
required. Moreover platform shall be more reactive as other interrupts
can be served while pumping data.

No throughput degradation was observed, at least on the zylonite
platform, while a slight degradation was being expected.

Signed-off-by: Robert Jarzmik <[email protected]>
Tested-by: Maxime Ripard <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

pxa3xx_flash_ids wasn't initialized to 0, which in certain cases could
end up containing corrupted values in its members. Fix this to avoid
possible issues.

Signed-off-by: Antoine Tenart <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

s3c2410_nand_probe is not the name of the function.

These prints have little utility, so let's just kill them.

Reported-by: Julia Lawall <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

Fix typo, "Unkown" -> "Unknown"

Signed-off-by: Colin Ian King <[email protected]>
Acked-by: Josh Wu <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

Currently the driver read NFC command registers to get NFC busy flag.
Actually this flag also can be get by reading HSMC_SR register.

Use the read NFC command registers need mapping a huge memory region.
To save the mapped memory region, we change to check NFC busy flag by
reading HSMC_SR register.

Signed-off-by: Boris Brezillon <[email protected]>
Signed-off-by: Josh Wu <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

While extending the mxc-nand driver it happend to me a few times that
the device was stuck and this made the machine hang during boot. So
implement a timeout and print a stack trace the first time this happens
to make it debuggable. The return type of the waiting function is also
changed to int to be able to handle the timeout in the caller.

Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

…lashes

At least on i.MX25 (i.e. NFCv2) preset_v2 is called with mtd->writesize
== 0 that is before the connect flash chip is detected. It then
configures for 8 bit ECC mode which needs 26 bytes of OOB per 512 bytes
main section. For flashes with a smaller OOB area issuing a read page
command makes the controller stuck with this config.

Note that this currently doesn't hurt because the first read page
command is issued only after detection is complete and preset is called
once more.

Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

When the hardware operates in 16 bit mode it always reads 16 bits even
for operations that only have the lower 8 bits defined. So the upper
bits must be discarded. Do this in the read_byte callback instead of
when reading the NAND id to support reading byte wise more than 5 bytes
and at other occations (like reading the ONFI parameter page).

Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

The mxc-nand controller works pagewise and so usually only sends
commands to the flash chip with column == 0. A request with column != 0
from the upper layer is then fulfilled by indexing appropriately into the
device's RAM buffer.

To be able to access the ONFI marker at offset 0x20 in reply to the
READID command however it's invalid to read 32 bytes starting from
column 0.

So let the function used to send the address cycles send the column
address actually passed instead of 0 and fix all callers to pass 0
instead appropriately. Also add some warnings in case this patch changes
the drivers semantics.

Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

The mxc-nand driver never supported the PARAM command to read out the
ONFI parameter page and so always relied on probing my manufacturer and
device id (as provided by the READID command).

This patch implements reading out the first parameter page copy at least
which should be good enough in practise.

This makes the boot log change from

	nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xb1
	nand: Micron NAND 128MiB 1,8V 16-bit

to
	nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xb1
	nand: Micron MT29F1G16ABBDAH4

on my machine.

Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

The PARAM command was long unimplemented and it probably wasn't
noticed because chip probing using only the few bytes returned by the
READID command are good enough in most cases to determine the chip in
use.

Still to notice such a shortcoming earlier in the future would be nice
in case it's something more vital.

Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

If no devices were found, we would already have skipped over this code.

Detected by Coverity, CID #744270

Signed-off-by: Brian Norris <[email protected]>
Acked-by: Robert Jarzmik <[email protected]>

'ret' is always zero, so this is all dead code.

This should quiet Coverity CID #1226739.

Signed-off-by: Brian Norris <[email protected]>
Cc: Kyungmin Park <[email protected]>

Caught by Coverity (CID #200625 and others)

Signed-off-by: Brian Norris <[email protected]>
Cc: Akinobu Mita <[email protected]>

Coverity noticed that these 'ret' assignments weren't being used. Let's
use them.

Note that nand_lock() and nand_unlock() are still not officially used by
any drivers.

Coverity CIDs #1227054 and #1227037

Signed-off-by: Brian Norris <[email protected]>

TclsRising is always 1.

Caught by Coverity.

Signed-off-by: Brian Norris <[email protected]>
Cc: Masahiro Yamada <[email protected]>

The only exit (break) from the preceding loop is nested within a
condition which yields req == NULL. This code is dead.

Coverity CID #752669

Signed-off-by: Brian Norris <[email protected]>

We're not initializing the ooblen field. Our users don't care, since
they check that oobbuf == NULL first, but it's good practice to zero
unused fields out.

We can drop the NULL initializations since we're memset()ing the whole
thing.

Noticed by Coverity, CID #200821, #200822

Signed-off-by: Brian Norris <[email protected]>

The cfi_staa_write_buffers function uses a large amount of kernel stack
whenever CONFIG_MTD_MAP_BANK_WIDTH_32 is set, and that results in a
warning on ARM allmodconfig builds:

drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers':
drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1208 bytes is larger than 1024 bytes [-Wframe-larger-than=]

It turns out that this is largely a result of a suboptimal implementation
of map_word_andequal(). Replacing this function with a straightforward
one reduces the stack size in this function by exactly 200 bytes,
shrinks the .text segment for this file from 27648 bytes to 26608 bytes,
and makes the warning go away.

Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

As the only comments I got for the "mtd: cfi: reduce stack size"
patch were about whitespace changes, it appears necessary to fix
up the rest of the file as well, which contains the exact same
mistakes.

Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

After commit 3e1d0bb ("audit: Convert int limit
uses to u32"), by converting an int to u32, few conditions will always evaluate
to false.

These warnings were emitted during compilation:

kernel/audit.c: In function ‘audit_set_enabled’:
kernel/audit.c:347:2: warning: comparison of unsigned expression < 0 is always
false [-Wtype-limits]
  if (state < AUDIT_OFF || state > AUDIT_LOCKED)
	  ^
	  kernel/audit.c: In function ‘audit_receive_msg’:
	  kernel/audit.c:880:9: warning: comparison of unsigned expression < 0 is
	  always false [-Wtype-limits]
	      if (s.backlog_wait_time < 0 ||

The following patch removes those unnecessary conditions.

Signed-off-by: Pranith Kumar <[email protected]>
Signed-off-by: Paul Moore <[email protected]>

Signed-off-by: Brian Norris <[email protected]>

Signed-off-by: Brian Norris <[email protected]>

Flash lock/unlock is a flash-specific operations. Factor out a callback
for it to more readily support other vendors.

Signed-off-by: Brian Norris <[email protected]>
Tested-by: VIET NGA DAO <[email protected]>

If a NAND device is not really present or pin muxes are not correctly
configured we can lock up the kernel waiting infinitely for NAND_STATUS
to be ready.

This can be easily reproduced on TI's DRA7-evm board by booting it
without NAND support in u-boot and disabling NAND pin muxes in the kernel.

Add timeout when waiting for NAND_CMD_RESET completion. As per ONFi v4.0
tRST can be upto 250ms for EZ-NAND and 5ms for raw NAND.

Signed-off-by: Roger Quadros <[email protected]>
Tested-by: Nishanth Menon <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

We know "rc" is set so there is no need to check again.

Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

Without this patch the timings are all set to 0 if not specified in the dts.
With this patch the driver falls back to use the defaults that are already
present in the driver and are known to work okay for some (older) boards.

Tested on a custom SPEAr600 based board.

Signed-off-by: Stefan Roese <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Cc: Viresh Kumar <[email protected]>
Cc: Mian Yousaf Kaukab <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

Two config options exist to define powerpc MPC8xx:
* CONFIG_PPC_8xx
* CONFIG_8xx
In addition, CONFIG_PPC_8xx also defines CONFIG_CPM1 as
communication co-processor

arch/powerpc/platforms/Kconfig.cputype has contained the following
comment about CONFIG_8xx item for some years:
"# this is temp to handle compat with arch=ppc"

It looks like not many places still have that old CONFIG_8xx used,
so it is likely to be a good time to get rid of it completely ?

Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.

Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

These lines were all indented one tab more than they should be.

Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

When displaying dev_err() messages it is useful to print the error value.

Signed-off-by: Fabio Estevam <[email protected]>
Acked-by: Han Xu <[email protected]>
[Brian: fix up "can not" at the same time]
Signed-off-by: Brian Norris <[email protected]>

return type of wait_for_completion_timeout is unsigned long not int, this
patch uses the return value of wait_for_completion_timeout in the condition
directly rather than adding a additional appropriately typed variable.

Signed-off-by: Nicholas Mc Guire <[email protected]>
Acked-by: Han Xu <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

return type of wait_for_completion_timeout is unsigned long not int. The
return variable is renamed to reflect its use and the type adjusted to
unsigned long.

Signed-off-by: Nicholas Mc Guire <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Acked-by: Huang Shijie <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

In case of scan_bbt() failure, we should better propagate it.

Signed-off-by: Fabio Estevam <[email protected]>
Acked-by: Huang Shijie <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

return type of wait_for_completion_timeout is unsigned long not int, this
patch uses the return value of wait_for_completion_timeout in the condition
directly rather than assigning it to an incorrect type variable.

The variable used for handling the return of wait_for_cmpletion_timeout
was int but should be unsigned long, where it was not in use for
anything else and the return value in case of completion (>0) is not
used it was removed and wait_for_completion_timeout() used directly in
the if condition.

To make the timeout values a bit simpler to read and also handle all of
the corner cases correctly the declarations are moved to
msecs_to_jiffies().

The timeout declaration cleanup is just for readability

Signed-off-by: Nicholas Mc Guire <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

The Denali Controller IP does not support sub-page writes.

Signed-off-by: Graham Moore <[email protected]>
Signed-off-by: Dinh Nguyen <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

This patch fixes a spelling typo in MODULE_DESCRIPTION in
ts5500_flash.c.

Signed-off-by: Masanari Iida <[email protected]>
[ Brian: fixed grammar in a spelling patch :) ]
Signed-off-by: Brian Norris <[email protected]>

For many use cases, it helps to have a device node for the entire
MTD device as well as device nodes for the individual partitions.
For example, this allows querying the entire device's properties.
A common idiom is to create an additional partition which spans
over the whole device.

This patch makes a config option, CONFIG_MTD_PARTITIONED_MASTER,
which makes the master partition present even when the device is
partitioned. This isn't turned on by default since it presents
a backwards-incompatible device numbering.

The patch also makes the parent of a partition device be the master,
if the config flag is set, now that the master is a full device.

Signed-off-by: Dan Ehrenberg <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

This patch makes a sysfs variable called 'offset' on each partition
which contains the offset in bytes from the beginning of the master
device that the partition starts.

Signed-off-by: Dan Ehrenberg <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

This patch makes MTD dynamic partitioning more flexible by removing
overlap checks for dynamic partitions. I don't see any  particular
reason why overlapping dynamic partitions should be prohibited while
static partitions are allowed to overlap freely.

The checks previously had an off-by-one error, where 'end' should be
one less than what it is currently set at, and adding partitions out of
increasing order will fail. Disabling the checks resolves this issue.

Signed-off-by: Dan Ehrenberg <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

It's better to use a macro instead of just a number.

Signed-off-by: Josh Wu <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

if atmel,pmecc-lookup-table-offset is not found in DT node, we don't
need to map the ROM table as we will build a runtime gf table anyway.

Reported-by: Nicolas Ferre <[email protected]>
Signed-off-by: Josh Wu <[email protected]>
Acked-by: Nicolas Ferre <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

This is only an API consolidation and should make things more readable
it replaces var * HZ / 1000 by msecs_to_jiffies(var) which helps readability
and also handles all corner-cases properly.

Signed-off-by: Nicholas Mc Guire <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

The .remove callback may be used when detaching a device via sysfs, so
we can't expect to free up this memory.

Signed-off-by: Brian Norris <[email protected]>
Acked-by: Robert Jarzmik <[email protected]>

In test case 3, we set vary_offset to write at different
offsets and lengths in the OOB available area. We need to
do the bitflip_limit check while checking for 0xff outside the
OOB offset + length area that we didn't modify during write.

Signed-off-by: Roger Quadros <[email protected]>
[Brian: whitespace fixup]
Signed-off-by: Brian Norris <[email protected]>

I always go nuts when I start an MTD test on a slow device and have to
wait forever until it finishes. From the debug output I already know
what the issue is but I have to wait or reset the board hard. Resetting
is often not an option (remote access, you don't want lose the current
state, etc...).

The solution is easy, check for pending signals at key positions in the
code. Using that one can even stop a test by pressing CTRL-C as
insmod/modprobe have SIGINT pending.

Signed-off-by: Richard Weinberger <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

Almost all flash that are "compatible" with m25p80 support the JEDEC
READ ID opcode (0x9F), and in fact, that is often the only thing that is
used to differentiate them. Let's add a compatible string that
represents this lowest common denominator of compatibility.

Device trees can still specify manufacturer/device names in addition,
but (until some reason is found to differentiate between them through
device tree) software will likely want to bind just against the generic
name, and avoid unnecessarily growing its device ID binding tables.

This is related to the work of commit a5b7616 ("mtd:
m25p80,spi-nor: Fix module aliases for m25p80"), which showed that
maintaining these device tables as stable device-tree/modalias binding
tables is not a worthwhile burden for mostly-comptatible flash.

At the same time, let's update the binding doc to point to the
m25p_ids[] ID list instead of spi_nor_ids[]. The former can be used for
device tree bindings, but the latter cannot. In the future, we should
pare down the m25p_ids[] list to only those IDs which are actually used
in device trees.

Signed-off-by: Brian Norris <[email protected]>
Cc: Rafał Miłecki <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>

Use the new 'nor-jedec' binding to provide automatic detection of flash
that use the 0x9F READ ID opcode. This can help for use cases where
platforms just specify compatibility with "m25p80", and then see
messages like this:

  m25p80 spi32766.0: found s25fl256s1, expected m25p80

Instead, they can just specify the generic string and see this:

  m25p80 spi32766.0: s25fl256s1 (32768 Kbytes)

Also, update the language about m25p_ids[] to straighten out the
expectations here. We should no longer need to continuously grow the
m25p_ids[] table, and in fact, we might want to start removing entries
which are not used in device trees so far, so we can just default to
auto-detection as much as possible in the future.

Signed-off-by: Brian Norris <[email protected]>
Cc: Rafał Miłecki <[email protected]>

Add support for EON en25s64 SPI flash.

Signed-off-by: Shengzhou Liu <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

Signed-off-by: Gabor Juhos <[email protected]>
Signed-off-by: Luka Perkov <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

Add Winbond (w25q64dw) 8MB flash to the list of supported chips.

Signed-off-by: Mika Westerberg <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

Add Macronix (mx25u6435f) 8MB flash to the list of supported chips.

Signed-off-by: Mika Westerberg <[email protected]>
Signed-off-by: Brian Norris <[email protected]>

If the SM rejects an alias GUID request the PF driver keeps trying to acquire
the specified GUID indefinitely, utilizing an exponential backoff scheme.

Retrying is managed per GUID entry. Each entry that wasn't applied holds its
next retry information. Retry requests to the SM consist of records of 8
consecutive GUIDS. Each record that contains GUIDs requiring retries holds its
next time-to-run based on the retry information of all its GUID entries. The
record having the lowest retry time will run first when that retry time
arrives.

Since the method (SET or DELETE) as sent to the SM applies to all the GUIDs in
the record, we must handle SET requests and DELETE requests in separate SM
messages (one for SETs and the other for DELETEs).

To avoid race conditions where a GUID entry request (set or delete) was
modified after the SM request was sent, we save the method and the requested
indices as part of the callback's context -- thus, only the requested indexes
are evaluated when the response is received.

When an GUID entry is approved we turn off its retry-required bit, this
prevents redundant SM retries from occurring on that record.

The port down event should be sent only when previously it was up. Likewise,
the port up event should be sent only if previously the port was down.

Synchronization was added around the flows that change entries and record state
to prevent race conditions.

Signed-off-by: Yishai Hadas <[email protected]>
Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

Manages alias GUIDs per VF per port in the core layer.

This is a pre-step for managing alias GUIDs in a mode that the admin
GUID is returned via ib_query_gid() regardless of whether the SM
has approved it or not.

Signed-off-by: Yishai Hadas <[email protected]>
Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

To have out of the box experience, the PF generates random GUIDs who
serve as the initial admin values.

Signed-off-by: Yishai Hadas <[email protected]>
Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

Set the admin alias GUID per the administrator's request via the sysfs
mechanism into the core layer.

The "get" request returns the current value. However, if the administrator
requests the SM to assign a new value by requesting 0, the SM assigned
GUID is returned.

Signed-off-by: Yishai Hadas <[email protected]>
Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

Change the init flow to ask GUIDs only for active VFs. This is done for
both SM & HOST modes so that there is no need any more to maintain the
ownership record type.

In case SM mode is used, the initial value will be 0, ask the SM to assign,
for the HOST mode the initial value will be the HOST generated GUID.

This will enable out of the box experience for both probed and attached VFs.

Signed-off-by: Yishai Hadas <[email protected]>
Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

Request GIDs from the SM on demand, i.e., when a VF actually needs them,
and release them when the GIDs are no longer in use.

In cloud environments, this is useful for GID migrations, in which a
GID is assigned to a VF on the destination HCA, while the VF on the
source HCA is shutdown (but the GID was not administratively released).

Signed-off-by: Yishai Hadas <[email protected]>
Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

There might be cases that PF doesn't get a "reset" command upon slave down
(e.g. virsh destroy). In these cases, however, an FLR event is issued.

Therefore, when the PF receives an FLR event for a slave, it should also
generate a shutdown event on the PF for that slave, to let the PF upper
layers (mlx4_ib, eth) perform any required cleanup/actions associated
with slave shutdown.

Signed-off-by: Yishai Hadas <[email protected]>
Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

Return the admin alias GUID value upon a GET request via HOST. We do this so
that the GUID value requested by the admin is returned even if the SM has not
yet approved this GUID (e.g. the SM is down).

Note that this does not create a problem, since the virtual port will remain
down until the SM does ACK the requested GUID value.

Signed-off-by: Yishai Hadas <[email protected]>
Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

Change the default mode to be HOST assigned instead of SM assigned. This is
the expected operational mode, because it doesn't depend on SM availability.

As PF generates random GUIDs as the initial admin values, this gives
out of the box experience.

Signed-off-by: Yishai Hadas <[email protected]>
Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

If ib_umem_get() is called with a size equal to 0 and an
non-page aligned address, one page will be pinned and a
0-sized umem will be returned to the caller.

This should not be allowed: it's not expected for a memory
region to have a size equal to 0.

This patch adds a check to explicitly refuse to register
a 0-sized region.

Link: http://mid.gmane.org/[email protected]
Cc: <[email protected]>
Cc: Shachar Raindel <[email protected]>
Cc: Jack Morgenstein <[email protected]>
Cc: Or Gerlitz <[email protected]>
Signed-off-by: Yann Droneaud <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

In a call to ib_umem_get(), if address is 0x0 and size is
already page aligned, check added in commit 8494057
("IB/uverbs: Prevent integer overflow in ib_umem_get address
arithmetic") will refuse to register a memory region that
could otherwise be valid (provided vm.mmap_min_addr sysctl
and mmap_low_allowed SELinux knobs allow userspace to map
something at address 0x0).

This patch allows back such registration: ib_umem_get()
should probably don't care of the base address provided it
can be pinned with get_user_pages().

There's two possible overflows, in (addr + size) and in
PAGE_ALIGN(addr + size), this patch keep ensuring none
of them happen while allowing to pin memory at address
0x0. Anyway, the case of size equal 0 is no more (partially)
handled as 0-length memory region are disallowed by an
earlier check.

Link: http://mid.gmane.org/[email protected]
Cc: <[email protected]> # 8494057 ("IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic")
Cc: Shachar Raindel <[email protected]>
Cc: Jack Morgenstein <[email protected]>
Cc: Or Gerlitz <[email protected]>
Signed-off-by: Yann Droneaud <[email protected]>
Reviewed-by: Sagi Grimberg <[email protected]>
Reviewed-by: Haggai Eran <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

Create a an ipoib_flush_ah and ipoib_stop_ah routines to use at
appropriate times to flush out all remaining ah entries before we shut
the device down.

Because neighbors and mcast entries can each have a reference on any
given ah, we must make sure to free all of those first before our ah
will actually have a 0 refcount and be able to be reaped.

This factoring is needed in preparation for having per-device work
queues.  The original per-device workqueue code resulted in the following
error message:

<ibdev>: ib_dealloc_pd failed

That error was tracked down to this issue.  With the changes to which
workqueues were flushed when, there were no flushes of the per device
workqueue after the last ah's were freed, resulting in an attempt to
dealloc the pd with outstanding resources still allocated.  This code
puts the explicit flushes in the needed places to avoid that problem.

Signed-off-by: Doug Ledford <[email protected]>

In preparation for using per device work queues, we need to move the
start of the neighbor thread task to after ipoib_ib_dev_init and move
the destruction of the neighbor task to before ipoib_ib_dev_cleanup.
Otherwise we will end up freeing our workqueue with work possibly
still on it.

Signed-off-by: Doug Ledford <[email protected]>

The ipoib_mcast_flush_dev routine is called with the rtnl_lock held and
needs to keep it held.  It also needs to call flush_workqueue() to flush
out any outstanding work.  In the past, we've had to try and make sure
that we didn't flush out any outstanding join completions because they
also wanted to grab rtnl_lock() and that would deadlock.  It turns out
that the only thing in the join completion handler that needs this lock
can be safely moved to our carrier_on_task, thereby reducing the
potential for the join completion code and the flush code to deadlock
against each other.

Signed-off-by: Doug Ledford <[email protected]>

We blindly assume that we can just take the rtnl lock and that will
prevent races with downing this interface.  Unfortunately, that's not
the case.  In ipoib_mcast_stop_thread() we will call flush_workqueue()
in an attempt to clear out all remaining instances of ipoib_join_task.
But, since this task is put on the same workqueue as the join task,
the flush_workqueue waits on this thread too.  But this thread is
deadlocked on the rtnl lock.  The better thing here is to use trylock
and loop on that until we either get the lock or we see that
FLAG_OPER_UP has been cleared, in which case we don't need to do
anything anyway and we just return.

While investigating which flag should be used, FLAG_ADMIN_UP or
FLAG_OPER_UP, it was determined that FLAG_OPER_UP was the more
appropriate flag to use.  However, there was a mix of these two flags in
use in the existing code.  So while we check for that flag here as part
of this race fix, also cleanup the two places that had used the less
appropriate flag for their tests.

Signed-off-by: Doug Ledford <[email protected]>

During my recent work on the rtnl lock deadlock in the IPoIB driver, I
saw that even once I fixed the apparent races for a single device, as
soon as that device had any children, new races popped up.  It turns
out that this is because no matter how well we protect against races
on a single device, the fact that all devices use the same workqueue,
and flush_workqueue() flushes *everything* from that workqueue means
that we would also have to prevent all races between different devices
(for instance, ipoib_mcast_restart_task on interface ib0 can race with
ipoib_mcast_flush_dev on interface ib0.8002, resulting in a deadlock on
the rtnl_lock).

There are several possible solutions to this problem:

Make carrier_on_task and mcast_restart_task try to take the rtnl for
some set period of time and if they fail, then bail.  This runs the
real risk of dropping work on the floor, which can end up being its
own separate kind of deadlock.

Set some global flag in the driver that says some device is in the
middle of going down, letting all tasks know to bail.  Again, this can
drop work on the floor.

Or the method this patch attempts to use, which is when we bring an
interface up, create a workqueue specifically for that interface, so
that when we take it back down, we are flushing only those tasks
associated with our interface.  In addition, keep the global
workqueue, but now limit it to only flush tasks.  In this way, the
flush tasks can always flush the device specific work queues without
having deadlock issues.

Signed-off-by: Doug Ledford <[email protected]>

Various places in the IPoIB code had a deadlock related to flushing
the ipoib workqueue.  Now that we have per device workqueues and a
specific flush workqueue, there is no longer a deadlock issue with
flushing the device specific workqueues and we can do so unilaterally.

Signed-off-by: Doug Ledford <[email protected]>

Commit a9c8ba5 ("IPoIB: Fix usage of uninitialized multicast
objects") added a new flag MCAST_JOIN_STARTED, but was not very strict
in how it was used.  We didn't always initialize the completion struct
before we set the flag, and we didn't always call complete on the
completion struct from all paths that complete it.  And when we did
complete it, sometimes we continued to touch the mcast entry after
the completion, opening us up to possible use after free issues.

This made it less than totally effective, and certainly made its use
confusing.  And in the flush function we would use the presence of this
flag to signal that we should wait on the completion struct, but we never
cleared this flag, ever.

In order to make things clearer and aid in resolving the rtnl deadlock
bug I've been chasing, I cleaned this up a bit.

 1) Remove the MCAST_JOIN_STARTED flag entirely
 2) Change MCAST_FLAG_BUSY so it now only means a join is in-flight
 3) Test mcast->mc directly to see if we have completed
    ib_sa_join_multicast (using IS_ERR_OR_NULL)
 4) Make sure that before setting MCAST_FLAG_BUSY we always initialize
    the mcast->done completion struct
 5) Make sure that before calling complete(&mcast->done), we always clear
    the MCAST_FLAG_BUSY bit
 6) Take the mcast_mutex before we call ib_sa_multicast_join and also
    take the mutex in our join callback.  This forces
    ib_sa_multicast_join to return and set mcast->mc before we process
    the callback.  This way, our callback can safely clear mcast->mc
    if there is an error on the join and we will do the right thing as
    a result in mcast_dev_flush.
 7) Because we need the mutex to synchronize mcast->mc, we can no
    longer call mcast_sendonly_join directly from mcast_send and
    instead must add sendonly join processing to the mcast_join_task
 8) Make MCAST_RUN mean that we have a working mcast subsystem, not that
    we have a running task.  We know when we need to reschedule our
    join task thread and don't need a flag to tell us.
 9) Add a helper for rescheduling the join task thread

A number of different races are resolved with these changes.  These
races existed with the old MCAST_FLAG_BUSY usage, the
MCAST_JOIN_STARTED flag was an attempt to address them, and while it
helped, a determined effort could still trip things up.

One race looks something like this:

Thread 1                             Thread 2
ib_sa_join_multicast (as part of running restart mcast task)
  alloc member
  call callback
                                     ifconfig ib0 down
				     wait_for_completion
    callback call completes
                                     wait_for_completion in
				     mcast_dev_flush completes
				       mcast->mc is PTR_ERR_OR_NULL
				       so we skip ib_sa_leave_multicast
    return from callback
  return from ib_sa_join_multicast
set mcast->mc = return from ib_sa_multicast

We now have a permanently unbalanced join/leave issue that trips up the
refcounting in core/multicast.c

Another like this:

Thread 1                   Thread 2         Thread 3
ib_sa_multicast_join
                                            ifconfig ib0 down
					    priv->broadcast = NULL
                           join_complete
			                    wait_for_completion
			   mcast->mc is not yet set, so don't clear
return from ib_sa_join_multicast and set mcast->mc
			   complete
			   return -EAGAIN (making mcast->mc invalid)
			   		    call ib_sa_multicast_leave
					    on invalid mcast->mc, hang
					    forever

By holding the mutex around ib_sa_multicast_join and taking the mutex
early in the callback, we force mcast->mc to be valid at the time we
run the callback.  This allows us to clear mcast->mc if there is an
error and the join is going to fail.  We do this before we complete
the mcast.  In this way, mcast_dev_flush always sees consistent state
in regards to mcast->mc membership at the time that the
wait_for_completion() returns.

Signed-off-by: Doug Ledford <[email protected]>

Allow the ipoib layer to attempt to join all outstanding multicast
groups at once.  The ib_sa layer will serialize multiple attempts to
join the same group, but will process attempts to join different groups
in parallel.  Take advantage of that.

In order to make this happen, change the mcast_join_thread to loop
through all needed joins, sending a join request for each one that we
still need to join.  There are a few special cases we handle though:

1) Don't attempt to join anything but the broadcast group until the join
of the broadcast group has succeeded.
2) No longer restart the join task at the end of completion handling.
If we completed successfully, we are done.  The join task now needs kicked
either by mcast_send or mcast_restart_task or mcast_start_thread, but
should not need started anytime else except when scheduling a backoff
attempt to rejoin.
3) No longer use separate join/completion routines for regular and
sendonly joins, pass them all through the same routine and just do the
right thing based on the SENDONLY join flag.
4) Only try to join a SENDONLY join twice, then drop the packets and
quit trying.  We leave the mcast group in the list so that if we get a
new packet, all that we have to do is queue up the packet and restart
the join task and it will automatically try to join twice and then
either send or flush the queue again.

Signed-off-by: Doug Ledford <[email protected]>

We needed the mcast_mutex when we had to prevent the join completion
callback from having the value it stored in mcast->mc overwritten
by a delayed return from ib_sa_join_multicast.  By storing the return
of ib_sa_join_multicast in an intermediate variable, we prevent a
delayed return from ib_sa_join_multicast overwriting the valid
contents of mcast->mc, and we no longer need a mutex to force the
join callback to run after the return of ib_sa_join_multicast.  This
allows us to do away with the mutex entirely and protect our critical
sections with a just a spinlock instead.  This is highly desirable
as there were some places where we couldn't use a mutex because the
code was not allowed to sleep, and so we were currently using a mix
of mutex and spinlock to protect what we needed to protect.  Now we
only have a spin lock and the locking complexity is greatly reduced.

Signed-off-by: Doug Ledford <[email protected]>

The current code in the RX flow uses two sg entries for each incoming
packet, the first one was for the IB headers and the second for the rest
of the data, that causes two  dma map/unmap and two allocations, and few
more actions that were done at the data path.

Use only one linear skb on each incoming packet, for the data (IB
headers and payload), that reduces the packet processing in the
data-path (only one skb, no frags, the first frag was not used anyway,
less memory allocations) and the dma handling (only one dma map/unmap
over each incoming packet instead of two map/unmap per each incoming packet).

After commit 73d3fe6 ("gro: fix aggregation for skb using frag_list") from
Eric Dumazet, we will get full aggregation for large packets.

When running bandwidth tests before and after the (over the card's numa node),
using "netperf -H 1.1.1.3 -T -t TCP_STREAM", the results before are ~12Gbs before
and after ~16Gbs on my setup (Mellanox's ConnectX3).

Signed-off-by: Erez Shitrit <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

…equest

Update the cached broadcast record in the priv object after every new
join of this broadcast domain group.

These values are needed for the port configuration (MTU size) and to
all the new multicast (non-broadcast) join requests initial parameters.

For example, SM starts with 2K MTU for all the fabric, and after that it
restarts (or handover to new SM) with new port configuration of 4K MTU.
Without using the new values, the driver will keep its old configuration
of 2K and will not apply the new configuration of 4K.

Signed-off-by: Erez Shitrit <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

As the result of a completion error the QP can moved to SQE state by
the hardware. Since it's not the Error state, there are no flushes
and hence the driver doesn't know about that.

The fix creates a task that after completion with error which is not a
flush tracks the QP state and if it is in SQE state moves it back to RTS.

Signed-off-by: Erez Shitrit <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

Whenever there is no path->ah to the destination, keep only defined
number of skb's. Otherwise there are cases that the driver can keep
infinite list of skb's.

For example, when one device want to send unicast arp to the destination,
and from some reason the SM doesn't respond, the driver currently keeps
all the skb's. If that unicast arp traffic stopped, all  these skb's
are kept by the path object till the interface is down.

Signed-off-by: Erez Shitrit <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

After Doug Ledford's changes there is no need in that bit, it's
semantic becomes subset of the IPOIB_FLAG_OPER_UP bit.

Signed-off-by: Erez Shitrit <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

The current code decreases from the mss size (which is the gso_size
from the kernel skb) the size of the packet headers.

It shouldn't do that because the mss that comes from the stack
(e.g IPoIB) includes only the tcp payload without the headers.

The result is indication to the HW that each packet that the HW sends
is smaller than what it could be, and too many packets will be sent
for big messages.

An easy way to demonstrate one more aspect of the problem is by
configuring the ipoib mtu to be less than 2*hlen (2*56) and then
run app sending big TCP messages. This will tell the HW to send packets
with giant (negative value which under unsigned arithmetics becomes
a huge positive one) length and the QP moves to SQE state.

Fixes: b832be1 ('IB/mlx4: Add IPoIB LSO support')
Reported-by: Matthew Finlay <[email protected]>
Signed-off-by: Erez Shitrit <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

Hello,

  When an application using XRCs abruptly terminates, the mmaped pages
of the CQ buffers are leaked.

  This comes from the fact that when resources are released in
ib_uverbs_cleanup_ucontext(), we fail to release the CQs because their
refcount is not 0.

  When creating an XRC SRQ, we increment the associated CQ refcount.
This refcount is only decremented when the SRQ is released.

  Therefore we need to release the SRQs prior to the CQs to make sure
that all references to the CQs are gone before trying to release these.

Signed-off-by: Sebastien Dugue <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

The ifconfig command has been deprecated for many years.
To encourage new users not to continue using it and learning
iproute2; the ifconfig should not be used in examples.

Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

Updating the MAINTAINERS file with ocrdma maintainers and their email ids

Signed-off-by: Selvin Xavier <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

Since ib_dma_map_single can fail use ib_dma_mapping_error to check
for errors.

Signed-off-by: Sebastian Ott <[email protected]>
Acked-by: Jack Morgenstein <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

This change slightly reduces the time needed to log in.

Signed-off-by: Bart Van Assche <[email protected]>
Reviewed-by: Sagi Grimberg <[email protected]>
Reviewed-by: David Dillow <[email protected]>
Cc: Sebastian Parschauer <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

The driver already defined the pr_format, it just hadn't
been converted to use pr_info, pr_warn, and pr_err instead
of the equivalent printks.  Convert so that messages from
the driver are now properly tagged with their driver name
and can be more easily debugged.

In addition, a number of these printk's were not newline
terminated, so fix that at the same time.

Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>

In case the user unloaded ib_iser while ep_connect is in
progress, we need to destroy the endpoint although ep_disconnect
wasn't invoked (we detect this by the iser conn state != DOWN).
However, if we got an REJECTED/UNREACHABLE CM event we move the
connection state to DOWN which will prevent us from destroying
the endpoint in the module unload stage. Fix this by setting the
connection state to TERMINATING in iser_conn_error so we can still
destroy the endpoint at unload stage.

Reported-by: Ariel Nahum <[email protected]>
Signed-off-by: Sagi Grimberg <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>