Re: [PATCH] net: neigh: disallow state transition DELAY->STALE in neigh_update()
Hi, Chunhui He wrote: > Hi, > > On Fri, 22 Jul 2016 10:20:01 +0300 (EEST), Julian Anastasov > wrote: >> >> Hello, >> >> On Thu, 21 Jul 2016, Chunhui He wrote: >> >>> If neigh entry was CONNECTED and address is not changed, and if new state is >>> STALE, entry state will not change. Because DELAY is not in CONNECTED, it's >>> possible to change state from DELAY to STALE. >>> >>> That is bad. Consider a host in IPv4 nerwork, a neigh entry in STALE state >>> is referenced to send packets, so goes to DELAY state. If the entry is not >>> confirmed by upper layer, it goes to PROBE state, and sends ARP request. >>> The neigh host sends ARP reply, then the entry goes to REACHABLE state. >>> But the entry state may be reseted to STALE by broadcast ARP packets, before >>> the entry goes to PROBE state. So it's possible that the entry will never go >>> to REACHABLE state, without external confirmation. >>> >>> In my case, the gateway refuses to send unicast packets to me, before it >>> sees >>> my ARP request. So it's critical to enter REACHABLE state by sending ARP >>> request, but not by external confirmation. >>> >>> This fixes neigh_update() not to change to STALE if old state is CONNECTED >>> or >>> DELAY. >>> >>> Signed-off-by: Chunhui He >>> --- >>> net/core/neighbour.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/net/core/neighbour.c b/net/core/neighbour.c >>> index 510cd62..29429eb 100644 >>> --- a/net/core/neighbour.c >>> +++ b/net/core/neighbour.c >>> @@ -1152,7 +1152,7 @@ int neigh_update(struct neighbour *neigh, const u8 >>> *lladdr, u8 new, >>> } else { >>> if (lladdr == neigh->ha && new == NUD_STALE && >>> ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) || >>> -(old & NUD_CONNECTED)) >>> +(old & (NUD_CONNECTED | NUD_DELAY))) >>> ) >>> new = old; >>> } >> >> You change looks correct to me. But this place >> has more problems. There is no good reason to set NUD_STALE >> for any state that is NUD_VALID if address is not changed. >> This matches perfectly the comment above this code: >> NUD_STALE should change a NUD_VALID state only when >> address changes. It also means that IPv6 does not need >> to provide NEIGH_UPDATE_F_WEAK_OVERRIDE anymore when >> NEIGH_UPDATE_F_OVERRIDE is also present. >> > > The NEIGH_UPDATE_F_WEAK_OVERRIDE is confusing to me, so I choose not to deal > with the flag. IPv6 depends on WEAK_OVERRIDE. Please do not change. > >> By this way the state machine can continue with >> the resolving: NUD_STALE -> NUD_DELAY (traffic) -> >> NUD_PROBE (retries) -> NUD_REACHABLE (unicast reply) >> while the address is not changed. Your change covers only >> NUD_DELAY, not NUD_PROBE, so it is better to allow more >> retries to send. We should not give up until success (NUD_REACHABLE). >> > > I have thought about this. > The origin code allows NUD_DELAY -> NUD_STALE and NUD_PROBE -> NUD_STALE. > This part was imported to kernel since v2.1.79, I don't know clearly why it > allows that. > > My analysis: > (1) As shown in my previous mail, NUD_DELAY -> NUD_STALE may cause "dead > loop", > so it should be fixed. > > (2) But NUD_PROBE -> NUD_STALE is acceptable, because in NUD_PROBE, ARP > request > has been sent, it is sufficient to break the "dead loop". > More attempts are accomplished by the following sequence: > NUD_STALE --> NUD_DELAY -(sent req)-> NUD_PROBE -(reset by neigh_update())-> > NUD_STALE --> NUD_DELAY -(send req again)-> ... --> > NUD_REACHABLE > > > But I also agree your change. > >> Second problem: NEIGH_UPDATE_F_WEAK_OVERRIDE has no >> priority over NEIGH_UPDATE_F_ADMIN. For example, now I can not >> change from NUD_PERMANENT to NUD_STALE: >> >> # ip neigh add 192.168.168.111 lladdr 00:11:22:33:44:55 nud perm dev wlan0 >> # ip neigh show to 192.168.168.111 >> 192.168.168.111 dev wlan0 lladdr 00:11:22:33:44:55 PERMANENT >> # ip neigh change 192.168.168.111 lladdr 00:11:22:33:44:55 nud stale dev >> wlan0 >> # ip neigh show to 192.168.168.111 >> 192.168.168.111 dev wlan0 lladdr 00:11:22:33:44:55 PERMANENT >> >> IMHO, here is how this place should look: >> >> diff --git a/net/core/neighbour.c b/net/core/neighbour.c >> index 5cdc62a..2b1cb91 100644 >> --- a/net/core/neighbour.c >> +++ b/net/core/neighbour.c >> @@ -1151,10 +1151,8 @@ int neigh_update(struct neighbour *neigh, const u8 >> *lladdr, u8 new, >> goto out; >> } else { >> if (lladdr == neigh->ha && new == NUD_STALE && >> -((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) || >> - (old & NUD_CONNECTED)) >> -) >> -new = old; >> +!(flags & NEIGH_UPDATE_F_ADMIN)) >> +goto out; >> } >>
Re: [PATCH] ipv6: Fixed source specific default route handling.
Matthias Schiffer wrote: > On 06/22/2015 07:58 AM, Steven Barth wrote: >> On 22.06.2015 00:35, Matthias Schiffer wrote: >>> Could you explain in detail what you mean with "If you want specific SA, >>> add same route with higher metric and/or (more) specific src match."? >>> Routes aren't bound to specific addresses except via the "src" attribute >>> (which is called prefsrc in the kernel), which is exactly what it not >>> working. I can't control the chosen source address at all when >>> source-specific routes are involved. >> Except that prefsrc and src are two different beasts and usually ip route >> from transates to >> RTA_SRC instead of RTA_PREFSOURCE when used with a prefix length. >> >> Try adding two routes to the same destination with the same metric but >> different source values with PREFSRC (e.g. IPv4) and then >> try doing the same with SRC (e.g. IPv6). The former will fail but the latter >> will succeed. > > Ah sorry, I didn't know that "src" and "prefsrc" were distinct concepts. > I meant to refer to "src" whenever I wrote "prefsrc". What are the > precise semantics of the "src" attribute? Any RFC I can read, or is this > a Linux-specific concept? > "src" is long-lived feature which is usually used with mutiple routing tables by "ip rule". --yoshfuji >> >> >> https://tools.ietf.org/html/draft-troan-homenet-sadr-01 >> was the original draft for source-address dependent routing IIRC so might be >> a good read. > > Thanks for the link, that helps a bit. > >> >> >>> >>> Even though the source-specific route has a higher metric than the >>> generic one, the source-specific one shadows the generic route. >> >> (was a bit ago since I read into this so please correct me if I am wrong) >> IIRC this is intentional since longest-prefix-match beats metric here >> and the source-address match counts to being more-specific here. See also >> above difference between PREFSRC and SRC. > > Ah, that would explain the metric issue. I looks like the source of my > confusion is that for source-specific routes *all* addresses are in the > candidate set, not only the addresses of the outgoing interface (which > makes sense as ip6_route_get_saddr() is called with a NULL rt6_info in > the source-specific case). > > I'm not sure if this can be fixed in a sane way (as there seems to be a > dependency cycle: source address should depend on outgoing interface, > which depends on the chosen route, which depends on the source address), > but it leads to highly unintuitive source address selection :( > > Markus suggested in the commit message not to call ip6_route_output at > all before the source address has been selected. Wouldn't this make it > impossible to choose the source address depending on the outgoing > interface in the non-source-specific case as well? > >> Cheers, >> >> Steven > > Thanks for the explanation, > Matthias > -- 吉藤英明 ミラクル・リナックス株式会社 技術本部 サポート部 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] neighbour: Convert if statment in the function, neigh_add_timer to a WARN_ON
Nicholas Krause wrote: > This converts the if statement for dumping the stack into a > WARN_ON in order to make this function's debugging check > simpler and have a cleaner output when this condition > occurs inside this function for when bugs related to > adding a duplicate neighbour table timer arise. > > Signed-off-by: Nicholas Krause > --- > net/core/neighbour.c | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/net/core/neighbour.c b/net/core/neighbour.c > index 3de6542..0bf71da 100644 > --- a/net/core/neighbour.c > +++ b/net/core/neighbour.c > @@ -165,11 +165,7 @@ static int neigh_forced_gc(struct neigh_table *tbl) > static void neigh_add_timer(struct neighbour *n, unsigned long when) > { > neigh_hold(n); > - if (unlikely(mod_timer(&n->timer, when))) { > - printk("NEIGH: BUG, double timer add, state is %x\n", > -n->nud_state); > - dump_stack(); > - } > + WARN_ON(unlikely(mod_timer(&n->timer, when))); > } NACK, please do not use WARN_ON for things with side effects. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] net: Export IGMP/MLD message validation code
Linus Lüssing wrote: > On Fri, Apr 10, 2015 at 07:46:39PM +0200, Linus Lüssing wrote: >> diff --git a/net/ipv6/mcast_snoop.c b/net/ipv6/mcast_snoop.c >> new file mode 100644 >> index 000..95b34c0 >> --- /dev/null >> +++ b/net/ipv6/mcast_snoop.c >> @@ -0,0 +1,198 @@ >> +/* Copyright (C) 2015: Linus Lüssing > > PS: I'm a little uncertain how this is usually done. If I should > add someone (maybe Hideaki YOSHIFUJI, the original author of the > bridge IPv6/MLD support?), then please let me know. If you want to claim copyright, add myself (2010, yoshf...@linux-ipv6.org). You may have Authors: lines for both. Also, you could have description like "Based on MLD support by ...". --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add IPv6 support to TCP SYN cookies
In article <[EMAIL PROTECTED]> (at Thu, 07 Feb 2008 10:40:19 +0100), Eric Dumazet <[EMAIL PROTECTED]> says: > [NET] IPV4: lower stack usage in cookie_hash() function > > 400 bytes allocated on stack might be a litle bit too much. Using a > per_cpu var is more friendly. > > Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> Applied to my inet6-2.6.26 tree. Thanks. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add IPv6 support to TCP SYN cookies
In article <[EMAIL PROTECTED]> (at Thu, 7 Feb 2008 21:49:26 -0800), Glenn Griffin <[EMAIL PROTECTED]> says: > Updated to incorporate Eric's suggestion of using a per cpu buffer > rather than allocating on the stack. Just a two line change, but will > resend in it's entirety. > > Signed-off-by: Glenn Griffin <[EMAIL PROTECTED]> Applied in my linux-2.6-dev tree. Thanks. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IPV4: fix compile error building without CONFIG_FS_PROC
In article <[EMAIL PROTECTED]> (at Mon, 04 Feb 2008 08:47:29 +0800), Li Zefan <[EMAIL PROTECTED]> says: > compile error building without CONFIG_FS_PROC. : > The exit method should have no return values... Have you really tested this with CONFIG_FS_PROC? --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IPv4: Enable use of 240/4 address space
In article <[EMAIL PROTECTED]> (at Sat, 19 Jan 2008 14:44:13 +0100 (CET)), Jan Engelhardt <[EMAIL PROTECTED]> says: > From 84bccef295aa9754ee662191e32ba1d64edce2ba Mon Sep 17 00:00:00 2001 > From: Jan Engelhardt <[EMAIL PROTECTED]> > Date: Fri, 18 Jan 2008 02:10:44 +0100 > Subject: [PATCH] IPv4: enable use of 240/4 address space > > This short patch modifies the IPv4 networking to enable use of the > 240.0.0.0/4 (aka "class-E") address space as propsed in the internet > draft draft-fuller-240space-00.txt. > > Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]> Acked-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IPv4: Enable use of 240/4 address space
In article <[EMAIL PROTECTED]> (at Fri, 18 Jan 2008 11:13:19 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> says: > Assuming IN_BADCLASS() is still there, we should not reuse the name > of "ipv6_is_badclass" because the their meanings are different. Again, ipv4_is_badclass() My hands almost automatically type "6" after "ipv"... --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IPv4: Enable use of 240/4 address space
In article <[EMAIL PROTECTED]> (at Fri, 18 Jan 2008 02:52:08 +0100 (CET)), Jan Engelhardt <[EMAIL PROTECTED]> says: > > On Jan 18 2008 10:26, YOSHIFUJI Hideaki / 吉藤英明 wrote: > >> -#define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) == > >> 0xf000) > >> -#define IN_BADCLASS(a) IN_EXPERIMENTAL((a)) > > > >No, please keep these macros. > > > >> @@ -264,7 +261,7 @@ static inline bool ipv4_is_local_multicast(__be32 addr) > >> > >> static inline bool ipv4_is_badclass(__be32 addr) > >> { > >> - return (addr & htonl(0xf000)) == htonl(0xf000); > >> + return addr == 0x; > >> } > >> > > > >To (un)align the IN_BADCLASS macro and ipv6_is_badclass() definition, > > Unalign? IPv6? "Limited" broadcast? Sorry, ipv4_is_badclass(). Assuming IN_BADCLASS() is still there, we should not reuse the name of "ipv6_is_badclass" because the their meanings are different. > -static inline bool ipv4_is_badclass(__be32 addr) > +static inline bool ipv4_is_broadcast(__be32 addr) > { I'm just afraid that people might think ipv4_is_broadcast is for testing subnet broadcast address. 255.255.255.255 is "limited broadcast address" (vs subnet broadcast address, which can be forwarded by routers). --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IPv4: Enable use of 240/4 address space
In article <[EMAIL PROTECTED]> (at Fri, 18 Jan 2008 02:13:52 +0100 (CET)), Jan Engelhardt <[EMAIL PROTECTED]> says: > diff --git a/include/linux/in.h b/include/linux/in.h > index 27d8a5a..b01bf75 100644 > --- a/include/linux/in.h > +++ b/include/linux/in.h > @@ -216,9 +216,6 @@ struct sockaddr_in { > #define IN_MULTICAST(a) IN_CLASSD(a) > #define IN_MULTICAST_NET 0xF000 > > -#define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) == > 0xf000) > -#define IN_BADCLASS(a) IN_EXPERIMENTAL((a)) > - > /* Address to accept any incoming messages. */ > #define INADDR_ANY ((unsigned long int) 0x) > No, please keep these macros. > @@ -264,7 +261,7 @@ static inline bool ipv4_is_local_multicast(__be32 addr) > > static inline bool ipv4_is_badclass(__be32 addr) > { > - return (addr & htonl(0xf000)) == htonl(0xf000); > + return addr == 0x; > } > To (un)align the IN_BADCLASS macro and ipv6_is_badclass() definition, you should change the name anyway, e.g., ipv6_is_limited_broadcast() or some something alike. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 001/001] ipv4: enable use of 240/4 address space
Hello. In article <[EMAIL PROTECTED]> (at Mon, 7 Jan 2008 17:10:57 -0800), Vince Fuller <[EMAIL PROTECTED]> says: > #define IN_MULTICAST_NET 0xF000 > > +#define IN_CLASSE(a) long int) (a)) & 0xf000) == 0xf000) > +#define IN_CLASSE_NET 0xff00 > +#define IN_CLASSE_NSHIFT8 > +#define IN_CLASSE_HOST (0x & ~IN_CLASSE_NET) > + > +/* > + * these are no longer used > #define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) == > 0xf000) > #define IN_BADCLASS(a) IN_EXPERIMENTAL((a)) > +*/ Please do not remove this, but have these instead: #define IN_EXPERIMENTAL(a) IN_CLASSE((a)) #define IN_BADCASS(a) IN_CLASSE((a)) And, I think it is good to remove BADCLASS() (inside #ifdef __KERNEL__ .. #endif) because we do not have its users any longer, right? Regards, --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 001/001] ipv4: enable use of 240/4 address space
In article <[EMAIL PROTECTED]> (at Fri, 11 Jan 2008 17:48:57 -0800 (PST)), David Miller <[EMAIL PROTECTED]> says: > From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> > Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST) > > > There is no positive consesus on this draft > > at the intarea meeting in Vancouver, right? > > > > We cannot / should not enable that space until we have reached > > a consensus on it. > > This is so incredibly incorrect. > > There is consensus on making network stacks able to use this > address space. And that is all that the patch does. No, we did never make consensus on it. > The consensus is only missing on whether to make the address > space public or private. > > This is also clearly spelled out in the draft. > > It is important to get as large of a head start on this as > possible because of how long it takes to deploy something > like this. Okay, though I am afraid this space will not be used widely, we should be ready for it. I'll make some more comments on the patch itself from another point view. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 001/001] ipv4: enable use of 240/4 address space
In article <[EMAIL PROTECTED]> (at Fri, 11 Jan 2008 12:17:02 +0100), Andi Kleen <[EMAIL PROTECTED]> says: > Vince Fuller <[EMAIL PROTECTED]> writes: > > > from Vince Fuller <[EMAIL PROTECTED]> > > > > This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 > > (aka "class-E") address space as consistent with the Internet Draft > > draft-fuller-240space-00.txt. > > Wouldn't it be wise to at least wait for it becoming an RFC first? I do think so, too. There is no positive consesus on this draft at the intarea meeting in Vancouver, right? We cannot / should not enable that space until we have reached a consensus on it. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] fs/autofs: Use time_before, time_before_eq, etc.
In article <[EMAIL PROTECTED]> (at Thu, 27 Dec 2007 08:08:53 +0100 (CET)), Julia Lawall <[EMAIL PROTECTED]> says: > On Wed, 26 Dec 2007, H. Peter Anvin wrote: > > > Ray Lee wrote: > > > On Dec 26, 2007 7:21 AM, Julia Lawall <[EMAIL PROTECTED]> wrote: > > > > - if (jiffies - ent->last_usage < timeout) > > > > + if (time_before(jiffies, ent->last_usage + timeout)) > > > > > > I don't think this is a safe change? subtraction is always safe (if > > > you think about it as 'distance'), addition isn't always safe unless > > > you know the range. The time_before macro will expand that out to > > > (effectively): > > > > > > if ( (long)(ent->last_usage + timeout) - (long)(jiffies) < 0 ) > > > > > > which seems to introduce an overflow condition in the first term. > > > > > > Dunno, I may be wrong (happens often), but at the very least what > > > you've transformed it into is no longer obviously correct, and so it's > > > not a great change. > > > > Indeed. The bottom form will have overflow issues at time > > jiffies_wraparound/2, whereas the top form will have overflow issues only > > near > > jiffies_wraparound/1. > > OK, so it seems like it is not such a good idea. > > There are, however, over 200 files that contain calls to the various time > functions that follow this pattern, eg: > > arch/arm/kernel/ecard.c:563 > if (!last || time_after(jiffies, last + 5*HZ)) { > > Perhaps they should be coverted to use a subtraction as well? No, use time_after() etc., unless you have very good reason not using them. And above is not a good reason at all. Frequency is not a problem. If we have longer timeout which could result in wrap-around, we must use another method, e.g. 64bit jiffies, anyway. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 20/38] drivers/net: Use time_before, time_before_eq, etc.
In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:40:06 +0100 (CET)), Julia Lawall <[EMAIL PROTECTED]> says: > diff -r -u -p a/drivers/net/cassini.c b/drivers/net/cassini.c > --- a/drivers/net/cassini.c 2007-10-22 11:25:14.0 +0200 > +++ b/drivers/net/cassini.c 2007-12-23 20:38:34.0 +0100 > @@ -91,6 +91,7 @@ > #include > #include > #include > +#include > > #include > > @@ -4141,8 +4142,9 @@ static void cas_link_timer(unsigned long > > if (link_transition_timeout != 0 && > cp->link_transition_jiffies_valid && > - ((jiffies - cp->link_transition_jiffies) > > - (link_transition_timeout))) { > + (time_after(jiffies, > + cp->link_transition_jiffies + > + (link_transition_timeout { > /* One-second counter so link-down workaround doesn't >* cause resets to occur so fast as to fool the switch >* into thinking the link is down. > diff -r -u -p a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c > --- a/drivers/net/cs89x0.c2007-10-22 11:25:14.0 +0200 > +++ b/drivers/net/cs89x0.c2007-12-23 20:38:54.0 +0100 > @@ -450,7 +451,7 @@ wait_eeprom_ready(struct net_device *dev > just in case EEPROM is ready when SI_BUSY in the > PP_SelfST is clear */ > while(readreg(dev, PP_SelfST) & SI_BUSY) > - if (jiffies - timeout >= 40) > + if (time_before_eq(jiffies, timeout + 40)) > return -1; > return 0; > } time_after_eq(). > @@ -1181,10 +1183,10 @@ send_test_pkt(struct net_device *dev) : > break; > - if (jiffies - timenow >= 5) > + if (time_before_eq(jiffies, timenow + 5)) > return 0; /* this shouldn't happen */ > > /* Write the contents of the packet */ time_after_eq() > diff -r -u -p a/drivers/net/e1000/e1000_ethtool.c > b/drivers/net/e1000/e1000_ethtool.c > --- a/drivers/net/e1000/e1000_ethtool.c 2007-12-09 09:35:19.0 > +0100 > +++ b/drivers/net/e1000/e1000_ethtool.c 2007-12-23 20:30:39.0 > +0100 > @@ -1537,12 +1537,12 @@ e1000_run_loopback_test(struct e1000_ada : > break; > } > - if (jiffies >= (time + 2)) { > + if (time_before_eq(jiffies, time + 2)) { > ret_val = 14; /* error code for time out error */ > break; > } ditto. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/38] drivers/infiniband: Use time_before, time_before_eq, etc.
In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:28:42 +0100 (CET)), Julia Lawall <[EMAIL PROTECTED]> says: > diff -r -u -p a/drivers/infiniband/hw/ipath/ipath_mad.c > b/drivers/infiniband/hw/ipath/ipath_mad.c > --- a/drivers/infiniband/hw/ipath/ipath_mad.c 2007-10-22 11:25:09.0 > +0200 > +++ b/drivers/infiniband/hw/ipath/ipath_mad.c 2007-12-23 20:35:37.0 > +0100 > @@ -1334,7 +1334,8 @@ static int process_subn(struct ib_device > } > > /* Is the mkey in the process of expiring? */ > - if (dev->mkey_lease_timeout && jiffies >= dev->mkey_lease_timeout) { > + if (dev->mkey_lease_timeout && > + time_before_eq(jiffies, dev->mkey_lease_timeout)) { > /* Clear timeout and mkey protection field. */ > dev->mkey_lease_timeout = 0; > dev->mkeyprot = 0; time_after_eq() --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/38] arch/ia64/sn: Use time_before, time_before_eq, etc.
In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:18:56 +0100 (CET)), Julia Lawall <[EMAIL PROTECTED]> says: > diff -r -u -p a/arch/ia64/sn/kernel/xpc_main.c > b/arch/ia64/sn/kernel/xpc_main.c > --- a/arch/ia64/sn/kernel/xpc_main.c 2007-11-12 10:35:56.0 +0100 > +++ b/arch/ia64/sn/kernel/xpc_main.c 2007-12-23 20:32:54.0 +0100 > @@ -230,7 +231,7 @@ xpc_hb_beater(unsigned long dummy) > { > xpc_vars->heartbeat++; > > - if (jiffies >= xpc_hb_check_timeout) { > + if (time_before_eq(jiffies, xpc_hb_check_timeout)) { > wake_up_interruptible(&xpc_act_IRQ_wq); > } > time_after_eq() > @@ -270,7 +271,7 @@ xpc_hb_checker(void *ignore) > > > /* checking of remote heartbeats is skewed by IRQ handling */ > - if (jiffies >= xpc_hb_check_timeout) { > + if (time_before_eq(jiffies, xpc_hb_check_timeout)) { > dev_dbg(xpc_part, "checking remote heartbeats\n"); > xpc_check_remote_hb(); > ditto. > @@ -305,7 +306,7 @@ xpc_hb_checker(void *ignore) > /* wait for IRQ or timeout */ > (void) wait_event_interruptible(xpc_act_IRQ_wq, > (last_IRQ_count < atomic_read(&xpc_act_IRQ_rcvd) || > - jiffies >= xpc_hb_check_timeout || > + time_before_eq(jiffies, xpc_hb_check_timeout) || > (volatile int) xpc_exiting)); > } > ditto. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 31/38] net/decnet: Use time_before, time_before_eq, etc.
In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:47:32 +0100 (CET)), Julia Lawall <[EMAIL PROTECTED]> says: > From: Julia Lawall <[EMAIL PROTECTED]> > > The functions time_before, time_before_eq, time_after, and time_after_eq > are more robust for comparing jiffies against other values. > - jiffies >= E > + time_after_eq(jiffies,E) > diff -r -u -p a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c > --- a/net/decnet/af_decnet.c 2007-11-08 08:00:53.0 +0100 > +++ b/net/decnet/af_decnet.c 2007-12-23 20:30:40.0 +0100 : > @@ -601,7 +602,7 @@ int dn_destroy_timer(struct sock *sk) > if (sk->sk_socket) > return 0; > > - if ((jiffies - scp->stamp) >= (HZ * decnet_time_wait)) { > + if (time_before_eq(jiffies, scp->stamp + HZ * decnet_time_wait)) { > dn_unhash_sock(sk); > sock_put(sk); > return 1; ugh? > --- a/net/decnet/dn_timer.c 2006-11-30 19:05:46.0 +0100 > +++ b/net/decnet/dn_timer.c 2007-12-23 20:30:40.0 +0100 > @@ -21,6 +21,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -96,7 +97,7 @@ static void dn_slow_timer(unsigned long >* since the last successful transmission. >*/ > if (scp->keepalive && scp->keepalive_fxn && (scp->state == DN_RUN)) { > - if ((jiffies - scp->stamp) >= scp->keepalive) > + if (time_before_eq(jiffies, scp->stamp + scp->keepalive)) > scp->keepalive_fxn(sk); > } > ugh? --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "ip neigh show" not showing arp cache entries?
In article <[EMAIL PROTECTED]> (at Wed, 12 Dec 2007 15:57:08 -0600), "Chris Friesen" <[EMAIL PROTECTED]> says: > > You may try other versions of this command > > > > http://devresources.linux-foundation.org/dev/iproute2/download/ > > They appear to be numbered by kernel version, and the above version is > the most recent one for 2.6.14. Will more recent ones (for newer > kernels) work with my kernel? It should work; if it doesn't, please make a report. Thanks. --yoshfuji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] SO_NO_CHECK for IPv6
In article <[EMAIL PROTECTED]> (at Thu, 22 Nov 2007 10:34:03 +0800), Herbert Xu <[EMAIL PROTECTED]> says: > On Wed, Nov 21, 2007 at 07:17:40PM -0500, Jeff Garzik wrote: > > > > For those interested, I am dealing with a UDP app that already does very > > strong checksumming and encryption, so additional software checksumming > > at the lower layers is quite simply a waste of CPU cycles. Hardware > > checksumming is fine, as long as its "free." > > No matter how strong your underlying checksumming is it's not > going to protect the IPv6 header is it :) In that sense, we should use AH. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] SO_NO_CHECK for IPv6
In article <[EMAIL PROTECTED]> (at Wed, 21 Nov 2007 07:45:32 -0500), Jeff Garzik <[EMAIL PROTECTED]> says: > > SO_NO_CHECK support for IPv6 appeared to be missing. This is presented, > based on a reading of net/ipv4/udp.c. Disagree. UDP checksum is mandatory in IPv6. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO #5 11/18] Network access control functions.
Hello. In article <[EMAIL PROTECTED]> (at Sat, 17 Nov 2007 02:34:50 +0900), [EMAIL PROTECTED] says: > + *cp++ = '\0'; > + count = sscanf(cp, > +NIP6_FMT "-" NIP6_FMT, > +&min[0], &min[1], &min[2], &min[3], > +&min[4], &min[5], &min[6], &min[7], > +&max[0], &max[1], &max[2], &max[3], > +&max[4], &max[5], &max[6], &max[7]); > + I think you can use in6_pton() here. > + count = sscanf(cp, > +NIPQUAD_FMT "-" NIPQUAD_FMT, > +&min[0], &min[1], > +&min[2], &min[3], > +&max[0], &max[1], > +&max[2], &max[3]); > + in4_pton(). > + > +/** > + * tmy_print_ipv6 - print ipv6 address > + * @buffer: pointer to buffer to save the result. > + * @buffer_len: sizeof @buffer . > + * @ip: pointer to an IPv6 address in network byte order. > + * > + * Returns @buffer . > + */ > +char *tmy_print_ipv6(char *buffer, const int buffer_len, const u16 *ip) > +{ > + memset(buffer, 0, buffer_len); > + snprintf(buffer, buffer_len - 1, NIP6_FMT, > + ntohs(ip[0]), ntohs(ip[1]), ntohs(ip[2]), ntohs(ip[3]), > + ntohs(ip[4]), ntohs(ip[5]), ntohs(ip[6]), ntohs(ip[7])); > + return buffer; > +} > + snprintf(buffer, buffer_len - 1, NIP6_FMT, NIP6(*(struct in6_addr *)ip)); > + count = sscanf(cp2, > +NIP6_FMT "-" NIP6_FMT, > +&min[0], &min[1], &min[2], &min[3], > +&min[4], &min[5], &min[6], &min[7], > +&max[0], &max[1], &max[2], &max[3], > +&max[4], &max[5], &max[6], &max[7]); > + again, in6_pton(). > + count = sscanf(cp2, > +NIPQUAD_FMT "-" NIPQUAD_FMT, > +&min[0], &min[1], &min[2], &min[3], > +&max[0], &max[1], &max[2], &max[3]); > + in4_pton(). --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] add SubmittingPatches to Documentation/ja_JP
Hello. Basically okay, but please refer to the original DCO document. Your mailer is broken. You should include "charset" parameter in your multipart. Maybe it is better to prepare a git repository, or attach it as a binary (application/octet-stream). --yoshfuji In article <[EMAIL PROTECTED]> (at Fri, 26 Oct 2007 15:55:24 +0900), Keiichi KII <[EMAIL PROTECTED]> says: > From: Keiichi Kii <[EMAIL PROTECTED]> > > This patch adds SubmittingPatches translated into Japanese to > Documentation/ja_JP directory. > > I attach the patch because there is a possibility that MUA > will change the character encoding sometimes. > > Signed-off-by: Keiichi KII <[EMAIL PROTECTED]> > -- > Keiichi KII > NEC Corporation OSS Platform Development Division > E-mail: [EMAIL PROTECTED] > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVIDIA Ethernet & invalid MAC
In article <[EMAIL PROTECTED]> (at Tue, 16 Oct 2007 12:00:45 -0400), Jeff Garzik <[EMAIL PROTECTED]> says: > Alan Cox wrote: > >> See the below for another report of this: > >> > >> http://marc.info/?t=11921571691&r=1&w=2 > >> > >> And apparently some motherboard vendors have their own allocations for > >> ethernet > >> addresses? > > > > We can teach it two ranges. I doubt anyone will be unlucky enough to have > > the one which could be either Nvidia or Gigabyte and have it matter. > > > > The "go complain to the BIOS vendor" comment from Nvidia to me isn't an > > answer. Maybe Nvidia can complain to BIOS vendors but end user complaints > > of that form rarely have any effect. > > That wasn't the point of the response at all. The datum is that set of > users where DEV_HAS_CORRECT_MACADDR is accurately set or clear is vast > majority of cases. > > For the rest, we'll want to look at adjusting DEV_HAS_CORRECT_MACADDR > based on DMI strings or a hueristic like you suggested. I think we could have kernel parameter as well. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 05/15](repost) Domain transition handler functions.
In article <[EMAIL PROTECTED]> (at Wed, 3 Oct 2007 23:26:57 +0900), Tetsuo Handa <[EMAIL PROTECTED]> says: > Peter Zijlstra wrote: > > Also, how do you avoid referencing dead data with your sll? I haven't > > actually looked at your patches, but the simple scheme you outlined > > didn't handle the iteration + concurrent removal scenario: > Regarding my singly-linked list, no entries are removed from the list. It's > append only (like CD-R media). > I set is_deleted flag of a entry instead of removing the entry from the list. It is not a good practice. Please free such objects. BTW, how many objects do you have in the list? --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 05/15](repost) Domain transition handler functions.
In article <[EMAIL PROTECTED]> (at Wed, 3 Oct 2007 22:04:11 +0900), Tetsuo Handa <[EMAIL PROTECTED]> says: > Well, is there a way to avoid read_lock when reading list? > > Currently, TOMOYO Linux avoids read_lock, on the assumption that > (1) First, ptr->next is initialized with NULL. > (2) Later, ptr->next is assigned non-NULL address. > (3) Assigning to ptr->next is done atomically. RCU? --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 05/15](repost) Domain transition handler functions.
In article <[EMAIL PROTECTED]> (at Wed, 3 Oct 2007 20:24:52 +0900), Tetsuo Handa <[EMAIL PROTECTED]> says: > It seems that standard kernel list API does not have singly-linked list > manipulation. > I'm considering the following list manipulation API. Tstsuo, please name it "slist", which is well-known. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 05/15](repost) Domain transition handler functions.
In article <[EMAIL PROTECTED]> (at Tue, 2 Oct 2007 21:44:57 +0900), Tetsuo Handa <[EMAIL PROTECTED]> says: > If I use "struct hlist_node" which has two pointers, > it needs more memory than "struct something" which has one pointer. > It is possible to use API defined in include/linux/list.h , > but to reduce memory usage, I dare not use these API. > Singly-linked list's rule in TOMOYO Linux is quite simple, > "ptr->next is NULL if the last element" and "non-NULL if not". Introducing your own list is not good. Please use hlist or introduce new "slist". --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet
In article <[EMAIL PROTECTED]> (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > From: lepton <[EMAIL PROTECTED]> > Date: Tue, 18 Sep 2007 10:16:17 +0800 > > > Hi, > > In some situation, icmp_reply and ip_send_reply will send > > out packet with the wrong source addr, the following patch > > will fix this. > > > > I don't understand why we must use rt->rt_src in the current > > code, if this is a wrong fix, please correct me. > > > > Signed-off-by: Lepton Wu <[EMAIL PROTECTED]> > > That the address is wrong is your opinion only :-) > > Source address selection is a rather complex topic, and > here we are definitely purposefully using the source > address selected by the routing lookup for the reply. And, if you do think something is "wrong", you need to describe it in detail, at least. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 20:23:16 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: > YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> writes: > > > Would you explain why it does not work properly > > for those cases? > > Mostly no appropriate strategy routine was setup to > report the data to the caller of sys_sysctl. I assume that default strategy have been existing for it, no?! Maybe, I do miss something... --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: > > - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary > sysctl names for a function that works with proc. : Well, retrans_time_ms and base_reachable_time_ms supercedes retrans_time and base_reachable_time, we've warned for long time for its deprecation. So, maybe, it is time to remove the old interfaces (retrans_time and base_reachable_time) and simplify ndisc_ifinfo_syctl_change(). --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:49:21 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> > Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST) > > > I disagree. It is bad to remove existing interface. > > Ditto for other patches. > > I think perhaps you misunderstand what Eric is doing. > > sys_sysctl() isn't working properly for these cases and it is both a > deprecated interface and not worth the pain of adding support > in these cases. Would you explain why it does not work properly for those cases? --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] sysctl: Error on bad sysctl tables
Hello. In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 14:09:29 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: > After going through the kernels sysctl tables several times it has > become clear that code review and testing is just not effective in > prevent problematic sysctl tables from being used in the stable > kernel. I certainly can't seem to fix the problems as fast as > they are introduced. : > The biggest part of the code is the table of valid binary sysctl > entries, but since we have frozen our set of binary sysctls this table > should not need to change, and it makes it much easier to detect > when someone unintentionally adds a new binary sysctl value. I don't think everyone needs to have this code, so it is better to make it configurable via CONFIG_SYSCTL_DEBUG or something..., ...no? --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
Hello. In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: > > - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary > sysctl names for a function that works with proc. > > - In neighbour.c reorder the table to put the possibly unused entries > at the end so we can remove them by terminating the table early. > > - In neighbour.c kill the entries with questionable binary sysctl > handling behavior. > > - In neighbour.c if we don't have a strategy routine remove the > binary path. So we don't the default sysctl strategy routine > on data that is not ready for it. > I disagree. It is bad to remove existing interface. Ditto for other patches. Regards, --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IPv6: ipv6_addr_type() doesn't know about RFC4193 addresses
In article <[EMAIL PROTECTED]> (at Wed, 25 Jul 2007 17:12:03 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > Contrarily, there may be ipv6_addr_type() call sites that really > do want to reject rfc4193 addresses. I do not think we have such users. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IPv6: ipv6_addr_type() doesn't know about RFC4193 addresses
Hello. In article <[EMAIL PROTECTED]> (at Wed, 25 Jul 2007 19:49:09 -0400), Dave Johnson <[EMAIL PROTECTED]> says: > ipv6_addr_type() doesn't check for 'Unique Local IPv6 Unicast > Addresses' (RFC4193) and returns IPV6_ADDR_RESERVED for that range. Acked-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> I would say, it would be better to add IPV6_ADDR_UNICAST as well for "reserved" addresses unless we have good reason not to do it, anyway. -- YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by "PM: Introduce pm_power_off_prepare"
In article <[EMAIL PROTECTED]> (at Thu, 26 Jul 2007 16:29:55 +0200), "Rafael J. Wysocki" <[EMAIL PROTECTED]> says: > > Yes, it definitely does. Thank you. > > OK, so here it goes again with a changelog: > > --- > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Generally, sysdev_shutdown() should be called after the ACPI preparation for > powering the system off. To make it happen, we can separate sysdev_shutdown() > from device_shutdown() and call it directly wherever necessary. > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> Acked-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by "PM: Introduce pm_power_off_prepare"
Hello. In article <[EMAIL PROTECTED]> (at Thu, 26 Jul 2007 14:12:33 +0200), "Rafael J. Wysocki" <[EMAIL PROTECTED]> says: > On Wednesday, 25 July 2007 17:28, YOSHIFUJI Hideaki / 吉藤英明 wrote: > > Hello. > > > > In article <[EMAIL PROTECTED]> (at Wed, 25 Jul 2007 14:46:55 +0200), > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> says: > > > > > On Wednesday, 25 July 2007 00:19, YOSHIFUJI Hideaki / 吉藤英明 wrote: > > : > > > > Linux 2.6.23-rc1 fails to power off my ThinkPad T42. > > > > Git-bisect told me that the following commit is to blame, > > > > and by reverting that commit, it works appropriately. > > > > > > (1) Can you please apply the appended patch and see if the message gets > > > printed when you try to power off the system? > > > > Yup, I got it. Last lines are: : > Can you please check if the appended patch helps? Yes, it definitely does. Thank you. Regards, --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by "PM: Introduce pm_power_off_prepare"
Hello. In article <[EMAIL PROTECTED]> (at Wed, 25 Jul 2007 14:46:55 +0200), "Rafael J. Wysocki" <[EMAIL PROTECTED]> says: > On Wednesday, 25 July 2007 00:19, YOSHIFUJI Hideaki / 吉藤英明 wrote: : > > Linux 2.6.23-rc1 fails to power off my ThinkPad T42. > > Git-bisect told me that the following commit is to blame, > > and by reverting that commit, it works appropriately. > > (1) Can you please apply the appended patch and see if the message gets > printed when you try to power off the system? Yup, I got it. Last lines are: | Shutdown: hda | ACPI: PCI interrupt for device :02:02.0 disabled | ACPI: PCI interrupt for device :02:01.0 disabled | ACPI: Preparing to power off the system > (2) Can you please post your .config? Attached. Regards, -- YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc1 # Mon Jul 23 02:01:42 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_LSF=y # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_NR_CPUS=8 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CO
[2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by "PM: Introduce pm_power_off_prepare"
Hello. Linux 2.6.23-rc1 fails to power off my ThinkPad T42. Git-bisect told me that the following commit is to blame, and by reverting that commit, it works appropriately. Regards, --yoshfuji bd804eba1c8597cbb7cd5a5f9fe886aae16a079a is first bad commit commit bd804eba1c8597cbb7cd5a5f9fe886aae16a079a Author: Rafael J. Wysocki <[EMAIL PROTECTED]> Date: Thu Jul 19 01:47:40 2007 -0700 PM: Introduce pm_power_off_prepare Introduce the pm_power_off_prepare() callback that can be registered by the interested platforms in analogy with pm_idle() and pm_power_off(), used for preparing the system to power off (needed by ACPI). This allows us to drop acpi_sysclass and device_acpi that are only defined in order to register the ACPI power off preparation callback, which is needed by pm_power_off() registered in a much different way. Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> Acked-by: Pavel Machek <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> :04 04 624870eb14bf9841fa2dca2cf13cc4c9a0479005 af79f843f3383bbecaed84d493926939cf0e1c12 M drivers :04 04 9b28a21970668ce133916bbe8d8fd4a61bce23d7 80fc84d7982369205dcf94029e3958c90db14bf0 M include :04 04 9ce5c8b5d3f87c121b2f7bc6e02bc814648a2739 2e2e1468dfa0db9dee5bd204fd3f802a975a6454 M kernel -- YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] network splice receive v3
Hello. In article <[EMAIL PROTECTED]> (at Wed, 11 Jul 2007 11:19:27 +0200), Jens Axboe <[EMAIL PROTECTED]> says: > @@ -835,6 +835,7 @@ const struct proto_ops inet_stream_ops = { > .recvmsg = sock_common_recvmsg, > .mmap = sock_no_mmap, > .sendpage = tcp_sendpage, > + .splice_read = tcp_splice_read, > #ifdef CONFIG_COMPAT > .compat_setsockopt = compat_sock_common_setsockopt, > .compat_getsockopt = compat_sock_common_getsockopt, Please add similar bits in net/ipv6/af_inet6.c unless there are any dependency on IPv4. (And if there are, it is not good.) --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try#5] Blackfin ethernet driver: on chip ethernet MAC controller driver
Hello. In article <[EMAIL PROTECTED]> (at Tue, 17 Jul 2007 00:49:02 +0800), Bryan Wu <[EMAIL PROTECTED]> says: > +static void bf537mac_set_multicast_list(struct net_device *dev) > +{ > + u32 sysctl; > + > + if (dev->flags & IFF_PROMISC) { > + printk(KERN_INFO "%s: set to promisc mode\n", dev->name); > + sysctl = bfin_read_EMAC_OPMODE(); > + sysctl |= RAF; > + bfin_write_EMAC_OPMODE(sysctl); > + } else if (dev->flags & IFF_ALLMULTI || dev->mc_count > 16) { > + /* accept all multicast */ > + sysctl = bfin_read_EMAC_OPMODE(); > + sysctl |= PAM; > + bfin_write_EMAC_OPMODE(sysctl); > + } else if (dev->mc_count) { > + /* set multicast */ > + } else { > + /* clear promisc or multicast mode */ > + sysctl = bfin_read_EMAC_OPMODE(); > + sysctl &= ~(RAF | PAM); > + bfin_write_EMAC_OPMODE(sysctl); > + } > +} > + Is this function really correct? Please make sure to set up multicast list on device, or set "all multi" on device if you do not know what to do; e.g. static void bf537mac_set_multicast_list(struct net_device *dev) { u32 sysctl; if (dev->flags & IFF_PROMISC) { printk(KERN_INFO "%s: set to promisc mode\n", dev->name); sysctl = bfin_read_EMAC_OPMODE(); sysctl |= RAF; bfin_write_EMAC_OPMODE(sysctl); } else if (dev->flags & IFF_ALLMULTI || dev->mc_count) { /* accept all multicast */ sysctl = bfin_read_EMAC_OPMODE(); sysctl |= PAM; bfin_write_EMAC_OPMODE(sysctl); } else { /* clear promisc or multicast mode */ sysctl = bfin_read_EMAC_OPMODE(); sysctl &= ~(RAF | PAM); bfin_write_EMAC_OPMODE(sysctl); } } --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/61] sysfs: make sysfs_put() ignore NULL sd
In article <[EMAIL PROTECTED]> (at Wed, 11 Jul 2007 16:55:29 -0700), Greg KH <[EMAIL PROTECTED]> says: > On Thu, Jul 12, 2007 at 08:50:47AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ > wrote: > > In article <[EMAIL PROTECTED]> (at Wed, 11 Jul 2007 16:31:43 -0700), Greg > > Kroah-Hartman <[EMAIL PROTECTED]> says: > > > > > Make sysfs_put() ignore NULL sd instead of oopsing. > > > > I do not think this is a good idea; it is non-sense (and rather a bug) > > to call "put" with NULL argument in general. > > It's better than having to check it all the time in the caller :) How many callers do we have that will get benefit from this change? Well, the change will hide the bug. It seems all callers in fs/sysfs already assume that the argument is NOT NULL, and it is a bug to call sysfs_put() with NULL; the function should be used to "put" something you "have" (non-NULL). If it is called with NULL, I would say, we should BUG here to detect the logical bug. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/61] sysfs: make sysfs_put() ignore NULL sd
In article <[EMAIL PROTECTED]> (at Wed, 11 Jul 2007 16:31:43 -0700), Greg Kroah-Hartman <[EMAIL PROTECTED]> says: > Make sysfs_put() ignore NULL sd instead of oopsing. I do not think this is a good idea; it is non-sense (and rather a bug) to call "put" with NULL argument in general. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sysfs: release mutex when kmalloc() failed in sysfs_open_file().
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> -- diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index b502c71..1f64ce5 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -283,6 +283,7 @@ static int sysfs_open_file(struct inode *inode, struct file *file) mutex_lock(&inode->i_mutex); if (!(set = inode->i_private)) { if (!(set = inode->i_private = kmalloc(sizeof(struct sysfs_buffer_collection), GFP_KERNEL))) { + mutex_unlock(&inode->i_mutex); error = -ENOMEM; goto Done; } else { -- YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TCP_MD5 and Intel e1000
In article <[EMAIL PROTECTED]> (at Tue, 22 May 2007 10:57:38 +0200), Eric Dumazet <[EMAIL PROTECTED]> says: > > I have tried to set up quagga with tcp-md5 support from kernel. All seems ok > > with a intel e100 NIC, but as i testetd with a intel e1000 NIC the tcp > > packets have an invalid md5 digest. > > If i run tcpdump on the mashine the packets are generated, it shows on the > > outgoing interface invalid md5 digests. > > Are there known issues about tcp-md5 and e1000 NICs? : > You could try "ethtool -K tx off", and/or other ethtool -K settings Disabling offloading should help; currently tcp-md5 stack blindly copy md5-signature from the first segment which is not appropriate for rest of segments. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.21-gitN - versioning question
In article <[EMAIL PROTECTED]> (at Sat, 12 May 2007 13:19:23 +0200 (MEST)), Jan Engelhardt <[EMAIL PROTECTED]> says: > I notice that people refer to certain git snapshots as e.g. -git16; > kernel.org does so too. Hovering over the link on kernel.org reveals > http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-git16.bz2 > but where do I actually find -git16 in Linus's git tree? git16 is > neither a branch nor a tag. http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-git16.id tells the commit in his tree. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Fix potential overflow in perfctr reservation
Hello. In article <[EMAIL PROTECTED]> (at Sun, 22 Apr 2007 01:09:17 -0700), Andrew Morton <[EMAIL PROTECTED]> says: > > [PATCH] x86: Fix potential overflow in perfctr reservation : > The created a warning storm: > > > arch/i386/kernel/nmi.c: In function 'avail_to_resrv_perfctr_nmi_bit': > arch/i386/kernel/nmi.c:129: warning: passing argument 2 of > 'constant_test_bit' from incompatible pointer type > arch/i386/kernel/nmi.c:129: warning: passing argument 2 of > 'variable_test_bit' from incompatible pointer type : > diff -puN > arch/i386/kernel/nmi.c~fix-x86-fix-potential-overflow-in-perfctr-reservation > arch/i386/kernel/nmi.c > --- > a/arch/i386/kernel/nmi.c~fix-x86-fix-potential-overflow-in-perfctr-reservation > +++ a/arch/i386/kernel/nmi.c > @@ -126,7 +126,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsig > int cpu; > BUG_ON(counter > NMI_MAX_COUNTER_BITS); > for_each_possible_cpu (cpu) { > - if (test_bit(counter, &per_cpu(perfctr_nmi_owner, cpu))) > + if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu))) > return 0; > } > return 1; : > > I worry rather a lot about how well runtime tested this very late change > was, and whether it works correctly even with this fix applied. Perhaps > we should jsut revert? Is DEFINE_PER_CPU(type, var[num]) is really valid? I guess it should be DEFINE_PER_CPU(type[num], var), no? [I386] NMI: Fix per_cpu() usage. Per-cpu array should be declared as DEFINE_PER_CPU(type[size], name), not as DEFINE_PER_CPU(type, name[size]). Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> diff --git a/arch/i386/kernel/nmi.c b/arch/i386/kernel/nmi.c index 9f1e8c1..eddb4f7 100644 --- a/arch/i386/kernel/nmi.c +++ b/arch/i386/kernel/nmi.c @@ -48,8 +48,8 @@ int nmi_watchdog_enabled; #define NMI_MAX_COUNTER_BITS 66 #define NMI_MAX_COUNTER_LONGS BITS_TO_LONGS(NMI_MAX_COUNTER_BITS) -static DEFINE_PER_CPU(unsigned long, perfctr_nmi_owner[NMI_MAX_COUNTER_LONGS]); -static DEFINE_PER_CPU(unsigned long, evntsel_nmi_owner[NMI_MAX_COUNTER_LONGS]); +static DEFINE_PER_CPU(unsigned long [NMI_MAX_COUNTER_LONGS], perfctr_nmi_owner); +static DEFINE_PER_CPU(unsigned long [NMI_MAX_COUNTER_LONGS], evntsel_nmi_owner); static cpumask_t backtrace_mask = CPU_MASK_NONE; /* nmi_active: @@ -126,7 +126,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsigned int counter) int cpu; BUG_ON(counter > NMI_MAX_COUNTER_BITS); for_each_possible_cpu (cpu) { - if (test_bit(counter, &per_cpu(perfctr_nmi_owner, cpu))) + if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu))) return 0; } return 1; @@ -142,7 +142,7 @@ int avail_to_resrv_perfctr_nmi(unsigned int msr) BUG_ON(counter > NMI_MAX_COUNTER_BITS); for_each_possible_cpu (cpu) { - if (test_bit(counter, &per_cpu(perfctr_nmi_owner, cpu))) + if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu))) return 0; } return 1; @@ -157,7 +157,7 @@ static int __reserve_perfctr_nmi(int cpu, unsigned int msr) counter = nmi_perfctr_msr_to_bit(msr); BUG_ON(counter > NMI_MAX_COUNTER_BITS); - if (!test_and_set_bit(counter, &per_cpu(perfctr_nmi_owner, cpu))) + if (!test_and_set_bit(counter, per_cpu(perfctr_nmi_owner, cpu))) return 1; return 0; } @@ -171,7 +171,7 @@ static void __release_perfctr_nmi(int cpu, unsigned int msr) counter = nmi_perfctr_msr_to_bit(msr); BUG_ON(counter > NMI_MAX_COUNTER_BITS); - clear_bit(counter, &per_cpu(perfctr_nmi_owner, cpu)); + clear_bit(counter, per_cpu(perfctr_nmi_owner, cpu)); } int reserve_perfctr_nmi(unsigned int msr) @@ -207,7 +207,7 @@ int __reserve_evntsel_nmi(int cpu, unsigned int msr) counter = nmi_evntsel_msr_to_bit(msr); BUG_ON(counter > NMI_MAX_COUNTER_BITS); - if (!test_and_set_bit(counter, &per_cpu(evntsel_nmi_owner, cpu)[0])) + if (!test_and_set_bit(counter, per_cpu(evntsel_nmi_owner, cpu))) return 1; return 0; } @@ -221,7 +221,7 @@ static void __release_evntsel_nmi(int cpu, unsigned int msr) counter = nmi_evntsel_msr_to_bit(msr); BUG_ON(counter > NMI_MAX_COUNTER_BITS); - clear_bit(counter, &per_cpu(evntsel_nmi_owner, cpu)[0]); + clear_bit(counter, per_cpu(evntsel_nmi_owner, cpu)); } int reserve_evntsel_nmi(unsigned int msr) -- YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPv6: Connection reset/timeout under heavy load
In article <[EMAIL PROTECTED]> (at Wed, 28 Mar 2007 02:26:24 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > > http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/yoshfuji/linux-2.6-fix.git;a=commit;h=33a79bba0cc2f197b46cc54182f94c31ff6ad334 > > > > I hope this patch will go in 2.6.16-stable... > > Please forward this patch to Adrian Bunk ([EMAIL PROTECTED]), > he will definitely add it to 2.6.16-stable for you. I will do it again... --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPv6: Connection reset/timeout under heavy load
In article <[EMAIL PROTECTED]> (at Wed, 28 Mar 2007 10:48:27 +0200), Agoston Horvath <[EMAIL PROTECTED]> says: > YOSHIFUJI Hideaki / 吉藤英明 wrote: > > Would you test with latest kernel, if possible, please? > > For the archive: switching to 2.6.20.4 fixed this problem. Thank you for your report. I guess the following change will fix the issue for 2.6.16.y: http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/yoshfuji/linux-2.6-fix.git;a=commit;h=33a79bba0cc2f197b46cc54182f94c31ff6ad334 I hope this patch will go in 2.6.16-stable... Regards, --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPv6: Connection reset/timeout under heavy load
Hello. (CC: netdev added.) In article <[EMAIL PROTECTED]> (at Tue, 27 Mar 2007 11:45:46 +0200), Agoston Horvath <[EMAIL PROTECTED]> says: > I'm using kernel 2.6.16.29, libc is 2.3.2.ds1-22sarge5. However, same result > was achieved using kernel version 2.6.13 on the same box. > > I'm out of further ideas. If anyone can give me some pointers about what > could be wrong, please, don't spare me. Would you test with latest kernel, if possible, please? --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc1-git compilation error in arch/i386/kernel/io_apic.c
Hello. I got this error with current git tree with CONFIG_SMP=n. | CHK include/linux/compile.h | CC arch/i386/kernel/io_apic.o |arch/i386/kernel/io_apic.c: In function `setup_IO_APIC_irqs': |arch/i386/kernel/io_apic.c:1357: error: structure has no member named `affinity' |arch/i386/kernel/io_apic.c: In function `io_apic_set_pci_routing': |arch/i386/kernel/io_apic.c:2878: error: structure has no member named `affinity' |make[1]: *** [arch/i386/kernel/io_apic.o] Error 1 |make: *** [arch/i386/kernel] Error 2 The commit 9f0a5ba5508143731dc63235de19659be20d26dc introduced this issue. The affinity member is only available with CONFIG_SMP. Regards, -- YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] cxgb3 - private ioctl cleanup
In article <[EMAIL PROTECTED]> (at Thu, 22 Feb 2007 04:50:05 -0800), Divy Le Ray <[EMAIL PROTECTED]> says: > > Even if you remove them, PLEASE DO NOT CHANGE THE VALUES, > > unless you have very, very good reason. : > The cxgb3 driver has not yet appeared in a stable version of the linux > kernel. > The odds of breaking an application using these private ioctls are > pretty slim. > Since some cleanup was required, I chose not to let holes between the > values. Even so, if I were you, I would not have changed them and I would even try keeping compatibility with old (out-kernel) drivers. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] cxgb3 - private ioctl cleanup
In article <[EMAIL PROTECTED]> (at Thu, 22 Feb 2007 04:34:34 -0800), Divy Le Ray <[EMAIL PROTECTED]> says: > > 1. Please do do change the values. > > 2. Explain why you are going to kill these ioctls. > > > Jeff and Arjan have required that most of these ioctls go. > Please read: > http://marc.theaimsgroup.com/?l=linux-netdev&m=117029584904193&w=2 Even if you remove them, PLEASE DO NOT CHANGE THE VALUES, unless you have very, very good reason. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] cxgb3 - private ioctl cleanup
In article <[EMAIL PROTECTED]> (at Thu, 22 Feb 2007 03:59:25 -0800), [EMAIL PROTECTED] says: > From: Divy Le Ray <[EMAIL PROTECTED]> > > Clean up some private ioctls. > > Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> > --- > > drivers/net/cxgb3/cxgb3_ioctl.h | 21 - > drivers/net/cxgb3/cxgb3_main.c | 48 > +++ > 2 files changed, 9 insertions(+), 60 deletions(-) > > diff --git a/drivers/net/cxgb3/cxgb3_ioctl.h b/drivers/net/cxgb3/cxgb3_ioctl.h > index a942818..42d4bf6 100644 > --- a/drivers/net/cxgb3/cxgb3_ioctl.h > +++ b/drivers/net/cxgb3/cxgb3_ioctl.h > @@ -36,28 +36,17 @@ > * Ioctl commands specific to this driver. > */ > enum { > - CHELSIO_SETREG = 1024, > - CHELSIO_GETREG, > - CHELSIO_SETTPI, > - CHELSIO_GETTPI, > - CHELSIO_GETMTUTAB, > + CHELSIO_GETMTUTAB = 1024, > CHELSIO_SETMTUTAB, > - CHELSIO_GETMTU, > - CHELSIO_SET_PM, > - CHELSIO_GET_PM, > - CHELSIO_GET_TCAM, > - CHELSIO_SET_TCAM, > - CHELSIO_GET_TCB, > CHELSIO_GET_MEM, > CHELSIO_LOAD_FW, > - CHELSIO_GET_PROTO, > - CHELSIO_SET_PROTO, > CHELSIO_SET_TRACE_FILTER, > - CHELSIO_SET_QSET_PARAMS, > CHELSIO_GET_QSET_PARAMS, > - CHELSIO_SET_QSET_NUM, > + CHELSIO_SET_QSET_PARAMS, > CHELSIO_GET_QSET_NUM, > - CHELSIO_SET_PKTSCHED, > + CHELSIO_SET_QSET_NUM, > + CHELSIO_GET_PM, > + CHELSIO_SET_PM, > }; > I disagree. This is very bad. 1. Please do do change the values. 2. Explain why you are going to kill these ioctls. Regards, --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1)
Hello. In article <[EMAIL PROTECTED]> (at Tue, 20 Feb 2007 20:53:45 -0800 (PST)), Linus Torvalds <[EMAIL PROTECTED]> says: > But there's a ton of architecture updates (arm, mips, powerpc, x86, you > name it), ACPI updates, and lots of driver work. And just a lot of > cleanups. I cannot boot 2.6.21-rc1; it falls into OOM-Killer. Interesting error message I can see is: request_module: runaway loop modprobe net-pf-1 After bisecting, the commit Driver core: let request_module() send a /sys/modules/kmod/-uevent (id c353c3fb0700a3c17ea2b0237710a184232ccd7f) is to blame. Reverting it fixes the issue to me. Regards, --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Coding style RFC: convert "for (i=0;i
In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 15:47:50 -0800), Joe Perches <[EMAIL PROTECTED]> says: > Now that most of the sizeof(array)/sizeof(array[0]) > conversions have been done (there are about 800 done > and about another 130 left), perhaps it could be > useful to change the code to use a define similar > to the list_for_each > > #define list_for_each(pos, head) \ > for (pos = (head)->next; prefetch(pos->next), pos != (head); \ > pos = pos->next) > > perhaps > > #define array_for_each(index, array) \ > for ((index) = 0; (index) < ARRAY_SIZE((array)); (index)++) I dislike this; it is overkill. list_for_each etc. are for list_head etc., of structures. On the other hand, arrays are not. It is very, very obvious how to access its members. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-git8 fails compile -- net/built-in.o __ipv6_addr_type
In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 21:35:59 -0500 (EST)), Pete Clements <[EMAIL PROTECTED]> says: > Quoting YOSHIFUJIHideaki/=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= > > In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 18:12:16 -0800), > Andrew Morton <[EMAIL PROTECTED]> says: > > > > > > On Mon, 12 Feb 2007 20:10:13 -0500 (EST) Pete Clements <[EMAIL > PROTECTED]> wrote: > > > > 2.6.20-git8 fails compile: > > > > > > > > CHK include/linux/compile.h > > > > UPD include/linux/compile.h > > > > CC init/version.o > > > > LD init/built-in.o > > > > LD .tmp_vmlinux1 > > > > net/built-in.o: In function `svc_udp_recvfrom': > > > > svcsock.c:(.text+0x61be4): undefined reference to `__ipv6_addr_type' > > > > make: *** [.tmp_vmlinux1] Error 1 > > > > > > > > > > Please send the .config. > > > > and, the gcc version... > > > > --yoshfuji > > - > > git 7 compiled just fine. Ah, this is because of new ipv6 support in sunrpc code. Enable it if it is statically compiled. Alternatively, we could - export __ipv6_addr_type in new net/ipv6/addrconf_core.c or - introduce tiny inline for chcking if the address is link-local. Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c index 63ae947..27dcb31 100644 --- a/net/sunrpc/svcsock.c +++ b/net/sunrpc/svcsock.c @@ -107,12 +107,12 @@ static inline void svc_reclassify_socket sock_lock_init_class_and_name(sk, "slock-AF_INET-NFSD", &svc_slock_key[0], "sk_lock-AF_INET-NFSD", &svc_key[0]); break; - +#ifdef CONFIG_IPV6 case AF_INET6: sock_lock_init_class_and_name(sk, "slock-AF_INET6-NFSD", &svc_slock_key[1], "sk_lock-AF_INET6-NFSD", &svc_key[1]); break; - +#endif default: BUG(); } @@ -131,7 +131,7 @@ static char *__svc_print_addr(struct soc NIPQUAD(((struct sockaddr_in *) addr)->sin_addr), htons(((struct sockaddr_in *) addr)->sin_port)); break; -#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) +#if defined(CONFIG_IPV6) case AF_INET6: snprintf(buf, len, "%x:%x:%x:%x:%x:%x:%x:%x, port=%u", NIP6(((struct sockaddr_in6 *) addr)->sin6_addr), @@ -449,7 +449,7 @@ svc_wake_up(struct svc_serv *serv) union svc_pktinfo_u { struct in_pktinfo pkti; -#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) +#if defined(CONFIG_IPV6) struct in6_pktinfo pkti6; #endif }; @@ -467,7 +467,7 @@ static void svc_set_cmsg_data(struct svc cmh->cmsg_len = CMSG_LEN(sizeof(*pki)); } break; -#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) +#if defined(CONFIG_IPV6) case AF_INET6: { struct in6_pktinfo *pki = CMSG_DATA(cmh); @@ -737,7 +737,7 @@ static void svc_udp_get_sender_address(s rqstp->rq_daddr.addr.s_addr = skb->nh.iph->daddr; } break; -#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) +#if defined(CONFIG_IPV6) case AF_INET6: { /* this is derived from net/ipv6/udp.c:udpv6_recvmesg */ struct sockaddr_in6 *sin6 = svc_addr_in6(rqstp); @@ -977,7 +977,7 @@ static inline int svc_port_is_privileged case AF_INET: return ntohs(((struct sockaddr_in *)sin)->sin_port) < PROT_SOCK; -#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) +#if defined(CONFIG_IPV6) case AF_INET6: return ntohs(((struct sockaddr_in6 *)sin)->sin6_port) < PROT_SOCK; diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c index 49cabff..877b52b 100644 --- a/net/sunrpc/xprtsock.c +++ b/net/sunrpc/xprtsock.c @@ -1187,11 +1187,12 @@ static inline void xs_reclassify_socket( &xs_slock_key[0], "sk_lock-AF_INET-NFS", &xs_key[0]); break; +#ifdef CONFIG_IPV6 case AF_INET6: sock_lock_init_class_and_name(sk, "slock-AF_INET6-NFS", &xs_slock_key[1], "sk_lock-AF_INET6-NFS", &xs_key[1]); break; - +#endif default: BUG(); } -- YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-git8 fails compile -- net/built-in.o __ipv6_addr_type
In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 18:12:16 -0800), Andrew Morton <[EMAIL PROTECTED]> says: > > On Mon, 12 Feb 2007 20:10:13 -0500 (EST) Pete Clements <[EMAIL PROTECTED]> > > wrote: > > 2.6.20-git8 fails compile: > > > > CHK include/linux/compile.h > > UPD include/linux/compile.h > > CC init/version.o > > LD init/built-in.o > > LD .tmp_vmlinux1 > > net/built-in.o: In function `svc_udp_recvfrom': > > svcsock.c:(.text+0x61be4): undefined reference to `__ipv6_addr_type' > > make: *** [.tmp_vmlinux1] Error 1 > > > > Please send the .config. and, the gcc version... --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[USBSERIAL] PL2303: Willcom WS002IN Support.
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> --- drivers/usb/serial/pl2303.c |1 + drivers/usb/serial/pl2303.h |5 + 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c index 5dc2ac9..8d72a2e 100644 --- a/drivers/usb/serial/pl2303.c +++ b/drivers/usb/serial/pl2303.c @@ -83,6 +83,7 @@ static struct usb_device_id id_table [] = { { USB_DEVICE(BELKIN_VENDOR_ID, BELKIN_PRODUCT_ID) }, { USB_DEVICE(ALCOR_VENDOR_ID, ALCOR_PRODUCT_ID) }, { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_ID) }, + { USB_DEVICE(WS002IN_VENDOR_ID, WS002IN_PRODUCT_ID) }, { } /* Terminating entry */ }; diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h index 65a5039..f9a71d0 100644 --- a/drivers/usb/serial/pl2303.h +++ b/drivers/usb/serial/pl2303.h @@ -97,3 +97,8 @@ /* Huawei E620 UMTS/HSDPA card (ID: 12d1:1001) */ #define HUAWEI_VENDOR_ID 0x12d1 #define HUAWEI_PRODUCT_ID 0x1001 + +/* Willcom WS002IN Data Driver (by NetIndex Inc.) */ +#define WS002IN_VENDOR_ID 0x11f6 +#define WS002IN_PRODUCT_ID 0x2001 + -- 1.4.4.1.g562ce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] 2.6.19.2 regression introduced by "IPV4/IPV6: Fix inet{, 6} device initialization order."
In article <[EMAIL PROTECTED]> (at Tue, 16 Jan 2007 03:01:56 +0100), Gabriel C <[EMAIL PROTECTED]> says: > Greg KH schrieb: > > On Sun, Jan 14, 2007 at 09:30:08PM -0800, David Miller wrote: > > > >> From: David Stevens <[EMAIL PROTECTED]> > >> Date: Sun, 14 Jan 2007 19:47:49 -0800 > >> > >> > >>> I think it's better to add the fix than withdraw this patch, since > >>> the original bug is a crash. > >>> > >> I completely agree. > >> > > > > Great, can someone forward the patch to us? > > > > Should be the fix from http://bugzilla.kernel.org/show_bug.cgi?id=7817 I've resent the patch to <[EMAIL PROTECTED]>. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer
Dave, please apply. Thank you. In article <[EMAIL PROTECTED]> (at Tue, 9 Jan 2007 07:11:39 +0200), Craig Schlenter <[EMAIL PROTECTED]> says: > All credit goes to Komuro <[EMAIL PROTECTED]> for tracking > this down. The patch is untested but it looks *cough* obviously > correct. > > Signed-off-by: Craig Schlenter <[EMAIL PROTECTED]> Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> --- Begin Message --- SGkgRGF2ZQ0KDQpZT1NISUZVSkkgSGlkZWFraSAvIOWQieiXpOiLseaYjiBoYXMgc3VnZ2VzdGVk IHRoYXQgSSBzZW5kIHRoZSBwYXRjaA0KYmVsb3cgdG8gZml4IHRoZSBmdHAgc3RhbGxzIHByZXNl bnQgaW4gdGhlIGN1cnJlbnQga2VybmVscy4NCg0KQWxsIGNyZWRpdCBnb2VzIHRvIEtvbXVybyA8 a29tdXJvanVuLW1ibkBuaWZ0eS5jb20+IGZvciB0cmFja2luZw0KdGhpcyBkb3duLiBUaGUgcGF0 Y2ggaXMgdW50ZXN0ZWQgYnV0IGl0IGxvb2tzICpjb3VnaCogb2J2aW91c2x5DQpjb3JyZWN0Lg0K DQpTaWduZWQtb2ZmLWJ5OiBDcmFpZyBTY2hsZW50ZXIgPGNyYWlnQGNvZGVmb3VudGFpbi5jb20+ DQoNClRoYW5rIHlvdSENCg0KLS1DcmFpZw0KDQpkaWZmIC0tZ2l0IGEvbmV0L2lwdjQvdGNwX2lw djQuYyBiL25ldC9pcHY0L3RjcF9pcHY0LmMNCmluZGV4IGJmN2EyMjQuLjEyZGU5MGEgMTAwNjQ0 DQotLS0gYS9uZXQvaXB2NC90Y3BfaXB2NC5jDQorKysgYi9uZXQvaXB2NC90Y3BfaXB2NC5jDQpA QCAtNjQ4LDcgKzY0OCw3IEBAIHN0YXRpYyB2b2lkIHRjcF92NF9zZW5kX2FjayhzdHJ1Y3QgdGNw X3RpbWV3YWl0X3NvY2sgKnR3c2ssDQogCQkJCSAgIFRDUE9MRU5fVElNRVNUQU1QKTsNCiAJCXJl cC5vcHRbMV0gPSBodG9ubCh0Y3BfdGltZV9zdGFtcCk7DQogCQlyZXAub3B0WzJdID0gaHRvbmwo dHMpOw0KLQkJYXJnLmlvdlswXS5pb3ZfbGVuID0gVENQT0xFTl9UU1RBTVBfQUxJR05FRDsNCisJ CWFyZy5pb3ZbMF0uaW92X2xlbiArPSBUQ1BPTEVOX1RTVEFNUF9BTElHTkVEOw0KIAl9DQogDQog CS8qIFN3YXAgdGhlIHNlbmQgYW5kIHRoZSByZWNlaXZlLiAqLw0K --- End Message ---
Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer
In article <[EMAIL PROTECTED]> (at Thu, 4 Jan 2007 14:23:30 +0200), Craig Schlenter <[EMAIL PROTECTED]> says: > On Fri, Jan 05, 2007 at 05:45:46AM +0900, Komuro wrote: > > Hi, > > > > I made a patch below. > > With this patch, the ftp-transfer-stop problem does not happen. > > Therefore, I think this is not a problem of vsftpd. > > > > Mr.YOSHIFUJI san, why did you set TCPOLEN_TSTAMP_ALIGNED > > to iov_len? > > > > > > > > --- linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c.orig 2007-01-03 > > 11:50:04.0 +0900 > > +++ linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c2007-01-03 15:30:44.0 > > +0900 > > @@ -648,7 +648,7 @@ static void tcp_v4_send_ack(struct tcp_t > >TCPOLEN_TIMESTAMP); > > rep.opt[1] = htonl(tcp_time_stamp); > > rep.opt[2] = htonl(ts); > > - arg.iov[0].iov_len = TCPOLEN_TSTAMP_ALIGNED; > > + arg.iov[0].iov_len = sizeof(rep); > > Perhaps this was supposed to be > arg.iov[0].iov_len += TCPOLEN_TSTAMP_ALIGNED; > > That's what the ipv6 stuff does in places. Good catch! I agree. Craig, please provide a patch for us, please. Thank you again. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [DISCUSS] Make the variable NULL after freeing it.
In article <[EMAIL PROTECTED]> (at Mon, 1 Jan 2007 01:43:00 +0100), Ingo Oeser <[EMAIL PROTECTED]> says: > On Sunday, 31. December 2006 14:38, Bernd Petrovitsch wrote: > > That depends on the decision/definition if (so called) "double free" is > > an error or not (and "free(NULL)" must work in POSIX-compliant > > environments). > > A double free of non-NULL is certainly an error. > So the idea of setting it to NULL is ok, since then you can > kfree the variable over and over again without any harm. I dislike (or, say, I hate) this idea; people should fix up such broken code paths. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer
In article <[EMAIL PROTECTED]> (at Sat, 30 Dec 2006 20:59:31 +0900), Komuro <[EMAIL PROTECTED]> says: > > Do you see similar issue with other simple application? > > sorry, I don't reproduce this problem on other application. Can you reproduce it with other ftp client and/or server? Anyway... Please provide the output of "netstat -na" command during the transfer, and the output of "lsmod | grep conntrack" (just for sure). More questions: What kind of mode do you use? e.g. PORT/EPRT/LPRT/PASV/EPSV/LPSV When the transfer get stuck, are other communication still working? Are there any workaround? e.g. stop-start vsftpd cycle, ifdown-ifup cycle, rmmod/insmod cycle etc. Regards, --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG KERNEL 2.6.20-rc1] ftp: get or put stops during file-transfer
In article <[EMAIL PROTECTED]> (at Sat, 30 Dec 2006 18:50:43 +0900), Komuro <[EMAIL PROTECTED]> says: > I investigated the ftp-file-transfer-stop problem by git-bisect method, > and found this problem was introduced by > "[TCP]: MD5 Signature Option (RFC2385) support" patch. > > Mr.YOSHIFUJI san, please fix this problem. Hmm, have you try disabling CONFIG_TCP_MD5SIG? (Is it already disabled?) Are there any specific size of transfer to reproduce this? Do you see similar issue with other simple application? --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] NTP shiftR cleanup
In article <[EMAIL PROTECTED]> (at Fri, 09 Sep 2005 18:03:37 -0700), john stultz <[EMAIL PROTECTED]> says: > diff --git a/kernel/time.c b/kernel/time.c > --- a/kernel/time.c > +++ b/kernel/time.c > @@ -338,30 +338,20 @@ int do_adjtimex(struct timex *txc) > if (mtemp >= MINSEC) { > ltemp = (time_offset / mtemp) << (SHIFT_USEC - > SHIFT_UPDATE); > - if (ltemp < 0) > - time_freq -= -ltemp >> SHIFT_KH; > - else > - time_freq += ltemp >> SHIFT_KH; > + time_freq = shiftR(ltemp, SHIFT_KH); > } else /* calibration interval too short (p. 12) */ > result = TIME_ERROR; Maybe, "time_freq += shiftR(ltemp, SHIFT_KH);"? --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-git3: build failure: sysctl_optmem_max
In article <[EMAIL PROTECTED]> (at Sat, 3 Sep 2005 11:27:56 +0100), Russell King <[EMAIL PROTECTED]> says: > While trying to build a kernel with CONFIG_SYSCTL disabled, the following > error occurs: > > CC net/ipv4/ip_sockglue.o > net/ipv4/ip_sockglue.c: In function `ip_setsockopt': > net/ipv4/ip_sockglue.c:622: error: `sysctl_optmem_max' undeclared (first use > in > net/ipv4/ip_sockglue.c:622: error: (Each undeclared identifier is reported > only > net/ipv4/ip_sockglue.c:622: error: for each function it appears in.) > > It seems that sysctl_optmem_max is only available if CONFIG_SYSCTL is set. > However, ip_setsockopt makes unconditional usage of this variable. This should fix the issue. Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> diff --git a/include/net/sock.h b/include/net/sock.h --- a/include/net/sock.h +++ b/include/net/sock.h @@ -1374,8 +1374,8 @@ extern void sk_init(void); #ifdef CONFIG_SYSCTL extern struct ctl_table core_table[]; -extern int sysctl_optmem_max; #endif +extern int sysctl_optmem_max; extern __u32 sysctl_wmem_default; extern __u32 sysctl_rmem_default; diff --git a/net/core/sock.c b/net/core/sock.c --- a/net/core/sock.c +++ b/net/core/sock.c @@ -1719,8 +1719,8 @@ EXPORT_SYMBOL(sock_wfree); EXPORT_SYMBOL(sock_wmalloc); EXPORT_SYMBOL(sock_i_uid); EXPORT_SYMBOL(sock_i_ino); -#ifdef CONFIG_SYSCTL EXPORT_SYMBOL(sysctl_optmem_max); +#ifdef CONFIG_SYSCTL EXPORT_SYMBOL(sysctl_rmem_max); EXPORT_SYMBOL(sysctl_wmem_max); #endif -- YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG
In article <[EMAIL PROTECTED]> (at Sat, 23 Jul 2005 08:54:27 -0400), Harald Welte <[EMAIL PROTECTED]> says: > --- a/include/linux/netlink.h > +++ b/include/linux/netlink.h > @@ -20,7 +20,7 @@ > #define NETLINK_IP6_FW 13 > #define NETLINK_DNRTMSG 14 /* DECnet routing messages */ > #define NETLINK_KOBJECT_UEVENT 15 /* Kernel messages to userspace > */ > -#define NETLINK_TAPBASE 16 /* 16 to 31 are ethertap */ > +#define NETLINK_W1 16 /* 16 to 31 are ethertap */ > > #define MAX_LINKS 32 > Comment says that 16-31 are used for ethertap. So, probably assigh NETLINK_W1 at 32, and bump MAX_LINKS? --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13-rc1 01/10] IOCHK interface for I/O error handling/detecting
In article <[EMAIL PROTECTED]> (at Wed, 06 Jul 2005 13:53:06 +0900), Hidetoshi Seto <[EMAIL PROTECTED]> says: > Index: linux-2.6.13-rc1/lib/iomap.c > === > --- linux-2.6.13-rc1.orig/lib/iomap.c > +++ linux-2.6.13-rc1/lib/iomap.c > @@ -230,3 +230,9 @@ void pci_iounmap(struct pci_dev *dev, vo > } > EXPORT_SYMBOL(pci_iomap); > EXPORT_SYMBOL(pci_iounmap); > + > +#ifndef HAVE_ARCH_IOMAP_CHECK > +/* Since generic funcs are inlined and defined in header, just export */ > +EXPORT_SYMBOL(iochk_clear); > +EXPORT_SYMBOL(iochk_read); > +#endif > Index: linux-2.6.13-rc1/include/asm-generic/iomap.h > === > --- linux-2.6.13-rc1.orig/include/asm-generic/iomap.h > +++ linux-2.6.13-rc1/include/asm-generic/iomap.h : > + */ > +#ifdef HAVE_ARCH_IOMAP_CHECK > +extern void iochk_init(void); > +extern void iochk_clear(iocookie *cookie, struct pci_dev *dev); > +extern int iochk_read(iocookie *cookie); > +#else > +static inline void iochk_init(void) {} > +static inline void iochk_clear(iocookie *cookie, struct pci_dev *dev) {} > +static inline int iochk_read(iocookie *cookie) { return 0; } > +#endif > + > #endif It looks strange to me. You cannot export "static inline" functions. You can export iochk_{init,clear,read} only if HAVE_ARCH_IOMAP_CHECK is defined. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [17/48] Suspend2 2.1.9.8 for 2.6.12: 500-version-specific-i386.patch
In article <[EMAIL PROTECTED]> (at Wed, 6 Jul 2005 12:20:41 +1000), Nigel Cunningham <[EMAIL PROTECTED]> says: > #define local_flush_tlb() __flush_tlb() > +#define local_flush_tlb_all() __flush_tlb_all(); You should remove ";". > extern void flush_tlb_page(struct vm_area_struct *, unsigned long); > +extern void do_flush_tlb_all(void * info); > + > +#define local_flush_tlb_all() \ > + do_flush_tlb_all(NULL); > ditto --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] USB: compilation failure on usb/image/microtek.c
From: Hideaki YOSHIFUJI <[EMAIL PROTECTED]> maybe typo? Signed-off-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]> --- a/drivers/usb/image/microtek.c +++ b/drivers/usb/image/microtek.c @@ -335,7 +335,7 @@ static int mts_scsi_abort (Scsi_Cmnd *sr mts_urb_abort(desc); - return FAILURE; + return FAILED; } static int mts_scsi_host_reset (Scsi_Cmnd *srb) -- Hideaki YOSHIFUJI @ USAGI Project <[EMAIL PROTECTED]> Homepage: http://www.yoshifuji.org/~hideaki/ GPG FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] introduce generic 64bit rotations and i386 asm optimized version
In article <[EMAIL PROTECTED]> (at Tue, 19 Apr 2005 09:18:10 +0300), Denis Vlasenko <[EMAIL PROTECTED]> says: > diff -urpN 2.6.12-rc2.1.be/include/linux/bitops.h > 2.6.12-rc2.2.ror/include/linux/bitops.h > --- 2.6.12-rc2.1.be/include/linux/bitops.hMon Apr 18 22:55:10 2005 > +++ 2.6.12-rc2.2.ror/include/linux/bitops.h Tue Apr 19 00:25:28 2005 > @@ -41,7 +41,7 @@ static inline int generic_ffs(int x) > * fls: find last bit set. > */ > > -static __inline__ int generic_fls(int x) > +static inline int generic_fls(int x) > { > int r = 32; > > @@ -76,7 +76,7 @@ static __inline__ int generic_fls(int x) > */ > #include > > -static __inline__ int get_bitmask_order(unsigned int count) > +static inline int get_bitmask_order(unsigned int count) > { > int order; > Please keep using __inline__, not inline. > +#ifndef ARCH_HAS_ROL64 > +static inline __u64 rol64(__u64 word, unsigned int shift) > +{ > + return (word << shift) | (word >> (64 - shift)); > +} > +#endif : > +#ifndef ARCH_HAS_ROR64 > +static inline __u64 ror64(__u64 word, unsigned int shift) > +{ > + return (word >> shift) | (word << (64 - shift)); > +} > +#endif > > #endif please use __inline__, in header files. -- Hideaki YOSHIFUJI @ USAGI Project <[EMAIL PROTECTED]> Homepage: http://www.yoshifuji.org/~hideaki/ GPG FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/