Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 16 10月, 2008 10 次提交
    • S
      ieee1394: survive a few seconds connection loss · fc392fe8
      由 Stefan Richter 提交于 
      There are situations when nodes vanish from the bus and come back in
quickly thereafter:
  - When certain bus-powered hubs are plugged in,
  - when certain disk enclosures are switched from self-power to bus
    power or vice versa and break the daisy chain during the transition,
  - when the user plugs a cable out and quickly plugs it back in, e.g.
    to reorder a daisy chain (works on Mac OS X if done quickly enough),
  - when certain hubs temporarily malfunction during high bus traffic.

The ieee1394 driver's nodemgr already contained a function to set
vanished nodes aside into "limbo"; i.e. they wouldn't actually be
deleted right away.  (In fact, only unloading the driver or writing into
an obscure sysfs attribute would delete them eventually.)  If nodes
reappeared later, they would be resurrected out of limbo.

Moving nodes into and out of limbo was accompanied with calling the
.suspend() and .resume() driver methods of the drivers which were bound
to a respective node's unit directories.  Not only is this somewhat
strange due to the intended use of these driver methods for power
management, also the sbp2 driver in particular does not implement
.suspend() and .resume().  Hence sbp2 would be disconnected from devices
in situations as listed above.

We now:
  - leave drivers bound when nodes go into limbo,
  - call the drivers' .update() when nodes come out of limbo,
  - automatically delete in-limbo nodes 3 seconds after the last
    bus reset and bus rescan.
  - Because of the automatic removal, the now obsolete bus attribute
    /sys/bus/ieee1394/destroy_node is removed.

This especially lets sbp2 survive brief disconnections.  You can for
example yank a disk's cable and plug it back in while reading the
respective disk with dd, but dd will happily continue as if nothing
happened.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      fc392fe8
    • S
      ieee1394: nodemgr clean up class iterators · 11305c3e
      由 Stefan Richter 提交于 
      Remove useless pointer type casts.
Remove unnecessary hi->host indirection where only host is used.
Remove an unnecessary WARN_ON.
Change a few names.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      11305c3e
    • S
      ieee1394: dv1394, video1394: remove unnecessary expressions · d98562d1
      由 Stefan Richter 提交于 
      init->channel and v.buffer are unsigned and tests for < 0 therefore
always false.  gcc knows this and eliminates the code, but anyway...
Reported by Roel Kluin.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      d98562d1
    • S
      ieee1394: raw1394: make write() thread-safe · f22e52b8
      由 Stefan Richter 提交于 
      Application programs should use a libraw1394 handle only in a single
thread.  The raw1394 driver was apparently relying on this, because it
did nothing to protect its fi->state variable from corruption due to
concurrent accesses.

We now serialize the fi->state accesses.  This affects the write() path.
We re-use the state_mutex which was introduced to protect fi->iso_state
accesses in the ioctl() path.  These paths and accesses are independent
of each other, hence separate mutexes could be used.  But I don't see
much benefit in that.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      f22e52b8
    • S
      ieee1394: raw1394: narrow down the state_mutex protected region · ddfb908d
      由 Stefan Richter 提交于 
      Refactor the ioctl dispatcher in order to move a fraction of it out of
the section which is serialized by fi->state_mutex.  This is not so much
about performance but more about self-documentation:  The mutex_lock()/
mutex_unlock() calls are now closer to the data accesses which the mutex
protects, i.e. to the iso_state switch.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      ddfb908d
    • S
      ieee1394: raw1394: replace BKL by local mutex, make ioctl() and mmap() thread-safe · 10963ea1
      由 Stefan Richter 提交于 
      This removes the last usage of the Big Kernel Lock from the ieee1394
stack, i.e. from raw1394's (unlocked_)ioctl and compat_ioctl.

The ioctl()s don't need to take the BKL, but they need to be serialized
per struct file *.  In particular, accesses to ->iso_state need to be
serial.  We simply use a blocking mutex for this purpose because
libraw1394 does not use O_NONBLOCK.  In practice, there is no lock
contention anyway because most if not all libraw1394 clients use a
libraw1394 handle only in a single thread.

mmap() also accesses ->iso_state.  Until now this was unprotected
against concurrent changes by ioctls.  Fix this bug while we are at it.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      10963ea1
    • S
      ieee1394: sbp2: enforce s/g segment size limit · ed6ffd08
      由 Stefan Richter 提交于 
      1. We don't need to round the SBP-2 segment size limit down to a
   multiple of 4 kB (0xffff -> 0xf000).  It is only necessary to
   ensure quadlet alignment (0xffff -> 0xfffc).

2. Use dma_set_max_seg_size() to tell the DMA mapping infrastructure
   and the block IO layer about the restriction.  This way we can
   remove the size checks and segment splitting in the queuecommand
   path.

   This assumes that no other code in the ieee1394 stack uses
   dma_map_sg() with conflicting requirements.  It furthermore assumes
   that the controller device's platform actually allows us to set the
   segment size to our liking.  Assert the latter with a BUG_ON().

