Skip to content

L
linux
Switch branch/tag
  1. 24 Feb, 2006 5 commits
    • Herbert Xu's avatar
      [IPSEC]: Use TOS when doing tunnel lookups · 4da3089f
      Herbert Xu authored 
      We should use the TOS because it's one of the routing keys.  It also
means that we update the correct routing cache entry when PMTU occurs.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4da3089f
    • Jamal Hadi Salim's avatar
      [NET] ethernet: Fix first packet goes out with MAC 00:00:00:00:00:00 · f8d0e3f1
      Jamal Hadi Salim authored 
      When you turn off ARP on a netdevice then the first packet always goes
out with a dstMAC of all zeroes. This is because the first packet is
used to resolve ARP entries. Even though the ARP entry may be resolved
(I tried by setting a static ARP entry for a host i was pinging from),
it gets overwritten by virtue of having the netdevice disabling ARP.

Subsequent packets go out fine with correct dstMAC address (which may
be why people have ignored reporting this issue).

To cut the story short: 

the culprit code is in net/ethernet/eth.c::eth_header()

----
        /*
         *      Anyway, the loopback-device should never use this
function...
         */

        if (dev->flags & (IFF_LOOPBACK|IFF_NOARP))
        {
                memset(eth->h_dest, 0, dev->addr_len);
                return ETH_HLEN;
        }

	if(daddr)
        {
                memcpy(eth->h_dest,daddr,dev->addr_len);
                return ETH_HLEN;
        }

----

Note how the h_dest is being reset when device has IFF_NOARP.

As a note:
All devices including loopback pass a daddr. loopback in fact passes
a 0 all the time ;-> 
This means i can delete the check totaly or i can remove the IFF_NOARP

Alexey says:
--------------------
I think, it was me who did this crap. It was so long ago I do not remember
why it was made.

I remember some troubles with dummy device. It tried to resolve
addresses, apparently, without success and generated errors instead of
blackholing. I think the problem was eventually solved at neighbour
level.

After some thinking I suspect the deletion of this chunk could change
behaviour of some parts which do not use neighbour cache f.e. packet
socket.

I think safer approach would be to move this chunk after if (daddr).
And the possibility to remove this completely could be analyzed later.
--------------------

Patch updated with Alexey's safer suggestions.
Signed-off-by: default avatarJamal Hadi Salim <hadi@cyberus.ca>
Acked-by: default avatarAlexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f8d0e3f1
    • Herbert Xu's avatar
      [XFRM]: Eliminate refcounting confusion by creating __xfrm_state_put(). · 21380b81
      Herbert Xu authored 
      We often just do an atomic_dec(&x->refcnt) on an xfrm_state object
because we know there is more than 1 reference remaining and thus
we can elide the heavier xfrm_state_put() call.

Do this behind an inline function called __xfrm_state_put() so that is
more obvious and also to allow us to more cleanly add refcount
debugging later.
Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21380b81
    • Suresh Bhogavilli's avatar
      [IPV4]: Fix garbage collection of multipath route entries · 85259878
      Suresh Bhogavilli authored 
      When garbage collecting route cache entries of multipath routes
in rt_garbage_collect(), entries were deleted from the hash bucket
'i' while holding a spin lock on bucket 'k' resulting in a system
hang.  Delete entries, if any, from bucket 'k' instead.
Signed-off-by: default avatarSuresh Bhogavilli <sbhogavilli@verisign.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      85259878
    • Patrick McHardy's avatar
      [NETFILTER]: Fix bridge netfilter related in xfrm_lookup · 42cf93cd
      Patrick McHardy authored 
      The bridge-netfilter code attaches a fake dst_entry with dst->ops == NULL
to purely bridged packets. When these packets are SNATed and a policy
lookup is done, xfrm_lookup crashes because it tries to dereference
dst->ops.

Change xfrm_lookup not to dereference dst->ops before checking for the
DST_NOXFRM flag and set this flag in the fake dst_entry.
Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      42cf93cd
  3. 23 Feb, 2006 3 commits
    • Stefan Richter's avatar
      sbp2: update 36byte inquiry workaround (fix compatibility regression) · a80614d1
      Stefan Richter authored 
      Since about Linux 2.6.14, sbp2's inquiry workaround did not work anymore
due to changes in the SCSI layer. Update it to become effective again.
Testing one of the two known affected bridges has shown that skip_ms_page_8
is required as well.

Also, make force_inquiry_hack tunable via /sys/module/sbp2/parameters.
Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: default avatarJody McIntyre <scjody@modernduck.com>
(cherry picked from 99496037c6744fd938ffb8ccfc8fc91762322ff8 commit)
      a80614d1
    • Stefan Richter's avatar
      sbp2: variable status FIFO address (fix login timeout) · 35bdddb8
      Stefan Richter authored 
      Let the ieee1394 core select a suitable 1394 address range for sbp2's
status FIFO instead of using a fixed range. Since the core only selects
addresses which are guaranteed to be out of the "physical range" as per
OHCI 1.1, this patch also fixes an old bug:

OHCI controllers which implement a writeable PhysicalUpperBound register
included sbp2's status FIFO in the physical range. That way sbp2 was
never notified of a succesful login and always failed after timeout.
Affected OHCI host adapters include ALi and Fujitsu controllers.

As another side effect of this patch, the status FIFO is no longer
located in a range for which OHCI chips perform "posted writes". Each
status write now requires a response subaction. But since large data
transfers involve only few status writes, there is no measurable
decrease of I/O throughput. What's more, the status FIFO is now safe
from potential host bus errors. Nevertheless, posted writes could be
re-enabled by extensions to the ARM features of the 1394 stack.
Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: default avatarJody McIntyre <scjody@modernduck.com>
(cherry picked from b2d38cccad4ef80d6b672b8f89aae5fe2907b113 commit)
      35bdddb8
    • Stefan Richter's avatar
      sbp2: fix another deadlock after disconnection · bf637ec3
      Stefan Richter authored 
      If there were commands enqueued but not completed before an SBP-2 unit
was unplugged (or an attempt to reconnect failed), knodemgrd or any
process which tried to remove the device would sleep uninterruptibly
in blk_execute_rq().  Therefore make sure that all commands are
completed when sbp2 retreats.
Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: default avatarJody McIntyre <scjody@modernduck.com>
(cherry picked from 61daa34c132c5d4ed8630e2c46e9bf2f0c7b3428 commit)
      bf637ec3
  5. 22 Feb, 2006 20 commits
  7. 21 Feb, 2006 12 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7