[SSSD] [PATCH] Last USN patches

Stephen Gallagher sgallagh at redhat.com
Wed May 4 13:10:10 UTC 2011


On Fri, 2011-04-29 at 15:53 +0200, Jan Zelený wrote:
> > On Wed, 2011-04-27 at 17:45 +0200, Jakub Hrozek wrote:
> > > On 04/27/2011 03:30 PM, Stephen Gallagher wrote:
> > > > On Tue, 2011-04-19 at 14:57 -0400, Stephen Gallagher wrote:
> > > >> On Tue, 2011-04-12 at 12:33 +0200, Jan Zelený wrote:
> > > >>> Can someone please take a look at the patch and ack that all issues
> > > >>> discovered by Simo have been corrected?
> > > >>> 
> > > >>> Also note that in the original email there is another patch, which
> > > >>> hasn't been reviewed yet.
> > > >> 
> > > >> Ack to both patches and pushed to master.
> > > > 
> > > > Unfortunately, I've now discovered several issues with this patch (too
> > > > late).
> > > > 
> > > > First, it causes a crash if SSSD started up in offline mode (e.g.
> > > > disconnected laptop) and then goes online (e.g. VPN).
> > > > 
> > > > #0  0x00007fec7adddd28 in sdap_check_online_done (req=0x0)
> > > > at ../src/providers/ldap/ldap_id.c:729
> > > > #1  0x00007fec7ae0f3e1 in sdap_cli_auth_done (subreq=0x0)
> > > > at ../src/providers/ldap/sdap_async_connection.c:1430
> > > > #2  0x00007fec7ae0e207 in sdap_auth_done (subreq=0x1ea9570)
> > > > at ../src/providers/ldap/sdap_async_connection.c:1007
> > > > #3  0x00007fec7ae0c8a9 in simple_bind_done (op=0x1ea9880,
> > > > reply=0x1ea97f0, error=0, pvt=0x1ea9570)
> > > > at ../src/providers/ldap/sdap_async_connection.c:540
> > > > #4  0x00007fec7adf4aa9 in sdap_process_message (ev=0x1e74470,
> > > > sh=0x1eb2c70, msg=0x1eb33e0) at ../src/providers/ldap/sdap_async.c:364
> > > > #5  0x00007fec7adf4363 in sdap_process_result (ev=0x1e74470,
> > > > pvt=0x1eb2c70) at ../src/providers/ldap/sdap_async.c:207
> > > > #6  0x00007fec7adf3db6 in sdap_ldap_result (ev=0x1e74470,
> > > > fde=0x1eb3140, flags=1, pvt=0x1eb2c70) at
> > > > ../src/providers/ldap/sdap_async.c:152 #7  0x000000389ee05d57 in ?? ()
> > > > from /usr/lib64/libtevent.so.0 #8  0x000000389ee035b0 in
> > > > _tevent_loop_once ()
> > > > from /usr/lib64/libtevent.so.0
> > > > #9  0x000000389ee0373b in tevent_common_loop_wait ()
> > > > from /usr/lib64/libtevent.so.0
> > > > #10 0x000000000043d41f in server_loop (main_ctx=0x1e755e0)
> > > > at ../src/util/server.c:526
> > > > #11 0x000000000040f8d2 in main (argc=6, argv=0x7fffbb9c67a8)
> > > > at ../src/providers/data_provider_be.c:1284
> > > > 
> > > > 
> > > > The problem is that ctx->srv_opts is NULL here (since we've never made
> > > > a connection to the server before this).
> > > > 
> > > > While I was investigating this, I noticed something else as well. This
> > > > entire IF block is completely useless as written. In the IF block, you
> > > > set ctx->srv_opts attributes, but then immediately after this block,
> > > > you replace the contents of ctx->srv_opts with the returned srv_opts
> > > > from sdap_cli_connect_recv()
> > > > 
> > > > My guess here is that the assignments in the IF block were supposed to
> > > > be setting srv_opts instead of ctx->srv_opts. The only part that
> > > > confuses me is where you're setting ctx->srv_opts->last_usn to
> > > > srv_opts->last_usn. I thought we had covered before that if the value
> > > > of srv_opts->last_usn was ever lower than the stored value, we MUST set
> > > > it to zero. This is because we know that the USN values are not in line
> > > > with the ones we have stored, so we have to do a full update to be
> > > > safe.
> > > > 
> > > > I'm attaching a patch that I think will resolve the issue (though I
> > > > can't test it as I don't have access to a server with USN values). At
> > > > the very least, it resolves the crash above for me.
> > > 
> > > Ack
> > 
> > I'm going to hold off pushing this until I get buy-in from Jan.
> 
> I'm sending my version of the correction. I already tested it and it seems to 
> work for me. Stephen, can you run your test, which caused the crash?
> 
> This patch already contains handling of the situation that came to my mind 
> today. See commit message for some details.
> 
> Jan


Ack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110504/364f0f4f/attachment.sig>


More information about the sssd-devel mailing list