{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":61218692,"defaultBranch":"master","name":"mlxsw","ownerLogin":"Mellanox","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2016-06-15T15:24:29.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/5813145?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1470923823.0","currentOid":""},"activityList":{"items":[{"before":"72a520f8470db27f06065fa9577ea84de6d9bc5d","after":"279c71d2350b73c8b99905c21ceddbe8960ccc66","ref":"refs/heads/master","pushedAt":"2024-05-05T16:39:34.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"idosch","name":"Ido Schimmel","path":"/idosch","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/197793?s=80&v=4"},"commit":{"message":"libbpf-tools: emadlatency: Attach fentry to mlxsw_emad_rx_listener_func()\n\nFollowing to the previous patch, change the existing BPF_PROG to a fentry\nfor the function which handles EMADs responses.\n\nSigned-off-by: Amit Cohen \nSigned-off-by: Ido Schimmel ","shortMessageHtmlLink":"libbpf-tools: emadlatency: Attach fentry to mlxsw_emad_rx_listener_fu…"}},{"before":"9d62ed3016351972227cd672a3aa1e0017f54e2d","after":"72a520f8470db27f06065fa9577ea84de6d9bc5d","ref":"refs/heads/master","pushedAt":"2024-04-30T06:16:46.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"idosch","name":"Ido Schimmel","path":"/idosch","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/197793?s=80&v=4"},"commit":{"message":"drgn: Use devlinks XArray to reach mlxsw data\n\nSince kernel commit 698a1eb1f75e (\"thermal: core: Store zone ops in\nstruct thermal_zone_device\") the tool in unable to reach the mlxsw data\n[1].\n\nFix by converting to use the global devlinks XArray instead. This should\nwork with both current and older kernels.\n\n[1]\n # ./res_dump\n [...]\n TypeError: invalid operands to comparison ('struct thermal_zone_device_ops' and 'struct thermal_zone_device_ops *')\n\nSigned-off-by: Ido Schimmel \nReviewed-by: Petr Machata ","shortMessageHtmlLink":"drgn: Use devlinks XArray to reach mlxsw data"}},{"before":"5dc6e0ccc5aa7082a60cd18b4e13e499d07c868c","after":"9d62ed3016351972227cd672a3aa1e0017f54e2d","ref":"refs/heads/master","pushedAt":"2023-10-03T08:43:23.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"idosch","name":"Ido Schimmel","path":"/idosch","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/197793?s=80&v=4"},"commit":{"message":"libbpf-tools: trapagg: Remove assumption about L2 header placement\n\nDo not assume that the L2 header starts at 'skb->data' and instead\nderive its placement using the 'mac_header' field that encodes the\noffset relative to 'skb->head'.\n\nSigned-off-by: Ido Schimmel ","shortMessageHtmlLink":"libbpf-tools: trapagg: Remove assumption about L2 header placement"}},{"before":"e996fd583eff1c43aacb9c79e55f5add12402d7d","after":"5dc6e0ccc5aa7082a60cd18b4e13e499d07c868c","ref":"refs/heads/master","pushedAt":"2023-07-13T10:48:45.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"idosch","name":"Ido Schimmel","path":"/idosch","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/197793?s=80&v=4"},"commit":{"message":"Debugging: drgn-tools: Add port_range_dump tool\n\nAdd a tool to dump port range registers in JSON format.\n\nSigned-off-by: Ido Schimmel \nReviewed-by: Petr Machata ","shortMessageHtmlLink":"Debugging: drgn-tools: Add port_range_dump tool"}},{"before":"2efcd392efdc0826cc50ed80782383010cd31321","after":"e996fd583eff1c43aacb9c79e55f5add12402d7d","ref":"refs/heads/master","pushedAt":"2023-05-11T13:26:34.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"idosch","name":"Ido Schimmel","path":"/idosch","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/197793?s=80&v=4"},"commit":{"message":"resmon: bpf: Fix missing EMAD responses\n\nWe often see resmon complaining that some entries (e.g., routes) were\nnot deleted after certain tests. Petr debugged it down to the fact that\nthe resmon BPF program is not invoked for every EMAD response.\n\nThe resmon BPF program is attached to the 'devlink:devlink_hwmsg'\ntracepoint which is triggered by mlxsw upon EMAD transmission and\nreception. The former happens in process context while the latter\nhappens in softIRQ context.\n\nIt is therefore possible that a softIRQ is raised while the BPF program\nis processing an EMAD request. If the softIRQ is raised because of an\nincoming EMAD response, then the kernel will try to invoke the BPF\nprogram on the same CPU. According to [1], this will result in the BPF\nprogram not being invoked for the EMAD response:\n\n\"kprobe programs have per-CPU reentrancy protection. That is, if some\nBPF kprobe/tracepoint program is running and something happens [...]\nthat would trigger another BPF program, then that nested BPF program\ninvocation will be skipped.\"\n\nFix this by attaching the BPF program to the mlxsw function that\nprocesses EMAD responses. This function is always executed in softIRQ\ncontext so it is not possible to run into the above problem.\n\nWith this fix the problem did not reproduce in 600 iterations on SN2201,\nwhereas without the fix the problem was reproduced quite consistently.\n\n[1] https://lore.kernel.org/all/CAEf4BzZg0r4YptYPu8Y_-qp=rY__W6dmb9kLwMV5MAH6C-2PSg@mail.gmail.com/\n\nFixes: e7ca40f02eb4 (\"resmon: Introduce the BPF interface\")\nSigned-off-by: Ido Schimmel \nReviewed-by: Petr Machata ","shortMessageHtmlLink":"resmon: bpf: Fix missing EMAD responses"}},{"before":"a73ad75ee48376a4b33d1cfabe79d146ae70231e","after":"2efcd392efdc0826cc50ed80782383010cd31321","ref":"refs/heads/master","pushedAt":"2023-05-07T16:56:49.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"idosch","name":"Ido Schimmel","path":"/idosch","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/197793?s=80&v=4"},"commit":{"message":"libbpf-tools: Pull upstream libbpf changes\n\nSigned-off-by: Ido Schimmel ","shortMessageHtmlLink":"libbpf-tools: Pull upstream libbpf changes"}},{"before":"62b9d3dc1a82e1db02b275361009a658b3bec069","after":"a73ad75ee48376a4b33d1cfabe79d146ae70231e","ref":"refs/heads/master","pushedAt":"2023-05-03T10:55:47.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"idosch","name":"Ido Schimmel","path":"/idosch","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/197793?s=80&v=4"},"commit":{"message":"resmon: stat: Zero the allocated resmon_stat in resmon_stat_create()\n\nThe field struct resmon_stat::gauges seems to happen to consistently start\nwith zeroes, but valgrind complains about uninitialized memory when\nformatting the stats RPC, and I suspect that MALLOC_PERTURB_ would cause it\nto break as well.\n\nMost of the time we initialize structures using the *x = (struct x){...}\nidiom, so allocating an all-zero memory is not necessary. Here, however, we\ndo a field-by-field allocation, which is why neglecting to include a field\ncaused this issue. So to fix this problem and future-proof this part of\ncode, request a zeroed-out memory by allocating through calloc().\n\nSigned-off-by: Petr Machata \nSigned-off-by: Ido Schimmel ","shortMessageHtmlLink":"resmon: stat: Zero the allocated resmon_stat in resmon_stat_create()"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEQeygmgA","startCursor":null,"endCursor":null}},"title":"Activity · Mellanox/mlxsw"}