linux-kernel - Re: Must check what?

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 4 Oct 2006 23:47:17 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Andrew Morton <akpm@...l.org>
Cc:	Matthew Wilcox <matthew@....cx>, linux-kernel@...r.kernel.org
Subject: Re: Must check what?

On Oct 04, 2006, at 15:43:10, Andrew Morton wrote:
> (Or we do
>
> 	return assert_zero_or_errno(ret);
>
> which is a bit ug, but gets us there)

I'm personally a big fan of:

   typedef int kerr_t;
   # define kreterr_t kerr_t __must_check

Then:

   kreterr_t some_device_function(void *data)
   {
   	kerr_t result;
   	if (!data)
   		return -EINVAL;
   	result = other_device_function(data + sizeof(struct foo));
   	[...]
   	return result;
   }

You could even tag __bitwise on kerr_t except that wouldn't work  
nicely with returning a negative error code.  Is there any way to  
tell sparse that:

   -ESOMECODE => -((__force kerr_t)3)

is ok when kerr_t is a bitwise type, without allowing any other math  
operations?

Alternatively you could:

   #ifdef __KERNEL__
   # define KENOENT ((__force kerr_t) -ENOENT)
   # define KENOMEM ((__force kerr_t) -ENOMEM)
   [...]
   #endif

But that's a _lot_ of code churn for fairly minimal gain.  It might  
be easier just to patch sparse to add an errcode type attribute with  
the desired behavior.  There also might be some way to do it with  
enums but I'm not familiar enough with the exact GCC behavior to  
comment.

Cheers,
Kyle Moffett
-
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/