3. Also use blk_queue_max_segment_size() to tell the block IO layer
   about it.  It cannot know it because our scsi_add_host() does not
   point to the FireWire controller's device.

We can also uniformly use dma_map_sg() for the single segment case just
like for the multi segment case, to further simplify the code.

Also clean up how the page table is converted to big endian.

Thanks to Grant Grundler and FUJITA Tomonori for advice.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      ed6ffd08
    • S
      ieee1394: sbp2: check for DMA mapping failures · cd8c79f1
      由 Stefan Richter 提交于 
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      cd8c79f1
    • S
      ieee1394: sbp2: stricter dma_sync · 0a77b17c
      由 Stefan Richter 提交于 
      Two dma_sync_single_for_cpu() were called in the wrong place.
Luckily they were merely for DMA_TO_DEVICE, hence nobody noticed.

Also reorder the matching dma_sync_single_for_device() a little bit
so that they reside in the same functions as their counterparts.
This also avoids syncing the s/g table for requests which don't use it.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      0a77b17c
    • J
      ieee1394: Use DIV_ROUND_UP · 68e2aa79
      由 Julia Lawall 提交于 
      Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      68e2aa79
  3. 10 10月, 2008 6 次提交
  5. 09 10月, 2008 9 次提交
  7. 08 10月, 2008 6 次提交
    • D
      tcp: Fix tcp_hybla zero congestion window growth with small rho and large cwnd. · 9d2c27e1
      由 Daniele Lacamera 提交于 
      Because of rounding, in certain conditions, i.e. when in congestion
avoidance state rho is smaller than 1/128 of the current cwnd, TCP
Hybla congestion control starves and the cwnd is kept constant
forever.

This patch forces an increment by one segment after #send_cwnd calls
without increments(newreno behavior).
Signed-off-by: NDaniele Lacamera <root@danielinux.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d2c27e1
    • H
      net: Fix netdev_run_todo dead-lock · 58ec3b4d
      由 Herbert Xu 提交于 
      Benjamin Thery tracked down a bug that explains many instances
of the error

unregister_netdevice: waiting for %s to become free. Usage count = %d

It turns out that netdev_run_todo can dead-lock with itself if
a second instance of it is run in a thread that will then free
a reference to the device waited on by the first instance.

The problem is really quite silly.  We were trying to create
parallelism where none was required.  As netdev_run_todo always
follows a RTNL section, and that todo tasks can only be added
with the RTNL held, by definition you should only need to wait
for the very ones that you've added and be done with it.

There is no need for a second mutex or spinlock.

This is exactly what the following patch does.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58ec3b4d
    • D
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6 · 742201e7
      由 David S. Miller 提交于
      742201e7
    • A
      tcp: Fix possible double-ack w/ user dma · 53240c20
      由 Ali Saidi 提交于 
      From: Ali Saidi <saidi@engin.umich.edu>

When TCP receive copy offload is enabled it's possible that
tcp_rcv_established() will cause two acks to be sent for a single
packet. In the case that a tcp_dma_early_copy() is successful,
copied_early is set to true which causes tcp_cleanup_rbuf() to be
called early which can send an ack. Further along in
tcp_rcv_established(), __tcp_ack_snd_check() is called and will
schedule a delayed ACK. If no packets are processed before the delayed
ack timer expires the packet will be acked twice.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      53240c20
    • P
      net: only invoke dev->change_rx_flags when device is UP · b6c40d68
      由 Patrick McHardy 提交于 
      Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a VLAN
device down that is in promiscous mode:

When the VLAN device is set down, the promiscous count on the real
device is decremented by one by vlan_dev_stop(). When removing the
promiscous flag from the VLAN device afterwards, the promiscous
count on the real device is decremented a second time by the
vlan_change_rx_flags() callback.

The root cause for this is that the ->change_rx_flags() callback is
invoked while the device is down. The synchronization is meant to mirror
the behaviour of the ->set_rx_mode callbacks, meaning the ->open function
is responsible for doing a full sync on open, the ->close() function is
responsible for doing full cleanup on ->stop() and ->change_rx_flags()
is meant to do incremental changes while the device is UP.

Only invoke ->change_rx_flags() while the device is UP to provide the
intended behaviour.
Tested-by: NJesper Dangaard Brouer <jdb@comx.dk>
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6c40d68
    • M
      SLOB: fix bogus ksize calculation · 85ba94ba
      由 Matt Mackall 提交于 
      SLOB's ksize calculation was braindamaged and generally harmlessly
underreported the allocation size. But for very small buffers, it could
in fact overreport them, leading code depending on krealloc to overrun
the allocation and trample other data.
Signed-off-by: NMatt Mackall <mpm@selenic.com>
Tested-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      85ba94ba
  9. 07 10月, 2008 9 次提交