* [PATCH 0/2] xenbus: xenbus_dev_request_and_reply() adjustments
@ 2016-07-07 7:25 Jan Beulich
2016-07-07 7:32 ` [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() Jan Beulich
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Jan Beulich @ 2016-07-07 7:25 UTC (permalink / raw)
To: david.vrabel, boris.ostrovsky, Juergen Gross; +Cc: xen-devel, linux-kernel
1: don't bail early from xenbus_dev_request_and_reply()
2: simplify xenbus_dev_request_and_reply()
Signed-off-by: Jan Beulich <jbeulich@suse.com>
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() 2016-07-07 7:25 [PATCH 0/2] xenbus: xenbus_dev_request_and_reply() adjustments Jan Beulich @ 2016-07-07 7:32 ` Jan Beulich 2016-07-07 11:36 ` [Xen-devel] " David Vrabel 2016-07-07 7:32 ` [PATCH 2/2] xenbus: simplify xenbus_dev_request_and_reply() Jan Beulich 2016-07-08 10:56 ` [Xen-devel] [PATCH 0/2] xenbus: xenbus_dev_request_and_reply() adjustments David Vrabel 2 siblings, 1 reply; 12+ messages in thread From: Jan Beulich @ 2016-07-07 7:32 UTC (permalink / raw) To: david.vrabel, boris.ostrovsky, Juergen Gross Cc: xen-devel, Konrad Rzeszutek Wilk, linux-kernel We must not skip the transaction_end() call for a failed XS_TRANSACTION_START. The removed code fragment got introduced by commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart") without its description really indicating why it was added (and hence I can't identify whether a more complex change might be needed here). Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/xen/xenbus/xenbus_xs.c | 3 --- 1 file changed, 3 deletions(-) --- 4.7-rc6-xen.orig/drivers/xen/xenbus/xenbus_xs.c +++ 4.7-rc6-xen/drivers/xen/xenbus/xenbus_xs.c @@ -249,9 +249,6 @@ void *xenbus_dev_request_and_reply(struc mutex_unlock(&xs_state.request_mutex); - if (IS_ERR(ret)) - return ret; - if ((msg->type == XS_TRANSACTION_END) || ((req_msg.type == XS_TRANSACTION_START) && (msg->type == XS_ERROR))) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() 2016-07-07 7:32 ` [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() Jan Beulich @ 2016-07-07 11:36 ` David Vrabel 2016-07-07 12:09 ` Jan Beulich 0 siblings, 1 reply; 12+ messages in thread From: David Vrabel @ 2016-07-07 11:36 UTC (permalink / raw) To: Jan Beulich, david.vrabel, boris.ostrovsky, Juergen Gross Cc: xen-devel, linux-kernel On 07/07/16 08:32, Jan Beulich wrote: > We must not skip the transaction_end() call for a failed > XS_TRANSACTION_START. The removed code fragment got introduced by > commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus > stalling shutdown/restart") without its description really indicating > why it was added (and hence I can't identify whether a more complex > change might be needed here). If sending the XS_TRANSACTION_END message failed, then the transaction is still open and transaction_end() should not be called. However, if sending an XS_TRANSACTION_START failed, then transaction_end() should be called. So, yes a more complex fix is needed here. David ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() 2016-07-07 11:36 ` [Xen-devel] " David Vrabel @ 2016-07-07 12:09 ` Jan Beulich 2016-07-07 12:17 ` David Vrabel 0 siblings, 1 reply; 12+ messages in thread From: Jan Beulich @ 2016-07-07 12:09 UTC (permalink / raw) To: david.vrabel; +Cc: xen-devel, boris.ostrovsky, Juergen Gross, linux-kernel >>> On 07.07.16 at 13:36, <david.vrabel@citrix.com> wrote: > On 07/07/16 08:32, Jan Beulich wrote: >> We must not skip the transaction_end() call for a failed >> XS_TRANSACTION_START. The removed code fragment got introduced by >> commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus >> stalling shutdown/restart") without its description really indicating >> why it was added (and hence I can't identify whether a more complex >> change might be needed here). > > If sending the XS_TRANSACTION_END message failed, then the transaction > is still open and transaction_end() should not be called. > > However, if sending an XS_TRANSACTION_START failed, then > transaction_end() should be called. > > So, yes a more complex fix is needed here. Well, both of the things you name are what happens with the patch in place. So if those two conditions are all that needs to be satisfied, then no more complex change is needed afaict (and was the behavior before the cross referenced commit) - the question really is whether that other commit meant to deal with something _beyond_ those two things. Jan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() 2016-07-07 12:09 ` Jan Beulich @ 2016-07-07 12:17 ` David Vrabel 2016-07-07 12:23 ` Jan Beulich 0 siblings, 1 reply; 12+ messages in thread From: David Vrabel @ 2016-07-07 12:17 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel, boris.ostrovsky, Juergen Gross, linux-kernel On 07/07/16 13:09, Jan Beulich wrote: >>>> On 07.07.16 at 13:36, <david.vrabel@citrix.com> wrote: >> On 07/07/16 08:32, Jan Beulich wrote: >>> We must not skip the transaction_end() call for a failed >>> XS_TRANSACTION_START. The removed code fragment got introduced by >>> commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus >>> stalling shutdown/restart") without its description really indicating >>> why it was added (and hence I can't identify whether a more complex >>> change might be needed here). >> >> If sending the XS_TRANSACTION_END message failed, then the transaction >> is still open and transaction_end() should not be called. >> >> However, if sending an XS_TRANSACTION_START failed, then >> transaction_end() should be called. >> >> So, yes a more complex fix is needed here. > > Well, both of the things you name are what happens with the patch > in place. So if those two conditions are all that needs to be satisfied, > then no more complex change is needed afaict (and was the behavior > before the cross referenced commit) - the question really is whether > that other commit meant to deal with something _beyond_ those two > things. You call transaction_end() if msg->type == XS_TRANSACTION_END, even if xb_write() returned an error. David ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() 2016-07-07 12:17 ` David Vrabel @ 2016-07-07 12:23 ` Jan Beulich 2016-07-07 13:13 ` David Vrabel 0 siblings, 1 reply; 12+ messages in thread From: Jan Beulich @ 2016-07-07 12:23 UTC (permalink / raw) To: David Vrabel; +Cc: xen-devel, boris.ostrovsky, Juergen Gross, linux-kernel >>> On 07.07.16 at 14:17, <david.vrabel@citrix.com> wrote: > On 07/07/16 13:09, Jan Beulich wrote: >>>>> On 07.07.16 at 13:36, <david.vrabel@citrix.com> wrote: >>> On 07/07/16 08:32, Jan Beulich wrote: >>>> We must not skip the transaction_end() call for a failed >>>> XS_TRANSACTION_START. The removed code fragment got introduced by >>>> commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus >>>> stalling shutdown/restart") without its description really indicating >>>> why it was added (and hence I can't identify whether a more complex >>>> change might be needed here). >>> >>> If sending the XS_TRANSACTION_END message failed, then the transaction >>> is still open and transaction_end() should not be called. >>> >>> However, if sending an XS_TRANSACTION_START failed, then >>> transaction_end() should be called. >>> >>> So, yes a more complex fix is needed here. >> >> Well, both of the things you name are what happens with the patch >> in place. So if those two conditions are all that needs to be satisfied, >> then no more complex change is needed afaict (and was the behavior >> before the cross referenced commit) - the question really is whether >> that other commit meant to deal with something _beyond_ those two >> things. > > You call transaction_end() if msg->type == XS_TRANSACTION_END, even if > xb_write() returned an error. When xb_write() returns an error, msg->type gets set to XS_ERROR. Jan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() 2016-07-07 12:23 ` Jan Beulich @ 2016-07-07 13:13 ` David Vrabel 2016-07-07 13:22 ` David Vrabel 0 siblings, 1 reply; 12+ messages in thread From: David Vrabel @ 2016-07-07 13:13 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel, boris.ostrovsky, Juergen Gross, linux-kernel On 07/07/16 13:23, Jan Beulich wrote: >>>> On 07.07.16 at 14:17, <david.vrabel@citrix.com> wrote: >> On 07/07/16 13:09, Jan Beulich wrote: >>>>>> On 07.07.16 at 13:36, <david.vrabel@citrix.com> wrote: >>>> On 07/07/16 08:32, Jan Beulich wrote: >>>>> We must not skip the transaction_end() call for a failed >>>>> XS_TRANSACTION_START. The removed code fragment got introduced by >>>>> commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus >>>>> stalling shutdown/restart") without its description really indicating >>>>> why it was added (and hence I can't identify whether a more complex >>>>> change might be needed here). >>>> >>>> If sending the XS_TRANSACTION_END message failed, then the transaction >>>> is still open and transaction_end() should not be called. >>>> >>>> However, if sending an XS_TRANSACTION_START failed, then >>>> transaction_end() should be called. >>>> >>>> So, yes a more complex fix is needed here. >>> >>> Well, both of the things you name are what happens with the patch >>> in place. So if those two conditions are all that needs to be satisfied, >>> then no more complex change is needed afaict (and was the behavior >>> before the cross referenced commit) - the question really is whether >>> that other commit meant to deal with something _beyond_ those two >>> things. >> >> You call transaction_end() if msg->type == XS_TRANSACTION_END, even if >> xb_write() returned an error. > > When xb_write() returns an error, msg->type gets set to XS_ERROR. So? if ((msg->type == XS_TRANSACTION_END) || (...)) transaction_end(); We don't check msg->type for XS_TRANSACTION_END messages. David ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() 2016-07-07 13:13 ` David Vrabel @ 2016-07-07 13:22 ` David Vrabel 2016-07-07 13:35 ` Jan Beulich 0 siblings, 1 reply; 12+ messages in thread From: David Vrabel @ 2016-07-07 13:22 UTC (permalink / raw) To: David Vrabel, Jan Beulich Cc: Juergen Gross, xen-devel, boris.ostrovsky, linux-kernel On 07/07/16 14:13, David Vrabel wrote: > On 07/07/16 13:23, Jan Beulich wrote: >>>>> On 07.07.16 at 14:17, <david.vrabel@citrix.com> wrote: >>> On 07/07/16 13:09, Jan Beulich wrote: >>>>>>> On 07.07.16 at 13:36, <david.vrabel@citrix.com> wrote: >>>>> On 07/07/16 08:32, Jan Beulich wrote: >>>>>> We must not skip the transaction_end() call for a failed >>>>>> XS_TRANSACTION_START. The removed code fragment got introduced by >>>>>> commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus >>>>>> stalling shutdown/restart") without its description really indicating >>>>>> why it was added (and hence I can't identify whether a more complex >>>>>> change might be needed here). >>>>> >>>>> If sending the XS_TRANSACTION_END message failed, then the transaction >>>>> is still open and transaction_end() should not be called. >>>>> >>>>> However, if sending an XS_TRANSACTION_START failed, then >>>>> transaction_end() should be called. >>>>> >>>>> So, yes a more complex fix is needed here. >>>> >>>> Well, both of the things you name are what happens with the patch >>>> in place. So if those two conditions are all that needs to be satisfied, >>>> then no more complex change is needed afaict (and was the behavior >>>> before the cross referenced commit) - the question really is whether >>>> that other commit meant to deal with something _beyond_ those two >>>> things. >>> >>> You call transaction_end() if msg->type == XS_TRANSACTION_END, even if >>> xb_write() returned an error. >> >> When xb_write() returns an error, msg->type gets set to XS_ERROR. > > So? > > if ((msg->type == XS_TRANSACTION_END) || > (...)) > transaction_end(); > > We don't check msg->type for XS_TRANSACTION_END messages. Sorry, being stupid. Yeah, the change is fine but it needs a better commit message. David ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() 2016-07-07 13:22 ` David Vrabel @ 2016-07-07 13:35 ` Jan Beulich 2016-07-08 10:18 ` David Vrabel 0 siblings, 1 reply; 12+ messages in thread From: Jan Beulich @ 2016-07-07 13:35 UTC (permalink / raw) To: David Vrabel; +Cc: xen-devel, boris.ostrovsky, Juergen Gross, linux-kernel >>> On 07.07.16 at 15:22, <david.vrabel@citrix.com> wrote: > On 07/07/16 14:13, David Vrabel wrote: >> On 07/07/16 13:23, Jan Beulich wrote: >>>>>> On 07.07.16 at 14:17, <david.vrabel@citrix.com> wrote: >>>> On 07/07/16 13:09, Jan Beulich wrote: >>>>>>>> On 07.07.16 at 13:36, <david.vrabel@citrix.com> wrote: >>>>>> On 07/07/16 08:32, Jan Beulich wrote: >>>>>>> We must not skip the transaction_end() call for a failed >>>>>>> XS_TRANSACTION_START. The removed code fragment got introduced by >>>>>>> commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus >>>>>>> stalling shutdown/restart") without its description really indicating >>>>>>> why it was added (and hence I can't identify whether a more complex >>>>>>> change might be needed here). >>>>>> >>>>>> If sending the XS_TRANSACTION_END message failed, then the transaction >>>>>> is still open and transaction_end() should not be called. >>>>>> >>>>>> However, if sending an XS_TRANSACTION_START failed, then >>>>>> transaction_end() should be called. >>>>>> >>>>>> So, yes a more complex fix is needed here. >>>>> >>>>> Well, both of the things you name are what happens with the patch >>>>> in place. So if those two conditions are all that needs to be satisfied, >>>>> then no more complex change is needed afaict (and was the behavior >>>>> before the cross referenced commit) - the question really is whether >>>>> that other commit meant to deal with something _beyond_ those two >>>>> things. >>>> >>>> You call transaction_end() if msg->type == XS_TRANSACTION_END, even if >>>> xb_write() returned an error. >>> >>> When xb_write() returns an error, msg->type gets set to XS_ERROR. >> >> So? >> >> if ((msg->type == XS_TRANSACTION_END) || >> (...)) >> transaction_end(); >> >> We don't check msg->type for XS_TRANSACTION_END messages. > > Sorry, being stupid. Yeah, the change is fine but it needs a better > commit message. I can certainly omit the part in parentheses. I don't think I should omit the reference to the original commit having introduced the issue. And without a more specific hint I also don't know what else may need changing. I'm sorry, I know I'm not doing very well in writing commit messages to your liking. Jan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() 2016-07-07 13:35 ` Jan Beulich @ 2016-07-08 10:18 ` David Vrabel 0 siblings, 0 replies; 12+ messages in thread From: David Vrabel @ 2016-07-08 10:18 UTC (permalink / raw) To: Jan Beulich, David Vrabel Cc: Juergen Gross, xen-devel, boris.ostrovsky, linux-kernel On 07/07/16 14:35, Jan Beulich wrote: >>>> On 07.07.16 at 15:22, <david.vrabel@citrix.com> wrote: >> On 07/07/16 14:13, David Vrabel wrote: >>> On 07/07/16 13:23, Jan Beulich wrote: >>>>>>> On 07.07.16 at 14:17, <david.vrabel@citrix.com> wrote: >>>>> On 07/07/16 13:09, Jan Beulich wrote: >>>>>>>>> On 07.07.16 at 13:36, <david.vrabel@citrix.com> wrote: >>>>>>> On 07/07/16 08:32, Jan Beulich wrote: >>>>>>>> We must not skip the transaction_end() call for a failed >>>>>>>> XS_TRANSACTION_START. The removed code fragment got introduced by >>>>>>>> commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus >>>>>>>> stalling shutdown/restart") without its description really indicating >>>>>>>> why it was added (and hence I can't identify whether a more complex >>>>>>>> change might be needed here). >>>>>>> >>>>>>> If sending the XS_TRANSACTION_END message failed, then the transaction >>>>>>> is still open and transaction_end() should not be called. >>>>>>> >>>>>>> However, if sending an XS_TRANSACTION_START failed, then >>>>>>> transaction_end() should be called. >>>>>>> >>>>>>> So, yes a more complex fix is needed here. >>>>>> >>>>>> Well, both of the things you name are what happens with the patch >>>>>> in place. So if those two conditions are all that needs to be satisfied, >>>>>> then no more complex change is needed afaict (and was the behavior >>>>>> before the cross referenced commit) - the question really is whether >>>>>> that other commit meant to deal with something _beyond_ those two >>>>>> things. >>>>> >>>>> You call transaction_end() if msg->type == XS_TRANSACTION_END, even if >>>>> xb_write() returned an error. >>>> >>>> When xb_write() returns an error, msg->type gets set to XS_ERROR. >>> >>> So? >>> >>> if ((msg->type == XS_TRANSACTION_END) || >>> (...)) >>> transaction_end(); >>> >>> We don't check msg->type for XS_TRANSACTION_END messages. >> >> Sorry, being stupid. Yeah, the change is fine but it needs a better >> commit message. > > I can certainly omit the part in parentheses. I don't think I should > omit the reference to the original commit having introduced the issue. > And without a more specific hint I also don't know what else may > need changing. I'm sorry, I know I'm not doing very well in writing > commit messages to your liking. I rewrote it as: xenbus: don't bail early from xenbus_dev_request_and_reply() xenbus_dev_request_and_reply() needs to track whether a transaction is open. For XS_TRANSACTION_START messages it calls transaction_start() and for XS_TRANSACTION_END messages it calls transaction_end(). If sending an XS_TRANSACTION_START message fails or responds with an an error, the transaction is not open and transaction_end() must be called. If sending an XS_TRANSACTION_END message fails, the transaction is still open, but if an error response is returned the transaction is closed. Commit 027bd7e89906 ("xen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart") introduced a regression where failed XS_TRANSACTION_START messages were leaving the transaction open. This can cause problems with suspend (and migration) as all transaction must be closed before suspending. It appears that the problematic change was added accidentally, so just remove it. David ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 2/2] xenbus: simplify xenbus_dev_request_and_reply() 2016-07-07 7:25 [PATCH 0/2] xenbus: xenbus_dev_request_and_reply() adjustments Jan Beulich 2016-07-07 7:32 ` [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() Jan Beulich @ 2016-07-07 7:32 ` Jan Beulich 2016-07-08 10:56 ` [Xen-devel] [PATCH 0/2] xenbus: xenbus_dev_request_and_reply() adjustments David Vrabel 2 siblings, 0 replies; 12+ messages in thread From: Jan Beulich @ 2016-07-07 7:32 UTC (permalink / raw) To: david.vrabel, boris.ostrovsky, Juergen Gross; +Cc: xen-devel, linux-kernel No need to retain a local copy of the full request message, only the type is really needed. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- drivers/xen/xenbus/xenbus_xs.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- 4.7-rc6-xen.orig/drivers/xen/xenbus/xenbus_xs.c +++ 4.7-rc6-xen/drivers/xen/xenbus/xenbus_xs.c @@ -232,10 +232,10 @@ static void transaction_resume(void) void *xenbus_dev_request_and_reply(struct xsd_sockmsg *msg) { void *ret; - struct xsd_sockmsg req_msg = *msg; + enum xsd_sockmsg_type type = msg->type; int err; - if (req_msg.type == XS_TRANSACTION_START) + if (type == XS_TRANSACTION_START) transaction_start(); mutex_lock(&xs_state.request_mutex); @@ -250,8 +250,7 @@ void *xenbus_dev_request_and_reply(struc mutex_unlock(&xs_state.request_mutex); if ((msg->type == XS_TRANSACTION_END) || - ((req_msg.type == XS_TRANSACTION_START) && - (msg->type == XS_ERROR))) + ((type == XS_TRANSACTION_START) && (msg->type == XS_ERROR))) transaction_end(); return ret; ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xen-devel] [PATCH 0/2] xenbus: xenbus_dev_request_and_reply() adjustments 2016-07-07 7:25 [PATCH 0/2] xenbus: xenbus_dev_request_and_reply() adjustments Jan Beulich 2016-07-07 7:32 ` [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() Jan Beulich 2016-07-07 7:32 ` [PATCH 2/2] xenbus: simplify xenbus_dev_request_and_reply() Jan Beulich @ 2016-07-08 10:56 ` David Vrabel 2 siblings, 0 replies; 12+ messages in thread From: David Vrabel @ 2016-07-08 10:56 UTC (permalink / raw) To: Jan Beulich, david.vrabel, boris.ostrovsky, Juergen Gross Cc: xen-devel, linux-kernel On 07/07/16 08:25, Jan Beulich wrote: > 1: don't bail early from xenbus_dev_request_and_reply() > 2: simplify xenbus_dev_request_and_reply() Applied to for-linus-4.7b, thanks. David ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-07-08 10:56 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-07-07 7:25 [PATCH 0/2] xenbus: xenbus_dev_request_and_reply() adjustments Jan Beulich 2016-07-07 7:32 ` [PATCH 1/2] xenbus: don't bail early from xenbus_dev_request_and_reply() Jan Beulich 2016-07-07 11:36 ` [Xen-devel] " David Vrabel 2016-07-07 12:09 ` Jan Beulich 2016-07-07 12:17 ` David Vrabel 2016-07-07 12:23 ` Jan Beulich 2016-07-07 13:13 ` David Vrabel 2016-07-07 13:22 ` David Vrabel 2016-07-07 13:35 ` Jan Beulich 2016-07-08 10:18 ` David Vrabel 2016-07-07 7:32 ` [PATCH 2/2] xenbus: simplify xenbus_dev_request_and_reply() Jan Beulich 2016-07-08 10:56 ` [Xen-devel] [PATCH 0/2] xenbus: xenbus_dev_request_and_reply() adjustments David Vrabel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox