On Fri, Nov 30, 2012 at 01:58:18PM +, Myklebust, Trond wrote:
> The reason for the choice of d_drop over d_invalidate() is the d_count
> checks. It really doesn't matter whether or not the client thinks it has
> users for a directory if the server is telling you that it is ESTALE. So
> we forc
On Fri, Nov 30, 2012 at 02:00:48AM +, Al Viro wrote:
> OK, that settles it. WARN_ON() and printks in the area can be dropped;
> the right fix is below. However, there's a similar place in cifs that
> also needs to be dealt with and I really, really wonder why the hell do
> we do d_drop() in
On Fri, 2012-11-30 at 02:00 +, Al Viro wrote:
> On Thu, Nov 29, 2012 at 05:54:02PM -0800, Patrick McLean wrote:
> > > Very interesting. Do you have anything mounted on the corresponding
> > > directories on server? The picture looks like you are getting empty
> > > fhandles in readdir+ resp
On Thu, Nov 29, 2012 at 06:33:53PM -0800, Patrick McLean wrote:
> Excellent, thanks. Is there any chance this will make it to 3.7? Also we
> might want to cc stable@ on this as well since it is a regression in 3.6.
Definitely. I've dropped that into vfs.git#for-linus and vfs.git#for-next
and to
On 29/11/12 06:00 PM, Al Viro wrote:
> On Thu, Nov 29, 2012 at 05:54:02PM -0800, Patrick McLean wrote:
>>> Very interesting. Do you have anything mounted on the corresponding
>>> directories on server? The picture looks like you are getting empty
>>> fhandles in readdir+ respons for exactly t
On Thu, Nov 29, 2012 at 05:54:02PM -0800, Patrick McLean wrote:
> > Very interesting. Do you have anything mounted on the corresponding
> > directories on server? The picture looks like you are getting empty
> > fhandles in readdir+ respons for exactly the same directories that happen
> > to
On 29/11/12 05:36 PM, Al Viro wrote:
> On Thu, Nov 29, 2012 at 04:57:19PM -0800, Patrick McLean wrote:
>>> Interesting... Server-side that should've been produced by
>>> encode_entryplus_baggage(), which looks like failing compose_entry_fh()...
>>> which has explicit
>>> if (d_mountpoint(d
On Thu, Nov 29, 2012 at 04:57:19PM -0800, Patrick McLean wrote:
> > Interesting... Server-side that should've been produced by
> > encode_entryplus_baggage(), which looks like failing compose_entry_fh()...
> > which has explicit
> > if (d_mountpoint(dchild))
> > goto out;
>
On 29/11/12 04:35 PM, Al Viro wrote:
> On Thu, Nov 29, 2012 at 04:19:51PM -0800, Patrick McLean wrote:
[8.821584] FH(0)]
[8.821586] FH(36)[01 00 07 01 89 00 00 00 00 00 00 00 e1 21 fe c4 9e
38 44 dc bf 1b d5 95 d6 76 d6 d9 a7 3c 1b 80 33 38 e3 62]
[8.821601] filenam
On Thu, Nov 29, 2012 at 04:19:51PM -0800, Patrick McLean wrote:
> >> [8.821584] FH(0)]
> >> [8.821586] FH(36)[01 00 07 01 89 00 00 00 00 00 00 00 e1 21 fe c4 9e
> >> 38 44 dc bf 1b d5 95 d6 76 d6 d9 a7 3c 1b 80 33 38 e3 62]
> >> [8.821601] filename: proc
> >
> > *whoa*
> >
> > So we
On 29/11/12 03:43 PM, Al Viro wrote:
> On Thu, Nov 29, 2012 at 02:53:13PM -0800, Patrick McLean wrote:
>> On 29/11/12 02:21 PM, Al Viro wrote:
>>> On Thu, Nov 29, 2012 at 02:06:22PM -0800, Patrick McLean wrote:
>>>
I have a trivial reproducer and am happy to help debug in any way that
I c
On Thu, Nov 29, 2012 at 02:53:13PM -0800, Patrick McLean wrote:
> On 29/11/12 02:21 PM, Al Viro wrote:
> > On Thu, Nov 29, 2012 at 02:06:22PM -0800, Patrick McLean wrote:
> >
> >> I have a trivial reproducer and am happy to help debug in any way that
> >> I can. That patch seems to fix the problem
On 29/11/12 02:21 PM, Al Viro wrote:
> On Thu, Nov 29, 2012 at 02:06:22PM -0800, Patrick McLean wrote:
>
>> I have a trivial reproducer and am happy to help debug in any way that
>> I can. That patch seems to fix the problem, and produces these
>> warnings in dmesg:
>
> OK... So we have differin
On Thu, Nov 29, 2012 at 02:06:22PM -0800, Patrick McLean wrote:
> I have a trivial reproducer and am happy to help debug in any way that
> I can. That patch seems to fix the problem, and produces these
> warnings in dmesg:
>
> [3.306483] dracut: Switching root
> [4.324378] systemd-udevd[5
On Thu, Nov 29, 2012 at 1:33 PM, Al Viro wrote:
> On Thu, Nov 29, 2012 at 11:16:59AM -0800, Patrick McLean wrote:
>> With 3.6-rc1 and up, when using a (dracut) initramfs with a read-only
>> nfs root, all accesses to /proc. /sys and /dev return EBUSY.
>
> See "[PATCH] Revert "__d_unalias() should r
On Thu, Nov 29, 2012 at 11:16:59AM -0800, Patrick McLean wrote:
> With 3.6-rc1 and up, when using a (dracut) initramfs with a read-only
> nfs root, all accesses to /proc. /sys and /dev return EBUSY.
See "[PATCH] Revert "__d_unalias() should refuse to move mountpoints"
thread. If you have a conven
With 3.6-rc1 and up, when using a (dracut) initramfs with a read-only
nfs root, all accesses to /proc. /sys and /dev return EBUSY.
Bisecting finds this commit as where this was introduced:
> ee3efa91e240f513898050ef305a49a653c8ed90 is the first bad commit
> commit ee3efa91e240f513898050ef305a49a6
17 matches
Mail list logo
