* Re: [PATCH iproute2] ip lib: Change timestamp to be shorter and on the same line
From: Vadim Kochan @ 2014-09-17 6:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20140916193850.4dec41e8@urahara>
Sure, I can add new option, currently timestamp is printed on separated
line so this solution I think can be easier to parse when it will be
on the same line as message,
and easier to detect to which message timestamp belongs.
On Wed, Sep 17, 2014 at 5:38 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Tue, 16 Sep 2014 12:58:06 +0300
> Vadim Kochan <vadim4j@gmail.com> wrote:
>
>> Changed timestamp format to look like more logging info:
>>
>> [Sep 01 20:56:11.853146]2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default
>> link/ether 3c:97:0e:a3:86:2e brd ff:ff:ff:ff:ff:ff
>>
>> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
>> ---
>> lib/utils.c | 7 +++----
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/utils.c b/lib/utils.c
>> index dc21567..03092ba 100644
>> --- a/lib/utils.c
>> +++ b/lib/utils.c
>> @@ -772,14 +772,13 @@ __u8* hexstring_a2n(const char *str, __u8 *buf, int blen)
>> int print_timestamp(FILE *fp)
>> {
>> struct timeval tv;
>> - char *tstr;
>> + char tstr[40] = {};
>>
>> memset(&tv, 0, sizeof(tv));
>> gettimeofday(&tv, NULL);
>>
>> - tstr = asctime(localtime(&tv.tv_sec));
>> - tstr[strlen(tstr)-1] = 0;
>> - fprintf(fp, "Timestamp: %s %ld usec\n", tstr, (long)tv.tv_usec);
>> + strftime(tstr, sizeof(tstr), "%b %d %H:%M:%S", localtime(&tv.tv_sec));
>> + fprintf(fp, "[%s.%ld]", tstr, (long)tv.tv_usec);
>> return 0;
>> }
>>
>
> I am loath to change the output format since people write scripts parsing
> output. Maybe add a new flag option to choose format?
^ permalink raw reply
* Re: [PATCH net v2] bonding: fix div by zero while enslaving and transmitting
From: Ding Tianhong @ 2014-09-17 6:15 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev
Cc: Eric Dumazet, Andy Gospodarek, Jay Vosburgh, Veaceslav Falico
In-Reply-To: <1410536298-8022-1-git-send-email-nikolay@redhat.com>
On 2014/9/12 23:38, Nikolay Aleksandrov wrote:
> The problem is that the slave is first linked and slave_cnt is
> incremented afterwards leading to a div by zero in the modes that use it
> as a modulus. What happens is that in bond_start_xmit()
> bond_has_slaves() is used to evaluate further transmission and it becomes
> true after the slave is linked in, but when slave_cnt is used in the xmit
> path it is still 0, so fetch it once and transmit based on that. Since
> it is used only in round-robin and XOR modes, the fix is only for them.
> Thanks to Eric Dumazet for pointing out the fault in my first try to fix
> this.
>
Hi, I think no need to add more checks in the xmit fast path, why not add a barrier to make
sure the slave_cnt inc to 1 before access it.
+ /* Increment slave_cnt before linking in the slave so we won't end up in
+ * bond_start_xmit with bond_has_slaves() true and slave_cnt == 0.
+ */
+ bond->slave_cnt++;
+ wmb();
I think it looks more efficiency, sorry for reply so late.
Regards
Ding
> Call trace (took it out of net-next kernel, but it's the same with net):
> [46934.330038] divide error: 0000 [#1] SMP
> [46934.330041] Modules linked in: bonding(O) 9p fscache
> snd_hda_codec_generic crct10dif_pclmul
> [46934.330041] bond0: Enslaving eth1 as an active interface with an up
> link
> [46934.330051] ppdev joydev crc32_pclmul crc32c_intel 9pnet_virtio
> ghash_clmulni_intel snd_hda_intel 9pnet snd_hda_controller parport_pc
> serio_raw pcspkr snd_hda_codec parport virtio_balloon virtio_console
> snd_hwdep snd_pcm pvpanic i2c_piix4 snd_timer i2ccore snd soundcore
> virtio_blk virtio_net virtio_pci virtio_ring virtio ata_generic
> pata_acpi floppy [last unloaded: bonding]
> [46934.330053] CPU: 1 PID: 3382 Comm: ping Tainted: G O
> 3.17.0-rc4+ #27
> [46934.330053] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [46934.330054] task: ffff88005aebf2c0 ti: ffff88005b728000 task.ti:
> ffff88005b728000
> [46934.330059] RIP: 0010:[<ffffffffa0198c33>] [<ffffffffa0198c33>]
> bond_start_xmit+0x1c3/0x450 [bonding]
> [46934.330060] RSP: 0018:ffff88005b72b7f8 EFLAGS: 00010246
> [46934.330060] RAX: 0000000000000679 RBX: ffff88004b077000 RCX:
> 000000000000002a
> [46934.330061] RDX: 0000000000000000 RSI: ffff88004b3f0500 RDI:
> ffff88004b077940
> [46934.330061] RBP: ffff88005b72b830 R08: 00000000000000c0 R09:
> ffff88004a83e000
> [46934.330062] R10: 000000000000ffff R11: ffff88004b1f12c0 R12:
> ffff88004b3f0500
> [46934.330062] R13: ffff88004b3f0500 R14: 000000000000002a R15:
> ffff88004b077940
> [46934.330063] FS: 00007fbd91a4c740(0000) GS:ffff88005f080000(0000)
> knlGS:0000000000000000
> [46934.330064] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [46934.330064] CR2: 00007f803a8bb000 CR3: 000000004b2c9000 CR4:
> 00000000000406e0
> [46934.330069] Stack:
> [46934.330071] ffffffff811e6169 00000000e772fa05 ffff88004b077000
> ffff88004b3f0500
> [46934.330072] ffffffff81d17d18 000000000000002a 0000000000000000
> ffff88005b72b8a0
> [46934.330073] ffffffff81620108 ffffffff8161fe0e ffff88005b72b8c4
> ffff88005b302000
> [46934.330073] Call Trace:
> [46934.330077] [<ffffffff811e6169>] ?
> __kmalloc_node_track_caller+0x119/0x300
> [46934.330084] [<ffffffff81620108>] dev_hard_start_xmit+0x188/0x410
> [46934.330086] [<ffffffff8161fe0e>] ? harmonize_features+0x2e/0x90
> [46934.330088] [<ffffffff81620b06>] __dev_queue_xmit+0x456/0x590
> [46934.330089] [<ffffffff81620c50>] dev_queue_xmit+0x10/0x20
> [46934.330090] [<ffffffff8168f022>] arp_xmit+0x22/0x60
> [46934.330091] [<ffffffff8168f090>] arp_send.part.16+0x30/0x40
> [46934.330092] [<ffffffff8168f1e5>] arp_solicit+0x115/0x2b0
> [46934.330094] [<ffffffff8160b5d7>] ? copy_skb_header+0x17/0xa0
> [46934.330096] [<ffffffff8162875a>] neigh_probe+0x4a/0x70
> [46934.330097] [<ffffffff8162979c>] __neigh_event_send+0xac/0x230
> [46934.330098] [<ffffffff8162a00b>] neigh_resolve_output+0x13b/0x220
> [46934.330100] [<ffffffff8165f120>] ? ip_forward_options+0x1c0/0x1c0
> [46934.330101] [<ffffffff81660478>] ip_finish_output+0x1f8/0x860
> [46934.330102] [<ffffffff81661f08>] ip_output+0x58/0x90
> [46934.330103] [<ffffffff81661602>] ? __ip_local_out+0xa2/0xb0
> [46934.330104] [<ffffffff81661640>] ip_local_out_sk+0x30/0x40
> [46934.330105] [<ffffffff81662a66>] ip_send_skb+0x16/0x50
> [46934.330106] [<ffffffff81662ad3>] ip_push_pending_frames+0x33/0x40
> [46934.330107] [<ffffffff8168854c>] raw_sendmsg+0x88c/0xa30
> [46934.330110] [<ffffffff81612b31>] ? skb_recv_datagram+0x41/0x60
> [46934.330111] [<ffffffff816875a9>] ? raw_recvmsg+0xa9/0x1f0
> [46934.330113] [<ffffffff816978d4>] inet_sendmsg+0x74/0xc0
> [46934.330114] [<ffffffff81697a9b>] ? inet_recvmsg+0x8b/0xb0
> [46934.330115] bond0: Adding slave eth2
> [46934.330116] [<ffffffff8160357c>] sock_sendmsg+0x9c/0xe0
> [46934.330118] [<ffffffff81603248>] ?
> move_addr_to_kernel.part.20+0x28/0x80
> [46934.330121] [<ffffffff811b4477>] ? might_fault+0x47/0x50
> [46934.330122] [<ffffffff816039b9>] ___sys_sendmsg+0x3a9/0x3c0
> [46934.330125] [<ffffffff8144a14a>] ? n_tty_write+0x3aa/0x530
> [46934.330127] [<ffffffff810d1ae4>] ? __wake_up+0x44/0x50
> [46934.330129] [<ffffffff81242b38>] ? fsnotify+0x238/0x310
> [46934.330130] [<ffffffff816048a1>] __sys_sendmsg+0x51/0x90
> [46934.330131] [<ffffffff816048f2>] SyS_sendmsg+0x12/0x20
> [46934.330134] [<ffffffff81738b29>] system_call_fastpath+0x16/0x1b
> [46934.330144] Code: 48 8b 10 4c 89 ee 4c 89 ff e8 aa bc ff ff 31 c0 e9
> 1a ff ff ff 0f 1f 00 4c 89 ee 4c 89 ff e8 65 fb ff ff 31 d2 4c 89 ee 4c
> 89 ff <f7> b3 64 09 00 00 e8 02 bd ff ff 31 c0 e9 f2 fe ff ff 0f 1f 00
> [46934.330146] RIP [<ffffffffa0198c33>] bond_start_xmit+0x1c3/0x450
> [bonding]
> [46934.330146] RSP <ffff88005b72b7f8>
>
> CC: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: Jay Vosburgh <j.vosburgh@gmail.com>
> CC: Veaceslav Falico <vfalico@gmail.com>
> Fixes: 278b208375 ("bonding: initial RCU conversion")
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
> ---
> v2: Based on Eric's feedback change the fix to fetch the value once in a
> local variable in the affected modes and to act based on that.
>
> I believe we don't need to move the increment now as it doesn't really
> matter if it'll be before the wmb or after.
>
> drivers/net/bonding/bond_main.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 57912ee231cb..798ae69fb63c 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -3659,8 +3659,14 @@ static int bond_xmit_roundrobin(struct sk_buff *skb, struct net_device *bond_dev
> else
> bond_xmit_slave_id(bond, skb, 0);
> } else {
> - slave_id = bond_rr_gen_slave_id(bond);
> - bond_xmit_slave_id(bond, skb, slave_id % bond->slave_cnt);
> + int slave_cnt = ACCESS_ONCE(bond->slave_cnt);
> +
> + if (likely(slave_cnt)) {
> + slave_id = bond_rr_gen_slave_id(bond);
> + bond_xmit_slave_id(bond, skb, slave_id % slave_cnt);
> + } else {
> + dev_kfree_skb_any(skb);
> + }
> }
>
> return NETDEV_TX_OK;
> @@ -3691,8 +3697,13 @@ static int bond_xmit_activebackup(struct sk_buff *skb, struct net_device *bond_d
> static int bond_xmit_xor(struct sk_buff *skb, struct net_device *bond_dev)
> {
> struct bonding *bond = netdev_priv(bond_dev);
> + int slave_cnt = ACCESS_ONCE(bond->slave_cnt);
>
> - bond_xmit_slave_id(bond, skb, bond_xmit_hash(bond, skb) % bond->slave_cnt);
> + if (likely(slave_cnt))
> + bond_xmit_slave_id(bond, skb,
> + bond_xmit_hash(bond, skb) % slave_cnt);
> + else
> + dev_kfree_skb_any(skb);
>
> return NETDEV_TX_OK;
> }
>
^ permalink raw reply
* Re: [PATCH v13 net-next 07/11] bpf: verifier (add ability to receive verification log)
From: Daniel Borkmann @ 2014-09-17 6:51 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Linus Torvalds, Andy Lutomirski,
Hannes Frederic Sowa, Chema Gonzalez, Eric Dumazet,
Peter Zijlstra, Pablo Neira Ayuso, H. Peter Anvin, Andrew Morton,
Kees Cook, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1410914370-29883-8-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
On 09/17/2014 02:39 AM, Alexei Starovoitov wrote:
> add optional attributes for BPF_PROG_LOAD syscall:
> union bpf_attr {
> struct {
> ...
> __u32 log_level; /* verbosity level of eBPF verifier */
> __u32 log_size; /* size of user buffer */
> __aligned_u64 log_buf; /* user supplied 'char *buffer' */
> };
> };
>
> when log_level > 0 the verifier will return its verification log in the user
> supplied buffer 'log_buf' which can be used by program author to analyze why
> verifier rejected given program.
>
> 'Understanding eBPF verifier messages' section of Documentation/networking/filter.txt
> provides several examples of these messages, like the program:
>
> BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
> BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
> BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
> BPF_LD_MAP_FD(BPF_REG_1, 0),
> BPF_CALL_FUNC(BPF_FUNC_map_lookup_elem),
> BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 1),
> BPF_ST_MEM(BPF_DW, BPF_REG_0, 4, 0),
> BPF_EXIT_INSN(),
>
> will be rejected with the following multi-line message in log_buf:
>
> 0: (7a) *(u64 *)(r10 -8) = 0
> 1: (bf) r2 = r10
> 2: (07) r2 += -8
> 3: (b7) r1 = 0
> 4: (85) call 1
> 5: (15) if r0 == 0x0 goto pc+1
> R0=map_ptr R10=fp
> 6: (7a) *(u64 *)(r0 +4) = 0
> misaligned access off 4 size 8
>
> The format of the output can change at any time as verifier evolves.
>
> Signed-off-by: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
> ---
> include/uapi/linux/bpf.h | 3 +
> kernel/bpf/syscall.c | 2 +-
> kernel/bpf/verifier.c | 235 ++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 239 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 424f442016e7..31b0ac208a52 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -138,6 +138,9 @@ union bpf_attr {
> __u32 insn_cnt;
> __aligned_u64 insns;
> __aligned_u64 license;
> + __u32 log_level; /* verbosity level of verifier */
> + __u32 log_size; /* size of user buffer */
> + __aligned_u64 log_buf; /* user supplied buffer */
> };
> } __attribute__((aligned(8)));
>
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 67b5e29f183e..c7be7163bd11 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -458,7 +458,7 @@ struct bpf_prog *bpf_prog_get(u32 ufd)
> }
>
> /* last field in 'union bpf_attr' used by this command */
> -#define BPF_PROG_LOAD_LAST_FIELD license
> +#define BPF_PROG_LOAD_LAST_FIELD log_buf
I was looking to find a use case for this item, but couldn't find anything, so
this seems to be dead code?
Was it, so that each time you extend an uapi structure like above that you would
only access the structure up to BPF_PROG_LOAD_LAST_FIELD? That might not work for
old binaries using this ABI running on newer kernels where there are different
expectations of what BPF_PROG_LOAD_LAST_FIELD has been at the time of compilation.
> static int bpf_prog_load(union bpf_attr *attr)
> {
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index d6f9c3d6b4d7..871edc1f2e1f 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -125,9 +125,244 @@
> * are set to NOT_INIT to indicate that they are no longer readable.
> */
>
> +/* single container for all structs
> + * one verifier_env per bpf_check() call
> + */
> +struct verifier_env {
> +};
> +
> +/* verbose verifier prints what it's seeing
> + * bpf_check() is called under lock, so no race to access these global vars
> + */
> +static u32 log_level, log_size, log_len;
> +static char *log_buf;
> +
> +static DEFINE_MUTEX(bpf_verifier_lock);
> +
> +/* log_level controls verbosity level of eBPF verifier.
> + * verbose() is used to dump the verification trace to the log, so the user
> + * can figure out what's wrong with the program
> + */
> +static void verbose(const char *fmt, ...)
> +{
> + va_list args;
> +
> + if (log_level == 0 || log_len >= log_size - 1)
> + return;
> +
> + va_start(args, fmt);
> + log_len += vscnprintf(log_buf + log_len, log_size - log_len, fmt, args);
> + va_end(args);
> +}
> +
> +static const char *const bpf_class_string[] = {
> + [BPF_LD] = "ld",
> + [BPF_LDX] = "ldx",
> + [BPF_ST] = "st",
> + [BPF_STX] = "stx",
> + [BPF_ALU] = "alu",
> + [BPF_JMP] = "jmp",
> + [BPF_RET] = "BUG",
> + [BPF_ALU64] = "alu64",
> +};
> +
> +static const char *const bpf_alu_string[] = {
> + [BPF_ADD >> 4] = "+=",
> + [BPF_SUB >> 4] = "-=",
> + [BPF_MUL >> 4] = "*=",
> + [BPF_DIV >> 4] = "/=",
> + [BPF_OR >> 4] = "|=",
> + [BPF_AND >> 4] = "&=",
> + [BPF_LSH >> 4] = "<<=",
> + [BPF_RSH >> 4] = ">>=",
> + [BPF_NEG >> 4] = "neg",
> + [BPF_MOD >> 4] = "%=",
> + [BPF_XOR >> 4] = "^=",
> + [BPF_MOV >> 4] = "=",
> + [BPF_ARSH >> 4] = "s>>=",
> + [BPF_END >> 4] = "endian",
> +};
> +
> +static const char *const bpf_ldst_string[] = {
> + [BPF_W >> 3] = "u32",
> + [BPF_H >> 3] = "u16",
> + [BPF_B >> 3] = "u8",
> + [BPF_DW >> 3] = "u64",
> +};
> +
> +static const char *const bpf_jmp_string[] = {
> + [BPF_JA >> 4] = "jmp",
> + [BPF_JEQ >> 4] = "==",
> + [BPF_JGT >> 4] = ">",
> + [BPF_JGE >> 4] = ">=",
> + [BPF_JSET >> 4] = "&",
> + [BPF_JNE >> 4] = "!=",
> + [BPF_JSGT >> 4] = "s>",
> + [BPF_JSGE >> 4] = "s>=",
> + [BPF_CALL >> 4] = "call",
> + [BPF_EXIT >> 4] = "exit",
> +};
> +
> +static void print_bpf_insn(struct bpf_insn *insn)
> +{
> + u8 class = BPF_CLASS(insn->code);
> +
> + if (class == BPF_ALU || class == BPF_ALU64) {
> + if (BPF_SRC(insn->code) == BPF_X)
> + verbose("(%02x) %sr%d %s %sr%d\n",
> + insn->code, class == BPF_ALU ? "(u32) " : "",
> + insn->dst_reg,
> + bpf_alu_string[BPF_OP(insn->code) >> 4],
> + class == BPF_ALU ? "(u32) " : "",
> + insn->src_reg);
> + else
> + verbose("(%02x) %sr%d %s %s%d\n",
> + insn->code, class == BPF_ALU ? "(u32) " : "",
> + insn->dst_reg,
> + bpf_alu_string[BPF_OP(insn->code) >> 4],
> + class == BPF_ALU ? "(u32) " : "",
> + insn->imm);
> + } else if (class == BPF_STX) {
> + if (BPF_MODE(insn->code) == BPF_MEM)
> + verbose("(%02x) *(%s *)(r%d %+d) = r%d\n",
> + insn->code,
> + bpf_ldst_string[BPF_SIZE(insn->code) >> 3],
> + insn->dst_reg,
> + insn->off, insn->src_reg);
> + else if (BPF_MODE(insn->code) == BPF_XADD)
> + verbose("(%02x) lock *(%s *)(r%d %+d) += r%d\n",
> + insn->code,
> + bpf_ldst_string[BPF_SIZE(insn->code) >> 3],
> + insn->dst_reg, insn->off,
> + insn->src_reg);
> + else
> + verbose("BUG_%02x\n", insn->code);
> + } else if (class == BPF_ST) {
> + if (BPF_MODE(insn->code) != BPF_MEM) {
> + verbose("BUG_st_%02x\n", insn->code);
> + return;
> + }
> + verbose("(%02x) *(%s *)(r%d %+d) = %d\n",
> + insn->code,
> + bpf_ldst_string[BPF_SIZE(insn->code) >> 3],
> + insn->dst_reg,
> + insn->off, insn->imm);
> + } else if (class == BPF_LDX) {
> + if (BPF_MODE(insn->code) != BPF_MEM) {
> + verbose("BUG_ldx_%02x\n", insn->code);
> + return;
> + }
> + verbose("(%02x) r%d = *(%s *)(r%d %+d)\n",
> + insn->code, insn->dst_reg,
> + bpf_ldst_string[BPF_SIZE(insn->code) >> 3],
> + insn->src_reg, insn->off);
> + } else if (class == BPF_LD) {
> + if (BPF_MODE(insn->code) == BPF_ABS) {
> + verbose("(%02x) r0 = *(%s *)skb[%d]\n",
> + insn->code,
> + bpf_ldst_string[BPF_SIZE(insn->code) >> 3],
> + insn->imm);
> + } else if (BPF_MODE(insn->code) == BPF_IND) {
> + verbose("(%02x) r0 = *(%s *)skb[r%d + %d]\n",
> + insn->code,
> + bpf_ldst_string[BPF_SIZE(insn->code) >> 3],
> + insn->src_reg, insn->imm);
> + } else if (BPF_MODE(insn->code) == BPF_IMM) {
> + verbose("(%02x) r%d = 0x%x\n",
> + insn->code, insn->dst_reg, insn->imm);
> + } else {
> + verbose("BUG_ld_%02x\n", insn->code);
> + return;
> + }
> + } else if (class == BPF_JMP) {
> + u8 opcode = BPF_OP(insn->code);
> +
> + if (opcode == BPF_CALL) {
> + verbose("(%02x) call %d\n", insn->code, insn->imm);
> + } else if (insn->code == (BPF_JMP | BPF_JA)) {
> + verbose("(%02x) goto pc%+d\n",
> + insn->code, insn->off);
> + } else if (insn->code == (BPF_JMP | BPF_EXIT)) {
> + verbose("(%02x) exit\n", insn->code);
> + } else if (BPF_SRC(insn->code) == BPF_X) {
> + verbose("(%02x) if r%d %s r%d goto pc%+d\n",
> + insn->code, insn->dst_reg,
> + bpf_jmp_string[BPF_OP(insn->code) >> 4],
> + insn->src_reg, insn->off);
> + } else {
> + verbose("(%02x) if r%d %s 0x%x goto pc%+d\n",
> + insn->code, insn->dst_reg,
> + bpf_jmp_string[BPF_OP(insn->code) >> 4],
> + insn->imm, insn->off);
> + }
> + } else {
> + verbose("(%02x) %s\n", insn->code, bpf_class_string[class]);
> + }
> +}
> +
> int bpf_check(struct bpf_prog *prog, union bpf_attr *attr)
> {
> + char __user *log_ubuf = NULL;
> + struct verifier_env *env;
> int ret = -EINVAL;
>
> + if (prog->len <= 0 || prog->len > BPF_MAXINSNS)
> + return -E2BIG;
> +
> + /* 'struct verifier_env' can be global, but since it's not small,
> + * allocate/free it every time bpf_check() is called
> + */
> + env = kzalloc(sizeof(struct verifier_env), GFP_KERNEL);
> + if (!env)
> + return -ENOMEM;
> +
> + /* grab the mutex to protect few globals used by verifier */
> + mutex_lock(&bpf_verifier_lock);
So only because of the verifier error log (which are global vars here) we
now have to hold a eBPF-related mutex lock each time when attaching a program?
Also, if you really have to do the verifier error log, can't we spare ourself
most part of the textifying parts if you would encode the verifier log into a
normal structure array with eBPF specific error codes and then do all this
pretty printing in user space? Why is that impossible? I really think it's odd.
> + if (attr->log_level || attr->log_buf || attr->log_size) {
> + /* user requested verbose verifier output
> + * and supplied buffer to store the verification trace
> + */
> + log_level = attr->log_level;
> + log_ubuf = (char __user *) (unsigned long) attr->log_buf;
> + log_size = attr->log_size;
> + log_len = 0;
> +
> + ret = -EINVAL;
> + /* log_* values have to be sane */
> + if (log_size < 128 || log_size > UINT_MAX >> 8 ||
> + log_level == 0 || log_ubuf == NULL)
> + goto free_env;
> +
> + ret = -ENOMEM;
> + log_buf = vmalloc(log_size);
> + if (!log_buf)
> + goto free_env;
> + } else {
> + log_level = 0;
> + }
> +
> + /* ret = do_check(env); */
> +
> + if (log_level && log_len >= log_size - 1) {
> + BUG_ON(log_len >= log_size);
> + /* verifier log exceeded user supplied buffer */
> + ret = -ENOSPC;
> + /* fall through to return what was recorded */
> + }
> +
> + /* copy verifier log back to user space including trailing zero */
> + if (log_level && copy_to_user(log_ubuf, log_buf, log_len + 1) != 0) {
> + ret = -EFAULT;
> + goto free_log_buf;
> + }
> +
> +
> +free_log_buf:
> + if (log_level)
> + vfree(log_buf);
> +free_env:
> + kfree(env);
> + mutex_unlock(&bpf_verifier_lock);
> return ret;
> }
>
^ permalink raw reply
* [PATCH 1/1] bluetooth: Check for SCO type before setting retransmission effort
From: Bernhard Thaler @ 2014-09-17 7:13 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg, davem
Cc: linux-bluetooth, netdev, linux-kernel, Bernhard Thaler
From: "Bernhard Thaler" <bernhard.thaler@r-it.at>
SCO connection cannot be setup to devices that do not support retransmission.
Patch based on http://permalink.gmane.org/gmane.linux.bluez.kernel/7779 and
adapted for this kernel version.
Code changed to check SCO/eSCO type before setting retransmission effort
and max. latency. The purpose of the patch is to support older devices not
capable of eSCO.
Tested on Blackberry 655+ headset which does not support retransmission.
Credits go to Alexander Sommerhuber.
Signed-off-by: Bernhard Thaler <bernhard.thaler@r-it.at>
---
net/bluetooth/hci_conn.c | 39 ++++++++++++++++++++++-----------------
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index faff624..093abcc 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -186,26 +186,31 @@ bool hci_setup_sync(struct hci_conn *conn, __u16 handle)
cp.rx_bandwidth = cpu_to_le32(0x00001f40);
cp.voice_setting = cpu_to_le16(conn->setting);
- switch (conn->setting & SCO_AIRMODE_MASK) {
- case SCO_AIRMODE_TRANSP:
- if (conn->attempt > ARRAY_SIZE(sco_param_wideband))
- return false;
- cp.retrans_effort = 0x02;
- param = &sco_param_wideband[conn->attempt - 1];
- break;
- case SCO_AIRMODE_CVSD:
- if (conn->attempt > ARRAY_SIZE(sco_param_cvsd))
+ if (!(conn->link->features[0][3] & LMP_ESCO)) {
+ cp.retrans_effort = 0xff;
+ cp.pkt_type = __cpu_to_le16(conn->pkt_type);
+ cp.max_latency = __cpu_to_le16(0xffff);
+ } else {
+ switch (conn->setting & SCO_AIRMODE_MASK) {
+ case SCO_AIRMODE_TRANSP:
+ if (conn->attempt > ARRAY_SIZE(sco_param_wideband))
+ return false;
+ cp.retrans_effort = 0x02;
+ param = &sco_param_wideband[conn->attempt - 1];
+ break;
+ case SCO_AIRMODE_CVSD:
+ if (conn->attempt > ARRAY_SIZE(sco_param_cvsd))
+ return false;
+ cp.retrans_effort = 0x01;
+ param = &sco_param_cvsd[conn->attempt - 1];
+ break;
+ default:
return false;
- cp.retrans_effort = 0x01;
- param = &sco_param_cvsd[conn->attempt - 1];
- break;
- default:
- return false;
+ }
+ cp.pkt_type = __cpu_to_le16(param->pkt_type);
+ cp.max_latency = __cpu_to_le16(param->max_latency);
}
- cp.pkt_type = __cpu_to_le16(param->pkt_type);
- cp.max_latency = __cpu_to_le16(param->max_latency);
-
if (hci_send_cmd(hdev, HCI_OP_SETUP_SYNC_CONN, sizeof(cp), &cp) < 0)
return false;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v11 net-next 12/12] bpf: mini eBPF library, test stubs and verifier testsuite
From: Daniel Borkmann @ 2014-09-17 7:16 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Linus Torvalds, Andy Lutomirski,
Steven Rostedt, Hannes Frederic Sowa, Chema Gonzalez,
Eric Dumazet, Peter Zijlstra, Pablo Neira Ayuso, H. Peter Anvin,
Andrew Morton, Kees Cook, Linux API, Network Development, LKML
In-Reply-To: <CAMEtUuzEQu30WiYprRcDBogJxxrDeNhvn=kF+z8cVvhR-vjTQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 09/10/2014 08:08 PM, Alexei Starovoitov wrote:
> On Wed, Sep 10, 2014 at 4:35 AM, Daniel Borkmann <dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> Since we already have an extensive BPF test suite, that is, lib/test_bpf.c,
>> which currently also does sanity checks for the classic BPF verifier, is
>> there a reason these verifier test cases cannot be extended/integrated there
>> as well but have to go to kernel/bpf/test_stub.c resp.
>> samples/bpf/test_verifier.c ?
>> I don't like that we put testing code into kernel/bpf/ whereas we already
>> have a BPF test infrastructure in the kernel elsewhere.
>
> yes. there is a reason. Verifier needs to be tested from user space,
> since it works on fds. Process local map_fd are part of the eBPF
> programs. Therefore one is testing things from kernel and
> another from userspace. We definitely need both.
> Currently there is no use case to call verifier from inside
> the kernel. I'm not sure there will be one. Verifier's main
> purpose is to check user supplied programs and provide
> humans an understandable error messages of what
> is 'unsafe' in particular program.
> Eventually we will integrate this verifier messages with
> program compilation. Like, the user would write a program
> in C then invoke a wrapper of compiler and verifier, which
> will point to lines in C code which are doing something
> wrong like loops or out of bounds access. Currently verifier
> complains about particular 'unsafe' instruction, but
> humans have hard time correlating asm to C.
That actually still doesn't answer my question why the test stub
cannot live in lib/test_bpf where we have our actual testing
framework for eBPF/BPF, also since you exactly only build test_stub.c
when TEST_BPF is enabled which is the Kconfig for lib/test_bpf.
^ permalink raw reply
* Re: Qdisc: Measuring Head-of-Line blocking with netperf-wrapper
From: Jesper Dangaard Brouer @ 2014-09-17 7:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev@vger.kernel.org, Stephen Hemminger, Tom Herbert,
David Miller, Hannes Frederic Sowa, Daniel Borkmann,
Florian Westphal, Toke Høiland-Jørgensen, Dave Taht,
brouer
In-Reply-To: <1410885016.7106.203.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, 16 Sep 2014 09:30:16 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-09-16 at 17:56 +0200, Jesper Dangaard Brouer wrote:
> > On Tue, 16 Sep 2014 06:59:19 -0700
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > > With the TCP usec rtt work I did lately, you'll get more precise results
> > > from a TCP_RR flow, as Tom and I explained.
> >
> > Here you go, developed a new test:
>
> Just to make sure I understand (sorry I dont have time going all your
> graphs right now)
Summary for you:
1) I have created the TCP_RR latency test you and Tom asked for.
2) Graphs shows TCP_RR and UDP_RR are more accurate than ping
3) Graphs shows that ping is within same range as TCP_RR and UDP_RR
4) My only problem, NoneXSO case does not work with TCP_RR, and
I need the NoneXSO case for evaluating my qdisc bulking patches.
> The target of your high prio flow is different from target of the
> antagonist flows ?
>
> Otherwise, you are not only measuring head of line blocking of your
> host, but the whole chain, including scheduling latencies of the
> (shared) target.
For the target-host I'm avoiding the problem, as it receives packets on
different HW queue and netservers will be running on different CPUs.
For the host, I'm by design, forcing it to run on the same single CPU,
to force using the same HW queue, so I can measure this HW queue and
its/BQLs push back. So, yes the host, is also affected by scheduling
latencies, which is bad. (perhaps reason NoneXSO cannot util BW).
How can I construct a test-case, on the host, to solve this problem?
(and still using/measuring the same xmit HW queue)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH net] macvlan: allow to enqueue broadcast pkt on virtual device
From: Nicolas Dichtel @ 2014-09-17 8:08 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel, Herbert Xu
Since commit 412ca1550cbe ("macvlan: Move broadcasts into a work queue"), the
driver uses tx_queue_len of the master device as the limit of packets enqueuing.
Problem is that virtual drivers have this value set to 0, thus all broadcast
packets were rejected.
Because tx_queue_len was arbitrarily chosen, I replace it with a static limit
of 1000 (also arbitrarily chosen).
CC: Herbert Xu <herbert@gondor.apana.org.au>
Reported-by: Thibaut Collet <thibaut.collet@6wind.com>
Suggested-by: Thibaut Collet <thibaut.collet@6wind.com>
Tested-by: Thibaut Collet <thibaut.collet@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
drivers/net/macvlan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index a96955597755..8e776935ca52 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -36,6 +36,7 @@
#include <linux/netpoll.h>
#define MACVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
+#define MACVLAN_BC_QUEUE_LEN 1000
struct macvlan_port {
struct net_device *dev;
@@ -248,7 +249,7 @@ static void macvlan_broadcast_enqueue(struct macvlan_port *port,
goto err;
spin_lock(&port->bc_queue.lock);
- if (skb_queue_len(&port->bc_queue) < skb->dev->tx_queue_len) {
+ if (skb_queue_len(&port->bc_queue) < MACVLAN_BC_QUEUE_LEN) {
__skb_queue_tail(&port->bc_queue, nskb);
err = 0;
}
--
2.1.0
^ permalink raw reply related
* Re: [GIT PULL nf-next 00/21] Second Round of IPVS Updates for v3.18
From: Pablo Neira Ayuso @ 2014-09-17 8:30 UTC (permalink / raw)
To: Julian Anastasov
Cc: Simon Horman, lvs-devel, netdev, netfilter-devel, Wensong Zhang
In-Reply-To: <alpine.LFD.2.11.1409170013440.3254@ja.home.ssi.bg>
On Wed, Sep 17, 2014 at 12:27:03AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Tue, 16 Sep 2014, Pablo Neira Ayuso wrote:
>
> > Hi Simon,
> >
> > On Tue, Sep 16, 2014 at 09:34:14AM +0900, Simon Horman wrote:
> > > Hi Pablo,
> > >
> > > please consider these IPVS updates for v3.18.
> > >
> > > * Add simple weighted failover scheduler
> > > - Thanks to Kenny Mathis
> > > * Support v6 real servers in v4 pools and vice versa
> > > - Thanks to Alex Gartrell and Julian Anastasov
> >
> > I need a slightly larger description of this series.
> >
> > I think you can merge patches 13-19 too. They are mostly two liners
> > with a similar description, so they naturally belong to the same
> > logical change. I would like to reduce the patchbomb pull request for
> > David.
>
> Good idea, done.
>
> Simon, I'm attaching such patch that replaces all
> these "ipvs: use correct address family in * logs".
> It additionally changes the new ip_vs_fo.c scheduler
> and ip_vs_wrr.c which was missed.
Thanks Julian.
@Simon, I can manually apply this batch if that reduces your workload.
Please let me know what you prefer.
Still I'd really appreciate a longer series description that I can
include in the pull-request for David.
Thanks.
^ permalink raw reply
* Re: [patch net-next 01/13] openvswitch: split flow structures into ovs specific and generic ones
From: Jiri Pirko @ 2014-09-17 8:34 UTC (permalink / raw)
To: Pravin Shelar
Cc: netdev, David Miller, nhorman, Andy Gospodarek, Thomas Graf,
Daniel Borkmann, Or Gerlitz, Jesse Gross, Andy Zhou,
Ben Hutchings, Stephen Hemminger, jeffrey.t.kirsher, vyasevic,
Cong Wang, john.r.fastabend, Eric Dumazet, Jamal Hadi Salim,
sfeldma, Florian Fainelli, roopa, John Linville,
dev@openvswitch.org, jasowang, ebiederm
In-Reply-To: <CALnjE+qwbQ=5wsLddvZX95xE2_U=osuDg8S10zKWarMD9mp4Aw@mail.gmail.com>
Thu, Sep 04, 2014 at 10:46:28PM CEST, pshelar@nicira.com wrote:
>On Thu, Sep 4, 2014 at 5:33 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Wed, Sep 03, 2014 at 08:41:39PM CEST, pshelar@nicira.com wrote:
>>>On Wed, Sep 3, 2014 at 2:24 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>> After this, flow related structures can be used in other code.
>>>>
>>>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>>> ---
>>>> include/net/sw_flow.h | 99 ++++++++++++++++++++++++++++++++++
>>>> net/openvswitch/actions.c | 3 +-
>>>> net/openvswitch/datapath.c | 74 +++++++++++++-------------
>>>> net/openvswitch/datapath.h | 4 +-
>>>> net/openvswitch/flow.c | 6 +--
>>>> net/openvswitch/flow.h | 102 +++++++----------------------------
>>>> net/openvswitch/flow_netlink.c | 53 +++++++++---------
>>>> net/openvswitch/flow_netlink.h | 10 ++--
>>>> net/openvswitch/flow_table.c | 118 ++++++++++++++++++++++-------------------
>>>> net/openvswitch/flow_table.h | 30 +++++------
>>>> net/openvswitch/vport-gre.c | 4 +-
>>>> net/openvswitch/vport-vxlan.c | 2 +-
>>>> net/openvswitch/vport.c | 2 +-
>>>> net/openvswitch/vport.h | 2 +-
>>>> 14 files changed, 276 insertions(+), 233 deletions(-)
>>>> create mode 100644 include/net/sw_flow.h
>>>>
>>>> diff --git a/include/net/sw_flow.h b/include/net/sw_flow.h
>>>> new file mode 100644
>>>> index 0000000..21724f1
>>>> --- /dev/null
>>>> +++ b/include/net/sw_flow.h
>>>> @@ -0,0 +1,99 @@
>>>> +/*
>>>> + * include/net/sw_flow.h - Generic switch flow structures
>>>> + * Copyright (c) 2007-2012 Nicira, Inc.
>>>> + * Copyright (c) 2014 Jiri Pirko <jiri@resnulli.us>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License as published by
>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>> + * (at your option) any later version.
>>>> + */
>>>> +
>>>> +#ifndef _NET_SW_FLOW_H_
>>>> +#define _NET_SW_FLOW_H_
>>>> +
>>>> +struct sw_flow_key_ipv4_tunnel {
>>>> + __be64 tun_id;
>>>> + __be32 ipv4_src;
>>>> + __be32 ipv4_dst;
>>>> + __be16 tun_flags;
>>>> + u8 ipv4_tos;
>>>> + u8 ipv4_ttl;
>>>> +};
>>>> +
>>>> +struct sw_flow_key {
>>>> + struct sw_flow_key_ipv4_tunnel tun_key; /* Encapsulating tunnel key. */
>>>> + struct {
>>>> + u32 priority; /* Packet QoS priority. */
>>>> + u32 skb_mark; /* SKB mark. */
>>>> + u16 in_port; /* Input switch port (or DP_MAX_PORTS). */
>>>> + } __packed phy; /* Safe when right after 'tun_key'. */
>>>> + struct {
>>>> + u8 src[ETH_ALEN]; /* Ethernet source address. */
>>>> + u8 dst[ETH_ALEN]; /* Ethernet destination address. */
>>>> + __be16 tci; /* 0 if no VLAN, VLAN_TAG_PRESENT set otherwise. */
>>>> + __be16 type; /* Ethernet frame type. */
>>>> + } eth;
>>>> + struct {
>>>> + u8 proto; /* IP protocol or lower 8 bits of ARP opcode. */
>>>> + u8 tos; /* IP ToS. */
>>>> + u8 ttl; /* IP TTL/hop limit. */
>>>> + u8 frag; /* One of OVS_FRAG_TYPE_*. */
>>>> + } ip;
>>>> + struct {
>>>> + __be16 src; /* TCP/UDP/SCTP source port. */
>>>> + __be16 dst; /* TCP/UDP/SCTP destination port. */
>>>> + __be16 flags; /* TCP flags. */
>>>> + } tp;
>>>> + union {
>>>> + struct {
>>>> + struct {
>>>> + __be32 src; /* IP source address. */
>>>> + __be32 dst; /* IP destination address. */
>>>> + } addr;
>>>> + struct {
>>>> + u8 sha[ETH_ALEN]; /* ARP source hardware address. */
>>>> + u8 tha[ETH_ALEN]; /* ARP target hardware address. */
>>>> + } arp;
>>>> + } ipv4;
>>>> + struct {
>>>> + struct {
>>>> + struct in6_addr src; /* IPv6 source address. */
>>>> + struct in6_addr dst; /* IPv6 destination address. */
>>>> + } addr;
>>>> + __be32 label; /* IPv6 flow label. */
>>>> + struct {
>>>> + struct in6_addr target; /* ND target address. */
>>>> + u8 sll[ETH_ALEN]; /* ND source link layer address. */
>>>> + u8 tll[ETH_ALEN]; /* ND target link layer address. */
>>>> + } nd;
>>>> + } ipv6;
>>>> + };
>>>> +} __aligned(BITS_PER_LONG/8); /* Ensure that we can do comparisons as longs. */
>>>> +
>>>
>>>HW offload API should be separate from OVS module. This has following
>>>advantages.
>>>1. It can be managed by OVS userspace vswitchd process which has much
>>>better context to setup hardware flow table. Once we add capabilities
>>>for swdev, it is much more easier for vswitchd process to choose
>>>correct (hw or sw) flow table for given flow.
>>
>> The idea is to add a nl attr in ovs genl iface so the vswitchd can
>> speficify the flow the to be in sw only, in hw only, in both.
>> I believe that is is more convenient to let switchd to communicate flows
>> via single iface.
>>
>How is it convenient? this patch complicates OVS kernel module. It add
>OVS interfaces for HW offload. And you need similar interfaces for
>switchdev device. So it duplicate code.
There is almost no code duplication there. And in next patchset
iteration I plan to have even less.
>On the other hand if vswitchd uses common interface (switchdev) there
>is no need to extend ovs kernel interface. For example specifying
>extra metadata, like (sw only, hw olny, both).
I understand you point of view. However from the offloading perspective
it makes much more sense to push the flows through a single interface
(ovs genl) and only offload selected flows to hw (pushing further).
Having vswitchd to handle 2 different ifaces for the same/similar thing
does not seem like a clean solution to me. And it really breaks the
offloading view.
Plus the amount of code needed to be pushed into ovs kernel dp code in
order to enable this is small.
>
>>>2. Other application that wants to use HW offload does not have
>>>dependency on OVS kernel module.
>>
>> That is not the case for this patchset. Userspace can insert/remove
>> flows using the switchdev generic netlink api - see:
>> [patch net-next 13/13] switchdev: introduce Netlink API
>>
>>>3. Hardware and software datapath remains separate, these two
>>>components has no dependency on each other, both can be developed
>>>independent of each other.
>>
>>
>> The general idea is to have the offloads handled in-kernel. Therefore I
>> hooked on to ovs kernel dp code.
>>
>>
>>
^ permalink raw reply
* Re: [PATCH v7 ethtool 0/2] patchset - Support for configurable RSS hash key
From: Ivan Vecera @ 2014-09-17 8:55 UTC (permalink / raw)
To: ben@decadent.org.uk; +Cc: Venkat Duvvuru, netdev@vger.kernel.org
In-Reply-To: <53E86A79.8010700@redhat.com>
On 11.8.2014 09:02, Ivan Vecera wrote:
> On 31.7.2014 09:43, Venkat Duvvuru wrote:
>>
>>
>>> -----Original Message-----
>>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>>> owner@vger.kernel.org] On Behalf Of Venkat Duvvuru
>>> Sent: Tuesday, July 22, 2014 5:51 PM
>>> To: ben@decadent.org.uk
>>> Cc: netdev@vger.kernel.org; Venkat Duvvuru
>>> Subject: [PATCH v7 ethtool 0/2] patchset - Support for configurable
>>> RSS hash
>>> key
>>>
>>> NIC drivers that support RSS use either a hard-coded value or a
>>> random value
>>> for the RSS hash key. Irrespective of the type of the key used, the user
>>> would want to change the hash key if he/she is not satisfied with the
>>> effectiveness of the default hash-key in spreading the incoming flows
>>> evenly
>>> across the RSS queues.
>>>
>>> This patch set adds support for configuring the RSS hash-key via the
>>> ethtool
>>> interface using -X/-x option.
>>>
>>> v7:
>>> 1. Changed rss string to RSS to be consistent with other parts of the
>>> error
>>> codes
>>> and documentation.
>>> 2. Corrected a few error messages
>>> 3. Changed error codes to use either 1 or 2 based on the situation
>>> 4. Added test cases in test-cmdline.c
>>>
>>> Venkat Duvvuru (2):
>>> ethtool: Support for configurable RSS hash key.
>>> ethtool: Support for configurable RSS hash key.
>>>
>>> ethtool-copy.h | 478
>>> ++++++++++++++++++++++++++++++++++++++++++--------------
>>> ethtool.8.in | 18 ++-
>>> ethtool.c | 393 +++++++++++++++++++++++++++++++++++++++--------
>>> test-cmdline.c | 11 ++
>>> 4 files changed, 717 insertions(+), 183 deletions(-)
>>
>> Ben, Please let me know if you have any further comments on this.
>>
>> /Venkat.
> Hi Ben,
> any objection?
>
> Ivan
Ben, is there any problem with this??
Ivan
^ permalink raw reply
* RE: [PATCHv4 net-next 2/3] sunvnet: allow admin to set sunvnet MTU
From: David Laight @ 2014-09-17 9:07 UTC (permalink / raw)
To: 'David L Stevens', David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <541886B9.3010206@oracle.com>
From: David L Stevens
> On 09/15/2014 08:35 PM, David L Stevens wrote:
>
> > */
> > #define VNET_TX_TIMEOUT (5 * HZ)
> >
> > -#define VNET_MAXPACKET 1518ULL /* ETH_FRAMELEN + VLAN_HDR */
> > +#define VNET_MAXPACKET 65553ULL /* 64K-1 +ETH HDR +VLAN HDR*/
That would be better as the expression (0xffffull + 14 + 4).
> > #define VNET_TX_RING_SIZE 512
> > #define VNET_TX_WAKEUP_THRESH(dr) ((dr)->pending / 4)
David
^ permalink raw reply
* RE: [PATCH v2 3/4] net: stmmac: add support for Intel Quark X1000
From: Kweh, Hock Leong @ 2014-09-17 9:11 UTC (permalink / raw)
To: David Miller
Cc: peppe.cavallaro@st.com, rayagond@vayavyalabs.com,
vbridgers2013@gmail.com, srinivas.kandagatla@st.com,
wens@csie.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Ong, Boon Leong
In-Reply-To: <20140917.005532.2054822778882237895.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, September 17, 2014 12:56 PM
> From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
> Date: Wed, 17 Sep 2014 02:41:39 +0000
>
> > Thanks for the pointer. I did a quickly checking on the class number
> > to see if I could use it for differentiation the ports number. Whereas
> > I found them both have the same class number as well. Below shows the
> > "lspci" dump to all the PCI devices on Quark X1000 Galileo board
> > (Ethernet controllers are
> > 00:14.6 and 00:14.7). Very unfortunately we are unlikely to use the
> > class number as well as pci_device_id for the differentiation.
> ...
> > 00:14.6 "Class 0200" "8086" "0937" "8086" "0937"
> > 00:14.7 "Class 0200" "8086" "0937" "8086" "0937"
>
> Are you kidding me? It's a perfect way to identify this device, it properly uses
> PCI_CLASS_NETWORK_ETHERNET (0x0200) in both cases and this will not
> match any other function on this PCI device at all.
>
> Please do as I suggested and use the PCI class for the differentiation and
> matching during probing.
Hi David,
Thanks for your feedback so far. Appreciate it.
Off the list because I think that my poorly written description may have caused some confusion. My sincere apology here.
Unfortunately, I don't really grasp your idea clearly based on your responses which I appreciate them a lot.
Sorry for the long description below but I hope to clearly pen down my thinking process so that you can follow my thinking incrementally without being confused.
So, let's roll back a bit so that with my following description, you can help correct me if my understanding of using PCI function ID to differentiate PHY port that is associated with each Ethernet controller is wrong:
The high-level idea about the change that I made for STMMAC IP inside Quark is as follow:
(1) Based on Quark-specific PCI ID declared inside stmmac_id_table[], the probe() function is
called to continue setting-up STMMAC for Quark.
@@ -228,11 +303,13 @@ static int stmmac_pci_resume(struct pci_dev *pdev)
#define STMMAC_VENDOR_ID 0x700
#define STMMAC_DEVICE_ID 0x1108
+#define STMMAC_QUARK_X1000_ID 0x0937
static const struct pci_device_id stmmac_id_table[] = {
{PCI_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID), PCI_ANY_ID,
PCI_ANY_ID, CHIP_STMICRO},
{PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_MAC), CHIP_STMICRO},
+ {PCI_VDEVICE(INTEL, STMMAC_QUARK_X1000_ID), CHIP_QUARK_X1000},
{}
};
(2) Back-ground on STMMAC hardware configuration on Intel Galileo Gen 1 & Gen 2 platforms:
Intel Quark SoC has 2 MAC controller as described by lspci output below:
00:14.6 Class 0200: 8086:0937 ====> 1st MAC controller
00:14.7 Class 0200: 8086:0937 ====> 2nd MAC controller
These Galileo boards use the same Intel Quark SoC and there is only one PHY connect to the 1st MAC [00:14.6 Class 0200: 8086:0937] The 2nd MAC [00:14.7 Class 0200: 8086:0937] is NOT connected to any PHY at all.
So, it appears to me that the only way that I can differentiate between 1st & 2nd MAC are based on PCI function ID, i.e. 14.6 & 14.7. Therefore, within the probe() function, for Intel Quark SoC only, the function performs next-level discovery of 1st or 2nd MAC controller through quark_run_time_config() function.
For other PCI ID (currently STMICRO_MAC) there is NO next-level discovery involved as rt_config is NULL.
Changes shown below:
static struct platform_data platform_info[] = { @@ -59,15 +65,76 @@ static struct platform_data platform_info[] = {
.phy_reset = NULL,
.phy_mask = 0,
.pbl = 32,
+ .fixed_burst = 0,
.burst_len = DMA_AXI_BLEN_256,
+ .rt_config = NULL, ===================> no 2nd-level discovery for other PCI ID
+ },
+ [CHIP_QUARK_X1000] = {
+ .phy_addr = 1,
+ .interface = PHY_INTERFACE_MODE_RMII,
+ .clk_csr = 2,
+ .has_gmac = 1,
+ .force_sf_dma_mode = 1,
+ .multicast_filter_bins = HASH_TABLE_SIZE,
+ .unicast_filter_entries = 1,
+ .phy_reset = NULL,
+ .phy_mask = 0,
+ .pbl = 16,
+ .fixed_burst = 1,
+ .burst_len = DMA_AXI_BLEN_256,
+ .rt_config = &quark_run_time_config, ==========> Quark specific 2nd-level discovery
+ },
+};
(3) Within quark_run_time_config(), due to the only way to differentiate 1st or 2nd MAC controller according to difference in function ID explained above, the following changes are made:
+static void quark_run_time_config(int chip_id, struct pci_dev *pdev) {
+ const char *board_name = dmi_get_system_info(DMI_BOARD_NAME);
+ int i;
+ int func_num = PCI_FUNC(pdev->devfn);
+
+ if (!board_name)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(quark_x1000_phy_info); i++) {
+ if ((!strcmp(quark_x1000_phy_info[i].board_name, board_name)) &&
+ quark_x1000_phy_info[i].pci_func_num == func_num)
+ platform_info[chip_id].phy_addr =
+ quark_x1000_phy_info[i].phy_address;
+ }
+}
The reasons for the above proposed condition checks, i.e. "board name" & "pci function name" are below:
a) As described above, the only difference in both instance of STMMAC IP inside Intel Quark SoC is the function ID,
so I have proposed to use function ID to be the decision point here to differentiate 1st MAC from 2nd MAC.
b) Allow future expansion of any other Intel Quark platforms with specific need to fix PHY address
c) A PHY address set as "-1" is to mark that the PHY (associated with function ID) is not connected to MAC, which
is being used here for the 2 Galileo boards -> 2nd MAC port not connected with PHY.
Finally, based on the above description, it appears to me that using PCI function ID to decode seems viable for Intel Quark specific hardware configuration.
Appreciate your time and any feedback is very much appreciated.
Thanks.
Regards,
Wilson
^ permalink raw reply
* [PATCH net-next] tcp: do not fake tcp headers in tcp_send_rcvq()
From: Eric Dumazet @ 2014-09-17 10:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Pavel Emelyanov, Neal Cardwell
From: Eric Dumazet <edumazet@google.com>
Now we no longer rely on having tcp headers for skbs in receive queue,
tcp repair do not need to build fake ones.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
Note: It seems we have no checks against too big sizes and alloc_skb()
could die hard ?
net/ipv4/tcp_input.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index ea92f23ffaf1..02fb66d4a018 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4304,24 +4304,19 @@ static int __must_check tcp_queue_rcv(struct sock *sk, struct sk_buff *skb, int
int tcp_send_rcvq(struct sock *sk, struct msghdr *msg, size_t size)
{
- struct sk_buff *skb = NULL;
- struct tcphdr *th;
+ struct sk_buff *skb;
bool fragstolen;
if (size == 0)
return 0;
- skb = alloc_skb(size + sizeof(*th), sk->sk_allocation);
+ skb = alloc_skb(size, sk->sk_allocation);
if (!skb)
goto err;
- if (tcp_try_rmem_schedule(sk, skb, size + sizeof(*th)))
+ if (tcp_try_rmem_schedule(sk, skb, skb->truesize))
goto err_free;
- th = (struct tcphdr *)skb_put(skb, sizeof(*th));
- skb_reset_transport_header(skb);
- memset(th, 0, sizeof(*th));
-
if (memcpy_fromiovec(skb_put(skb, size), msg->msg_iov, size))
goto err_free;
@@ -4329,7 +4324,7 @@ int tcp_send_rcvq(struct sock *sk, struct msghdr *msg, size_t size)
TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(skb)->seq + size;
TCP_SKB_CB(skb)->ack_seq = tcp_sk(sk)->snd_una - 1;
- if (tcp_queue_rcv(sk, skb, sizeof(*th), &fragstolen)) {
+ if (tcp_queue_rcv(sk, skb, 0, &fragstolen)) {
WARN_ON_ONCE(fragstolen); /* should not happen */
__kfree_skb(skb);
}
^ permalink raw reply related
* Re: bisected regression: 3c59x corrupts packets in 3.17-rc5
From: Neil Horman @ 2014-09-17 10:27 UTC (permalink / raw)
To: David Miller; +Cc: mroos, klassert, netdev, linux-kernel
In-Reply-To: <20140916.162923.605101746131407931.davem@davemloft.net>
On Tue, Sep 16, 2014 at 04:29:23PM -0400, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Tue, 16 Sep 2014 06:17:04 -0400
>
> > I'm guessing the above change has uncovered another bug,
>
> Neil, read your patch carefully, I think it added the bug.
>
> The ->page_offset of the frag gets applied two times.
>
> skb_dma_map_frag() already takes frag->page_offset into consideration,
> you then pass it in as the 'offset' argument and it then gets added to
> itself to compute th final offset.
>
Shit, you're right, sorry about that. Its odd, I'm running it here, and its not
causing problems, but thats obviously wrong. Meelis, please add the above fix
to your test and confirm that it sovles the problem. If you could keep the
previous patch in place too that would be great, as we should probably add the
dma error checking anyway.
[PATCH] 3c59x: Fix bad offset spec in skb_frag_dma_map
Recently aded the use of skb_frag_dma_map to 3c59x, but didn't realize it
automatically included the frag_offset internally, as well as provided an option
to specify an extra offset in the parameter list. We need to specify an offset
of 0 in the parameter list to avoid skb corruption that results in lost
connections.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
---
drivers/net/ethernet/3com/3c59x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/3com/3c59x.c b/drivers/net/ethernet/3com/3c59x.c
index 5621dab..0f59d68 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -2186,7 +2186,7 @@ boomerang_start_xmit(struct sk_buff *skb, struct net_device *dev)
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
dma_addr = skb_frag_dma_map(&VORTEX_PCI(vp)->dev, frag,
- frag->page_offset,
+ 0,
frag->size,
DMA_TO_DEVICE);
if (dma_mapping_error(&VORTEX_PCI(vp)->dev, dma_addr)) {
--
1.9.3
^ permalink raw reply related
* [PATCH][V2] Freescale Frame Manager Device Tree binding document
From: Igal.Liberman @ 2014-09-17 11:08 UTC (permalink / raw)
To: devicetree, linuxppc-dev, netdev; +Cc: scottwood, Igal Liberman, Emilian.Medve
From: Igal Liberman <Igal.Liberman@freescale.com>
The Frame Manager (FMan) combines the Ethernet network interfaces with packet
distribution logic to provide intelligent distribution and queuing decisions
for incoming traffic at line rate.
This binding document describes Freescale's Frame Manager hardware attributes
that are used by the Frame Manager driver for its basic initialization and
configuration.
Difference between [V1] and [V2]:
Addressed all comments recieved from Scott in [V1]
Signed-off-by: Igal Liberman <Igal.Liberman@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/fman.txt | 529 ++++++++++++++++++++
1 file changed, 529 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/fman.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
new file mode 100644
index 0000000..da8e5f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
@@ -0,0 +1,529 @@
+=============================================================================
+Freescale Frame Manager Device Bindings
+
+CONTENTS
+ - FMan Node
+ - FMan Port Node
+ - FMan MURAM Node
+ - FMan dTSEC/XGEC/mEMAC Node
+ - FMan IEEE 1588 Node
+ - Example
+
+=============================================================================
+FMan Node
+
+DESCRIPTION
+
+Due to the fact that the FMan is an aggregation of sub-engines (ports, MACs,
+etc.) the FMan node will have child nodes for each of them.
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type: <stringlist>
+ Definition: Must include "fsl,fman"
+ FMan version can be determined via FM_IP_REV_1 register in the
+ FMan block. The offset is 0xc4 from the beginning of the
+ Frame Processing Manager memory map (0xc3000 from the
+ beginning of the FMan node).
+
+- cell-index
+ Usage: required
+ Value type: <u32>
+ Definition: Specifies the index of the FMan unit.
+
+ The cell-index value may be used by the SoC, to identify the
+ FMan unit in the SoC memory map. In the table bellow,
+ there's a description of the cell-index use in each SoC:
+
+ - P1023:
+ register[bit] FMan unit cell-index
+ ============================================================
+ DEVDISR[1] 1 0
+
+ - P2041, P3041, P4080 P5020, P5040:
+ register[bit] FMan unit cell-index
+ ============================================================
+ DCFG_DEVDISR2[6] 1 0
+ DCFG_DEVDISR2[14] 2 1
+ (Second FM available only in P4080 and P5040)
+
+ - B4860, T1040, T2080, T4240:
+ register[bit] FMan unit cell-index
+ ============================================================
+ DCFG_CCSR_DEVDISR2[24] 1 0
+ DCFG_CCSR_DEVDISR2[25] 2 1
+ (Second FM available only in T4240)
+
+ DEVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in
+ the specific SoC "Device Configuration/Pin Control" Memory
+ Map.
+
+- reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. Specifies the offset of the
+ following configuration registers:
+ - BMI configuration registers.
+ - QMI configuration registers.
+ - DMA configuration registers.
+ - FPM configuration registers.
+ - FMan controller configuration registers.
+
+- ranges
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property.
+
+- clocks
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: phandle for fman clock.
+
+- clock-names
+ usage: optional
+ Value type: <stringlist>
+ Definition: A standard property
+
+- interrupts
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A pair of IRQs are specified in this property.
+ The first element is associated with the event interrupts and
+ the second element is associated with the error interrupts.
+
+- fsl,qman-channel-range
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: Specifies the range of the available dedicated
+ channels in the FMan. The first cell specifies the beginning
+ of the range and the second cell specifies the number of
+ channels.
+ Further information available at:
+ "Work Queue (WQ) Channel Assignments in the QMan" section
+ in DPAA Reference Manual.
+
+=============================================================================
+FMan MURAM Node
+
+DESCRIPTION
+
+FMan Internal memory - shared between all the FMan modules.
+It contains data structures that are common and written to or read by
+the modules.
+FMan internal memory is split into the following parts:
+ Packet buffering (Tx/Rx FIFOs)
+ Frames internal context
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type: <stringlist>
+ Definition: Must include "fsl,fman-muram"
+
+- ranges
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property.
+ Specifies the multi-user memory offset and the size within
+ the FMan.
+
+EXAMPLE
+
+muram@0 {
+ compatible = "fsl,fman-muram";
+ ranges = <0 0x000000 0x28000>;
+};
+
+=============================================================================
+FMan Port Node
+
+DESCRIPTION
+
+The Frame Manager (FMan) supports several types of hardware ports:
+ Ethernet receiver (RX)
+ Ethernet transmitter (TX)
+ Offline/Host command (O/H)
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type: <stringlist>
+ Definition: A standard property.
+ Must include one of the following:
+ - "fsl,fman-v2-port-oh" for FManV2 OH ports
+ - "fsl,fman-v2-port-rx" for FManV2 RX ports
+ - "fsl,fman-v2-port-tx" for FManV2 TX ports
+ - "fsl,fman-v3-port-oh" for FManV3 OH ports
+ - "fsl,fman-v3-port-rx" for FManV3 RX ports
+ - "fsl,fman-v3-port-tx" for FManV3 TX ports
+
+- cell-index
+ Usage: required
+ Value type: <u32>
+ Definition: Specifies the hardware port id.
+ Each hardware port on the FMan has its own hardware PortID.
+ Super set of all hardware Port IDs available at FMan Reference
+ Manual under "FMan Hardware Ports in Freescale Devices" table.
+
+ Each hardware port is assigned a 4KB, port-specific page in
+ the FMan hardware port memory region (which is part of the
+ FMan memory map). The first 4 KB in the FMan hardware ports
+ memory region is used for what are called common registers.
+ The subsequent 63 4KB pages are allocated to the hardware
+ ports.
+ The page of a specific port is determined by the cell-index.
+
+- reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: There is one reg region describing the port
+ configuration registers.
+
+EXAMPLE
+
+port@a8000 {
+ cell-index = <0x28>;
+ compatible = "fsl,fman-v2-port-tx";
+ reg = <0xa8000 0x1000>;
+};
+
+port@88000 {
+ cell-index = <0x8>;
+ compatible = "fsl,fman-v2-port-rx";
+ reg = <0x88000 0x1000>;
+};
+
+port@81000 {
+ cell-index = <0x1>;
+ compatible = "fsl,fman-v2-port-oh";
+ reg = <0x81000 0x1000>;
+};
+
+=============================================================================
+FMan dTSEC/XGEC/mEMAC Node
+
+DESCRIPTION
+
+mEMAC/dTSEC/XGEC are the Ethernet network interfaces
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type: <stringlist>
+ Definition: A standard property.
+ Must include one of the following:
+ - "fsl,fman-dtsec" for dTSEC MAC
+ - "fsl,fman-xgec" for XGEC MAC
+ - "fsl,fman-memac for mEMAC MAC
+
+- cell-index
+ Usage: required
+ Value type: <u32>
+ Definition: Specifies the MAC id.
+
+ The cell-index value may be used by the FMan or the SoC, to
+ identify the MAC unit in the FMan (or SoC) memory map.
+ In the tables bellow there's a description of the cell-index
+ use, there are two tables, one describes the use of cell-index
+ by the FMan, the second describes the use by the SoC:
+
+ 1. FMan Registers
+
+ FManV2:
+ register[bit] MAC cell-index
+ ============================================================
+ FM_EPI[16] XGEC 8
+ FM_EPI[16+n] dTSECn n-1
+ FM_NPI[11+n] dTSECn n-1
+ n = 1,..,5
+
+ FManV3:
+ register[bit] MAC cell-index
+ ============================================================
+ FM_EPI[16+n] mEMACn n-1
+ FM_EPI[25] mEMAC10 9
+
+ FM_NPI[11+n] mEMACn n-1
+ FM_NPI[10] mEMAC10 9
+ FM_NPI[11] mEMAC9 8
+ n = 1,..8
+
+ FM_EPI and FM_NPI are located in the FMan memory map.
+
+ 2. SoC registers:
+
+ - P2041, P3041, P4080 P5020, P5040:
+ register[bit] FMan MAC cell
+ Unit index
+ ============================================================
+ DCFG_DEVDISR2[7] 1 XGEC 8
+ DCFG_DEVDISR2[7+n] 1 dTSECn n-1
+ DCFG_DEVDISR2[15] 2 XGEC 8
+ DCFG_DEVDISR2[15+n] 2 dTSECn n-1
+ n = 1,..5
+
+ - T1040, T2080, T4240, B4860:
+ register[bit] FMan MAC cell
+ Unit index
+ ============================================================
+ DCFG_CCSR_DEVDISR2[n-1] 1 mEMACn n-1
+ DCFG_CCSR_DEVDISR2[11+n] 2 mEMACn n-1
+ n = 1,..6,9,10
+
+ EVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in
+ the specific SoC "Device Configuration/Pin Control" Memory
+ Map.
+
+- reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property.
+
+- fsl,fman-ports
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: An array of two phandles - the first references is
+ the FMan RX port and the second is the TX port used by this
+ MAC.
+
+- ptp-timer
+ Usage required
+ Value type: <phandle>
+ Definition: A phandle for 1EEE1588 timer.
+
+EXAMPLE
+
+fman1_tx28: port@a8000 {
+ cell-index = <0x28>;
+ compatible = "fsl,fman-v2-port-tx";
+ reg = <0xa8000 0x1000>;
+};
+
+fman1_rx8: port@88000 {
+ cell-index = <0x8>;
+ compatible = "fsl,fman-v2-port-rx";
+ reg = <0x88000 0x1000>;
+};
+
+ptp-timer: ptp_timer@fe000 {
+ compatible = "fsl,fman-ptp-timer";
+ reg = <0xfe000 0x1000>;
+};
+
+ethernet@e0000 {
+ compatible = "fsl,fman-dtsec";
+ cell-index = <0>;
+ reg = <0xe0000 0x1000>;
+ fsl,fman-ports = <&fman1_rx8 &fman1_tx28>;
+ ptp-timer = <&ptp-timer>;
+};
+
+============================================================================
+FMan IEEE 1588 Node
+
+DESCRIPTION
+
+The FMan interface to support IEEE 1588
+
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type: <stringlist>
+ Definition: A standard property.
+ Must include "fsl,fman-ptp-timer".
+
+- reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property.
+
+EXAMPLE
+
+ptp-timer@fe000 {
+ compatible = "fsl,fman-ptp-timer";
+ reg = <0xfe000 0x1000>;
+};
+
+=============================================================================
+Example
+
+fman@400000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <1>;
+ compatible = "fsl,fman"
+ ranges = <0 0x400000 0x100000>;
+ reg = <0x400000 0x100000>;
+ clocks = <&fman_clk>;
+ clock-names = "fmanclk";
+ interrupts = <
+ 96 2 0 0
+ 16 2 1 1>;
+ fsl,qman-channel-range = <0x40 0xc>;
+
+ muram@0 {
+ compatible = "fsl,fman-muram";
+ reg = <0x0 0x28000>;
+ };
+
+ port@81000 {
+ cell-index = <1>;
+ compatible = "fsl,fman-v2-port-oh";
+ reg = <0x81000 0x1000>;
+ };
+
+ port@82000 {
+ cell-index = <2>;
+ compatible = "fsl,fman-v2-port-oh";
+ reg = <0x82000 0x1000>;
+ };
+
+ port@83000 {
+ cell-index = <3>;
+ compatible = "fsl,fman-v2-port-oh";
+ reg = <0x83000 0x1000>;
+ };
+
+ port@84000 {
+ cell-index = <4>;
+ compatible = "fsl,fman-v2-port-oh";
+ reg = <0x84000 0x1000>;
+ };
+
+ port@85000 {
+ cell-index = <5>;
+ compatible = "fsl,fman-v2-port-oh";
+ reg = <0x85000 0x1000>;
+ };
+
+ port@86000 {
+ cell-index = <6>;
+ compatible = "fsl,fman-v2-port-oh";
+ reg = <0x86000 0x1000>;
+ };
+
+ fman1_rx_0x8: port@88000 {
+ cell-index = <0x8>;
+ compatible = "fsl,fman-v2-port-rx";
+ reg = <0x88000 0x1000>;
+ };
+
+ fman1_rx_0x9: port@89000 {
+ cell-index = <0x9>;
+ compatible = "fsl,fman-v2-port-rx";
+ reg = <0x89000 0x1000>;
+ };
+
+ fman1_rx_0xa: port@8a000 {
+ cell-index = <0xa>;
+ compatible = "fsl,fman-v2-port-rx";
+ reg = <0x8a000 0x1000>;
+ };
+
+ fman1_rx_0xb: port@8b000 {
+ cell-index = <0xb>;
+ compatible = "fsl,fman-v2-port-rx";
+ reg = <0x8b000 0x1000>;
+ };
+
+ fman1_rx_0xc: port@8c000 {
+ cell-index = <0xc>;
+ compatible = "fsl,fman-v2-port-rx";
+ reg = <0x8c000 0x1000>;
+ };
+
+ fman1_rx_0x10: port@90000 {
+ cell-index = <0x10>;
+ compatible = "fsl,fman-v2-port-rx";
+ reg = <0x90000 0x1000>;
+ };
+
+ fman1_tx_0x28: port@a8000 {
+ cell-index = <0x28>;
+ compatible = "fsl,fman-v2-port-tx";
+ reg = <0xa8000 0x1000>;
+ };
+
+ fman1_tx_0x29: port@a9000 {
+ cell-index = <0x29>;
+ compatible = "fsl,fman-v2-port-tx";
+ reg = <0xa9000 0x1000>;
+ };
+
+ fman1_tx_0x2a: port@aa000 {
+ cell-index = <0x2a>;
+ compatible = "fsl,fman-v2-port-tx";
+ reg = <0xaa000 0x1000>;
+ };
+
+ fman1_tx_0x2b: port@ab000 {
+ cell-index = <0x2b>;
+ compatible = "fsl,fman-v2-port-tx";
+ reg = <0xab000 0x1000>;
+ };
+
+ fman1_tx_0x2c: port@ac0000 {
+ cell-index = <0x2c>;
+ compatible = "fsl,fman-v2-port-tx";
+ reg = <0xac000 0x1000>;
+ };
+
+ fman1_tx_0x30: port@b0000 {
+ cell-index = <0x30>;
+ compatible = "fsl,fman-v2-port-tx";
+ reg = <0xb0000 0x1000>;
+ };
+
+ ethernet@e0000 {
+ compatible = "fsl,fman-dtsec";
+ cell-index = <0>;
+ reg = <0xe0000 0x1000>;
+ fsl,fman-ports = <&fman1_rx_0x8 &fman1_tx_0x28>;
+ };
+
+ ethernet@e2000 {
+ compatible = "fsl,fman-dtsec";
+ cell-index = <1>;
+ reg = <0xe2000 0x1000>;
+ fsl,fman-ports = <&fman1_rx_0x9 &fman1_tx_0x29>;
+ };
+
+ ethernet@e4000 {
+ compatible = "fsl,fman-dtsec";
+ cell-index = <2>;
+ reg = <0xe4000 0x1000>;
+ fsl,fman-ports = <&fman1_rx_0xa &fman1_tx_0x2a>;
+ };
+
+ ethernet@e6000 {
+ compatible = "fsl,fman-dtsec";
+ cell-index = <3>;
+ reg = <0xe6000 0x1000>;
+ fsl,fman-ports = <&fman1_rx_0xb &fman1_tx_0x2b>;
+ };
+
+ ethernet@e8000 {
+ compatible = "fsl,fman-dtsec";
+ cell-index = <4>;
+ reg = <0xf0000 0x1000>;
+ fsl,fman-ports = <&fman1_rx_0xc &fman1_tx_0x2c>;
+
+ ethernet@f0000 {
+ cell-index = <8>;
+ compatible = "fsl,fman-xgec";
+ reg = <0xf0000 0x1000>;
+ fsl,fman-ports = <&fman1_rx_0x10 &fman1_tx_0x30>;
+ };
+
+ ptp-timer@fe000 {
+ compatible = "fsl,fman-ptp-timer";
+ reg = <0xfe000 0x1000>;
+ };
+};
--
1.7.9.5
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply related
* Re: [PATCH net v2] bonding: fix div by zero while enslaving and transmitting
From: Nikolay Aleksandrov @ 2014-09-17 11:08 UTC (permalink / raw)
To: Ding Tianhong, netdev
Cc: Eric Dumazet, Andy Gospodarek, Jay Vosburgh, Veaceslav Falico
In-Reply-To: <541926EB.4010809@huawei.com>
On 17/09/14 08:15, Ding Tianhong wrote:
> On 2014/9/12 23:38, Nikolay Aleksandrov wrote:
>> The problem is that the slave is first linked and slave_cnt is
>> incremented afterwards leading to a div by zero in the modes that use it
>> as a modulus. What happens is that in bond_start_xmit()
>> bond_has_slaves() is used to evaluate further transmission and it becomes
>> true after the slave is linked in, but when slave_cnt is used in the xmit
>> path it is still 0, so fetch it once and transmit based on that. Since
>> it is used only in round-robin and XOR modes, the fix is only for them.
>> Thanks to Eric Dumazet for pointing out the fault in my first try to fix
>> this.
>>
>
> Hi, I think no need to add more checks in the xmit fast path, why not add a barrier to make
> sure the slave_cnt inc to 1 before access it.
>
> + /* Increment slave_cnt before linking in the slave so we won't end up in
> + * bond_start_xmit with bond_has_slaves() true and slave_cnt == 0.
> + */
> + bond->slave_cnt++;
> + wmb();
>
> I think it looks more efficiency, sorry for reply so late.
>
> Regards
> Ding
>
>
Hi Ding,
You should re-read Eric's comment to my first fix. In my first attempt I moved
the increment before the slave linking which does rcu_assign_pointer() which
implies a full memory barrier, IIRC. The issue is that this fixes the writer
side and makes sure the increment is visible before linking the slave, but I
missed that on the reader side (bond_start_xmit()) we don't have any barriers,
so the CPU is free to do whatever it likes with the access to slave_cnt F.e. it
can fetch it before the slave list.
Now, this fix shouldn't be felt much performance-wise since the likely() hint
will be correct 99% of the time because the situation where slave_cnt is not in
sync is only in a very short period of time while enslaving and releasing
slaves. If you'd like to further remove this one check - you could. You can
fetch slave_cnt only once in bond_start_xmit() and use that as a check for
further transmitting instead of empty slave list but you must pass down the
fetched value to the xmitting functions, that is you should not re-fetch it, so
it'd probably require you to add additional parameter to all modes' xmit
functions so you can pass it down from bond_start_xmit(). Since only 2 modes
actually use slave_cnt I don't think that is necessary.
In any case net should be merged with net-next first.
Cheers,
Nik
^ permalink raw reply
* [PATCH net-next] net: add alloc_skb_with_frags() helper
From: Eric Dumazet @ 2014-09-17 11:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Extract from sock_alloc_send_pskb() code building skb with frags,
so that we can reuse this in other contexts.
Intent is to use it from tcp_send_rcvq(), tcp_collapse(), ...
We also want to replace some skb_linearize() calls to a more reliable
strategy in pathological cases where we need to reduce number of frags.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/linux/skbuff.h | 6 +++
net/core/skbuff.c | 78 +++++++++++++++++++++++++++++++++++++++
net/core/sock.c | 78 +++++++--------------------------------
3 files changed, 99 insertions(+), 63 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 756e3d057e84..f1bfa3781c75 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -769,6 +769,12 @@ static inline struct sk_buff *alloc_skb(unsigned int size,
return __alloc_skb(size, priority, 0, NUMA_NO_NODE);
}
+struct sk_buff *alloc_skb_with_frags(unsigned long header_len,
+ unsigned long data_len,
+ int max_page_order,
+ int *errcode,
+ gfp_t gfp_mask);
+
static inline struct sk_buff *alloc_skb_fclone(unsigned int size,
gfp_t priority)
{
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 29f7f0121491..06a8feb10099 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4102,3 +4102,81 @@ err_free:
return NULL;
}
EXPORT_SYMBOL(skb_vlan_untag);
+
+/**
+ * alloc_skb_with_frags - allocate skb with page frags
+ *
+ * header_len: size of linear part
+ * data_len: needed length in frags
+ * max_page_order: max page order desired.
+ * errcode: pointer to error code if any
+ * gfp_mask: allocation mask
+ *
+ * This can be used to allocate a paged skb, given a maximal order for frags.
+ */
+struct sk_buff *alloc_skb_with_frags(unsigned long header_len,
+ unsigned long data_len,
+ int max_page_order,
+ int *errcode,
+ gfp_t gfp_mask)
+{
+ int npages = (data_len + (PAGE_SIZE - 1)) >> PAGE_SHIFT;
+ unsigned long chunk;
+ struct sk_buff *skb;
+ struct page *page;
+ gfp_t gfp_head;
+ int i;
+
+ *errcode = -EMSGSIZE;
+ /* Note this test could be relaxed, if we succeed to allocate
+ * high order pages...
+ */
+ if (npages > MAX_SKB_FRAGS)
+ return NULL;
+
+ gfp_head = gfp_mask;
+ if (gfp_head & __GFP_WAIT)
+ gfp_head |= __GFP_REPEAT;
+
+ *errcode = -ENOBUFS;
+ skb = alloc_skb(header_len, gfp_head);
+ if (!skb)
+ return NULL;
+
+ skb->truesize += npages << PAGE_SHIFT;
+
+ for (i = 0; npages > 0; i++) {
+ int order = max_page_order;
+
+ while (order) {
+ if (npages >= 1 << order) {
+ page = alloc_pages(gfp_mask |
+ __GFP_COMP |
+ __GFP_NOWARN |
+ __GFP_NORETRY,
+ order);
+ if (page)
+ goto fill_page;
+ /* Do not retry other high order allocations */
+ order = 1;
+ max_page_order = 0;
+ }
+ order--;
+ }
+ page = alloc_page(gfp_mask);
+ if (!page)
+ goto failure;
+fill_page:
+ chunk = min_t(unsigned long, data_len,
+ PAGE_SIZE << order);
+ skb_fill_page_desc(skb, i, page, 0, chunk);
+ data_len -= chunk;
+ npages -= 1 << order;
+ }
+ return skb;
+
+failure:
+ kfree_skb(skb);
+ return NULL;
+}
+EXPORT_SYMBOL(alloc_skb_with_frags);
diff --git a/net/core/sock.c b/net/core/sock.c
index 6f436b5e4961..de887c45c63b 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1762,21 +1762,12 @@ struct sk_buff *sock_alloc_send_pskb(struct sock *sk, unsigned long header_len,
unsigned long data_len, int noblock,
int *errcode, int max_page_order)
{
- struct sk_buff *skb = NULL;
- unsigned long chunk;
- gfp_t gfp_mask;
+ struct sk_buff *skb;
long timeo;
int err;
- int npages = (data_len + (PAGE_SIZE - 1)) >> PAGE_SHIFT;
- struct page *page;
- int i;
-
- err = -EMSGSIZE;
- if (npages > MAX_SKB_FRAGS)
- goto failure;
timeo = sock_sndtimeo(sk, noblock);
- while (!skb) {
+ for (;;) {
err = sock_error(sk);
if (err != 0)
goto failure;
@@ -1785,66 +1776,27 @@ struct sk_buff *sock_alloc_send_pskb(struct sock *sk, unsigned long header_len,
if (sk->sk_shutdown & SEND_SHUTDOWN)
goto failure;
- if (atomic_read(&sk->sk_wmem_alloc) >= sk->sk_sndbuf) {
- set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags);
- set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
- err = -EAGAIN;
- if (!timeo)
- goto failure;
- if (signal_pending(current))
- goto interrupted;
- timeo = sock_wait_for_wmem(sk, timeo);
- continue;
- }
-
- err = -ENOBUFS;
- gfp_mask = sk->sk_allocation;
- if (gfp_mask & __GFP_WAIT)
- gfp_mask |= __GFP_REPEAT;
+ if (sk_wmem_alloc_get(sk) < sk->sk_sndbuf)
+ break;
- skb = alloc_skb(header_len, gfp_mask);
- if (!skb)
+ set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags);
+ set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
+ err = -EAGAIN;
+ if (!timeo)
goto failure;
-
- skb->truesize += data_len;
-
- for (i = 0; npages > 0; i++) {
- int order = max_page_order;
-
- while (order) {
- if (npages >= 1 << order) {
- page = alloc_pages(sk->sk_allocation |
- __GFP_COMP |
- __GFP_NOWARN |
- __GFP_NORETRY,
- order);
- if (page)
- goto fill_page;
- /* Do not retry other high order allocations */
- order = 1;
- max_page_order = 0;
- }
- order--;
- }
- page = alloc_page(sk->sk_allocation);
- if (!page)
- goto failure;
-fill_page:
- chunk = min_t(unsigned long, data_len,
- PAGE_SIZE << order);
- skb_fill_page_desc(skb, i, page, 0, chunk);
- data_len -= chunk;
- npages -= 1 << order;
- }
+ if (signal_pending(current))
+ goto interrupted;
+ timeo = sock_wait_for_wmem(sk, timeo);
}
-
- skb_set_owner_w(skb, sk);
+ skb = alloc_skb_with_frags(header_len, data_len, max_page_order,
+ errcode, sk->sk_allocation);
+ if (skb)
+ skb_set_owner_w(skb, sk);
return skb;
interrupted:
err = sock_intr_errno(timeo);
failure:
- kfree_skb(skb);
*errcode = err;
return NULL;
}
^ permalink raw reply related
* Re: [PATCH 1/2 nf-next] net: bridge: don't register netfilter call_iptables hooks by default
From: Pablo Neira Ayuso @ 2014-09-17 12:15 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel, netdev
In-Reply-To: <1410882457-16641-1-git-send-email-fw@strlen.de>
Hi Florian,
On Tue, Sep 16, 2014 at 05:47:36PM +0200, Florian Westphal wrote:
> Jesper reports that kernels with CONFIG_BRIDGE_NETFILTER=n show significantly
> better performance vs. CONFIG_BRIDGE_NETFILTER=y, even with
> bridge-nf-call-iptables=0.
>
> This is because bridge registers some bridge netfilter hooks at
> module load time, so the static key to bypass nf rule evaluation
> via NF_HOOK() is false.
>
> The hooks serve no purpose, unless iptables filtering for bridges is
> desired (i.e., bridge-nf-call-*=1 and active iptables rules present).
>
> The proper solution would be to just change the bridge-nf-call-iptables sysctl
> default value to 0 and then register the hooks when user enables call-iptables
> sysctl. We cannot do that though since it breaks existing setups.
>
> The next best solution is to delay registering of the hooks until
> we know that
>
> a) call-iptables sysctl is enabled (this is the default)
> AND
> b) ip(6)tables rules are loaded.
>
> This adds br_nf_check_call_iptables() helper in bridge input before
> bridge 'prerouting' (sic) hooks to perform this check.
>
> IOW, if user does not turn off call-iptables sysctl on the bridge, hook
> registering is only done if NFPROTO_IPV4/IPV6 hooks are registered as
> well once the first packet arrives on a bridge port.
>
> Doing this check for every packet is still faster than registering
> the hooks unconditionally. To not add overhead for setups where
> the call-iptables hooks are required, a static key shortcut is provided.
>
> As its not possible to register hooks from bh context (grabs mutex)
> its scheduled via workqueue.
My main concern with this approach is that we may let packets go
through unfiltered for some little time until the worker thread has
the chance to register the hooks.
Alternatives that I see for these are:
* pr_info to indicate the br_netfilter enable by default is
deprecated. Similar to your small patch 2/2, but it will take quite
some time until we can finally change this to zero.
* I think we can unregister the hooks when we notice that all
bridge-nf-call-*tables are zero from the sysctl. We register them if
any of them becomes 1 again.
Let me know, thanks.
^ permalink raw reply
* Re: [PATCH 1/2 nf-next] net: bridge: don't register netfilter call_iptables hooks by default
From: Florian Westphal @ 2014-09-17 12:42 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Florian Westphal, netfilter-devel, netdev
In-Reply-To: <20140917121530.GA3750@salvia>
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > As its not possible to register hooks from bh context (grabs mutex)
> > its scheduled via workqueue.
>
> My main concern with this approach is that we may let packets go
> through unfiltered for some little time until the worker thread has
> the chance to register the hooks.
They are supposed to be dropped until hook is there.
However, Nikolay Alexandrov just (correctly...) pointed out to me via irc that this mutex
abuse is against the rules (lock/unlock in different threads!).
So, please toss this series.
> Alternatives that I see for these are:
> * pr_info to indicate the br_netfilter enable by default is
> deprecated. Similar to your small patch 2/2, but it will take quite
> some time until we can finally change this to zero.
Right. I had planned to send a revert for patch 1 at some point,
plus a change to default to 0.
> * I think we can unregister the hooks when we notice that all
> bridge-nf-call-*tables are zero from the sysctl. We register them if
> any of them becomes 1 again.
Thats what I thought, but we now also have per-bridge sysfs knobs,
i.e. sysctl could be 0 and someone enabling br42->call_iptables ....
Its doable, but it gets ugly.
I don't think its worth the pain to care about "sometimes
enabled/disabled".
^ permalink raw reply
* Re: bisected regression: 3c59x corrupts packets in 3.17-rc5
From: mroos @ 2014-09-17 12:43 UTC (permalink / raw)
To: Neil Horman; +Cc: David Miller, steffen, netdev, Linux Kernel list
In-Reply-To: <20140917102701.GA5699@hmsreliant.think-freely.org>
> Shit, you're right, sorry about that. Its odd, I'm running it here, and its not
> causing problems, but thats obviously wrong. Meelis, please add the above fix
> to your test and confirm that it sovles the problem. If you could keep the
> previous patch in place too that would be great, as we should probably add the
> dma error checking anyway.
>
>
> [PATCH] 3c59x: Fix bad offset spec in skb_frag_dma_map
Tested 2 variants: only this patch (backported to old state) and both
patches together.
Both work fine.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Request For PartnerShip.
From: Hon. Amirel Yacouba @ 2014-09-17 12:45 UTC (permalink / raw)
--
Greetings,
I have emailed you earlier without a response.In my first email I
mentioned about my late client whose relatives I cannot get in touch
with.But both of you have the same last name so it will be very easy
to make you become her official next of kin.I am compelled to do this
because I would not want the bank to push my late client's funds
amount $5.5 million dollars into the bank treasury as unclaimed
inheritance.If you are interested you do let me know and get back to
me with this bellow information's.
Your Full Names:....................
Residential Address:................
Private Email Address...............
Telephone/fax Numbers:..............
Age:................................
Occupation:.........................
Marital status......................
Yours faithfully,
Barrister.Amirel Yacouba
Email:armelllyacouba@gmail.com
^ permalink raw reply
* Re: bisected regression: 3c59x corrupts packets in 3.17-rc5
From: Neil Horman @ 2014-09-17 12:56 UTC (permalink / raw)
To: mroos; +Cc: David Miller, steffen, netdev, Linux Kernel list
In-Reply-To: <alpine.LRH.2.11.1409171529350.26961@adalberg.ut.ee>
On Wed, Sep 17, 2014 at 03:43:54PM +0300, mroos@linux.ee wrote:
> > Shit, you're right, sorry about that. Its odd, I'm running it here, and its not
> > causing problems, but thats obviously wrong. Meelis, please add the above fix
> > to your test and confirm that it sovles the problem. If you could keep the
> > previous patch in place too that would be great, as we should probably add the
> > dma error checking anyway.
> >
> >
> > [PATCH] 3c59x: Fix bad offset spec in skb_frag_dma_map
>
> Tested 2 variants: only this patch (backported to old state) and both
> patches together.
>
> Both work fine.
>
Thank you, Meelis. Dave, I'll propose these patches officially in just a bit
sorry for the
> --
> Meelis Roos (mroos@linux.ee)
>
^ permalink raw reply
* [PATCH 1/2] 3c59x: Add dma error checking and recovery
From: Neil Horman @ 2014-09-17 13:04 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Linux Kernel list, David S. Miller, Meelis Roos
In-Reply-To: <alpine.LRH.2.11.1409160209280.21050@adalberg.ut.ee>
Noted that 3c59x has no checks on transmit for failed DMA mappings, and no
ability to unmap fragments when a single map fails in the middle of a transmit.
This patch provides error checking to ensure that dma mappings work properly,
and unrolls an skb mapping if a fragmented skb transmission has a mapping
failure to prevent leaks.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Linux Kernel list <linux-kernel@vger.kernel.org>
CC: "David S. Miller" <davem@davemloft.net>
CC: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
---
drivers/net/ethernet/3com/3c59x.c | 50 ++++++++++++++++++++++++++++++++-------
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/3com/3c59x.c b/drivers/net/ethernet/3com/3c59x.c
index 3fe45c7..5621dab 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -2129,6 +2129,7 @@ boomerang_start_xmit(struct sk_buff *skb, struct net_device *dev)
int entry = vp->cur_tx % TX_RING_SIZE;
struct boom_tx_desc *prev_entry = &vp->tx_ring[(vp->cur_tx-1) % TX_RING_SIZE];
unsigned long flags;
+ dma_addr_t dma_addr;
if (vortex_debug > 6) {
pr_debug("boomerang_start_xmit()\n");
@@ -2163,24 +2164,48 @@ boomerang_start_xmit(struct sk_buff *skb, struct net_device *dev)
vp->tx_ring[entry].status = cpu_to_le32(skb->len | TxIntrUploaded | AddTCPChksum | AddUDPChksum);
if (!skb_shinfo(skb)->nr_frags) {
- vp->tx_ring[entry].frag[0].addr = cpu_to_le32(pci_map_single(VORTEX_PCI(vp), skb->data,
- skb->len, PCI_DMA_TODEVICE));
+ dma_addr = pci_map_single(VORTEX_PCI(vp), skb->data, skb->len,
+ PCI_DMA_TODEVICE);
+ if (dma_mapping_error(&VORTEX_PCI(vp)->dev, dma_addr))
+ goto out_dma_err;
+
+ vp->tx_ring[entry].frag[0].addr = cpu_to_le32(dma_addr);
vp->tx_ring[entry].frag[0].length = cpu_to_le32(skb->len | LAST_FRAG);
} else {
int i;
- vp->tx_ring[entry].frag[0].addr = cpu_to_le32(pci_map_single(VORTEX_PCI(vp), skb->data,
- skb_headlen(skb), PCI_DMA_TODEVICE));
+ dma_addr = pci_map_single(VORTEX_PCI(vp), skb->data,
+ skb_headlen(skb), PCI_DMA_TODEVICE);
+ if (dma_mapping_error(&VORTEX_PCI(vp)->dev, dma_addr))
+ goto out_dma_err;
+
+ vp->tx_ring[entry].frag[0].addr = cpu_to_le32(dma_addr);
vp->tx_ring[entry].frag[0].length = cpu_to_le32(skb_headlen(skb));
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+ dma_addr = skb_frag_dma_map(&VORTEX_PCI(vp)->dev, frag,
+ frag->page_offset,
+ frag->size,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(&VORTEX_PCI(vp)->dev, dma_addr)) {
+ for(i = i-1; i >= 0; i--)
+ dma_unmap_page(&VORTEX_PCI(vp)->dev,
+ le32_to_cpu(vp->tx_ring[entry].frag[i+1].addr),
+ le32_to_cpu(vp->tx_ring[entry].frag[i+1].length),
+ DMA_TO_DEVICE);
+
+ pci_unmap_single(VORTEX_PCI(vp),
+ le32_to_cpu(vp->tx_ring[entry].frag[0].addr),
+ le32_to_cpu(vp->tx_ring[entry].frag[0].length),
+ PCI_DMA_TODEVICE);
+
+ goto out_dma_err;
+ }
+
vp->tx_ring[entry].frag[i+1].addr =
- cpu_to_le32(skb_frag_dma_map(
- &VORTEX_PCI(vp)->dev,
- frag,
- frag->page_offset, frag->size, DMA_TO_DEVICE));
+ cpu_to_le32(dma_addr);
if (i == skb_shinfo(skb)->nr_frags-1)
vp->tx_ring[entry].frag[i+1].length = cpu_to_le32(skb_frag_size(frag)|LAST_FRAG);
@@ -2189,7 +2214,10 @@ boomerang_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
}
#else
- vp->tx_ring[entry].addr = cpu_to_le32(pci_map_single(VORTEX_PCI(vp), skb->data, skb->len, PCI_DMA_TODEVICE));
+ dma_addr = cpu_to_le32(pci_map_single(VORTEX_PCI(vp), skb->data, skb->len, PCI_DMA_TODEVICE));
+ if (dma_mapping_error(&VORTEX_PCI(vp)->dev, dma_addr))
+ goto out_dma_err;
+ vp->tx_ring[entry].addr = cpu_to_le32(dma_addr);
vp->tx_ring[entry].length = cpu_to_le32(skb->len | LAST_FRAG);
vp->tx_ring[entry].status = cpu_to_le32(skb->len | TxIntrUploaded);
#endif
@@ -2217,7 +2245,11 @@ boomerang_start_xmit(struct sk_buff *skb, struct net_device *dev)
skb_tx_timestamp(skb);
iowrite16(DownUnstall, ioaddr + EL3_CMD);
spin_unlock_irqrestore(&vp->lock, flags);
+out:
return NETDEV_TX_OK;
+out_dma_err:
+ dev_err(&VORTEX_PCI(vp)->dev, "Error mapping dma buffer\n");
+ goto out;
}
/* The interrupt handler does all of the Rx thread work and cleans up
--
1.9.3
^ permalink raw reply related
* [PATCH 2/2] 3c59x: Fix bad offset spec in skb_frag_dma_map
From: Neil Horman @ 2014-09-17 13:04 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Linux Kernel list, David S. Miller, Meelis Roos
In-Reply-To: <1410959085-7351-1-git-send-email-nhorman@tuxdriver.com>
Recently aded the use of skb_frag_dma_map to 3c59x, but didn't realize it
automatically included the frag_offset internally, as well as provided an option
to specify an extra offset in the parameter list. We need to specify an offset
of 0 in the parameter list to avoid skb corruption that results in lost
connections.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Linux Kernel list <linux-kernel@vger.kernel.org>
CC: "David S. Miller" <davem@davemloft.net>
CC: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
---
drivers/net/ethernet/3com/3c59x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/3com/3c59x.c b/drivers/net/ethernet/3com/3c59x.c
index 5621dab..0f59d68 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -2186,7 +2186,7 @@ boomerang_start_xmit(struct sk_buff *skb, struct net_device *dev)
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
dma_addr = skb_frag_dma_map(&VORTEX_PCI(vp)->dev, frag,
- frag->page_offset,
+ 0,
frag->size,
DMA_TO_DEVICE);
if (dma_mapping_error(&VORTEX_PCI(vp)->dev, dma_addr)) {
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 0/3] bnx2x: Support new Multi-function modes
From: Yuval Mintz @ 2014-09-17 13:24 UTC (permalink / raw)
To: davem, netdev; +Cc: Ariel.Elior, Yuval Mintz
This patch series adds support for 2 new Multi-function modes -
Unified Fabric Port [UFP] as well as nic partitioning 1.5 [NPAR1.5].
With the addition of the new multi-function modes, the series also
revises some of the storage-related multi-function macros.
[Do notice this series has several small issues with checkpatch]
Dave,
Please consider applying this series to `net-next'.
Thanks,
Yuval
Dmitry Kravkov (1):
bnx2x: Changes with storage & MAC macros
Yuval Mintz (2):
bnx2x: New multi-function mode: UFP
bnx2x: Add a fallback multi-function mode NPAR1.5
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 53 +++++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 12 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 14 +-
.../net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h | 28 +--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 204 ++++++++++++++++-----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 41 ++++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.h | 23 +++
8 files changed, 296 insertions(+), 81 deletions(-)
--
1.8.3.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox