Clearly, hsync and vsinc bool vars are part of the return
logic on the second case of the switch. Annotate that, in
order to shut up gcc warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There are two cases here that it does a switch fall through.
Annotate it, in order to shut up gcc warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
On two switches, this driver have unannotated switch
fall through.
in the first case, it falls through a return. On the second
one, it prints undesired log messages on fall through.
Solve that by copying the commands that it should be
running. Gcc will very likely optimize it anyway, so this
sholdn't be causing any harm, and shuts up gcc warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The atomisp currently produce hundreds of warnings when W=1.
It is a known fact that this driver is currently in bad
shape, and there are lot of things to be done here.
We don't want to be bothered by those "minor" stuff for now,
while the driver doesn't receive a major cleanup. So,
disable those warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Gcc 7.1 complains that:
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c: In function 'mtk_vdec_pic_info_update':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:284:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
int ret;
^~~
Indeed, if debug is disabled, "ret" is never used. The best
fix for it seems to make the fuction to return an error code.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Gcc 7.1 complains about:
drivers/media/platform/s5p-jpeg/jpeg-core.c: In function 's5p_jpeg_parse_hdr.isra.9':
drivers/media/platform/s5p-jpeg/jpeg-core.c:1207:12: warning: 'width' may be used uninitialized in this function [-Wmaybe-uninitialized]
result->w = width;
~~~~~~~~~~^~~~~~~
drivers/media/platform/s5p-jpeg/jpeg-core.c:1208:12: warning: 'height' may be used uninitialized in this function [-Wmaybe-uninitialized]
result->h = height;
~~~~~~~~~~^~~~~~~~
Indeed the code would allow it to return a random value (although
it shouldn't happen, in practice). So, explicitly set both to zero,
just in case.
Acked-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Avoid warnings like those:
drivers/media/pci/ddbridge/ddbridge-core.c: In function 'dvb_input_detach':
drivers/media/pci/ddbridge/ddbridge-core.c:787:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (input->fe) {
^
drivers/media/pci/ddbridge/ddbridge-core.c:792:2: note: here
case 4:
^~~~
...
On several cases, it is just that gcc 7.1 is not capable of
understanding the comment, but on other places, we need an
annotation.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
When a REMOTE_KEY_PRESSED event happens, it does the right
thing. However, if debug is enabled, it will print a bogus
message warning that "key repeated".
Fix it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The logic that handles CA_SET_PID is clearly missing a
break: it prints that the command succeeded, but, due to the
missing break, it would be returning -EOPNOTSUPP, as if the
driver weren't supporting such ioctl.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Right now, the driver is doing the right thing for
PVC_ERRORCODE_UNKNOWN and PVC_ERRORCODE_INVALID_CONTROL:
for both, it returns an error code (SAA_ERR_NOT_SUPPORTED).
However, it is printing two error messages instead of one
on those cases.
Fix the logic.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There's a missing break for VSB16 modulation logic, with would
cause it to return -EINVAL, instead of handling it.
Fix it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
gcc-7 suggests that an expression using a bitwise not and a bitmask
on a 'bool' variable is better written using boolean logic:
drivers/media/rc/imon.c: In function 'imon_incoming_scancode':
drivers/media/rc/imon.c:1725:22: error: '~' on a boolean expression [-Werror=bool-operation]
ictx->pad_mouse = ~(ictx->pad_mouse) & 0x1;
^
drivers/media/rc/imon.c:1725:22: note: did you mean to use logical not?
I agree.
Fixes: 21677cfc56 ("V4L/DVB: ir-core: add imon driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This is a patch to the atomisp_tpg.c file that fixes up a missing
blank line warning found by the checkpatch.pl tool
Signed-off-by: Manny Vindiola <mannyv@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
We're putting the NUL terminators one space beyond where they belong.
This doesn't show up in testing because all but the callers put a NUL in
the correct place themselves. LOL. It causes a static checker warning
about buffer overflows.
Fixes: a49d25364d ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
We should verify that "ix < max_len" before we test whether we have
reached the NUL terminator.
Fixes: a49d25364d ("staging/atomisp: Add support for the Intel IPU v2")
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
With gcc-7.1.1 I was getting the following compile error:
error: ‘*’ in boolean context, suggest ‘&&’ instead
The problem is the definition of CEIL_DIV:
#define CEIL_DIV(a, b) ((b) ? ((a) + (b) - 1) / (b) : 0)
Which when called as: CEIL_DIV(x, y * z) triggers this error, note
we cannot do as the error suggests since b is evaluated multiple times.
This commit fixes these compile errors.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Fix sparse warnings: "symbol not declared; should it be static?"
Signed-off-by: Guru Das Srinagesh <gurooodas@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Fix for error (not warnings) reported by checkpatch.pl
Specifically:
- missing whitespace around "=" and after ","
- indentation with spaces instead of tabs
- lines starting with a whitespace
This patch does not affect the compiled code in any way.
Signed-off-by: Avraham Shukron <avraham.shukron@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Fixes a sparse warning:
drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c:35:5: warning: symbol 'qos' was not declared. Should it be static?
Signed-off-by: Valentin Vidic <Valentin.Vidic@CARNet.hr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The below mentioned fix contains a small but severe bug,
fix it to make the driver work again.
Fixes: 3538aa6ecf ("[media] tc358743: fix register i2c_rd/wr functions")
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Fix a link error in this specific combination of config options:
CONFIG_MEDIA_CEC_SUPPORT=y
CONFIG_CEC_CORE=m
CONFIG_MEDIA_CEC_NOTIFIER=y
CONFIG_VIDEO_STI_HDMI_CEC=m
CONFIG_DRM_STI=y
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_remove':
sti_hdmi.c:(.text.sti_hdmi_remove+0x10): undefined reference to
`cec_notifier_set_phys_addr'
sti_hdmi.c:(.text.sti_hdmi_remove+0x34): undefined reference to
`cec_notifier_put'
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_connector_get_modes':
sti_hdmi.c:(.text.sti_hdmi_connector_get_modes+0x4a): undefined
reference to `cec_notifier_set_phys_addr_from_edid'
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_probe':
sti_hdmi.c:(.text.sti_hdmi_probe+0x204): undefined reference to
`cec_notifier_get'
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_connector_detect':
sti_hdmi.c:(.text.sti_hdmi_connector_detect+0x36): undefined reference
to `cec_notifier_set_phys_addr'
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_disable':
sti_hdmi.c:(.text.sti_hdmi_disable+0xc0): undefined reference to
`cec_notifier_set_phys_addr'
The version below seems to work, though I don't particularly
like the IS_REACHABLE() addition since that can be confusing
to users.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
We should ensure that 'plane_no' is '< vb->num_planes' as done in
'vb2_plane_cookie' just a few lines below.
Fixes: e23ccc0ad9 ("[media] v4l: add videobuf2 Video for Linux 2 driver framework")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Remove including <linux/version.h> that is not needed.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The driver allocates the spinlock but not initialize it.
Use spin_lock_init() on it to initialize it correctly.
This is detected by Coccinelle semantic patch.
Fixes: 0f314f6c2e ("[media] rainshadow-cec: new RainShadow Tech HDMI
CEC driver")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The conversion from soc_camera omitted a correct handling of the clock
gating for a sensor. When the pxa_camera driver module was removed it
tried to unregister clk, but this caused a similar warning:
WARNING: CPU: 0 PID: 6740 at drivers/media/v4l2-core/v4l2-clk.c:278
v4l2_clk_unregister(): Refusing to unregister ref-counted 0-0030 clock!
The clock was at time still refcounted by the sensor driver. Before
the removing of the pxa_camera the clock must be dropped by the sensor
driver. This should be triggered by v4l2_async_notifier_unregister() call
which removes sensor driver module too, calls unbind() function and then
tries to probe sensor driver again. Inside unbind() we can safely
unregister the v4l2 clock as the sensor driver got removed. The original
v4l2_clk_unregister() should be put inside test as the clock can be
already unregistered from unbind(). If there was not any bound sensor
the clock is still present.
The codepath is practically a copy from the old soc_camera. The bug was
tested with a pxa_camera+ov9640 combination during the conversion
of the ov9640 from the soc_camera.
Signed-off-by: Petr Cvek <petr.cvek@tul.cz>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Changing the IS_REACHABLE() into a plain #ifdef broke the case of
CONFIG_MEDIA_RC=m && CONFIG_MEDIA_CEC=y:
drivers/media/cec/cec-core.o: In function `cec_unregister_adapter':
cec-core.c:(.text.cec_unregister_adapter+0x18): undefined reference to `rc_unregister_device'
drivers/media/cec/cec-core.o: In function `cec_delete_adapter':
cec-core.c:(.text.cec_delete_adapter+0x54): undefined reference to `rc_free_device'
drivers/media/cec/cec-core.o: In function `cec_register_adapter':
cec-core.c:(.text.cec_register_adapter+0x94): undefined reference to `rc_register_device'
cec-core.c:(.text.cec_register_adapter+0xa4): undefined reference to `rc_free_device'
cec-core.c:(.text.cec_register_adapter+0x110): undefined reference to `rc_unregister_device'
drivers/media/cec/cec-core.o: In function `cec_allocate_adapter':
cec-core.c:(.text.cec_allocate_adapter+0x234): undefined reference to `rc_allocate_device'
drivers/media/cec/cec-adap.o: In function `cec_received_msg':
cec-adap.c:(.text.cec_received_msg+0x734): undefined reference to `rc_keydown'
cec-adap.c:(.text.cec_received_msg+0x768): undefined reference to `rc_keyup'
This adds an additional dependency to explicitly forbid this combination.
Fixes: 5f2c467c54 ("[media] cec: add MEDIA_CEC_RC config option")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The barrier implied by spin_unlock() in rain_irq_work_handler makes it hard
for gcc to figure out the state of the variables, leading to a false-positive
warning:
drivers/media/usb/rainshadow-cec/rainshadow-cec.c: In function 'rain_irq_work_handler':
drivers/media/usb/rainshadow-cec/rainshadow-cec.c:171:31: error: 'data' may be used uninitialized in this function [-Werror=maybe-uninitialized]
Slightly rearranging the code makes it easier for the compiler to see that the
code is correct, and gets rid of the warning.
Fixes: 0f314f6c2e ("[media] rainshadow-cec: new RainShadow Tech HDMI CEC driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
gcc warns about an obviously incorrect use of strncat():
drivers/media/usb/rainshadow-cec/rainshadow-cec.c: In function 'rain_cec_adap_transmit':
drivers/media/usb/rainshadow-cec/rainshadow-cec.c:299:4: error: specified bound 48 equals the size of the destination [-Werror=stringop-overflow=]
It seems that strlcat was intended here, and using that makes the
code correct.
Fixes: 0f314f6c2e ("[media] rainshadow-cec: new RainShadow Tech HDMI CEC driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
ir_lirc_register() currently creates its own lirc_buffer before
passing the lirc_driver to lirc_register_driver().
When a module is later unloaded, ir_lirc_unregister() gets called
which performs a call to lirc_unregister_driver() and then free():s
the lirc_buffer.
The problem is that:
a) there can still be a userspace app holding an open lirc fd
when lirc_unregister_driver() returns; and
b) the lirc_buffer contains "wait_queue_head_t wait_poll" which
is potentially used as long as any userspace app is still around.
The result is an oops which can be triggered quite easily by a
userspace app monitoring its lirc fd using epoll() and not closing
the fd promptly on device removal.
The minimalistic fix is to let lirc_dev create the lirc_buffer since
lirc_dev will then also free the buffer once it believes it is safe to
do so.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The call to input_register_device() needs to take place
before the repeat parameters are set or the input subsystem
repeat handling will be disabled (as was already noted in
the comments in that function).
Cc: stable <stable@vger.kernel.org> # v4.11
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Since this driver does no detection of hardware, it might be used with
a non-sir port. Escape out if we are spinning.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Several atomisp files use:
ccflags-y += -Werror
As, on media, our usual procedure is to use W=1, and atomisp
has *a lot* of warnings with such flag enabled,like:
./drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/host/system_local.h:62:26: warning: 'DDR_BASE' defined but not used [-Wunused-const-variable=]
At the end, it causes our build to fail, impacting our workflow.
So, remove this crap. If one wants to force -Werror, he
can still build with it enabled by passing a parameter to
make.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJZF2pwAAoJEHm+PkMAQRiG9aAIAJJyV6Ux9kaX+glqO3KIs0wm
0K/yqMOv1JTfJ1UUgY4iZbk5XOPPmXv1bdKJFECZfuAHdymJUF/RVNNvDlZbaLdd
K8vDEi92eRwcf07a5b/Q2F8yNfADKKmRAA/oAbuQLBhJ0dPHig70PIvi9gq9kqiE
Ft1MinbsZLavYatLm7oVDr/nsYebEDMGwTy0EX5bF2YjydfAlCvVWnI5ld5wisiV
0fQF4W7MMjjcpAzG8uq3atEB8iQcWS2Ykz2chZRbYzHcdV2WJW751Vge9xc05Hzi
rxlqn6peZFiFyM0qdPLhY0ktGzSTZcCFeb3aZicvm5aOamy2KJjOSZrEwjU8kts=
=VHpx
-----END PGP SIGNATURE-----
Merge tag 'v4.12-rc1' into patchwork
Linux 4.12-rc1
* tag 'v4.12-rc1': (13212 commits)
Linux 4.12-rc1
mm, docs: update memory.stat description with workingset* entries
mm: vmscan: scan until it finds eligible pages
mm, thp: copying user pages must schedule on collapse
dax: fix PMD data corruption when fault races with write
dax: fix data corruption when fault races with write
ext4: return to starting transaction in ext4_dax_huge_fault()
mm: fix data corruption due to stale mmap reads
dax: prevent invalidation of mapped DAX entries
Tigran has moved
mm, vmalloc: fix vmalloc users tracking properly
mm/khugepaged: add missed tracepoint for collapse_huge_page_swapin
gcov: support GCC 7.1
mm, vmstat: Remove spurious WARN() during zoneinfo print
time: delete current_fs_time()
hwpoison, memcg: forcibly uncharge LRU pages
sound: Disable the build of OSS drivers
drm/i915: Make vblank evade warnings optional
Input: cros_ec_keyb - remove extraneous 'const'
drm/nouveau/therm: remove ineffective workarounds for alarm bugs
...
Pull some more input subsystem updates from Dmitry Torokhov:
"An updated xpad driver with a few more recognized device IDs, and a
new psxpad-spi driver, allowing connecting Playstation 1 and 2 joypads
via SPI bus"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: cros_ec_keyb - remove extraneous 'const'
Input: add support for PlayStation 1/2 joypads connected via SPI
Input: xpad - add USB IDs for Mad Catz Brawlstick and Razer Sabertooth
Input: xpad - sync supported devices with xboxdrv
Input: xpad - sort supported devices by USB ID
Pull UML fixes from Richard Weinberger:
"No new stuff, just fixes"
* 'for-linus-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml:
um: Add missing NR_CPUS include
um: Fix to call read_initrd after init_bootmem
um: Include kbuild.h instead of duplicating its macros
um: Fix PTRACE_POKEUSER on x86_64
um: Set number of CPUs
um: Fix _print_addr()
Merge misc fixes from Andrew Morton:
"15 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
mm, docs: update memory.stat description with workingset* entries
mm: vmscan: scan until it finds eligible pages
mm, thp: copying user pages must schedule on collapse
dax: fix PMD data corruption when fault races with write
dax: fix data corruption when fault races with write
ext4: return to starting transaction in ext4_dax_huge_fault()
mm: fix data corruption due to stale mmap reads
dax: prevent invalidation of mapped DAX entries
Tigran has moved
mm, vmalloc: fix vmalloc users tracking properly
mm/khugepaged: add missed tracepoint for collapse_huge_page_swapin
gcov: support GCC 7.1
mm, vmstat: Remove spurious WARN() during zoneinfo print
time: delete current_fs_time()
hwpoison, memcg: forcibly uncharge LRU pages
Commit 4b4cea91691d ("mm: vmscan: fix IO/refault regression in cache
workingset transition") introduced three new entries in memory stat
file:
- workingset_refault
- workingset_activate
- workingset_nodereclaim
This commit adds a corresponding description to the cgroup v2 docs.
Link: http://lkml.kernel.org/r/1494530293-31236-1-git-send-email-guro@fb.com
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Li Zefan <lizefan@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We have encountered need_resched warnings in __collapse_huge_page_copy()
while doing {clear,copy}_user_highpage() over HPAGE_PMD_NR source pages.
mm->mmap_sem is held for write, but the iteration is well bounded.
Reschedule as needed.
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1705101426380.109808@chino.kir.corp.google.com
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is based on a patch from Jan Kara that fixed the equivalent race in
the DAX PTE fault path.
Currently DAX PMD read fault can race with write(2) in the following
way:
CPU1 - write(2) CPU2 - read fault
dax_iomap_pmd_fault()
->iomap_begin() - sees hole
dax_iomap_rw()
iomap_apply()
->iomap_begin - allocates blocks
dax_iomap_actor()
invalidate_inode_pages2_range()
- there's nothing to invalidate
grab_mapping_entry()
- we add huge zero page to the radix tree
and map it to page tables
The result is that hole page is mapped into page tables (and thus zeros
are seen in mmap) while file has data written in that place.
Fix the problem by locking exception entry before mapping blocks for the
fault. That way we are sure invalidate_inode_pages2_range() call for
racing write will either block on entry lock waiting for the fault to
finish (and unmap stale page tables after that) or read fault will see
already allocated blocks by write(2).
Fixes: 9f141d6ef6 ("dax: Call ->iomap_begin without entry lock during dax fault")
Link: http://lkml.kernel.org/r/20170510172700.18991-1-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently DAX read fault can race with write(2) in the following way:
CPU1 - write(2) CPU2 - read fault
dax_iomap_pte_fault()
->iomap_begin() - sees hole
dax_iomap_rw()
iomap_apply()
->iomap_begin - allocates blocks
dax_iomap_actor()
invalidate_inode_pages2_range()
- there's nothing to invalidate
grab_mapping_entry()
- we add zero page in the radix tree
and map it to page tables
The result is that hole page is mapped into page tables (and thus zeros
are seen in mmap) while file has data written in that place.
Fix the problem by locking exception entry before mapping blocks for the
fault. That way we are sure invalidate_inode_pages2_range() call for
racing write will either block on entry lock waiting for the fault to
finish (and unmap stale page tables after that) or read fault will see
already allocated blocks by write(2).
Fixes: 9f141d6ef6
Link: http://lkml.kernel.org/r/20170510085419.27601-5-jack@suse.cz
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
DAX will return to locking exceptional entry before mapping blocks for a
page fault to fix possible races with concurrent writes. To avoid lock
inversion between exceptional entry lock and transaction start, start
the transaction already in ext4_dax_huge_fault().
Fixes: 9f141d6ef6
Link: http://lkml.kernel.org/r/20170510085419.27601-4-jack@suse.cz
Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently, we didn't invalidate page tables during invalidate_inode_pages2()
for DAX. That could result in e.g. 2MiB zero page being mapped into
page tables while there were already underlying blocks allocated and
thus data seen through mmap were different from data seen by read(2).
The following sequence reproduces the problem:
- open an mmap over a 2MiB hole
- read from a 2MiB hole, faulting in a 2MiB zero page
- write to the hole with write(3p). The write succeeds but we
incorrectly leave the 2MiB zero page mapping intact.
- via the mmap, read the data that was just written. Since the zero
page mapping is still intact we read back zeroes instead of the new
data.
Fix the problem by unconditionally calling invalidate_inode_pages2_range()
in dax_iomap_actor() for new block allocations and by properly
invalidating page tables in invalidate_inode_pages2_range() for DAX
mappings.
Fixes: c6dcf52c23
Link: http://lkml.kernel.org/r/20170510085419.27601-3-jack@suse.cz
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
