| To: | Alex Elder <aelder@xxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 12/12] xfs: Remove the macro XFS_BUFTARG_NAME |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Sun, 24 Jul 2011 07:37:24 -0400 |
| Cc: | Chandra Seetharaman <sekharan@xxxxxxxxxx>, xfs@xxxxxxxxxxx |
| In-reply-to: | <1311364181.2771.114.camel@doink> |
| References: | <20110722003226.21069.58401.sendpatchset@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110722003408.21069.44409.sendpatchset@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1311364181.2771.114.camel@doink> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Fri, Jul 22, 2011 at 02:49:41PM -0500, Alex Elder wrote: > On Thu, 2011-07-21 at 17:34 -0700, Chandra Seetharaman wrote: > > Remove the definition and usages of the macro XFS_BUFTARG_NAME. > > > > Signed-off-by: Chandra Seetharaman <sekharan@xxxxxxxxxx> > > Reviewed-by: Christoph Hellwig <hch@xxxxxx> > > > Wow, I hadn't looked at the definition of > xfs_buf_target_name() before. It's not safe > (using a pointer to since-released stack space), > though in practice it's going to be fine. > > Defining it as an inline function with a static > buffer would at least avoid that, though it > means it's not reentrant either. IMHO the right fix is to just kill it off entirely. All XFS messages now have the filesystem name prefixed to them, and while we can have up to three devices, all these error messages can only hit either the main or the log device, and it's obvious from the context which one we did hit. |
| Previous by Date: | Re: [PATCH 08/12] xfs: Remove the macro XFS_BUF_SET_PTR, Christoph Hellwig |
|---|---|
| Next by Date: | Re: [PATCH 02/12 v3] xfs: Remove the macro XFS_BUF_ZEROFLAGS, Christoph Hellwig |
| Previous by Thread: | Re: [PATCH 12/12] xfs: Remove the macro XFS_BUFTARG_NAME, Chandra Seetharaman |
| Next by Thread: | Re: [PATCH 12/12] xfs: Remove the macro XFS_BUFTARG_NAME, Alex Elder |
| Indexes: | [Date] [Thread] [Top] [All Lists] |