| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Many simple, block-based filesystems use generic_file_fsync as their
fsync operation. Some others (ext* and fat) also call this function
to handle syncing out data.
Switch this code over to use errseq_t based error reporting so that
all of these filesystems get reliable error reporting via fsync,
fdatasync and msync.
Signed-off-by: Jeff Layton <[email protected]>
|
|
This is a very minimal conversion to errseq_t based error tracking
for raw block device access. Just have it use the standard
file_write_and_wait_range call.
Note that there are internal callers that call sync_blockdev
and the like that are not affected by this. They'll continue
to use the AS_EIO/AS_ENOSPC flags for error reporting like
they always have for now.
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
|
|
Jan Kara's description for this patch is much better than mine, so I'm
quoting it verbatim here:
DAX currently doesn't set errors in the mapping when cache flushing
fails in dax_writeback_mapping_range(). Since this function can get
called only from fsync(2) or sync(2), this is actually as good as it can
currently get since we correctly propagate the error up from
dax_writeback_mapping_range() to filemap_fdatawrite()
However, in the future better writeback error handling will enable us to
properly report these errors on fsync(2) even if there are multiple file
descriptors open against the file or if sync(2) gets called before
fsync(2). So convert DAX to using standard error reporting through the
mapping.
Signed-off-by: Jeff Layton <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-and-tested-by: Ross Zwisler <[email protected]>
|
|
writeback errors
Let's try to make this extra clear for fs authors.
Cc: Jan Kara <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
|
|
When a writeback error occurs, we want later callers to be able to pick
up that fact when they go to wait on that writeback to complete.
Traditionally, we've used AS_EIO/AS_ENOSPC flags to track that, but
that's problematic since only one "checker" will be informed when an
error occurs.
In later patches, we're going to want to convert many of these callers
to check for errors since a well-defined point in time. For now, ensure
that we can handle both sorts of checks by both setting errors in both
places when there is a writeback failure.
Signed-off-by: Jeff Layton <[email protected]>
|
|
Most filesystems currently use mapping_set_error and
filemap_check_errors for setting and reporting/clearing writeback errors
at the mapping level. filemap_check_errors is indirectly called from
most of the filemap_fdatawait_* functions and from
filemap_write_and_wait*. These functions are called from all sorts of
contexts to wait on writeback to finish -- e.g. mostly in fsync, but
also in truncate calls, getattr, etc.
The non-fsync callers are problematic. We should be reporting writeback
errors during fsync, but many places spread over the tree clear out
errors before they can be properly reported, or report errors at
nonsensical times.
If I get -EIO on a stat() call, there is no reason for me to assume that
it is because some previous writeback failed. The fact that it also
clears out the error such that a subsequent fsync returns 0 is a bug,
and a nasty one since that's potentially silent data corruption.
This patch adds a small bit of new infrastructure for setting and
reporting errors during address_space writeback. While the above was my
original impetus for adding this, I think it's also the case that
current fsync semantics are just problematic for userland. Most
applications that call fsync do so to ensure that the data they wrote
has hit the backing store.
In the case where there are multiple writers to the file at the same
time, this is really hard to determine. The first one to call fsync will
see any stored error, and the rest get back 0. The processes with open
fds may not be associated with one another in any way. They could even
be in different containers, so ensuring coordination between all fsync
callers is not really an option.
One way to remedy this would be to track what file descriptor was used
to dirty the file, but that's rather cumbersome and would likely be
slow. However, there is a simpler way to improve the semantics here
without incurring too much overhead.
This set adds an errseq_t to struct address_space, and a corresponding
one is added to struct file. Writeback errors are recorded in the
mapping's errseq_t, and the one in struct file is used as the "since"
value.
This changes the semantics of the Linux fsync implementation such that
applications can now use it to determine whether there were any
writeback errors since fsync(fd) was last called (or since the file was
opened in the case of fsync having never been called).
Note that those writeback errors may have occurred when writing data
that was dirtied via an entirely different fd, but that's the case now
with the current mapping_set_error/filemap_check_error infrastructure.
This will at least prevent you from getting a false report of success.
The new behavior is still consistent with the POSIX spec, and is more
reliable for application developers. This patch just adds some basic
infrastructure for doing this, and ensures that the f_wb_err "cursor"
is properly set when a file is opened. Later patches will change the
existing code to use this new infrastructure for reporting errors at
fsync time.
Signed-off-by: Jeff Layton <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
|
|
An errseq_t is a way of recording errors in one place, and allowing any
number of "subscribers" to tell whether an error has been set again
since a previous time.
It's implemented as an unsigned 32-bit value that is managed with atomic
operations. The low order bits are designated to hold an error code
(max size of MAX_ERRNO). The upper bits are used as a counter.
The API works with consumers sampling an errseq_t value at a particular
point in time. Later, that value can be used to tell whether new errors
have been set since that time.
Note that there is a 1 in 512k risk of collisions here if new errors
are being recorded frequently, since we have so few bits to use as a
counter. To mitigate this, one bit is used as a flag to tell whether the
value has been sampled since a new value was recorded. That allows
us to avoid bumping the counter if no one has sampled it since it
was last bumped.
Later patches will build on this infrastructure to change how writeback
errors are tracked in the kernel.
Signed-off-by: Jeff Layton <[email protected]>
Reviewed-by: NeilBrown <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
|
|
The -EIO returned here can end up overriding whatever error is marked in
the address space, and be returned at fsync time, even when there is a
more appropriate error stored in the mapping.
Read errors are also sometimes tracked on a per-page level using
PG_error. Suppose we have a read error on a page, and then that page is
subsequently dirtied by overwriting the whole page. Writeback doesn't
clear PG_error, so we can then end up successfully writing back that
page and still return -EIO on fsync.
Worse yet, PG_error is cleared during a sync() syscall, but the -EIO
return from that is silently discarded. Any subsystem that is relying on
PG_error to report errors during fsync can easily lose writeback errors
due to this. All you need is a stray sync() call to wait for writeback
to complete and you've lost the error.
Since the handling of the PG_error flag is somewhat inconsistent across
subsystems, let's just rely on marking the address space when there are
writeback errors. Change the TestClearPageError call to ClearPageError,
and make __filemap_fdatawait_range a void return function.
Signed-off-by: Jeff Layton <[email protected]>
|
|
filemap_write_and_wait{_range} will return an error if writeback
initiation fails, but won't clear errors in the address_space. This is
particularly problematic on DAX, as filemap_fdatawrite* is
effectively synchronous there. Ensure that we clear the AS_EIO/AS_ENOSPC
flags when filemap_fdatawrite* returns an error.
Signed-off-by: Jeff Layton <[email protected]>
|
|
Resetting this flag is almost certainly racy, and will be problematic
with some coming changes.
Make filemap_fdatawait_keep_errors return int, but not clear the flag(s).
Have jbd2 call it instead of filemap_fdatawait and don't attempt to
re-set the error flag if it fails.
Reviewed-by: Jan Kara <[email protected]>
Reviewed-by: Carlos Maiolino <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
|
|
I noticed on xfs that I could still sometimes get back an error on fsync
on a fd that was opened after the error condition had been cleared.
The problem is that the buffer code sets the write_io_error flag and
then later checks that flag to set the error in the mapping. That flag
perisists for quite a while however. If the file is later opened with
O_TRUNC, the buffers will then be invalidated and the mapping's error
set such that a subsequent fsync will return error. I think this is
incorrect, as there was no writeback between the open and fsync.
Add a new mark_buffer_write_io_error operation that sets the flag and
the error in the mapping at the same time. Replace all calls to
set_buffer_write_io_error with mark_buffer_write_io_error, and remove
the places that check this flag in order to set the error in the
mapping.
This sets the error in the mapping earlier, at the time that it's first
detected.
Signed-off-by: Jeff Layton <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Reviewed-by: Carlos Maiolino <[email protected]>
|
|
ext2 currently does a test+clear of the AS_EIO flag, which is
is problematic for some coming changes.
What we really need to do instead is call filemap_check_errors
in __generic_file_fsync after syncing out the buffers. That
will be sufficient for this case, and help other callers detect
these errors properly as well.
With that, we don't need to twiddle it in ext2.
Suggested-by: Jan Kara <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Reviewed-by: Matthew Wilcox <[email protected]>
|
|
Signed-off-by: Jeff Layton <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Reviewed-by: Matthew Wilcox <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
|
|
The error code should be negative. Since this ends up in the default case
anyway, this is harmless, but it's less confusing to negate it. Also,
later patches will require a negative error code here.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Jeff Layton <[email protected]>
Reviewed-by: Ross Zwisler <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Reviewed-by: Matthew Wilcox <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: Wolfram Sang <[email protected]>
Acked-by: Daniel Thompson <[email protected]>
Acked-by: Bartlomiej Zolnierkiewicz <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
include/linux/i2c is not for client devices.
Move the header file to a more appropriate location.
Signed-off-by: Wolfram Sang <[email protected]>
Acked-by: Daniel Thompson <[email protected]>
Acked-by: Michael Hennerich <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
The LP87565 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Configurable Bucks(Single and multi-phase).
- Configurable General Purpose Output Signals (GPO).
The LP87565-Q1 variant device uses two 2-phase outputs configuration,
Buck0 is master for Buck0/1 output and Buck2 is master for Buck2/3
output.
Signed-off-by: Keerthy <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Currently we request the irq when probing, but never free it. So after
unbind ec driver, this irq will be left requested, which would break
the next bind:
[ 2683.338437] genirq: Flags mismatch irq 64. 00002008 (chromeos-ec) vs. 00002008 (chromeos-ec)
[ 2683.338591] cros-ec-spi spi5.0: request irq 64: error -16
[ 2683.338610] cros-ec-spi spi5.0: cannot register EC
[ 2683.338656] cros-ec-spi: probe of spi5.0 failed with error -16
Signed-off-by: Jeffy Chen <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Acked-by: Rob Herring <[email protected]>
Reviewed-by: Jingoo Han <[email protected]>
Signed-off-by: Olimpiu Dejeu <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Remove the register DA9062AA_BBAT_CONT (0x0C5) from the DA9061 chip model
regmap access ranges. This applies to both da9061_aa_readable_ranges[]
and da9061_aa_writeable_ranges[].
This change is to correct the DA9061 chip model and align it with the
latest DA9061 Datasheet.
This register previously appeared in the DA9061 Datasheet, Revision 3.2,
01-Mar-2016 and has been removed from later DA9061 datasheet from Dialog,
Revision 3.3, 04-Apr-2017.
Signed-off-by: Steve Twiss <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Remove the register DA9062AA_BBAT_CONT (0x0C5) from the DA9061 chip model
regmap access ranges. This applies to both da9061_aa_readable_ranges[]
and da9061_aa_writeable_ranges[].
This change is to correct the DA9061 chip model and align it with the
latest DA9061 Datasheet.
This register previously appeared in the DA9061 Datasheet, Revision 3.2,
01-Mar-2016 and has been removed from later DA9061 datasheet from Dialog,
Revision 3.3, 04-Apr-2017.
Signed-off-by: Steve Twiss <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
On x86 the AXP288 PMIC provides an ACPI OpRegion handler, which must be
available before other drivers using it are loaded, which can only be
ensured if the MFD, OpRegion and i2c-bus drivers are built-in.
Since the AXP20x MFD code is used on non x86 too we cannot simply change
this into a bool, I've tried some Kconfig magic with if x86 but I could
not get this working correctly, so this commit just documents that this
should be built-in on x86, which fixes errors like these during boot:
mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
ACPI Error: No handler for Region [REGS] (ffff93543b0cc3a8) [UserDefinedRegion]
ACPI Error: Region UserDefinedRegion (ID=143) has no handler (20170119/exfldio-2
ACPI Error: Method parse/execution failed [\_SB.PCI0.I2C7.PMI5.GET] (Node ffff93
ACPI Error: Method parse/execution failed [\_SB.PCI0.SHC1._PS0] (Node ffff93543b
acpi 80860F14:02: Failed to change power state to D0
Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Chen-Yu Tsai <[email protected]>
Tested-by: russianneuromancer <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Add mfd driver for Intel CHT Whiskey Cove PMIC, based on various non
upstreamed CHT Whiskey Cove PMIC patches.
This is a somewhat minimal version which adds irqchip support and cells
for: ACPI PMIC opregion support, the i2c-controller driving the external
charger irc and the pwrsrc/extcon block.
Further cells can be added in the future if/when drivers are upstreamed
for them.
[The above patch caused a build error on some archetectures]
From: Arnd Bergmann <[email protected]>
I ran into a build error on ARM with a platform that has a non-standard
clk implementation:
drivers/clk/clk.o: In function `clk_disable':
clk.c:(.text.clk_disable+0x0): multiple definition of `clk_disable'
arch/arm/mach-omap1/clock.o:clock.c:(.text.clk_disable+0x0): first defined here
drivers/clk/clk.o: In function `clk_enable':
clk.c:(.text.clk_enable+0x0): multiple definition of `clk_enable'
arch/arm/mach-omap1/clock.o:clock.c:(.text.clk_enable+0x0): first defined here
The problem is a device driver that uses 'select COMMON_CLK', which is
generally a bad idea: selecting a subsystem should only be done from
a platform, otherwise we run into circular dependencies. The same driver
also selects 'GPIOLIB' and 'I2C', which has a similar effect.
This turns all three into 'depends on', as it should be.
Finally, we can limit the build to x86, unless we are compile testing.
First patch:
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Fix for first patch (squashed):
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
The SIMATIC IOT2020 and IOT2040 are derived from the Galileo Gen2 board
and share its I2C frequency.
Signed-off-by: Sascha Weisenberger <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Avoids reimplementation of DMI matching in intel_quark_i2c_setup.
Signed-off-by: Jan Kiszka <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Usage of devm_of_platform_populate() simplify driver code
by allowing to delete cpcap_remove().
Signed-off-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Use devm_of_platform_populate() to be sure that of_platform_depopulate
is called when removing the driver.
Signed-off-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Usage of devm_of_platform_populate() simplify driver code
by allowing to delete pmic_spmi_remove().
Signed-off-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Use devm_of_platform_populate() to be sure that of_platform_depopulate
is called when removing the driver.
Signed-off-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Use devm_of_platform_populate() to be sure that of_platform_depopulate
is called when removing the driver.
Signed-off-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Use devm_of_platform_populate() to be sure that of_platform_depopulate
is called when removing the driver.
Signed-off-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Use devm_of_platform_populate() to be sure that of_platform_depopulate
is called when removing the driver.
Signed-off-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Use devm_of_platform_populate() to be sure that of_platform_depopulate
is called when removing the driver.
Signed-off-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Use devm_of_platform_populate() instead of of_platform_populate()
and suppress stm32_timers_remove() which become useless.
Signed-off-by: Benjamin Gaignard <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
The Crystal Cove PMIC provides an ACPI OPRegion handler, which must be
available before other drivers using it are loaded, which is why
INTEL_SOC_PMIC is a bool.
Just having the driver is not enough, the driver for the i2c-bus must
also be built in, to ensure this, this patch adds a select for it.
This fixes errors like these during boot:
mmc0: SDHCI controller on ACPI [80860F14:00] using ADMA
ACPI Error: No handler for Region [REGS] (ffff93543b0cc3a8) [UserDefinedRegion] (20170119/evregion-166)
ACPI Error: Region UserDefinedRegion (ID=143) has no handler (20170119/exfldio-299)
ACPI Error: Method parse/execution failed [\_SB.PCI0.I2C7.PMI5.GET] (Node ffff93543b0cde10), AE_NOT_EXIST (20170119/psparse-543)
ACPI Error: Method parse/execution failed [\_SB.PCI0.SHC1._PS0] (Node ffff93543b0b5cd0), AE_NOT_EXIST (20170119/psparse-543)
acpi 80860F14:02: Failed to change power state to D0
While at it this patch also changes the human readable name of the Kconfig
option to make clear the INTEL_SOC_PMIC option selects support for the
Intel Crystal Cove PMIC and documents why this is a bool.
[The above patch caused a build error on some archetectures]
From: Arnd Bergmann <[email protected]>
I ran into a build error on ARM with a platform that has a non-standard
clk implementation:
drivers/clk/clk.o: In function `clk_disable':
clk.c:(.text.clk_disable+0x0): multiple definition of `clk_disable'
arch/arm/mach-omap1/clock.o:clock.c:(.text.clk_disable+0x0): first defined here
drivers/clk/clk.o: In function `clk_enable':
clk.c:(.text.clk_enable+0x0): multiple definition of `clk_enable'
arch/arm/mach-omap1/clock.o:clock.c:(.text.clk_enable+0x0): first defined here
The problem is a device driver that uses 'select COMMON_CLK', which is
generally a bad idea: selecting a subsystem should only be done from
a platform, otherwise we run into circular dependencies. The same driver
also selects 'GPIOLIB' and 'I2C', which has a similar effect.
This turns all three into 'depends on', as it should be.
Finally, we can limit the build to x86, unless we are compile testing.
First patch:
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Fix for first patch (squashed):
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Additions to search terms for files supported by Dialog Semiconductor.
This update will allow Dialog support to follow files for device tree
bindings (onkey, thermal and watchdog) and source code for chip thermal
monitoring drivers.
Signed-off-by: Steve Twiss <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
struct irq_domain_ops is not modified, so it can be made const.
Signed-off-by: Tobias Klauser <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
found
As silently failing isn't that nice, emit an error message at a place
that was silent on failure up to now.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Link to the generic GPIO specifier bindings now that the second cell of
the binding has some support in the driver.
Signed-off-by: Charles Keepax <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Add NULL check before dereferencing pointer of_id in order to avoid
a potential NULL pointer dereference.
Addresses-Coverity-ID: 1408830
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Add NULL check before dereferencing pointer of_id in order to avoid
a potential NULL pointer dereference.
Addresses-Coverity-ID: 1408829
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
The request should be resent when DMA transfer error occurred.
For rts5227, the clock rate needs to be reduced when error occurred.
Signed-off-by: Steven Feng <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
As axp20x-regulator now supports AXP803, add a cell for it.
Signed-off-by: Icenowy Zheng <[email protected]>
Acked-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Remove the restart handler registered in probe on device remove.
Fixes: a370f60a58ec ("mfd: rn5t618: Register restart handler")
Signed-off-by: Stefan Agner <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Since a copy of the pdata was added into the core struct in
commit f6dd8449cd50 ("mfd: wm831x: Add basic device tree binding")
the pdata pointer in probe can no longer be NULL. As such remove
the redundant checks for this case.
Signed-off-by: Charles Keepax <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
These hexdumps get printed no matter if CONFIG_DEBUG is set or
not. Just get rid of them.
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Intel Cannonlake PCH has the same LPSS than Intel Kabylake. Add the new IDs
to the list of supported devices.
Signed-off-by: Mika Westerberg <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Signed-off-by: Al Viro <[email protected]>
|
|
When a CIFS filesystem is mounted with the forcemand option and the
following command is run on it, lockdep warns about a circular locking
dependency between CifsInodeInfo::lock_sem and the inode lock.
while echo foo > hello; do :; done & while touch -c hello; do :; done
cifs_writev() takes the locks in the wrong order, but note that we can't
only flip the order around because it releases the inode lock before the
call to generic_write_sync() while it holds the lock_sem across that
call.
But, AFAICS, there is no need to hold the CifsInodeInfo::lock_sem across
the generic_write_sync() call either, so we can release both the locks
before generic_write_sync(), and change the order.
======================================================
WARNING: possible circular locking dependency detected
4.12.0-rc7+ #9 Not tainted
------------------------------------------------------
touch/487 is trying to acquire lock:
(&cifsi->lock_sem){++++..}, at: cifsFileInfo_put+0x88f/0x16a0
but task is already holding lock:
(&sb->s_type->i_mutex_key#11){+.+.+.}, at: utimes_common+0x3ad/0x870
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sb->s_type->i_mutex_key#11){+.+.+.}:
__lock_acquire+0x1f74/0x38f0
lock_acquire+0x1cc/0x600
down_write+0x74/0x110
cifs_strict_writev+0x3cb/0x8c0
__vfs_write+0x4c1/0x930
vfs_write+0x14c/0x2d0
SyS_write+0xf7/0x240
entry_SYSCALL_64_fastpath+0x1f/0xbe
-> #0 (&cifsi->lock_sem){++++..}:
check_prevs_add+0xfa0/0x1d10
__lock_acquire+0x1f74/0x38f0
lock_acquire+0x1cc/0x600
down_write+0x74/0x110
cifsFileInfo_put+0x88f/0x16a0
cifs_setattr+0x992/0x1680
notify_change+0x61a/0xa80
utimes_common+0x3d4/0x870
do_utimes+0x1c1/0x220
SyS_utimensat+0x84/0x1a0
entry_SYSCALL_64_fastpath+0x1f/0xbe
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&sb->s_type->i_mutex_key#11);
lock(&cifsi->lock_sem);
lock(&sb->s_type->i_mutex_key#11);
lock(&cifsi->lock_sem);
*** DEADLOCK ***
2 locks held by touch/487:
#0: (sb_writers#10){.+.+.+}, at: mnt_want_write+0x41/0xb0
#1: (&sb->s_type->i_mutex_key#11){+.+.+.}, at: utimes_common+0x3ad/0x870
stack backtrace:
CPU: 0 PID: 487 Comm: touch Not tainted 4.12.0-rc7+ #9
Call Trace:
dump_stack+0xdb/0x185
print_circular_bug+0x45b/0x790
__lock_acquire+0x1f74/0x38f0
lock_acquire+0x1cc/0x600
down_write+0x74/0x110
cifsFileInfo_put+0x88f/0x16a0
cifs_setattr+0x992/0x1680
notify_change+0x61a/0xa80
utimes_common+0x3d4/0x870
do_utimes+0x1c1/0x220
SyS_utimensat+0x84/0x1a0
entry_SYSCALL_64_fastpath+0x1f/0xbe
Fixes: 19dfc1f5f2ef03a52 ("cifs: fix the race in cifs_writev()")
Signed-off-by: Rabin Vincent <[email protected]>
Signed-off-by: Steve French <[email protected]>
Acked-by: Pavel Shilovsky <[email protected]>
|