Jay Vosburgh writes:
> Michael J Dilmore wrote:
>
>>if (WARN_ON(!new_active_slave) {
>>netdev_dbg("Can't add new active slave - pointer null");
>>return ERROR_CODE
>>}
>
> In general, yes, but in this case, the condition should be
> impossible to hit, so BUG_ON seems appropriate.
I
On Thu, Jun 22, 2017 at 12:04:54AM +0100, Michael J Dilmore wrote:
>
> Is it worth at least wrapping BUG_ON in an unlikely macro then?
See BUG_ON() definition:
#ifndef HAVE_ARCH_BUG_ON
#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
#endif
where HAVE_ARCH_BUG_ON is de
On 21/06/17 23:39, Jay Vosburgh wrote:
Michael J Dilmore wrote:
On 21/06/17 22:56, David Miller wrote:
From: Michael D
Date: Wed, 21 Jun 2017 22:41:07 +0100
I don't think you can stop it being dereferenced... you just need to
prevent an attacker from exploiting the null pointer dereferenc
Michael J Dilmore wrote:
>On 21/06/17 22:56, David Miller wrote:
>
>> From: Michael D
>> Date: Wed, 21 Jun 2017 22:41:07 +0100
>>
>>> I don't think you can stop it being dereferenced... you just need to
>>> prevent an attacker from exploiting the null pointer dereference
>>> vulnerability right?
David Miller wrote:
>From: Michael D
>Date: Wed, 21 Jun 2017 22:41:07 +0100
>
>> I don't think you can stop it being dereferenced... you just need to
>> prevent an attacker from exploiting the null pointer dereference
>> vulnerability right? And this is done by returning the function right
>> aw
On 21/06/17 22:56, David Miller wrote:
From: Michael D
Date: Wed, 21 Jun 2017 22:41:07 +0100
I don't think you can stop it being dereferenced... you just need to
prevent an attacker from exploiting the null pointer dereference
vulnerability right? And this is done by returning the function ri
From: Michael D
Date: Wed, 21 Jun 2017 22:41:07 +0100
> I don't think you can stop it being dereferenced... you just need to
> prevent an attacker from exploiting the null pointer dereference
> vulnerability right? And this is done by returning the function right
> away?
What's all of this about
And please stop top posting, thank you.
I don't think you can stop it being dereferenced... you just need to
prevent an attacker from exploiting the null pointer dereference
vulnerability right? And this is done by returning the function right
away?
On 21 June 2017 at 22:36, David Miller wrote:
> From: Michael D
> Date: Wed, 21 Ju
From: Michael D
Date: Wed, 21 Jun 2017 22:35:56 +0100
> How do we actually stop a null pointer being dereferenced here?
Maybe that's why it's a BUG_ON(), there is no reasonable way
to continue if the pointer is NULL.
How do we actually stop a null pointer being dereferenced here? Other
examples I've seen check for null and then immediately return the
function with an error code so that it cannot be referenced again.
Something like:
if (WARN_ON(!new_active)
return 1
This behaviour should be OK for this f
Michael J Dilmore wrote:
>The function below contains a BUG_ON where no active slave is detected. The
>patch
>converts this to a WARN_ON to avoid crashing the kernel.
>
>Signed-off-by: Michael J Dilmore
>---
> drivers/net/bonding/bond_options.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletio
The function below contains a BUG_ON where no active slave is detected. The
patch
converts this to a WARN_ON to avoid crashing the kernel.
Signed-off-by: Michael J Dilmore
---
drivers/net/bonding/bond_options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bond
13 matches
Mail list logo
