pj wrote:
> Check out the assembly code generated by:
>
> BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX));
>
> (Hint: you can't find it ;)
>
> It -is- compile time!
To be clear, BUG_ON() in general is a runtime check.
But the compiler can optimize out constant expressions,
and
On Thu, Oct 25, 2007 at 06:24:25PM -0700, Paul Jackson wrote:
> Paul M wrote:
> > Sounds reasonable to me. Is there any kind of compile-time assert
> > macro in the kernel?
>
> Check out the assembly code generated by:
>
> BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX));
>
>
On 10/25/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Paul M wrote:
> > Sounds reasonable to me. Is there any kind of compile-time assert
> > macro in the kernel?
>
> Check out the assembly code generated by:
>
> BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX));
>
> (Hint: you can't
Paul M wrote:
> Sounds reasonable to me. Is there any kind of compile-time assert
> macro in the kernel?
Check out the assembly code generated by:
BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX));
(Hint: you can't find it ;)
It -is- compile time!
--
I won't
On Thu, Oct 25, 2007 at 06:10:24PM -0700, Paul Menage wrote:
> On 10/24/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> > Paul M wrote:
> > > I think I'd rather not make this change - if we later changed the size
> > > of release_agent_path[] this could silently fail. Can we get around
> > > the
On 10/24/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Paul M wrote:
> > I think I'd rather not make this change - if we later changed the size
> > of release_agent_path[] this could silently fail. Can we get around
> > the coverity checker somehow?
>
> Perhaps we can simplify this check then, to:
On 10/24/07, Paul Jackson [EMAIL PROTECTED] wrote:
Paul M wrote:
I think I'd rather not make this change - if we later changed the size
of release_agent_path[] this could silently fail. Can we get around
the coverity checker somehow?
Perhaps we can simplify this check then, to:
On Thu, Oct 25, 2007 at 06:10:24PM -0700, Paul Menage wrote:
On 10/24/07, Paul Jackson [EMAIL PROTECTED] wrote:
Paul M wrote:
I think I'd rather not make this change - if we later changed the size
of release_agent_path[] this could silently fail. Can we get around
the coverity checker
Paul M wrote:
Sounds reasonable to me. Is there any kind of compile-time assert
macro in the kernel?
Check out the assembly code generated by:
BUG_ON(sizeof(cgrp-root-release_agent_path) PATH_MAX));
(Hint: you can't find it ;)
It -is- compile time!
--
I won't rest
On 10/25/07, Paul Jackson [EMAIL PROTECTED] wrote:
Paul M wrote:
Sounds reasonable to me. Is there any kind of compile-time assert
macro in the kernel?
Check out the assembly code generated by:
BUG_ON(sizeof(cgrp-root-release_agent_path) PATH_MAX));
(Hint: you can't find it ;)
It
On Thu, Oct 25, 2007 at 06:24:25PM -0700, Paul Jackson wrote:
Paul M wrote:
Sounds reasonable to me. Is there any kind of compile-time assert
macro in the kernel?
Check out the assembly code generated by:
BUG_ON(sizeof(cgrp-root-release_agent_path) PATH_MAX));
(Hint: you can't
pj wrote:
Check out the assembly code generated by:
BUG_ON(sizeof(cgrp-root-release_agent_path) PATH_MAX));
(Hint: you can't find it ;)
It -is- compile time!
To be clear, BUG_ON() in general is a runtime check.
But the compiler can optimize out constant expressions,
and code
Paul M wrote:
> I think I'd rather not make this change - if we later changed the size
> of release_agent_path[] this could silently fail. Can we get around
> the coverity checker somehow?
Perhaps we can simplify this check then, to:
BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX));
On 10/24/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> Two questions:
> - Is it really intended to perhaps change release_agent_path[] to have
> less than PATH_MAX size?
I've got no intention to do so currently.
> - If yes, do you want to return -E2BIG for (nbytes >= PATH_MAX) or for
>
On Wed, Oct 24, 2007 at 09:30:23AM -0700, Paul Menage wrote:
> I think I'd rather not make this change - if we later changed the size
> of release_agent_path[] this could silently fail. Can we get around
> the coverity checker somehow?
I do not care what the Coverity checker thinks about the
I think I'd rather not make this change - if we later changed the size
of release_agent_path[] this could silently fail. Can we get around
the coverity checker somehow?
Paul
On 10/24/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch removes dead code spotted by the Coverity checker
> (look
This patch removes dead code spotted by the Coverity checker
(look at the "(nbytes >= PATH_MAX)" check).
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
kernel/cgroup.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
--- linux-2.6/kernel/cgroup.c.old
This patch removes dead code spotted by the Coverity checker
(look at the (nbytes = PATH_MAX) check).
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
kernel/cgroup.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
--- linux-2.6/kernel/cgroup.c.old 2007-10-23
I think I'd rather not make this change - if we later changed the size
of release_agent_path[] this could silently fail. Can we get around
the coverity checker somehow?
Paul
On 10/24/07, Adrian Bunk [EMAIL PROTECTED] wrote:
This patch removes dead code spotted by the Coverity checker
(look at
On Wed, Oct 24, 2007 at 09:30:23AM -0700, Paul Menage wrote:
I think I'd rather not make this change - if we later changed the size
of release_agent_path[] this could silently fail. Can we get around
the coverity checker somehow?
I do not care what the Coverity checker thinks about the code,
On 10/24/07, Adrian Bunk [EMAIL PROTECTED] wrote:
Two questions:
- Is it really intended to perhaps change release_agent_path[] to have
less than PATH_MAX size?
I've got no intention to do so currently.
- If yes, do you want to return -E2BIG for (nbytes = PATH_MAX) or for
(nbytes =
Paul M wrote:
I think I'd rather not make this change - if we later changed the size
of release_agent_path[] this could silently fail. Can we get around
the coverity checker somehow?
Perhaps we can simplify this check then, to:
BUG_ON(sizeof(cgrp-root-release_agent_path) PATH_MAX));
Less
22 matches
Mail list logo
