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:	Thu, 25 Oct 2012 16:49:28 +0200
From:	Tony Cheneau <tony.cheneau@...esiak.org>
To:	Alexander Smirnov <alex.bluesman.smirnov@...il.com>
Cc:	"David S. Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>,
	<linux-zigbee-devel@...ts.sourceforge.net>,
	Alan Ott <alan@...nal11.us>
Subject: Re: [PATCH net-next 00/15] 6lowpan: Some more bug fixes

Hello Alexander,

Thank you for your comments. See my answer inline.

Le 25.10.2012 06:52, Alexander Smirnov a écrit :
> Hi,
>
[...]
> 1. The series is quite huge what makes it difficult for the review. 
> It
> would be better to split it into one-two and submit separately (not
> simultaneously).
OK. Will do.

> 2. Could you also please provide some notes about how have you tested
> these changes (logs, plain text)? Do I need to check your changes
> locally on my desk? If so I need some instructions.
I'm not sure what you are asking here. There was some more debugging 
printk, that I removed because they were too verbose. Mostly, I test my 
patch with few userspace program, like ping6, iperf (both for TCP and 
UDP) and ssh. I also wrote a TCP and a UDP echo server, so as to test 
fragmentation in more details. For most functional patches, I usually 
confirm through wireshark that the packets indeed look the way they 
should (this, I've done it for patch 11 for example). But I don't have 
any automated scripts to check for regression. I can provide you the 
script I use to configure nodes if needed (but it pretty straighward and 
should look like your own scripts).
I'm not sure that really answers your question.

> 3. Please DO NOT submit patches like: this patch fixes blablabla 
> which
> isn't in the kernel yet (like patch 13,15). I have no clue what you
> have locally on your laptop and what you will send in some time. I'd
> like to see here the working code, not a references to TBD.
I'm OK with removing patch 13 (I'll introduce it alongside the serial 
driver later on). I'm not so OK with removing patch 15, or at least, it 
would require some more testing in other parts of the code. Basically, 
the TBD are placeholder for when the Association Request/Response will 
be reimplemented. I introduced it because otherwise, .assoc_req and 
.assoc_resp entries of mac802154_mlme_wpan would go uninitialized and 
would cause kernel crash when called. I could have modified the calling 
code to deal with that, but I thought these primitives were meant to be 
re-implemented soon anyway.

> 4. The reference to linux-zigbee project isn't an occasion for me to
> apply this code to this tree. I have no goal to merge all this fun to
> mainline due to several things in linux-zigbee kernel work NOT
> according to the standard (mostly it's a timing problems) and global
> refactoring needed.
I don't understand what you are talking about here. I would guess that 
you are talking about patch 15. If so, my answer is the following, while 
I understand your effort to refactor linux-zigbee code and fix things 
along the way, some code went through net-next that cause crashes. My 
pragmatic approach is to try to fix it before more people use it, even 
through it might not always be the most elegant way to do it.

Regards,
Tony
--
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