headers
Julia Lawall | 1 Aug 2010 19:23
Picon
Favicon

[PATCH] drivers/scsi/pm8001: introduce missing kfree

From: Julia Lawall <julia <at> diku.dk>

Error handling code following a kmalloc should free the allocated data.

The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
 <at> r exists <at> 
local idexpression x;
expression E;
identifier f,f1;
position p1,p2;
 <at>  <at> 

x <at> p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
<... when != x
     when != if (...) { <+...x...+> }
     when != (x) == NULL
     when != (x) != NULL
     when != (x) == 0
     when != (x) != 0
(
x->f1 = E
|
 (x->f1 == NULL || ...)
|
 f(...,x->f1,...)
)
...>
(Continue reading)

Permalink | Reply | 1 comment |
headers
jack wang | 2 Aug 2010 03:34

RE: [PATCH] drivers/scsi/pm8001: introduce missing kfree


[Jack]Looks good to me! Thanks!
Acked-by: Jack Wang<jack_wang <at> usish.com>

From: Julia Lawall <julia <at> diku.dk>

Error handling code following a kmalloc should free the allocated data.

The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
 <at> r exists <at> 
local idexpression x;
expression E;
identifier f,f1;
position p1,p2;
 <at>  <at> 

x <at> p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
<... when != x
     when != if (...) { <+...x...+> }
     when != (x) == NULL
     when != (x) != NULL
     when != (x) == 0
     when != (x) != 0
