* Re: [PATCH] arm: prevent inlining in arxescsi.c causing build failures
From: Sergei Shtylyov @ 2011-12-01 10:46 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Paul Gortmaker, linux-kernel, linux-arm-kernel, JBottomley,
linux-scsi
In-Reply-To: <20111201080613.GF26618@pengutronix.de>
Hello.
On 01.12.2011 12:06, Uwe Kleine-König wrote:
>> The following failure is seen in routine coverage builds:
>> CC [M] drivers/scsi/arm/arxescsi.o
>> /tmp/cccEyiO7.s: Assembler messages:
>> /tmp/cccEyiO7.s:334: Error: symbol `.loop_1' is already defined
>> /tmp/cccEyiO7.s:337: Error: symbol `.loop_2' is already defined
>> /tmp/cccEyiO7.s:343: Error: symbol `.loop_3' is already defined
>> /tmp/cccEyiO7.s:365: Error: symbol `.loop_1' is already defined
>> /tmp/cccEyiO7.s:368: Error: symbol `.loop_2' is already defined
>> /tmp/cccEyiO7.s:374: Error: symbol `.loop_3' is already defined
>> make[4]: *** [drivers/scsi/arm/arxescsi.o] Error 1
>> It is caused by multiple inline of arxescsi_pseudo_dma_write()
>> which is responsible for the above labels. Marking the fcn
>> as non-inline fixes the issue.
>> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
> Is that a compiler or a code issue? If it's the compiler please fix
> that. If it's the code, then please document why you added the noinline.
> Having said that, "my" compiler compiles drivers/scsi/arm/arxescsi.o
> just fine (using rpc_defconfig on v3.2-rc2).
>> diff --git a/drivers/scsi/arm/arxescsi.c b/drivers/scsi/arm/arxescsi.c
>> index a750aa7..2608a9e 100644
>> --- a/drivers/scsi/arm/arxescsi.c
>> +++ b/drivers/scsi/arm/arxescsi.c
>> @@ -72,7 +72,8 @@ arxescsi_dma_setup(struct Scsi_Host *host, struct scsi_pointer *SCp,
>> return fasdma_pseudo;
>> }
>>
>> -static void arxescsi_pseudo_dma_write(unsigned char *addr, void __iomem *base)
>> +static noinline void
>> +arxescsi_pseudo_dma_write(unsigned char *addr, void __iomem *base)
> Shouldn't this line get some indention?
No, usually such lines don't get indented.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] arm: prevent inlining in arxescsi.c causing build failures
From: Sergei Shtylyov @ 2011-12-01 10:46 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Paul Gortmaker, linux-kernel, linux-arm-kernel, JBottomley,
linux-scsi
In-Reply-To: <20111201080613.GF26618@pengutronix.de>
Hello.
On 01.12.2011 12:06, Uwe Kleine-König wrote:
>> The following failure is seen in routine coverage builds:
>> CC [M] drivers/scsi/arm/arxescsi.o
>> /tmp/cccEyiO7.s: Assembler messages:
>> /tmp/cccEyiO7.s:334: Error: symbol `.loop_1' is already defined
>> /tmp/cccEyiO7.s:337: Error: symbol `.loop_2' is already defined
>> /tmp/cccEyiO7.s:343: Error: symbol `.loop_3' is already defined
>> /tmp/cccEyiO7.s:365: Error: symbol `.loop_1' is already defined
>> /tmp/cccEyiO7.s:368: Error: symbol `.loop_2' is already defined
>> /tmp/cccEyiO7.s:374: Error: symbol `.loop_3' is already defined
>> make[4]: *** [drivers/scsi/arm/arxescsi.o] Error 1
>> It is caused by multiple inline of arxescsi_pseudo_dma_write()
>> which is responsible for the above labels. Marking the fcn
>> as non-inline fixes the issue.
>> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
> Is that a compiler or a code issue? If it's the compiler please fix
> that. If it's the code, then please document why you added the noinline.
> Having said that, "my" compiler compiles drivers/scsi/arm/arxescsi.o
> just fine (using rpc_defconfig on v3.2-rc2).
>> diff --git a/drivers/scsi/arm/arxescsi.c b/drivers/scsi/arm/arxescsi.c
>> index a750aa7..2608a9e 100644
>> --- a/drivers/scsi/arm/arxescsi.c
>> +++ b/drivers/scsi/arm/arxescsi.c
>> @@ -72,7 +72,8 @@ arxescsi_dma_setup(struct Scsi_Host *host, struct scsi_pointer *SCp,
>> return fasdma_pseudo;
>> }
>>
>> -static void arxescsi_pseudo_dma_write(unsigned char *addr, void __iomem *base)
>> +static noinline void
>> +arxescsi_pseudo_dma_write(unsigned char *addr, void __iomem *base)
> Shouldn't this line get some indention?
No, usually such lines don't get indented.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: OE-core based java layer?
From: Paul Eggleton @ 2011-12-01 10:40 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <4ED73FF4.1020406@dresearch-fe.de>
On Thursday 01 December 2011 09:51:00 Steffen Sledz wrote:
> On 30.11.2011 20:40, Otavio Salvador wrote:
> > https://github.com/woglinde/meta-java
>
> In my opinion ths should be added to
> <http://www.openembedded.org/wiki/LayerIndex>.
Done :)
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: Compile error with Ubuntu 11.10
From: Ian Campbell @ 2011-12-01 10:47 UTC (permalink / raw)
To: Adda Rathbone; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <CANrAofX3ARD8CN8HtoBnetfMZvBUS5RSC89ExuGoVSzqmE2V9A@mail.gmail.com>
On Wed, 2011-11-30 at 21:19 +0000, Adda Rathbone wrote:
> Hi,
> compilation of xen-unstable with a fresh Ubuntu 11.10 x86_64 fails
> with following error:
>
> cc1: warnings being treated as errors
> libxl_create.c: In function ‘store_libxl_entry’:
> libxl_create.c:465: error: format not a string literal and no format
> arguments
Looks like Ubuntu has enabled -Wformat-nonliteral by default
I expect that this needs to change to be
return libxl__xs_write(gc, XBT_NULL, path, "%s", libxl__strdup(gc,
libxl_device_model_version_to_string(dm_info->device_model_version)));
(note the additional "%s",)
Can you try that?
The other alternative would be to add -Wnoformat-nonliteral I guess.
It's also not obvious what the strdup is for there.
Ian.
>
> Steps to reproduce:
>
> - Install Ubuntu 11.10
> (http://www.ubuntu.com/start-download?distro=desktop&bits=64&release=latest)
> - sudo apt-get install mercurial libsdl-dev pciutils-dev ncurses-dev
> uuid-dev gettext libyajl-dev flex zlib1g-dev libssl-dev xorg-dev bcc
> bin86 iasl libc6-dev-i386 patch git
> - hg clone http://xenbits.xensource.com/xen-unstable.hg
> - cd xen-unstable.hg/tools
> - make
>
> Adda
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH][oe-core 1/2] gst-plugins-good: bump PR for gdbm SOVERSION change
From: Richard Purdie @ 2011-12-01 10:40 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1322722819-2808-1-git-send-email-Martin.Jansa@gmail.com>
On Thu, 2011-12-01 at 08:00 +0100, Martin Jansa wrote:
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
> .../gstreamer/gst-plugins-good_0.10.30.bb | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Merged to master (along with 2/2), thanks.
Richard
^ permalink raw reply
* [PATCH] arm: prevent inlining in arxescsi.c causing build failures
From: Sergei Shtylyov @ 2011-12-01 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111201080613.GF26618@pengutronix.de>
Hello.
On 01.12.2011 12:06, Uwe Kleine-K?nig wrote:
>> The following failure is seen in routine coverage builds:
>> CC [M] drivers/scsi/arm/arxescsi.o
>> /tmp/cccEyiO7.s: Assembler messages:
>> /tmp/cccEyiO7.s:334: Error: symbol `.loop_1' is already defined
>> /tmp/cccEyiO7.s:337: Error: symbol `.loop_2' is already defined
>> /tmp/cccEyiO7.s:343: Error: symbol `.loop_3' is already defined
>> /tmp/cccEyiO7.s:365: Error: symbol `.loop_1' is already defined
>> /tmp/cccEyiO7.s:368: Error: symbol `.loop_2' is already defined
>> /tmp/cccEyiO7.s:374: Error: symbol `.loop_3' is already defined
>> make[4]: *** [drivers/scsi/arm/arxescsi.o] Error 1
>> It is caused by multiple inline of arxescsi_pseudo_dma_write()
>> which is responsible for the above labels. Marking the fcn
>> as non-inline fixes the issue.
>> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
> Is that a compiler or a code issue? If it's the compiler please fix
> that. If it's the code, then please document why you added the noinline.
> Having said that, "my" compiler compiles drivers/scsi/arm/arxescsi.o
> just fine (using rpc_defconfig on v3.2-rc2).
>> diff --git a/drivers/scsi/arm/arxescsi.c b/drivers/scsi/arm/arxescsi.c
>> index a750aa7..2608a9e 100644
>> --- a/drivers/scsi/arm/arxescsi.c
>> +++ b/drivers/scsi/arm/arxescsi.c
>> @@ -72,7 +72,8 @@ arxescsi_dma_setup(struct Scsi_Host *host, struct scsi_pointer *SCp,
>> return fasdma_pseudo;
>> }
>>
>> -static void arxescsi_pseudo_dma_write(unsigned char *addr, void __iomem *base)
>> +static noinline void
>> +arxescsi_pseudo_dma_write(unsigned char *addr, void __iomem *base)
> Shouldn't this line get some indention?
No, usually such lines don't get indented.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 0/3] A few more updates
From: Richard Purdie @ 2011-12-01 10:39 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: openembedded-core
In-Reply-To: <cover.1322716218.git.sgw@linux.intel.com>
On Wed, 2011-11-30 at 21:12 -0800, Saul Wold wrote:
> Richard,
>
> This address the missing checksums and patches from my
> last set. Also added here is libffi.
>
> iconv will come later, there was a different problem that I need
> to track down.
>
> Sau!
>
>
> The following changes since commit f4efaa0f472b4bf0ba0a0297cc9ecc8b5a671f72:
>
> squashfs-tools: fix PR, those should start with 'r' (2011-11-30 23:37:40 +0000)
>
> are available in the git repository at:
> git://git.openembedded.org/openembedded-core-contrib sgw/updates
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/updates
>
> Saul Wold (3):
> xserver-xorg*: Update to 1.11.2
> gnutls: Update to 2.12.14
> libffi: Update to 3.0.10
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: [PATCH] kvm tools: Process virito blk requests in separate thread
From: Pekka Enberg @ 2011-12-01 10:45 UTC (permalink / raw)
To: Sasha Levin; +Cc: Asias He, Cyrill Gorcunov, Ingo Molnar, kvm
In-Reply-To: <1322729917.3702.10.camel@lappy>
On Thu, Dec 1, 2011 at 10:58 AM, Sasha Levin <levinsasha928@gmail.com> wrote:
> I was looking into the concept of adding 'dedicated' threads to the
> threadpool, since when the threadpool was added originally one of the
> purposes was to have all worker threads in a single place.
>
> This way we could still have threads in one place, which would make it
> easier to control all of them but still won't hurt performance of those
> threads.
>
> We can merge this patch, and I'll do the dedicated thread patch on top
> of it.
Nah. Lets add the new API and change this patch to use it instead.
^ permalink raw reply
* Re: [BUG?]3.0-rc4+ftrace+kprobe: set kprobe at instruction 'stwu' lead to system crash/freeze
From: tiejun.chen @ 2011-12-01 10:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jim Keniston, Anton Blanchard, linux-kernel, Steven Rostedt,
Yong Zhang, paulus, yrl.pp-manager.tt, Masami Hiramatsu,
linuxppc-dev
In-Reply-To: <1322686809.29041.10.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2011-11-30 at 19:06 +0800, tiejun.chen wrote:
>
>>> - Copy the exception frame we're about to unwind to just -below- the
>>> new r1 value we want to write to. Then perform the write, and change
>>> r1 to point to that copy of the frame.
>>>
>>> - Branch to restore: which will unwind everything from that copy of
>>> the frame, and eventually set r1 to GPR(1) in the copy which contains
>>> the new value of r1.
>> We still can't restore this there.
>
> Yes, we can since we have copied the pt_regs down to -below- where we
> are going to write to. That's the whole trick. We copy the pt_regs
> somewhere "safe" and restore from there.
>
>> I mean we have to do that real restore here. So I'm really not sure if its a
>> good way to add such a codes including check TIF/copy-get new r1/restore
>> operation here since this is so deep for the exception return code.
>
> No. Re-read my explanation.
>
> In the do_work case (so when things are still easy), we copy the pt_regs
> of the return frame to a safe place (right below where we want to write
> to typically), and change r1 to point to this "new" frame which we use
> to restore from. Then we do the store which is now safe and go to an
> unmodified "restore" exit path.
Do you mean we should push the original pt_regs (or that whole exception stack)
downwards the location the new r1 point? Then its safe to perform this real
emulated stw instruction. At last we will reroute r1 to that copied exception
frame to restore as normal. Right?
Here I suppose so, I implement this for PPC32 based on the above understanding.
I take a validation for kprobing do_fork()/show_interrupts(), now looks fine.
Tomorrow I will go PPC64, and hope its fine as well.
If everything is good I'll send these patches to linuxppc-dev next week.
Cheers
Tiejun
>
>>> This is the less intrusive approach and should work just fine, it's also
>>> more robust than anything I've been able to think of and the approach
>>> would work for 32 and 64-bit similarily.
>>>
>>> (***) Above comment about a bug: If you look at entry_64.S version of
>>> ret_from_except_lite you'll notice that in the !preempt case, after
>>> we've checked MSR_PR we test for any TIF flag in _TIF_USER_WORK_MASK to
>>> decide whether to go to do_work or not. However, in the preempt case, we
>>> do a convoluted trick to test SIGPENDING only if PR was set and always
>>> test NEED_RESCHED ... but we forget to test any other bit of
>>> _TIF_USER_WORK_MASK !!! So that means that with preempt, we completely
>>> fail to test for things like single step, syscall tracing, etc...
>>>
>> This is another problem we should address.
>>
>>> I think this should be fixed at the same time, by simplifying the code
>>> by doing:
>>>
>>> - Test PR. If set, go to test_work_user, else continue (or the other
>>> way around and call it test_work_kernel)
>>>
>>> - In test_work_user, always test for _TIF_USER_WORK_MASK to decide to
>>> go to do_work, maybe call it do_user_work
>>>
>>> - In test_work_kernel, test for _TIF_KERNEL_WORK_MASK which is set to
>>> our new flag along with NEED_RESCHED if preempt is enabled and branch to
>>> do_kernel_work.
>>>
>>> do_user_work is basically the same as today's user_work
>>>
>>> do_kernel_work is basically the same as today preempt block with added
>>> code to handle the new flag as described above.
>>>
>>> Is anybody volunteering for fixing that ? I don't have the bandwidth
>> I always use one specific kprobe stack to fix this for BOOKE and work well in my
>> local tree :) Do you remember my v3 patch? I think its possible to extend this
>> for all PPC variants.
>>
>> Anyway, I'd like to be this volunteer with our last solution.
>
> So the second problem I exposed, for which you just volunteered
> (hint :-) is an orthogonal issue not related to kprobe or stacks which
> happen to be something I discovered yesterday while looking at the code.
>
> As for the solution to the emulation problem, re-read my explanation.
> The whole trick is that we can avoid a separate stack (which I really
> want to avoid) and we can avoid touching the low level restore code
> path.
>
> Cheers,
> Ben.
^ permalink raw reply
* Re: [BUG?]3.0-rc4+ftrace+kprobe: set kprobe at instruction 'stwu' lead to system crash/freeze
From: tiejun.chen @ 2011-12-01 10:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jim Keniston, Anton Blanchard, linux-kernel, Steven Rostedt,
Yong Zhang, paulus, yrl.pp-manager.tt, Masami Hiramatsu,
linuxppc-dev
In-Reply-To: <1322686809.29041.10.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Wed, 2011-11-30 at 19:06 +0800, tiejun.chen wrote:
>
>>> - Copy the exception frame we're about to unwind to just -below- the
>>> new r1 value we want to write to. Then perform the write, and change
>>> r1 to point to that copy of the frame.
>>>
>>> - Branch to restore: which will unwind everything from that copy of
>>> the frame, and eventually set r1 to GPR(1) in the copy which contains
>>> the new value of r1.
>> We still can't restore this there.
>
> Yes, we can since we have copied the pt_regs down to -below- where we
> are going to write to. That's the whole trick. We copy the pt_regs
> somewhere "safe" and restore from there.
>
>> I mean we have to do that real restore here. So I'm really not sure if its a
>> good way to add such a codes including check TIF/copy-get new r1/restore
>> operation here since this is so deep for the exception return code.
>
> No. Re-read my explanation.
>
> In the do_work case (so when things are still easy), we copy the pt_regs
> of the return frame to a safe place (right below where we want to write
> to typically), and change r1 to point to this "new" frame which we use
> to restore from. Then we do the store which is now safe and go to an
> unmodified "restore" exit path.
Do you mean we should push the original pt_regs (or that whole exception stack)
downwards the location the new r1 point? Then its safe to perform this real
emulated stw instruction. At last we will reroute r1 to that copied exception
frame to restore as normal. Right?
Here I suppose so, I implement this for PPC32 based on the above understanding.
I take a validation for kprobing do_fork()/show_interrupts(), now looks fine.
Tomorrow I will go PPC64, and hope its fine as well.
If everything is good I'll send these patches to linuxppc-dev next week.
Cheers
Tiejun
>
>>> This is the less intrusive approach and should work just fine, it's also
>>> more robust than anything I've been able to think of and the approach
>>> would work for 32 and 64-bit similarily.
>>>
>>> (***) Above comment about a bug: If you look at entry_64.S version of
>>> ret_from_except_lite you'll notice that in the !preempt case, after
>>> we've checked MSR_PR we test for any TIF flag in _TIF_USER_WORK_MASK to
>>> decide whether to go to do_work or not. However, in the preempt case, we
>>> do a convoluted trick to test SIGPENDING only if PR was set and always
>>> test NEED_RESCHED ... but we forget to test any other bit of
>>> _TIF_USER_WORK_MASK !!! So that means that with preempt, we completely
>>> fail to test for things like single step, syscall tracing, etc...
>>>
>> This is another problem we should address.
>>
>>> I think this should be fixed at the same time, by simplifying the code
>>> by doing:
>>>
>>> - Test PR. If set, go to test_work_user, else continue (or the other
>>> way around and call it test_work_kernel)
>>>
>>> - In test_work_user, always test for _TIF_USER_WORK_MASK to decide to
>>> go to do_work, maybe call it do_user_work
>>>
>>> - In test_work_kernel, test for _TIF_KERNEL_WORK_MASK which is set to
>>> our new flag along with NEED_RESCHED if preempt is enabled and branch to
>>> do_kernel_work.
>>>
>>> do_user_work is basically the same as today's user_work
>>>
>>> do_kernel_work is basically the same as today preempt block with added
>>> code to handle the new flag as described above.
>>>
>>> Is anybody volunteering for fixing that ? I don't have the bandwidth
>> I always use one specific kprobe stack to fix this for BOOKE and work well in my
>> local tree :) Do you remember my v3 patch? I think its possible to extend this
>> for all PPC variants.
>>
>> Anyway, I'd like to be this volunteer with our last solution.
>
> So the second problem I exposed, for which you just volunteered
> (hint :-) is an orthogonal issue not related to kprobe or stacks which
> happen to be something I discovered yesterday while looking at the code.
>
> As for the solution to the emulation problem, re-read my explanation.
> The whole trick is that we can avoid a separate stack (which I really
> want to avoid) and we can avoid touching the low level restore code
> path.
>
> Cheers,
> Ben.
^ permalink raw reply
* Re: VM Hanging after reboot
From: Artur Baruchi @ 2011-12-01 10:41 UTC (permalink / raw)
To: Fajar A. Nugraha; +Cc: Konrad Rzeszutek Wilk, Xen-devel, xen-users
In-Reply-To: <CAG1y0sfjmeDoLJ131TV-GUphhcuu+LcmJLJC-3h5=DzMKe7Jmg@mail.gmail.com>
Hi.
The error is within the guest (HVM virtual machine).
Thanks.
Att.
Artur Baruchi
On Thu, Dec 1, 2011 at 1:28 AM, Fajar A. Nugraha <list@fajar.net> wrote:
> On Thu, Dec 1, 2011 at 10:16 AM, Konrad Rzeszutek Wilk
> <konrad@darnok.org> wrote:
>> On Wed, Nov 30, 2011 at 09:09:58PM -0200, Artur Baruchi wrote:
>>> Hi Konrad.
>>>
>>> That was my first though (disk going bad). But I create another VM in
>>> a different host and faced the same error. I tried to create another
>>
>> So is the error from within the guest or from the dom0?
>>
>
> As Konrad asked, is the error in dom0 or domU?
>
> If dom0, then most likely it's disk problem. One way to diagnose it is
> by reading from the disk (dd_rescue is nice) and see if at least it's
> able to read the disk completely.
>
> If domU, then it's probably a bug in dom0 kernel (the blkback driver,
> perhaps). In which case novell guys might be able to help you more. I
> recall something like this when using older kernel for dom0 (forgot
> the exact version, sorry), but the error went away after I used
> vanilla 3.1.0 for dom0 kernel.
>
> --
> Fajar
^ permalink raw reply
* Re: [Qemu-devel] Improve QEMU performance with LLVM codegen and other techniques
From: 陳韋任 @ 2011-12-01 10:40 UTC (permalink / raw)
To: Peter Maydell; +Cc: qemu-devel, 陳韋任
In-Reply-To: <CAFEAcA-Lf3wYDcCqA1FMZSEKmPXRUEjnpr810xQBZL26xuS8nw@mail.gmail.com>
> The IO thread is always enabled in QEMU these days.
We use QEMU 0.13. I think IO thread is not enabled by default.
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
^ permalink raw reply
* RE: [PATCH] SCSI: aacraid: potential integer overflow in aac_get_containers()
From: Achim Leubner @ 2011-12-01 10:07 UTC (permalink / raw)
To: Haogang Chen, aacraid; +Cc: JBottomley, linux-scsi, linux-kernel
In-Reply-To: <1322706601-26181-1-git-send-email-haogangchen@gmail.com>
Acked-by: Achim Leubner <Achim_Leubner@pmc-sierra.com>
-----Original Message-----
From: linux-scsi-owner@vger.kernel.org
[mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Haogang Chen
Sent: Donnerstag, 1. Dezember 2011 03:30
To: aacraid@adaptec.com
Cc: JBottomley@parallels.com; linux-scsi@vger.kernel.org;
linux-kernel@vger.kernel.org; haogangchen@gmail.com
Subject: [PATCH] SCSI: aacraid: potential integer overflow in
aac_get_containers()
There is a potential integer overflow in aac_get_containers(). When
maximum_num_containers is large, the subsequent call to kzalloc() will
allocate a buffer smaller than expected, which leads to memory
corruption in the for loop.
The patch replaces kzalloc with kcalloc.
Signed-off-by: Haogang Chen <haogangchen@gmail.com>
---
drivers/scsi/aacraid/aachba.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/aacraid/aachba.c
b/drivers/scsi/aacraid/aachba.c
index 409f580..440b84d 100644
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -381,7 +381,7 @@ int aac_get_containers(struct aac_dev *dev)
if (maximum_num_containers < MAXIMUM_NUM_CONTAINERS)
maximum_num_containers = MAXIMUM_NUM_CONTAINERS;
- fsa_dev_ptr = kzalloc(sizeof(*fsa_dev_ptr) *
maximum_num_containers,
+ fsa_dev_ptr = kcalloc(maximum_num_containers,
sizeof(*fsa_dev_ptr),
GFP_KERNEL);
if (!fsa_dev_ptr)
return -ENOMEM;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [Devel] Affordable Education
From: devel @ 2011-12-01 10:39 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
AFFORDABLE ONLINE BACHEL0R'S, MASTER'S & DOCT0RATE DEGREES
Add Bache1or's, Master's or Doctorate Degrees to your resume in just a few weeks and open avenues to promotion and better jobs!
At your Own Pace!
At your Own Schedule!
At your Own Convenience!
No Examination!
No Study!
No Class!
Regardless of your age, sex, marital status, or location, you can receive a degree in your desired field. All you need is sufficient work, military, or life experience and you are already on your way to an instant degree in your relevant field.
Earn a recognized University Degree based on work or life experience within weeks!
Get your desired degree on the basis of your Prior Knowledge and Professional Experience.
Give us a call NOW!
1-404-549-4731
Please leave us your:
1) Your Name
3) Phone No.
We will get back to you ASAP
^ permalink raw reply
* Re: How to drop an idle connection with iptables?
From: Jan Engelhardt @ 2011-12-01 10:39 UTC (permalink / raw)
To: Anatoly Muliarski; +Cc: lu zhongda, netfilter
In-Reply-To: <CA+4D1sfSu77cv_b5R0R_SULDpGX-9i70AuxBguAqOcrN1EpWiw@mail.gmail.com>
On Thursday 2011-12-01 11:22, Anatoly Muliarski wrote:
>Hi Lu,
>
>I suggest trying to drop invalid packets:
>iptables -I INPUT -m state --state INVALID -j DROP
>iptables -I OUTPUT -m state --state INVALID -j DROP
Or better yet, -m conntrack --ctstate INVALID.
^ permalink raw reply
* Re: [PATCH 2/2] x86/microcode: enable boot time (pre-Dom0) loading
From: Borislav Petkov @ 2011-12-01 10:38 UTC (permalink / raw)
To: Jan Beulich
Cc: Konrad Rzeszutek Wilk, xen-devel@lists.xensource.com,
Ian Campbell, hpa@zytor.com
In-Reply-To: <4ED75EB202000078000649E9@nat28.tlf.novell.com>
On Thu, Dec 01, 2011 at 10:02:10AM +0000, Jan Beulich wrote:
> >>> On 01.12.11 at 10:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2011-12-01 at 08:04 +0000, Jan Beulich wrote:
> >>
> >> > I got the impression they wanted some new .pack format or so?
> >> > Or is the format that they were talking about exactly what you
> >> picked?
> >>
> >> I merely picked the binary formats that are already in use; I see no
> >> reason to invent another one.
> >
> > Adding a header/magic number so you can detect which of the blobs is
> > microcode?
>
> This is precisely what I did *not* want to do.
Well, AFAICR, we talked about using the setup_data linked list in
the user-mode kernel header and since parse_setup_data() looks at
data->type, then probably something should state the type of the ucode
image, but I'm not sure on the details.
FWIW, hpa mentioned at KS he already has some code doing early ucode
loading so I'll let him chime in here. He's away this week though so it
could take a while.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
^ permalink raw reply
* Re: [PATCH v2] ramoops: use pstore interface
From: Marco Stornelli @ 2011-12-01 10:31 UTC (permalink / raw)
To: Kees Cook
Cc: Chen Gong, linux-kernel, Tony Luck, Randy Dunlap, Arnd Bergmann,
Greg Kroah-Hartman, Andrew Morton
In-Reply-To: <CAGXu5j+kzXpAhCYELDBBeMDPg2XMHt8jWRjZf2xiPVSMfUhjzA@mail.gmail.com>
Il 29/11/2011 18:24, Kees Cook ha scritto:
> On Mon, Nov 28, 2011 at 8:50 PM, Chen Gong<gong.chen@linux.intel.com> wrote:
>> 于 2011/11/29 4:09, Kees Cook 写道:
>>>
>>> Instead of using /dev/mem directly, use the common pstore infrastructure
>>> to handle Oops gathering and extraction.
>>>
>>> Signed-off-by: Kees Cook<keescook@chromium.org>
>>> ---
>>> This depends on the pstore changes waiting for -next in:
>>>
>>> http://git.kernel.org/?p=linux/kernel/git/aegl/linux.git;a=shortlog;h=refs/heads/next
>>> ---
>>> Documentation/ramoops.txt | 8 +-
>>> drivers/char/Kconfig | 1 +
>>> drivers/char/ramoops.c | 206
>>> ++++++++++++++++++++++++++++++++++-----------
>>> 3 files changed, 160 insertions(+), 55 deletions(-)
>>>
>>> diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
>>> index 8fb1ba7..a0b9d8e 100644
>>> --- a/Documentation/ramoops.txt
>>> +++ b/Documentation/ramoops.txt
>>> @@ -3,7 +3,7 @@ Ramoops oops/panic logger
>>>
>>> Sergiu Iordache<sergiu@chromium.org>
>>>
>>> -Updated: 8 August 2011
>>> +Updated: 17 November 2011
>>>
>>> 0. Introduction
>>>
>>> @@ -71,6 +71,6 @@ timestamp and a new line. The dump then continues with
>>> the actual data.
>>>
>>> 4. Reading the data
>>>
>>> -The dump data can be read from memory (through /dev/mem or other means).
>>> -Getting the module parameters, which are needed in order to parse the
>>> data, can
>>> -be done through /sys/module/ramoops/parameters/* .
>>> +The dump data can be read from the pstore filesystem. The format for
>>> these
>>> +files is "dmesg-ramoops-N", where N is the record number in memory. To
>>> delete
>>> +a stored record from RAM, simply unlink the respective pstore file.
>>
>> I think the definition of "mem_address" in the doc is not very clear. It is
>> not a normal memory instead of a persistent RAM. I suggest adding more
>> descriptions.
>> It's better if there is a real example.
>
> Okay. I'm not sure it's in the scope of this patch, but I can try.
>
> Marco, do you have suggestions for how this could be enhanced?
>
I don't know actually. It's not mandatory use a persistent memory. A
simple piece of reserved RAM is ok. Obviously it will work only over
reboot and not over power down. I define mem_address as a generic piece
of reserved memory.
Marco
^ permalink raw reply
* Re: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
From: Liu, Jinsong @ 2011-12-01 10:35 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel@lists.xensource.com, keir@xen.org
In-Reply-To: <4ED761060200007800064A09@nat28.tlf.novell.com>
Jan Beulich wrote:
>>>> On 01.12.11 at 11:01, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Liu, Jinsong wrote:
>>> Jan Beulich wrote:
>>>>>>> On 27.11.11 at 11:16, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>> wrote:
>>>>> Jan Beulich wrote:
>>>>>>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>>>>> wrote:
>>>>>>> This patch disable PCID/INVPCID for dom0.
>>>>>>
>>>>>> Do we really need to disable it, rather than making it work?
>>>>>> Conceptually the feature seems usable, and the instruction would
>>>>>> need replacement by a hypercall anyway (just like invlpg).
>>>>>
>>>>> It's a design choice.
>>>>> Exposing PCID/INVPCID to pv would involve some additional task,
>>>>> like coordinated PCID allocation algorithm, or change vmm vcpu
>>>>> context swich, which would make it complex. However, exposing
>>>>> PCID/INVPCID to pv has not obvious benefit or even result in
>>>>> performance regression.
>>>>
>>>> Would you mind elaborating on that statement?
>>>>
>>>> Jan
>>>
>>> For pv, if expose PCID to pv, the PCIDs of different pv domain may
>>> conflict, which make processor confused at TLB.
>>> To make PCID work at pv, it need
>>> 1, either a coordinated PCID allocation algorithm, so that the local
>>> PCID of pv domain can be changed to a global unique PCID; 2, or, a
>>> 'clean' vcpu context switch logic to flush all TLB;
>>> method 1 make things complex w/o obvious benefit;
>>> method 2 need change current vcpu context switch logic (i.e, mov cr3
>>> only flush TLB entries of specific PCID if PCID enabled), and if
>>> flush *all* TLB is required at context switch, we lose the change to
>>> optimize context switch by partly flush TLB case by case, which may
>>> result in performance regression;
>>>
>>> Thanks,
>>> Jinsong
>>
>> Jan, any comments? Thanks, Jinsong
>
> No, no further comments (just don't have the time right now to think
> through the possible alternatives). So for the moment I think things
> could go in as posted by you. It's not immediately clear though
> whether the series needs to be applied in order (it would seem that's
> not a requirement, but I'd like your confirmation), as I could at most
> take care of patches 2, 3, and 6.
>
> Jan
Do you mean checkin patches 2/3/6 first?
It's OK to checkin patches 2/3/6 first, they are ./xen code, no order-dependence with patches 1/4/5 (which are ./tools code).
Thanks,
Jinsong
^ permalink raw reply
* RE: [PATCH] ARM: exynos4: Fix for stall in case of cpu hotplug or sleep
From: Kukjin Kim @ 2011-12-01 10:35 UTC (permalink / raw)
To: 'Amit Daniel Kachhap', linux-samsung-soc; +Cc: patches
In-Reply-To: <1321616752-1233-1-git-send-email-amit.kachhap@linaro.org>
Amit Daniel Kachhap wrote:
>
> This patch adds remove_irq in place of disable_irq which is
> correct equivalent function for setup_irq used in
> exynos4_mct_tick_init.
>
> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@linaro.org>
> Tested-by: Inderpal Singh <inderpal.singh@linaro.org>
> ---
> arch/arm/mach-exynos/mct.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
> index 97343df..959f251 100644
> --- a/arch/arm/mach-exynos/mct.c
> +++ b/arch/arm/mach-exynos/mct.c
> @@ -428,9 +428,13 @@ int __cpuinit local_timer_setup(struct
> clock_event_device *evt)
>
> void local_timer_stop(struct clock_event_device *evt)
> {
> + unsigned int cpu = smp_processor_id();
> evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
> if (mct_int_type == MCT_INT_SPI)
> - disable_irq(evt->irq);
> + if (cpu == 0)
> + remove_irq(evt->irq, &mct_tick0_event_irq);
> + else
> + remove_irq(evt->irq, &mct_tick1_event_irq);
Hmm, how about the cpu number is 2 or 3 on Quad-core?
As you know, this should be used for all of EXYNOS SoCs.
> else
> disable_percpu_irq(IRQ_MCT_LOCALTIMER);
> }
> --
> 1.7.1
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
From: Ian Campbell @ 2011-12-01 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201111301815.01297.arnd@arndb.de>
On Wed, 2011-11-30 at 18:15 +0000, Arnd Bergmann wrote:
> On Wednesday 30 November 2011, Ian Campbell wrote:
> > On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote:
> > > On Wednesday 30 November 2011, Ian Campbell wrote:
> > > What I suggested to the KVM developers is to start out with the
> > > vexpress platform, but then generalize it to the point where it fits
> > > your needs. All hardware that one expects a guest to have (GIC, timer,
> > > ...) will still show up in the same location as on a real vexpress,
> > > while anything that makes no sense or is better paravirtualized (LCD,
> > > storage, ...) just becomes optional and has to be described in the
> > > device tree if it's actually there.
> >
> > That's along the lines of what I was thinking as well.
> >
> > The DT contains the address of GIC, timer etc as well right? So at least
> > in principal we needn't provide e.g. the GIC at the same address as any
> > real platform but in practice I expect we will.
>
> Yes.
>
> > In principal we could also offer the user options as to which particular
> > platform a guest looks like.
>
> At least when using a qemu based simulation. Most platforms have some
> characteristics that are not meaningful in a classic virtualization
> scenario, but it would certainly be helpful to use the virtualization
> extensions to run a kernel that was built for a particular platform
> faster than with pure qemu, when you want to test that kernel image.
>
> It has been suggested in the past that it would be nice to run the
> guest kernel built for the same platform as the host kernel by
> default, but I think it would be much better to have just one
> platform that we end up using for guests on any host platform,
> unless there is a strong reason to do otherwise.
Yes, I agree, certainly that is what we were planning to target in the
first instance. Doing this means that we can get away with minimal
emulation of actual hardware, relying instead on PV drivers or hardware
virtualisation features.
Supporting specific board platforms as guests would be nice to have
eventually. We would need to do more emulation (e.g. running qemu as a
device model) for that case.
> There is also ongoing restructuring in the ARM Linux kernel to
> allow running the same kernel binary on multiple platforms. While
> there is still a lot of work to be done, you should assume that
> we will finish it before you see lots of users in production, there
> is no need to plan for the current one-kernel-per-board case.
We were absolutely banking on targeting the results of this work, so
that's good ;-)
Ian.
^ permalink raw reply
* Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt extensions
From: Ian Campbell @ 2011-12-01 10:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
Pawel Moll, kvm@vger.kernel.org, Stefano Stabellini,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
android-virt@lists.cs.columbia.edu,
embeddedxen-devel@lists.sourceforge.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <201111301815.01297.arnd@arndb.de>
On Wed, 2011-11-30 at 18:15 +0000, Arnd Bergmann wrote:
> On Wednesday 30 November 2011, Ian Campbell wrote:
> > On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote:
> > > On Wednesday 30 November 2011, Ian Campbell wrote:
> > > What I suggested to the KVM developers is to start out with the
> > > vexpress platform, but then generalize it to the point where it fits
> > > your needs. All hardware that one expects a guest to have (GIC, timer,
> > > ...) will still show up in the same location as on a real vexpress,
> > > while anything that makes no sense or is better paravirtualized (LCD,
> > > storage, ...) just becomes optional and has to be described in the
> > > device tree if it's actually there.
> >
> > That's along the lines of what I was thinking as well.
> >
> > The DT contains the address of GIC, timer etc as well right? So at least
> > in principal we needn't provide e.g. the GIC at the same address as any
> > real platform but in practice I expect we will.
>
> Yes.
>
> > In principal we could also offer the user options as to which particular
> > platform a guest looks like.
>
> At least when using a qemu based simulation. Most platforms have some
> characteristics that are not meaningful in a classic virtualization
> scenario, but it would certainly be helpful to use the virtualization
> extensions to run a kernel that was built for a particular platform
> faster than with pure qemu, when you want to test that kernel image.
>
> It has been suggested in the past that it would be nice to run the
> guest kernel built for the same platform as the host kernel by
> default, but I think it would be much better to have just one
> platform that we end up using for guests on any host platform,
> unless there is a strong reason to do otherwise.
Yes, I agree, certainly that is what we were planning to target in the
first instance. Doing this means that we can get away with minimal
emulation of actual hardware, relying instead on PV drivers or hardware
virtualisation features.
Supporting specific board platforms as guests would be nice to have
eventually. We would need to do more emulation (e.g. running qemu as a
device model) for that case.
> There is also ongoing restructuring in the ARM Linux kernel to
> allow running the same kernel binary on multiple platforms. While
> there is still a lot of work to be done, you should assume that
> we will finish it before you see lots of users in production, there
> is no need to plan for the current one-kernel-per-board case.
We were absolutely banking on targeting the results of this work, so
that's good ;-)
Ian.
^ permalink raw reply
* Re: [PATCH V4] mmc: allow upper layers to determine immediately if a card has been removed
From: Sujit Reddy Thumma @ 2011-12-01 10:34 UTC (permalink / raw)
To: Adrian Hunter; +Cc: Chris Ball, per.lkml, linux-mmc, linux-arm-msm
In-Reply-To: <1322490120-23429-1-git-send-email-adrian.hunter@intel.com>
On 11/28/2011 7:52 PM, Adrian Hunter wrote:
> Add a function mmc_detect_card_removed() which upper layers
> can use to determine immediately if a card has been removed.
> This function should be called after an I/O request fails so
> that all queued I/O requests can be errored out immediately
> instead of waiting for the card device to be removed.
>
> Signed-off-by: Adrian Hunter<adrian.hunter@intel.com>
Acked-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
--
Thanks,
Sujit
^ permalink raw reply
* Busy looping iwl3945 driver
From: Zdenek Kabelac @ 2011-12-01 10:33 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: linux-wireless
Hi
Today I've noticed 100% CPU occupied by kworker thread - which
appeared to be the result of some iwl3945 driver interaction.
Here are some trace of some tasks from that moment.
It looked like when I've then even tried to run 'mc' of 'ifconfig' -
they could not start since some device lock was kept busy.
The problem was most probably caused by doing suspend when attached to
the wireless network and resuming in wired docking station,
without having the previous wireless AP available.
My hw - T61, 4G, C2D, iwl3945 wifi, X86_64 kernel 3.2.0-rc3
Only reboot fixed this problem.
NetworkManager D 0000000000000000 0 648 1 0x00000004
ffff8801301157e8 0000000000000046 ffffffff814d9fe4 0000000000000000
ffff8801301157f8 ffff88012c968000 0000000000000000 ffff880130115fd8
ffff880130115fd8 ffff880130115fd8 ffffffff81a0d020 ffff88012c968000
Call Trace:
[<ffffffff814d9fe4>] ? __schedule+0x994/0xb50
[<ffffffff814da23f>] schedule+0x3f/0x60
[<ffffffff814db1c2>] mutex_lock_nested+0x1b2/0x3f0
[<ffffffffa033984f>] ? ieee80211_ifa_changed+0x9f/0x150 [mac80211]
[<ffffffffa033984f>] ? ieee80211_ifa_changed+0x9f/0x150 [mac80211]
[<ffffffffa033984f>] ieee80211_ifa_changed+0x9f/0x150 [mac80211]
[<ffffffff814e17e3>] notifier_call_chain+0x93/0x100
[<ffffffff81082cf8>] __blocking_notifier_call_chain+0x78/0xb0
[<ffffffff81082d46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff814856b6>] __inet_del_ifa+0xb6/0x290
[<ffffffff8148633e>] inet_rtm_deladdr+0x10e/0x160
[<ffffffff81436544>] rtnetlink_rcv_msg+0x124/0x2e0
[<ffffffff81436420>] ? __rtnl_unlock+0x20/0x20
[<ffffffff81446c49>] netlink_rcv_skb+0xa9/0xd0
[<ffffffff81434465>] rtnetlink_rcv+0x25/0x40
[<ffffffff81446580>] netlink_unicast+0x2c0/0x310
[<ffffffff81446886>] netlink_sendmsg+0x2b6/0x310
[<ffffffff81410458>] ? sock_update_classid+0xb8/0x1f0
[<ffffffff81409cee>] sock_sendmsg+0x10e/0x1e0
[<ffffffff8140babd>] ? sock_recvmsg+0x18d/0x210
[<ffffffff8112dce3>] ? might_fault+0x53/0xb0
[<ffffffff8112dd2c>] ? might_fault+0x9c/0xb0
[<ffffffff8112dce3>] ? might_fault+0x53/0xb0
[<ffffffff814191c6>] ? verify_iovec+0x56/0xd0
[<ffffffff8140c116>] __sys_sendmsg+0x376/0x380
[<ffffffff81161458>] ? fget_light+0x48/0x3b0
[<ffffffff811614f1>] ? fget_light+0xe1/0x3b0
[<ffffffff81161458>] ? fget_light+0x48/0x3b0
[<ffffffff8118149f>] ? mntput+0x1f/0x30
[<ffffffff8140db19>] sys_sendmsg+0x49/0x90
[<ffffffff814e562b>] system_call_fastpath+0x16/0x1b
avahi-daemon D 0000000000000246 0 667 1 0x00000000
ffff880127df5ba8 0000000000000046 0000000000000000 0000000000000000
ffff880127df5bb8 ffff880128be4600 0000000000000000 ffff880127df5fd8
ffff880127df5fd8 ffff880127df5fd8 ffff88012ca72300 ffff880128be4600
Call Trace:
[<ffffffff814da23f>] schedule+0x3f/0x60
[<ffffffff814db1c2>] mutex_lock_nested+0x1b2/0x3f0
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] rtnl_lock+0x17/0x20
[<ffffffff8148ff6f>] ip_mc_leave_group+0x2f/0x180
[<ffffffff8145b2f4>] do_ip_setsockopt+0x6d4/0xdb0
[<ffffffff81409cee>] ? sock_sendmsg+0x10e/0x1e0
[<ffffffff8116a1fc>] ? pipe_write+0x2ec/0x5b0
[<ffffffff811a1b43>] ? fsnotify+0x93/0x600
[<ffffffff8140d6f1>] ? sys_sendto+0x101/0x130
[<ffffffff8145bad6>] ip_setsockopt+0x36/0xb0
[<ffffffff8147dcab>] udp_setsockopt+0x1b/0x40
[<ffffffff8140e574>] sock_common_setsockopt+0x14/0x20
[<ffffffff8140d8ff>] sys_setsockopt+0x7f/0xe0
[<ffffffff814e562b>] system_call_fastpath+0x16/0x1b
wpa_supplicant D 0000000000000246 0 770 1 0x00000000
ffff880127c17908 0000000000000046 0000000000000000 0000000000000000
ffff880127c17918 ffff880127e02300 0000000000000000 ffff880127c17fd8
ffff880127c17fd8 ffff880127c17fd8 ffff88012ca72300 ffff880127e02300
Call Trace:
[<ffffffff814da23f>] schedule+0x3f/0x60
[<ffffffff814db1c2>] mutex_lock_nested+0x1b2/0x3f0
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] rtnl_lock+0x17/0x20
[<ffffffffa02ec1d5>] nl80211_pre_doit+0xf5/0x190 [cfg80211]
[<ffffffff81447263>] genl_rcv_msg+0x1c3/0x250
[<ffffffff814470a0>] ? genl_rcv+0x40/0x40
[<ffffffff81446c49>] netlink_rcv_skb+0xa9/0xd0
[<ffffffff81447085>] genl_rcv+0x25/0x40
[<ffffffff81446580>] netlink_unicast+0x2c0/0x310
[<ffffffff81446886>] netlink_sendmsg+0x2b6/0x310
[<ffffffff81410458>] ? sock_update_classid+0xb8/0x1f0
[<ffffffff81409cee>] sock_sendmsg+0x10e/0x1e0
[<ffffffff8140babd>] ? sock_recvmsg+0x18d/0x210
[<ffffffff8112dce3>] ? might_fault+0x53/0xb0
[<ffffffff8112dd2c>] ? might_fault+0x9c/0xb0
[<ffffffff8112dce3>] ? might_fault+0x53/0xb0
[<ffffffff814191c6>] ? verify_iovec+0x56/0xd0
[<ffffffff8140c116>] __sys_sendmsg+0x376/0x380
[<ffffffff8106a904>] ? set_current_blocked+0x34/0x60
[<ffffffff8100bee1>] ? fpu_finit+0x21/0x40
[<ffffffff8100bf4a>] ? init_fpu+0x4a/0x180
[<ffffffff8100d198>] ? restore_i387_xstate+0xc8/0x1d0
[<ffffffff811615bf>] ? fget_light+0x1af/0x3b0
[<ffffffff814ddedb>] ? _raw_spin_unlock_irq+0x3b/0x60
[<ffffffff8140db19>] sys_sendmsg+0x49/0x90
[<ffffffff814e562b>] system_call_fastpath+0x16/0x1b
ntpd D 0000000000000246 0 21324 1 0x00000000
ffff880127adfca8 0000000000000046 0000000000000000 0000000000000000
ffff880127adfcb8 ffff880127f5c600 0000000000000000 ffff880127adffd8
ffff880127adffd8 ffff880127adffd8 ffff8800379e4600 ffff880127f5c600
Call Trace:
[<ffffffff814da23f>] schedule+0x3f/0x60
[<ffffffff814db1c2>] mutex_lock_nested+0x1b2/0x3f0
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] rtnl_lock+0x17/0x20
[<ffffffff81428165>] dev_ioctl+0x3c5/0x660
[<ffffffff81090b80>] ? lockdep_init_map+0xf0/0x590
[<ffffffff814092ad>] sock_do_ioctl+0x5d/0x70
[<ffffffff81409339>] sock_ioctl+0x79/0x2f0
[<ffffffff811736f8>] do_vfs_ioctl+0x98/0x570
[<ffffffff814dddf5>] ? _raw_spin_unlock+0x35/0x60
[<ffffffff8115d7cd>] ? fd_install+0x7d/0x100
[<ffffffff811615bf>] ? fget_light+0x1af/0x3b0
[<ffffffff81173c61>] sys_ioctl+0x91/0xa0
[<ffffffff814e562b>] system_call_fastpath+0x16/0x1b
Here I've tried 'mc' and rmmod of iwl3945 (which had in fact open count == 0)
mc D 0000000000000000 0 12325 12174 0x00000000
ffff880007a77ca8 0000000000000046 ffffffff814d9fe4 0000000000000000
ffff880007a77cb8 ffff880037918000 0000000000000000 ffff880007a77fd8
ffff880007a77fd8 ffff880007a77fd8 ffffffff81a0d020 ffff880037918000
Call Trace:
[<ffffffff814d9fe4>] ? __schedule+0x994/0xb50
[<ffffffff814da23f>] schedule+0x3f/0x60
[<ffffffff814db1c2>] mutex_lock_nested+0x1b2/0x3f0
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] ? rtnl_lock+0x17/0x20
[<ffffffff81434437>] rtnl_lock+0x17/0x20
[<ffffffff81428165>] dev_ioctl+0x3c5/0x660
[<ffffffff81090b80>] ? lockdep_init_map+0xf0/0x590
[<ffffffff814092ad>] sock_do_ioctl+0x5d/0x70
[<ffffffff81409339>] sock_ioctl+0x79/0x2f0
[<ffffffff811736f8>] do_vfs_ioctl+0x98/0x570
[<ffffffff814dddf5>] ? _raw_spin_unlock+0x35/0x60
[<ffffffff8115d7cd>] ? fd_install+0x7d/0x100
[<ffffffff811615bf>] ? fget_light+0x1af/0x3b0
[<ffffffff81173c61>] sys_ioctl+0x91/0xa0
[<ffffffff814e562b>] system_call_fastpath+0x16/0x1b
rmmod D 0000000000000000 0 12340 22112 0x00000000
ffff880051811bf8 0000000000000046 ffffffff814d9fe4 ffffffff814d5fd1
0000000000000001 ffff8800b0cd8000 0000000000000046 ffff880051811fd8
ffff880051811fd8 ffff880051811fd8 ffff880136d44600 ffff8800b0cd8000
Call Trace:
[<ffffffff814d9fe4>] ? __schedule+0x994/0xb50
[<ffffffff814d5fd1>] ? __slab_free+0x233/0x3aa
[<ffffffff814da23f>] schedule+0x3f/0x60
[<ffffffff814dd265>] rwsem_down_failed_common+0xc5/0x160
[<ffffffff814dd313>] rwsem_down_write_failed+0x13/0x20
[<ffffffff812d2733>] call_rwsem_down_write_failed+0x13/0x20
[<ffffffff81082a07>] ? blocking_notifier_chain_unregister+0x27/0xe0
[<ffffffff814dc629>] ? down_write+0x89/0xb0
[<ffffffff81082a07>] ? blocking_notifier_chain_unregister+0x27/0xe0
[<ffffffff81082a07>] blocking_notifier_chain_unregister+0x27/0xe0
[<ffffffff81485cd8>] unregister_inetaddr_notifier+0x18/0x20
[<ffffffffa03380b6>] ieee80211_unregister_hw+0x46/0x120 [mac80211]
[<ffffffffa03b4779>] iwl3945_pci_remove+0x57/0x300 [iwl3945]
[<ffffffff814dde62>] ? _raw_spin_unlock_irqrestore+0x42/0x80
[<ffffffff812ee156>] pci_device_remove+0x46/0x110
[<ffffffff813926bc>] __device_release_driver+0x7c/0xe0
[<ffffffff81392fc8>] driver_detach+0xd8/0xe0
[<ffffffff813924f1>] bus_remove_driver+0x91/0x110
[<ffffffff813937b2>] driver_unregister+0x62/0xa0
[<ffffffff812ecf94>] pci_unregister_driver+0x44/0xc0
[<ffffffffa03b4a32>] iwl3945_exit+0x10/0x17 [iwl3945]
[<ffffffff810a169e>] sys_delete_module+0x16e/0x250
[<ffffffff8109647f>] ? trace_hardirqs_on_caller+0x1f/0x1b0
[<ffffffff814e562b>] system_call_fastpath+0x16/0x1b
Here is 'pert record -a -g'
# Overhead Command Shared Object
Symbol
# ........ ............... ..........................
...........................................
#
97.57% kworker/u:3 [kernel.kallsyms] [k] lock_timer_base
|
--- lock_timer_base
try_to_del_timer_sync
del_timer_sync
iwl3945_send_tx_power
ieee80211_bss_info_change_notify
ieee80211_sta_eosp_irqsafe
ieee80211_sta_eosp_irqsafe
ieee80211_stop_tx_ba_cb
ieee80211_stop_tx_ba_cb
ieee80211_stop_tx_ba_cb
ieee80211_stop_tx_ba_cb
process_one_work
worker_thread
kthread
kernel_thread_helper
0.38% kworker/u:3 [kernel.kallsyms] [k] ioread32
|
--- ioread32
|
|--37.76%-- iwl_legacy_send_bt_config
| iwl3945_rx_queue_restock
| iwl3945_irq_tasklet
| tasklet_action
| __do_softirq
| call_softirq
| do_softirq
| irq_exit
| __irqentry_text_start
| ret_from_intr
| try_to_del_timer_sync
| del_timer_sync
| iwl3945_send_tx_power
| ieee80211_bss_info_change_notify
| ieee80211_sta_eosp_irqsafe
| ieee80211_sta_eosp_irqsafe
| ieee80211_stop_tx_ba_cb
| ieee80211_stop_tx_ba_cb
| ieee80211_stop_tx_ba_cb
| ieee80211_stop_tx_ba_cb
| process_one_work
| worker_thread
| kthread
| kernel_thread_helper
|
|--31.13%-- iwl3945_irq_tasklet
| tasklet_action
| __do_softirq
| call_softirq
| do_softirq
| irq_exit
| |
| |--92.86%-- __irqentry_text_start
| | ret_from_intr
| | try_to_del_timer_sync
| | del_timer_sync
| | iwl3945_send_tx_power
| | ieee80211_bss_info_change_notify
| | ieee80211_sta_eosp_irqsafe
| | ieee80211_sta_eosp_irqsafe
| | ieee80211_stop_tx_ba_cb
| | ieee80211_stop_tx_ba_cb
| | ieee80211_stop_tx_ba_cb
| | ieee80211_stop_tx_ba_cb
| | process_one_work
| | worker_thread
| | kthread
| | kernel_thread_helper
| |
| --7.14%-- smp_apic_timer_interrupt
| apic_timer_interrupt
| try_to_del_timer_sync
| del_timer_sync
| iwl3945_send_tx_power
| ieee80211_bss_info_change_notify
| ieee80211_sta_eosp_irqsafe
| ieee80211_sta_eosp_irqsafe
| ieee80211_stop_tx_ba_cb
| ieee80211_stop_tx_ba_cb
| ieee80211_stop_tx_ba_cb
| ieee80211_stop_tx_ba_cb
| process_one_work
| worker_thread
| kthread
| kernel_thread_helper
|
--31.12%-- iwl_legacy_add_beacon_time
handle_irq_event_percpu
handle_irq_event
handle_edge_irq
handle_irq
__irqentry_text_start
ret_from_intr
try_to_del_timer_sync
del_timer_sync
iwl3945_send_tx_power
ieee80211_bss_info_change_notify
ieee80211_sta_eosp_irqsafe
ieee80211_sta_eosp_irqsafe
ieee80211_stop_tx_ba_cb
ieee80211_stop_tx_ba_cb
ieee80211_stop_tx_ba_cb
ieee80211_stop_tx_ba_cb
process_one_work
worker_thread
kthread
kernel_thread_helper
0.27% kworker/u:3 [kernel.kallsyms] [k] read_hpet
....
Zdenek
^ permalink raw reply
* Re: [PATCH 1/4] iommu: Add iommu_device_group callback and iommu_group sysfs entry
From: David Woodhouse @ 2011-12-01 10:33 UTC (permalink / raw)
To: Alex Williamson
Cc: David Gibson, Benjamin Herrenschmidt, joerg.roedel, iommu,
linux-kernel, chrisw, agraf, scottwood, B08248
In-Reply-To: <1322722110.26545.68.camel@bling.home>
On Wed, 2011-11-30 at 23:48 -0700, Alex Williamson wrote:
> I'm not sure if we're getting into VM usage with "assigning" terminology
> above. You're free to architect qemu however you want on POWER to make
> groups be the assignable unit to a guest. On x86, an individual device
> is the assignable unit for a guest. Unassigned group devices will still
> be required to be held by vfio, they'll just be unused. Thanks,
I'm not sure I understand this.
BY DEFINITION, the smallest assignable unit is the group, surely? Isn't
that the *point* of the groups? That the IOMMU cannot tell the
difference between the devices in the group?
So in *practice*, surely you cannot assign just *one* device from a
group? You can assign the while group, or nothing.
You might *pretend* to assign single devices, and we might try to cope
with the weirdness that happens when you want *one* device of a group to
be owned by one VM, another device in the same group to be owned by a
second VM, and a third device from the same group to be driven by a
native driver in the host. But why not just assign groups as a whole?
Surely that makes most sense?
Btw, did we get a quirk for the Ricoh multi-function devices which all
need to be in the same group because they do all their DMA from function
zero? I think we need another similar quirk for a Marvell SATA
controller which seems to do its AHCI DMA from its IDE function; see
https://bugzilla.redhat.com/757166
--
dwmw2
^ permalink raw reply
* [PATCH] imx: add polled io uart methods
From: Dirk Behme @ 2011-12-01 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111019035249.GA20598@lithium.compnerd.org>
On 19.10.2011 05:52, Saleem Abdulrasool wrote:
> On Tue, 18 Oct 2011, Uwe Kleine-K?nig wrote:
>
>> On Sun, Oct 16, 2011 at 08:22:01PM -0700, Saleem Abdulrasool wrote:
>>> These methods are invoked if the iMX uart is used in conjuction with kgdb during
>>> early boot. In order to access the UART without the interrupts, the kernel uses
>>> the basic polling methods for IO with the device. With these methods
>>> implemented, it is now possible to enable kgdb during early boot over serial.
>>>
>>> Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
>>> ---
>>> drivers/tty/serial/imx.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 files changed, 77 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>>> index 7e91b3d..4fcf9ca 100644
>>> --- a/drivers/tty/serial/imx.c
>>> +++ b/drivers/tty/serial/imx.c
>>> @@ -102,6 +102,7 @@
>>> #define UCR2_STPB (1<<6) /* Stop */
>>> #define UCR2_WS (1<<5) /* Word size */
>>> #define UCR2_RTSEN (1<<4) /* Request to send interrupt enable */
>>> +#define UCR2_ATEN (1<<3) /* Aging Timer Enable */
>>> #define UCR2_TXEN (1<<2) /* Transmitter enabled */
>>> #define UCR2_RXEN (1<<1) /* Receiver enabled */
>>> #define UCR2_SRST (1<<0) /* SW reset */
>>> @@ -1075,6 +1076,77 @@ imx_verify_port(struct uart_port *port, struct serial_struct *ser)
>>> return ret;
>>> }
>>>
>>> +
>> needless newline
>
> Removed.
>
>>> +#if defined(CONFIG_CONSOLE_POLL)
>>> +static int imx_poll_get_char(struct uart_port *port)
>>> +{
>>> + volatile unsigned int status;
>> Why is that volatile?
>
> It shouldnt be, removed the volatile attribute. Im not sure why that was there,
> it really doesnt make any sense since there isnt any inline assembler there to
> confuse the compiler.
>
>>> + unsigned int cr1, cr2, cr3;
>>> + unsigned char c;
>>> +
>>> + /* save control registers */
>>> + cr1 = readl(port->membase + UCR1);
>>> + cr2 = readl(port->membase + UCR2);
>>> + cr3 = readl(port->membase + UCR3);
>>> +
>> Best regards
>> Uwe
>
> Thanks for the review. Ive not attached the updated patch since Id like to make
> the changes that Sascha suggested, and I shall post the updated patch
> subsequently.
Any update on this?
Many thanks
Dirk
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.