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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090621.225018.185805046.davem@davemloft.net>
Date:	Sun, 21 Jun 2009 22:50:18 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	lk-netdev@...netdev.nosense.org
Cc:	fw@...len.de, netdev@...r.kernel.org
Subject: Re: [PATCH] econet: have failed ec_queue_packet() call return
 NET_RX_BAD

From: Mark Smith <lk-netdev@...netdev.nosense.org>
Date: Sat, 20 Jun 2009 20:50:26 +0930

> On Sat, 20 Jun 2009 12:53:25 +0200
> Florian Westphal <fw@...len.de> wrote:
> 
>> Mark Smith <lk-netdev@...netdev.nosense.org> wrote:
>> > econet_rcv() calls ec_queue_packet(). The return from ec_queue_packet()
>> > is the direct result of a call to sock_queue_rcv_skb(). Error returns
>> > from ec_queue_packet() and therefore sock_queue_rcv_skb() are due to
>> > kernel errors, so have econet_rcv() return NET_RX_BAD in this case.
>> 
>> What about doing this instead?
> 
> I think there is value in distinguishing between network/protocol
> errors and kernel errors. It helps determine where the fault might lie
> - in the network somewhere, or isolated to the receiving host. In
> larger organisations there is typically a networks support team and a
> hosts/sys admin team. Hints such as this that help determine who's
> problem the fault is to deal with can be a big time saver (being a
> networking person on one of these sorts of teams, I'm scrathing an
> itch :-) )
> 
> If these econet patches are accepted, I'll send through similar patches
> for the other protocols in the kernel where necessary.

Indeed I bet whoever added NET_RX_BAD thought the distinction had
value too.

But it's been there for many years, and:

1) almost nobody sets it

2) nothing really acts upon or reports it specially

and if after all that time these two things are still true, then
it's obviously worthless in reality.

Therefore my inclination is to apply Florian's patch once the
merge window closes and the next-next-net-2.6 stuff starts getting
applied :-)

You can submit the econet stuff relative to that if you like.  But
I wonder Mark, are you actually using that protocol? :-)


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