At the very least, we should not be taking the i_mutex until after
checking if the server even supports ALLOCATE or DEALLOCATE, allowing
v4.0 or v4.1 to exit without potentially waiting on a lock.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
This patch adds a GETATTR to the end of ALLOCATE and DEALLOCATE
operations so we can set the updated inode size and change attribute
directly. DEALLOCATE will still need to release pagecache pages, so
nfs42_proc_deallocate() now calls truncate_pagecache_range() before
contacting the server.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
instead.
Cc: Hyong-Youb Kim <hykim@myri.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: netdev@vger.kernel.org
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If NO_DMA=y:
drivers/built-in.o: In function `grcan_free_dma_buffers':
grcan.c:(.text+0x2d7716): undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `grcan_allocate_dma_buffers':
grcan.c:(.text+0x2d779c): undefined reference to `dma_alloc_coherent'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
If NO_DMA=y:
drivers/built-in.o: In function `arc_emac_tx_clean':
emac_main.c:(.text+0x2decde): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `arc_emac_rx':
emac_main.c:(.text+0x2dee1c): undefined reference to `dma_unmap_single'
emac_main.c:(.text+0x2dee72): undefined reference to `dma_map_single'
emac_main.c:(.text+0x2dee7e): undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `arc_emac_probe':
(.text+0x2df2ee): undefined reference to `dmam_alloc_coherent'
drivers/built-in.o: In function `arc_emac_open':
emac_main.c:(.text+0x2df6d8): undefined reference to `dma_map_single'
emac_main.c:(.text+0x2df6e4): undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `arc_emac_tx':
emac_main.c:(.text+0x2df9e4): undefined reference to `dma_map_single'
emac_main.c:(.text+0x2df9f0): undefined reference to `dma_mapping_error'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
If NO_DMA=y:
drivers/built-in.o: In function `xgbe_probe':
xgbe-main.c:(.text+0x2def0a): undefined reference to `dma_set_mask'
xgbe-main.c:(.text+0x2def20): undefined reference to `dma_supported'
drivers/built-in.o: In function `xgbe_rx_poll':
xgbe-drv.c:(.text+0x2e0320): undefined reference to `dma_sync_single_for_cpu'
xgbe-drv.c:(.text+0x2e035e): undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `xgbe_unmap_rdata':
xgbe-desc.c:(.text+0x2e5fe4): undefined reference to `dma_unmap_page'
xgbe-desc.c:(.text+0x2e5ffa): undefined reference to `dma_unmap_single'
xgbe-desc.c:(.text+0x2e604a): undefined reference to `dma_unmap_page'
xgbe-desc.c:(.text+0x2e6084): undefined reference to `dma_unmap_page'
drivers/built-in.o: In function `xgbe_alloc_pages':
xgbe-desc.c:(.text+0x2e6156): undefined reference to `dma_map_page'
xgbe-desc.c:(.text+0x2e6164): undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `xgbe_free_ring':
xgbe-desc.c:(.text+0x2e63d4): undefined reference to `dma_unmap_page'
xgbe-desc.c:(.text+0x2e640e): undefined reference to `dma_unmap_page'
xgbe-desc.c:(.text+0x2e644a): undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `xgbe_init_ring':
xgbe-desc.c:(.text+0x2e64d4): undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `xgbe_map_tx_skb':
xgbe-desc.c:(.text+0x2e6628): undefined reference to `dma_map_single'
xgbe-desc.c:(.text+0x2e6638): undefined reference to `dma_mapping_error'
xgbe-desc.c:(.text+0x2e66b2): undefined reference to `dma_map_single'
xgbe-desc.c:(.text+0x2e66c2): undefined reference to `dma_mapping_error'
xgbe-desc.c:(.text+0x2e6762): undefined reference to `dma_map_page'
xgbe-desc.c:(.text+0x2e6772): undefined reference to `dma_mapping_error'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The driver uses pinctrl directly and thus should include the appropriate
header. Sort the headers while we are here to have a better view what is
included and what is not.
Reported-by: Pascal Huerst <pascal.huerst@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Those symlinks are created for the mux_dev, so we need to remove it from
there. Currently, it breaks for muxes where the mux_dev is not the device
of the parent adapter like this:
[ 78.234644] WARNING: CPU: 0 PID: 365 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5c/0x78()
[ 78.242438] sysfs: cannot create duplicate filename '/devices/platform/i2cbus@8/channel-0'
Remove confusing comments while we are here.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: c9449affad
Cc: stable@kernel.org
And sort them to prevent this from happening again.
Reported-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Commit 523c5b8964 ("i2c: Remove support for legacy PM") removed the PM
ops from the bus type, which causes the pm operations on the s3c2410
adapter device to fail (-ENOSUPP in rpm_callback). The adapter device
doesn't get bound to a driver and as such can't have its own pm_runtime
callbacks. Previously this was fine as the bus callbacks would have been
used, but now this can cause devices which use PM runtime and are
attached over I2C to fail to resume.
This commit fixes this issue by marking all adapter devices with
pm_runtime_no_callbacks, since they can't have any.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Beata Michalska <b.michalska@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: 523c5b8964
Cc: stable@kernel.org
My Pengutronix address is not valid anymore, redirect people to the Pengutronix
kernel team.
Reported-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Robert Schwebel <r.schwebel@pengutronix.de>
My Pengutronix address is not valid anymore, redirect people to the Pengutronix
kernel team.
Reported-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Robert Schwebel <r.schwebel@pengutronix.de>
master_xfer() method should return number of i2c messages transferred,
but on Rockchip we were usually returning just 1, which caused trouble
with users that actually check number of transferred messages vs.
checking for negative error codes.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
fixed several comment and whitespace style issues
Signed-off-by: Jason Eastman <eastman.jason.linux@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Maloy says:
====================
tipc: three bug fixes
A set of unrelated corrections; one for the tipc netns implementation,
one regarding problems with random link resets, and one removing a
an erroneous refcount decrement when reading link statistsics via
netlink.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When link statistics is dumped over netlink, we iterate over
the list of peer nodes and append each links statistics to
the netlink msg. In the case where the dump is resumed after
filling up a nlmsg, the node refcnt is decremented without
having been incremented previously which may cause the node
reference to be freed. When this happens, the following
info/stacktrace will be generated, followed by a crash or
undefined behavior.
We fix this by removing the erroneous call to tipc_node_put
inside the loop that iterates over nodes.
[ 384.312303] INFO: trying to register non-static key.
[ 384.313110] the code is fine but needs lockdep annotation.
[ 384.313290] turning off the locking correctness validator.
[ 384.313290] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.0.0+ #13
[ 384.313290] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 384.313290] ffff88003c6d0290 ffff88003cc03ca8 ffffffff8170adf1 0000000000000007
[ 384.313290] ffffffff82728730 ffff88003cc03d38 ffffffff810a6a6d 00000000001d7200
[ 384.313290] ffff88003c6d0ab0 ffff88003cc03ce8 0000000000000285 0000000000000001
[ 384.313290] Call Trace:
[ 384.313290] <IRQ> [<ffffffff8170adf1>] dump_stack+0x4c/0x65
[ 384.313290] [<ffffffff810a6a6d>] __lock_acquire+0xf3d/0xf50
[ 384.313290] [<ffffffff810a7375>] lock_acquire+0xd5/0x290
[ 384.313290] [<ffffffffa0043e8c>] ? link_timeout+0x1c/0x170 [tipc]
[ 384.313290] [<ffffffffa0043e70>] ? link_state_event+0x4e0/0x4e0 [tipc]
[ 384.313290] [<ffffffff81712890>] _raw_spin_lock_bh+0x40/0x80
[ 384.313290] [<ffffffffa0043e8c>] ? link_timeout+0x1c/0x170 [tipc]
[ 384.313290] [<ffffffffa0043e8c>] link_timeout+0x1c/0x170 [tipc]
[ 384.313290] [<ffffffff810c4698>] call_timer_fn+0xb8/0x490
[ 384.313290] [<ffffffff810c45e0>] ? process_timeout+0x10/0x10
[ 384.313290] [<ffffffff810c5a2c>] run_timer_softirq+0x21c/0x420
[ 384.313290] [<ffffffffa0043e70>] ? link_state_event+0x4e0/0x4e0 [tipc]
[ 384.313290] [<ffffffff8105a954>] __do_softirq+0xf4/0x630
[ 384.313290] [<ffffffff8105afdd>] irq_exit+0x5d/0x60
[ 384.313290] [<ffffffff8103ade1>] smp_apic_timer_interrupt+0x41/0x50
[ 384.313290] [<ffffffff817144a0>] apic_timer_interrupt+0x70/0x80
[ 384.313290] <EOI> [<ffffffff8100db10>] ? default_idle+0x20/0x210
[ 384.313290] [<ffffffff8100db0e>] ? default_idle+0x1e/0x210
[ 384.313290] [<ffffffff8100e61a>] arch_cpu_idle+0xa/0x10
[ 384.313290] [<ffffffff81099803>] cpu_startup_entry+0x2c3/0x530
[ 384.313290] [<ffffffff810d2893>] ? clockevents_register_device+0x113/0x200
[ 384.313290] [<ffffffff81038b0f>] start_secondary+0x13f/0x170
Fixes: 8a0f6ebe84 ("tipc: involve reference counter for node structure")
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the function tipc_sk_rcv(), the stack variable 'err'
is only initialized to TIPC_ERR_NO_PORT for the first
iteration over the link input queue. If a chain of messages
are received from a link, failure to lookup the socket for
any but the first message will cause the message to bounce back
out on a random link.
We fix this by properly initializing err.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a new topology server is launched in a new namespace, its
listening socket is inserted into the "init ns" namespace's socket
hash table rather than the one owned by the new namespace. Although
the socket's namespace is forcedly changed to the new namespace later,
the socket is still stored in the socket hash table of "init ns"
namespace. When a client created in the new namespace connects
its own topology server, the connection is failed as its server's
socket could not be found from its own namespace's socket table.
If __sock_create() instead of original sock_create_kern() is used
to create the server's socket through specifying an expected namesapce,
the socket will be inserted into the specified namespace's socket
table, thereby avoiding to the topology server broken issue.
Fixes: 76100a8a64 ("tipc: fix netns refcnt leak")
Reported-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
AFAIK the PAPR document which defines the virtual device interface used by
the ibmveth driver doesn't specify a specific maximum MTU. So, in the
ibmveth driver, the maximum allowed MTU is determined by the maximum
allocated buffer size of 64k (corresponding to one page in the common case)
minus the per-buffer overhead IBMVETH_BUFF_OH (which has value 22 for 14
bytes of ethernet header, plus 8 bytes for an opaque handle).
This suggests a maximum allowable MTU of 65514 bytes, but in fact the
driver only permits a maximum MTU of 65513. This is because there is a <
instead of an <= in ibmveth_change_mtu(), which only permits an MTU which
is strictly smaller than the buffer size, rather than allowing the buffer
to be completely filled.
This patch fixes the buglet.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
With the CPU iteration variable called 'i', it's relatively easy
to have variable shadowing which sparse will warn about. Avoid
that by renaming the variable to __cpu which is less likely to
be used in the surrounding context.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove the function kgdb_post_primary_code() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Acked-by: Sonic Zhang <sonic.zhang@analog.com>
Rework of the prandom device with introduction of a new SHA-512 based
NIST SP 800-90 conform deterministic random bit generator.
Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
After the file ptes have been removed the bit combination used to
encode non-linear mappings can be reused for the swap ptes. This
frees up a precious pte software bit. Reflect the change in the
swap encoding in the comments and do some cleanup while we are
at it.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The dirty & young bit from the pmd is not copied correctly to the
pseudo pte in __pmd_to_pte. In fact it is not copied at all, the
bits get lost. As the old style huge page currently does not need
the dirty & young information this has no effect, but may be needed
in the future.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The new ebpf code uses e.g. the laal instruction which is part of the
interlocked-access facility 1 which again was introduced with z196.
So we must make sure the ebpf code generator depends on MARCH_Z196_FEATURES.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
If one memory allocation fails, there is a memory leak.
Signed-off-by: Christophe Jaillet <christophe.jaillet@wanadoo.fr>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Replacing a 2K page table with a 4K page table while a VMA is active
for the affected memory region is fundamentally broken. Rip out the
page table reallocation code and replace it with a simple system
control 'vm.allocate_pgste'. If the system control is set the page
tables for all processes are allocated as full 4K pages, even for
processes that do not need it.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Introduce KEXEC_CONTROL_MEMORY_GFP to allow the architecture code
to override the gfp flags of the allocation for the kexec control
page. The loop in kimage_alloc_normal_control_pages allocates pages
with GFP_KERNEL until a page is found that happens to have an
address smaller than the KEXEC_CONTROL_MEMORY_LIMIT. On systems
with a large memory size but a small KEXEC_CONTROL_MEMORY_LIMIT
the loop will keep allocating memory until the oom killer steps in.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Sometimes it fails to wake up from suspend to RAM, this is because
we would flush the data cache by assemble command FLUSHINV before
suspend to RAM, and there is a delay between this command execution
and cache flush completion. Add a 1uS delay to works around this.
Signed-off-by: Aaron Wu <Aaron.wu@analog.com>
Interacting with the USB_PHY_TEST MMR through debugfs was causing wide-spread
chaos in the realm (kernel panic). Expunge all references to this demonic
register.
Signed-off-by: Andre Wolokita <Andre.Wolokita@analog.com>
Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Steven Miao <realmz6@gmail.com>
For platforms that don't support DT, some early MFD modules can register
lookup tables. Remove the __init annotation so that this works. This is
similar to gpio_add_lookup_table() which allows late additions.
CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Switch default pcbeep path to Line in path.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Tested-by: Hui Wang <hui.wang@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The tom code should be using SND_SST_MFLD_PLATFORM and not the baytrail one.
So fix it now
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This fix the below build error
arch/powerpc/mm/hash_utils_64.c: In function ‘flush_hash_hugepage’:
arch/powerpc/mm/hash_utils_64.c:1381:1: error: label at end of compound statement
tm_abort:
^
make[1]: *** [arch/powerpc/mm/hash_utils_64.o] Error 1
Reported-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
These functions are used in various drivers, including the latest
version of the 8250 driver. The latter causes the following build
failure.
drivers/tty/serial/8250/8250_core.c: In function 'mem32be_serial_out':
drivers/tty/serial/8250/8250_core.c:456:2: error:
implicit declaration of function 'iowrite32be'
drivers/tty/serial/8250/8250_core.c: In function 'mem32be_serial_in':
drivers/tty/serial/8250/8250_core.c:462:2: error:
implicit declaration of function 'ioread32be'
Cc: Kevin Cernekee <cernekee@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes: c627f2ceb6 ("serial: 8250: Add support for big-endian MMIO
accesses")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Rob Herring <robh@kernel.org>
These functions are used in various drivers, including the latest
version of the 8250 driver. The latter causes the following build failure.
drivers/tty/serial/8250/8250_core.c: In function 'mem32be_serial_out':
drivers/tty/serial/8250/8250_core.c:456:2: error:
implicit declaration of function 'iowrite32be'
drivers/tty/serial/8250/8250_core.c: In function 'mem32be_serial_in':
drivers/tty/serial/8250/8250_core.c:462:2: error:
implicit declaration of function 'ioread32be'
Cc: Kevin Cernekee <cernekee@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes: c627f2ceb6 ("serial: 8250: Add support for big-endian MMIO
accesses")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Rob Herring <robh@kernel.org>
The return value of vxlan_fdb_replace always is greater than or equal to 0
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In 02c958dd3 (net/macb: add TX multiqueue support for gem), the
initialization of tx_head and tx_tail in macb_init_rings() was moved
inside the loop that iterates over each element in the ring. Since
tx_head and tx_tail only need to be assigned once, move them back out of
the loop.
Signed-off-by: Ben Shelton <ben.shelton@ni.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
