Christian Kratzer wrote: > Hi Rick, > > On Sun, 18 Oct 2015, Rick Macklem wrote: > > > Christian Kratzer wrote: > >> Hi Rick, > >> > >> looks like your latest patch nailed the issue. The box has been up for 3 > >> days: > >> > >> ck@noc3:~ % uptime > >> 12:22PM up 3 days, 4:11, 1 user, load averages: 0.07, 0.10, 0.08 > >> ck@noc3:~ % > >> > >> If it does not crash over the weekend this seems to be it: > >> > > When I took a closer look, it appears that PR 172942 was a different crash > > and > > it appears that one was fixed via r264600. > > > > Your problem does not appear to be in the bugs database. (I will commit the > > patch in mid-November anyhow, but creating a PR for this might be useful > > for > > others.) > > > > Btw, I think the attached patch (which includes this change) also fixes a > > problem that caused a crash during mounting, reported via PR 201912. > > (If you`d like to test this one that would be appreciated. It should be > > applied to code not already patched with the one below, since the below > > patch is included in it.) > > > > Thanks for your help with this, rick > <snipp/> > > I'll put your patch on the VM in question. Btw. it has been up for 6 days now > without a crash. > > Before I do that I would like to see that it really addresses PR 201912. > > Do you have any idea how I could provoke that one ? > Not really, I'm afraid. The patch deals with the failure cases in smb_vc_create(), which I think was what caused the crash, given the backtrace in the PR.
You can look at smb_vc_create() and see there is a bunch of "goto fail;" cases, but I don't know how to specifically tickle any of these? You could "fake it" by putting a "goto fail;" at line#428, just after the "error = ENOMEM;". This will break smb_vc_create() big time, but I think it will generate the same crash as PR 201912. > Ideally I would like to do the stuff that forces the panic, then apply > the patch and see that the system stays stable despite me doing the > silly moves again. > That would be nice, but so long as I know that the patch doesn't cause a regression, I am comfortable committing it. (This refers to the other 2 changes in the patch. It seems clear that the fix in smbiod2.patch is ok to commit.) Thanks for all your help with this, rick > Greetings > Christian > > -- > Christian Kratzer CK Software GmbH > Email: c...@cksoft.de Wildberger Weg 24/2 > Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer > Web: http://www.cksoft.de/ > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
