Smatch 1.57 released
Smatch is a C static analysis tool, but with a lot of kernel specific checks. It's been 8 months since I did a Smatch release so probably another one was due. The main interesting thing right now is the value tracking across function boundaries with the database. But also there was a some work done with array out of bounds detection. And internally there was a fix so it should run faster and use less memory. Along with lots of other small fixes. The way to use Smatch is: git clone git://repo.or.cz/smatch.git cd smatch make cd ~/path/to/kernel [ This next step is optional if you want to build the database. If you build it several times the database becomes more complete. ] ~/path/to/smatch/smatch_scripts/build_kernel_data.sh ~/path/to/smatch/smatch_scripts/test_kernel.sh It creates warns.txt file with all the warnings. Or alternatively if you just want to check one file then the command is: ~/progs/smatch/devel/smatch_scripts/kchecker drivers/file.c regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: gdm72xx: wm_ioctl.h: fixed a macro coding style
On Thu, Nov 01, 2012 at 11:42:59PM -0700, Kumar Amit Mehta wrote: fix for macro coding style. No. The parenthesis are not needed. I assume this is a checkpatch.pl warning? regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: gdm72xx: wm_ioctl.h: fixed a macro coding style
On Fri, Nov 02, 2012 at 12:36:30AM -0700, Kumar amit mehta wrote: On Fri, Nov 02, 2012 at 09:55:55AM +0300, Dan Carpenter wrote: On Thu, Nov 01, 2012 at 11:42:59PM -0700, Kumar Amit Mehta wrote: fix for macro coding style. No. The parenthesis are not needed. I assume this is a checkpatch.pl warning? regards, dan carpenter Running checkpatch.pl on this file (wm_ioctl.h) returns error. I think there are patches which fix checkpatch.pl for this but they haven't been merged yet? $ ./scripts/checkpatch.pl -f drivers/staging/gdm72xx/wm_ioctl.h ERROR: Macros with complex values should be enclosed in parenthesis #94: FILE: staging/gdm72xx/wm_ioctl.h:94: +#define ifr_name ifr_ifrn.ifrn_name total: 1 errors, 0 warnings, 97 lines checked regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at block/genhd.c:1570 disk_clear_events+0xbf/0xd0()
Hi, I have created a bug for this: https://bugzilla.kernel.org/show_bug.cgi?id=47871 Please add the following information: *) Last known good kernel version *) Current broken kernel version *) Complete dmesg regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec/kdump kernel fails to start
On Wed, Sep 05, 2012 at 11:34:25PM +0800, Cong Wang wrote: On Wed, Sep 5, 2012 at 1:32 AM, Flavio Leitner f...@redhat.com wrote: Hi folks, I have system that no longer boots kdump kernel. Basically, # echo c /proc/sysrq-trigger to dump a vmcore doesn't work. It just hangs after showing the usual panic messages. I've bisected the problem and the commit introducing the issue is the one below. Any idea? commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8 Author: WANG Cong xiyou.wangc...@gmail.com 2012-03-05 20:05:13 Committer: Ingo Molnar mi...@elte.hu 2012-03-06 05:38:26 Parent: 550cf00dbc8ee402bef71628cb71246493dd4500 (Merge tag 'mmc-fixes-for-3.3' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Child: a6fca40f1d7f3e232c9de27c1cebbb9f787fbc4f (x86, tlb: Switch cr3 in leave_mm() only when needed) Branches: master, remotes/origin/master Follows: v3.3-rc6 Precedes: v3.5-rc1 x86/mm: Fix the size calculation of mapping tables There was some attempt to fix this: https://patchwork.kernel.org/patch/1195751/ but for some reason it is not accepted. I filed a bug for this: https://bugzilla.kernel.org/show_bug.cgi?id=47881 Is it fixed now? regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Freeze or Oops on recent kernels
I'm not going to file a bug for this on bugzilla because it's ancient and not a new bug. But I can forward it to linux-media and the get_maintainer.pl people for cx23885_video. HINT: We only care about the very most recent kernel. If you can take a photo of the stack trace, then file a bug report and attach the .jpg. regards, dan carpenter On Fri, Sep 07, 2012 at 09:24:13PM +1000, yvahk-xre...@zacglen.net wrote: I am getting either a a kernel Oops or freeze (without any console output) on recent kernels. I have tested on 2.6.32.26 PAE, 3.1.9 PAE, and 3.4.9 PAE all with similar results. The hardware involved comprises mainly: 12 GB ram Intel DX58S02 motherboard Intel Xeon E5220 2 x onboard ethernet Intel PRO/1000 PT Dual Port ethernet Hauppauge HVR1700 DVB-T PCIe card Technisat SkyStar2 DVB-T PCI card The oops or freeze occurs when both DVB cards are recording simultaneously. With either card installed on their own there is never any problem. I should also add that the exact same kernel and cards on a Gigabyte GA-P31-S3G motherboard + Intel Pentium 4 the problem NEVER occurs. So there may be a DX58S02/timing/interrupt issue. When there is an oops it is like this (hand-transcribed from 2.6.32.26 PAE kernel): c0789444 panic + 3e/e9 oops_end + 97/a6 no_context + 13b/145 __bad_area_nosemaphore + ec/f4 ? do_page_fault + 0/29f bad_area_nosemaphore + 12/15 do_page_fault + 139/29f ? do_page_fault + 139/29f c078b54b error_code + 73/78 f82084fb ? cx23885_video_irq + d8/1dc f820b04d cx23885_irq + 3df/3fe c04834ac handle_irq_event + 57/fd handle_fasteoi_irq + 6f/a2 handle_irq + 40/4d do_IRQ + 46/9a common_interrupt + 30/38 c045b7a9 ? prepare_to_wait + 14c f7fef5a5 ? videobug_waitm + 90/133 c045b601 ? autoremove_waker_function + 0/34 f805e5bc videobuf_dvb_thread + 73/135 f805e4f9 ? videobuf_dvb_thread + 0/135 c045b3c9 kthread + 64/69 ? kthread + 0/69 kernel_thread_helper + 7/10 Although I am a very experienced programmer I have next to zero kernel expertise except for minor patching of a few drivers. My guess from the stack trace is that there might be an issue with page fault recursion (if that is at all possible). Anyhow I don't want to waste too much of my time or anybody elses on this - although with the problem occuring with 3.4.9 kernel which has significant interrupt handling changes it probably is something that somebody might want to know about. If anybody can spot a clue as to where I should be looking and how I should go about isolating the problem (if only kernel core dumped!) please let me know and I will possibly try and assist. I need some guidance. Regards John W. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Freeze or Oops on recent kernels
On Mon, Sep 24, 2012 at 04:52:32PM +1000, yvahk-xre...@zacglen.net wrote: HINT: We only care about the very most recent kernel. If you can take a photo of the stack trace, then file a bug report and attach the .jpg. After a bit of experimentation my guess is that is is all about bad Intel DX58SO2 motherboard. And my guess is that it has something to do with memory mapping during an interrupt. Don't know much about memory mapping but I suspect that something quite fundamental goes wrong with this motherboard only. Exact same type of oops also happens with a PCIe RS232 serial card. There is not enough information here for us to help you. Sorry. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iwl3945: order 5 allocation during ifconfig up; vm problem?
On Wed, Sep 12, 2012 at 08:54:06AM +0200, Johannes Berg wrote: On Tue, 2012-09-11 at 22:57 -0700, Marc MERLIN wrote: On Wed, Sep 12, 2012 at 07:16:28AM +0200, Eric Dumazet wrote: On Tue, 2012-09-11 at 16:25 -0700, Andrew Morton wrote: Asking for a 256k allocation is pretty crazy - this is an operating system kernel, not a userspace application. I'm wondering if this is due to a recent change, but I'm having trouble working out where the allocation call site is. -- (Adding Marc Merlin to CC, since he reported same problem) Thats the firmware loading in iwlwifi driver. Not sure if it can use SG. drivers/net/wireless/iwlwifi/iwl-drv.c iwl_alloc_ucode() - iwl_alloc_fw_desc() - dma_alloc_coherent() I'm filing bugzilla entries for regressions. What's the status on this? regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Suspend on Thinkpad x220: Hangs during resume
Hi, I have created a bug for this: https://bugzilla.kernel.org/show_bug.cgi?id=47901 Please add the following information: *) Last known good kernel version *) Current broken kernel version *) Complete dmesg regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hot-added cpu is not asiggned to the correct node
On Wed, Sep 12, 2012 at 02:33:11PM +0900, Yasuaki Ishimatsu wrote: When I hot-added CPUs and memories simultaneously using container driver, all the hot-added CPUs were mistakenly assigned to node0. Is this something which used to work correctly? If so which was the most recent working kernel? regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging:bcm: fix coding style issue in Bcmchar.c
On Mon, Sep 24, 2012 at 04:44:43PM +0600, Gorskin Ilya wrote: This is a patch to the Bcmchar.c file that fixes up a coding style warning found by the checkpatch.pl tool The right way to fix this is to choose better variable names and to get rid of the bogus BCM_DEBUG_PRINT() macro. It's better to leave the warnings in for now. checkpatch.pl is not the king of us. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Staging:bcm: fix coding style error in InterfaceIsr.c
On Tue, Sep 25, 2012 at 11:04:28AM +0600, Gorskin Ilya wrote:
- if(((Adapter-bPreparingForLowPowerMode == TRUE)
(Adapter-bDoSuspend == TRUE)) ||
- psIntfAdapter-bSuspended ||
- psIntfAdapter-bPreparingForBusSuspend)
- {
- BCM_DEBUG_PRINT(Adapter,DBG_TYPE_OTHERS, INTF_INIT,
DBG_LVL_ALL,Interrupt call back is called while suspending the device);
+ if (((Adapter-bPreparingForLowPowerMode == TRUE)
+ (Adapter-bDoSuspend == TRUE)) ||
+ psIntfAdapter-bSuspended ||
+ psIntfAdapter-bPreparingForBusSuspend) {
+ BCM_DEBUG_PRINT(Adapter, DBG_TYPE_OTHERS, INTF_INIT,
+ DBG_LVL_ALL,
+ Interrupt call back is called
+ while suspending the device);
return ;
Hi,
Thanks for doing this, these changes are welcome. However, they
should be done slightly differently.
Take one type of checkpatch warning at a time and fix that one over
the file, then do a separate patch for the next type of warning.
[patch 1/2] Staging: bcm: move curly braces in InterfaceIsr.c
[patch 2/2] Staging: bcm: clean up conditions in InterfaceIsr.c
Something like that.
Also the way you've indented the condition is not right. The
conditions which are together should line up like this:
if (((Adapter-bPreparingForLowPowerMode == TRUE)
(Adapter-bDoSuspend == TRUE)) ||
psIntfAdapter-bSuspended ||
psIntfAdapter-bPreparingForBusSuspend) {
Also the condition has too many parenthesis. Everyone knows how the
precedence works in:
if (foo == 3 || bar == 4) {
We don't need to specify:
if ((foo == 3) || (bar == 4)) {
Putting extra parenthesis make the code harder to read and has lead
to == vs = bugs which would have been caught by gcc:
warning: suggest parentheses around assignment used as truth value
[-Wparentheses]
Also can we just leave off the == TRUE, or is this a case where it
can == TRUE, == FALSE, and == FILENOTFOUND?
Finally, this is not quoted correctly.
+ Interrupt call back is called
+ while suspending the device);
Don't break those string literals up across multiple lines, but if
you do then you need to add quotes.
Interrupt call back is called
^
while suspending the device);
^
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Staging:bcm: fix coding style error in InterfaceIsr.c
On Tue, Sep 25, 2012 at 11:04:29AM +0600, Gorskin Ilya wrote: This is a patch to the InterfaceIsr.c file that fixes up a coding style issues found by the checkpatch.pl tool I'm afraid all these need to be redone along the lines which I explained in my other email. Signed-off-by: Ilya Gorskin reven...@gmail.com --- drivers/staging/bcm/InterfaceIsr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/bcm/InterfaceIsr.c b/drivers/staging/bcm/InterfaceIsr.c index 4f78451..0e68485 100644 --- a/drivers/staging/bcm/InterfaceIsr.c +++ b/drivers/staging/bcm/InterfaceIsr.c @@ -120,7 +120,7 @@ static void read_int_callback(struct urb *urb/*, struct pt_regs *regs*/) urb-status = STATUS_SUCCESS ; break ; /*return;*/ - default: + default: /*This is required to check what is the defaults * conditions when it occurs..*/ BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, NEXT_SEND, Checkpatch is a tool that finds ugly code. You've silenced the warning. The code still looks like dog vommit, but now checkpatch doesn't find it. Don't do that. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] Staging:bcm: fix coding style error in InterfacerTx.c
On Tue, Sep 25, 2012 at 12:44:35PM +0600, Ilya gorskin wrote: This is a patch to the InterfaceTx.c file that fixes up a coding style issues found by the checkpatch.pl tool Stop! Read your email! Start over. Work more slowly. Don't do the bogus numbering: [patch] [patch 2/3] [patch 3/3] [patch 4/4] [patch 5/5]... Write your patches. Wait over night. Review it the next morning. Email it. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/3] remoteproc: memory leak in rproc_handle_carveout()
We only need to allocate mapping if there is an rproc domain.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Static checker stuff. Handle with appropriate caution.
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index b6c6229..f163704 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -573,17 +573,10 @@ static int rproc_handle_carveout(struct rproc *rproc,
dev_dbg(dev, carveout rsc: da %x, pa %x, len %x, flags %x\n,
rsc-da, rsc-pa, rsc-len, rsc-flags);
- mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
- if (!mapping) {
- dev_err(dev, kzalloc mapping failed\n);
- return -ENOMEM;
- }
-
carveout = kzalloc(sizeof(*carveout), GFP_KERNEL);
if (!carveout) {
dev_err(dev, kzalloc carveout failed\n);
- ret = -ENOMEM;
- goto free_mapping;
+ return -ENOMEM;
}
va = dma_alloc_coherent(dev-parent, rsc-len, dma, GFP_KERNEL);
@@ -613,11 +606,18 @@ static int rproc_handle_carveout(struct rproc *rproc,
* physical address in this case.
*/
if (rproc-domain) {
+ mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
+ if (!mapping) {
+ dev_err(dev, kzalloc mapping failed\n);
+ ret = -ENOMEM;
+ goto dma_free;
+ }
+
ret = iommu_map(rproc-domain, rsc-da, dma, rsc-len,
rsc-flags);
if (ret) {
dev_err(dev, iommu_map failed: %d\n, ret);
- goto dma_free;
+ goto free_mapping;
}
/*
@@ -662,12 +662,12 @@ static int rproc_handle_carveout(struct rproc *rproc,
return 0;
+free_mapping:
+ kfree(mapping);
dma_free:
dma_free_coherent(dev-parent, rsc-len, va, dma);
free_carv:
kfree(carveout);
-free_mapping:
- kfree(mapping);
return ret;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 2/3] remoteproc: snprintf() can return more than was printed
snprintf() returns the number of characters which would have been printed if there were enough space. For example, on the first print if we fill up the 28 character string then it would return a number more than 30. Use scnprintf() instead because that returns the actual number of characters printed. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c index 10a3825..ea90a56 100644 --- a/drivers/remoteproc/remoteproc_debugfs.c +++ b/drivers/remoteproc/remoteproc_debugfs.c @@ -82,7 +82,7 @@ static ssize_t rproc_state_read(struct file *filp, char __user *userbuf, state = rproc-state RPROC_LAST ? RPROC_LAST : rproc-state; - i = snprintf(buf, 30, %.28s (%d)\n, rproc_state_string[state], + i = scnprintf(buf, 30, %.28s (%d)\n, rproc_state_string[state], rproc-state); return simple_read_from_buffer(userbuf, count, ppos, buf, i); @@ -103,7 +103,7 @@ static ssize_t rproc_name_read(struct file *filp, char __user *userbuf, char buf[100]; int i; - i = snprintf(buf, sizeof(buf), %.98s\n, rproc-name); + i = scnprintf(buf, sizeof(buf), %.98s\n, rproc-name); return simple_read_from_buffer(userbuf, count, ppos, buf, i); } -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 3/3] remoteproc: return -EFAULT on copy_from_user failure
copy_from_user() returns the number of bytes remaining to be copied, but we want to return an error code here. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/remoteproc/remoteproc_debugfs.c b/drivers/remoteproc/remoteproc_debugfs.c index ea90a56..157a573 100644 --- a/drivers/remoteproc/remoteproc_debugfs.c +++ b/drivers/remoteproc/remoteproc_debugfs.c @@ -161,7 +161,7 @@ rproc_recovery_write(struct file *filp, const char __user *user_buf, ret = copy_from_user(buf, user_buf, count); if (ret) - return ret; + return -EFAULT; /* remove end of line */ if (buf[count - 1] == '\n') -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at kernel/workqueue.c:1066 try_to_grab_pending
Added Tejun to the CC list. regards, dan carpenter On Fri, Sep 14, 2012 at 02:07:24AM +, Jongman Heo wrote: Hi Guys, I hit this warning with current linus + for-next branch of wq.git, running Fedora 17 on VMWare linux guest. [89449.738642] [ cut here ] [89453.060422] WARNING: at kernel/workqueue.c:1066 try_to_grab_pending+0x38/0x112() [89454.328625] Hardware name: VMware Virtual Platform [89454.328635] Modules linked in: vmwgfx ttm drm [89455.530576] Pid: 327, comm: jbd2/sda3-8 Not tainted 3.6.0-rc5+ #27 [89455.530582] Call Trace: [89455.530730] [c042c5ba] warn_slowpath_common+0x77/0x8c [89456.608291] [c04414b6] ? try_to_grab_pending+0x38/0x112 [89456.608306] [c04414b6] ? try_to_grab_pending+0x38/0x112 [89456.608314] [c042c5ec] warn_slowpath_null+0x1d/0x1f [89456.608320] [c04414b6] try_to_grab_pending+0x38/0x112 [89456.608325] [c0441688] mod_delayed_work_on+0x1f/0x51 [89456.608331] [c04416d1] mod_delayed_work+0x17/0x19 [89457.699645] [c0826a31] linkwatch_schedule_work+0x57/0x66 [89457.699656] [c0826ac6] linkwatch_fire_event+0x86/0x8b [89458.723637] [c082c844] netif_carrier_on+0x22/0x33 [89458.764724] [c07322ff] vmxnet3_check_link+0x7d/0x13b [89458.764743] [c07323f8] vmxnet3_process_events+0x3b/0x10c [89458.764748] [c0732509] vmxnet3_msix_event+0x40/0x5c [89458.765129] [c047f29a] handle_irq_event_percpu+0x44/0x18b [89458.765261] [c046e834] ? arch_local_irq_save+0x12/0x17 [89458.765387] [c0481306] ? unmask_irq+0x1e/0x1e [89458.765393] [c047f406] handle_irq_event+0x25/0x3f [89458.765397] [c0481306] ? unmask_irq+0x1e/0x1e [89458.765401] [c0481388] handle_edge_irq+0x82/0x9d [89458.765403] IRQ [c0403ed1] ? do_IRQ+0x37/0x8d [89458.795193] [c06f5e7d] ? scsi_finish_command+0xd2/0xda [89458.795210] [c06fa58b] ? scsi_decide_disposition+0xfd/0x188 [89458.795219] [c0432a8a] ? ftrace_define_fields_irq_handler_entry+0x71/0x71 [89460.964638] [c08e7a30] ? common_interrupt+0x30/0x38 [89460.964657] [c0432a8a] ? ftrace_define_fields_irq_handler_entry+0x71/0x71 [89462.112729] [c06300d8] ? des3_ede_setkey+0x3bf/0x754 [89462.112750] [c043212f] ? arch_local_irq_enable+0x7/0xb [89462.112756] [c0432ae3] ? __do_softirq+0x59/0x18d [89462.112763] [c0432a8a] ? ftrace_define_fields_irq_handler_entry+0x71/0x71 [89462.112766] IRQ [c0432d79] ? irq_exit+0x35/0x86 [89462.115903] [c041c8c5] ? smp_apic_timer_interrupt+0x64/0x71 [89462.115965] [c06fc56e] ? scsi_setup_fs_cmnd+0x6e/0x73 [89462.115980] [c08e260d] ? apic_timer_interrupt+0x31/0x38 [89462.115989] [c046e811] ? arch_local_irq_restore+0x5/0xb [89462.115995] [c08e20e6] ? _raw_spin_unlock_irqrestore+0xf/0x11 [89462.116002] [c0741dad] ? mptspi_qcmd+0x9f/0xa8 [89462.116010] [c06f5e85] ? scsi_finish_command+0xda/0xda [89462.116016] [c06f6f09] ? scsi_dispatch_cmd+0x150/0x1f7 [89463.216101] [c063a38b] ? blk_add_timer+0x6f/0x91 [89463.216122] [c06fc2e0] ? scsi_request_fn+0x452/0x47a [89464.329451] [c04d1168] ? kmem_cache_alloc+0x73/0xd7 [89465.360988] [c04a5f1f] ? mempool_alloc_slab+0xe/0x10 [89465.361007] [c0631af1] ? __blk_run_queue+0x14/0x16 [89465.361013] [c06345e9] ? queue_unplugged+0x5b/0x80 [89465.361018] [c0407156] ? read_tsc+0x9/0x26 [89465.361023] [c0636f2c] ? blk_flush_plug_list+0x153/0x163 [89465.361095] [c08e190c] ? io_schedule+0x38/0x62 [89465.361101] [c04a423d] ? sleep_on_page+0x8/0xc [89465.361105] [c08e0a7f] ? __wait_on_bit+0x34/0x5b [89465.376234] [c04a4235] ? lock_page+0x20/0x20 [89465.376252] [c04a43ad] ? wait_on_page_bit+0x59/0x60 [89465.376259] [c04451c2] ? autoremove_wake_function+0x34/0x34 [89465.376263] [c04a4487] ? filemap_fdatawait_range+0x73/0x123 [89465.376339] [c04f985f] ? bio_alloc_bioset+0x37/0x97 [89466.049333] [c058649d] ? jbd2_journal_write_metadata_buffer+0x26a/0x27d [89466.049352] [c04a4568] ? filemap_fdatawait+0x31/0x3b [89466.049359] [c058034a] ? jbd2_journal_commit_transaction+0x9b7/0x12f1 [89466.049366] [c0583ff5] ? kjournald2+0xa1/0x1f7 [89466.049373] [c044518e] ? remove_wait_queue+0x27/0x27 [89466.049377] [c0444cd8] ? kthread+0x59/0x5e [89466.049382] [c0583f54] ? commit_timeout+0xa/0xa [89466.049387] [c0444c7f] ? kthread_freezable_should_stop+0x3b/0x3b [89466.049394] [c08e7a3e] ? kernel_thread_helper+0x6/0xd [89466.049398] ---[ end trace 1311b68903c57261 ]--- [89510.373372] eth0: NIC Link is Down [89515.678226] eth0: NIC Link is Up 1 Mbps [95685.119369] eth0: NIC Link is Down [95693.639798] eth0: NIC Link is Up 1 Mbps [95770.746511] eth0: NIC Link is Down [95775.963195] eth0: NIC Link is Up 1 Mbps [167185.224550] BUG: soft lockup - CPU#1 stuck for 21s! [nmbd:753] [167185.435684] Modules linked in: vmwgfx ttm drm [167185.754011] Pid: 753, comm: nmbd Tainted: GW3.6.0-rc5+ #27 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform [167185.840437] EIP: 0060:[c046437f] EFLAGS: 0207 CPU: 1 [167185.982084] EIP
Re: kernel BUG at fs/buffer.c:3205 (stable 3.5.3)
Did any of the old kernels work? Have you ruled out bad hardware? If the answers to both questions are yes then it makes your email harder to ignore. In which case, we'd probably want the complete dmesg. The USB mailing list is linux-...@vger.kernel.org. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: w/ current kernel (3.5.3) I need 2 attempts for s2disk in a row
Hi, I have created a bug for this: https://bugzilla.kernel.org/show_bug.cgi?id=47931 Please add the following information: *) Last known good kernel version *) Complete dmesg regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Backlight control broken between 3.6.0-rc1 and 3.6.0-rc4
On Sun, Sep 16, 2012 at 04:25:10AM -0700, Grant wrote: I have a Dell XPS 13 Ultrabook laptop. Backlight control used to be broken, it works in 3.6.0-rc1, and it is broken again in 3.6.0-rc4. I've filed a bug for this. https://bugzilla.kernel.org/show_bug.cgi?id=47941 Please add the following information: *) Complete dmesg *) lsmod, working and non-working *) .config regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging/gdm72xx: coding style fixes gdm_qos.c
On Tue, Sep 25, 2012 at 04:53:52PM +0400, Alexey Khoroshilov wrote: Fix checkpatch.pl warnings: WARNING: Prefer pr_debug(... to printk(KERN_DEBUG, ... WARNING: Prefer pr_warn(... to printk(KERN_WARNING, ... WARNING: Prefer pr_err(... to printk(KERN_ERR, ... Better to just replace the dprintk macros instead of prettifying them. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: sbe-2t3e3: fix error handling in t3e3_init_channel()
On Tue, Sep 25, 2012 at 04:56:02PM +0400, Alexey Khoroshilov wrote: t3e3_init_channel() incorrectly handles errors in several places: it returns zero and does not deallocate all required resources. The patch fixes that places. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru Looks good. Reviewed-by: Dan Carpenter dan.carpen...@oracle.com regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: Thermal: Update binding logic based on platform data
Hello Durgadoss R,
This is a semi-automatic email about new static checker warnings.
The patch 9b70dfa68ae8: Thermal: Update binding logic based on
platform data from Sep 18, 2012, leads to the following Smatch
complaint:
drivers/thermal/thermal_sys.c:292 bind_tz()
error: we previously assumed 'tzp' could be null (see line 283)
drivers/thermal/thermal_sys.c
282 /* If there is no platform data, try to use ops-bind */
283 if (!tzp tz-ops-bind) {
New check.
284 list_for_each_entry(pos, thermal_cdev_list, node) {
285 ret = tz-ops-bind(tz, pos);
286 if (ret)
287 print_bind_err_msg(tz, pos, ret);
288 }
289 goto exit;
290 }
291
292 if (!tzp-tbp)
New dereference.
293 goto exit;
294
There are also some locking bugs which need to be fixed as well.
drivers/thermal/thermal_sys.c:268 bind_cdev() warn: inconsistent returns
mutex:thermal_list_lock: locked (256) unlocked (268)
drivers/thermal/thermal_sys.c:396 update_temperature() warn: inconsistent
returns mutex:tz-lock: locked (390) unlocked (396)
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging:vt6656: Fix tabs error in 80211mgr.c
On Wed, Sep 26, 2012 at 12:05:11PM +0600, Ilya gorskin wrote: This is a patch to the 80211mgr.c file that fixes up a tabs error found by the checkpatch.pl tool Signed-off-by: Goirskin Ilya reven...@gmail.com --- drivers/staging/vt6656/80211mgr.c | 628 +++--- 1 file changed, 310 insertions(+), 318 deletions(-) diff --git a/drivers/staging/vt6656/80211mgr.c b/drivers/staging/vt6656/80211mgr.c index 39f9842..4241d29 100644 --- a/drivers/staging/vt6656/80211mgr.c +++ b/drivers/staging/vt6656/80211mgr.c @@ -98,11 +98,11 @@ vMgrEncodeBeacon( /* Fixed Fields */ pFrame-pqwTimestamp = (PQWORD)(WLAN_HDR_A3_DATA_PTR((pFrame-pHdr-sA3)) -+ WLAN_BEACON_OFF_TS); + + WLAN_BEACON_OFF_TS); This was aligned correctly in the original. (Although the line is messy so it explains why you were confused). pFrame-pwBeaconInterval = (PWORD)(WLAN_HDR_A3_DATA_PTR((pFrame-pHdr-sA3)) - + WLAN_BEACON_OFF_BCN_INT); + + WLAN_BEACON_OFF_BCN_INT); pFrame-pwCapInfo = (PWORD)(WLAN_HDR_A3_DATA_PTR((pFrame-pHdr-sA3)) -+ WLAN_BEACON_OFF_CAPINFO); + + WLAN_BEACON_OFF_CAPINFO); pFrame-len = WLAN_HDR_ADDR3_LEN + WLAN_BEACON_OFF_SSID; @@ -132,98 +132,90 @@ vMgrDecodeBeacon( /* Fixed Fields */ pFrame-pqwTimestamp = (PQWORD)(WLAN_HDR_A3_DATA_PTR((pFrame-pHdr-sA3)) -+ WLAN_BEACON_OFF_TS); + + WLAN_BEACON_OFF_TS); pFrame-pwBeaconInterval = (PWORD)(WLAN_HDR_A3_DATA_PTR((pFrame-pHdr-sA3)) - + WLAN_BEACON_OFF_BCN_INT); + + WLAN_BEACON_OFF_BCN_INT); pFrame-pwCapInfo = (PWORD)(WLAN_HDR_A3_DATA_PTR((pFrame-pHdr-sA3)) -+ WLAN_BEACON_OFF_CAPINFO); + + WLAN_BEACON_OFF_CAPINFO); /* Information elements */ pItem = (PWLAN_IE)((PBYTE)(WLAN_HDR_A3_DATA_PTR((pFrame-pHdr-sA3))) - + WLAN_BEACON_OFF_SSID); + + WLAN_BEACON_OFF_SSID); Actually all of these were more correct in the original. Ah. I see the problem. The original used spaces. Still the alignment was better. It should be: [tab] [tab] [tab] [space] [space] You're allowed to use spaces to get the alignment to work. Really the '+' should probably be on the line before. But it's not worth sending a patch over. pFrame-pwCapInfo = (PWORD)(WLAN_HDR_A3_DATA_PTR((pFrame-pHdr-sA3)) -+ WLAN_REASSOCREQ_OFF_CAP_INFO); + + WLAN_REASSOCREQ_OFF_CAP_INFO); pFrame-pwListenInterval = (PWORD)(WLAN_HDR_A3_DATA_PTR((pFrame-pHdr-sA3)) - + WLAN_REASSOCREQ_OFF_LISTEN_INT); + + WLAN_REASSOCREQ_OFF_LISTEN_INT); Really??? I'm not a huge fan of the 80 character line limit, but at least the left side of the line should be within the 80 characters. Yeah. This patch is going nowhere. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
This is fixed now? regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thermal: Update binding logic based on platform data
On Wed, Sep 26, 2012 at 02:39:22PM +, R, Durgadoss wrote: Hi, -Original Message- From: Dan Carpenter [mailto:dan.carpen...@oracle.com] Sent: Wednesday, September 26, 2012 1:58 AM To: R, Durgadoss Cc: Zhang, Rui; linux-kernel@vger.kernel.org Subject: re: Thermal: Update binding logic based on platform data Hello Durgadoss R, This is a semi-automatic email about new static checker warnings. The patch 9b70dfa68ae8: Thermal: Update binding logic based on platform data from Sep 18, 2012, leads to the following Smatch complaint: looking into this. Will submit appropriate fix patches soon. Is there a way for me to check/verify these kind of warnings from my side ? This way, I can do the check before I submit each patch. Sure: git clone git://repo.or.cz/smatch.git cd smatch make (no make install needed) cd /to/kernel/src/ ~/path/to/smatch/smatch_scripts/kchecker drivers/thermal/thermal_sys.c regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] sound: Remove unnecessary semicolon
On Thu, Sep 27, 2012 at 01:43:18PM +0200, Peter Senna Tschudin wrote: Remove unnecessary semicolon And: sound/drivers/vx/vx_pcm.c: Convert spaces into tab Found by http://coccinelle.lip6.fr/ Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com --- Next time, could you put a little comment here under the --- line about what changed between v1 and v2? regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] ixgbe: add driver set_max_vfs support
On Wed, Oct 03, 2012 at 10:51:35AM -0700, Yinghai Lu wrote:
Need ixgbe guys to close the loop to use set_max_vfs instead
kernel parameters.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Jeff Kirsher jeffrey.t.kirs...@intel.com
Cc: Jesse Brandeburg jesse.brandeb...@intel.com
Cc: Greg Rose gregory.v.r...@intel.com
Cc: David S. Miller da...@davemloft.net
Cc: John Fastabend john.r.fastab...@intel.com
Cc: e1000-de...@lists.sourceforge.net
Cc: net...@vger.kernel.org
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h |2 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 44 +++-
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index b9623e9..d39d975 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -558,6 +558,8 @@ struct ixgbe_adapter {
u32 interrupt_event;
u32 led_reg;
+ struct ixgbe_info *ixgbe_info;
+
#ifdef CONFIG_IXGBE_PTP
struct ptp_clock *ptp_clock;
struct ptp_clock_info ptp_caps;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index ee61819..1c097c7 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -129,13 +129,6 @@ static struct notifier_block dca_notifier = {
};
#endif
-#ifdef CONFIG_PCI_IOV
-static unsigned int max_vfs;
-module_param(max_vfs, uint, 0);
-MODULE_PARM_DESC(max_vfs,
- Maximum number of virtual functions to allocate per physical
function - default is zero and maximum value is 63);
-#endif /* CONFIG_PCI_IOV */
-
static unsigned int allow_unsupported_sfp;
module_param(allow_unsupported_sfp, uint, 0);
MODULE_PARM_DESC(allow_unsupported_sfp,
@@ -4496,7 +4489,7 @@ static int __devinit ixgbe_sw_init(struct ixgbe_adapter
*adapter)
#ifdef CONFIG_PCI_IOV
/* assign number of SR-IOV VFs */
if (hw-mac.type != ixgbe_mac_82598EB)
- adapter-num_vfs = (max_vfs 63) ? 0 : max_vfs;
+ adapter-num_vfs = min_t(int, pdev-max_vfs, 63);
Could we make this min_t(uint, ...);
-max_vfs is type unsigned int. We take an unsigned long from sysfs.
We silently truncate it to an unsigned int. Then we cast it to a
negative number and compare against 63 and take the minimum...
It's root only so it's not a problem but it's a hassle to audit.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 19/20] drivers/net/ethernet/marvell/skge.c: fix error return code
On Fri, Oct 05, 2012 at 12:36:35AM -0700, Joe Perches wrote: On Fri, 2012-10-05 at 07:22 +0200, Julia Lawall wrote: A tool was used to find a potential problem, and then Peter studied the code to see what fix was appropriate. Hi Julia. Was it true that a static analysis tool found the original potential issue? If so, what tool was it? But wasn't the scripted fix applied to the rest of the tree robotically? It was coccinelle. It just prints a warning. You have to go in manually, review the code and pick the correct error code. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: block: Add driver for Micron RealSSD pcie flash cards
Hello Sam Bradshaw, The patch 88523a61558a: block: Add driver for Micron RealSSD pcie flash cards from Aug 30, 2011, creates an endian bug: drivers/block/mtip32xx/mtip32xx.c:2468 mtip_hw_submit_io() drivers/block/mtip32xx/mtip32xx.c 2465 fis-opts= 1 7; 2466 fis-command = 2467 (dir == READ ? ATA_CMD_FPDMA_READ : ATA_CMD_FPDMA_WRITE); 2468 *((unsigned int *) fis-lba_low) = (start 0xFF); 2469 *((unsigned int *) fis-lba_low_ex) = ((start 24) 0xFF); ^^^ These addresses point to a series of four unions inside the host_to_dev_fis struct. The unions will be set to different values depending on if the CPU is big or little endian. If you knew which endianness this works on, then you could probably add a cpu_to_be32() or cpu_to_le32(). 2470 fis-device = 1 6; 2471 fis-features= nsect 0xFF; regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] power: battery: pointer math issue in gab_probe()
On Mon, Nov 05, 2012 at 09:34:21PM +0900, anish kumar wrote: Hello Dan, Is this patch of yours picked up by anyone? David this should go through you? regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] Staging: winbond: wb35rx_s: Fixed coding style issue
It's better to use more descriptive subjects on the patches. This one could probably have been broken into smaller patches [patch 4/x] Staging: winbond: wb35rx_s: fix white space [patch 5/x] Staging: winbond: wb35rx_s: fix comments [patch 6/x] Staging: winbond: wb35rx_s: allow header to be included twice It's small enough that I don't have strong feelings about it, but in general that's how you should do it. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] gpio-timberdale: fix a potential wrapping issue
On Fri, Oct 12, 2012 at 11:01:08PM +0200, Linus Walleij wrote: On Thu, Oct 11, 2012 at 8:56 AM, Dan Carpenter dan.carpen...@oracle.com wrote: -last_ier is an unsigned long but the high bits can't be used int the original code because the shift wraps. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Applied, thanks! Should we send this to stable? (I assume so ...) This was a static checker fix. I guess the answer would depend on if there are over 30 IRQs. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/3] Add modules to support realtek PCIE card reader
On Sat, Oct 06, 2012 at 03:23:56PM +0800, wwang wrote: We are still maintaining the SCSI driver for Realtek card reader, and will release the latest source code in the Github in the future. But maybe we won't push it to the staging tree any more. Maybe we should just remove the staging code if it won't be fixed. That's sort of the point of staging. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] clocksource: clean up parse_pmtmr()
I changed the strict_strtoul() to kstrtouint(). That has the check
for UINT_MAX built in to it so the ifdefs can be removed. Also
I changed a printk() to pr_info().
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
index 6b5cf02..5d1b926 100644
--- a/drivers/clocksource/acpi_pm.c
+++ b/drivers/clocksource/acpi_pm.c
@@ -233,16 +233,15 @@ fs_initcall(init_acpi_pm_clocksource);
*/
static int __init parse_pmtmr(char *arg)
{
- unsigned long base;
+ unsigned int base;
+ int ret;
- if (strict_strtoul(arg, 16, base))
- return -EINVAL;
-#ifdef CONFIG_X86_64
- if (base UINT_MAX)
- return -ERANGE;
-#endif
- printk(KERN_INFO PMTMR IOPort override: 0x%04x - 0x%04lx\n,
- pmtmr_ioport, base);
+ ret = kstrtouint(arg, 16, base);
+ if (ret)
+ return ret;
+
+ pr_info(PMTMR IOPort override: 0x%04x - 0x%04x\n, pmtmr_ioport,
+ base);
pmtmr_ioport = base;
return 1;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
re: sched, numa, mm: Implement constant, per task Working Set Sampling (WSS) rate
Hello Peter Zijlstra,
The patch 3d049f8a5398: sched, numa, mm: Implement constant, per
task Working Set Sampling (WSS) rate from Oct 14, 2012, leads to the
following warning:
kernel/sched/fair.c:954 task_numa_work()
error: we previously assumed 'vma' could be null (see line 948)
943 if (!vma) {
944 ACCESS_ONCE(mm-numa_scan_seq)++;
945 offset = 0;
946 vma = mm-mmap;
947 }
948 while (vma !vma_migratable(vma)) {
^^^
If this is NULL,
949 vma = vma-vm_next;
950 if (!vma)
951 goto again;
952 }
953
954 offset = max(offset, vma-vm_start);
^
then it leads to a NULL dereference here.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.7 RC1
On Mon, Oct 22, 2012 at 04:37:45PM -0700, K. Y. Srinivasan wrote: While testing 3.7 RC1 I discovered that invoking the function orderly_poweroff() from an interrupt context will trigger an ASSERT(). This was not the case till recently. The comment preceding the orderly_poweroff() function claims that this function can be invoked from any context and in the current Hyper-V util driver, we support host-driven orderly shut down of the guest by invoking this orderly_poweroff() function in the context of the message callback. This code has been working for a very long time and it is broken now. Is my assumption that orderly_poweroff() could be invoked from the interrupt context a wrong assumption? You can't call orderly_poweroff() from interrupt context. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.7 RC1
On Tue, Oct 23, 2012 at 02:24:58PM +, KY Srinivasan wrote: -Original Message- From: Dan Carpenter [mailto:dan.carpen...@oracle.com] Sent: Tuesday, October 23, 2012 1:47 AM To: KY Srinivasan Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; jasow...@redhat.com Subject: Re: 3.7 RC1 On Mon, Oct 22, 2012 at 04:37:45PM -0700, K. Y. Srinivasan wrote: While testing 3.7 RC1 I discovered that invoking the function orderly_poweroff() from an interrupt context will trigger an ASSERT(). This was not the case till recently. The comment preceding the orderly_poweroff() function claims that this function can be invoked from any context and in the current Hyper-V util driver, we support host-driven orderly shut down of the guest by invoking this orderly_poweroff() function in the context of the message callback. This code has been working for a very long time and it is broken now. Is my assumption that orderly_poweroff() could be invoked from the interrupt context a wrong assumption? You can't call orderly_poweroff() from interrupt context. Thanks Dan; I am curious to understand the basis for your assertion. As I noted earlier the documentation for this function clearly says it can be called from any context. Furthermore, __orderly_poweroff(), the helper function allocates memory with the GFP_ATOMIC flag set. Lastly, the behavior of orderly_poweroff() has been such that this function could be called from interrupt context for a very long time and something has changed now. For what it is worth, there are other users in the kernel (in 3.7 RC1) that are invoking the orderly_poweroff() function from interrupt context other than the Hyper-V shutdown handler: fsl_hv_shutdown_isr() in drivers/virt/fsl_hypervisor.c. I suspect there are other users as well that have made this similar assumption. Aw crap. I was wrong. Sorry about that. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] ds2782_battery: signedness bug in ds278x_read_reg16()
We need to check for negative values before doing the swab16() for the
error handling to work.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/power/ds2782_battery.c b/drivers/power/ds2782_battery.c
index 6bb6e2f..2fa9b6b 100644
--- a/drivers/power/ds2782_battery.c
+++ b/drivers/power/ds2782_battery.c
@@ -80,13 +80,13 @@ static inline int ds278x_read_reg16(struct ds278x_info
*info, int reg_msb,
{
int ret;
- ret = swab16(i2c_smbus_read_word_data(info-client, reg_msb));
+ ret = i2c_smbus_read_word_data(info-client, reg_msb);
if (ret 0) {
dev_err(info-client-dev, register read failed\n);
return ret;
}
- *val = ret;
+ *val = swab16(ret);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] time: cast -raw_interval to u64 to avoid shift overflow
We fixed a bunch of integer overflows in timekeeping code during the 3.6
cycle. I did an audit based on that and found this potential overflow.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
I'm not super familiar with this code so please review my work
carefully.
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 5ce06a3..1d1ee67 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1113,7 +1113,7 @@ static cycle_t logarithmic_accumulation(struct timekeeper
*tk, cycle_t offset,
accumulate_nsecs_to_secs(tk);
/* Accumulate raw time */
- raw_nsecs = tk-raw_interval shift;
+ raw_nsecs = (u64)tk-raw_interval shift;
raw_nsecs += tk-raw_time.tv_nsec;
if (raw_nsecs = NSEC_PER_SEC) {
u64 raw_secs = raw_nsecs;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: android: binder: Fixed multi-line strings
On Tue, Oct 09, 2012 at 12:31:03AM +0530, Anmol Sarma wrote: Changed all user visible multi-line stings to single line. Signed-off-by: Anmol Sarma unmole...@gmail.com These sorts of things are really a judgement call. checkpatch.pl is being bossier than it should be. I would ignore keep the maintaier's original code. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [staging][zram] Fix handling of incompressible pages
On Mon, Oct 08, 2012 at 06:32:44PM -0700, Nitin Gupta wrote: Change 130f315a introduced a bug in the handling of incompressible When you mention a patch, please include the human readable patch title as well as the hash. staging: zram: remove special handle of uncompressed page. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at block/genhd.c:1570 disk_clear_events+0xbf/0xd0()
Fixed in: commit fdd514e16bb2531c0c61ae8a1f87740ce217f630 Author: Tejun Heo t...@kernel.org Date: Thu Jun 9 20:43:59 2011 +0200 block: make disk_block_events() properly wait for work cancellation regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Instead of IP addresses the kernel started to show zero's
Add netdev to the CC list. regards, dan carpenter On Fri, Sep 21, 2012 at 10:27:04PM +0400, Alexey Vlasov wrote: Hi. Here it writes LOG module (netfilter) in syslog: Sep 21 22:24:04 l24 kernel: ipsec:SYN-OUTPUT-HTTP IN= OUT=eth0 SRC= DST= LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=9042 DF PROTO=TCP SPT=51169 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 UID=545369 GID=155 This is recent, here go zero's again. cat /proc/net/xt_recent/j-brute src= ttl: 117 last_seen: 4349942400 oldest_pkt: 1 4349942400 src= ttl: 119 last_seen: 4349968063 oldest_pkt: 1 4349968063 Can it be fixed without restarting the box? Thanks. # uname -a Linux l24 3.4.6 ... -- BRGDS. Alexey Vlasov. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Instead of IP addresses the kernel started to show zero's
On Tue, Oct 09, 2012 at 02:50:10PM +0200, Eric Dumazet wrote: On Tue, 2012-10-09 at 15:36 +0300, Dan Carpenter wrote: Add netdev to the CC list. netdev already in the CC list by Borislav Petkov Sorry. He sent the email twice in two threads and I was still looking at the first report. :( regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'
On Tue, Oct 09, 2012 at 01:52:49PM +0200, Ohad Ben-Cohen wrote: Hi Sjur, On Tue, Oct 9, 2012 at 12:30 PM, Sjur BRENDELAND sjur.brandel...@stericsson.com wrote: Sorry for not responding sooner, but I thought this issue was solved with your patch remoteproc: fix (again) the virtio-related build breakage (https://lkml.org/lkml/2012/10/6/85). I'm not sure I understand why you would want to add a dependency to ARM. But if you're uncomfortable by having STE_MODEM_RPROC directly selectable, perhaps we could let it be selected by arch specific Kconfig files, e.g. mach-ux500? I would just like the Kconfig dependencies to reflect the real world: E.g., if there's no chance the STE modem is going to be used on x86, then let's not ask x86 folks about it. Does limiting the STE modem to certain platform/architectures make sense ? (if not, that's ok) Unless there is a good reason why then we shouldn't put arbitrary limits like that. If we leave it in people at least run static analyzers on it and try modprobing it. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e): undefined reference to `vring_transport_features'
On Tue, Oct 09, 2012 at 04:15:15PM +0200, Ohad Ben-Cohen wrote: On Tue, Oct 9, 2012 at 3:28 PM, Dan Carpenter dan.carpen...@oracle.com wrote: Unless there is a good reason why That's what I'm asking. Is there an inherent coupling with some platform/architecture ? E.g., OMAP remote processors only go with OMAP chips. If it already compiles fine on x86 then there is no advantage to disabling it. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] gpio-timberdale: fix a potential wrapping issue
-last_ier is an unsigned long but the high bits can't be used int the original code because the shift wraps. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/gpio/gpio-timberdale.c b/drivers/gpio/gpio-timberdale.c index 031c6ad..1a3e2b9 100644 --- a/drivers/gpio/gpio-timberdale.c +++ b/drivers/gpio/gpio-timberdale.c @@ -116,7 +116,7 @@ static void timbgpio_irq_disable(struct irq_data *d) unsigned long flags; spin_lock_irqsave(tgpio-lock, flags); - tgpio-last_ier = ~(1 offset); + tgpio-last_ier = ~(1UL offset); iowrite32(tgpio-last_ier, tgpio-membase + TGPIO_IER); spin_unlock_irqrestore(tgpio-lock, flags); } @@ -128,7 +128,7 @@ static void timbgpio_irq_enable(struct irq_data *d) unsigned long flags; spin_lock_irqsave(tgpio-lock, flags); - tgpio-last_ier |= 1 offset; + tgpio-last_ier |= 1UL offset; iowrite32(tgpio-last_ier, tgpio-membase + TGPIO_IER); spin_unlock_irqrestore(tgpio-lock, flags); } -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] [SCSI] bfa: unlock on error in bfad_iocmd_cfg_trunk()
We added a new return but forgot to drop the lock first.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Bug introduced in e353546e [SCSI] bfa: Add diagnostic port (D-Port)
support.
diff --git a/drivers/scsi/bfa/bfad_bsg.c b/drivers/scsi/bfa/bfad_bsg.c
index 555e7db..91465b2 100644
--- a/drivers/scsi/bfa/bfad_bsg.c
+++ b/drivers/scsi/bfa/bfad_bsg.c
@@ -2238,8 +2238,10 @@ bfad_iocmd_cfg_trunk(struct bfad_s *bfad, void *cmd,
unsigned int v_cmd)
spin_lock_irqsave(bfad-bfad_lock, flags);
- if (bfa_fcport_is_dport(bfad-bfa))
+ if (bfa_fcport_is_dport(bfad-bfa)) {
+ spin_unlock_irqrestore(bfad-bfad_lock, flags);
return BFA_STATUS_DPORT_ERR;
+ }
if ((fcport-cfg.topology == BFA_PORT_TOPOLOGY_LOOP) ||
(fcport-topology == BFA_PORT_TOPOLOGY_LOOP))
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] [SCSI] bfa: cleanup a memcpy()
Smatch complains that we are writing more data than -srlid_base
member can hold. In fact, we are over writing the whole struct. I've
re-written it to be a bit more clear and to silence the static checker
warning.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/scsi/bfa/bfa_ioc.c b/drivers/scsi/bfa/bfa_ioc.c
index 0116c10..a6dc18e 100644
--- a/drivers/scsi/bfa/bfa_ioc.c
+++ b/drivers/scsi/bfa/bfa_ioc.c
@@ -3624,11 +3624,9 @@ bfa_sfp_show_comp(struct bfa_sfp_s *sfp, struct
bfi_mbmsg_s *msg)
bfa_trc(sfp, sfp-memtype);
if (sfp-memtype == BFI_SFP_MEM_DIAGEXT) {
bfa_trc(sfp, sfp-data_valid);
- if (sfp-data_valid) {
- u32 size = sizeof(struct sfp_mem_s);
- u8 *des = (u8 *) (sfp-sfpmem-srlid_base);
- memcpy(des, sfp-dbuf_kva, size);
- }
+ if (sfp-data_valid)
+ memcpy(sfp-sfpmem, sfp-dbuf_kva,
+ sizeof(*sfp-sfpmem));
/*
* Queue completion callback.
*/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] irq: potential integer wrapping __setup_irq()
thread_mask is an unsigned long. It's better to use 1UL here so we
can take advantage of the high bits as well.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 4c69326..cfe1283 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1027,7 +1027,7 @@ __setup_irq(unsigned int irq, struct irq_desc *desc,
struct irqaction *new)
* thread_mask assigned. See the loop above which or's
* all existing action-thread_mask bits.
*/
- new-thread_mask = 1 ffz(thread_mask);
+ new-thread_mask = 1UL ffz(thread_mask);
} else if (new-handler == irq_default_primary_handler
!(desc-irq_data.chip-flags IRQCHIP_ONESHOT_SAFE)) {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] aoe: avoid using skb member after dev_queue_xmit
On Wed, Oct 24, 2012 at 03:08:07PM -0700, Andrew Morton wrote: On Wed, 24 Oct 2012 14:26:13 -0400 Ed Cashin ecas...@coraid.com wrote: After calling dev_queue_xmit it is no longer safe to access the members of the skb. Reported-by: Dan Carpenter dan.carpen...@oracle.com hm, that was clever. How did Dan detect this bug? It was a Smatch thing, but it wasn't enabled by default. I think I will enable it. This is the second bug use after dev_queue_xmit() in two years. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] gpiolib: unlock on error in gpio_export()
We need to unlock here before returning. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- Only needed in linux-next. diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index d5f9742..14251c3 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -728,7 +728,8 @@ int gpio_export(unsigned gpio, bool direction_may_change) __func__, gpio, test_bit(FLAG_REQUESTED, desc-flags), test_bit(FLAG_EXPORT, desc-flags)); - return -EPERM; + status = -EPERM; + goto fail_unlock; } if (!desc-chip-direction_input || !desc-chip-direction_output) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] mei: copy_from_user() doesn't return an error code
copy_from_user() returns the number of bytes remaining but we should be returning -EFAULT here. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- Only needed in linux-next. diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c index ed4943f..ce1014e 100644 --- a/drivers/misc/mei/main.c +++ b/drivers/misc/mei/main.c @@ -607,8 +607,8 @@ static ssize_t mei_write(struct file *file, const char __user *ubuf, dev_dbg(dev-pdev-dev, cb request size = %zd\n, length); - rets = copy_from_user(write_cb-request_buffer.data, ubuf, length); - if (rets) + rets = -EFAULT; + if (copy_from_user(write_cb-request_buffer.data, ubuf, length)) goto unlock_dev; cl-sm_state = 0; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] fbmem: return -EFAULT on copy_to_user() failure
copy_to_user() returns the number of bytes remaining to be copied. put_user() returns -EFAULT on error. This function ORs a bunch of stuff together and returns jumbled non-zero values on error. It should return -EFAULT. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c index 3ff0105..3d2a4d0 100644 --- a/drivers/video/fbmem.c +++ b/drivers/video/fbmem.c @@ -1302,8 +1302,9 @@ static int do_fscreeninfo_to_user(struct fb_fix_screeninfo *fix, err |= put_user(fix-accel, fix32-accel); err |= copy_to_user(fix32-reserved, fix-reserved, sizeof(fix-reserved)); - - return err; + if (err) + return -EFAULT; + return 0; } static int fb_get_fscreeninfo(struct fb_info *info, unsigned int cmd, -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] ALSA: es1968: precedence bug in snd_es1968_tea575x_get_pins()
I don't think this works as intended. '|' higher precedence than ?: so the bitwize OR 0 | (val STR_MOST) is a no-op. I have re-written it to be more clear. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- I don't have a way to test this. diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c index 50169bc..7266020 100644 --- a/sound/pci/es1968.c +++ b/sound/pci/es1968.c @@ -2581,9 +2581,14 @@ static u8 snd_es1968_tea575x_get_pins(struct snd_tea575x *tea) struct es1968 *chip = tea-private_data; unsigned long io = chip-io_port + GPIO_DATA; u16 val = inw(io); - - return (val STR_DATA) ? TEA575X_DATA : 0 | - (val STR_MOST) ? TEA575X_MOST : 0; + u8 ret; + + ret = 0; + if (val STR_DATA) + ret |= TEA575X_DATA; + if (val STR_MOST) + ret |= TEA575X_MOST; + return ret; } static void snd_es1968_tea575x_set_direction(struct snd_tea575x *tea, bool output) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ALSA: es1968: precedence bug in snd_es1968_tea575x_get_pins()
On Tue, Nov 13, 2012 at 12:03:10AM -0800, Joe Perches wrote: On Tue, 2012-11-13 at 10:44 +0300, Dan Carpenter wrote: I don't think this works as intended. '|' higher precedence than ?: so the bitwize OR 0 | (val STR_MOST) is a no-op. I have re-written it to be more clear. [] diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c [] @@ -2581,9 +2581,14 @@ static u8 snd_es1968_tea575x_get_pins(struct snd_tea575x *tea) struct es1968 *chip = tea-private_data; unsigned long io = chip-io_port + GPIO_DATA; u16 val = inw(io); - - return (val STR_DATA) ? TEA575X_DATA : 0 | - (val STR_MOST) ? TEA575X_MOST : 0; + u8 ret; + + ret = 0; + if (val STR_DATA) + ret |= TEA575X_DATA; + if (val STR_MOST) + ret |= TEA575X_MOST; + return ret; Cute. smatch I presume? Tools are useful. Yep. This is a smatch thing. Moving the close parentheses is a pretty common style too return (val STR_DATA ? TEA575X_DATA : 0) | (val STR_MOST ? TEA575X_MOST : 0); That would work as well, of course. I don't have a strong preference either way. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] staging/serqt_usb2: refactor qt_read_bulk_callback() in serqt_usb2.c
On Sat, Nov 10, 2012 at 06:33:56AM +0900, YAMANE Toshiaki wrote:
Modified to eliminate the deep nesting and redundant description.
Signed-off-by: YAMANE Toshiaki yamaneto...@gmail.com
---
drivers/staging/serqt_usb2/serqt_usb2.c | 147
+--
1 file changed, 80 insertions(+), 67 deletions(-)
diff --git a/drivers/staging/serqt_usb2/serqt_usb2.c
b/drivers/staging/serqt_usb2/serqt_usb2.c
index 9bc8923..0395bdf 100644
--- a/drivers/staging/serqt_usb2/serqt_usb2.c
+++ b/drivers/staging/serqt_usb2/serqt_usb2.c
@@ -291,22 +291,89 @@ static void qt_interrupt_callback(struct urb *urb)
/* FIXME */
}
+static int qt_status_change(unsigned int limit,
+ unsigned char *data,
+ int i,
+ struct quatech_port *qt_port,
+ struct usb_serial_port *port)
+{
+ void (*fn)(struct quatech_port *, unsigned char);
+
+ if (0x00 == data[i + 2]) {
+ dev_dbg(port-dev, Line status status.\n);
+ fn = ProcessLineStatus;
+ } else {
+ dev_dbg(port-dev, Modem status status.\n);
+ fn = ProcessModemStatus;
+ }
+
+ if (i limit) {
Why can't we test whether i == (RxCount - 3) earlier and handle
the errors there? That way we wouldn't need to pass the limit
variable.
In fact, this whole function is sort of nasty. We start by doing
a switch (data[i + 2]) { then we combine the 0x00 and 0x01 and call
this function which separates them out and sets a function pointer
and then calls the function point? Get rid of this whole function.
You shouldn't need to use function pointers to do this; that's too
many levels of abstraction.
+ dev_dbg(port-dev,
+ Illegal escape seuences in received data\n);
+ return 0;
+ }
+
+ (*fn)(qt_port, data[i + 3]);
+
+ return 1;
+}
+
[snip]
if (urb-status) {
qt_port-ReadBulkStopped = 1;
- dev_dbg(urb-dev-dev, %s - nonzero write bulk status
received: %d\n,
+ dev_dbg(urb-dev-dev,
+ %s - nonzero write bulk status received: %d\n,
__func__, urb-status);
Don't mix in these unrelated 80 character limit changes.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] staging: line6: wrap 80 char lines in capture.c
On Sun, Nov 11, 2012 at 01:24:39PM +0100, Stefan Hajnoczi wrote: Signed-off-by: Stefan Hajnoczi stefa...@gmail.com --- drivers/staging/line6/capture.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/staging/line6/capture.c b/drivers/staging/line6/capture.c index c85c5b6..389c41f 100644 --- a/drivers/staging/line6/capture.c +++ b/drivers/staging/line6/capture.c @@ -256,8 +256,8 @@ static void audio_in_callback(struct urb *urb) #ifdef CONFIG_LINE6_USB_IMPULSE_RESPONSE if (!(line6pcm-flags LINE6_BITS_PCM_IMPULSE)) #endif - if (test_bit(LINE6_INDEX_PCM_ALSA_CAPTURE_STREAM, line6pcm-flags) - (fsize 0)) + if (test_bit(LINE6_INDEX_PCM_ALSA_CAPTURE_STREAM, The reason this is hitting the 80 character limit is because LINE6_INDEX_PCM_ALSA_CAPTURE_STREAM is 35 characters long. It isn't even clear from the name what it holds. It's just a very crap name. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] staging: line6: replace DEBUG_MESSAGES() with dev_dbg()
On Sun, Nov 11, 2012 at 01:52:24PM +0100, Stefan Hajnoczi wrote: + dev_dbg(pod-line6.ifcdev, + wrong size of channel dump message (%d instead of %d)\n, + pod-line6.message_length, + (int)sizeof(pod-prog_data) + + 7); Better to get rid of the cast. You're already over the 80 character limit so putting the 7); on the line before is ok. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Drivers: hv: Cleanup error handling in vmbus_open()
On Fri, Oct 12, 2012 at 01:22:42PM -0700, K. Y. Srinivasan wrote: -errorout: - hv_ringbuffer_cleanup(newchannel-outbound); - hv_ringbuffer_cleanup(newchannel-inbound); +error1: + spin_lock_irqsave(vmbus_connection.channelmsg_lock, flags); + list_del(open_info-msglistentry); + spin_unlock_irqrestore(vmbus_connection.channelmsg_lock, flags); + +error0: It's better to give the labels meaningful names like error_del and error_pages instead of GW-BASIC numbers. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation DMA-API-HOWTO.txt Add dma mapping error check usage examples
On Sun, Oct 14, 2012 at 09:54:24AM -0600, Shuah Khan wrote:
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index a0b6250..cf1adb4 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -468,11 +468,46 @@ To map a single region, you do:
size_t size = buffer-len;
dma_handle = dma_map_single(dev, addr, size, direction);
+ if (unlikely(dma_mapping_error(dma_handle))) {
Don't encourage people to put unlikely() and likely() into their
driver code. It should only be used after benchmarking both with
and without. I can't imagine how it would make a measurable
difference here.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Drivers: Staging: CSR: Fixed coding style warnings
When you're writing the subject you don't need to add the Drivers: bit. That is understood. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] Drivers: Staging: CSR: Fixed indentation problems on data_tx.c
On Mon, Oct 15, 2012 at 12:16:50AM +0900, Sangho Yi wrote:
@@ -15,36 +15,37 @@
#include csr_wifi_hip_unifi.h
#include unifi_priv.h
-int
-uf_verify_m4(unifi_priv_t *priv, const unsigned char *packet, unsigned int
length)
-{
-const unsigned char *p = packet;
-u16 keyinfo;
+int uf_verify_m4 (unifi_priv_t *priv, const unsigned char *packet,
+ unsigned int length) {
The original was correct. The new code is wrong.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Staging: CSR: Fixed indentation problems on drv.c (tab mess)
On Mon, Oct 15, 2012 at 12:58:25AM +0900, Sangho Yi wrote: -module_param(use_5g, int, S_IRUGO|S_IWUSR); -module_param(led_mask,int, S_IRUGO|S_IWUSR); +module_param(use_5g, int, S_IRUGO|S_IWUSR); +module_param(led_mask, int, S_IRUGO|S_IWUSR); These things sort of lined up in the original code almost but now they are done in a random way. Why??? regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Staging: CSR: Fixed 41% of exceeding 80 characters problems on drv.c
On Mon, Oct 15, 2012 at 12:58:26AM +0900, Sangho Yi wrote: -int buswidth = 0; /* 0 means use default, values 1,4 */ -int sdio_clock = 5; /* kHz */ +int buswidth = 0;/* 0 means use default, values 1,4 */ +int sdio_clock = 5; /* kHz */ These are nonsense indenting. :( regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/14] staging: csr: fixed indentation from spaces to tabs on io.c
On Tue, Oct 16, 2012 at 02:24:20AM +0900, Sangho Yi wrote: static int uf_read_proc(char *page, char **start, off_t offset, int count, -int *eof, void *data); + int *eof, void *data); The original was correct. The new one is wrong. I'm not reviewing any more of this patchset. Sorry. Please redo everything. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: android: ashmem: Replaces printk with pr_err and pr_info
On Sat, Jul 14, 2012 at 08:28:34AM -0400, Austin Robinson wrote:
In several instances in ashmem.c, printk(KERN_INFO... and printk{KERN_ERR...
were being
used. This replaces those with the preferred pr_err and pr_info, which removes
style-related warnings.
Someone already did this. You should be working against linux-next.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch -next] ext4: locking issue on error path
We recently changed how the locking worked here, but this error path was
missed.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 8c84070..2728fb7 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3031,8 +3031,10 @@ static ssize_t ext4_ext_direct_IO(int rw, struct kiocb
*iocb,
if (!is_sync_kiocb(iocb)) {
ext4_io_end_t *io_end =
ext4_init_io_end(inode, GFP_NOFS);
- if (!io_end)
- return -ENOMEM;
+ if (!io_end) {
+ ret = -ENOMEM;
+ goto retake_lock;
+ }
io_end-flag |= EXT4_IO_END_DIRECT;
iocb-private = io_end;
/*
@@ -3094,6 +3096,7 @@ static ssize_t ext4_ext_direct_IO(int rw, struct kiocb
*iocb,
ext4_clear_inode_state(inode, EXT4_STATE_DIO_UNWRITTEN);
}
+retake_lock:
/* take i_mutex locking again if we do a ovewrite dio */
if (overwrite) {
up_read(EXT4_I(inode)-i_data_sem);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
potential NULL dereference in futex_wait_requeue_pi()
Hi Darren,
The patch 52400ba94675: futex: add requeue_pi functionality from
Apr 3, 2009, leads to the following warning:
kernel/futex.c:2373 futex_wait_requeue_pi()
error: potential NULL dereference 'pi_mutex'.
2330 if (!q.rt_waiter) {
2331 /*
2332 * Got the lock. We might not be the anticipated owner
if we
2333 * did a lock-steal - fix up the PI-state in that case.
2334 */
2335 if (q.pi_state (q.pi_state-owner != current)) {
2336 spin_lock(q.lock_ptr);
2337 ret = fixup_pi_state_owner(uaddr2, q, current);
pi_mutex is NULL here and it looks like fixup_pi_state_owner() can
return -EFAULT.
2338 spin_unlock(q.lock_ptr);
2339 }
2340 } else {
[snipped]
2366 }
2367
2368 /*
2369 * If fixup_pi_state_owner() faulted and was unable to handle
the
2370 * fault, unlock the rt_mutex and return the fault to userspace.
2371 */
2372 if (ret == -EFAULT) {
2373 if (rt_mutex_owner(pi_mutex) == current)
This will oops if pi_mutex is NULL.
2374 rt_mutex_unlock(pi_mutex);
2375 } else if (ret == -EINTR) {
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: potential NULL dereference in futex_wait_requeue_pi()
On Wed, Jul 18, 2012 at 08:41:38AM -0700, Darren Hart wrote: On 07/18/2012 08:31 AM, Dave Jones wrote: On Wed, Jul 18, 2012 at 05:25:14PM +0300, Dan Carpenter wrote: Hi Darren, The patch 52400ba94675: futex: add requeue_pi functionality from Apr 3, 2009, leads to the following warning: kernel/futex.c:2373 futex_wait_requeue_pi() error: potential NULL dereference 'pi_mutex'. This sounds like the oops I saw that I reported at https://lkml.org/lkml/2012/7/13/328 I'm looking into the report Dave sent today (delayed from piles of urgent issues after returning from vacation, my apologies). Dan, under which workload are you seeing this? This was a static checker warning. It was Dave who saw the oops from syscall fuzzing with trinity. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sep_main.c: remove duplicated include
The subject here should have been: [PATCH] Staging: sep: remove duplicated include You can find the right subject prefix to use by typing: git log --oneline filename.c Also it would have been ok to combine both the sep changes together. It's just one change even though it's split across two files. The vme change is separate because it's in a different module. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] ntfs: remove an unneeded NULL check
The ctx variable can never be NULL here and also we dereference it on the previous line. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/fs/ntfs/file.c b/fs/ntfs/file.c index 7389d2d..4db19f7 100644 --- a/fs/ntfs/file.c +++ b/fs/ntfs/file.c @@ -309,8 +309,7 @@ do_non_resident_extend: done: flush_dcache_mft_record_page(ctx-ntfs_ino); mark_mft_record_dirty(ctx-ntfs_ino); - if (ctx) - ntfs_attr_put_search_ctx(ctx); + ntfs_attr_put_search_ctx(ctx); if (m) unmap_mft_record(base_ni); ntfs_debug(Done, initialized_size 0x%llx, i_size 0x%llx., -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging/sbe-2t3e3: error path cleanup in t3e3_init_channel
Cleanup means there are no behavior changes. This is a bug fix. On Thu, Jul 19, 2012 at 06:00:01PM +0530, Devendra Naga wrote: a) if alloc_hdlcdev fails, we are going into the free_regions, and returning out the err (which is 0 by the prev call), return -ENOMEM if this function fail. b) setup_device also can fail, as it calls around the register_hdlc_dev which is again a macro of the register_netdev. take the error from the setup_device and return it out in error condition c) request_irq when fails, we are freeing requested mem regions and disabling the pci device(?) and returning err which is agian 0 here. take the error from request_irq and err path will take care of returning it. as if we return 0 , at the init function, t3e3_init_card, we have a success case and if there are two channels we call this function again, having the result of it completely unknown. This result in having the probe return 0, unloading the driver may (not) cause ambigous result. These bugs were there before your patch, but we should also be doing an unregister_hdlc_device() and a free_netdev(). regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: pstore/ram: Add ftrace messages handling
Hello Anton Vorontsov,
This is a semi-automatic email about new static checker warnings.
The patch a694d1b5916a: pstore/ram: Add ftrace messages handling
from Jul 9, 2012, leads to the following Smatch complaint:
fs/pstore/ram.c:423 ramoops_probe()
error: we previously assumed 'cxt-cprz' could be null (see line 408)
fs/pstore/ram.c
407
408 if (!cxt-przs !cxt-cprz !cxt-fprz) {
^^
Checked here.
409 pr_err(memory size too small, minimum is %lu\n,
410 cxt-console_size + cxt-record_size +
411 cxt-ftrace_size);
412 goto fail_cnt;
413 }
414
415 cxt-pstore.data = cxt;
416 /*
417 * Console can handle any buffer size, so prefer dumps buffer
418 * size since usually it is smaller.
419 */
420 if (cxt-przs)
421 cxt-pstore.bufsize = cxt-przs[0]-buffer_size;
422 else
423 cxt-pstore.bufsize = cxt-cprz-buffer_size;
^
Dereferenced here. What about if only cxt-fprz is non-NULL?
Also these are crap variable names, przs and cprz look so similar.
It makes my head hurt to keep them appart.
424 cxt-pstore.buf = kmalloc(cxt-pstore.bufsize, GFP_KERNEL);
425 spin_lock_init(cxt-pstore.buf_lock);
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/90] staging: comedi: comedidev.h: introduce comedi_to_pci_dev() helper
On Thu, Jul 19, 2012 at 11:20:52AM -0500, H Hartley Sweeten wrote:
On Thursday, July 19, 2012 2:23 AM, Ian Abbott wrote:
On 2012-07-19 02:24, H Hartley Sweeten wrote:
Introduce a wrapper for to_pci_dev() to allow the comedi pci drivers
to store the pci_dev pointer in the comedi_device hw_dev variable and
retrieve it easily.
Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Cc: Ian Abbott abbo...@mev.co.uk
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/staging/comedi/comedidev.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/comedi/comedidev.h
b/drivers/staging/comedi/comedidev.h
index de8c99c..620222d 100644
--- a/drivers/staging/comedi/comedidev.h
+++ b/drivers/staging/comedi/comedidev.h
@@ -446,6 +446,11 @@ static inline void comedi_set_hw_dev(struct
comedi_device *dev,
}
}
+static inline struct pci_dev *comedi_to_pci_dev(struct comedi_device *dev)
+{
+ return to_pci_dev(dev-hw_dev);
+}
+
That needs to be something like:
return dev-hw_dev ? to_pci_dev(dev-hw_dev) : NULL;
Hmm.. I'm not really sure.
I assumed that the container_of() macro would return NULL if the ptr passed to
it was NULL. But, I'm not sure how this actually unwinds for that case.
Greg, do you know if the NULL check is needed? It's is possible that the
dev-hw_dev
pointer could be NULL.
container_of() just does pointer math with the offset. Since
-hw_dev is not the first member of the pci_dev struct then
to_pci_dev() never returns NULL. If you give it a NULL pointer it
returns a bogus pointer back.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [QUESTION ON BUG] the rcu stall issue could not be reproduced
My bug was fixed in March. There was an email thread about it when the merge window opened but I can't find it... regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pstore/ram: Add ftrace messages handling
On Thu, Jul 19, 2012 at 04:20:32PM -0700, Anton Vorontsov wrote: Hi Dan, On Thu, Jul 19, 2012 at 05:28:56PM +0300, Dan Carpenter wrote: The patch a694d1b5916a: pstore/ram: Add ftrace messages handling from Jul 9, 2012, leads to the following Smatch complaint: A nice tool. The homepage of Smatch doesn't explicitly say that, so I have to ask: is it a complete superset of sparse (i.e. does it produce all the warnings that the pure sparse can produce)? If so, I'll probably switch to it from the vanilla sparse. No. It just uses Sparse as a parser. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] driver-core: dev_to_node() should handle NULL pointers
What prompted this patch is that in dma_pool_create() we call
dev_to_node() before checking whether dev is NULL. It looks like
there are places which call dma_pool_create() with a NULL pointer. An
example is in drivers/usb/gadget/amd5536udc.c.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Static checker fix.
diff --git a/include/linux/device.h b/include/linux/device.h
index aa7b3b4..c80e7a8d 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -714,7 +714,9 @@ int dev_set_name(struct device *dev, const char *name, ...);
#ifdef CONFIG_NUMA
static inline int dev_to_node(struct device *dev)
{
- return dev-numa_node;
+ if (dev)
+ return dev-numa_node;
+ return -1;
}
static inline void set_dev_node(struct device *dev, int node)
{
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] tty: handle NULL parameters in free_tty_struct()
We sometimes pass NULL pointers to free_tty_struct(). One example where
it can happen is in the error handling code in pty_common_install().
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index ca7c25d..e49b839 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -181,6 +181,8 @@ struct tty_struct *alloc_tty_struct(void)
void free_tty_struct(struct tty_struct *tty)
{
+ if (!tty)
+ return;
if (tty-dev)
put_device(tty-dev);
kfree(tty-write_buf);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [QUESTION ON BUG] the rcu stall issue could not be reproduced
On Fri, Jul 20, 2012 at 04:24:25PM +0800, Michael Wang wrote: On 07/20/2012 02:41 PM, Dan Carpenter wrote: My bug was fixed in March. There was an email thread about it when the merge window opened but I can't find it... Hi, Dan Thanks for your reply. Currently this issue won't appear because the CONFIG_RCU_CPU_STALL_TIMEOUT=60, which is big enough to avoid the warning info. So is this the fix you mentioned? or someone has find out the true reason and fixed it? I don't think there was an email thread on the RCU stall issue after all. I'm not sure what how it was fixed. The 60 second time out would have still triggered with my bug. It was a complete system hang, the RCU stall message was just a debugging hint. I was hitting the bug every couple days reliably on all my systems. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] mwave: info leak in mwave_ioctl()
Smatch complains that on 64 bit systems, there is a hole in the MW_ABILITIES struct between -component_count and -component_list[]. It leaks stack information from the mwave_ioctl() function. I've added a memset() to initialize the struct to zero. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/char/mwave/tp3780i.c b/drivers/char/mwave/tp3780i.c index c689697..04e6d6a 100644 --- a/drivers/char/mwave/tp3780i.c +++ b/drivers/char/mwave/tp3780i.c @@ -479,6 +479,7 @@ int tp3780I_QueryAbilities(THINKPAD_BD_DATA * pBDData, MW_ABILITIES * pAbilities PRINTK_2(TRACE_TP3780I, tp3780i::tp3780I_QueryAbilities entry pBDData %p\n, pBDData); + memset(pAbilities, 0, sizeof(*pAbilities)); /* fill out standard constant fields */ pAbilities-instr_per_sec = pBDData-rDspSettings.uIps; pAbilities-data_size = pBDData-rDspSettings.uDStoreSize; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lowmemorykiller: prevent multiple instances of low memory killer
On Mon, Apr 15, 2013 at 03:03:29PM +0200, Oskar Andero wrote:
From: Snild Dolkow snild.dol...@sonymobile.com
Running multiple instances of LMK is not useful since it will try to
kill the same process.
This patch adds a spinlock to prevent multiple instances of the LMK
running at the same time. Uses spin_trylock and return on failure to
avoid blocking.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Brian Swetland swetl...@google.com
Reviewed-by: Radovan Lekanovic radovan.lekano...@sonymobile.com
Signed-off-by: Snild Dolkow snild.dol...@sonymobile.com
Signed-off-by: Oskar Andero oskar.and...@sonymobile.com
---
drivers/staging/android/lowmemorykiller.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/staging/android/lowmemorykiller.c
b/drivers/staging/android/lowmemorykiller.c
index 3b91b0f..0b19353 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -38,6 +38,7 @@
#include linux/rcupdate.h
#include linux/profile.h
#include linux/notifier.h
+#include linux/spinlock.h
static uint32_t lowmem_debug_level = 2;
static short lowmem_adj[6] = {
@@ -57,6 +58,8 @@ static int lowmem_minfree_size = 4;
static unsigned long lowmem_deathpending_timeout;
+#define LMK_BUSY (-1)
Where is lowmem_shrink called from? I only see shrink called from
the bcache sysfs handler __bch_cache_set(). The return value isn't
checked there.
Up to now this function has only returns positive numbers.
There isn't a place which check LMK_BUSY so maybe it's best to just
return zero?
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lowmemorykiller: prevent multiple instances of low memory killer
On Mon, Apr 15, 2013 at 03:38:08PM +0200, Dolkow, Snild wrote: Where is lowmem_shrink called from? I only see shrink called from the bcache sysfs handler __bch_cache_set(). The return value isn't checked there. Up to now this function has only returns positive numbers. There isn't a place which check LMK_BUSY so maybe it's best to just return zero? Hey Dan, lowmem_shrink is assigned to a shrinker struct (include/linux/shrinker.h) and called in do_shrinker_shrink() in mm/vmscan.c. That, in turn, is called and checked in a few places in vmscan.c. From the comments in shrinker.h: It should return the number of objects which remain in the cache. If it returns -1, it means it cannot do any scanning at this time (eg. there is a risk of deadlock). The callback must not return -1 if nr_to_scan is zero. Ah. Good. -1 is the right return. But really should be a #define in shrinker.h instead of in drivers/staging/android/. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lowmemorykiller: prevent multiple instances of low memory killer
On Mon, Apr 15, 2013 at 04:11:18PM -0700, David Rientjes wrote:
On Mon, 15 Apr 2013, Greg Kroah-Hartman wrote:
The positive numbers are used to return information on the remaining
cache size (again, see the comment I pasted above). We could use
-EBUSY, but we'd have to change vmscan.c, which checks specifically
for -1. I can't see a technical reason why -EBUSY couldn't have been
chosen instead, but there's also no real reason to change it now.
If it's not the correct thing to do, sure we can change it, just send a
patch. It makes way more sense than some random -1 return value to me.
Care to send a series of patches fixing this up properly?
The comment in shrinker.h is misleading, not the source code.
do_shrinker_shrink() will fail for anything negative and 0.
The comment is correct. The only acceptable negative return is -1.
Look at the second time do_shrinker_shrink() is called from
shrink_slab().
283 while (total_scan = batch_size) {
284 int nr_before;
285
286 nr_before = do_shrinker_shrink(shrinker,
shrink, 0);
287 shrink_ret = do_shrinker_shrink(shrinker,
shrink,
288 batch_size);
289 if (shrink_ret == -1)
290 break;
291 if (shrink_ret nr_before)
292 ret += nr_before - shrink_ret;
293 count_vm_events(SLABS_SCANNED, batch_size);
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/12] radio-si476x: Fix incorrect pointer checking
On Thu, Apr 18, 2013 at 09:58:38AM -0700, Andrey Smirnov wrote: Fix incorrect pointer checking and make some minor code improvements: * Remove unnecessary elements from function pointer table(vtable), that includes all the elements that are FM-only, this allows for not checking of the fucntion pointer and calling of the function directly(THe check if the tuner is in FM mode has to be done anyway) * Fix incorrect function pointer checking where the code would check one pointer to be non-NULL, but would use other pointer, which would not be checked. * Remove code duplication in si476x_radio_read_rsq_blob and si476x_radio_read_rsq_primary_blob. * Add some BUG_ON statements for function pointers that should never be NULL Signed-off-by: Andrey Smirnov andrew.smir...@gmail.com Signed-off-by: Dan Carpenter dan.carpen...@oracle.com This should be a Reported-by for me, probably. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd:rtsx: Support RTL8411B
On Fri, Apr 19, 2013 at 09:52:42PM +0800, rogera...@realtek.com wrote: From: Roger Tseng rogera...@realtek.com Adding support of model RTL8411B. Since the model is similar to RTL8411, differences are implemented in rtl8411.c. What tree is this against? regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] gru: info leak in gru_get_config_info()
The info.fill array isn't initialized so it can leak uninitialized stack information to user space. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/misc/sgi-gru/grufile.c b/drivers/misc/sgi-gru/grufile.c index 44d273c..ed5fc43 100644 --- a/drivers/misc/sgi-gru/grufile.c +++ b/drivers/misc/sgi-gru/grufile.c @@ -176,6 +176,7 @@ static long gru_get_config_info(unsigned long arg) info.nodes = num_online_nodes(); info.blades = info.nodes / nodesperblade; info.chiplets = GRU_CHIPLETS_PER_BLADE * info.blades; + memset(info.fill, 0, sizeof(info.fill)); if (copy_to_user((void __user *)arg, info, sizeof(info))) return -EFAULT; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch v2] gru: info leak in gru_get_config_info()
The info.fill array isn't initialized so it can leak uninitialized stack information to user space. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- v2: style changes diff --git a/drivers/misc/sgi-gru/grufile.c b/drivers/misc/sgi-gru/grufile.c index 44d273c..0535d1e 100644 --- a/drivers/misc/sgi-gru/grufile.c +++ b/drivers/misc/sgi-gru/grufile.c @@ -172,6 +172,7 @@ static long gru_get_config_info(unsigned long arg) nodesperblade = 2; else nodesperblade = 1; + memset(info, 0, sizeof(info)); info.cpus = num_online_cpus(); info.nodes = num_online_nodes(); info.blades = info.nodes / nodesperblade; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: omap-thermal: remove trailing whitespace from omap-bandgap.c
On Mon, Apr 08, 2013 at 02:27:13PM -0400, Eduardo Valentin wrote: Thanks, please keep sending your patches and copy my email address so I will give you a quick response. Please, send a patch adding yourself to the MAINTAINERS file so the get_maintainer.pl script does the right thing automatically. After that you will be an official kernel maintainer with all the honor and dignity that goes along with it. :) regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] tty: mxser: forever loops on error
There were a couple signedness bugs decrementing i which would lead to
a forever loops.
I've made a couple other variables signed as well because they are all
related array offsets and it would be weird if they weren't the same
type.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index d996038..a095859 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -2556,9 +2556,9 @@ static int mxser_probe(struct pci_dev *pdev,
{
#ifdef CONFIG_PCI
struct mxser_board *brd;
- unsigned int i, j;
unsigned long ioaddress;
struct device *tty_dev;
+ int i, j;
int retval = -EINVAL;
for (i = 0; i MXSER_BOARDS; i++)
@@ -2700,7 +2700,7 @@ static int __init mxser_module_init(void)
{
struct mxser_board *brd;
struct device *tty_dev;
- unsigned int b, i, m;
+ int b, i, m;
int retval;
mxvar_sdriver = alloc_tty_driver(MXSER_PORTS + 1);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] tty: mxser: forever loops on error
On Tue, Apr 09, 2013 at 09:50:35AM +0400, Alexey Khoroshilov wrote: Hi Dan, Thank you for the patch. We are also trying to fix the issue: https://lkml.org/lkml/2013/2/19/29 https://lkml.org/lkml/2013/4/8/55 and the fix is finally in Greg's tty git tree since yesterday: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git (tty-linus branch). Good deal. Btw, by the time that Fenguang's kbuild scripts emailed you, it was already too late to send a v2 patch. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2 -next] dma-buf: double unlock in debugfs code
We unlock here when we failed to take the lock.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
This is in linux-next, and I think the debugfs code is only in Sumit's
tree.
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 466476f..174cd2c 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -593,7 +593,7 @@ static int dma_buf_describe(struct seq_file *s)
if (ret) {
seq_printf(s,
\tERROR locking buffer object: skipping\n);
- goto skip_buffer;
+ continue;
}
seq_printf(s, \t);
@@ -618,7 +618,6 @@ static int dma_buf_describe(struct seq_file *s)
count++;
size += buf_obj-size;
-skip_buffer:
mutex_unlock(buf_obj-lock);
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild] [patch 1/2 -next] dma-buf: double unlock in debugfs code
Oops... I mailed that prematurely. There isn't a [patch 2/2]. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: Warn on comparisons to true and false
On Wed, Apr 10, 2013 at 10:14:15PM -0400, Dave Jones wrote: On Wed, Apr 10, 2013 at 03:57:51PM -0700, Andrew Morton wrote: On Tue, 09 Apr 2013 20:17:14 -0700 Joe Perches j...@perches.com wrote: Comparisons of A to true and false are better written as A and !A. Bleat a message on use. hm. I'm counting around 1,100 instances of == true and == false. That's a lot of people to shout at. Is it really worthwhile? foo==true is a bit of a waste of space but I can't say that I find it terribly offensive. It would be interesting to see how many people have historically screwed up and used (!a) when they mean (a) and vice versa, versus spelling it out longform. I'd be surprised if the results weren't skewed in favour of the more verbose form. I see a the occasional reversed test in Smatch but normally these kind of bugs are detected with basic testing so they are rare. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2 -next] dma-buf: double unlock in debugfs code
On Fri, Apr 12, 2013 at 08:43:05AM +0530, Sumit Semwal wrote: Hi Dan, On Apr 11, 2013 11:54 AM, Dan Carpenter dan.carpen...@oracle.com wrote: We unlock here when we failed to take the lock. Thanks for catching this; I will add it to the for-next queue. Could I merge this change with the main patch while submitting to mainline? With an attribution to you, of course. Yeah. Just merge it. Don't stress about attribution. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] agp: info leak in agpioc_info_wrap()
On 64 bit systems the agp_info struct has a hole between -agp_mode and -aper_base. We need to clear it to avoid leaking stack information to userspace. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/char/agp/frontend.c b/drivers/char/agp/frontend.c index 2e04433..3fbce33 100644 --- a/drivers/char/agp/frontend.c +++ b/drivers/char/agp/frontend.c @@ -729,6 +729,7 @@ static int agpioc_info_wrap(struct agp_file_private *priv, void __user *arg) agp_copy_info(agp_bridge, kerninfo); + memset(userinfo, 0, sizeof(userinfo)); userinfo.version.major = kerninfo.version.major; userinfo.version.minor = kerninfo.version.minor; userinfo.bridge_id = kerninfo.device-vendor | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8192u: fix coding style
On Wed, Mar 27, 2013 at 08:20:11PM +0900, Haksu Jeong wrote: Fix coding style of r8192U_dm.h This patch is white space damaged and doesn't apply. Save the raw patch as text (including headers and everything). cat my_patch.txt | git am Fails. Probably it's better to split this up and send it as several patches. [patch 1/3] Staging: rtl8192u: r8192U_dm.h: use c99 comments [patch 2/3] Staging: rtl8192u: r8192U_dm.h: use proper white space [patch 3/3] Staging: rtl8192u: r8192U_dm.h: reposition the braces regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: comedi: Fixed camel case style issue in usbdux.c
On Wed, Mar 13, 2013 at 12:19:20PM -0400, Jacob Garber wrote:
This is a patch to usbdux.c that fixes the camel case warnings found
by the checkpatch.pl tool
Signed-off-by: Jacob Garber ajtgar...@gmail.com
---
-static int usbduxsub_submit_InURBs(struct usbduxsub *usbduxsub)
+static int usbduxsub_submit_inurbs(struct usbduxsub *usbduxsub)
{
- int i, errFlag;
+ int i, err_flag;
This is really just a regular error code, not a flag. But that was
there in the original so no worries.
Looks good.
Reviewed-by: Dan Carpenter dan.carpen...@oracle.com
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
