On Tue, Nov 19, 2013 at 02:00:11PM -0800, Eric Dumazet wrote:
On Tue, 2013-11-19 at 23:53 +0200, Michael S. Tsirkin wrote:
Which NIC? Virtio? Prior to 2613af0ed18a11d5c566a81f9a6510b73180660a
it didn't drop packets received from host as far as I can tell.
virtio is more like a pipe than a
On Tue, Nov 19, 2013 at 01:38:16PM -0800, Michael Dalton wrote:
Great catch Jason. I agree this now raises the larger issue of how to
handle a memory alloc failure in the middle of receive. As Eric mentioned,
we can drop the packet and free the remaining (num_buf) frags.
Michael, perhaps I'm
We need decrease the rq-num after we can get a buf through
virtqueue_get_buf() even if we could not allocate frag skb. Otherwise, the
refill routine won't be triggered under heavy memory stress since the driver may
still think there's enough room.
This bug was introduced by commit
When we fail to allocate a frag skb, we need put the refcnt of the page and drop
the rest of the buffers. Otherwise the page was leaked and driver won't get a
correct head buffer after this failure.
This bug was introduced by commit 2613af0ed18a11d5c566a81f9a6510b73180660a
(virtio_net: migrate
On Wed, Nov 20, 2013 at 05:07:25PM +0800, Jason Wang wrote:
When mergeable buffer were used, we only put the first page buf leave the rest
of buffers in the virt queue. This will cause the driver could not get the
correct head buffer any more. Fix this by dropping the rest of buffers for
this
On Wed, Nov 20, 2013 at 05:07:26PM +0800, Jason Wang wrote:
We need decrease the rq-num after we can get a buf through
virtqueue_get_buf() even if we could not allocate frag skb. Otherwise, the
refill routine won't be triggered under heavy memory stress since the driver
may
still think
- 原始邮件 -
On Wed, Nov 20, 2013 at 05:07:25PM +0800, Jason Wang wrote:
When mergeable buffer were used, we only put the first page buf leave the
rest
of buffers in the virt queue. This will cause the driver could not get the
correct head buffer any more. Fix this by dropping the
- 原始邮件 -
On Wed, Nov 20, 2013 at 05:07:26PM +0800, Jason Wang wrote:
We need decrease the rq-num after we can get a buf through
virtqueue_get_buf() even if we could not allocate frag skb. Otherwise, the
refill routine won't be triggered under heavy memory stress since the
driver
On Wed, Nov 20, 2013 at 05:07:25PM +0800, Jason Wang wrote:
When mergeable buffer were used, we only put the first page buf leave the rest
of buffers in the virt queue. This will cause the driver could not get the
correct head buffer any more. Fix this by dropping the rest of buffers for
this
On Wed, Nov 20, 2013 at 07:08:02AM -0500, Jason Wang wrote:
- 原始邮件 -
On Wed, Nov 20, 2013 at 05:07:25PM +0800, Jason Wang wrote:
When mergeable buffer were used, we only put the first page buf leave the
rest
of buffers in the virt queue. This will cause the driver could not
On Wed, Nov 20, 2013 at 07:08:50AM -0500, Jason Wang wrote:
- 原始邮件 -
On Wed, Nov 20, 2013 at 05:07:26PM +0800, Jason Wang wrote:
We need decrease the rq-num after we can get a buf through
virtqueue_get_buf() even if we could not allocate frag skb. Otherwise, the
refill
- 原始邮件 -
On Wed, Nov 20, 2013 at 05:07:25PM +0800, Jason Wang wrote:
When mergeable buffer were used, we only put the first page buf leave the
rest
of buffers in the virt queue. This will cause the driver could not get the
correct head buffer any more. Fix this by dropping the
- 原始邮件 -
On Wed, Nov 20, 2013 at 07:08:50AM -0500, Jason Wang wrote:
- 原始邮件 -
On Wed, Nov 20, 2013 at 05:07:26PM +0800, Jason Wang wrote:
We need decrease the rq-num after we can get a buf through
virtqueue_get_buf() even if we could not allocate frag skb.
On Wed, Nov 20, 2013 at 08:54:02AM -0500, Jason Wang wrote:
- 原始邮件 -
On Wed, Nov 20, 2013 at 05:07:25PM +0800, Jason Wang wrote:
When mergeable buffer were used, we only put the first page buf leave the
rest
of buffers in the virt queue. This will cause the driver could not
Apologies if you are receiving this mail more than once...
**
WorldCIST'14
The 2014 World Conference on Information Systems and Technologies
April 15 - 18, Madeira Island,
On Wed, 2013-11-20 at 10:58 +0200, Michael S. Tsirkin wrote:
On Tue, Nov 19, 2013 at 02:00:11PM -0800, Eric Dumazet wrote:
On Tue, 2013-11-19 at 23:53 +0200, Michael S. Tsirkin wrote:
Which NIC? Virtio? Prior to 2613af0ed18a11d5c566a81f9a6510b73180660a
it didn't drop packets received
Hi,
when an active virtio block device is hot-unplugged from a KVM guest, running
affected guest user applications are not aware of any errors that occur due
to the lost device. This patch-set adds code to avoid further request queueing
when a lost block device is detected, resulting in
Add an optional notify() callback to virtio_driver. A backend
driver can provide this callback to perform actions for a lost
device.
notify() event values are inherited from virtio_ccw's notify()
callback. We might want to support even more of them lateron.
notify() return values are defined in
Add virtblk_notify() as virtio_driver's notify() callback.
When a transport driver is notified that a device disappeared it
should invoke this callback to prevent further request queueing.
Subsequent block layer calls of virtio_blk's request function will
fail, resulting in appropriate I/O
virtio_ccw's notify() callback for the common IO layer invokes
virtio_driver's notify() callback to pass-on information to a
backend driver if an online device disappeared.
Signed-off-by: Heinz Graalfs graa...@linux.vnet.ibm.com
---
drivers/s390/kvm/virtio_ccw.c | 14 --
1 file
* Frank Ch. Eigler f...@redhat.com wrote:
masami.hiramatsu.pt wrote:
[...] This series also includes a change which prohibits probing
on the address in .entry.text because the code is used for very
low-level sensitive interrupt/syscall entries. Probing such code
may cause
On Wed, Nov 20, 2013 at 07:16:33AM -0800, Eric Dumazet wrote:
On Wed, 2013-11-20 at 10:58 +0200, Michael S. Tsirkin wrote:
On Tue, Nov 19, 2013 at 02:00:11PM -0800, Eric Dumazet wrote:
On Tue, 2013-11-19 at 23:53 +0200, Michael S. Tsirkin wrote:
Which NIC? Virtio? Prior to
On Wed, 2013-11-20 at 18:06 +0200, Michael S. Tsirkin wrote:
Hmm some kind of disconnect here.
I got you rmanagement about bufferbloat.
What I am saying is that maybe we should drop packets more
aggressively: when we drop one packet of a flow, why not
drop everything that's queued and is
On Wed, Nov 20, 2013 at 08:14:21AM -0800, Eric Dumazet wrote:
On Wed, 2013-11-20 at 18:06 +0200, Michael S. Tsirkin wrote:
Hmm some kind of disconnect here.
I got you rmanagement about bufferbloat.
What I am saying is that maybe we should drop packets more
aggressively: when we drop
On Wed, 20 Nov 2013 12:36:00 -0500
Frank Ch. Eigler f...@redhat.com wrote:
Hi -
Does this new blacklist cover enough that the kernel now survives a
broadly wildcarded perf-probe, e.g. over e.g. all of its kallsyms?
That's generally the purpose of the annotations - if it doesn't
masami.hiramatsu.pt wrote:
[...] This series also includes a change which prohibits probing on
the address in .entry.text because the code is used for very
low-level sensitive interrupt/syscall entries. Probing such code may
cause unexpected result (actually most of that area is already in
Hi -
Does this new blacklist cover enough that the kernel now survives a
broadly wildcarded perf-probe, e.g. over e.g. all of its kallsyms?
That's generally the purpose of the annotations - if it doesn't then
that's a bug.
AFAIK, no kernel since kprobes was introduced has ever stood up
On 11/20/2013 09:56 AM, Steven Rostedt wrote:
On Wed, 20 Nov 2013 12:36:00 -0500
Frank Ch. Eigler f...@redhat.com wrote:
Hi -
Does this new blacklist cover enough that the kernel now survives a
broadly wildcarded perf-probe, e.g. over e.g. all of its kallsyms?
That's generally the
(2013/11/21 2:36), Frank Ch. Eigler wrote:
Hi -
Does this new blacklist cover enough that the kernel now survives a
broadly wildcarded perf-probe, e.g. over e.g. all of its kallsyms?
That's generally the purpose of the annotations - if it doesn't then
that's a bug.
AFAIK, no kernel
On 11/20/2013 10:20 PM, Michael S. Tsirkin wrote:
On Wed, Nov 20, 2013 at 08:54:02AM -0500, Jason Wang wrote:
- 原始邮件 -
On Wed, Nov 20, 2013 at 05:07:25PM +0800, Jason Wang wrote:
When mergeable buffer were used, we only put the first page buf leave the
rest
of buffers in the virt
Heinz Graalfs graa...@linux.vnet.ibm.com writes:
Add an optional notify() callback to virtio_driver. A backend
driver can provide this callback to perform actions for a lost
device.
notify() event values are inherited from virtio_ccw's notify()
callback. We might want to support even more of
On Wed, Nov 20, 2013 at 04:22:02PM +0100, Heinz Graalfs wrote:
Add virtblk_notify() as virtio_driver's notify() callback.
When a transport driver is notified that a device disappeared it
should invoke this callback to prevent further request queueing.
Subsequent block layer calls of
On Wed, Nov 20, 2013 at 04:22:02PM +0100, Heinz Graalfs wrote:
Add virtblk_notify() as virtio_driver's notify() callback.
When a transport driver is notified that a device disappeared it
should invoke this callback to prevent further request queueing.
Subsequent block layer calls of
On Wed, Nov 20, 2013 at 04:22:01PM +0100, Heinz Graalfs wrote:
Add an optional notify() callback to virtio_driver. A backend
driver can provide this callback to perform actions for a lost
device.
notify() event values are inherited from virtio_ccw's notify()
callback. We might want to
On Wed, Nov 20, 2013 at 04:22:00PM +0100, Heinz Graalfs wrote:
Hi,
when an active virtio block device is hot-unplugged from a KVM guest, running
affected guest user applications are not aware of any errors that occur due
to the lost device. This patch-set adds code to avoid further request
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2013/11/21 2:36), Frank Ch. Eigler wrote:
[ ... ]
one needs to resort to something like:
# cat /proc/kallsyms | grep ' [tT] ' | while read addr type symbol; do
perf probe $symbol
done
then wait for a few hours for
36 matches
Mail list logo
