Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 27 5月, 2006 2 次提交
  3. 24 5月, 2006 5 次提交
    • S
      [BRIDGE]: need to ref count the LLC sap · 387e2b04
      由 Stephen Hemminger 提交于 
      Bridge will OOPS on removal if other application has the SAP open.
The bridge SAP might be shared with other usages, so need
to do reference counting on module removal rather than explicit
close/delete.

Since packet might arrive after or during removal, need to clear
the receive function handle, so LLC only hands it to user (if any).
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      387e2b04
    • C
      [NETFILTER]: SNMP NAT: fix memleak in snmp_object_decode · 4a063739
      由 Chris Wright 提交于 
      If kmalloc fails, error path leaks data allocated from asn1_oid_decode().
Signed-off-by: NChris Wright <chrisw@sous-sol.org>
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a063739
    • P
      [NETFILTER]: H.323 helper: fix sequence extension parsing · 4d942d8b
      由 Patrick McHardy 提交于 
      When parsing unknown sequence extensions the "son"-pointer points behind
the last known extension for this type, don't try to interpret it.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d942d8b
    • P
      [NETFILTER]: H.323 helper: fix parser error propagation · 7185989d
      由 Patrick McHardy 提交于 
      The condition "> H323_ERROR_STOP" can never be true since H323_ERROR_STOP
is positive and is the highest possible return code, while real errors are
negative, fix the checks. Also only abort on real errors in some spots
that were just interpreting any return value != 0 as error.

Fixes crashes caused by use of stale data after a parsing error occured:

BUG: unable to handle kernel paging request at virtual address bfffffff
 printing eip:
