[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080107112951.GC12589@duck.suse.cz>
Date: Mon, 7 Jan 2008 12:29:51 +0100
From: Jan Kara <jack@...e.cz>
To: marcin.slusarz@...il.com
Cc: LKML <linux-kernel@...r.kernel.org>,
Ben Fennema <bfennema@...con.csc.calpoly.edu>
Subject: Re: [PATCH 19/24] udf: check if udf_load_logicalvol failed
On Sun 23-12-07 02:51:09, marcin.slusarz@...il.com wrote:
> udf_load_logicalvol may fail eg in out of memory conditions - check it
> and propagate error further
>
> Signed-off-by: Marcin Slusarz <marcin.slusarz@...il.com>
> CC: Ben Fennema <bfennema@...con.csc.calpoly.edu>
> CC: Jan Kara <jack@...e.cz>
I certainly agree with the idea of the change. Just note that
udf_process_sequence() returns 1 in case of failure so propagating an error
is not ideal - we should keep things consistent. And also note that the
actual value is disregarded in udf_load_partition() anyway.
Honza
> ---
> fs/udf/super.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/fs/udf/super.c b/fs/udf/super.c
> index 4aef612..f8c5794 100644
> --- a/fs/udf/super.c
> +++ b/fs/udf/super.c
> @@ -1141,6 +1141,7 @@ static int udf_process_sequence(struct super_block *sb, long block,
> uint32_t vdsn;
> uint16_t ident;
> long next_s = 0, next_e = 0;
> + int ret;
>
> memset(vds, 0, sizeof(struct udf_vds_record) * VDS_POS_LENGTH);
>
> @@ -1216,7 +1217,11 @@ static int udf_process_sequence(struct super_block *sb, long block,
> if (i == VDS_POS_PRIMARY_VOL_DESC) {
> udf_load_pvoldesc(sb, bh);
> } else if (i == VDS_POS_LOGICAL_VOL_DESC) {
> - udf_load_logicalvol(sb, bh, fileset); /* TODO: check return value */
> + ret = udf_load_logicalvol(sb, bh, fileset);
> + if (ret != 0) {
> + brelse(bh);
> + return ret;
> + }
> } else if (i == VDS_POS_PARTITION_DESC) {
> struct buffer_head *bh2 = NULL;
> if (udf_load_partdesc(sb, bh)) {
--
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists