Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 29 11月, 2007 8 次提交
    • S
      [TCP] illinois: Incorrect beta usage · a357dde9
      由 Stephen Hemminger 提交于 
      Lachlan Andrew observed that my TCP-Illinois implementation uses the
beta value incorrectly:
  The parameter  beta  in the paper specifies the amount to decrease
  *by*:  that is, on loss,
     W <-  W -  beta*W
  but in   tcp_illinois_ssthresh() uses  beta  as the amount
  to decrease  *to*: W <- beta*W

This bug makes the Linux TCP-Illinois get less-aggressive on uncongested network,
hurting performance. Note: since the base beta value is .5, it has no
impact on a congested network.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      a357dde9
    • H
      [IPSEC]: Fix uninitialised dst warning in __xfrm_lookup · 5e5234ff
      由 Herbert Xu 提交于 
      Andrew Morton reported that __xfrm_lookup generates this warning:

net/xfrm/xfrm_policy.c: In function '__xfrm_lookup':
net/xfrm/xfrm_policy.c:1449: warning: 'dst' may be used uninitialized in this function

This is because if policy->action is of an unexpected value then dst will
not be initialised.  Of course, in practice this should never happen since
the input layer xfrm_user/af_key will filter out all illegal values.  But
the compiler doesn't know that of course.

So this patch fixes this by taking the conservative approach and treat all
unknown actions the same as a blocking action.

Thanks to Andrew for finding this and providing an initial fix.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5e5234ff
    • P
      [INET]: Fix inet_diag register vs rcv race · 07693198
      由 Pavel Emelyanov 提交于 
      The following race is possible when one cpu unregisters the handler
while other one is trying to receive a message and call this one:

CPU1:                                                 CPU2:
inet_diag_rcv()                                       inet_diag_unregister()
  mutex_lock(&inet_diag_mutex);
  netlink_rcv_skb(skb, &inet_diag_rcv_msg);
    if (inet_diag_table[nlh->nlmsg_type] == 
                               NULL) /* false handler is still registered */
    ...
    netlink_dump_start(idiagnl, skb, nlh,
                           inet_diag_dump, NULL);
           cb = kzalloc(sizeof(*cb), GFP_KERNEL);
                   /* sleep here freeing memory 
                    * or preempt
                    * or sleep later on nlk->cb_mutex
                    */
                                                         spin_lock(&inet_diag_register_lock);
                                                         inet_diag_table[type] = NULL;
    ...                                                  spin_unlock(&inet_diag_register_lock);
                                                         synchronize_rcu();
                                                         /* CPU1 is sleeping - RCU quiescent
                                                          * state is passed
                                                          */
                                                         return;
    /* inet_diag_dump is finally called: */
    inet_diag_dump()
      handler = inet_diag_table[cb->nlh->nlmsg_type];
      BUG_ON(handler == NULL); 
      /* OOPS! While we slept the unregister has set
       * handler to NULL :(
       */

Grep showed, that the register/unregister functions are called
from init/fini module callbacks for tcp_/dccp_diag, so it's OK
to use the inet_diag_mutex to synchronize manipulations with the
inet_diag_table and the access to it.

Besides, as Herbert pointed out, asynchronous dumps should hold 
this mutex as well, and thus, we provide the mutex as cb_mutex one.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      07693198
    • P
      [BRIDGE]: Properly dereference the br_should_route_hook · 82de382c
      由 Pavel Emelyanov 提交于 
      This hook is protected with the RCU, so simple

	if (br_should_route_hook)
		br_should_route_hook(...)

is not enough on some architectures.

Use the rcu_dereference/rcu_assign_pointer in this case.

Fixed Stephen's comment concerning using the typeof().
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      82de382c
    • P
      [BRIDGE]: Lost call to br_fdb_fini() in br_init() error path · 17efdd45
      由 Pavel Emelyanov 提交于 
      In case the br_netfilter_init() (or any subsequent call) 
fails, the br_fdb_fini() must be called to free the allocated
in br_fdb_init() br_fdb_cache kmem cache.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      17efdd45
    • F
      [UNIX]: EOF on non-blocking SOCK_SEQPACKET · 0a112258
      由 Florian Zumbiehl 提交于 
      I am not absolutely sure whether this actually is a bug (as in: I've got
no clue what the standards say or what other implementations do), but at
least I was pretty surprised when I noticed that a recv() on a
non-blocking unix domain socket of type SOCK_SEQPACKET (which is connection
oriented, after all) where the remote end has closed the connection
returned -1 (EAGAIN) rather than 0 to indicate end of file.

This is a test case:

| #include <sys/types.h>
| #include <unistd.h>
| #include <sys/socket.h>
| #include <sys/un.h>
| #include <fcntl.h>
| #include <string.h>
| #include <stdlib.h>
| 
| int main(){
| 	int sock;
| 	struct sockaddr_un addr;
| 	char buf[4096];
| 	int pfds[2];
| 
| 	pipe(pfds);
| 	sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
| 	addr.sun_family=AF_UNIX;
| 	strcpy(addr.sun_path,"/tmp/foobar_testsock");
| 	bind(sock,(struct sockaddr *)&addr,sizeof(addr));
| 	listen(sock,1);
| 	if(fork()){
| 		close(sock);
| 		sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
| 		connect(sock,(struct sockaddr *)&addr,sizeof(addr));
| 		fcntl(sock,F_SETFL,fcntl(sock,F_GETFL)|O_NONBLOCK);
| 		close(pfds[1]);
| 		read(pfds[0],buf,sizeof(buf));
| 		recv(sock,buf,sizeof(buf),0); // <-- this one
| 	}else accept(sock,NULL,NULL);
| 	exit(0);
| }

If you try it, make sure /tmp/foobar_testsock doesn't exist.

The marked recv() returns -1 (EAGAIN) on 2.6.23.9. Below you find a
patch that fixes that.
Signed-off-by: NFlorian Zumbiehl <florz@florz.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0a112258
    • J
      [VLAN]: Fix nested VLAN transmit bug · 6ab3b487
      由 Joonwoo Park 提交于 
      Fix misbehavior of vlan_dev_hard_start_xmit() for recursive encapsulations.
Signed-off-by: NJoonwoo Park <joonwpark81@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6ab3b487
    • J
      [SUNGEM]: Fix NAPI regression with reset work · dde655c9
      由 Johannes Berg 提交于 
      sungem's gem_reset_task() will unconditionally try to disable NAPI even
when it's called while the interface is not operating and hence the NAPI
struct isn't enabled. Make napi_disable() depend on gp->running.

Also removes a superfluous test of gp->running in the same function.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      dde655c9
  3. 27 11月, 2007 2 次提交
  5. 26 11月, 2007 4 次提交
    • A
      [IPV4]: Remove bogus ifdef mess in arp_process · 3660019e
      由 Adrian Bunk 提交于 
      The #ifdef's in arp_process() were not only a mess, they were also wrong 
in the CONFIG_NET_ETHERNET=n and (CONFIG_NETDEV_1000=y or 
CONFIG_NETDEV_10000=y) cases.

Since they are not required this patch removes them.

Also removed are some #ifdef's around #include's that caused compile 
errors after this change.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      3660019e
    • H
      [SKBUFF]: Free old skb properly in skb_morph · 2d4baff8
      由 Herbert Xu 提交于 
      The skb_morph function only freed the data part of the dst skb, but leaked
the auxiliary data such as the netfilter fields.  This patch fixes this by
moving the relevant parts from __kfree_skb to skb_release_all and calling
it in skb_morph.

It also makes kfree_skbmem static since it's no longer called anywhere else
and it now no longer does skb_release_data.

Thanks to Yasuyuki KOZAKAI for finding this problem and posting a patch for
it.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2d4baff8
    • P
      [IPV4]: Fix memory leak in inet_hashtables.h when NUMA is on · 218ad12f
      由 Pavel Emelyanov 提交于 
      The inet_ehash_locks_alloc() looks like this:

#ifdef CONFIG_NUMA
	if (size > PAGE_SIZE)
		x = vmalloc(...);
	else
#endif
		x = kmalloc(...);

Unlike it, the inet_ehash_locks_alloc() looks like this:

#ifdef CONFIG_NUMA
	if (size > PAGE_SIZE)
		vfree(x);
	else
#else
		kfree(x);
#endif

The error is obvious - if the NUMA is on and the size
is less than the PAGE_SIZE we leak the pointer (kfree is
inside the #else branch).

Compiler doesn't warn us because after the kfree(x) there's
a "x = NULL" assignment, so here's another (minor?) bug: we 
don't set x to NULL under certain circumstances.

Boring explanation, I know... Patch explains it better.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      218ad12f
    • H
      [IPSEC]: Temporarily remove locks around copying of non-atomic fields · 8053fc3d
      由 Herbert Xu 提交于 
      The change 050f009e

	[IPSEC]: Lock state when copying non-atomic fields to user-space

caused a regression.

Ingo Molnar reports that it causes a potential dead-lock found by the
lock validator as it tries to take x->lock within xfrm_state_lock while
numerous other sites take the locks in opposite order.

For 2.6.24, the best fix is to simply remove the added locks as that puts
us back in the same state as we've been in for years.  For later kernels
a proper fix would be to reverse the locking order for every xfrm state
user such that if x->lock is taken together with xfrm_state_lock then
it is to be taken within it.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      8053fc3d
  7. 23 11月, 2007 2 次提交
  9. 22 11月, 2007 5 次提交
  11. 21 11月, 2007 11 次提交
  13. 20 11月, 2007 8 次提交