netdev - Re: [PATCH net-next v2] rocker: move netevent neigh update to processes context

lists.openwall.net		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 linux-cve-announce 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]

Message-Id: <20150604.114816.405065923499742451.davem@davemloft.net>
Date:	Thu, 04 Jun 2015 11:48:16 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	toshiaki.makita1@...il.com
Cc:	horms@...ge.net.au, simon.horman@...ronome.com, sfeldma@...il.com,
	netdev@...r.kernel.org, jiri@...nulli.us,
	makita.toshiaki@....ntt.co.jp
Subject: Re: [PATCH net-next v2] rocker: move netevent neigh update to
 processes context

From: Toshiaki Makita <toshiaki.makita1@...il.com>
Date: Fri, 05 Jun 2015 00:34:50 +0900

> I'm thinking IRQ context does not match the prepare-commit model, and
> Scott's fix is needed. There are more critical problems Scott's patch
> fixes.
> (I shortly explained it before, although it is not clearly stated in
> the commitlog. http://marc.info/?l=linux-netdev&m=143219842420093&w=2)
> 
> 1. Operations from IRQ context could change the state of rocker, like
> hash tables. This could cause inconsistent states between
> prepare-commit (for example, prepare phase cannot find an entry but
> commit phase can find it), and leads to memory corruption (unreserved
> memory could be used or reserved memory could not be used in commit
> phase).

If you hold the spinlock across the prepare and commit operation there
is no problem.

It is exactly what I am suggesting and fixes all the bugs.

You add ->transaction_begin() and ->transaction_end() and these take
the driver's spinlock or whatever synchronization object to protect
the transaction.

Then there is no conflict between software interrupt based operations
and RTNL mutex held ones.

I'm not going to explain my preference for how to fix this any further
and will ignore any further submissions of a patch that tries to do
this by pushing things to a workqueue, sorry.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html