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/addrlabel: fix ip6addrlbl_get()
Cong Wang wrote:
> On Mon, Dec 21, 2015 at 1:54 AM, Andrey Ryabinin
> wrote:
>> ip6addrlbl_get() has never worked. If ip6addrlbl_hold() succeeded,
>> ip6addrlbl_get() will exit with '-ESRCH'. If ip6addrlbl_hold() failed,
>> ip6addrlbl_get() will use about to be free ip6addrlbl_entry pointer.
>>
>> Fix this by inverting ip6addrlbl_hold() check.
>>
>> Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address
>> selection policy table.")
>> Signed-off-by: Andrey Ryabinin
>
> Good catch!
>
> Reviewed-by: Cong Wang
Acked-by: YOSHIFUJI Hideaki
--
Hideaki Yoshifuji
Technical Division, MIRACLE LINUX CORPORATION
--
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] 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 4/9 net-next] ipv6: replace if/BUG by BUG_ON
Hi,
Fabian Frederick wrote:
> Signed-off-by: Fabian Frederick
> ---
> net/ipv6/addrconf.c | 3 +--
> net/ipv6/esp6.c | 3 +--
> net/ipv6/netfilter/nf_conntrack_reasm.c | 3 +--
> 3 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 2660263..e205918 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -4805,8 +4805,7 @@ static int inet6_set_link_af(struct net_device *dev,
> const struct nlattr *nla)
> if (!idev)
> return -EAFNOSUPPORT;
>
> - if (nla_parse_nested(tb, IFLA_INET6_MAX, nla, NULL) < 0)
> - BUG();
> + BUG_ON(nla_parse_nested(tb, IFLA_INET6_MAX, nla, NULL) < 0);
>
NACK, I do not prefer using BUG_ON() with side effects.
--yoshfuji
> if (tb[IFLA_INET6_TOKEN]) {
> err = inet6_set_iftoken(idev, nla_data(tb[IFLA_INET6_TOKEN]));
> diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
> index e48f2c7..9e51b69 100644
> --- a/net/ipv6/esp6.c
> +++ b/net/ipv6/esp6.c
> @@ -280,8 +280,7 @@ static int esp_input_done2(struct sk_buff *skb, int err)
> if (unlikely(err))
> goto out;
>
> - if (skb_copy_bits(skb, skb->len - alen - 2, nexthdr, 2))
> - BUG();
> + BUG_ON(skb_copy_bits(skb, skb->len - alen - 2, nexthdr, 2));
>
> err = -EINVAL;
> padlen = nexthdr[0];
> diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c
> b/net/ipv6/netfilter/nf_conntrack_reasm.c
> index 6f187c8..cea1a4a 100644
> --- a/net/ipv6/netfilter/nf_conntrack_reasm.c
> +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
> @@ -538,8 +538,7 @@ find_prev_fhdr(struct sk_buff *skb, u8 *prevhdrp, int
> *prevhoff, int *fhoff)
> pr_debug("too short\n");
> return -1;
> }
> - if (skb_copy_bits(skb, start, &hdr, sizeof(hdr)))
> - BUG();
> + BUG_ON(skb_copy_bits(skb, start, &hdr, sizeof(hdr)));
> if (nexthdr == NEXTHDR_AUTH)
> hdrlen = (hdr.hdrlen+2)<<2;
> else
>
--
Hideaki Yoshifuji
Technical Division, MIRACLE LINUX CORPORATION
--
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 net v2] ipv6: Prevent ipv6_find_hdr() from returning ENOENT for valid non-first fragments
Hi, Rahul Sharma wrote: ipv6_find_hdr() currently assumes that the next-header field in the fragment header of the non-first fragment is the "protocol number of the last header" (here last header excludes any extension header protocol numbers ) which is incorrect as per RFC2460. The next-header value is the first header of the fragmentable part of the original packet (which can be extension header as well). This can create reassembly problems. For example: Fragmented authenticated OSPFv3 packets (where AH header is inserted before the protocol header). For the second fragment, the next header value in the fragment header will be NEXTHDR_AUTH which is correct but ipv6_find_hdr will return ENOENT since AH is an extension header resulting in second fragment getting dropped. This check for the presence of non-extension header needs to be removed. Signed-off-by: Rahul Sharma Acked-by: YOSHIFUJI Hideaki -- Hideaki Yoshifuji Technical Division, MIRACLE LINUX CORPORATION -- 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/4] tun: Use iovec iterators
Hi,
Herbert Xu wrote:
Oops, this patch had a left-over skb_pull which made it broken.
Here is a fixed version.
tun: Use iovec iterators
This patch removes the use of skb_copy_datagram_const_iovec in
favour of the iovec iterator-based skb_copy_datagram_iter.
Signed-off-by: Herbert Xu
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 9dd3746..ff955cdb 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
:
@@ -1244,23 +1245,25 @@ static ssize_t tun_put_user(struct tun_struct *tun,
if (tun->flags & TUN_VNET_HDR)
vnet_hdr_sz = tun->vnet_hdr_sz;
+ total = skb->len + vlan_hlen + vnet_hdr_sz;
+
if (!(tun->flags & TUN_NO_PI)) {
- if ((len -= sizeof(pi)) < 0)
+ if (iov_iter_count(iter) < sizeof(pi))
return -EINVAL;
- if (len < skb->len + vlan_hlen + vnet_hdr_sz) {
+ if (iov_iter_count(iter) < total) {
I guess this should be: sizeof(pi) + total
--
Hideaki Yoshifuji
Technical Division, MIRACLE LINUX CORPORATION
--
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/
[PATCH] isdnloop: Validate NUL-terminated strings from user.
Return -EINVAL unless all of user-given strings are correctly
NUL-terminated.
Signed-off-by: YOSHIFUJI Hideaki
---
drivers/isdn/isdnloop/isdnloop.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/isdn/isdnloop/isdnloop.c b/drivers/isdn/isdnloop/isdnloop.c
index 02125e6..e1f8748 100644
--- a/drivers/isdn/isdnloop/isdnloop.c
+++ b/drivers/isdn/isdnloop/isdnloop.c
@@ -1070,6 +1070,12 @@ isdnloop_start(isdnloop_card *card, isdnloop_sdef *sdefp)
return -EBUSY;
if (copy_from_user((char *) &sdef, (char *) sdefp, sizeof(sdef)))
return -EFAULT;
+
+ for (i = 0; i < 3; i++) {
+ if (!memchr(sdef.num[i], 0, sizeof(sdef.num[i])))
+ return -EINVAL;
+ }
+
spin_lock_irqsave(&card->isdnloop_lock, flags);
switch (sdef.ptype) {
case ISDN_PTYPE_EURO:
--
1.7.9.5
--
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] isdnloop: NUL-terminate strings from userspace
Vegard Nossum wrote: > Both the in-kernel and BSD strlcpy() require that the source string is > NUL terminated. We could use strncpy() + explicitly terminate the result, > but this relies on src and dest having the same size, so the safest thing > to do seems to explicitly terminate the source string before doing the > strlcpy(). : > diff --git a/drivers/isdn/isdnloop/isdnloop.c > b/drivers/isdn/isdnloop/isdnloop.c > index 02125e6..50cd348 100644 > --- a/drivers/isdn/isdnloop/isdnloop.c > +++ b/drivers/isdn/isdnloop/isdnloop.c > @@ -1070,6 +1070,14 @@ isdnloop_start(isdnloop_card *card, isdnloop_sdef > *sdefp) > return -EBUSY; > if (copy_from_user((char *) &sdef, (char *) sdefp, sizeof(sdef))) > return -EFAULT; > + > + /* > + * Null terminate strings from userspace so we don't have to worry > + * about this later on. > + */ > + for (i = 0; i < 3; i++) > + sdef.num[i][sizeof(sdef.num[0]) - 1] = '\0'; > + Why don't we return -EINVAL if it is not correctly terminated by NUL? --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: Disable IPv4-mapped - enforce IPV6_V6ONLY
Hello.
Alexander Holler wrote:
> Am 22.02.2013 16:21, schrieb Alexander Holler:
>> Hello,
>>
>> I'm searching for a way to either enforce IPV6_V6ONLY or to block
>> IPv4-mapped addresses on ipv6-sockets (e.g. by using iptables) system-wide.
>>
>> E.g. net.ipv6.bindv6only doesn't help if something calls
>>
>> int v6on = 0;
>> setsockopt(sd, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&v6on, sizeof(v6on))
>>
>> In such a case I still want to disable or block IPv4-mapped addresses on
>> that socket, even if the program thinks it nows it better.
>>
>> Until now I haven't found a solution.
>
> I've now done it by the following hack:
>
> ---
> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> index d1e2e8e..9eefd3e 100644
> --- a/net/ipv6/ipv6_sockglue.c
> +++ b/net/ipv6/ipv6_sockglue.c
> @@ -235,7 +235,7 @@ static int do_ipv6_setsockopt(struct sock *sk, int level,
> int optname,
> if (optlen < sizeof(int) ||
> inet_sk(sk)->inet_num)
> goto e_inval;
> - np->ipv6only = valbool;
> + np->ipv6only = valbool || net->ipv6.sysctl.bindv6only;
> retv = 0;
> break;
> ---
>
> A proper solution would be to either return false if net.ipv6.bindv6only is
> true and optval is false (which would break downward compatibility because it
> wouldn't just be a default and setsockopt might return an error) or to
> introduce a new sysctl variable like net.ipv6.bindv6only_enforced_silently.
> ("silently" because setsockopt() wouldn't return an error if
> net.ipv6.bindv6only is true and optval (v6only in the example above) is
> false.)
>
> I would volunteer to write a patch which introduces something like
> net.ipv6.bindv6only_enforced_silently if some maintainer would give me his ok.
>
> If so, the question remains if
>
> systemctl net.ipv6.bindv6only_enforced_silently = 1
>
> should set systemctl.net.ipv6.bindv6only too or if an error should be
> returned if net.ipv6.bindv6only is false.
I am not convinced why you need this, and I am not in favor of
enfocing IPV6_V6ONLY, but... some points:
- We should allow system-admin to "enforce" IPV6_V6ONLY to 0 as well.
- CAP_NET_ADMIN users should always be able to use both modes
(They can do sysctl anyway.)
- setsockopt should fail w/ EPERM if user tries to override.
--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: WARNING: at net/core/neighbour.c:1545 neigh_table_init()
Eric Dumazet wrote:
> On Sat, 2013-02-09 at 20:39 +0800, Fengguang Wu wrote:
>> Greetings,
>>
>> I got the below oops in linux-next and the first bad commit is
>>
>> commit 455e987c0c2eb2c9045dc854559474cf41509965
>> Merge: 7c17e48 fd6da69
>> Author: Linus Torvalds
>> Date: Sat Dec 1 13:07:48 2012 -0800
>>
>> Merge branch 'perf-urgent-for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>
>> Pull perf fixes from Ingo Molnar:
>> "This is mostly about unbreaking architectures that took the UAPI
>> changes in the v3.7 cycle, plus misc fixes."
>>
>> * 'perf-urgent-for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
>> perf kvm: Fix building perf kvm on non x86 arches
>> perf kvm: Rename perf_kvm to perf_kvm_stat
>> perf: Make perf build for x86 with UAPI disintegration applied
>> perf powerpc: Use uapi/unistd.h to fix build error
>> tools: Pass the target in descend
>> tools: Honour the O= flag when tool build called from a higher Makefile
>> tools: Define a Makefile function to do subdir processing
>> x86: Export asm/{svm.h,vmx.h,perf_regs.h}
>> perf tools: Fix strbuf_addf() when the buffer needs to grow
>> perf header: Fix numa topology printing
>> perf, powerpc: Fix hw breakpoints returning -ENOSPC
>>
>> [ 108.102297] NET4: DECnet for Linux: V.2.5.68s (C) 1995-2003 Linux DECnet
>> Project Team
>> [ 108.105501] [ cut here ]
>> [ 108.106286] WARNING: at
>> /c/kernel-tests/src/i386/net/core/neighbour.c:1545
>> neigh_table_init+0x16f/0x490()
>> [ 108.107506] Hardware name: Bochs
>> [ 108.108577] Pid: 1, comm: swapper Not tainted 3.8.0-rc5-01118-geee5035 #17
>> [ 108.109506] Call Trace:
>> [ 108.79] [] warn_slowpath_common+0xf2/0x140
>> [ 108.112064] [] ? neigh_table_init+0x16f/0x490
>> [ 108.112880] [] ? neigh_table_init+0x16f/0x490
>> [ 108.114164] [] ? atm_clip_init+0x98/0x98
>> [ 108.115409] [] warn_slowpath_null+0x39/0x50
>> [ 108.116776] [] neigh_table_init+0x16f/0x490
>> [ 108.118169] [] ? mutex_unlock+0x16/0x30
>> [ 108.119260] [] ? proto_register+0x65/0x350
>> [ 108.120016] [] ? atm_clip_init+0x98/0x98
>> [ 108.121591] [] dn_neigh_init+0x1b/0x2b
>> [ 108.122305] [] decnet_init+0x67/0xfc
>> [ 108.123169] [] do_one_initcall+0xf2/0x259
>> [ 108.124259] [] kernel_init_freeable+0x223/0x393
>> [ 108.125053] [] ? loglevel+0x55/0x55
>> [ 108.125712] [] kernel_init+0x19/0x200
>> [ 108.126411] [] ret_from_kernel_thread+0x1b/0x30
>> [ 108.127194] [] ? rest_init+0x1f0/0x1f0
>> [ 108.128351] ---[ end trace 1bcbb5f262552fec ]---
>>
>> git bisect start v3.7 v3.6 --
>> git bisect good d66e6737d454553e1e62109d8298ede5351178a4 #10
>> 2013-02-09 11:28:24 Merge
>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
>> git bisect good e1b28147f684af67bfac989756c27c19859d3d4e #10
>> 2013-02-09 11:58:58 Merge branch 'for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
>> git bisect good 37820108f395032e850e400139d956561a043c26 #10
>> 2013-02-09 12:28:59 Merge tag 'fixes-for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
>> git bisect good 60541d778e536455970281de25b2476e01c03aef #10
>> 2013-02-09 12:59:29 unicore32: switch to generic sys_execve()
>> git bisect good 403f43c937d24832b18524f65415c0bbba6b5064 #10
>> 2013-02-09 13:29:53 team: bcast: convert return value of
>> team_dev_queue_xmit() to bool correctly
>> git bisect good e23739b4ade80a3a7f87198f008f6c44a7cbc9fd #10
>> 2013-02-09 14:00:15 Merge branch 'v4l_for_linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
>> git bisect bad 455e987c0c2eb2c9045dc854559474cf41509965 # 0
>> 2013-02-09 14:03:12 Merge branch 'perf-urgent-for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>> git bisect good 50a53bbe1280839755cb120eef729ad150f644f9 #10
>> 2013-02-09 14:31:02 Merge branch 'akpm' (Fixes from Andrew)
>> git bisect good 31e06a42a34395111842707a85774151245447b7 #10
>> 2013-02-09 15:01:25 Merge branch 'for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal
>> git bisect good 97a13bf3fed11a7508d58b67515c4b83cce25540 #10
>> 2013-02-09 15:31:48 Merge tag 'perf-uapi-20121119' of
>> git://git.infradead.org/users/dhowells/linux-headers into perf/urgent
>> git bisect good 8fdd78eeb11aeda018b22424f863344ef83a92d3 #10
>> 2013-02-09 16:02:24 Merge tag 'for-linus' of
>> git://linux-c6x.org/git/projects/linux-c6x-upstreaming
>> git bisect good 7c17e486e865d616f0e37c7f7f0e4dcfab704cd8 #10
>> 2013-02-09 16:32:42 Merge branch 'x86/urgent' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>> git bisect good 7321090f6751c9987c26a8c81c63680d16a614d7 #10
>> 2013-02-09 17:03:13 perf kvm: Fix building perf kvm on non x86 arches
>> git bisec
[PATCH net-next] net neighbour,decnet: Ensure to align device private data on preferred alignment.
To allow both of protocol-specific data and device-specific data
attached with neighbour entry, and to eliminate size calculation
cost when allocating entry, sizeof protocol-speicic data must be
multiple of NEIGH_PRIV_ALIGN. On 64bit archs,
sizeof(struct dn_neigh) is multiple of NEIGH_PRIV_ALIGN, but on
32bit archs, it was not.
Introduce NEIGH_ENTRY_SPACE() macro to ensure that protocol-specific
entry-size meets our requirement.
Reported-by: Fengguang Wu
Signed-off-by: YOSHIFUJI Hideaki
---
include/net/neighbour.h |1 +
net/decnet/dn_neigh.c |2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index 629ee57..7e748ad 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -181,6 +181,7 @@ struct neigh_table {
};
#define NEIGH_PRIV_ALIGN sizeof(long long)
+#define NEIGH_ENTRY_SIZE(size) ALIGN((size), NEIGH_PRIV_ALIGN)
static inline void *neighbour_priv(const struct neighbour *n)
{
diff --git a/net/decnet/dn_neigh.c b/net/decnet/dn_neigh.c
index 3aede1b..856636a 100644
--- a/net/decnet/dn_neigh.c
+++ b/net/decnet/dn_neigh.c
@@ -95,7 +95,7 @@ static u32 dn_neigh_hash(const void *pkey,
struct neigh_table dn_neigh_table = {
.family = PF_DECnet,
- .entry_size = sizeof(struct dn_neigh),
+ .entry_size = NEIGH_ENTRY_SIZE(sizeof(struct
dn_neigh)),
.key_len = sizeof(__le16),
.hash = dn_neigh_hash,
.constructor = dn_neigh_construct,
--
1.7.9.5
--
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/
[PATCH] digsig: Fix memory leakage in digsig_verify_rsa().
digsig_verify_rsa() does not free kmalloc'ed buffer returned by mpi_get_buffer(). Signed-off-by: YOSHIFUJI Hideaki --- lib/digsig.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/digsig.c b/lib/digsig.c index 8c0e629..dc2be7e 100644 --- a/lib/digsig.c +++ b/lib/digsig.c @@ -162,6 +162,8 @@ static int digsig_verify_rsa(struct key *key, memset(out1, 0, head); memcpy(out1 + head, p, l); + kfree(p); + err = pkcs_1_v1_5_decode_emsa(out1, len, mblen, out2, &len); if (err) goto err; -- 1.7.9.5 -- 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] CMAC support for CryptoAPI, fixed patch issues, indent, and testmgr build issues
YOSHIFUJI Hideaki wrote:
> Jussi Kivilinna wrote:
>
>>>>> diff --git a/include/uapi/linux/pfkeyv2.h
>>>>> b/include/uapi/linux/pfkeyv2.h
>>>>> index 0b80c80..d61898e 100644
>>>>> --- a/include/uapi/linux/pfkeyv2.h
>>>>> +++ b/include/uapi/linux/pfkeyv2.h
>>>>> @@ -296,6 +296,7 @@ struct sadb_x_kmaddress {
>>>>> #define SADB_X_AALG_SHA2_512HMAC7
>>>>> #define SADB_X_AALG_RIPEMD160HMAC8
>>>>> #define SADB_X_AALG_AES_XCBC_MAC9
>>>>> +#define SADB_X_AALG_AES_CMAC_MAC10
>>>>> #define SADB_X_AALG_NULL251/* kame */
>>>>> #define SADB_AALG_MAX251
>>>>
>>>> Should these values be based on IANA assigned IPSEC AH transform
>>>> identifiers?
>>>>
>>>> https://www.iana.org/assignments/isakmp-registry/isakmp-registry.xml#isakmp-registry-6
>>>
>>> There is no CMAC entry apparently ... despite the fact that CMAC is a
>>> proposed RFC standard for IPsec.
>>>
>>> It might be safer to move that to 14 since it's currently unassigned and
>>> then go through whatever channels are required to allocate it. Mostly this
>>> affects key setting. So this means my patch would break AH_RSA setkey
>>> calls (which the kernel doesn't support anyways).
>>>
>>
>> Problem seems to be that PFKEYv2 does not quite work with IKEv2, and XFRM
>> API should be used instead. There is new numbers assigned for IKEv2:
>> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-7
>>
>> For new SADB_X_AALG_*, I'd think you should use value from "Reserved for
>> private use" range. Maybe 250?
>
> We can choose any value unless we do not break existing
> binaries. When IKE used, the daemon is responsible
> for translation.
I meant, we can choose any values "if" we do not break ...
--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] CMAC support for CryptoAPI, fixed patch issues, indent, and testmgr build issues
Jussi Kivilinna wrote:
>>> > diff --git a/include/uapi/linux/pfkeyv2.h
>>> > b/include/uapi/linux/pfkeyv2.h
>>> > index 0b80c80..d61898e 100644
>>> > --- a/include/uapi/linux/pfkeyv2.h
>>> > +++ b/include/uapi/linux/pfkeyv2.h
>>> > @@ -296,6 +296,7 @@ struct sadb_x_kmaddress {
>>> > #define SADB_X_AALG_SHA2_512HMAC7
>>> > #define SADB_X_AALG_RIPEMD160HMAC8
>>> > #define SADB_X_AALG_AES_XCBC_MAC9
>>> > +#define SADB_X_AALG_AES_CMAC_MAC10
>>> > #define SADB_X_AALG_NULL251/* kame */
>>> > #define SADB_AALG_MAX251
>>>
>>> Should these values be based on IANA assigned IPSEC AH transform
>>> identifiers?
>>>
>>> https://www.iana.org/assignments/isakmp-registry/isakmp-registry.xml#isakmp-registry-6
>>
>> There is no CMAC entry apparently ... despite the fact that CMAC is a
>> proposed RFC standard for IPsec.
>>
>> It might be safer to move that to 14 since it's currently unassigned and
>> then go through whatever channels are required to allocate it. Mostly this
>> affects key setting. So this means my patch would break AH_RSA setkey calls
>> (which the kernel doesn't support anyways).
>>
>
> Problem seems to be that PFKEYv2 does not quite work with IKEv2, and XFRM API
> should be used instead. There is new numbers assigned for IKEv2:
> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-7
>
> For new SADB_X_AALG_*, I'd think you should use value from "Reserved for
> private use" range. Maybe 250?
We can choose any value unless we do not break existing
binaries. When IKE used, the daemon is responsible
for translation.
--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] firewire net: Ensure checksumming in upper layer.
Stephan Gatzka wrote: > >> "Off-link source" means the source exists on the different L2 >> network. In other words, source is connected via router(s). >> >> ethernet firewire >> Host -- Router Host >> > > O.k., understood. But the receiving router verifies the checksum of incoming > packets and sends them on the firewire link. On firewire we have CRC > checksums to ensure the integrity of packets. > > I agree with your patch but I don't see why we should check them in the > driver. I thought your patch will ensure that the checksums will be verified > in the upper layers. Routers do not inspect whole packet. For IPv4, we have IP checksum, but routers (usually) do not check upper-layer (e.g. UDP) checksum. For IPv6, we do not have IP checksum. CHECKSUM_UNNECESSARY means the driver has verified upper layer (e.g. TCP/UDP) checksum. Modern hardware can perform upper-layer checksumming as well. But of course, not all drivers are required to verify the upper-layer checksum; if the driver do not verify checksum in the packet, just say CHECKSUM_NONE. Regards, --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] firewire net: Ensure checksumming in upper layer.
Stephan Gatzka wrote: > >>> Indeed neither the device nor the lower drivers check protocol checksums. >>> But the CRCs of the encapsulating 1394 packets are checked in hardware. >>> Shall protocol checksums be verified regardless? >> >> Yes, because packets may come from off-link source. >> > > Hm, I can't see any off-link packets coming from > fwnet_finish_incoming_packet() > > So I wont verify checksums in the driver. "Off-link source" means the source exists on the different L2 network. In other words, source is connected via router(s). ethernet firewire Host -- Router Host --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] firewire net: Ensure checksumming in upper layer.
Stefan Richter wrote: > On Jan 20 YOSHIFUJI Hideaki wrote: >> It is wrong to set skb->ip_summed to CHECKSUM_UNNECESSARY unless >> the device has already checked it. >> >> Signed-off-by: YOSHIFUJI Hideaki >> --- >> drivers/firewire/net.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c >> index e7a711f5..df6a1ca 100644 >> --- a/drivers/firewire/net.c >> +++ b/drivers/firewire/net.c >> @@ -520,7 +520,7 @@ static int fwnet_finish_incoming_packet(struct >> net_device *net, >> dev = netdev_priv(net); >> /* Write metadata, and then pass to the receive level */ >> skb->dev = net; >> -skb->ip_summed = CHECKSUM_UNNECESSARY; /* don't check it */ >> +skb->ip_summed = CHECKSUM_NONE; >> >> /* >> * Parse the encapsulation header. This actually does the job of > > Indeed neither the device nor the lower drivers check protocol checksums. > But the CRCs of the encapsulating 1394 packets are checked in hardware. > Shall protocol checksums be verified regardless? Yes, because packets may come from off-link source. --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/
[PATCH] firewire net: Use LL_RESERVED_SPACE(), HH_DATA_OFF().
Signed-off-by: YOSHIFUJI Hideaki
---
drivers/firewire/net.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index df6a1ca..2b27bff 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -270,7 +270,7 @@ static int fwnet_header_cache(const struct neighbour *neigh,
if (type == cpu_to_be16(ETH_P_802_3))
return -1;
net = neigh->dev;
- h = (struct fwnet_header *)((u8 *)hh->hh_data + 16 - sizeof(*h));
+ h = (struct fwnet_header *)((u8 *)hh->hh_data +
HH_DATA_OFF(sizeof(*h)));
h->h_proto = type;
memcpy(h->h_dest, neigh->ha, net->addr_len);
hh->hh_len = FWNET_HLEN;
@@ -282,7 +282,7 @@ static int fwnet_header_cache(const struct neighbour *neigh,
static void fwnet_header_cache_update(struct hh_cache *hh,
const struct net_device *net, const unsigned char *haddr)
{
- memcpy((u8 *)hh->hh_data + 16 - FWNET_HLEN, haddr, net->addr_len);
+ memcpy((u8 *)hh->hh_data + HH_DATA_OFF(FWNET_HLEN), haddr,
net->addr_len);
}
static int fwnet_header_parse(const struct sk_buff *skb, unsigned char *haddr)
@@ -398,11 +398,11 @@ static struct fwnet_partial_datagram *fwnet_pd_new(struct
net_device *net,
new->datagram_label = datagram_label;
new->datagram_size = dg_size;
- new->skb = dev_alloc_skb(dg_size + net->hard_header_len + 15);
+ new->skb = dev_alloc_skb(dg_size + LL_RESERVED_SPACE(net));
if (new->skb == NULL)
goto fail_w_fi;
- skb_reserve(new->skb, (net->hard_header_len + 15) & ~15);
+ skb_reserve(new->skb, LL_RESERVED_SPACE(net));
new->pbuf = skb_put(new->skb, dg_size);
memcpy(new->pbuf + frag_off, frag_buf, frag_len);
list_add_tail(&new->pd_link, &peer->pd_list);
@@ -690,14 +690,14 @@ static int fwnet_incoming_packet(struct fwnet_device
*dev, __be32 *buf, int len,
buf++;
len -= RFC2374_UNFRAG_HDR_SIZE;
- skb = dev_alloc_skb(len + net->hard_header_len + 15);
+ skb = dev_alloc_skb(len + LL_RESERVED_SPACE(net));
if (unlikely(!skb)) {
dev_err(&net->dev, "out of memory\n");
net->stats.rx_dropped++;
return -ENOMEM;
}
- skb_reserve(skb, (net->hard_header_len + 15) & ~15);
+ skb_reserve(skb, LL_RESERVED_SPACE(net));
memcpy(skb_put(skb, len), buf, len);
return fwnet_finish_incoming_packet(net, skb, source_node_id,
--
1.7.9.5
--
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/
[PATCH] firewire net: Ensure checksumming in upper layer.
It is wrong to set skb->ip_summed to CHECKSUM_UNNECESSARY unless the device has already checked it. Signed-off-by: YOSHIFUJI Hideaki --- drivers/firewire/net.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c index e7a711f5..df6a1ca 100644 --- a/drivers/firewire/net.c +++ b/drivers/firewire/net.c @@ -520,7 +520,7 @@ static int fwnet_finish_incoming_packet(struct net_device *net, dev = netdev_priv(net); /* Write metadata, and then pass to the receive level */ skb->dev = net; - skb->ip_summed = CHECKSUM_UNNECESSARY; /* don't check it */ + skb->ip_summed = CHECKSUM_NONE; /* * Parse the encapsulation header. This actually does the job of -- 1.7.9.5 -- 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: Redefinition of struct in6_addr in and
Carlos O'Donell wrote:
> On 01/18/2013 05:44 AM, Pedro Alves wrote:
>> On 01/18/2013 04:22 AM, Carlos O'Donell wrote:
>>> On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger wrote:
On Wednesday 16 January 2013 22:15:38 David Miller wrote:
> From: Carlos O'Donell
> Date: Wed, 16 Jan 2013 21:15:03 -0500
>
>> +/* If a glibc-based userspace has already included in.h, then we will
>> not + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq.
>> The + * ABI used by the kernel and by glibc match exactly. Neither the
>> kernel + * nor glibc should break this ABI without coordination.
>> + */
>> +#ifndef _NETINET_IN_H
>> +
>
> I think we should shoot for a non-glibc-centric solution.
>
> I can't imagine that other libc's won't have the same exact problem
> with their netinet/in.h conflicting with the kernel's, redefining
> structures like in6_addr, that we'd want to provide a protection
> scheme for here as well.
yes, the kernel's use of __GLIBC__ in exported headers has already caused
problems in the past. fortunately, it's been reduced down to just one case
now (stat.h). let's not balloon it back up.
-mike
>>>
>>> I also see coda.h has grown a __GLIBC__ usage.
>>>
>>> In the next revision of the patch I created a single libc-compat.h header
>>> which encompasses the logic for any libc that wants to coordinate with
>>> the kernel headers.
>>
>>
>>> It's simple enough to move all of the __GLIBC__ uses into libc-compat.h,
>>> then you control userspace libc coordination from one file.
>>
>> How about just deciding on a single macro/symbol both the
>> kernel and libc (any libc that needs this) define? Something
>> like both the kernel and userland doing:
>>
>> #ifndef __IPV6_BITS_DEFINED
>> #define __IPV6_BITS_DEFINED
>> ...
>> define in6_addr, sockaddr_in6, ipv6_mreq, whatnot
>> #endif
Hmm, how should we handle future structs/enums then?
For example, if I want to have in6_flowlabel_req{} defined in
glibc, what should we do?
We probably want to have __LIBC_HAS_STRUCT_IN6_FLOWLABEL_REQ
defined.
--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: Redefinition of struct in6_addr in and
Carlos O'Donell wrote:
> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
> index f79c372..a2b16a5 100644
> --- a/include/uapi/linux/in6.h
> +++ b/include/uapi/linux/in6.h
> @@ -23,6 +23,13 @@
>
> #include
>
> +/* If a glibc-based userspace has already included in.h, then we will not
> + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq. The
> + * ABI used by the kernel and by glibc match exactly. Neither the kernel
> + * nor glibc should break this ABI without coordination.
> + */
> +#ifndef _NETINET_IN_H
> +
> /*
> * IPv6 address structure
> */
This should be
#if !defined(__GLIBC__) || !defined(_NETINET_IN_H)
> @@ -30,12 +37,20 @@
> struct in6_addr {
> union {
> __u8u6_addr8[16];
> +#if !defined(__GLIBC__) \
> +|| (defined(__GLIBC__) && (defined(__USE_MISC) || defined(__USE_GNU))) \
> +|| defined(__KERNEL__)
> __be16 u6_addr16[8];
> __be32 u6_addr32[4];
> +#endif
> } in6_u;
> +#if !defined(__GLIBC__) \
> +|| (defined(__GLIBC__) && (defined(__USE_MISC) || defined(__USE_GNU))) \
> +|| defined(__KERNEL__)
> #define s6_addr in6_u.u6_addr8
> #define s6_addr16in6_u.u6_addr16
> #define s6_addr32in6_u.u6_addr32
> +#endif
> };
2nd "if" be after s6_addr?
--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: Redefinition of struct in6_addr in and
Carlos O'Donell wrote: > diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h > index f79c372..a2b16a5 100644 > --- a/include/uapi/linux/in6.h > +++ b/include/uapi/linux/in6.h : > #define IPV6_PRIORITY_14 0x0e00 > #define IPV6_PRIORITY_15 0x0f00 > > + > +#ifndef _NETINET_IN_H > +#if defined (__GLIBC__) > +/* Include all of the other IPPROTO_* defines for userspace. */ > +#include > +#endif > /* > * IPV6 extension headers Overall, it looks good, but why including linux/ipproto.h? --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: Redefinition of struct in6_addr in and
Cong Wang wrote:
> (Cc'ing some glibc developers...)
>
> Hello,
>
> In glibc source file inet/netinet/in.h and kernel source file
> include/uapi/linux/in6.h, both define struct in6_addr, and both are
> visible to user applications. Thomas reported a conflict below.
>
> So, how can we handle this? /me is wondering why we didn't see this
> before.
>
> Thanks.
>
> On Tue, 2013-01-15 at 12:55 +0200, Thomas Backlund wrote:
>> Cong Wang skrev 15.1.2013 12:11:
>>>
>>> Does the following patch help?
>>>
>>> $ git diff include/uapi/linux/if_bridge.h
>>> diff --git a/include/uapi/linux/if_bridge.h
>>> b/include/uapi/linux/if_bridge.h
>>> index 5db2975..653db23 100644
>>> --- a/include/uapi/linux/if_bridge.h
>>> +++ b/include/uapi/linux/if_bridge.h
>>> @@ -14,6 +14,7 @@
>>> #define _UAPI_LINUX_IF_BRIDGE_H
>>>
>>> #include
>>> +#include
>>>
>>> #define SYSFS_BRIDGE_ATTR "bridge"
>>> #define SYSFS_BRIDGE_FDB "brforward"
>>>
>>
>> Well, I suggested the same fix in the beginning of the thread
>> on netdev and lkml: "if_bridge.h: include in6.h for struct in6_addr use"
>>
>> as it seemed to fix the libvirt case
>>
>> but then asked it to be ignored after I tried to build connman,
>> and hit this conflict with glibc-2.17:
>>
>> In file included from /usr/include/arpa/inet.h:22:0,
>> from ./include/connman/inet.h:25,
>> from src/connman.h:128,
>> from src/tethering.c:40:
>> /usr/include/netinet/in.h:35:5: error: expected identifier before
>> numeric constant
>> /usr/include/netinet/in.h:197:8: error: redefinition of 'struct in6_addr'
>> In file included from /usr/include/linux/if_bridge.h:17:0,
>> from src/tethering.c:38:
>> /usr/include/linux/in6.h:30:8: note: originally defined here
>> In file included from /usr/include/arpa/inet.h:22:0,
>> from ./include/connman/inet.h:25,
>> from src/connman.h:128,
>> from src/tethering.c:40:
>> /usr/include/netinet/in.h:238:8: error: redefinition of 'struct
>> sockaddr_in6'
>> In file included from /usr/include/linux/if_bridge.h:17:0,
>> from src/tethering.c:38:
>> /usr/include/linux/in6.h:46:8: note: originally defined here
>> In file included from /usr/include/arpa/inet.h:22:0,
>> from ./include/connman/inet.h:25,
>> from src/connman.h:128,
>> from src/tethering.c:40:
>> /usr/include/netinet/in.h:274:8: error: redefinition of 'struct ipv6_mreq'
>> In file included from /usr/include/linux/if_bridge.h:17:0,
>> from src/tethering.c:38:
>> /usr/include/linux/in6.h:54:8: note: originally defined here
>> make[1]: *** [src/src_connmand-tethering.o] Error 1
>>
>>
>> So I'm not sure it's the right one...
This is not a new issue. In addition to this,
netinet/in.h also conflits with linux/in.h.
We might have
#if !defined(__GLIBC__) || !defined(_NETINET_IN_H)
:
#endif
around those conflicting definitions in uapi/linux/in{,6}.h.
--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 1/1] ipv6: fix the noflags test in addrconf_get_prefix_route
Romain KUNTZ wrote: > From e7ece201c35615c44a3cfdc10ee28ad5a5878f41 Mon Sep 17 00:00:00 2001 > From: Romain Kuntz > Date: Wed, 9 Jan 2013 15:02:26 +0100 > Subject: [PATCH 1/1] ipv6: fix the noflags test in addrconf_get_prefix_route > > The tests on the flags in addrconf_get_prefix_route() does no make > much sense: the 'noflags' parameter contains the set of flags that > must not match with the route flags, so the test must be done > against 'noflags', and not against 'flags'. > > Signed-off-by: Romain Kuntz > --- > net/ipv6/addrconf.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c > index 408cac4a..29ba4ff 100644 > --- a/net/ipv6/addrconf.c > +++ b/net/ipv6/addrconf.c > @@ -1877,7 +1877,7 @@ static struct rt6_info *addrconf_get_prefix_route(const > struct in6_addr *pfx, > continue; > if ((rt->rt6i_flags & flags) != flags) > continue; > - if ((noflags != 0) && ((rt->rt6i_flags & flags) != 0)) > + if ((rt->rt6i_flags & noflags) != 0) > continue; > dst_hold(&rt->dst); > break; > Acked-by: YOSHIFUJI Hideaki --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: [IPv6] crashed when __ip6_del_rt()
stanley zhou wrote:
> when call write_lock_bh() table is null cause crash in __ip6_del_rt().
> kernel version is 2.6.30.10
:
> static int __ip6_del_rt(struct rt6_info *rt, struct nl_info *info)
> {
> int err;
> struct fib6_table *table;
> struct net *net = dev_net(rt->rt6i_dev);
>
> if (rt == net->ipv6.ip6_null_entry) {
> +++err = -ENOENT;
> +++goto out;
> --- return -ENOENT;
> }
>
> table = rt->rt6i_table;
> write_lock_bh(&table->tb6_lock);
> err = fib6_del(rt, info);
> write_unlock_bh(&table->tb6_lock);
> +++out:
> dst_release(&rt->u.dst);
> return err;
> }
>
I think this is what commit 6825a26c ("ipv6: release reference of
ip6_null_entry's dst entry in __ip6_del_rt") by Gao feng
does, which is already in v3.7.
Are you suggesting that we should have this in -stable tree as well?
--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/
Re: Off-by-one bug at unix_mkname ?
In article <[EMAIL PROTECTED]> (at Mon, 28 Mar 2005 11:25:39 +0200 (MEST)), Jan (BEngelhardt <[EMAIL PROTECTED]> says: (B (B> (B> On Mar 28 2005 17:39, YOSHIFUJI Hideaki / [EMAIL PROTECTED](B wrote: (B> (B> >+ * This may look like an off by one error but it is (B> >+ * a bit more subtle. 108 is the longest valid AF_UNIX (B> >+ * path for a binding. sun_path[108] doesnt as such (B> >+ * exist. However in kernel space we are guaranteed that (B> >+ * it is a valid memory location in our kernel (B> >+ * address buffer. (B> >+ */ (B> (B> Now, does 2.6. _still_ guarantee that 108 is a valid offset? (B (BYes, it does. (B (B--yoshfuji (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: Off-by-one bug at unix_mkname ?
In article <[EMAIL PROTECTED]> (at Mon, 28 Mar 2005 17:39:38 +0900 (JST)),
(BYOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> says:
(B
(B> So, I'd suggest to put the comment back to 2.4/2.6 instead.
(B> (Note: net/socket.c refers this around MAX_SOCK_ADDR definition.)
(B>
(B> Signed-off-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]>
(B
(BOops, sorry, I made a mistake when I did copy-n-paste...
(B
(BSigned-off-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]>
(B
(B= net/unix/af_unix.c 1.73 vs edited =
(B--- 1.73/net/unix/af_unix.c 2005-03-10 13:42:53 +09:00
(B+++ edited/net/unix/af_unix.c 2005-03-28 17:45:26 +09:00
(B@@ -188,6 +188,14 @@
(Bif (!sunaddr || sunaddr->sun_family != AF_UNIX)
(Breturn -EINVAL;
(Bif (sunaddr->sun_path[0]) {
(B+ /*
(B+* This may look like an off by one error but it is
(B+* a bit more subtle. 108 is the longest valid AF_UNIX
(B+* path for a binding. sun_path[108] doesnt as such
(B+* exist. However in kernel space we are guaranteed that
(B+* it is a valid memory location in our kernel
(B+* address buffer.
(B+*/
(B((char *)sunaddr)[len]=0;
(Blen = strlen(sunaddr->sun_path)+1+sizeof(short);
(Breturn len;
(B
(B--
(BHideaki YOSHIFUJI @ USAGI Project <[EMAIL PROTECTED]>
(BGPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at http://www.tux.org/lkml/
Re: Off-by-one bug at unix_mkname ?
In article <[EMAIL PROTECTED]> (at Mon, 28 Mar 2005 17:21:08 +0900 (JST)),
(BYOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> says:
(B
(B> > It seems to me that the following code is off-by-one bug.
(B:
(B> Well, 2.2 has some comment on this:
(B
(BSo, I'd suggest to put the comment back to 2.4/2.6 instead.
(B(Note: net/socket.c refers this around MAX_SOCK_ADDR definition.)
(B
(BSigned-off-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]>
(B
(B= net/unix/af_unix.c 1.73 vs edited =
(B--- 1.73/net/unix/af_unix.c 2005-03-10 13:42:53 +09:00
(B+++ edited/net/unix/af_unix.c 2005-03-28 17:31:33 +09:00
(B@@ -188,6 +188,15 @@
(Bif (!sunaddr || sunaddr->sun_family != AF_UNIX)
(Breturn -EINVAL;
(Bif (sunaddr->sun_path[0]) {
(B+ /*
(B+* This may look like an off by one error but it is
(B+* a bit more subtle. 108 is the longest valid AF_UNIX
(B+* path for a binding. sun_path[108] doesnt as such
(B+* exist. However in kernel space we are guaranteed that
(B+* it is a valid memory location in our kernel
(B+* address buffer.
(B+*/
(B+ if (len > sizeof(*sunaddr))
(B((char *)sunaddr)[len]=0;
(Blen = strlen(sunaddr->sun_path)+1+sizeof(short);
(Breturn len;
(B
(B--
(BHideaki YOSHIFUJI @ USAGI Project <[EMAIL PROTECTED]>
(BGPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at http://www.tux.org/lkml/
