netdev - Re: [PATCH] ethtool: Support arbitrary speeds

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:	Fri, 09 Jan 2009 09:55:55 -0800
From:	Rick Jones <rick.jones2@...com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	Jeff Garzik <jgarzik@...ox.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] ethtool: Support arbitrary speeds

Ben Hutchings wrote:
> The speed and speed_hi fields of struct ethtool_cmd together represent
> a value in units of Mbit/s.  The valid speed settings are hardware-
> dependent and should be checked by the driver.  Remove our validation
> and allow arbitrary positive values.  Continue to report 0 and -1 as
> "Unknown!" since some drivers will report these invalid values when
> the link is down.
> 
> Signed-off-by: Ben Hutchings <bhutchings@...arflare.com>
> ---
> On Thu, 2009-01-08 at 11:50 -0800, Rick Jones wrote:
> 
>>>I think 0, (u32)(-1) and (u16)(-1) may have to be special-cased as
>>>unknown, but everything else can be treated as a number of Mbit/s.  I
>>>don't know what a driver should do about an interface that really runs
>>>at 65.535 Gbit/s though...
>>
>>Something along these lines then? (assuming my mailer doesn't fubar this
>>:( - I normally send matches via mailx)
> 
> 
> That's kind of incomplete.  Here's my attempt.
> 
> In a quick test I found that the tg3 driver *doesn't* validate the speed
> setting if autonegotiation is off, and will accept and report back e.g.
> 99.  But this patch doesn't create a new problem as you could already
> set it to the unsupported speeds of 2500 and 10000.

I'm fine with yanking the vetting on set - didn't do it initially 
because what got me patching in the first place does the setting of the 
speeds "elsewhere" so set support wasn't an issue.

WRT the get part:

> @@ -893,30 +884,17 @@ static void dump_advertised(struct ethtool_cmd *ep)
>  
>  static int dump_ecmd(struct ethtool_cmd *ep)
>  {
> +	u32 speed;
> +
>  	dump_supported(ep);
>  	dump_advertised(ep);
>  
>  	fprintf(stdout, "	Speed: ");
> -	switch (ethtool_cmd_speed(ep)) {
> -	case SPEED_10:
> -		fprintf(stdout, "10Mb/s\n");
> -		break;
> -	case SPEED_100:
> -		fprintf(stdout, "100Mb/s\n");
> -		break;
> -	case SPEED_1000:
> -		fprintf(stdout, "1000Mb/s\n");
> -		break;
> -	case SPEED_2500:
> -		fprintf(stdout, "2500Mb/s\n");
> -		break;
> -	case SPEED_10000:
> -		fprintf(stdout, "10000Mb/s\n");
> -		break;
> -	default:
> -		fprintf(stdout, "Unknown! (%i)\n", ethtool_cmd_speed(ep));
> -		break;
> -	};
> +	speed = ethtool_cmd_speed(ep);
> +	if (speed == 0 || speed == (u16)(-1) || speed == (u32)(-1))
> +		fprintf(stdout, "Unknown!\n");

Doesn't that need to keep the reporting of the unknown speed in parens 
like the original?

rick jones
--
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