Fix an uninitialized variable reference in xpt_async.

[asomers]

Summary

Initialize async_arg_ptr in xpt_async when called with async_code
AC_ADVINFO_CHANGED.

Test Plan

The only way I know of to call xpt_async with AC_ADVINFO_CHANGED is when the
ses(4) driver sets the physical path of a device. And since that only happens
when a device is inserted (or a SES device changes its configuration, which
never happens on my hardware), symptoms will only be visible if the enc_daemon
thread is running slow. Otherwise it will set the physical path before the
device finishes creating all of its devnodes on startup. And the only way I
know to slow down enc_daemon is to attach a large number of devices at the same
time.

For example, without this patch, attaching 95 disks at once resulted in all of
them getting physical path device nodes for their da devices, but only two
got physical path device nodes for their pass devices.

[mav]

Hmm. Not sure how could I miss that, looks like a wrong copy/paste. Instead of async_arg_size assignment there should probably be async_arg_ptr assignment. I am not sure that assigning both as in your patch is very useful.

[imp]

This looks good to my eye. Not sure how it could have worked before.

[asomers]

In D2290#4, @mav wrote:

Hmm. Not sure how could I miss that, looks like a wrong copy/paste. Instead of async_arg_size assignment there should probably be async_arg_ptr assignment. I am not sure that assigning both as in your patch is very useful.

async_arg_size gets referenced by xpt_async_process, so it's still worthwhile to assign it.

[asomers]

In D2290#7, @imp wrote:

This looks good to my eye. Not sure how it could have worked before.

Before it only worked due to timing. Normally, ses(4) finishes setting the physical path before the device finishes arriving. For example, passregister enqueues a pass_add_physpath taskqueue. When ses(4) sets the physical path, it attempts to enqueue another pass_add_physpath via xpt_async. But if ses(4) is fast enough, then the first pass_add_physpath won't have fired yet, and it won't matter that xpt_async is broken.

[asomers]

Closed by commit rS281531 (authored by @asomers).

[mav]

In D2290#10, @asomers wrote:

In D2290#4, @mav wrote:

Hmm. Not sure how could I miss that, looks like a wrong copy/paste. Instead of async_arg_size assignment there should probably be async_arg_ptr assignment. I am not sure that assigning both as in your patch is very useful.

async_arg_size gets referenced by xpt_async_process, so it's still worthwhile to assign it.

It is assigned to zero few lines before that point. Assigning it to -1 after that is irrelevant.

[asomers]

In D2290#15, @mav wrote:

In D2290#10, @asomers wrote:

In D2290#4, @mav wrote:

Hmm. Not sure how could I miss that, looks like a wrong copy/paste. Instead of async_arg_size assignment there should probably be async_arg_ptr assignment. I am not sure that assigning both as in your patch is very useful.

async_arg_size gets referenced by xpt_async_process, so it's still worthwhile to assign it.

It is assigned to zero few lines before that point. Assigning it to -1 after that is irrelevant.

The outcome is irrelevant today, but will it always be irrelevant? I prefer to program defensively. async_arg_size has a meaning, and later code checks it, so I prefer that its value be accurate.