lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 30 Aug 2020 10:49:58 +0300
From:   Vadym Kochan <>
To:     David Miller <>
Subject: Re: [net-next v5 1/6] net: marvell: prestera: Add driver for
 Prestera family ASIC devices

Hi David,

On Wed, Aug 26, 2020 at 07:34:46AM -0700, David Miller wrote:
> From: Vadym Kochan <>
> Date: Wed, 26 Aug 2020 11:17:44 +0300
> > Initially there was (in RFC patch set), not locking, but _rcu list API
> > used, because the port list is modified only by 1 writer when creating
> > the port or deleting it on switch uninit (the really theoretical case
> > which might happen is that event might be received at that time which
> > causes to loop over this list to find the port), as I understand
> > correctly list_add_rcu is safe to use with no additional locking if there is 1
> > writer and many readers ? So can I use back this approach ?
> Are you really certain only one writer can exist at one time?

Yes, list_add() is called on:

    prestera_pci_probe() -> prestera_device_register() -> prestera_switch_init() -> prestera_create_ports()

and list_del() is called on:

    prestera_pci_remove() -> prestera_device_unregister() -> prestera_switch_fini() -> prestera_destroy_ports()

in all other cases the port_list is used for port lookup on rx or when
event is received from the fw. So I really think that at least RCU list
API might be used or rw lock. In early version the ports were creating
before fw event handlers registration, but in this version the ports are
creating after event handlers are registered so it really needs locking.

Regarding DMA comments, looks like I can get rid of those bounce buffer
handling because swiotlb can handle this ? In that case looks like just
DMA map/unmap and sync should be enough.

Vadym Kochan

Powered by blists - more mailing lists