Since iscsi responses from the kernel are multicast we might get into
a situation where multiple discoveryd handle the same response.
With this commit we use a shared mutex to lock between the discoveryd forks
so each fork will handle its intended portal.
So we wait for login and stale logouts to finish between releasing the mutex.

Signed-off-by: Roi Dayan <>
Signed-off-by: Sagi Grimberg <>

The issue was discovered after working with discoveryd and offload driver
which needed the following patch that was already submitted to the mailing list:

Hi Mike, long time... :)

Are the problem events the discovery related ones like the ep_connect
ones, or is this a problem with the normal session login/logout events too?

This problem of multiple instances handling a NL multicast event, so
even for session_create etc... Each time we ask the kernel to do
something we're bound to race.

The tcp discoveryd doesn't use the kernel to establish the discovery
session so it's not a problem there.

Do we still hit the same problem if someone were to run iscsiadm while
this is running, or if we were to just run multiple instances of iscsiadm?

Exactly. running two instances of iscsiadm triggers the same race
conditions and we may end up asking the kernel to create the leading
conn on the a session id twice (and other weird things).

We'll need to fix that too, but we figured we'd start small and fix a
real bug report.

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
For more options, visit

Reply via email to