(
x->f1 = E
|
 (x->f1 == NULL || ...)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vladislav Bolkhovitin | 2 Aug 2010 12:38

Re: [RFC] relaxed barrier semantics

Jan Kara, on 07/31/2010 04:47 AM wrote:
> On Fri 30-07-10 16:20:25, Christoph Hellwig wrote:
>> On Fri, Jul 30, 2010 at 05:44:08PM +0400, Vladislav Bolkhovitin wrote:
>>> Yes, but why not to make step further and allow to completely eliminate
>>> the waiting/draining using ORDERED requests? Current advanced storage
>>> hardware allows that.
>>
>> There is a few caes where we could do that - the fsync without metadata
>> changes above would be the prime example.  But there's a lot lower
>> hanging fruit until we get to the point where it's worth trying.
>    Umm, I don't understand you. I think that fsync in particular is an
> example where you have to wait and issue cache flush if the drive has
> volatile write cache. Otherwise you cannot promise to the user data will be
> really on disk in case of crash. So no ordering helps you.

Isn't there the second wait for journal update?

>    And if you are speaking about a drive without volatile write caches, then
> fsync without metadata changes is just trivial and you don't need any
> ordering.

A drive can reorder queued SIMPLE requests at any time doesn't matter if 
it has volatile write caches or not. So, if you expect in-order requests 
execution (with journal updates you do?), you need to enforce that order 
either by ORDERED requests or (local) queue draining.

Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 4 comments |
headers
Christof Schmitt | 2 Aug 2010 13:05
Picon
Favicon

Re: [patch 0/1] Apply segment size and segment boundary to integrity data

On Wed, Jul 21, 2010 at 12:20:01AM -0400, Martin K. Petersen wrote:
> >>>>> "Christof" == Christof Schmitt <christof.schmitt <at> de.ibm.com> writes:
> 
> Christof> To have a simple approach that covers the case with one
> Christof> integrity data segment per user data segment, we only report
> Christof> half the size for the scatterlist length when running
> Christof> DIX. This guarantees that the other half can be used for
> Christof> integrity data.
> 
> Yup, a few of our partners did something similar.
> 
> My concern is the scenario where we submit lots of 512-byte writes that
> get merged into (in your case) 4 KB segments.  Each of those 512-byte
> writes could come with an 8-byte integrity metadata tuple.  And so you'd
> need 8 DI scatterlist elements per data element.
> 
> 
> Christof> Meaning the integrity data sg list would have more entries
> Christof> than max_segments? I have not seen this during my experiments,
> Christof> but then i likely have not hit every case of a possible
> Christof> request layout.
> 
> dd to the block device is usually a good way to issue long scatterlists.
> 
> 
> Christof> Ok, i have to look into that as well. It would be an issue
> Christof> with the approach we are looking at now: If there are
> Christof> max_segments data segments, and more than max_segments
> Christof> integrity data segments, we will overrun the hardware
> Christof> constraint.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christoph Hellwig | 2 Aug 2010 14:48
Picon

Re: [RFC] relaxed barrier semantics

On Mon, Aug 02, 2010 at 02:38:18PM +0400, Vladislav Bolkhovitin wrote:
> >   Umm, I don't understand you. I think that fsync in particular is an
> >example where you have to wait and issue cache flush if the drive has
> >volatile write cache. Otherwise you cannot promise to the user data will be
> >really on disk in case of crash. So no ordering helps you.
> 
> Isn't there the second wait for journal update?

Yes.

> A drive can reorder queued SIMPLE requests at any time doesn't matter if 
> it has volatile write caches or not.

I know.

> So, if you expect in-order requests 
> execution (with journal updates you do?), you need to enforce that order 
> either by ORDERED requests or (local) queue draining.

Yes, exactly what I say.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 3 comments |
headers
Oliver Neukum | 2 Aug 2010 16:36
Picon

Re: [PATCH] usb-storage: implement autosuspend

Am Mittwoch, 28. Juli 2010, 23:12:39 schrieb Alan Stern:
> 
> This patch (as1400) adds runtime-PM support to usb-storage.  It
> utilizes the SCSI layer's runtime-PM implementation, so its scope is
> limited.  Currently the only effect is that disk-like devices (such as
> card readers or flash drives) will be autosuspended if they aren't
> mounted and their device files aren't open.  This would apply, for
> example, to card readers that don't contain a memory card.

So it will autosuspend devices that do contain a medium, which
is not mounted? This is a bit problematic, as some card readers
will report a medium change upon resumption?

How does user space deal with this?

	Regards
		Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Alan Stern | 2 Aug 2010 17:07
Picon
Favicon

Re: [PATCH] usb-storage: implement autosuspend

On Mon, 2 Aug 2010, Oliver Neukum wrote:

> Am Mittwoch, 28. Juli 2010, 23:12:39 schrieb Alan Stern:
> > 
> > This patch (as1400) adds runtime-PM support to usb-storage.  It
> > utilizes the SCSI layer's runtime-PM implementation, so its scope is
> > limited.  Currently the only effect is that disk-like devices (such as
> > card readers or flash drives) will be autosuspended if they aren't
> > mounted and their device files aren't open.  This would apply, for
> > example, to card readers that don't contain a memory card.
> 
> So it will autosuspend devices that do contain a medium, which
> is not mounted? This is a bit problematic, as some card readers
> will report a medium change upon resumption?
> 
> How does user space deal with this?

For the most part it won't matter.  It's rare to open a card reader's 
device file without mounting it.

If it does matter, the user can disable autosuspend (or more 
accurately, avoid enabling it) for that device.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 2 Aug 2010 18:32

Re: 2.6.35-rc6-git6: Reported regressions from 2.6.34

Hello, Linus.

On 08/01/2010 08:01 PM, Linus Torvalds wrote:
> This has a proposed patch. I don't know what the status of it is, though. Jens?
> 
>    http://marc.info/?l=linux-kernel&m=127950018204029&w=2
> 
>> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16393
>> Subject         : kernel BUG at fs/block_dev.c:765!
>> Submitter       : Markus Trippelsdorf <markus <at> trippelsdorf.de>
>> Date            : 2010-07-14 13:52 (19 days old)
>> Message-ID      : <20100714135217.GA1797 <at> arch.tripp.de>
>> References      : http://marc.info/?l=linux-kernel&m=127911564213748&w=2
> 
> This one is interesting. And I think I perhaps see where it's coming from.
> 
> bd_start_claiming() (through bd_prepare_to_claim()) has two separate
> success cases: either there was no holder (bd_claiming is NULL) or the
> new holder was already claiming it (bd_claiming == holder).
> 
> Note in particular the case of the holder _already_ holding it. What happens is:
> 
>  - bd_start_claiming() succeeds because we had _already_ claimed it
> with the same holder
> 
>  - then some error happens, and we call bd_abort_claiming(), which
> does whole->bd_claiming = NULL;
> 
>  - the original holder thinks it still holds the bd, but it has been released!
>
(Continue reading)

Permalink | Reply | 10 comments |

Gmane