From: Timo Lindhorst <lindhors@linux.vnet.ibm.com>
To: dedekind@infradead.org
Cc: MTD list <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH] [MTD] UBI: Fix counting of ec value
Date: Mon, 12 Feb 2007 11:48:28 +0100 [thread overview]
Message-ID: <45D045FC.7090902@linux.vnet.ibm.com> (raw)
In-Reply-To: <1171273959.17314.16.camel@sauron>
Hi Artem,
>>+ ec_hdr = ubi_zalloc_ec_hdr(ubi);
>>+ if (unlikely(!ec_hdr))
>>+ return -ENOMEM;
>
>
> So why have you moved this memory allocation here?
Actually I have not moved up the allocation, but moved down the
'if (unlikely(ec > UBI_MAX_ERASECOUNTER)) { ... ' block, since we need
to know the new ec value before we can do this test.
I thought you want the allocation to be done before erasure, to prevent
the erasure if the ec_hdr cannot be written due to a failure of memory
allocation.
Otherwise, the allocation can be moved down again, but than the new ec
is possibly not written to the EB if no memory can be allocated for ec_hdr.
Do I miss something? What do you think?
>>+
>>+ ret = err = ubi_io_sync_erase(ubi, e->pnum, torture);
>>+ if (unlikely(err < 0))
>>+ goto out_free;
>>+
>>+ ec += ret;
>
> What's the point in the new 'ret' variable? Why ec += err does not work?
I just thought adding an error code to a counter seems odd. Do you
prefer this way?
>
>> if (unlikely(ec > UBI_MAX_ERASECOUNTER)) {
>> /*
>> * Erase counter overflow. Upgrade UBI and use 64-bit
>> * erase counters internally.
>> */
>> ubi_err("erase counter overflow at PEB %d, EC %d",
>>- e->pnum, e->ec);
>>+ e->pnum, ec);
>> return -EINVAL;
>
> And now you do not free memory.
Yes, sorry! I have changed it to:
err = -EINVAL;
goto out_free;
}
I will resend the patch when I have got your comments to the upper points.
Kind regards,
Timo
next prev parent reply other threads:[~2007-02-12 10:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-12 9:16 [PATCH] [MTD] UBI: Fix counting of ec value Timo Lindhorst
2007-02-12 9:52 ` Artem Bityutskiy
2007-02-12 10:48 ` Timo Lindhorst [this message]
2007-02-12 11:38 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45D045FC.7090902@linux.vnet.ibm.com \
--to=lindhors@linux.vnet.ibm.com \
--cc=dedekind@infradead.org \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox