| Message ID | 20131023124444.65ace6e3@notabene.brown (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 10/22/2013 08:44 PM, NeilBrown wrote: > On Tue, 22 Oct 2013 10:23:14 -0500 Tony Asleson <tasleson@redhat.com> wrote: >> The reason I chose to return values was to make sure requested operation >> actually completed requested operation. Unexporting a non-existent >> export is not considered an error and returns no indication you did >> absolutely nothing. > > Hi, > thanks makes sense - I had missed that (even though you explained it in the > patch description :-( ) > > With your patch, if asked to unexport something that wasn't exported it > would not report any error, but would exit with an error status. Is that > correct? I think I would rather have a message printed if there is an error. Correct, I only made changes for the exit status. I was trying to make changes that would be mostly invisible to end users. I have no concerns adding a printed error output too, but others may. Changing the behavior of any command line tool is potentially problematic when scripted. > So would something like this (on top of my patch) address you need, or was > there something else I missed? Yes, this should work for the unexport fs case. However, the reason my patch was a little more invasive was to ensure that both the export and unexport paths were covered. For example, if the strdup call fails in function client_init, we fail the operation and return exit value of 0. Unlikely, but just the first example I stumbled across. Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 23 Oct 2013 12:36:23 -0500 Tony Asleson <tasleson@redhat.com> wrote: > On 10/22/2013 08:44 PM, NeilBrown wrote: > > On Tue, 22 Oct 2013 10:23:14 -0500 Tony Asleson <tasleson@redhat.com> wrote: > >> The reason I chose to return values was to make sure requested operation > >> actually completed requested operation. Unexporting a non-existent > >> export is not considered an error and returns no indication you did > >> absolutely nothing. > > > > Hi, > > thanks makes sense - I had missed that (even though you explained it in the > > patch description :-( ) > > > > With your patch, if asked to unexport something that wasn't exported it > > would not report any error, but would exit with an error status. Is that > > correct? I think I would rather have a message printed if there is an error. > > Correct, I only made changes for the exit status. I was trying to make > changes that would be mostly invisible to end users. I have no concerns > adding a printed error output too, but others may. > > Changing the behavior of any command line tool is potentially > problematic when scripted. > > > So would something like this (on top of my patch) address you need, or was > > there something else I missed? > > Yes, this should work for the unexport fs case. > > However, the reason my patch was a little more invasive was to ensure > that both the export and unexport paths were covered. > > For example, if the strdup call fails in function client_init, we fail > the operation and return exit value of 0. Unlikely, but just the first > example I stumbled across. I think it is a lot closer to "impossible" than just "unlikely". malloc doesn't fail in this sort of context, the OOM killer kills something off instead. My personal preference is to replace all malloc/calloc/strdup calls with the xmalloc, xstrdup etc calls in support/nfs/xcommon.c. If you are worried about malloc failing, I'd much prefer to see a patch which changes nfs-utils to use those uniformly. There might be a question over the best behaviour for daemons like mountd and gssd. However as we move towards having systemd manage those, they will be restarted if they ever exit, and they are mostly stateless so that is quite safe. Does anyone else have thoughts on this? NeilBrown
On Oct 23, 2013, at 6:18 PM, NeilBrown <neilb@suse.de> wrote: > On Wed, 23 Oct 2013 12:36:23 -0500 Tony Asleson <tasleson@redhat.com> wrote: > >> On 10/22/2013 08:44 PM, NeilBrown wrote: >>> On Tue, 22 Oct 2013 10:23:14 -0500 Tony Asleson <tasleson@redhat.com> wrote: >>>> The reason I chose to return values was to make sure requested operation >>>> actually completed requested operation. Unexporting a non-existent >>>> export is not considered an error and returns no indication you did >>>> absolutely nothing. >>> >>> Hi, >>> thanks makes sense - I had missed that (even though you explained it in the >>> patch description :-( ) >>> >>> With your patch, if asked to unexport something that wasn't exported it >>> would not report any error, but would exit with an error status. Is that >>> correct? I think I would rather have a message printed if there is an error. >> >> Correct, I only made changes for the exit status. I was trying to make >> changes that would be mostly invisible to end users. I have no concerns >> adding a printed error output too, but others may. >> >> Changing the behavior of any command line tool is potentially >> problematic when scripted. >> >>> So would something like this (on top of my patch) address you need, or was >>> there something else I missed? >> >> Yes, this should work for the unexport fs case. >> >> However, the reason my patch was a little more invasive was to ensure >> that both the export and unexport paths were covered. >> >> For example, if the strdup call fails in function client_init, we fail >> the operation and return exit value of 0. Unlikely, but just the first >> example I stumbled across. > > I think it is a lot closer to "impossible" than just "unlikely". > malloc doesn't fail in this sort of context, the OOM killer kills something > off instead. > My personal preference is to replace all malloc/calloc/strdup calls with > the xmalloc, xstrdup etc calls in support/nfs/xcommon.c. > If you are worried about malloc failing, I'd much prefer to see a patch which > changes nfs-utils to use those uniformly. > > There might be a question over the best behaviour for daemons like mountd > and gssd. However as we move towards having systemd manage those, they will > be restarted if they ever exit, and they are mostly stateless so that is > quite safe. > > Does anyone else have thoughts on this? Yes. My thought is "xmalloc is an abomination." :-) We really do not want any of these tools exiting left if there's a memory allocation failure. For a user, that's no better than a segfault. What's more, if a utility like exportfs isn't very carefully coded, a sideways exit can leave on-disk files in an inconsistent state. A rule of thumb is never hide control flow (like exiting) inside macros or libraries. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/23/2013 05:18 PM, NeilBrown wrote: > On Wed, 23 Oct 2013 12:36:23 -0500 Tony Asleson <tasleson@redhat.com> wrote: >> For example, if the strdup call fails in function client_init, we fail >> the operation and return exit value of 0. Unlikely, but just the first >> example I stumbled across. > > I think it is a lot closer to "impossible" than just "unlikely". > malloc doesn't fail in this sort of context, the OOM killer kills something > off instead. > My personal preference is to replace all malloc/calloc/strdup calls with > the xmalloc, xstrdup etc calls in support/nfs/xcommon.c. > If you are worried about malloc failing, I'd much prefer to see a patch which > changes nfs-utils to use those uniformly. Sorry, my real point was that there are other ways for exportfs to fail to do the operation and fail to report it, thus the reason my patch was more invasive. I will try to find another more likely example that illustrates this. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23/10/13 19:31, Chuck Lever wrote: > > On Oct 23, 2013, at 6:18 PM, NeilBrown <neilb@suse.de> wrote: > >> On Wed, 23 Oct 2013 12:36:23 -0500 Tony Asleson <tasleson@redhat.com> wrote: >> >>> On 10/22/2013 08:44 PM, NeilBrown wrote: >>>> On Tue, 22 Oct 2013 10:23:14 -0500 Tony Asleson <tasleson@redhat.com> wrote: >>>>> The reason I chose to return values was to make sure requested operation >>>>> actually completed requested operation. Unexporting a non-existent >>>>> export is not considered an error and returns no indication you did >>>>> absolutely nothing. >>>> >>>> Hi, >>>> thanks makes sense - I had missed that (even though you explained it in the >>>> patch description :-( ) >>>> >>>> With your patch, if asked to unexport something that wasn't exported it >>>> would not report any error, but would exit with an error status. Is that >>>> correct? I think I would rather have a message printed if there is an error. >>> >>> Correct, I only made changes for the exit status. I was trying to make >>> changes that would be mostly invisible to end users. I have no concerns >>> adding a printed error output too, but others may. >>> >>> Changing the behavior of any command line tool is potentially >>> problematic when scripted. >>> >>>> So would something like this (on top of my patch) address you need, or was >>>> there something else I missed? >>> >>> Yes, this should work for the unexport fs case. >>> >>> However, the reason my patch was a little more invasive was to ensure >>> that both the export and unexport paths were covered. >>> >>> For example, if the strdup call fails in function client_init, we fail >>> the operation and return exit value of 0. Unlikely, but just the first >>> example I stumbled across. >> >> I think it is a lot closer to "impossible" than just "unlikely". >> malloc doesn't fail in this sort of context, the OOM killer kills something >> off instead. >> My personal preference is to replace all malloc/calloc/strdup calls with >> the xmalloc, xstrdup etc calls in support/nfs/xcommon.c. >> If you are worried about malloc failing, I'd much prefer to see a patch which >> changes nfs-utils to use those uniformly. >> >> There might be a question over the best behaviour for daemons like mountd >> and gssd. However as we move towards having systemd manage those, they will >> be restarted if they ever exit, and they are mostly stateless so that is >> quite safe. >> >> Does anyone else have thoughts on this? > > Yes. My thought is "xmalloc is an abomination." :-) > > We really do not want any of these tools exiting left if there's a memory allocation failure. > For a user, that's no better than a segfault. I the past I have agreed with this... But as Neil points out, we now live in a systemd world were daemons are restarted, so maybe it does make sense to exit on these types of failures. With daemons like mountd there is really no state that would be lost.... steved. > > What's more, if a utility like exportfs isn't very carefully coded, a sideways exit > can leave on-disk files in an inconsistent state. > > A rule of thumb is never hide control flow (like exiting) inside macros or libraries. > > -- > Chuck Lever > chuck[dot]lever[at]oracle[dot]com > > > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Oct 24, 2013, at 11:56 AM, Steve Dickson <SteveD@redhat.com> wrote: > > > On 23/10/13 19:31, Chuck Lever wrote: >> >> On Oct 23, 2013, at 6:18 PM, NeilBrown <neilb@suse.de> wrote: >> >>> On Wed, 23 Oct 2013 12:36:23 -0500 Tony Asleson <tasleson@redhat.com> wrote: >>> >>>> On 10/22/2013 08:44 PM, NeilBrown wrote: >>>>> On Tue, 22 Oct 2013 10:23:14 -0500 Tony Asleson <tasleson@redhat.com> wrote: >>>>>> The reason I chose to return values was to make sure requested operation >>>>>> actually completed requested operation. Unexporting a non-existent >>>>>> export is not considered an error and returns no indication you did >>>>>> absolutely nothing. >>>>> >>>>> Hi, >>>>> thanks makes sense - I had missed that (even though you explained it in the >>>>> patch description :-( ) >>>>> >>>>> With your patch, if asked to unexport something that wasn't exported it >>>>> would not report any error, but would exit with an error status. Is that >>>>> correct? I think I would rather have a message printed if there is an error. >>>> >>>> Correct, I only made changes for the exit status. I was trying to make >>>> changes that would be mostly invisible to end users. I have no concerns >>>> adding a printed error output too, but others may. >>>> >>>> Changing the behavior of any command line tool is potentially >>>> problematic when scripted. >>>> >>>>> So would something like this (on top of my patch) address you need, or was >>>>> there something else I missed? >>>> >>>> Yes, this should work for the unexport fs case. >>>> >>>> However, the reason my patch was a little more invasive was to ensure >>>> that both the export and unexport paths were covered. >>>> >>>> For example, if the strdup call fails in function client_init, we fail >>>> the operation and return exit value of 0. Unlikely, but just the first >>>> example I stumbled across. >>> >>> I think it is a lot closer to "impossible" than just "unlikely". >>> malloc doesn't fail in this sort of context, the OOM killer kills something >>> off instead. >>> My personal preference is to replace all malloc/calloc/strdup calls with >>> the xmalloc, xstrdup etc calls in support/nfs/xcommon.c. >>> If you are worried about malloc failing, I'd much prefer to see a patch which >>> changes nfs-utils to use those uniformly. >>> >>> There might be a question over the best behaviour for daemons like mountd >>> and gssd. However as we move towards having systemd manage those, they will >>> be restarted if they ever exit, and they are mostly stateless so that is >>> quite safe. >>> >>> Does anyone else have thoughts on this? >> >> Yes. My thought is "xmalloc is an abomination." :-) >> >> We really do not want any of these tools exiting left if there's a memory allocation failure. >> For a user, that's no better than a segfault. > I the past I have agreed with this... But as Neil points out, we now live in > a systemd world were daemons are restarted, so maybe it does make sense to > exit on these types of failures. With daemons like mountd there is > really no state that would be lost.... Neil's arguments are very practical, but ... There are other reasons that malloc() can fail. Software bugs are high on that list. It can also fail if user input (or network input) is used to determine the requested allocation size. In addition, rpmlint/fedpkg-lint complain if there's an exit(2) call in your linked libraries. They would frown on xmalloc() invoking exit (they also aren't happy with xlog). Whether or not it's OK for daemons, I still maintain that for administrative tools run directly by users like exportfs, we want to be more careful. Since the daemons share the same libraries as the user tools, that means xmalloc and friends should be avoided everywhere, IMO. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 24 Oct 2013 12:05:35 -0400 Chuck Lever <chuck.lever@oracle.com> wrote: > > On Oct 24, 2013, at 11:56 AM, Steve Dickson <SteveD@redhat.com> wrote: > > > > > > > On 23/10/13 19:31, Chuck Lever wrote: > >> > >> On Oct 23, 2013, at 6:18 PM, NeilBrown <neilb@suse.de> wrote: > >> > >>> On Wed, 23 Oct 2013 12:36:23 -0500 Tony Asleson <tasleson@redhat.com> wrote: > >>> > >>>> On 10/22/2013 08:44 PM, NeilBrown wrote: > >>>>> On Tue, 22 Oct 2013 10:23:14 -0500 Tony Asleson <tasleson@redhat.com> wrote: > >>>>>> The reason I chose to return values was to make sure requested operation > >>>>>> actually completed requested operation. Unexporting a non-existent > >>>>>> export is not considered an error and returns no indication you did > >>>>>> absolutely nothing. > >>>>> > >>>>> Hi, > >>>>> thanks makes sense - I had missed that (even though you explained it in the > >>>>> patch description :-( ) > >>>>> > >>>>> With your patch, if asked to unexport something that wasn't exported it > >>>>> would not report any error, but would exit with an error status. Is that > >>>>> correct? I think I would rather have a message printed if there is an error. > >>>> > >>>> Correct, I only made changes for the exit status. I was trying to make > >>>> changes that would be mostly invisible to end users. I have no concerns > >>>> adding a printed error output too, but others may. > >>>> > >>>> Changing the behavior of any command line tool is potentially > >>>> problematic when scripted. > >>>> > >>>>> So would something like this (on top of my patch) address you need, or was > >>>>> there something else I missed? > >>>> > >>>> Yes, this should work for the unexport fs case. > >>>> > >>>> However, the reason my patch was a little more invasive was to ensure > >>>> that both the export and unexport paths were covered. > >>>> > >>>> For example, if the strdup call fails in function client_init, we fail > >>>> the operation and return exit value of 0. Unlikely, but just the first > >>>> example I stumbled across. > >>> > >>> I think it is a lot closer to "impossible" than just "unlikely". > >>> malloc doesn't fail in this sort of context, the OOM killer kills something > >>> off instead. > >>> My personal preference is to replace all malloc/calloc/strdup calls with > >>> the xmalloc, xstrdup etc calls in support/nfs/xcommon.c. > >>> If you are worried about malloc failing, I'd much prefer to see a patch which > >>> changes nfs-utils to use those uniformly. > >>> > >>> There might be a question over the best behaviour for daemons like mountd > >>> and gssd. However as we move towards having systemd manage those, they will > >>> be restarted if they ever exit, and they are mostly stateless so that is > >>> quite safe. > >>> > >>> Does anyone else have thoughts on this? > >> > >> Yes. My thought is "xmalloc is an abomination." :-) > >> > >> We really do not want any of these tools exiting left if there's a memory allocation failure. > >> For a user, that's no better than a segfault. > > I the past I have agreed with this... But as Neil points out, we now live in > > a systemd world were daemons are restarted, so maybe it does make sense to > > exit on these types of failures. With daemons like mountd there is > > really no state that would be lost.... > > Neil's arguments are very practical, but ... > > There are other reasons that malloc() can fail. Software bugs are high on that list. It can also fail if user input (or network input) is used to determine the requested allocation size. > > In addition, rpmlint/fedpkg-lint complain if there's an exit(2) call in your linked libraries. They would frown on xmalloc() invoking exit (they also aren't happy with xlog). > > Whether or not it's OK for daemons, I still maintain that for administrative tools run directly by users like exportfs, we want to be more careful. Since the daemons share the same libraries as the user tools, that means xmalloc and friends should be avoided everywhere, IMO. I don't follow this argument. Why do we need to be more careful for administrative tools? Tools should always be written to be crash-proof, and I believe exportfs is. It writes to a temp file and then performs an atomic rename when the new file is ready. If anything goes wrong it is perfectly safe to simply exit, and the important files will be unchanged. The memory allocation failures that we are talking about here are for a dozen bytes or so and are extremely are. I would be a lot more confident in 'exit' doing the right thing, than in multiple untested error paths carrying the error up and making sure not to write out the file if the malloc error might result in it having the wrong value. (On the question of 'exit' in libraries, I'm ambivalent). NeilBrown > > -- > Chuck Lever > chuck[dot]lever[at]oracle[dot]com > >
On Oct 27, 2013, at 11:39 PM, NeilBrown <neilb@suse.de> wrote: > On Thu, 24 Oct 2013 12:05:35 -0400 Chuck Lever <chuck.lever@oracle.com> wrote: > >> >> On Oct 24, 2013, at 11:56 AM, Steve Dickson <SteveD@redhat.com> wrote: >> >>> >>> >>> On 23/10/13 19:31, Chuck Lever wrote: >>>> >>>> On Oct 23, 2013, at 6:18 PM, NeilBrown <neilb@suse.de> wrote: >>>> >>>>> On Wed, 23 Oct 2013 12:36:23 -0500 Tony Asleson <tasleson@redhat.com> wrote: >>>>> >>>>>> On 10/22/2013 08:44 PM, NeilBrown wrote: >>>>>>> On Tue, 22 Oct 2013 10:23:14 -0500 Tony Asleson <tasleson@redhat.com> wrote: >>>>>>>> The reason I chose to return values was to make sure requested operation >>>>>>>> actually completed requested operation. Unexporting a non-existent >>>>>>>> export is not considered an error and returns no indication you did >>>>>>>> absolutely nothing. >>>>>>> >>>>>>> Hi, >>>>>>> thanks makes sense - I had missed that (even though you explained it in the >>>>>>> patch description :-( ) >>>>>>> >>>>>>> With your patch, if asked to unexport something that wasn't exported it >>>>>>> would not report any error, but would exit with an error status. Is that >>>>>>> correct? I think I would rather have a message printed if there is an error. >>>>>> >>>>>> Correct, I only made changes for the exit status. I was trying to make >>>>>> changes that would be mostly invisible to end users. I have no concerns >>>>>> adding a printed error output too, but others may. >>>>>> >>>>>> Changing the behavior of any command line tool is potentially >>>>>> problematic when scripted. >>>>>> >>>>>>> So would something like this (on top of my patch) address you need, or was >>>>>>> there something else I missed? >>>>>> >>>>>> Yes, this should work for the unexport fs case. >>>>>> >>>>>> However, the reason my patch was a little more invasive was to ensure >>>>>> that both the export and unexport paths were covered. >>>>>> >>>>>> For example, if the strdup call fails in function client_init, we fail >>>>>> the operation and return exit value of 0. Unlikely, but just the first >>>>>> example I stumbled across. >>>>> >>>>> I think it is a lot closer to "impossible" than just "unlikely". >>>>> malloc doesn't fail in this sort of context, the OOM killer kills something >>>>> off instead. >>>>> My personal preference is to replace all malloc/calloc/strdup calls with >>>>> the xmalloc, xstrdup etc calls in support/nfs/xcommon.c. >>>>> If you are worried about malloc failing, I'd much prefer to see a patch which >>>>> changes nfs-utils to use those uniformly. >>>>> >>>>> There might be a question over the best behaviour for daemons like mountd >>>>> and gssd. However as we move towards having systemd manage those, they will >>>>> be restarted if they ever exit, and they are mostly stateless so that is >>>>> quite safe. >>>>> >>>>> Does anyone else have thoughts on this? >>>> >>>> Yes. My thought is "xmalloc is an abomination." :-) >>>> >>>> We really do not want any of these tools exiting left if there's a memory allocation failure. >>>> For a user, that's no better than a segfault. >>> I the past I have agreed with this... But as Neil points out, we now live in >>> a systemd world were daemons are restarted, so maybe it does make sense to >>> exit on these types of failures. With daemons like mountd there is >>> really no state that would be lost.... >> >> Neil's arguments are very practical, but ... >> >> There are other reasons that malloc() can fail. Software bugs are high on that list. It can also fail if user input (or network input) is used to determine the requested allocation size. >> >> In addition, rpmlint/fedpkg-lint complain if there's an exit(2) call in your linked libraries. They would frown on xmalloc() invoking exit (they also aren't happy with xlog). >> >> Whether or not it's OK for daemons, I still maintain that for administrative tools run directly by users like exportfs, we want to be more careful. Since the daemons share the same libraries as the user tools, that means xmalloc and friends should be avoided everywhere, IMO. > > I don't follow this argument. Why do we need to be more careful for > administrative tools? > > Tools should always be written to be crash-proof, and I believe exportfs is. > It writes to a temp file and then performs an atomic rename when the new file > is ready. If anything goes wrong it is perfectly safe to simply exit, and > the important files will be unchanged. Data corruption is only half the argument. The other half is how this looks to users when it happens. The tool just stops working with a cryptic error message. IMO it looks no better than a segfault. But you may be right; there might be no good alternatives, and the possibility of failure is rare in normal cases. > The memory allocation failures that we are talking about here are for a dozen > bytes or so and are extremely are. I would be a lot more confident in 'exit' > doing the right thing, than in multiple untested error paths carrying the > error up and making sure not to write out the file if the malloc error might > result in it having the wrong value. As you say, this isn't an issue if the tool is writing to a temp file, then renaming as the last step. > (On the question of 'exit' in libraries, I'm ambivalent). While this doesn't apply to exportfs, of course, these days one may also have to think about GUIs, binding to other language environments, or scripts run in "behind the scenes" environments where there is no possibility of reporting an error. Sideways library exits are quite unhelpful in those cases. They might make prototyping a little easier, but I can't think of a good user-centric reason to use them. But, I'm not objecting, just whinging a bit. If you want to take this course, then go ahead. It's really an argument about coding style rather than something important ;-) -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/utils/exportfs/exportfs.c b/utils/exportfs/exportfs.c index 52fc03d..c9e12db 100644 --- a/utils/exportfs/exportfs.c +++ b/utils/exportfs/exportfs.c @@ -351,6 +351,7 @@ unexportfs(char *arg, int verbose) char *path; char *hname = arg; int htype; + int success = 0; if ((path = strchr(arg, ':')) != NULL) *path++ = '\0'; @@ -397,7 +398,10 @@ unexportfs(char *arg, int verbose) #endif exp->m_xtabent = 0; exp->m_mayexport = 0; + success = 1; } + if (!success) + xlog(L_ERROR, "Could not find %s to unexport.\n", arg); freeaddrinfo(ai); }