lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 1 Apr 2015 12:46:15 +0200 From: Jan Kara <jack@...e.cz> To: Changwoo Min <changwoo.m@...il.com> Cc: jack@...e.cz, linux-kernel@...r.kernel.org, taesoo@...ech.edu, changwoo@...ech.edu, sanidhya@...ech.edu, blee@...ech.edu, csong84@...ech.edu Subject: Re: [PATCH] udf: return correct errno for udf_update_inode() On Sun 22-03-15 19:17:49, Changwoo Min wrote: > Instead of -ENOMEM, properly return -EIO udf_update_inode() > error, similar/consistent to the rest of filesystems. > > Signed-off-by: Changwoo Min <changwoo.m@...il.com> So I actually had a look how we treat results from udf_tgetblk(). The truth is: Once we return ENOMEM. Once we return EIO. Once we just return NULL from the function and it will get eventually translated to something like EIO. Once we just crash. Twice we just ignore the problem (as it is during readahead). So saying there is any consistency among the callers of udf_tgetblk() is just wrong. But looking into when getblk() can fail to return the buffer, EIO is probably a better return value. So I've take the patch. Honza > > --- > fs/udf/inode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/udf/inode.c b/fs/udf/inode.c > index a445d59..c758023 100644 > --- a/fs/udf/inode.c > +++ b/fs/udf/inode.c > @@ -1637,7 +1637,7 @@ static int udf_update_inode(struct inode *inode, int do_sync) > udf_get_lb_pblock(inode->i_sb, &iinfo->i_location, 0)); > if (!bh) { > udf_debug("getblk failure\n"); > - return -ENOMEM; > + return -EIO; > } > > lock_buffer(bh); > -- > 1.9.1 > -- 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