- 01 Dec, 2019 40 commits
-
-
Gustavo A. R. Silva authored
[ Upstream commit f4445bb9 ] There is a NULL pointer dereference in case *slot* happens to be NULL at lines 1053 and 1878: struct hisi_sas_cq *cq = &hisi_hba->cq[slot->dlvry_queue]; Notice that *slot* is being NULL checked at lines 1057 and 1881: if (slot), which implies it may be NULL. Fix this by placing the declaration and definition of variable cq, which contains the pointer dereference slot->dlvry_queue, after slot has been properly NULL checked. Addresses-Coverity-ID: 1474515 ("Dereference before null check") Addresses-Coverity-ID: 1474520 ("Dereference before null check") Fixes: 584f53fe ("scsi: hisi_sas: Fix the race between IO completion and timeout for SMP/internal IO") Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
David S. Miller authored
[ Upstream commit 46b83064 ] If PARPORT_PC_FIFO is not enabled, do not provide the dma lock macros and lock definition. Otherwise: ./arch/sparc/include/asm/parport.h:24:24: warning: ‘dma_spin_lock’ defined but not used [-Wunused-variable] static DEFINE_SPINLOCK(dma_spin_lock); ^~~~~~~~~~~~~ ./include/linux/spinlock_types.h:81:39: note: in definition of macro ‘DEFINE_SPINLOCK’ #define DEFINE_SPINLOCK(x) spinlock_t x = __SPIN_LOCK_UNLOCKED(x) Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Jithu Joseph authored
[ Upstream commit b61b8bba ] When the last CPU in an rdt_domain goes offline, its rdt_domain struct gets freed. Current pseudo-locking code is unaware of this scenario and tries to dereference the freed structure in a few places. Add checks to prevent pseudo-locking code from doing this. While further work is needed to seamlessly restore resource groups (not just pseudo-locking) to their configuration when the domain is brought back online, the immediate issue of invalid pointers is addressed here. Fixes: f4e80d67 ("x86/intel_rdt: Resctrl files reflect pseudo-locked information") Fixes: 443810fe ("x86/intel_rdt: Create debugfs files for pseudo-locking testing") Fixes: 746e0859 ("x86/intel_rdt: Create character device exposing pseudo-locked region") Fixes: 33dc3e41 ("x86/intel_rdt: Make CPU information accessible for pseudo-locked regions") Signed-off-by:
Jithu Joseph <jithu.joseph@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: fenghua.yu@intel.com Cc: tony.luck@intel.com Cc: gavin.hindman@intel.com Cc: hpa@zytor.com Link: https://lkml.kernel.org/r/231f742dbb7b00a31cc104416860e27dba6b072d.1539384145.git.reinette.chatre@intel.comSigned-off-by:
-
Vignesh R authored
[ Upstream commit b682cffa ] McSPI has 32 byte FIFO in Transmit-Receive mode. Current code tries to configuration FIFO watermark level for DMA trigger to be GCD of transfer length and max FIFO size which would mean trigger level may be set to 32 for transmit-receive mode if length is aligned. This does not work in case of SPI slave mode where FIFO always needs to have data ready whenever master starts the clock. With DMA trigger size of 32 there will be a small window during slave TX where DMA is still putting data into FIFO but master would have started clock for next byte, resulting in shifting out of stale data. Similarly, on Slave RX side there may be RX FIFO overflow Fix this by setting FIFO watermark for DMA trigger to word length. This means DMA is triggered as soon as FIFO has space for word length bytes and DMA would make sure FIFO is almost always full therefore improving FIFO occupancy in both master and slave mode. Signed-off-by:
Vignesh R <vigneshr@ti.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Christoph Hellwig authored
[ Upstream commit 80885468 ] All properly written drivers now have error handling in the dma_map_single / dma_map_page callers. As swiotlb_tbl_map_single already prints a useful warning when running out of swiotlb pool space we can also remove swiotlb_full entirely as it serves no purpose now. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Thomas Richter authored
[ Upstream commit ec0c0bb4 ] Return an error when the function debug_register() fails allocating the debug handle. Also remove the registered debug handle when the initialization fails later on. Signed-off-by:
Thomas Richter <tmricht@linux.ibm.com> Reviewed-by:
Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 64b9d16e ] Clang warns: drivers/atm/zatm.c:513:7: error: while loop has empty body [-Werror,-Wempty-body] zwait; ^ drivers/atm/zatm.c:513:7: note: put the semicolon on a separate line to silence this warning Get rid of this warning by using an empty do-while loop. While we're at it, add parentheses to make it clear that this is a function-like macro. Link: https://github.com/ClangBuiltLinux/linux/issues/42Suggested-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
J. Bruce Fields authored
[ Upstream commit 826799e6 ] Commits ffb6ca33 and e08ea3a9 prevent setting xprt_min_resvport greater than xprt_max_resvport, but may also break simple code that sets one parameter then the other, if the new range does not overlap the old. Also it looks racy to me, unless there's some serialization I'm not seeing. Granted it would probably require malicious privileged processes (unless there's a chance these might eventually be settable in unprivileged containers), but still it seems better not to let userspace panic the kernel. Simpler seems to be to allow setting the parameters to whatever you want but interpret xprt_min_resvport > xprt_max_resvport as the empty range. Fixes: ffb6ca33 "sunrpc: Prevent resvport min/max inversion..." Fixes: e08ea3a9 "sunrpc: Prevent rexvport min/max inversion..." Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit e732f448 ] Signed-off-by:
-
Peng Hao authored
[ Upstream commit 1bd70d2e ] FILE pointer variable f is opened but never closed. Signed-off-by:
Peng Hao <peng.hao2@zte.com.cn> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Heinz Mauelshagen authored
[ Upstream commit d857ad75 ] With raid4/5/6, journal device and write intent bitmap are mutually exclusive. Signed-off-by:
Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Xin Long authored
[ Upstream commit cd305c74 ] sk->sk_wmem_queued is used to count the size of chunks in out queue while sk->sk_wmem_alloc is for counting the size of chunks has been sent. sctp is increasing both of them before enqueuing the chunks, and using sk->sk_wmem_alloc to check for writable space. However, sk_wmem_alloc is also increased by 1 for the skb allocked for sending in sctp_packet_transmit() but it will not wake up the waiters when sk_wmem_alloc is decreased in this skb's destructor. If msg size is equal to sk_sndbuf and sendmsg is waiting for sndbuf, the check 'msg_len <= sctp_wspace(asoc)' in sctp_wait_for_sndbuf() will keep waiting if there's a skb allocked in sctp_packet_transmit, and later even if this skb got freed, the waiting thread will never get waked up. This issue has been there since very beginning, so we change to use sk->sk_wmem_queued to check for writable space as sk_wmem_queued is not increased for the skb allocked for sending, also as TCP does. SOCK_SNDBUF_LOCK check is also removed here as it's for tx buf auto tuning which I will add in another patch. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit e325808c ] Currently the call to atoi is being passed a single char string that is not null terminated, so there is a potential read overrun along the stack when parsing for an integer value. Fix this by instead using a 2 char string that is initialized to all zeros to ensure that a 1 char read into the string is always terminated with a \0. Detected by cppcheck: "Invalid atoi() argument nr 1. A nul-terminated string is required." Fixes: 3391ba0e ("usbip: tools: Extract generic code to be shared with vudc backend") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Mattias Jacobsson authored
[ Upstream commit 09015855 ] Upon success the update_status handler returns a positive number corresponding to the number of bytes transferred by usb_control_msg. However the return code of the update_status handler should indicate if an error occurred(negative) or how many bytes of the user's input to sysfs that was consumed. Return code zero indicates all bytes were consumed. The bug can for example result in the update_status handler being called twice, the second time with only the "unconsumed" part of the user's input to sysfs. Effectively setting an incorrect brightness. Change the update_status handler to return zero for all successful transactions and forward usb_control_msg's error code upon failure. Signed-off-by:
Mattias Jacobsson <2pi@mok.nu> Signed-off-by:
-
Jon Derrick authored
[ Upstream commit dc8af3a8 ] The VMD removal path calls pci_stop_root_busi(), which tears down the pcie tree, including detaching all of the attached drivers. During driver detachment, devices may use pci_release_region() to release resources. This path relies on the resource being accessible in resource tree. By detaching the child domain from the parent resource domain prior to stopping the bus, we are preventing the list traversal from finding the resource to be freed. If we instead detach the resource after stopping the bus, we will have properly freed the resource and detaching is simply accounting at that point. Without this order, the resource is never freed and is orphaned on VMD removal, leading to a warning: [ 181.940162] Trying to free nonexistent resource <e5a10000-e5a13fff> Fixes: 2c2c5c5c ("x86/PCI: VMD: Attach VMD resources to parent domain's resource tree") Signed-off-by:
Jon Derrick <jonathan.derrick@intel.com> [lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
[ Upstream commit fc0c8b36 ] There's some antiquated debug output that's trying to do a hand-made hexdump and turning into horrible 1-byte-per-line output these days. Use print_hex_dump() instead Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Philipp Klocke authored
[ Upstream commit eb7ebfa3 ] Compiling with clang yields the following warning: sound/i2c/cs8427.c:140:31: warning: implicit conversion from 'int' to 'char' changes value from 160 to -96 [-Wconstant-conversion] data[0] = CS8427_REG_AUTOINC | CS8427_REG_CORU_DATABUF; ~ ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~ Because CS8427_REG_AUTOINC is defined as 128, it is too big for a char field. So change data from char to unsigned char, that it can hold the value. This patch does not change the generated code. Signed-off-by:
Philipp Klocke <philipp97kl@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Ulf Hansson authored
[ Upstream commit 2c9b7f87 ] A caller of pm_genpd_init() that provides some states for the genpd via the ->states pointer in the struct generic_pm_domain, should also provide a governor. This because it's the job of the governor to pick a state that satisfies the constraints. Therefore, let's print a warning to inform the user about such bogus configuration and avoid to bail out, by instead picking the shallowest state before genpd invokes the ->power_off() callback. Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by:
Lina Iyer <ilina@codeaurora.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 589edb56 ] Bay and Cherry Trail devices with a Dollar Cove or Whiskey Cove PMIC have an ACPI node with a HID of INT33FE which is a "virtual" battery device implementing a standard ACPI battery interface which depends upon a proprietary, undocument OpRegion called BMOP. Since we do have docs for the actual fuel-gauges used on these boards we instead use native fuel-gauge drivers talking directly to the fuel-gauge ICs on boards which rely on this INT33FE device for their battery monitoring. On boards with a Dollar Cove PMIC the INT33FE device's resources (_CRS) describe a non-existing I2C client at address 0x6b with a bus-speed of 100KHz. This is a problem on some boards since there are actual devices on that same bus which need a speed of 400KHz to function properly. This commit adds the INT33FE HID to the list of devices with I2C resources which should be enumerated as a platform-device rather then letting the i2c-core instantiate an i2c-client matching the first I2C resource, so that its bus-speed will not influence the max speed of the I2C bus. This fixes e.g. the touchscreen not working on the Teclast X98 II Plus. The INT33FE device on boards with a Whiskey Cove PMIC is somewhat special. Its first I2C resource is for a secondary I2C address of the PMIC itself, which is already described in an ACPI device with an INT34D3 HID. But it has 3 more I2C resources describing 3 other chips for which we do need to instantiate I2C clients and which need device-connections added between them for things to work properly. This special case is handled by the drivers/platform/x86/intel_cht_int33fe.c code. Before this commit that code was binding to the i2c-client instantiated for the secondary I2C address of the PMIC, since we now instantiate a platform device for the INT33FE device instead, this commit also changes the intel_cht_int33fe driver from an i2c driver to a platform driver. This also brings the intel_cht_int33fe drv inline with how we instantiate multiple i2c clients from a single ACPI device in other cases, as done by the drivers/platform/x86/i2c-multi-instantiate.c code. Reported-and-tested-by:
Alexander Meiler <alex.meiler@protonmail.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Steven Rostedt (VMware) authored
[ Upstream commit c2712b85 ] Andy had some concerns about using regs_get_kernel_stack_nth() in a new function regs_get_kernel_argument() as if there's any error in the stack code, it could cause a bad memory access. To be on the safe side, call probe_kernel_read() on the stack address to be extra careful in accessing the memory. A helper function, regs_get_kernel_stack_nth_addr(), was added to just return the stack address (or NULL if not on the stack), that will be used to find the address (and could be used by other functions) and read the address with kernel_probe_read(). Requested-by:
Andy Lutomirski <luto@amacapital.net> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Reviewed-by:
Joel Fernandes (Google) <joel@joelfernandes.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20181017165951.09119177@gandalf.local.homeSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Brian Foster authored
[ Upstream commit efc3289c ] In the typical unmount case, the AIL is forced out by the unmount sequence before the xfsaild task is stopped. Since AIL items are removed on writeback completion, this means that the AIL ->ail_buf_list delwri queue has been drained. This is not always true in the shutdown case, however. It's possible for buffers to sit on a delwri queue for a period of time across submission attempts if said items are locked or have been relogged and pinned since first added to the queue. If the attempt to log such an item results in a log I/O error, the error processing can shutdown the fs, remove the item from the AIL, stale the buffer (dropping the LRU reference) and clear its delwri queue state. The latter bit means the buffer will be released from a delwri queue on the next submission attempt, but this might never occur if the filesystem has shutdown and the AIL is empty. This means that such buffers are held indefinitely by the AIL delwri queue across destruction of the AIL. Aside from being a memory leak, these buffers can also hold references to in-core perag structures. The latter problem manifests as a generic/475 failure, reproducing the following asserts at unmount time: XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0, file: fs/xfs/xfs_mount.c, line: 151 XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0, file: fs/xfs/xfs_mount.c, line: 132 To prevent this problem, clear the AIL delwri queue as a final step before xfsaild() exit. The !empty state should never occur in the normal case, so add an assert to catch unexpected problems going forward. [dgc: add comment explaining need for xfs_buf_delwri_cancel() after calling xfs_buf_delwri_submit_nowait().] Signed-off-by:
Brian Foster <bfoster@redhat.com> Reviewed-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com> Signed-off-by:
-
Dave Chinner authored
[ Upstream commit 37fd1678 ] When looking at a 4.18 based KASAN use after free report, I noticed that racing xfs_buf_rele() may race on dropping the last reference to the buffer and taking the buffer lock. This was the symptom displayed by the KASAN report, but the actual issue that was reported had already been fixed in 4.19-rc1 by commit e339dd8d ("xfs: use sync buffer I/O for sync delwri queue submission"). Despite this, I think there is still an issue with xfs_buf_rele() in this code: release = atomic_dec_and_lock(&bp->b_hold, &pag->pag_buf_lock); spin_lock(&bp->b_lock); if (!release) { ..... If two threads race on the b_lock after both dropping a reference and one getting dropping the last reference so release = true, we end up with: CPU 0 CPU 1 atomic_dec_and_lock() atomic_dec_and_lock() spin_lock(&bp->b_lock) spin_lock(&bp->b_lock) <spins> <release = true bp->b_lru_ref = 0> <remove from lists> freebuf = true spin_unlock(&bp->b_lock) xfs_buf_free(bp) <gets lock, reading and writing freed memory> <accesses freed memory> spin_unlock(&bp->b_lock) <reads/writes freed memory> IOWs, we can't safely take bp->b_lock after dropping the hold reference because the buffer may go away at any time after we drop that reference. However, this can be fixed simply by taking the bp->b_lock before we drop the reference. It is safe to nest the pag_buf_lock inside bp->b_lock as the pag_buf_lock is only used to serialise against lookup in xfs_buf_find() and no other locks are held over or under the pag_buf_lock there. Make this clear by documenting the buffer lock orders at the top of the file. Signed-off-by:
-
Netanel Belgazal authored
[ Upstream commit 8c590f97 ] The Kconfig limitation of X86 is to too wide. The ENA driver only requires a little endian dependency. Change the dependency to be on little endian CPU. Signed-off-by:
Netanel Belgazal <netanel@amazon.com> Signed-off-by:
-
Kyeongdon Kim authored
[ Upstream commit 33c4368e ] This fixes the "'hash' may be used uninitialized in this function" net/unix/af_unix.c:1041:20: warning: 'hash' may be used uninitialized in this function [-Wmaybe-uninitialized] addr->hash = hash ^ sk->sk_type; Signed-off-by:
Kyeongdon Kim <kyeongdon.kim@lge.com> Signed-off-by:
-
Marek Behún authored
[ Upstream commit 26422340 ] This is a fix for the port_set_speed method for the Topaz family. Currently the same method is used as for the Peridot family, but this is wrong for the SERDES port. On Topaz, the SERDES port is port 5, not 9 and 10 as in Peridot. Moreover setting alt_bit on Topaz only makes sense for port 0 (for (differentiating 100mbps vs 200mbps). The SERDES port does not support more than 2500mbps, so alt_bit does not make any difference. Signed-off-by:
Marek Behún <marek.behun@nic.cz> Signed-off-by:
-
Finn Thain authored
[ Upstream commit b7ded0e8 ] The core driver, esp_scsi, does not use the ESP_CONFIG2_FENAB bit, so the chip's Transfer Counter register is only 16 bits wide (not 24). A larger transfer cannot work and will theoretically result in a failed command and a "DMA length is zero" error. Fixes: 3109e5ae ("scsi: zorro_esp: New driver for Amiga Zorro NCR53C9x boards") Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Cc: Michael Schmitz <schmitzmic@gmail.com> Tested-by:
Michael Schmitz <schmitzmic@gmail.com> Reviewed-by:
-
Christoph Hellwig authored
[ Upstream commit 6c404a68 ] We need to transfer device ownership to the CPU before we can manipulate the mapped data. Signed-off-by:
-
Christoph Hellwig authored
[ Upstream commit 3a5bd702 ] We can't just transfer ownership to the CPU and then unmap, as this will break with swiotlb. Instead unmap the command and sense buffer a little earlier in the I/O completion handler and get rid of the pci_dma_sync_sg_for_cpu call entirely. Signed-off-by:
-
Marcel Ziswiler authored
[ Upstream commit a85227da ] Similar to the following: commit 43217236 ("ASoC: tegra_alc5632: fix device_node refcounting") commit 7c5dfd54 ("ASoC: tegra: fix device_node refcounting") Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
-
Alexandre Belloni authored
[ Upstream commit 7fa75007 ] The allocation for the audio pmc is using the size of struct clk_audio_pad instead of struct clk_audio_pmc. This works fine because the former is larger than the latter but it is safer to be correct. Fixes: ("0865805d clk: at91: add audio pll clock drivers") Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Lubomir Rintel authored
[ Upstream commit 4917fb90 ] A typo that makes it impossible to get the correct clocks for MMP2_CLK_SDH2 and MMP2_CLK_SDH3. Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Fixes: 1ec770d9 ("clk: mmp: add mmp2 DT support for clock driver") Signed-off-by:
-
Honghui Zhang authored
[ Upstream commit 3828d60f ] Commit 43e6409d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") added MSI support but enabled MSI in the wrong place, at a step in the probe sequence where clocks were not still enabled. Fix this issue by calling mtk_pcie_enable_msi() in mtk_pcie_startup_port_v2() since clocks are enabled when mtk_pcie_startup_port_v2() is called. To avoid forward declaration of mtk_pcie_enable_msi(), move the mtk_pcie_startup_port_v2() function definition in the file. Fixes: 43e6409d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") Signed-off-by:
Honghui Zhang <honghui.zhang@mediatek.com> [lorenzo.pieralisi@arm.com: squashed commit and adapted log] Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
-
Keith Busch authored
[ Upstream commit cb4bfda6 ] A removal waits for the reset_work to complete. If a surprise removal occurs around the same time as an error triggered controller reset, and reset work happened to dispatch a command to the removed controller, the command won't be recovered since the timeout work doesn't do anything during error recovery. We wouldn't want to wait for timeout handling anyway, so this patch fixes this by disabling the controller and killing admin queues prior to syncing with the reset_work. Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit 1216e9ef ] Building with W=1 enables the compiler warning -Wimplicit-fallthrough=3. That option does not recognize the fall-through comment in the fcloop driver. Add a fall-through comment that is recognized for -Wimplicit-fallthrough=3. This patch avoids that the compiler reports the following warning when building with W=1: drivers/nvme/target/fcloop.c:647:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (op == NVMET_FCOP_READDATA) ^ Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit 8eacd1bd ] Although I'm not sure whether it is a good idea to support large discard commands, I think integer overflow for discard ranges larger than 4 GB should be avoided. This patch avoids that smatch reports the following: drivers/nvme/target/io-cmd-file.c:249:1 nvmet_file_execute_discard() warn: should '((range.nlb)) << req->ns->blksize_shift' be a 64 bit type? Fixes: d5eff33e ("nvmet: add simple file backed ns support") Signed-off-by:
Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 18e732b8 ] Clang warns when one enumerated type is implicitly converted to another and this happens in several locations in this driver, ultimately related to the set_cipher_{mode,config0} functions. set_cipher_mode expects a mode of type drv_cipher_mode and set_cipher_config0 expects a mode of type drv_crypto_direction. drivers/crypto/ccree/cc_ivgen.c:58:35: warning: implicit conversion from enumeration type 'enum cc_desc_direction' to different enumeration type 'enum drv_crypto_direction' [-Wenum-conversion] set_cipher_config0(&iv_seq[idx], DESC_DIRECTION_ENCRYPT_ENCRYPT); drivers/crypto/ccree/cc_hash.c:99:28: warning: implicit conversion from enumeration type 'enum cc_hash_conf_pad' to different enumeration type 'enum drv_crypto_direction' [-Wenum-conversion] set_cipher_config0(desc, HASH_DIGEST_RESULT_LITTLE_ENDIAN); drivers/crypto/ccree/cc_aead.c:1643:30: warning: implicit conversion from enumeration type 'enum drv_hash_hw_mode' to different enumeration type 'enum drv_cipher_mode' [-Wenum-conversion] set_cipher_mode(&desc[idx], DRV_HASH_HW_GHASH); Since this fundamentally isn't a problem because these values just represent simple integers for a shift operation, make it clear to Clang that this is okay by making the mode parameter in both functions an int. Link: https://github.com/ClangBuiltLinux/linux/issues/46Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 20054597 ] Clang warns when one enumerated type is implicitly converted to another. drivers/scsi/iscsi_tcp.c:803:15: warning: implicit conversion from enumeration type 'enum iscsi_host_param' to different enumeration type 'enum iscsi_param' [-Wenum-conversion] &addr, param, buf); ^~~~~ 1 warning generated. iscsi_conn_get_addr_param handles ISCSI_HOST_PARAM_IPADDRESS just fine so add an explicit cast to iscsi_param to make it clear to Clang that this is expected behavior. Link: https://github.com/ClangBuiltLinux/linux/issues/153Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 761c830e ] Clang warns when one enumerated type is implicitly converted to another. drivers/scsi/bfa/bfa_fcs_lport.c:379:26: warning: implicit conversion from enumeration type 'enum bfa_lport_aen_event' to different enumeration type 'enum bfa_ioc_aen_event' [-Wenum-conversion] BFA_AEN_CAT_LPORT, event); ^~~~~ The root cause of these warnings is the bfad_im_post_vendor_event function, which expects a value from enum bfa_ioc_aen_event but there are multiple instances of values from enums bfa_port_aen_event, bfa_audit_aen_event, and bfa_lport_aen_event being used in this function. Given that this doesn't appear to be a problem since cat helps with differentiating the events, just change evt's type to int so that no conversion needs to happen and Clang won't warn. Update aen_type's type in bfa_aen_entry_s as members that hold enumerated types should be int. Link: https://github.com/ClangBuiltLinux/linux/issues/147Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 362b5da3 ] Clang warns when an enumerated type is implicitly converted to another. drivers/scsi/isci/request.c:3476:13: warning: implicit conversion from enumeration type 'enum sci_task_status' to different enumeration type 'enum sci_status' [-Wenum-conversion] status = sci_controller_start_task(ihost, ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/isci/host.c:2744:10: warning: implicit conversion from enumeration type 'enum sci_status' to different enumeration type 'enum sci_task_status' [-Wenum-conversion] return SCI_SUCCESS; ~~~~~~ ^~~~~~~~~~~ drivers/scsi/isci/host.c:2753:9: warning: implicit conversion from enumeration type 'enum sci_status' to different enumeration type 'enum sci_task_status' [-Wenum-conversion] return status; ~~~~~~ ^~~~~~ Avoid all of these implicit conversion by just making sci_controller_start_task use sci_status. This silences Clang and has no functional change since sci_task_status has all of its values mapped to something in sci_status. Link: https://github.com/ClangBuiltLinux/linux/issues/153Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit e9e9a103 ] Clang warns when one enumerated type is implicitly converted to another. drivers/scsi/isci/request.c:1629:13: warning: implicit conversion from enumeration type 'enum sci_io_status' to different enumeration type 'enum sci_status' [-Wenum-conversion] status = SCI_IO_FAILURE_RESPONSE_VALID; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/isci/request.c:1631:12: warning: implicit conversion from enumeration type 'enum sci_io_status' to different enumeration type 'enum sci_status' [-Wenum-conversion] status = SCI_IO_FAILURE_RESPONSE_VALID; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ status is of type sci_status but SCI_IO_FAILURE_RESPONSE_VALID is of type sci_io_status. Use SCI_FAILURE_IO_RESPONSE_VALID, which is from sci_status and has SCI_IO_FAILURE_RESPONSE_VALID's exact value since that is what SCI_IO_FAILURE_RESPONSE_VALID is mapped to in the isci.h file. Link: https://github.com/ClangBuiltLinux/linux/issues/153Signed-off-by:
-
