- 18 Apr, 2017 3 commits
-
-
Eric Dumazet authored
[ Upstream commit fbfa743a ] This function suffers from multiple issues. First one is that pskb_may_pull() may reallocate skb->head, so the 'raw' pointer needs either to be reloaded or not used at all. Second issue is that NEXTHDR_DEST handling does not validate that the options are present in skb->data, so we might read garbage or access non existent memory. With help from Willem de Bruijn. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Dmitry Vyukov <dvyukov@google.com> Cc: Willem de Bruijn <willemb@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit f1712c73 ] Zhang Yanmin reported crashes [1] and provided a patch adding a synchronize_rcu() call in can_rx_unregister() The main problem seems that the sockets themselves are not RCU protected. If CAN uses RCU for delivery, then sockets should be freed only after one RCU grace period. Recent kernels could use sock_set_flag(sk, SOCK_RCU_FREE), but let's ease stable backports with the following fix instead. [1] BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff81495e25>] selinux_socket_sock_rcv_skb+0x65/0x2a0 Call Trace: <IRQ> [<ffffffff81485d8c>] security_sock_rcv_skb+0x4c/0x60 [<ffffffff81d55771>] sk_filter+0x41/0x210 [<ffffffff81d12913>] sock_queue_rcv_skb+0x53/0x3a0 [<ffffffff81f0a2b3>] raw_rcv+0x2a3/0x3c0 [<ffffffff81f06eab>] can_rcv_filter+0x12b/0x370 [<ffffffff81f07af9>] can_receive+0xd9/0x120 [<ffffffff81f07beb>] can_rcv+0xab/0x100 [<ffffffff81d362ac>] __netif_receive_skb_core+0xd8c/0x11f0 [<ffffffff81d36734>] __netif_receive_skb+0x24/0xb0 [<ffffffff81d37f67>] process_backlog+0x127/0x280 [<ffffffff81d36f7b>] net_rx_action+0x33b/0x4f0 [<ffffffff810c88d4>] __do_softirq+0x184/0x440 [<ffffffff81f9e86c>] do_softirq_own_stack+0x1c/0x30 <EOI> [<ffffffff810c76fb>] do_softirq.part.18+0x3b/0x40 [<ffffffff810c8bed>] do_softirq+0x1d/0x20 [<ffffffff81d30085>] netif_rx_ni+0xe5/0x110 [<ffffffff8199cc87>] slcan_receive_buf+0x507/0x520 [<ffffffff8167ef7c>] flush_to_ldisc+0x21c/0x230 [<ffffffff810e3baf>] process_one_work+0x24f/0x670 [<ffffffff810e44ed>] worker_thread+0x9d/0x6f0 [<ffffffff810e4450>] ? rescuer_thread+0x480/0x480 [<ffffffff810ebafc>] kthread+0x12c/0x150 [<ffffffff81f9ccef>] ret_from_fork+0x3f/0x70 Reported-by:
Zhang Yanmin <yanmin.zhang@intel.com> Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
-
Linus Torvalds authored
commit 38f7bd94 upstream. This reverts commit c845acb3. It turns out that it just replaces one deadlock with another one: we can still get the wrong lock ordering with the readlock due to overlayfs calling back into the filesystem layer and still taking the vfs locks after the readlock. The proper solution ends up being to just split the readlock into two pieces: the bind lock (taken *outside* the vfs locks) and the IO lock (taken *inside* the filesystem locks). The two locks are independent anyway. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by:
Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by:
-
- 08 Feb, 2017 36 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This fixes commit f67924cc which was commit 7359df25 upstream. When backporting the patch, there was an unused variable, and the printk type was incorrect. Fix this up by moving back to the correct type as shown in commit 649ee054 and remove the unneeded variable. This fixes up two build warnings. Cc: Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
-
Greg Kroah-Hartman authored
Commit dd4fff23 which is commit fac8e0f5 upstream, seems to have included the sit_gro_receive function, yet it never is used, causing an obvious warning message. Hook it up to the correct sit_offload structure. Note, for 3.16, the backport of fac8e0f5 does not include this function, nor the ipip case. I'm guessing that this is not correct for 3.18, as one of the functions was included, but could be totally wrong. Cc: Jesse Gross <jesse@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
-
Greg Kroah-Hartman authored
Fix up commit cec8983e which was commit 6de62f15 upstream. The function prototypes were wrong. Someone was ignoring compiler warnings :( Cc: Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
-
Magnus Damm authored
commit c6535e1e upstream. Remove ZBOOT MMC/SDHI Documentation for sh7372 together wit the vrl4 utility. Without sh7372 and Mackerel support these files are no longer useful. Signed-off-by:
Magnus Damm <damm+renesas@opensource.se> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> [removes a build warning in 3.18, and as this chip never was made, it is safe to remove the documentation here. The code was removed in 4.1. - gregkh] Signed-off-by:
-
Dan Carpenter authored
commit ba0635ff upstream. Static checkers complain that we should probably add curly braces because, from the indenting, it looks like seq_printf() should be inside the list_for_each_entry() loop. But the code is actually correct, it's just the indenting which is off. Besides fixing the indenting on seq_printf(), I did add curly braces, because generally mult-line indents should have curly braces to make them more readable. The unintended indent was left behind and not unindented in commit d7f46fc4 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Fri Dec 6 14:10:55 2013 -0800 drm/i915: Make pin count per VMA Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Hans Westgaard Ry authored
commit 5f74f82e upstream. Devices may have limits on the number of fragments in an skb they support. Current codebase uses a constant as maximum for number of fragments one skb can hold and use. When enabling scatter/gather and running traffic with many small messages the codebase uses the maximum number of fragments and may thereby violate the max for certain devices. The patch introduces a global variable as max number of fragments. Signed-off-by:
Hans Westgaard Ry <hans.westgaard.ry@oracle.com> Reviewed-by:
Håkon Bugge <haakon.bugge@oracle.com> Acked-by:
-
Linus Torvalds authored
commit 10fbd36e upstream. rq_data_dir() returns either READ or WRITE (0 == READ, 1 == WRITE), not a boolean value. Now, admittedly the "!= 0" doesn't really change the value (0 stays as zero, 1 stays as one), but it's not only redundant, it confuses gcc, and causes gcc to warn about the construct switch (rq_data_dir(req)) { case READ: ... case WRITE: ... that we have in a few drivers. Now, the gcc warning is silly and stupid (it seems to warn not about the switch value having a different type from the case statements, but about _any_ boolean switch value), but in this case the code itself is silly and stupid too, so let's just change it, and get rid of warnings like this: drivers/block/hd.c: In function ‘hd_request’: drivers/block/hd.c:630:11: warning: switch condition has boolean value [-Wswitch-bool] switch (rq_data_dir(req)) { The odd '!= 0' came in when "cmd_flags" got turned into a "u64" in commit 5953316d ("block: make rq->cmd_flags be 64-bit") and is presumably because the old code (that just did a logical 'and' with 1) would then end up making the type of rq_data_dir() be u64 too. But if we want to retain the old regular integer type, let's just cast the result to 'int' rather than use that rather odd '!= 0'. Signed-off-by:
-
Andy Shevchenko authored
commit a5c2db96 upstream. This patch splits few helpers, namely dw_spi_dma_prepare_rx(), dw_spi_dma_prepare_tx(), and dw_spi_dma_setup() which will be useful for the consequent improvements. There is no functional change. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> [removes a build warning with newer versions of gcc - gregkh] Signed-off-by:
-
Ingo Molnar authored
commit 927392d7 upstream. Linus reported the following new warning on x86 allmodconfig with GCC 5.1: > ./arch/x86/include/asm/spinlock.h: In function ‘arch_spin_lock’: > ./arch/x86/include/asm/spinlock.h:119:3: warning: implicit declaration > of function ‘__ticket_lock_spinning’ [-Wimplicit-function-declaration] > __ticket_lock_spinning(lock, inc.tail); > ^ This warning triggers because of these hacks in misc.h: /* * we have to be careful, because no indirections are allowed here, and * paravirt_ops is a kind of one. As it will only run in baremetal anyway, * we just keep it from happening */ #undef CONFIG_PARAVIRT #undef CONFIG_KASAN But these hacks were not updated when CONFIG_PARAVIRT_SPINLOCKS was added, and eventually (with the introduction of queued paravirt spinlocks in recent kernels) this created an invalid Kconfig combination and broke the build. So add a CONFIG_PARAVIRT_SPINLOCKS #undef line as well. Also remove the _ASM_X86_DESC_H quirk: that undocumented quirk was originally added ages ago, in: 099e1377 ("x86: use ELF format in compressed images.") and I went back to that kernel (and fixed up the main Makefile which didn't build anymore) and checked what failure it avoided: it avoided an include file dependencies related build failure related to our old x86-platforms code. That old code is long gone, the header dependencies got cleaned up, and the build does not fail anymore with the totality of asm/desc.h included - so remove the quirk. Reported-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Yoshihiro Shimoda authored
commit 9ae7ce00 upstream. This patch fixes the following warning if 64-bit architecture environment: ./drivers/usb/renesas_usbhs/common.c:496:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] dparam->type = of_id ? (u32)of_id->data : 0; Acked-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Luis de Bethencourt authored
commit 8c182ae2 upstream. For loop is outside of the else branch of the above conditional statement. Fixing misleading indentation. Fix a smatch warning: drivers/staging/rtl8723au/core/rtw_wlan_util.c:528 WMMOnAssocRsp23a() warn: curly braces intended? Signed-off-by:
Luis de Bethencourt <luisbg@osg.samsung.com> Acked-by:
Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by:
-
Dan Carpenter authored
commit 53bd4a00 upstream. >From the indenting, it looks like curly braces were intended here. Signed-off-by:
-
Linus Torvalds authored
commit 7796c11c upstream. This one was driving me mad, with several lines of warnings during the allmodconfig build for a single bogus pointer cast. The warning was so verbose due to the indirect macro expansion explanation, and the whole thing was just for a debug printout. The bogus pointer-to-integer cast was pointless anyway, so just remove it, and use '%p' to show the pointer. Signed-off-by:
-
Colin Ian King authored
commit b6acb0cf upstream. Fix indent warning when building with gcc 6: drivers/staging/iio/adc/ad7192.c:239:4: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Anil Gurumurthy authored
commit b7f4d634 upstream. Signed-off-by:
Anil Gurumurthy <anil.gurumurthy@qlogic.com> Tested-by : Sudarasana Kalluru <sudarsana.kalluru@qlogic.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
James Bottomley <JBottomley@Odin.com> Signed-off-by:
-
Joe Perches authored
commit e6c97234 upstream. Reduce stack use by using kmemdup and not using a very large struct on stack. In function ‘i40e_dbg_dump_desc’: warning: the frame size of 8192 bytes is larger than 2048 bytes [-Wframe-larger-than=] Signed-off-by:
Joe Perches <joe@perches.com> Tested-by:
Jim Young <jamesx.m.young@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Tim Gardner authored
commit dd29dae0 upstream. drivers/scsi/be2iscsi/be_main.c: In function 'be_sgl_create_contiguous': drivers/scsi/be2iscsi/be_main.c:3187:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] WARN_ON(!length > 0); gcc version 5.2.1 Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Cc: Jayamohan Kallickal <jayamohan.kallickal@avagotech.com> Cc: Minh Tran <minh.tran@avagotech.com> Cc: John Soni Jose <sony.john-n@avagotech.com> Cc: "James E.J. Bottomley" <JBottomley@odin.com> Reported-by:
Joel Stanley <joel@jms.id.au> Reviewed-by:
Manoj Kumar <manoj@linux.vnet.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Arnd Bergmann authored
commit 2cce76c3 upstream. gcc-6 warns about code in il3945_hw_txq_ctx_free() being somewhat ambiguous: drivers/net/wireless/intel/iwlegacy/3945.c:1022:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses] This adds a set of curly braces to avoid the warning. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
David Malcolm authored
commit e1395a32 upstream. This code in drivers/net/ethernet/dec/tulip/uli526x.c function "uli526x_timer": 1086 } else 1087 if ((tmp_cr12 & 0x3) && db->link_failed) { [...snip...] 1109 } 1110 else if(!(tmp_cr12 & 0x3) && db->link_failed) 1111 { [...snip...] 1117 } 1118 db->init=0; is misleadingly indented: the db->init=0 is indented as if part of the else clause at line 1086, but it is independent of it (no braces before the "if" at line 1087). This patch fixes the indentation to reflect the actual meaning of the code, though is it actually meant to be part of the "else" clause? (I'm a compiler developer, not a kernel person). It also adds spaces around the assignment, to placate checkpatch.pl. Seen via an experimental new gcc warning I'm working on for gcc 6, -Wmisleading-indentation, using gcc r223098 adding -Werror=misleading-indentation to KBUILD_CFLAGS in Makefile. The experimental GCC emits this warning (as an error), rightly IMHO: drivers/net/ethernet/dec/tulip/uli526x.c: In function ‘uli526x_timer’: drivers/net/ethernet/dec/tulip/uli526x.c:1118:3: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation] db->init=0; ^ drivers/net/ethernet/dec/tulip/uli526x.c:1086:4: note: ...this ‘else’ clause, but it is not } else ^ Hope this is helpful Dave Signed-off-by:
David Malcolm <dmalcolm@redhat.com> Signed-off-by:
-
Linus Torvalds authored
commit 1d11437f upstream. My 'allmodconfig' build is _almost_ free of warnings, and most of the remaining ones are for legacy drivers that just do bad things that I can't find it in my black heart to care too much about. But this one was just annoying me: drivers/media/v4l2-core/videobuf2-core.c:3256:26: warning: unused variable ‘fileio’ [-Wunused-variable] because commit 0e661006 ("[media] vb2: fix 'UNBALANCED' warnings when calling vb2_thread_stop()") removed all users of 'fileio' and instead calls "__vb2_cleanup_fileio(q)" to clean up q->fileio. But the now unused 'fileio' variable was left around. Signed-off-by:
-
Tomer Barletz authored
commit cc7fce80 upstream. With gcc 5.1 I get: warning: switch condition has boolean value [-Wswitch-bool] Signed-off-by:
Tomer Barletz <barletz@gmail.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
David S. Miller authored
commit 129d23a5 upstream. This fixes: ==================== net/netfilter/nft_reject.c: In function ‘nft_reject_dump’: net/netfilter/nft_reject.c:61:2: warning: enumeration value ‘NFT_REJECT_TCP_RST’ not handled in switch [-Wswitch] switch (priv->type) { ^ net/netfilter/nft_reject.c:61:2: warning: enumeration value ‘NFT_REJECT_ICMPX_UNREACH’ not handled in switch [-Wswi\ tch] net/netfilter/nft_reject_inet.c: In function ‘nft_reject_inet_dump’: net/netfilter/nft_reject_inet.c:105:2: warning: enumeration value ‘NFT_REJECT_TCP_RST’ not handled in switch [-Wswi\ tch] switch (priv->type) { ^ ==================== Signed-off-by:
-
Hans Verkuil authored
commit 7e0d4e92 upstream. Fix these compiler warnings that appeared after switching to gcc-5.1.0: drivers/media/platform/s3c-camif/camif-capture.c: In function 'sensor_set_power': drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] if (!on == camif->sensor.power_count) ^ drivers/media/platform/s3c-camif/camif-capture.c: In function 'sensor_set_streaming': drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] if (!on == camif->sensor.stream_count) ^ Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Cc: Kamil Debski <k.debski@samsung.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Juergen Gross authored
commit 1cf38741 upstream. xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper bound of the loop setting non-kernel-image entries to zero should not exceed the size of level2_kernel_pgt. Reported-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
-
Tomer Barletz authored
commit 8ec7cfce upstream. This fixes the following warning, that is seen with gcc 5.1: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
James C Boyd authored
commit 09a5c34e upstream. GCC reports a -Wlogical-not-parentheses warning here; therefore add parentheses to shut it up and to express our intent more. Signed-off-by:
James C Boyd <jcboyd.dev@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Arnd Bergmann authored
commit 6ec0a86c upstream. gcc-5.x warns about a preexisting problem in the hpt36x pata driver: drivers/ata/pata_hpt366.c: In function 'hpt36x_init_one': drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] Other ata drivers have the same problem, as ata_pci_bmdma_init_one takes a non-const pointer, and they solve it by using a cast to turn that pointer into a normal non-const pointer. I also tried to change the ata core code to make host->private_data a const pointer, but that quickly got out of hand, as some other drivers expect it to be writable, so I ended up using the same hack as the others here. Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Jiri Slaby authored
commit 9391976a upstream. gcc5 warns about passing a const array to hci_test_bit which takes a non-const pointer: net/bluetooth/hci_sock.c: In function ‘hci_sock_sendmsg’: net/bluetooth/hci_sock.c:955:8: warning: passing argument 2 of ‘hci_test_bit’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-array-qualifiers] &hci_sec_filter.ocf_mask[ogf])) && ^ net/bluetooth/hci_sock.c:49:19: note: expected ‘void *’ but argument is of type ‘const __u32 (*)[4] {aka const unsigned int (*)[4]}’ static inline int hci_test_bit(int nr, void *addr) ^ So make 'addr' 'const void *'. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Signed-off-by:
-
David Miller authored
commit c1f86676 upstream. More recent GCC warns about two kinds of switch statement uses: 1) Switching on an enumeration, but not having an explicit case statement for all members of the enumeration. To show the compiler this is intentional, we simply add a default case with nothing more than a break statement. 2) Switching on a boolean value. I think this warning is dumb but nevertheless you get it wholesale with -Wswitch. This patch cures all such warnings in netfilter. Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Linus Torvalds authored
commit 124a3d88 upstream. Newer versions of gcc warn about the use of __builtin_return_address() with a non-zero argument when "-Wall" is specified: kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’: kernel/trace/trace_irqsoff.c:433:86: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address] stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1); [ .. repeats a few times for other similar cases .. ] It is true that a non-zero argument is somewhat dangerous, and we do not actually have very many uses of that in the kernel - but the ftrace code does use it, and as Stephen Rostedt says: "We are well aware of the danger of using __builtin_return_address() of > 0. In fact that's part of the reason for having the "thunk" code in x86 (See arch/x86/entry/thunk_{64,32}.S). [..] it adds extra frames when tracking irqs off sections, to prevent __builtin_return_address() from accessing bad areas. In fact the thunk_32.S states: 'Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash)'." For now, __builtin_return_address() with a non-zero argument is the best we can do, and the warning is not helpful and can end up making people miss other warnings for real problems. So disable the frame-address warning on compilers that need it. Acked-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Arnd Bergmann authored
commit 8e0cc8c3 upstream. gcc points out code that is not indented the way it is interpreted: net/caif/cfpkt_skbuff.c: In function 'cfpkt_setlen': net/caif/cfpkt_skbuff.c:289:4: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation] return cfpkt_getlen(pkt); ^~~~~~ net/caif/cfpkt_skbuff.c:286:3: note: ...this 'else' clause, but it is not else ^~~~ It is clear from the context that not returning here would be a bug, as we'd end up passing a negative length into a function that takes a u16 length, so it is not missing curly braces here, and I'm assuming that the indentation is the only part that's wrong about it. Signed-off-by:
-
Dan Carpenter authored
commit 946e8798 upstream. The verbose module parameter can be set to 2 for extremely verbose messages so the type should be int instead of bool. Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Tillmann Heidsieck authored
commit cbb41b91 upstream. Fix a smatch warning: drivers/atm/iphase.c:1178 rx_pkt() warn: curly braces intended? The code is correct, the indention is misleading. In case the allocation of skb fails, we want to skip to the end. Signed-off-by:
Tillmann Heidsieck <theidsieck@leenox.de> Signed-off-by:
-
Andrew Morton authored
commit 0f989f74 upstream. The patch "module: fix types of device tables aliases" newly requires that invocations of MODULE_DEVICE_TABLE(type, name); come *after* the definition of `name'. That is reasonable, but some drivers weren't doing this. Fix them. Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Andrey Ryabinin <a.ryabinin@samsung.com> Cc: David Miller <davem@davemloft.net> Cc: Hans Verkuil <hverkuil@xs4all.nl> Acked-by:
-
Andrey Ryabinin authored
commit 6301939d upstream. MODULE_DEVICE_TABLE() macro used to create aliases to device tables. Normally alias should have the same type as aliased symbol. Device tables are arrays, so they have 'struct type##_device_id[x]' types. Alias created by MODULE_DEVICE_TABLE() will have non-array type - 'struct type##_device_id'. This inconsistency confuses compiler, it could make a wrong assumption about variable's size which leads KASan to produce a false positive report about out of bounds access. For every global variable compiler calls __asan_register_globals() passing information about global variable (address, size, size with redzone, name ...) __asan_register_globals() poison symbols redzone to detect possible out of bounds accesses. When symbol has an alias __asan_register_globals() will be called as for symbol so for alias. Compiler determines size of variable by size of variable's type. Alias and symbol have the same address, so if alias have the wrong size part of memory that actually belongs to the symbol could be poisoned as redzone of alias symbol. By fixing type of alias symbol we will fix size of it, so __asan_register_globals() will not poison valid memory. Signed-off-by:
Andrey Ryabinin <a.ryabinin@samsung.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Konstantin Serebryany <kcc@google.com> Cc: Dmitry Chernenkov <dmitryc@google.com> Signed-off-by:
Andrey Konovalov <adech.fo@gmail.com> Cc: Yuri Gribov <tetra2005@gmail.com> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Christoph Lameter <cl@linux.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Signed-off-by:
-
- 18 Jan, 2017 1 commit
-
-
Sasha Levin authored
Signed-off-by:Sasha Levin <alexander.levin@verizon.com>
-
