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]
Message-ID: <20101109142208.GB18269@hmsreliant.think-freely.org>
Date:	Tue, 9 Nov 2010 09:22:08 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	Mike Waychison <mikew@...gle.com>
Cc:	simon.kagstrom@...insight.net, davem@...emloft.net,
	Matt Mackall <mpm@...enic.com>, adurbin@...gle.com,
	linux-kernel@...r.kernel.org, chavey@...gle.com,
	Greg KH <greg@...ah.com>,
	Américo Wang <xiyou.wangcong@...il.com>,
	akpm@...ux-foundation.org, linux-api@...r.kernel.org
Subject: Re: [PATCH v2 20/23] netoops: Add x86 specific bits to packet headers

On Mon, Nov 08, 2010 at 12:33:35PM -0800, Mike Waychison wrote:
> We need to be able to gather information about the CPUs that caused the crash.
> 
> This commit only handles x86, but it is desirable to come up with some new
> packet format that can accommodate any architecture.
> 
> Signed-off-by: Mike Waychison <mikew@...gle.com>
> ---
> TODO: This should be made more general to other architectures.  As is, we are
> probably okay exporting some value for the 'arch' field.  Different
> architectures though will likely want to gather different data.
> ---
>  drivers/net/netoops.c |   27 +++++++++++++++++++++------
>  1 files changed, 21 insertions(+), 6 deletions(-)
> 
Not sure I see the value in encapsulating arch specific data in a netoops
message.  Ostensibly this information can be inferred at the time of the crash
by the name/ip of the system crashing (one presumes that the sysadmin knows what
systems are what arch, or can look it up easily).

If thats not the case, why not just dump out the contents of /proc/cpuinfo in
ascii form, so that no arch specific data is needed?

Regards
Neil

> diff --git a/drivers/net/netoops.c b/drivers/net/netoops.c
> index dc1ee97..f63e12a 100644
> --- a/drivers/net/netoops.c
> +++ b/drivers/net/netoops.c
> @@ -69,16 +69,24 @@ struct netoops_msg {
>  		u32 packet_count;
>  		u32 packet_no;
>  		u32 __reserved1;
> -		u8 __reserved2;
> -		u8 __reserved3;
> -		u8 __reserved4;
> +		u8 x86_family;
> +		u8 x86_model;
> +		u8 x86_stepping;
>  		/*
>  		 * NOTE: fixed length strings for a packet.  NULL
>  		 * termination not required.
>  		 */
>  		char kernel_version[64];
> -		char __reserved5[64];
> -		char __reserved6[64];
> +		char __reserved2[64];
> +		char __reserved3[64];
> +		/* NOTE: regs is 60 or 168 bytes */
> +		struct pt_regs regs; /* arch specific. */
> +		/*
> +		 * NOTE: The header is potentially ~385 bytes
> +		 * already.  That doesn't leave much room for
> +		 * expansion unless we reduce the data size
> +		 * or truncate above fields.
> +		 */
>  	} __attribute__ ((packed)) header;
>  	char data[NETOOPS_DATA_BYTES];
>  } __attribute__ ((packed));
> @@ -94,10 +102,17 @@ static void setup_packet_header(int packet_count, int soft_dump)
>  	msg.header.dump_id = (jiffies/HZ) & 0xffff;
>  	msg.header.packet_count = packet_count;
>  	msg.header.header_size = sizeof(msg.header);
> +#ifndef CONFIG_UML
> +	msg.header.x86_family = current_cpu_data.x86;
> +	msg.header.x86_model = current_cpu_data.x86_model;
> +	msg.header.x86_stepping = current_cpu_data.x86_mask;
> +#endif
>  	strncpy(msg.header.kernel_version,
>  		utsname()->release,
>  		min(sizeof(msg.header.kernel_version),
>  		    sizeof(utsname()->release)));
> +	if (regs != NULL)
> +		memcpy(&msg.header.regs, regs, sizeof(msg.header.regs));
>  }
>  
>  static int packet_count_from_length(unsigned long l)
> @@ -182,7 +197,7 @@ static void netoops(struct kmsg_dumper *dumper, enum kmsg_dump_reason reason,
>  
>  	/* setup the non varying parts of the message */
>  	memset(&msg, 0, sizeof(msg));
> -	setup_packet_header(packet_count_1 + packet_count_2, soft_dump);
> +	setup_packet_header(packet_count_1 + packet_count_2, regs, soft_dump);
>  
>  	/* Transmission loop */
>  	for (i = 0; i < NETOOPS_RETRANSMIT_COUNT; i++) {
> 
> 
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