Thanks,
applied to configfs-for-next.
On Fri, May 17, 2019 at 10:23:12AM +0200, Christoph Hellwig wrote:
> On Thu, May 16, 2019 at 06:27:53PM +0530, stumm...@codeaurora.org wrote:
> > Hi Christoph, Al,
> >
> > Can you please consider this patch for merging?
>
> I've been sitting on this for a while, mostly because I can't convince
>
On Thu, May 16, 2019 at 06:27:53PM +0530, stumm...@codeaurora.org wrote:
> Hi Christoph, Al,
>
> Can you please consider this patch for merging?
I've been sitting on this for a while, mostly because I can't convince
myself it is safe. What protects other threads from using ->s_dentry
just when
Hi Christoph, Al,
Can you please consider this patch for merging?
Thanks,
Sahitya.
On 2019-01-31 08:50, Sahitya Tummala wrote:
Al,
Can we merge this patch, if there are no further comments?
Thanks,
Sahitya.
On Thu, Jan 03, 2019 at 04:48:15PM +0530, Sahitya Tummala wrote:
In the
Al,
Can we merge this patch, if there are no further comments?
Thanks,
Sahitya.
On Thu, Jan 03, 2019 at 04:48:15PM +0530, Sahitya Tummala wrote:
> In the vfs_statx() context, during path lookup, the dentry gets
> added to sd->s_dentry via configfs_attach_attr(). In the end,
> vfs_statx() kills
In the vfs_statx() context, during path lookup, the dentry gets
added to sd->s_dentry via configfs_attach_attr(). In the end,
vfs_statx() kills the dentry by calling path_put(), which invokes
configfs_d_iput(). Ideally, this dentry must be removed from
sd->s_dentry but it doesn't if the
6 matches
Mail list logo