Coverity (CID 1929) spotted the following: if a transfer buffer
allocation fails, the last allocated urb is leaked (it hasn't been
stored in dev->urb[] yet so em28xx_uninit_isoc misses it). The patch
also includes a small typo fix.
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
The exception path associated with an invalid ext_csd_struct returns
without freeing ext_csd.
Coverity CID 1909.
Signed-off-by: Florin Malita
---
drivers/mmc/core/mmc.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
.
Coverity CID 1922.
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
drivers/media/video/cx23885/cx23885-core.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/media/video/cx23885/cx23885-core.c
b/drivers/media/video/cx23885/cx23885-core.c
index af16505..3
This fixes a leak in the !mtd->erasesize error path (Coverity 1765).
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
drivers/mtd/rfd_ftl.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/rfd_ftl.c b/drivers/mtd/rfd_ftl.c
index d4b1ba8..006c03a 100644
--- a/dr
Temporarily allocated struct mlx4_qp_context *context is leaked by
several error paths. The patch takes advantage of the return value 'err'
being preinitialized to -EINVAL.
Spotted by Coverity (1768).
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/
Coverity (1769) found the following problem: if the erase counter
overflow check triggers, ec_hdr is leaked.
Moving the allocation after the overflow check should take care of it.
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
drivers/mtd/ubi/scan.c |8
1 file chan
If lpfc_hbq_alloc() fails, an hbq_buffer is leaked. Found by Coverity
(1775).
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
drivers/scsi/lpfc/lpfc_sli.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc
d-off-by: Florin Malita <[EMAIL PROTECTED]>
---
drivers/usb/serial/mos7720.c |5 -
drivers/usb/serial/mos7840.c | 19 ---
2 files changed, 24 deletions(-)
diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
index 231b584..01e811b 100644
--- a/
On 06/15/2007 02:30 PM, Michael Poole wrote:
Florin Malita writes:
On 06/15/2007 12:18 PM, Michael Poole wrote:
Yes. If I cut a book in half and store the halves separately, does
the second half become an independent work?
Except in this case you're not touching the bo
On 06/15/2007 12:18 PM, Michael Poole wrote:
Florin Malita writes:
On 06/15/2007 10:56 AM, Michael Poole wrote:
The GPL cares about the key
used to generate an integral part of the executable form of the GPLed
work.
GLPv2 doesn't: why do you think the digital signature
On 06/15/2007 10:33 AM, Nicolas Mailhot wrote:
Le Ven 15 juin 2007 15:41, Jesper Juhl a écrit :
But the only thing that *actually* matters is what the license text
*says*. It doesn't matter what the authors of the license text
intended
Judges would disagree there
I very much doubt
On 06/15/2007 10:56 AM, Michael Poole wrote:
The GPL cares about the key
used to generate an integral part of the executable form of the GPLed
work.
GLPv2 doesn't: why do you think the digital signature is an integral
part of the executable? It can be a totally separate blob, distributed
vi
On 06/14/2007 05:39 PM, Alexandre Oliva wrote:
On Jun 14, 2007, Florin Malita <[EMAIL PROTECTED]> wrote:
No, it's not: replacing does not create derivative
work. Modification does.
Thanks. Good point. This convinces me that this doesn't work as a
legal argument und
On 06/14/2007 02:27 PM, Alexandre Oliva wrote:
No, by this twisted logic Tivo *cannot* modify that particular copy
any more than you can. They can modify *another* copy (just like you)
and they can *replace* the copy in your device with the new version
(unlike you).
Again, replacing is one
Alexandre Oliva wrote:
On Jun 14, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
When they download the software, they get another copy, and they have
a right to modify that copy.
But you get the TiVO corporations copy of the software?
Yes. The customer gets the copy that Ti
'ioc' should be deallocated if __copy_from_user fails (found by Coverity
- CID 1644).
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
spidev.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index c0a6dce..2464f34 100644
-
n't have to deal with allocation
failures in an error path anymore - something like this (diff against
the original code):
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd/ubi/vtbl.c
index b6fd6bb..2ad2d59 100644
--- a/drivers/mtd/ub
Coverity (CID 1614) spotted new_seb being dereferenced after kfree() in
create_vtbl's write_error path.
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
vtbl.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd
ify_create() trigger in devpts_pty_new().
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
fs/devpts/inode.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
index 643e57b..06ef9a2 100644
--- a/fs/devpts/inode.c
+++ b/f
[EMAIL PROTECTED] wrote:
Anything time stamping things it processes many of will call some sort of
time function pretty often. Could happen frequently with certain classes of
applications.
Right, but if the timestamp granularity is coarse and there's no
blocking call in between it makes no se
On 7/24/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> time() isn't a hot
> path in the real world.
That's what you would expect but I've straced stuff calling
gettimeofday() in huge bursts every other second. Obviously braindead
stuff but so is "the real world" most of the time() ... :)
-
To unsubscri
On 7/24/05, Ciprian <[EMAIL PROTECTED]> wrote:
> test /= 10;
> test *= 10;
> test += 10;
> test -= 10;
You're not trying to benchmark the kernel with those arithmetic
operations are you?! That's completely bogus, the kernel is not
involved in any of that.
As it has been already pointed out, the o
22 matches
Mail list logo
