- 15 Jul, 2015 40 commits
-
-
Fabio Falzoi authored
This patch fixes the following checkpatch.pl error: CHECK:PARENTHESIS_ALIGNMENT at line 217. Signed-off-by:
Fabio Falzoi <fabio.falzoi84@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Fabio Falzoi authored
This patch removes some unnecessary multiple blank lines to fix the following checkpatch errors: CHECK:LINE_SPACING at lines 29, 67, 131, 287, 299, 312, 326, 351 and 364. Signed-off-by:
-
Fabio Falzoi authored
Remove paragraph about writing to the Free Software Foundation's mailing address from GPL notice. This patch fixes the following checkpatch error: CHECK:FSF_MAILING_ADDRESS at line 17. Signed-off-by:
-
Tim Sell authored
We learned that it was possible for the core networking code to call visornic_xmit() within ISR context, resulting in the need for us to use spin_lock_irqsave() / spin_lock_irqrestore() to lock accesses to our virtual device channels. Without the correct locking added in this patch, random hangs would occur on typical kernels while stressing the netork. When using a kernel with CONFIG_DEBUG_SPINLOCK=y, a stackdump would occur at the time of the hang reporting: BUG: spinlock recursion on CPU#0, vnic_incoming/<pid> (see below for more details) We considered the possibility of adding a protocol between a visordriver and visorbus where the visordriver could specify which type of locking it required for its virtual device channels (essentially indicating whether or not it was possible for the channel to be accessed in ISR context), but decided this extra complexity was NOT needed, and that channel queues should always be accessed with the most-stringent locking. So that is what is implemented in this commit. Below is an example stackdump illustrating the spinlock recursion that is fixed by this commit. Note that we are first in virtnic_rx() writing to the device channel when an APIC timer interrupt occurs. Within the core networking code, net_rx_action() calls process_backlog(), which eventually lands up back up in virtnic_xmit() in the code attempting to also write to the device channel. BUG: spinlock recursion on CPU#0, vnic_incoming/262 lock: 0xffff88002db810c0, .magic: dead4ead, .owner: vnic_incoming/262, .owner_cpu: 0 CPU: 0 PID: 262 Comm: vnic_incoming Tainted: G C 4.2.0-rc1-ARCH+ #56 Hardware name: Dell Inc. PowerEdge T110/ , BIOS 1.23 12/15/2009 ffff8800216ac200 ffff88002c803388 ffffffff81476364 0000000000000106 ffff88002db810c0 ffff88002c8033a8 ffffffff8109e2bc ffff88002db810c0 ffffffff817631d4 ffff88002c8033c8 ffffffff8109e330 ffff88002db810c0 Call Trace: <IRQ> [<ffffffff81476364>] dump_stack+0x4f/0x73 [<ffffffff8109e2bc>] spin_dump+0x7c/0xc0 [<ffffffff8109e330>] spin_bug+0x30/0x40 [<ffffffff8109e547>] do_raw_spin_lock+0x127/0x140 [<ffffffff8147bad0>] _raw_spin_lock+0x40/0x50 [<ffffffffa0151fa6>] ? visorchannel_signalinsert+0x46/0x70 [visorbus] [<ffffffffa0151fa6>] visorchannel_signalinsert+0x46/0x70 [visorbus] [<ffffffffa01683a2>] visornic_xmit+0x302/0x5d0 [visornic] [<ffffffff813b2f30>] dev_hard_start_xmit+0x2e0/0x510 [<ffffffff813b2b75>] ? validate_xmit_skb+0x235/0x310 [<ffffffff813d79e7>] sch_direct_xmit+0xf7/0x1d0 [<ffffffff813b34d3>] __dev_queue_xmit+0x203/0x640 [<ffffffff813b3320>] ? __dev_queue_xmit+0x50/0x640 [<ffffffff813f3f6f>] ? ip_finish_output+0x1df/0x310 [<ffffffff813b3933>] dev_queue_xmit_sk+0x13/0x20 [<ffffffff813f3a5c>] ip_finish_output2+0x22c/0x470 [<ffffffff813f3f6f>] ? ip_finish_output+0x1df/0x310 [<ffffffff810987e0>] ? __lock_is_held+0x50/0x70 [<ffffffff813f3f6f>] ip_finish_output+0x1df/0x310 [<ffffffff813f4c31>] ip_output+0xb1/0x100 [<ffffffff813f41be>] ip_local_out_sk+0x3e/0x80 [<ffffffff813f4388>] ip_queue_xmit+0x188/0x4a0 [<ffffffff813f4200>] ? ip_local_out_sk+0x80/0x80 [<ffffffff8139fcd6>] ? __alloc_skb+0x86/0x1e0 [<ffffffff8140bd5b>] tcp_transmit_skb+0x4cb/0x9c0 [<ffffffff8139f0dc>] ? __kmalloc_reserve+0x3c/0x90 [<ffffffff8139fcea>] ? __alloc_skb+0x9a/0x1e0 [<ffffffff8140c47d>] tcp_send_ack+0x10d/0x150 [<ffffffff814060ee>] __tcp_ack_snd_check+0x5e/0x90 [<ffffffff81408eb4>] tcp_rcv_established+0x354/0x710 [<ffffffff81412182>] tcp_v4_do_rcv+0x162/0x3f0 [<ffffffff81414412>] tcp_v4_rcv+0xb22/0xb50 [<ffffffff813ee2bc>] ? ip_local_deliver_finish+0x4c/0x2d0 [<ffffffff813ee350>] ip_local_deliver_finish+0xe0/0x2d0 [<ffffffff813ee2bc>] ? ip_local_deliver_finish+0x4c/0x2d0 [<ffffffff813ee72e>] ip_local_deliver+0xae/0xc0 [<ffffffff813edeaf>] ip_rcv_finish+0x14f/0x510 [<ffffffff813aab2d>] ? __netif_receive_skb_core+0x9d/0xb70 [<ffffffff813eea13>] ip_rcv+0x2d3/0x3b0 [<ffffffff81097110>] ? cpuacct_css_alloc+0xb0/0xb0 [<ffffffff813ab0f3>] __netif_receive_skb_core+0x663/0xb70 [<ffffffff813aab2d>] ? __netif_receive_skb_core+0x9d/0xb70 [<ffffffff810971a9>] ? cpuacct_charge+0x99/0xb0 [<ffffffff81097110>] ? cpuacct_css_alloc+0xb0/0xb0 [<ffffffff810987e0>] ? __lock_is_held+0x50/0x70 [<ffffffff813ab72c>] ? process_backlog+0xbc/0x150 [<ffffffff813ab78b>] ? process_backlog+0x11b/0x150 [<ffffffff813ab627>] __netif_receive_skb+0x27/0x70 [<ffffffff813ab702>] process_backlog+0x92/0x150 [<ffffffff813afffd>] net_rx_action+0x13d/0x350 [<ffffffff81036b2d>] ? lapic_next_event+0x1d/0x30 [<ffffffff81058694>] __do_softirq+0x104/0x320 [<ffffffff810c0788>] ? hrtimer_interrupt+0xc8/0x1a0 [<ffffffff81074e70>] ? blocking_notifier_chain_cond_register+0x70/0x70 [<ffffffff81058ab9>] irq_exit+0x79/0xa0 [<ffffffff8147ecca>] smp_apic_timer_interrupt+0x4a/0x60 [<ffffffff8147d2c8>] apic_timer_interrupt+0x68/0x70 <EOI> [<ffffffff81271c02>] ? __memcpy+0x12/0x20 [<ffffffffa01517da>] ? visorchannel_write+0x4a/0x80 [visorbus] [<ffffffffa0151eb8>] signalinsert_inner+0x88/0x130 [visorbus] [<ffffffffa0151fb5>] visorchannel_signalinsert+0x55/0x70 [visorbus] [<ffffffffa0166e57>] visornic_rx+0x12e7/0x19d0 [visornic] [<ffffffffa01677c9>] process_incoming_rsps+0x289/0x690 [visornic] [<ffffffff814771c5>] ? preempt_schedule+0x25/0x30 [<ffffffff81001026>] ? ___preempt_schedule+0x12/0x14 [<ffffffff81093080>] ? wait_woken+0x90/0x90 [<ffffffffa0167540>] ? visornic_rx+0x19d0/0x19d0 [visornic] [<ffffffffa0167540>] ? visornic_rx+0x19d0/0x19d0 [visornic] [<ffffffff81073a39>] kthread+0xe9/0x110 [<ffffffff81073950>] ? __init_kthread_worker+0x70/0x70 [<ffffffff8147c89f>] ret_from_fork+0x3f/0x70 [<ffffffff81073950>] ? __init_kthread_worker+0x70/0x70 Fixes: b12fdf7d ('staging: unisys: rework signal remove/insert to avoid sparse lock warnings') Signed-off-by:Tim Sell <Timothy.Sell@unisys.com> Signed-off-by:
Benjamin Romer <benjamin.romer@unisys.com> Signed-off-by:
-
David Kershner authored
A visorchannel associated with a device should have its writing to the channel protected by a lock. Fixes: b32c4997 ('staging: unisys: Move channel creation up the stack') Signed-off-by:
David Kershner <david.kershner@unisys.com> Signed-off-by:
-
Christophe JAILLET authored
Remove some extra tabs in order to improve readalibility. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
This patch turns a kmalloc/memset into an equivalent kzalloc. Signed-off-by:
-
Tim Sell authored
visorchannel_write() and it's user visorbus_write_channel() are exported, so all visorbus function drivers (i.e., drivers that call visorbus_register_visor_driver()) are potentially affected by the bug. Because of pointer-arithmetic rules, the address being written to in the affected code was actually at byte offset: sizeof(struct channel_header) * offset instead of just <offset> bytes as intended. The bug could cause some very difficult-to-diagnose symptoms. The particular problem that led me on this chase was a kernel fault that would occur during 'insmod visornic' after a previous 'rmmod visornic', where we would fault during netdev_register_kobject() within pm_runtime_set_memalloc_noio() while traversing a device list, which occurred because dev->parent for the visorbus device had become corrupted. Fixes: 0abb60c1 ('staging: unisys: visorchannel_write(): Handle...') Signed-off-by:Don Zickus <dzickus@redhat.com> Signed-off-by:
-
Tim Sell authored
I'm not sure what adverse runtime effects the previously-omitted NULL-termination would cause, but the code was definitely wrong. Fixes: 79573162 ('staging: unisys: Clean up device sysfs attributes') Signed-off-by:
-
Ken Cox authored
When building with ARCH=um you get the following error: arch/x86/include/asm/cpufeature.h:252:42: error: 'REQUIRED_MASK0' undeclared The Unisys drivers should not be compiled for UML, so this patch addresses that by adding a dependency to kconfig for !UML. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Tested-by:
Ken Cox <jkc@redhat.com> Signed-off-by:
-
David Kershner authored
We inadvertently remove the MODULE_DEVICE_TABLE line for visorbus, this patch adds it back in. Signed-off-by:
-
Tim Sell authored
A struct visornic_devdata for each visornic device is actually allocated as part of alloc_etherdev(), here in visornic_probe(): netdev = alloc_etherdev(sizeof(struct visornic_devdata)); But code in devdata_release() was treating devdata as a pointer that needed to be kfree()d! This was causing all sorts of weird behavior after doing an rmmod of visornic, both because free_netdev() was actually freeing the memory used for devdata, and because devdata wasn't pointing to dynamically-allocated memory in the first place. The kfree(devdata) and the kref that tracked devdata's usage have been appropriately deleted. Signed-off-by: -
Tim Sell authored
Just switch this line so it uses the correct function call. Signed-off-by:
-
Tim Sell authored
This only makes sense, since the worker thread depends upon the netdev existing. Signed-off-by:
-
Tim Sell authored
visornic_cleanup() was previously incorrectly destroying its global workqueues prior to cleaning up the devices which used them. This patch corrects the order of these operations. Signed-off-by:
-
Tim Sell authored
visornic_remove() is called to logically detach the visornic driver from a visorbus-supplied device, which can happen either just prior to a visorbus-supplied device disappearing, or as a result of an rmmod of visornic. Prior to this patch, logic was missing to properly clean up for this removal, which was fixed via the following changes: * A going_away flag is now used to interlock between device destruction and workqueue operations, protected by priv_lock. I.e., setting going_away=true under lock guarantees that no new work items can get queued to the work queues. going_away=true also short-circuits other operations to enable device destruction to proceed. * Missing clean-up operations for the workqueues, netdev, debugfs entries, and the worker thread were added. * Memory referenced from the visornic private devdata struct is now freed as part of devdata destruction. Signed-off-by:
-
Tim Sell authored
Looks like an errant patch fitting caused us to redundantly allocate the workqueues at both the beginning and end of visornic_init(). This was corrected by removing the allocations at the beginning. Signed-off-by:
-
Tim Sell authored
Add error message to genuine rare error paths, and debug messages to enable relatively non-verbose tracing of code paths You can enable debug messages by including this on the kernel command line: visornic.dyndbg=+p or by this from the command line: echo "module visornic +p" > <debugfs>/dynamic_debug/control Refer to Documentation/dynamic-debug-howto.txt for more details. In addition to the new debug and error messages, a message like the following will be logged every time a visornic device is probed, which will enable you to map back-and-forth between visorbus device names (e.g., "vbus2:dev0") and netdev names (e.g., "eth0"): visornic vbus2:dev0: visornic_probe success netdev=eth0 With this patch and visornic debugging enabled, you should expect to see messages like the following in the most-common scenarios: * driver loaded: visornic_init * device probed: visornic vbus2:dev0: visornic_probe visor_thread_start visor_thread_start success * network interface configured (ifconfig): net eth0: visornic_open net eth0: visornic_enable_with_timeout net eth0: visornic_enable_with_timeout success net eth0: visornic_open success Signed-off-by: -
Tim Sell authored
Neglect to NULL rcvbuf pointer array could result in faults later This problem would exhibit itself as a fault when when attempting to stop any visornic device (i.e., in visornic_disable_with_timeout() or visornic_serverdown_complete()) that had never been started (i.e., for which init_rcv_bufs() had never been called). Because the array of rcvbuf was never cleared to NULLs, we would mistakenly attempt to call kfree_skb() on garbage memory. Signed-off-by:
-
Tim Sell authored
Prevent faults in visornic_pause, visornic_resume(), and visornic_remove() Prior to this patch, any call to visornic_pause(), visornic_resume(), or visornic_remove() would fault, due to dev_set_drvdata() never having been called to stash our struct visornic_devdata * into the device's drvdata. I.e., all calls to dev_get_drvdata() were returning NULL, meaning a fault was soon to follow. Signed-off-by:
-
Tim Sell authored
Correct visornic_pause() to indicate completion asynchronously rather than in-line Previously, visornic_pause() (called to stop the device due to IOVM service partition recovery) was calling the passed complete_func() in-line, rather than delaying the calling until after the device had actually been stopped. The behavior has been corrected so that the calling of the complete_func() is now delayed until after the stopping of the device has been completed in visornic_serverdown_complete(), which runs asynchronously via the workqueue visornic_serverdown_workqueue. Signed-off-by:
-
Tim Sell authored
Prevent faults processing messages for devices that no driver has yet registered to handle. Previously, code of the form: drv = to_visor_driver(dev->device.driver); if (!drv) goto away; was not having the desired intent, because to_visor_driver() was essentially returning garbage if its argument was NULL. The only existing case of this is in initiate_chipset_device_pause_resume(), which is called during IOVM service partition recovery. We were thus faulting when IOVM service partition recovery was initiated on a bus that had at least one device for which no function driver had registered (visorbus_register_visor_driver). Signed-off-by: -
Tim Sell authored
Fix problem that prevents us from responding to any device message after device_create. By neglecting to NULL out pending_msg_hdr after the device_create response, we were effectively preventing any subsequent messages to the device from working, because device_epilog() will correctly bail out early if it sees that pending_msg_hdr is still set non-NULL, as that is an indicator to mean that an unanswered message is still outstanding. This problem was discovered as part of testing IOVM service partition recovery, because device_epilog() was in fact bailing out when it was called from my_device_changestate(), which of course prevented us from transitioning the device to the paused state. However, the incorrect behavior would occur for ANY subsequent command directed at the device, not just for changestate. Signed-off-by:
-
Anders Fridlund authored
This is a patch to the ddk750_dvi.h file that fixes up a brace error found by the checkpatch.pl tool Signed-off-by:
Anders Fridlund <anders.fridlund@gmail.com> Signed-off-by:
-
Vinay Simha BN authored
kernel coding style fixes for below messages from scripts/checkpatch.pl ERROR: do not initialise globals to 0 or NULL Signed-off-by:
Vinay Simha BN <simhavcs@gmail.com> Signed-off-by:
-
Anatoly Stepanov authored
Add spaces according to checkpatch.pl messages: "ERROR: spaces required around that '=' (ctx:VxV)" "ERROR: need consistent spacing around '-' (ctx:WxV)" "ERROR: spaces required around that '?' (ctx:VxE)" "ERROR: need consistent spacing around '&' (ctx:VxW)" Signed-off-by:
Anatoly Stepanov <drivengroove@gmail.com> Signed-off-by:
-
Anatoly Stepanov authored
Fix according to checkpatch.pl message: "ERROR: open brace '{' following function declarations go on the next line" Signed-off-by: -
Anatoly Stepanov authored
Remove assignment from if condition according to checkpatch.pl message: "ERROR: do not use assignment in if condition" Signed-off-by:
-
Anatoly Stepanov authored
Fix according to checkpatch.pl message: "ERROR: switch and case should be at the same indent" Signed-off-by:
-
Anatoly Stepanov authored
Fix indentation according to checkpatch.pl message: "ERROR: space required after that close brace '}'" Signed-off-by:
-
Anatoly Stepanov authored
Fix open braces according to checkpatch.pl message: "ERROR: that open brace { should be on the previous line" Signed-off-by: -
Anatoly Stepanov authored
Fix indentation of pointer operator '*' according to checkpatch.pl message: "ERROR: 'foo* bar' should be 'foo *bar' " Signed-off-by:
-
Anatoly Stepanov authored
Insert spaces before '(' according to checkpatch.pl message: "ERROR: space required before the open parenthesis" Signed-off-by: -
Anatoly Stepanov authored
Insert spaces according to checkpatch.pl message: "ERROR: space required before the open brace '{'" Signed-off-by: -
Anatoly Stepanov authored
Remove trailing whitespaces according to checkpatch.pl error message: "ERROR: trailing whitespace" Signed-off-by:
-
Anatoly Stepanov authored
Replace spaces with tabs according to checkpatch.pl error message: "ERROR: code indent should use tabs where possible" Signed-off-by:
-
Hari Prasath Gujulan Elango authored
This patch removes the redundant __func__ from dynamic debug prints as the pr_xxx set of functions can be dynamically controlled to include function name.Also fix a typo in debug statement. Signed-off-by:
Hari Prasath Gujulan Elango <hgujulan@visteon.com> Signed-off-by:
-
Santhosh Pai authored
This patch fixes the checkpatch.pl warning: WARNING: ENOSYS means 'invalid syscall nr' and nothing else try_module_get fails when the reference count of the module is not allowed to be incremented ,and hence -ENXIO is returned indicating no device or address. [IA - combined two of santhosh's changes to the error return value!] Signed-off-by:
santhosh pai <santhosh.pai88@yahoo.com> Reviewed-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Ian Abbott authored
If the "comedi" module has been loaded with the "comedi_num_legacy_minors" module parameter set to a non-zero value, some reserved comedi devices get created. These can be attached to a low-level comedi driver using the `COMEDI_DEVCONFIG` ioctl command, which checks for the `CAP_SYS_ADMIN` capability. Of course, the comedi device needs to be opened before the ioctl command can be sent. If the comedi device is unattached, `comedi_open()` currently requires the `CAP_NET_ADMIN` capability. It makes more sense to just require the `CAP_SYS_ADMIN` capability here, so change it. For the curious, commit a8f80e8f ("Networking: use CAP_NET_ADMIN when deciding to call request_module") changed this capability from `CAP_SYS_MODULE` to `CAP_NET_ADMIN`, even though it doesn't seem relevant here. The original `CAP_SYS_MODULE` capability was due to the function having some code to request a module using a "char-major-%i-%i" alias, but that was never compiled in and was removed by commit f30f2c2d ("staging: comedi: remove check for CONFIG_KMOD"). Signed-off-by:
-
Ian Abbott authored
The analog output range is not programmable, but the ranges for each of the two analog output channels are settable via jumpers. These jumper settings are not readable by the driver. The driver provides a range table containing all the possible internal ranges (+/-10V, +/-5V, 0-10V, 0-5V) to provide information to the user application (although any range selected by the application that differs from the jumper settings will not produce the expected voltage output). The range table does not cover all possible ranges of the analog output channels. The jumpers also allow an external reference voltage between 0 and 10V to be used as bipolar or unipolar output range. Add a couple more ranges to the end of the range table to define these two external ranges. Signed-off-by:
-
