Re: [PATCH] net/mlx5: Fix a potential use after free in mlx5e_ktls_del_rx

2021-03-23 Thread Maxim Mikityanskiy
On 2021-03-22 16:21, Lv Yunlong wrote: My static analyzer tool reported a potential uaf in mlx5e_ktls_del_rx. In this function, if the condition cancel_work_sync(>work) is true, and then priv_rx could be freed. But priv_rx is used later. I'm unfamiliar with how this function works. Maybe the

Re: [syzbot] BUG: unable to handle kernel NULL pointer dereference in htb_select_queue

2021-03-10 Thread Maxim Mikityanskiy
On 2021-03-10 19:03, Eric Dumazet wrote: On 3/10/21 3:54 PM, Maxim Mikityanskiy wrote: On 2021-03-09 17:20, Eric Dumazet wrote: On 3/9/21 4:13 PM, syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:    38b5133a octeontx2-pf: Fix otx2_get_fecparam() git tree:   net

Re: [syzbot] BUG: unable to handle kernel NULL pointer dereference in htb_select_queue

2021-03-10 Thread Maxim Mikityanskiy
: Maxim Mikityanskiy Date: Tue Jan 19 12:08:13 2021 + sch_htb: Hierarchical QoS hardware offload bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13ab12ecd0 final oops: https://syzkaller.appspot.com/x/report.txt?x=106b12ecd0 console output: https

[PATCH] HID: plantronics: Workaround for double volume key presses

2021-02-07 Thread Maxim Mikityanskiy
onics: Update to map volume up/down controls") Signed-off-by: Maxim Mikityanskiy --- People from Plantronics, maybe you could advise on a better fix than filtering duplicate events on driver level? Do you happen to know why they occur in the first place? Are any other headsets affected? drive

[PATCH] media: usbtv: Fix deadlock on suspend

2021-02-05 Thread Maxim Mikityanskiy
with snd_card_free_when_closed, that doesn't wait until all references are released, allowing suspend to progress. Fixes: 63ddf68de52e ("[media] usbtv: add audio support") Signed-off-by: Maxim Mikityanskiy --- drivers/media/usb/usbtv/usbtv-audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] Revert "block: simplify set_init_blocksize" to regain lost performance

2021-01-26 Thread Maxim Mikityanskiy
On Wed, Jan 27, 2021 at 6:23 AM Bart Van Assche wrote: > > On 1/26/21 11:59 AM, Maxim Mikityanskiy wrote: > > The cited commit introduced a serious regression with SATA write speed, > > as found by bisecting. This patch reverts this commit, which restores > > write

[PATCH] Revert "block: simplify set_init_blocksize" to regain lost performance

2021-01-26 Thread Maxim Mikityanskiy
tored back to the state before the faulty commit, and even a bit higher in RAID tests (which aren't HDD-bound on this device) - that is likely related to other optimizations done between the faulty commit and 5.10.10 which also improved the read speed. Signed-off-by: Maxim Mikityanskiy Fixes: 5f

Re: [PATCH] [net-next] net/mlx5e: xsk: dynamically allocate mlx5e_channel_param

2019-07-23 Thread Maxim Mikityanskiy
On 2019-07-08 18:16, Maxim Mikityanskiy wrote: > On 2019-07-08 15:55, Arnd Bergmann wrote: >> -mlx5e_build_xsk_cparam(priv, params, xsk, ); >> +cparam = kzalloc(sizeof(*cparam), GFP_KERNEL); > > Similar code in mlx5e_open_channels (en_main.c) uses kvzalloc.

Re: [PATCH] [net-next] net/mlx5e: xsk: dynamically allocate mlx5e_channel_param

2019-07-08 Thread Maxim Mikityanskiy
On 2019-07-08 15:55, Arnd Bergmann wrote: > The structure is too large to put on the stack, resulting in a > warning on 32-bit ARM: > > drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:59:5: error: stack > frame size of 1344 bytes in function >'mlx5e_open_xsk'

Re: [PATCH 1/1] Address regression in inet6_validate_link_af

2019-06-13 Thread Maxim Mikityanskiy
On 2019-06-13 09:45, Jonas Bonn wrote: > Hi Max, > > On 12/06/2019 12:42, Maxim Mikityanskiy wrote: >> On 2019-06-11 13:03, Jonas Bonn wrote: >>> Patch 7dc2bccab0ee37ac28096b8fcdc390a679a15841 introduces a regression >>> with systemd 241.  In that revisio

Re: [PATCH 1/1] Address regression in inet6_validate_link_af

2019-06-12 Thread Maxim Mikityanskiy
. Thanks, Max [1]: https://github.com/systemd/systemd/commit/0e2fdb83bb5e22047e0c7cc058b415d0e93f02cf > With this, systemd-networkd version 241 once > again is able to bring up the link, albeit not quite as intended and > thereby with a warning in the kernel log. > > CC: Maxim Mikitya

Re: [PATCH] platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay Trail

2019-03-04 Thread Maxim Mikityanskiy
plement irq_set_wake on BYT devices, > > > > Pushed to my review and testing queue, thanks! Kernel 5.0 was released without this patch, is it still planned to merge it? > > Fixes: c3b8e884defa ("platform/x86: intel_int0002_vgpio: ... irq_set_wake") > > R

Re: [PATCH] platform/x86: intel_int0002_vgpio: Implement irq_set_wake

2019-02-02 Thread Maxim Mikityanskiy
On Sat, Feb 2, 2019 at 12:52 AM Hans de Goede wrote: > > Hi, > > On 1/31/19 8:47 PM, Maxim Mikityanskiy wrote: > > Hi, > > > > On Mon, Sep 24, 2018 at 5:37 PM Hans de Goede wrote: > >> > >> We were relying on the interrupt being shared

Re: [PATCH] platform/x86: intel_int0002_vgpio: Implement irq_set_wake

2019-01-31 Thread Maxim Mikityanskiy
Hi, On Mon, Sep 24, 2018 at 5:37 PM Hans de Goede wrote: > > We were relying on the interrupt being shared with the ACPI SCI and the > ACPI core calling irq_set_wake. But that does not always happen on > Bay Trail devices, so we should do it ourselves. > > This fixes wake from USB not working on