On Thu, 2012-10-18 at 20:55 -0700, Joe Perches wrote:
> ethernet, ipv4, and ipv6 address testing uses 3 different api naming styles.
>
> ethernet uses:is__ether_addr
> ipv4 uses:ipv4_is_
> ipv6 uses:ipv6_addr_
>
> Standardize on the ipv6 style of _addr_ to reduce
> the number of s
On Wed, 2013-06-05 at 14:11 -0700, Tejun Heo wrote:
> (cc'ing wireless crowd, tglx and Ingo. The original thread is at
> http://thread.gmane.org/gmane.linux.kernel/1500158/focus=55005 )
>
> Hello, Ben.
>
> On Wed, Jun 05, 2013 at 01:58:31PM -0700, Ben Greear wrote:
> > Hmm, wonder if I found it
On Wed, 2013-06-05 at 20:14 -0700, Tejun Heo wrote:
>
> Ah, so, that's why it's showing up now. We probably have had the same
> issue all along but it used to be masked by the softirq limiting. Do
> you care to revive the 10 iterations limit so that it's limited by
> both the count and timing?
On Wed, 2013-06-05 at 20:50 -0700, Ben Greear wrote:
> On 06/05/2013 08:46 PM, Eric Dumazet wrote:
> >
> > We use in Google a patch triggering warning is a thread holds the cpu
> > without taking care to need_resched() for more than xx ms
>
> Well, I'm sure that pa
On Wed, 2013-06-05 at 20:41 -0700, Ben Greear wrote:
> On 06/05/2013 08:26 PM, Eric Dumazet wrote:
> > On Wed, 2013-06-05 at 20:14 -0700, Tejun Heo wrote:
> >
> >>
> >> Ah, so, that's why it's showing up now. We probably have had the same
> >
On Tue, 2015-03-03 at 12:24 +0800, Fred Chou wrote:
> From: Fred Chou
>
> The temporary buffer to hold firmware data is not really needed,
> and memcpy can be avoided by using data pointer instead.
>
> Signed-off-by: Fred Chou
> ---
> drivers/net/wireless/ath/ath9k/hif_usb.c | 12 ++--
Le jeudi 06 janvier 2011 à 16:05 -0800, Luis R. Rodriguez a écrit :
> Eric, also please make sure you read and understand what using a SOB means:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159a
looks like it was originally reported against 2.6.35-rc1. Eric Dumazet
> > provided a patch which fixed the issue, but apparently it's still not
> > upstream. Why is this?
> >
> > If it is suitable for upstream inclusion, please take my Tested-by:
> > Matt Turner
>
Le vendredi 07 janvier 2011 à 02:04 +0100, Christian Lamparter a écrit :
> On Friday 07 January 2011 01:46:03 gree...@candelatech.com wrote:
> > From: Ben Greear
> >
> > Patch is from Eric Dumazet, as described here:
> > https://patchwork.kernel.org/patch/104271/
&g
Le jeudi 06 janvier 2011 à 17:57 -0800, Luis R. Rodriguez a écrit :
> On Thu, Jan 6, 2011 at 5:23 PM, Eric Dumazet wrote:
> > Le vendredi 07 janvier 2011 à 02:04 +0100, Christian Lamparter a écrit :
> >> On Friday 07 January 2011 01:46:03 gree...@candelatech.com wrote:
>
Le jeudi 06 janvier 2011 à 18:13 -0800, Luis R. Rodriguez a écrit :
> On Thu, Jan 6, 2011 at 6:07 PM, Eric Dumazet wrote:
> The only way to accept your patch is to use a debugfs option to
> disable it, we need AMSDU support enabled by default.
>
I dont care of my patch ;)
There i
Le vendredi 07 janvier 2011 à 03:24 +0100, Eric Dumazet a écrit :
> Given IEEE80211_MAX_MPDU_LEN is more than 3840, and skb shinfo adds more
> than 256 bytes, I can assert rx_bufsize is greater than 4096 : order-1
On 64bit arches :
sizeof(struct skb_shared_info) = 0x198
Ben Greear
> > >>
> > >> Patch is from Eric Dumazet, as described here:
> > >> https://patchwork.kernel.org/patch/104271/
> > >>
> > >> Reported-by: Michael Guntsche
> > >> Signed-off-by: Eric Dumazet
> > >> Signed
Le vendredi 07 janvier 2011 à 14:20 -0800, Ben Greear a écrit :
> On 0
> > Using skb_copy() is wrong then, since it makes a copy (order-1
> > allocations)
> >
> > It should use :
> > skb_alloc( actual_size_of_frame not the 3840 thing ...)
> > copy(data)
>
> We need the extra stuff copied too
14 matches
Mail list logo