c01aa0f8
*pde = 1a801067
*pte = 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: ip_nat_h323 ip_conntrack_h323 nfsd exportfs sch_sfq sch_red cls_fw sch_hfsc  xt_length ipt_owner xt_MARK iptable_mangle nfs lockd sunrpc pppoe pppoxx
CPU:    0
EIP:    0060:[<c01aa0f8>]    Not tainted VLI
EFLAGS: 00210646   (2.6.17-rc4 #8)
EIP is at memmove+0x19/0x22
eax: d77264e9   ebx: d77264e9   ecx: e88d9b17   edx: d77264e9
esi: bfffffff   edi: bfffffff   ebp: de6a7680   esp: c0349db8
ds: 007b   es: 007b   ss: 0068
Process asterisk (pid: 3765, threadinfo=c0349000 task=da068540)
Stack: <0>00000006 c0349e5e d77264e3 e09a2b4e e09a38a0 d7726052 d7726124 00000491
       00000006 00000006 00000006 00000491 de6a7680 d772601e d7726032 c0349f74
       e09a2dc2 00000006 c0349e5e 00000006 00000000 d76dda28 00000491 c0349f74
Call Trace:
 [<e09a2b4e>] mangle_contents+0x62/0xfe [ip_nat]
 [<e09a2dc2>] ip_nat_mangle_tcp_packet+0xa1/0x191 [ip_nat]
 [<e0a2712d>] set_addr+0x74/0x14c [ip_nat_h323]
 [<e0ad531e>] process_setup+0x11b/0x29e [ip_conntrack_h323]
 [<e0ad534f>] process_setup+0x14c/0x29e [ip_conntrack_h323]
 [<e0ad57bd>] process_q931+0x3c/0x142 [ip_conntrack_h323]
 [<e0ad5dff>] q931_help+0xe0/0x144 [ip_conntrack_h323]
...

Found by the PROTOS c07-h2250v4 testsuite.
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7185989d
    • N
      [PATCH] knfsd: Fix two problems that can cause rmmod nfsd to die · f2d39586
      由 NeilBrown 提交于 
      Both cause the 'entries' count in the export cache to be non-zero at module
removal time, so unregistering that cache fails and results in an oops.

1/ exp_pseudoroot (used for NFSv4 only) leaks a reference to an export
   entry.
2/ sunrpc_cache_update doesn't increment the entries count when it adds
   an entry.

Thanks to "david m.  richter" <richterd@citi.umich.edu> for triggering the
problem and finding one of the bugs.

Cc: "david m. richter" <richterd@citi.umich.edu>
Signed-off-by: NNeil Brown <neilb@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f2d39586
  5. 23 5月, 2006 3 次提交
  7. 20 5月, 2006 4 次提交
  9. 19 5月, 2006 5 次提交
  11. 17 5月, 2006 6 次提交
  13. 13 5月, 2006 1 次提交
    • S
      [NEIGH]: Fix IP-over-ATM and ARP interaction. · bd89efc5
      由 Simon Kelley 提交于 
      The classical IP over ATM code maintains its own IPv4 <-> <ATM stuff>
ARP table, using the standard neighbour-table code. The
neigh_table_init function adds this neighbour table to a linked list
of all neighbor tables which is used by the functions neigh_delete()
neigh_add() and neightbl_set(), all called by the netlink code.

Once the ATM neighbour table is added to the list, there are two
tables with family == AF_INET there, and ARP entries sent via netlink
go into the first table with matching family. This is indeterminate
and often wrong.

To see the bug, on a kernel with CLIP enabled, create a standard IPv4
ARP entry by pinging an unused address on a local subnet. Then attempt
to complete that entry by doing

ip neigh replace <ip address> lladdr <some mac address> nud reachable

Looking at the ARP tables by using 

ip neigh show

will reveal two ARP entries for the same address. One of these can be
found in /proc/net/arp, and the other in /proc/net/atm/arp.

This patch adds a new function, neigh_table_init_no_netlink() which
does everything the neigh_table_init() does, except add the table to
the netlink all-arp-tables chain. In addition neigh_table_init() has a
check that all tables on the chain have a distinct address family.
The init call in clip.c is changed to call
neigh_table_init_no_netlink().

Since ATM ARP tables are rather more complicated than can currently be
handled by the available rtattrs in the netlink protocol, no
functionality is lost by this patch, and non-ATM ARP manipulation via
netlink is rescued. A more complete solution would involve a rtattr
for ATM ARP entries and some way for the netlink code to give
neigh_add and friends more information than just address family with
which to find the correct ARP table.

[ I've changed the assertion checking in neigh_table_init() to not
  use BUG_ON() while holding neigh_tbl_lock.  Instead we remember that
  we found an existing tbl with the same family, and after dropping
  the lock we'll give a diagnostic kernel log message and a stack dump.
  -DaveM ]
Signed-off-by: NSimon Kelley <simon@thekelleys.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd89efc5
  15. 12 5月, 2006 1 次提交
  17. 11 5月, 2006 3 次提交
  19. 10 5月, 2006 4 次提交
  21. 07 5月, 2006 2 次提交
  23. 06 5月, 2006 4 次提交
    • J
      [TCP]: Fix snd_cwnd adjustments in tcp_highspeed.c · 5528e568
      由 John Heffner 提交于 
      Xiaoliang (David) Wei wrote:
> Hi gurus,
> 
>    I am reading the code of tcp_highspeed.c in the kernel and have a
> question on the hstcp_cong_avoid function, specifically the following
> AI part (line 136~143 in net/ipv4/tcp_highspeed.c ):
> 
>                /* Do additive increase */
>                if (tp->snd_cwnd < tp->snd_cwnd_clamp) {
>                        tp->snd_cwnd_cnt += ca->ai;
>                        if (tp->snd_cwnd_cnt >= tp->snd_cwnd) {
>                                tp->snd_cwnd++;
>                                tp->snd_cwnd_cnt -= tp->snd_cwnd;
>                        }
>                }
> 
>    In this part, when (tp->snd_cwnd_cnt == tp->snd_cwnd),
> snd_cwnd_cnt will be -1... snd_cwnd_cnt is defined as u16, will this
> small chance of getting -1 becomes a problem?
> Shall we change it by reversing the order of the cwnd++ and cwnd_cnt -= 
> cwnd?

Absolutely correct.  Thanks.
Signed-off-by: NJohn Heffner <jheffner@psc.edu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5528e568
    • R
      [NETROM/ROSE]: Kill module init version kernel log messages. · f530937b
      由 Ralf Baechle 提交于 
      There are out of date and don't tell the user anything useful.
The similar messages which IPV4 and the core networking used
to output were killed a long time ago.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f530937b
    • H
      [DCCP]: Fix sock_orphan dead lock · 134af346
      由 Herbert Xu 提交于 
      Calling sock_orphan inside bh_lock_sock in dccp_close can lead to dead
locks.  For example, the inet_diag code holds sk_callback_lock without
disabling BH.  If an inbound packet arrives during that admittedly tiny
window, it will cause a dead lock on bh_lock_sock.  Another possible
path would be through sock_wfree if the network device driver frees the
tx skb in process context with BH enabled.

We can fix this by moving sock_orphan out of bh_lock_sock.

The tricky bit is to work out when we need to destroy the socket
ourselves and when it has already been destroyed by someone else.

By moving sock_orphan before the release_sock we can solve this
problem.  This is because as long as we own the socket lock its
state cannot change.

So we simply record the socket state before the release_sock
and then check the state again after we regain the socket lock.
If the socket state has transitioned to DCCP_CLOSED in the time being,
we know that the socket has been destroyed.  Otherwise the socket is
still ours to keep.

This problem was discoverd by Ingo Molnar using his lock validator.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      134af346
    • S
      [BRIDGE]: keep track of received multicast packets · 1c29fc49
      由 Stephen Hemminger 提交于 
      It makes sense to add this simple statistic to keep track of received
multicast packets.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c29fc49