Brandon Craig Rhodes wrote:
> + if (skb_tailroom(skb) < 4) {
> + int err;
> + err = skb_padto(skb, skb->len + 4);
> + if (unlikely(err || skb_tailroom(skb) < 4)) {
> + printk(KERN_DEBUG "Failed to increase tailroom"
> +
chas williams - CONTRACTOR wrote:
> still generates a warning from gcc though.
The warning is bogus in this case, though -- the only way for "*pcr" to
be unset is when alloc_shaper() returns non-zero
> + *pcr = 0;
You're right, 0 is better than ATM_MAX_PCR here.
-Mitch
-
To unsubscr
Jeff Garzik wrote:
> 1) not safe on 64-bit
Almost certainly correct. Probably never will be -- IIRC this SAR was
mainly used in embedded apps. I don't know if any commercially-available
PCI cards were ever made with it. I could be wrong though, it's been awhile
since I was up on the ATM industr
(cc:'s trimmed again)
Jeff Garzik wrote:
> drivers/atm/ambassador.c: In function ?amb_open?:
> drivers/atm/ambassador.c:1049: warning: ?tx_rate_bits? may be used
> uninitialized in this function
>
> The variable is accessed before the make_rate() error code is checked,
Or rather, the make_rate
(trimmed cc:'s since, IMO, isn't really all that general interest)
Jeff Garzik wrote:
> drivers/atm/zatm.c: In function ?zatm_open?:
> drivers/atm/zatm.c:919: warning: ?pcr? may be used uninitialized in this
> function
Yeah, looks like a bug. Not very high-impact because:
1. it only results i
Erik Mouw wrote:
> On Thu, Apr 13, 2006 at 10:29:19AM -0700, Stephen Hemminger wrote:
> > Shouldn't compiler have gagged on this?
>
> Apparently not. At least the compiler I use doesn't warn about it (gcc
> version 3.3.5 (Debian 1:3.3.5-13)).
>
> Linus, this might be be something for sparse to ch
Jeff Garzik wrote:
> Once packets classified to be delivered to a specific local host socket,
> what further operations are require privs? What received packet data
> cannot be exposed to userspace?
You just need to make sure that you don't leak data from other peoples
sockets. Two issues I se
James Courtier-Dutton wrote:
> When I had the conversation with Matt at KS, the problem we were trying
> to solve was "Memory pressure with network attached swap space".
s/swap space/writable filesystems/
You can hit these problems even if you have no swap. Too much of the
memory becomes filled
Alan Cox wrote:
> But your user space that would add the routes is not so protected so I'm
> not sure this is actually a solution, more of an extended fudge.
Yes, there's no 100% solution -- no matter how much memory you reserve and
how many paths you protect if you try hard enough you can come up
Patrick McHardy wrote:
> -static inline const int before48(const u64 seq1, const u64 seq2)
> +static inline int before48(const u64 seq1, const u64 seq2)
Perhaps "__attribute__ ((const))" is what was meant here?
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the bod
I'm fairly pessimistic about full TOE also, I just want to see the patch
cleaned up a bit so we can see the exact impact it would have. The RX
optimization work presented in the Neterion and Intel papers at OLS sounds a
lot more interesting to me though.
However, I do want to comment on one state
The networking gurus can comment on the internals of your patch better than
I can. Just a few style notes though:
> +#ifdef CONFIG_TCP_OFFLOAD
> +#define NETIF_F_TCPIP_OFFLOAD65536 /* Can offload TCP/IP */
> +#endif
No need to protect this inside CONFIG_* option
> +/* TOE API */
> +#i
12 matches
Mail list logo
