aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-07-06Merge tag 'leds_for_4.13' of ↵Linus Torvalds9-237/+34
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds Pull LED updates from Jacek Anaszewski: "This time we're removing more than adding: Removed drivers: leds-versatile: - all users of the Versatile LED driver are deleted and replaced with the very generic leds-syscon leds-sead3: - SEAD3 is using the generic leds-syscon & regmap based register-bit-led driver LED class drivers improvements: ledtrig-gpio: - use threaded IRQ, which both simplifies the code because we can drop the workqueue indirection, and it enables using the trigger for GPIOs that work with threaded IRQs themselves - refresh LED state after GPIO change since the new GPIO may have a different state than the old one leds-lp55xx: - make various arrays static const leds-pca963x: - add bindings to invert polarity" * tag 'leds_for_4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: leds: lp55xx: make various arrays static const leds: Remove SEAD-3 driver leds: trigger: gpio: Use threaded IRQ leds: trigger: gpio: Refresh LED state after GPIO change leds: Delete obsolete Versatile driver leds: pca963x: Add bindings to invert polarity
2017-07-06Merge tag 'media/v4.13-1' of ↵Linus Torvalds348-5135/+40503
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media updates from Mauro Carvalho Chehab: - addition of fwnode support at V4L2 core - addition of a few more SDR formats - new imx driver to support i.MX6 cameras - new driver for Qualcon venus codecs - new I2C sensor drivers: dw9714, max2175, ov13858, ov5640 - new CEC driver: stm32-cec - some improvements to DVB frontend documentation and a few fixups - several driver improvements and fixups * tag 'media/v4.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (361 commits) [media] media: entity: Catch unbalanced media_pipeline_stop calls [media] media/uapi/v4l: clarify cropcap/crop/selection behavior [media] v4l2-ioctl/exynos: fix G/S_SELECTION's type handling [media] vimc: sen: Declare vimc_sen_video_ops as static [media] vimc: sca: Add scaler [media] vimc: deb: Add debayer filter [media] vimc: Subdevices as modules [media] vimc: cap: Support several image formats [media] vimc: sen: Support several image formats [media] vimc: common: Add vimc_colorimetry_clamp [media] vimc: common: Add vimc_link_validate [media] vimc: common: Add vimc_pipeline_s_stream helper [media] vimc: common: Add vimc_ent_sd_* helper [media] vimc: Move common code from the core [media] vimc: sen: Integrate the tpg on the sensor [media] media: i2c: ov772x: Force use of SCCB protocol [media] dvb uapi docs: enums are passed by value, not reference [media] dvb: don't use 'time_t' in event ioctl [media] media: venus: enable building with COMPILE_TEST [media] af9013: refactor power control ...
2017-07-06Merge tag 'sound-4.13-rc1' of ↵Linus Torvalds349-5620/+13826
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound updates from Takashi Iwai: "This development cycle resulted in a fair amount of changes in both core and driver sides. The most significant change in ALSA core is about PCM. Also the support of of-graph card and the new DAPM widget for DSP are noteworthy changes in ASoC core. And there're lots of small changes splat over the tree, as you can see in diffstat. Below are a few highlights: ALSA core: - Removal of set_fs() hackery from PCM core stuff, and the code reorganization / optimization thereafter - Improved support of PCM ack ops, and a new ABI for improved control/status mmap handling - Lots of constifications in various codes ASoC core: - The support of of-graph card, which may work as a better generic device for a replacement of simple-card - New widget types intended mainly for use with DSPs ASoC drivers: - New drivers for Allwinner V3s SoCs - Ensonic ES8316 codec support - More Intel SKL and KBL works - More device support for Intel SST Atom (mostly for cheap tablets and 2-in-1 devices) - Support for Rockchip PDM controllers - Support for STM32 I2S and S/PDIF controllers - Support for ZTE AUD96P22 codecs HD-audio: - Support of new Realtek codecs (ALC215/ALC285/ALC289), more quirks for HP and Dell machines - A few more fixes for i915 component binding" * tag 'sound-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (418 commits) ALSA: hda - Fix unbalance of i915 module refcount ASoC: Intel: Skylake: Remove driver debugfs exit ASoC: Intel: Skylake: explicitly add the headers sst-dsp.h ALSA: hda/realtek - Remove GPIO_MASK ALSA: hda/realtek - Fix typo of pincfg for Dell quirk ALSA: pcm: add a documentation for tracepoints ALSA: atmel: ac97c: fix error return code in atmel_ac97c_probe() ALSA: x86: fix error return code in hdmi_lpe_audio_probe() ASoC: Intel: Skylake: Add support to read firmware registers ASoC: Intel: Skylake: Add sram address to sst_addr structure ASoC: Intel: Skylake: Debugfs facility to dump module config ASoC: Intel: Skylake: Add debugfs support ASoC: fix semicolon.cocci warnings ASoC: rt5645: Add quirk override by module option ASoC: rsnd: make arrays path and cmd_case static const ASoC: audio-graph-card: add widgets and routing for external amplifier support ASoC: audio-graph-card: update bindings for amplifier support ASoC: rt5665: calibration should be done before jack detection ASoC: rsnd: constify dev_pm_ops structures. ASoC: nau8825: change crosstalk-bypass property to bool type ...
2017-07-06Merge branch 'for-4.13' of ↵Linus Torvalds8-201/+548
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup changes from Tejun Heo: - Waiman made the debug controller work and a lot more useful on cgroup2 - There were a couple issues with cgroup subtree delegation. The documentation on delegating to a non-root user was missing some part and cgroup namespace support wasn't factoring in delegation at all. The documentation is updated and the now there is a mount option to make cgroup namespace fit for delegation * 'for-4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup: implement "nsdelegate" mount option cgroup: restructure cgroup_procs_write_permission() cgroup: "cgroup.subtree_control" should be writeable by delegatee cgroup: fix lockdep warning in debug controller cgroup: refactor cgroup_masks_read() in the debug controller cgroup: make debug an implicit controller on cgroup2 cgroup: Make debug cgroup support v2 and thread mode cgroup: Make Kconfig prompt of debug cgroup more accurate cgroup: Move debug cgroup to its own file cgroup: Keep accurate count of tasks in each css_set
2017-07-06Merge branch 'for-4.13' of ↵Linus Torvalds36-236/+1589
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata Pull libata updates from Tejun Heo: - Christoph added support for TCG OPAL self encrypting disks - Minwoo added support for ATA PASS-THROUGH(32) - Linus Walleij removed spurious drvdata assignments in some drivers - Support for a few new device and other fixes * 'for-4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata: (33 commits) sd: add support for TCG OPAL self encrypting disks libata: fix build warning from unused goto label libata: Support for an ATA PASS-THROUGH(32) command. ahci: Add Device ID for ASMedia 1061R and 1062R sata_via: Enable optional hotplug on VT6420 ata: ahci_brcm: Avoid writing to read-only registers libata: Add the AHCI_HFLAG_NO_WRITE_TO_RO flag libata: Add the AHCI_HFLAG_YES_ALPM flag ata: ftide010: fix resource printing libata: make the function name in comment match the actual function ata: sata_rcar: make of_device_ids const. ata: pata_octeon_cf: make of_device_ids const. libata: Convert bare printks to pr_cont libahci: wrong comments in ahci_do_softreset() ata: declare ata_port_info structures as const ata: Add driver for Faraday Technology FTIDE010 ata: Add DT bindings for the Gemini SATA bridge ata: Add DT bindings for Faraday Technology FTIDE010 libata: implement SECURITY PROTOCOL IN/OUT libata: factor out a ata_identify_page_supported helper ...
2017-07-06Merge branch 'for-4.13' of ↵Linus Torvalds19-70/+621
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu Pull percpu updates from Tejun Heo: "These are the percpu changes for the v4.13-rc1 merge window. There are a couple visibility related changes - tracepoints and allocator stats through debugfs, along with __ro_after_init markings and a cosmetic rename in percpu_counter. Please note that the simple O(#elements_in_the_chunk) area allocator used by percpu allocator is again showing scalability issues, primarily with bpf allocating and freeing large number of counters. Dennis is working on the replacement allocator and the percpu allocator will be seeing increased churns in the coming cycles" * 'for-4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu: percpu: fix static checker warnings in pcpu_destroy_chunk percpu: fix early calls for spinlock in pcpu_stats percpu: resolve err may not be initialized in pcpu_alloc percpu_counter: Rename __percpu_counter_add to percpu_counter_add_batch percpu: add tracepoint support for percpu memory percpu: expose statistics about percpu memory via debugfs percpu: migrate percpu data structures to internal header percpu: add missing lockdep_assert_held to func pcpu_free_area mark most percpu globals as __ro_after_init
2017-07-06vrf: fix bug_on triggered by rx when destroying a vrfNikolay Aleksandrov1-5/+6
When destroying a VRF device we cleanup the slaves in its ndo_uninit() function, but that causes packets to be switched (skb->dev == vrf being destroyed) even though we're pass the point where the VRF should be receiving any packets while it is being dismantled. This causes a BUG_ON to trigger if we have raw sockets (trace below). The reason is that the inetdev of the VRF has been destroyed but we're still sending packets up the stack with it, so let's free the slaves in the dellink callback as David Ahern suggested. Note that this fix doesn't prevent packets from going up when the VRF device is admin down. [ 35.631371] ------------[ cut here ]------------ [ 35.631603] kernel BUG at net/ipv4/fib_frontend.c:285! [ 35.631854] invalid opcode: 0000 [#1] SMP [ 35.631977] Modules linked in: [ 35.632081] CPU: 2 PID: 22 Comm: ksoftirqd/2 Not tainted 4.12.0-rc7+ #45 [ 35.632247] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 35.632477] task: ffff88005ad68000 task.stack: ffff88005ad64000 [ 35.632632] RIP: 0010:fib_compute_spec_dst+0xfc/0x1ee [ 35.632769] RSP: 0018:ffff88005ad67978 EFLAGS: 00010202 [ 35.632910] RAX: 0000000000000001 RBX: ffff880059a7f200 RCX: 0000000000000000 [ 35.633084] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff82274af0 [ 35.633256] RBP: ffff88005ad679f8 R08: 000000000001ef70 R09: 0000000000000046 [ 35.633430] R10: ffff88005ad679f8 R11: ffff880037731cb0 R12: 0000000000000001 [ 35.633603] R13: ffff8800599e3000 R14: 0000000000000000 R15: ffff8800599cb852 [ 35.634114] FS: 0000000000000000(0000) GS:ffff88005d900000(0000) knlGS:0000000000000000 [ 35.634306] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 35.634456] CR2: 00007f3563227095 CR3: 000000000201d000 CR4: 00000000000406e0 [ 35.634632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 35.634865] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 35.635055] Call Trace: [ 35.635271] ? __lock_acquire+0xf0d/0x1117 [ 35.635522] ipv4_pktinfo_prepare+0x82/0x151 [ 35.635831] raw_rcv_skb+0x17/0x3c [ 35.636062] raw_rcv+0xe5/0xf7 [ 35.636287] raw_local_deliver+0x169/0x1d9 [ 35.636534] ip_local_deliver_finish+0x87/0x1c4 [ 35.636820] ip_local_deliver+0x63/0x7f [ 35.637058] ip_rcv_finish+0x340/0x3a1 [ 35.637295] ip_rcv+0x314/0x34a [ 35.637525] __netif_receive_skb_core+0x49f/0x7c5 [ 35.637780] ? lock_acquire+0x13f/0x1d7 [ 35.638018] ? lock_acquire+0x15e/0x1d7 [ 35.638259] __netif_receive_skb+0x1e/0x94 [ 35.638502] ? __netif_receive_skb+0x1e/0x94 [ 35.638748] netif_receive_skb_internal+0x74/0x300 [ 35.639002] ? dev_gro_receive+0x2ed/0x411 [ 35.639246] ? lock_is_held_type+0xc4/0xd2 [ 35.639491] napi_gro_receive+0x105/0x1a0 [ 35.639736] receive_buf+0xc32/0xc74 [ 35.639965] ? detach_buf+0x67/0x153 [ 35.640201] ? virtqueue_get_buf_ctx+0x120/0x176 [ 35.640453] virtnet_poll+0x128/0x1c5 [ 35.640690] net_rx_action+0x103/0x343 [ 35.640932] __do_softirq+0x1c7/0x4b7 [ 35.641171] run_ksoftirqd+0x23/0x5c [ 35.641403] smpboot_thread_fn+0x24f/0x26d [ 35.641646] ? sort_range+0x22/0x22 [ 35.641878] kthread+0x129/0x131 [ 35.642104] ? __list_add+0x31/0x31 [ 35.642335] ? __list_add+0x31/0x31 [ 35.642568] ret_from_fork+0x2a/0x40 [ 35.642804] Code: 05 bd 87 a3 00 01 e8 1f ef 98 ff 4d 85 f6 48 c7 c7 f0 4a 27 82 41 0f 94 c4 31 c9 31 d2 41 0f b6 f4 e8 04 71 a1 ff 45 84 e4 74 02 <0f> 0b 0f b7 93 c4 00 00 00 4d 8b a5 80 05 00 00 48 03 93 d0 00 [ 35.644342] RIP: fib_compute_spec_dst+0xfc/0x1ee RSP: ffff88005ad67978 Fixes: 193125dbd8eb ("net: Introduce VRF device driver") Reported-by: Chris Cormier <[email protected]> Signed-off-by: Nikolay Aleksandrov <[email protected]> Acked-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-07-06move file_{start,end}_write() out of do_iter_write()Al Viro1-2/+4
... and do *not* grab it in vfs_write_iter(). Fixes: "fs: implement vfs_iter_read using do_iter_read" Signed-off-by: Al Viro <[email protected]>
2017-07-06Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller3-0/+15
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains two Netfilter fixes for your net tree, they are: 1) Fix memleak from netns release path of conntrack protocol trackers, patch from Liping Zhang. 2) Uninitialized flags field in ebt_log, that results in unpredictable logging format in ebtables, also from Liping. ==================== Signed-off-by: David S. Miller <[email protected]>
2017-07-06btrfs: minimal conversion to errseq_t writeback error reporting on fsyncJeff Layton1-5/+8
Just check and advance the errseq_t in the file before returning, and use an errseq_t based check for writeback errors. Other internal callers of filemap_* functions are left as-is. Signed-off-by: Jeff Layton <[email protected]>
2017-07-06xfs: minimal conversion to errseq_t writeback error reportingJeff Layton1-1/+1
Just check and advance the data errseq_t in struct file before before returning from fsync on normal files. Internal filemap_* callers are left as-is. Reviewed-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jeff Layton <[email protected]>
2017-07-06ext4: use errseq_t based error handling for reporting data writeback errorsJeff Layton1-1/+1
Add a call to filemap_report_wb_err at the end of ext4_sync_file. This will ensure that we check and advance the errseq_t in the file, which allows us to track and report errors on all open fds when they occur. Signed-off-by: Jeff Layton <[email protected]>
2017-07-06fs: convert __generic_file_fsync to use errseq_t based reportingJeff Layton1-4/+6
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]>
2017-07-06block: convert to errseq_t based writeback error trackingJeff Layton1-1/+1
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]>
2017-07-06dax: set errors in mapping when writeback failsJeff Layton1-1/+3
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]>
2017-07-06Documentation: flesh out the section in vfs.txt on storing and reporting ↵Jeff Layton1-3/+41
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]>
2017-07-06mm: set both AS_EIO/AS_ENOSPC and errseq_t in mapping_set_errorJeff Layton1-6/+25
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]>
2017-07-06fs: new infrastructure for writeback error handling and reportingJeff Layton7-1/+206
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]>
2017-07-06lib: add errseq_t type and infrastructure for handling itJeff Layton4-1/+234
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]>
2017-07-06mm: don't TestClearPageError in __filemap_fdatawait_rangeJeff Layton1-15/+5
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]>
2017-07-06mm: clear AS_EIO/AS_ENOSPC when writeback initiation failsJeff Layton1-0/+6
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]>
2017-07-06jbd2: don't clear and reset errors after waiting on writebackJeff Layton3-15/+19
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]>
2017-07-06buffer: set errors in mapping at the time that the error occursJeff Layton3-8/+15
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]>
2017-07-06fs: check for writeback errors after syncing out buffers in generic_file_fsyncJeff Layton2-5/+4
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]>
2017-07-06buffer: use mapping_set_error instead of setting the flagJeff Layton1-1/+1
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]>
2017-07-06mm: fix mapping_set_error call in me_pagecache_dirtyJeff Layton1-1/+1
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]>
2017-07-06ptp: dte: Use LL suffix for 64-bit constantsGeert Uytterhoeven1-1/+1
With gcc 4.1.2: drivers/ptp/ptp_dte.c: In function ‘dte_write_nco_delta’: drivers/ptp/ptp_dte.c:105: warning: integer constant is too large for ‘long’ type drivers/ptp/ptp_dte.c:112: warning: integer constant is too large for ‘long’ type drivers/ptp/ptp_dte.c:114: warning: integer constant is too large for ‘long’ type Add the missing "LL" suffix to fix this. Fixes: 8a56aa107f1e8123 ("ptp: Add a ptp clock driver for Broadcom DTE") Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-07-06sctp: set the value of flowi6_oif to sk_bound_dev_if to make sctp_v6_get_dst ↵Zheng Li1-0/+2
to find the correct route entry. if there are several same route entries with different outgoing net device, application's socket specifies the oif through setsockopt with SO_BINDTODEVICE, sctpv6 should choose the route entry whose outgoing net device is the oif which was specified by socket, set the value of flowi6_oif to sk->sk_bound_dev_if to make sctp_v6_get_dst to find the correct route entry. Signed-off-by: Zheng Li <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-07-06TLS: Fix length check in do_tls_getsockopt_tx()Matthias Rosenfelder1-1/+1
copy_to_user() copies the struct the pointer is pointing to, but the length check compares against sizeof(pointer) and not sizeof(struct). On 32-bit the size is probably the same, so it might have worked accidentally. Signed-off-by: Matthias Rosenfelder <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-07-06tcp: md5: tcp_md5_do_lookup_exact() can be staticWu Fengguang1-3/+3
Fixes: 6797318e623d ("tcp: md5: add an address prefix for key lookup") Signed-off-by: Fengguang Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-07-06net: ipv6: Compare lwstate in detecting duplicate nexthopsDavid Ahern3-11/+10
Lennert reported a failure to add different mpls encaps in a multipath route: $ ip -6 route add 1234::/16 \ nexthop encap mpls 10 via fe80::1 dev ens3 \ nexthop encap mpls 20 via fe80::1 dev ens3 RTNETLINK answers: File exists The problem is that the duplicate nexthop detection does not compare lwtunnel configuration. Add it. Fixes: 19e42e451506 ("ipv6: support for fib route lwtunnel encap attributes") Signed-off-by: David Ahern <[email protected]> Reported-by: João Taveira Araújo <[email protected]> Reported-by: Lennert Buytenhek <[email protected]> Acked-by: Roopa Prabhu <[email protected]> Tested-by: Lennert Buytenhek <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-07-06liquidio: fix bug in soft reset failure detectionDerek Chickles2-2/+2
The code that detects a failed soft reset of Octeon is comparing the wrong value against the reset value of the Octeon SLI_SCRATCH_1 register, resulting in an inability to detect a soft reset failure. Fix it by using the correct value in the comparison, which is any non-zero value. Fixes: f21fb3ed364b ("Add support of Cavium Liquidio ethernet adapters") Fixes: c0eab5b3580a ("liquidio: CN23XX firmware download") Signed-off-by: Derek Chickles <[email protected]> Signed-off-by: Satanand Burla <[email protected]> Signed-off-by: Raghu Vatsavayi <[email protected]> Signed-off-by: Felix Manlunas <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2017-07-06smp/hotplug: Move unparking of percpu threads to the control CPUThomas Gleixner1-18/+19
Vikram reported the following backtrace: BUG: scheduling while atomic: swapper/7/0/0x00000002 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.32-perf+ #680 schedule schedule_hrtimeout_range_clock schedule_hrtimeout wait_task_inactive __kthread_bind_mask __kthread_bind __kthread_unpark kthread_unpark cpuhp_online_idle cpu_startup_entry secondary_start_kernel He analyzed correctly that a parked cpu hotplug thread of an offlined CPU was still on the runqueue when the CPU came back online and tried to unpark it. This causes the thread which invoked kthread_unpark() to call wait_task_inactive() and subsequently schedule() with preemption disabled. His proposed workaround was to "make sure" that a parked thread has scheduled out when the CPU goes offline, so the situation cannot happen. But that's still wrong because the root cause is not the fact that the percpu thread is still on the runqueue and neither that preemption is disabled, which could be simply solved by enabling preemption before calling kthread_unpark(). The real issue is that the calling thread is the idle task of the upcoming CPU, which is not supposed to call anything which might sleep. The moron, who wrote that code, missed completely that kthread_unpark() might end up in schedule(). The solution is simpler than expected. The thread which controls the hotplug operation is waiting for the CPU to call complete() on the hotplug state completion. So the idle task of the upcoming CPU can set its state to CPUHP_AP_ONLINE_IDLE and invoke complete(). This in turn wakes the control task on a different CPU, which then can safely do the unpark and kick the now unparked hotplug thread of the upcoming CPU to complete the bringup to the final target state. Control CPU AP bringup_cpu(); __cpu_up() ------------> bringup_ap(); bringup_wait_for_ap() wait_for_completion(); cpuhp_online_idle(); <------------ complete(); unpark(AP->stopper); unpark(AP->hotplugthread); while(1) do_idle(); kick(AP->hotplugthread); wait_for_completion(); hotplug_thread() run_online_callbacks(); complete(); Fixes: 8df3e07e7f21 ("cpu/hotplug: Let upcoming cpu bring itself fully up") Reported-by: Vikram Mulukutla <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: Sebastian Sewior <[email protected]> Cc: Rusty Russell <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Andrew Morton <[email protected]> Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1707042218020.2131@nanos Signed-off-by: Thomas Gleixner <[email protected]>
2017-07-06video: adp8870: move header file out of I2C realmWolfram Sang3-2/+2
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]>
2017-07-06backlight: adp8860: Move header file out of I2C realmWolfram Sang3-2/+2
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]>
2017-07-06mfd: Add LP87565 PMIC supportKeerthy5-0/+428
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]>
2017-07-06mfd: cros_ec: Free IRQ on exitJeffy Chen1-0/+3
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]>
2017-07-06dt-bindings: vendor-prefixes: Add arctic to vendor prefixOlimpiu Dejeu1-0/+1
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]>
2017-07-06mfd: da9061: Fix to remove BBAT_CONT register from chip modelSteve Twiss1-6/+0
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]>
2017-07-06mfd: da9061: Fix to remove BBAT_CONT register from chip modelSteve Twiss1-6/+0
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]>
2017-07-06mfd: axp20x-i2c: Document that this must be builtin on x86Hans de Goede1-0/+5
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]>
2017-07-06mfd: Add Cherry Trail Whiskey Cove PMIC driverHans de Goede3-0/+247
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]>
2017-07-06mfd: tc6393xb: Handle return value of clk_prepare_enableArvind Yadav1-1/+3
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]>
2017-07-06mfd: intel_quark_i2c_gpio: Add support for SIMATIC IOT2000 platformJan Kiszka1-0/+16
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]>
2017-07-06mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequencyJan Kiszka1-20/+13
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]>
2017-07-06mfd: motorola-cpcap: Use devm_of_platform_populate()Benjamin Gaignard1-12/+1
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]>
2017-07-06mfd: smsc-ece: Use devm_of_platform_populate()Benjamin Gaignard1-2/+1
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]>
2017-07-06mfd: qcom-spmi-pmic: Use devm_of_platform_populate()Benjamin Gaignard1-8/+1
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]>
2017-07-06mfd: palmas: Use devm_of_platform_populate()Benjamin Gaignard1-1/+1
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]>
2017-07-06mfd: exynos: Use devm_of_platform_populate()Benjamin Gaignard1-1/+1
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]>
Powered by cgit, Gruvboxed by Blaster4385.