search for: orig_len

...b616..6e4f347 100644 > --- a/net/core/net-sysfs.c > +++ b/net/core/net-sysfs.c > @@ -322,7 +322,20 @@ NETDEVICE_SHOW_RW(flags, fmt_hex); > > static int change_tx_queue_len(struct net_device *dev, unsigned long new_len) > { > - dev->tx_queue_len = new_len; > + int res, orig_len = dev->tx_queue_len; > + > + if (new_len != orig_len) { > + dev->tx_queue_len = new_len; > + res = call_netdevice_notifiers(NETDEV_CHANGE_TX_QUEUE_LEN, dev); > + res = notifier_to_errno(res); > + if (res) { > + netdev_err(dev, > + "refused to change de...

...b616..6e4f347 100644 > --- a/net/core/net-sysfs.c > +++ b/net/core/net-sysfs.c > @@ -322,7 +322,20 @@ NETDEVICE_SHOW_RW(flags, fmt_hex); > > static int change_tx_queue_len(struct net_device *dev, unsigned long new_len) > { > - dev->tx_queue_len = new_len; > + int res, orig_len = dev->tx_queue_len; > + > + if (new_len != orig_len) { > + dev->tx_queue_len = new_len; > + res = call_netdevice_notifiers(NETDEV_CHANGE_TX_QUEUE_LEN, dev); > + res = notifier_to_errno(res); > + if (res) { > + netdev_err(dev, > + "refused to change de...

...sysfs.c b/net/core/net-sysfs.c index 7a0b616..6e4f347 100644 --- a/net/core/net-sysfs.c +++ b/net/core/net-sysfs.c @@ -322,7 +322,20 @@ NETDEVICE_SHOW_RW(flags, fmt_hex); static int change_tx_queue_len(struct net_device *dev, unsigned long new_len) { - dev->tx_queue_len = new_len; + int res, orig_len = dev->tx_queue_len; + + if (new_len != orig_len) { + dev->tx_queue_len = new_len; + res = call_netdevice_notifiers(NETDEV_CHANGE_TX_QUEUE_LEN, dev); + res = notifier_to_errno(res); + if (res) { + netdev_err(dev, + "refused to change device tx_queue_len\n"); + dev->...

...+++ b/net/core/net-sysfs.c >>> @@ -322,7 +322,20 @@ NETDEVICE_SHOW_RW(flags, fmt_hex); >>> static int change_tx_queue_len(struct net_device *dev, unsigned >>> long new_len) >>> { >>> - dev->tx_queue_len = new_len; >>> + int res, orig_len = dev->tx_queue_len; >>> + >>> + if (new_len != orig_len) { >>> + dev->tx_queue_len = new_len; >>> + res = call_netdevice_notifiers(NETDEV_CHANGE_TX_QUEUE_LEN, >>> dev); >>> + res = notifier_to_errno(res); >>...

...+++ b/net/core/net-sysfs.c >>> @@ -322,7 +322,20 @@ NETDEVICE_SHOW_RW(flags, fmt_hex); >>> static int change_tx_queue_len(struct net_device *dev, unsigned >>> long new_len) >>> { >>> - dev->tx_queue_len = new_len; >>> + int res, orig_len = dev->tx_queue_len; >>> + >>> + if (new_len != orig_len) { >>> + dev->tx_queue_len = new_len; >>> + res = call_netdevice_notifiers(NETDEV_CHANGE_TX_QUEUE_LEN, >>> dev); >>> + res = notifier_to_errno(res); >>...

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=567 ------- Additional Comments From kaber@trash.net 2007-05-14 14:28 MET ------- There are two len fields, caplen and len. Which one is wrong? -- Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the

.../net/core/net-sysfs.c >> +++ b/net/core/net-sysfs.c >> @@ -322,7 +322,20 @@ NETDEVICE_SHOW_RW(flags, fmt_hex); >> >> static int change_tx_queue_len(struct net_device *dev, unsigned long new_len) >> { >> - dev->tx_queue_len = new_len; >> + int res, orig_len = dev->tx_queue_len; >> + >> + if (new_len != orig_len) { >> + dev->tx_queue_len = new_len; >> + res = call_netdevice_notifiers(NETDEV_CHANGE_TX_QUEUE_LEN, dev); >> + res = notifier_to_errno(res); >> + if (res) { >> + netdev_err(dev, >> +...

...sysfs.c b/net/core/net-sysfs.c index 7a0b616..6e4f347 100644 --- a/net/core/net-sysfs.c +++ b/net/core/net-sysfs.c @@ -322,7 +322,20 @@ NETDEVICE_SHOW_RW(flags, fmt_hex); static int change_tx_queue_len(struct net_device *dev, unsigned long new_len) { - dev->tx_queue_len = new_len; + int res, orig_len = dev->tx_queue_len; + + if (new_len != orig_len) { + dev->tx_queue_len = new_len; + res = call_netdevice_notifiers(NETDEV_CHANGE_TX_QUEUE_LEN, dev); + res = notifier_to_errno(res); + if (res) { + netdev_err(dev, + "refused to change device tx_queue_len\n"); + dev->...

...t; --- a/generator/states-reply-chunk.c > +++ b/generator/states-reply-chunk.c > @@ -461,6 +461,11 @@ REPLY.CHUNK_REPLY.RECV_BS_ENTRIES: > struct command *cmd = h->reply_cmd; > size_t i; > uint32_t context_id; > + int error; > + const char *name; > + uint32_t orig_len, len, flags; > + uint64_t total, cap; > + bool stop; > > switch (recv_into_rbuf (h)) { > case -1: SET_NEXT_STATE (%.DEAD); return 0; > @@ -481,30 +486,63 @@ REPLY.CHUNK_REPLY.RECV_BS_ENTRIES: > if (context_id == h->meta_contexts.ptr[i].context_id) >...

...st : $cnt" done /* also java prog I used to test this problem on w2k and Linux */ import java.util.*; import java.io.*; public class SMBtest { public static void main(String args[]) { String directory = args[0]; File orig_dir = new File(directory); File orig_fl[] = orig_dir.listFiles(); int orig_len = orig_fl.length; int cnt = 0; int er_cnt = 0; do { File new_dir = new File(directory); File new_fl[] = new_dir.listFiles(); int new_len = new_fl.length; cnt ++; if (new_len != orig_len) { er_cnt ++; System.out.print(" new:" + new_len + "!= old:"...

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the

WARNING: This is not compatible with the previous lz4 patchset. If you''re using experimental compression that isn''t in mainline kernels, be prepared to backup and restore or decompress before upgrading, and have backups in case it eats data (which appears not to be a problem any more, but has been during development). These patches add lz4 and lz4hc compression

Hi all, This is version three of the patches I previously posted here: v1: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ v2: https://lore.kernel.org/r/20200630173734.14057-1-will at kernel.org Changes since v2 include: * Actually add the barrier in READ_ONCE() for Alpha! * Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than the other

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases