On Fri, Jan 29, 2021 at 10:00 AM Jakub Kicinski wrote:
>
> On Thu, 28 Jan 2021 21:47:04 -0800 Cong Wang wrote:
> > On Thu, Jan 28, 2021 at 9:21 PM Jakub Kicinski wrote:
> > > On Thu, 28 Jan 2021 21:08:05 -0800 Cong Wang wrote:
> > > > On Thu, Jan 28, 2021 at 12:55 PM Jakub Kicinski wrote:
> > >
On Thu, 28 Jan 2021 21:47:04 -0800 Cong Wang wrote:
> On Thu, Jan 28, 2021 at 9:21 PM Jakub Kicinski wrote:
> > On Thu, 28 Jan 2021 21:08:05 -0800 Cong Wang wrote:
> > > On Thu, Jan 28, 2021 at 12:55 PM Jakub Kicinski wrote:
> > > >
> > > > On Sat, 23 Jan 2021 17:30:49 -0800 Cong Wang wrote:
On Thu, Jan 28, 2021 at 9:21 PM Jakub Kicinski wrote:
>
> On Thu, 28 Jan 2021 21:08:05 -0800 Cong Wang wrote:
> > On Thu, Jan 28, 2021 at 12:55 PM Jakub Kicinski wrote:
> > >
> > > On Sat, 23 Jan 2021 17:30:49 -0800 Cong Wang wrote:
> > > > From: Cong Wang
> > > >
> > > > dev_ifsioc_locked() is
On Thu, 28 Jan 2021 21:08:05 -0800 Cong Wang wrote:
> On Thu, Jan 28, 2021 at 12:55 PM Jakub Kicinski wrote:
> >
> > On Sat, 23 Jan 2021 17:30:49 -0800 Cong Wang wrote:
> > > From: Cong Wang
> > >
> > > dev_ifsioc_locked() is called with only RCU read lock, so when
> > > there is a parallel wri
On Thu, Jan 28, 2021 at 12:55 PM Jakub Kicinski wrote:
>
> On Sat, 23 Jan 2021 17:30:49 -0800 Cong Wang wrote:
> > From: Cong Wang
> >
> > dev_ifsioc_locked() is called with only RCU read lock, so when
> > there is a parallel writer changing the mac address, it could
> > get a partially updated m
On Sat, 23 Jan 2021 17:30:49 -0800 Cong Wang wrote:
> From: Cong Wang
>
> dev_ifsioc_locked() is called with only RCU read lock, so when
> there is a parallel writer changing the mac address, it could
> get a partially updated mac address, as shown below:
>
> Thread 1 Thread
On Mon, Jan 25, 2021 at 11:43 AM Gong, Sishuai wrote:
>
> Hi,
>
> We also found another pair of writer and reader that may suffer the same
> problem.
>
> A data race may also happen on the variable netdev->dev_addr when functions
> e1000_set_mac() and packet_getname() run in parallel, eventually
Hi,
We also found another pair of writer and reader that may suffer the same
problem.
A data race may also happen on the variable netdev->dev_addr when functions
e1000_set_mac() and packet_getname() run in parallel, eventually it could
return a partially updated MAC address to the user, as sho
From: Cong Wang
dev_ifsioc_locked() is called with only RCU read lock, so when
there is a parallel writer changing the mac address, it could
get a partially updated mac address, as shown below:
Thread 1Thread 2
// eth_commit_mac_addr_change()
memcpy(dev->dev_addr, addr->s
