Now that we're past the 3.4 merge window should I post the LNFS
modifications for review for when 3.5 rolls around?
Dave
On 04/05/2012 13:15, Myklebust, Trond wrote:
> On Thu, 2012-04-05 at 13:02 -0400, David Quigley wrote:
>> Now that we're past the 3.4 merge window should I post the LNFS
>> modifications for review for when 3.5 rolls around?
>
> The sooner the better. It looks as if there will be quite a bit of
> stuff
> going into 3.5, so it would be nice to maximise our testing window.
>
> Thanks!
> Trond
I have a mostly working copy for 3.2 which I can forward port but I'm
having an issue with it. The revalidate code changed at some point and
just to get things working I dropped a piece of code from the patch set
that I couldn't figure out how to transition to the new revalidate code.
Unfortunately this is the initial get of the security label so the
security label is invalid until the first cache invalidation. Any
suggestions on where to place this code? I can give you the original
code snippet when I get home that I dropped.
Dave
On 04/05/2012 22:20, Myklebust, Trond wrote:
>> -----Original Message-----
>> From: David Quigley [mailto:[email protected]]
>> Sent: Thursday, April 05, 2012 2:38 PM
>> To: Myklebust, Trond
>> Cc: [email protected]
>> Subject: Re: Another try at LNFS?
>>
>> On 04/05/2012 17:26, David Quigley wrote:
>> > On 04/05/2012 13:15, Myklebust, Trond wrote:
>> >> On Thu, 2012-04-05 at 13:02 -0400, David Quigley wrote:
>> >>> Now that we're past the 3.4 merge window should I post the LNFS
>> >>> modifications for review for when 3.5 rolls around?
>> >>
>> >> The sooner the better. It looks as if there will be quite a bit
>> of
>> >> stuff going into 3.5, so it would be nice to maximise our testing
>> >> window.
>> >>
>> >> Thanks!
>> >> Trond
>> >
>> > I have a mostly working copy for 3.2 which I can forward port but
>> I'm
>> > having an issue with it. The revalidate code changed at some point
>> and
>> > just to get things working I dropped a piece of code from the
>> patch
>> > set that I couldn't figure out how to transition to the new
>> revalidate
>> > code. Unfortunately this is the initial get of the security label
>> so
>> > the security label is invalid until the first cache invalidation.
>> Any
>> > suggestions on where to place this code? I can give you the
>> original
>> > code snippet when I get home that I dropped.
>> >
>> > Dave
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe
>> linux-nfs"
>> > in
>> > the body of a message to [email protected] More majordomo
>> info
>> > at http://vger.kernel.org/majordomo-info.html
>>
>> Looking at my patches it looks like nfs_lookup_revalidate was
>> changed and at
>> the time I couldn't figure out what it was changed to.
>
> Hi Dave,
> There shouldn't be much in the way of changes in
> nfs_lookup_revalidate(): I was just trying to clean it up in
> preparation for the atomic open patches that Miklos is currently
> working on.
> At this point, it looks as if most of that functionality will in any
> case be moved into the struct file_operations->open callback, so that
> we can keep ->d_revalidate() as a pure lookup function.
>
> Cheers
> Trond
Ok, I'll try to take a look at it next week since I head out of town
for the weekend starting this afternoon. If I run into any other
problems I'll check back with you guys. After that forward porting
shouldn't be much of an issue its just time consuming and unfortunately
my time is limited as of late.
T24gVGh1LCAyMDEyLTA0LTA1IGF0IDEzOjAyIC0wNDAwLCBEYXZpZCBRdWlnbGV5IHdyb3RlOg0K
PiBOb3cgdGhhdCB3ZSdyZSBwYXN0IHRoZSAzLjQgbWVyZ2Ugd2luZG93IHNob3VsZCBJIHBvc3Qg
dGhlIExORlMgDQo+IG1vZGlmaWNhdGlvbnMgZm9yIHJldmlldyBmb3Igd2hlbiAzLjUgcm9sbHMg
YXJvdW5kPw0KDQpUaGUgc29vbmVyIHRoZSBiZXR0ZXIuIEl0IGxvb2tzIGFzIGlmIHRoZXJlIHdp
bGwgYmUgcXVpdGUgYSBiaXQgb2Ygc3R1ZmYNCmdvaW5nIGludG8gMy41LCBzbyBpdCB3b3VsZCBi
ZSBuaWNlIHRvIG1heGltaXNlIG91ciB0ZXN0aW5nIHdpbmRvdy4NCg0KVGhhbmtzIQ0KICBUcm9u
ZA0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoN
Ck5ldEFwcA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQoNCg==
On 04/05/2012 17:26, David Quigley wrote:
> On 04/05/2012 13:15, Myklebust, Trond wrote:
>> On Thu, 2012-04-05 at 13:02 -0400, David Quigley wrote:
>>> Now that we're past the 3.4 merge window should I post the LNFS
>>> modifications for review for when 3.5 rolls around?
>>
>> The sooner the better. It looks as if there will be quite a bit of
>> stuff
>> going into 3.5, so it would be nice to maximise our testing window.
>>
>> Thanks!
>> Trond
>
> I have a mostly working copy for 3.2 which I can forward port but I'm
> having an issue with it. The revalidate code changed at some point
> and
> just to get things working I dropped a piece of code from the patch
> set that I couldn't figure out how to transition to the new
> revalidate
> code. Unfortunately this is the initial get of the security label so
> the security label is invalid until the first cache invalidation. Any
> suggestions on where to place this code? I can give you the original
> code snippet when I get home that I dropped.
>
> Dave
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Looking at my patches it looks like nfs_lookup_revalidate was changed
and at the time I couldn't figure out what it was changed to.
Dave
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYXZpZCBRdWlnbGV5IFttYWls
dG86ZHBxdWlnbEBkYXZlcXVpZ2xleS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNSwg
MjAxMiAyOjM4IFBNDQo+IFRvOiBNeWtsZWJ1c3QsIFRyb25kDQo+IENjOiBsaW51eC1uZnNAdmdl
ci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBBbm90aGVyIHRyeSBhdCBMTkZTPw0KPiANCj4g
T24gMDQvMDUvMjAxMiAxNzoyNiwgRGF2aWQgUXVpZ2xleSB3cm90ZToNCj4gPiBPbiAwNC8wNS8y
MDEyIDEzOjE1LCBNeWtsZWJ1c3QsIFRyb25kIHdyb3RlOg0KPiA+PiBPbiBUaHUsIDIwMTItMDQt
MDUgYXQgMTM6MDIgLTA0MDAsIERhdmlkIFF1aWdsZXkgd3JvdGU6DQo+ID4+PiBOb3cgdGhhdCB3
ZSdyZSBwYXN0IHRoZSAzLjQgbWVyZ2Ugd2luZG93IHNob3VsZCBJIHBvc3QgdGhlIExORlMNCj4g
Pj4+IG1vZGlmaWNhdGlvbnMgZm9yIHJldmlldyBmb3Igd2hlbiAzLjUgcm9sbHMgYXJvdW5kPw0K
PiA+Pg0KPiA+PiBUaGUgc29vbmVyIHRoZSBiZXR0ZXIuIEl0IGxvb2tzIGFzIGlmIHRoZXJlIHdp
bGwgYmUgcXVpdGUgYSBiaXQgb2YNCj4gPj4gc3R1ZmYgZ29pbmcgaW50byAzLjUsIHNvIGl0IHdv
dWxkIGJlIG5pY2UgdG8gbWF4aW1pc2Ugb3VyIHRlc3RpbmcNCj4gPj4gd2luZG93Lg0KPiA+Pg0K
PiA+PiBUaGFua3MhDQo+ID4+ICAgVHJvbmQNCj4gPg0KPiA+IEkgaGF2ZSBhIG1vc3RseSB3b3Jr
aW5nIGNvcHkgZm9yIDMuMiB3aGljaCBJIGNhbiBmb3J3YXJkIHBvcnQgYnV0IEknbQ0KPiA+IGhh
dmluZyBhbiBpc3N1ZSB3aXRoIGl0LiBUaGUgcmV2YWxpZGF0ZSBjb2RlIGNoYW5nZWQgYXQgc29t
ZSBwb2ludCBhbmQNCj4gPiBqdXN0IHRvIGdldCB0aGluZ3Mgd29ya2luZyBJIGRyb3BwZWQgYSBw
aWVjZSBvZiBjb2RlIGZyb20gdGhlIHBhdGNoDQo+ID4gc2V0IHRoYXQgSSBjb3VsZG4ndCBmaWd1
cmUgb3V0IGhvdyB0byB0cmFuc2l0aW9uIHRvIHRoZSBuZXcgcmV2YWxpZGF0ZQ0KPiA+IGNvZGUu
IFVuZm9ydHVuYXRlbHkgdGhpcyBpcyB0aGUgaW5pdGlhbCBnZXQgb2YgdGhlIHNlY3VyaXR5IGxh
YmVsIHNvDQo+ID4gdGhlIHNlY3VyaXR5IGxhYmVsIGlzIGludmFsaWQgdW50aWwgdGhlIGZpcnN0
IGNhY2hlIGludmFsaWRhdGlvbi4gQW55DQo+ID4gc3VnZ2VzdGlvbnMgb24gd2hlcmUgdG8gcGxh
Y2UgdGhpcyBjb2RlPyBJIGNhbiBnaXZlIHlvdSB0aGUgb3JpZ2luYWwNCj4gPiBjb2RlIHNuaXBw
ZXQgd2hlbiBJIGdldCBob21lIHRoYXQgSSBkcm9wcGVkLg0KPiA+DQo+ID4gRGF2ZQ0KPiA+IC0t
DQo+ID4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vi
c2NyaWJlIGxpbnV4LW5mcyINCj4gPiBpbg0KPiA+IHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBt
YWpvcmRvbW9Admdlci5rZXJuZWwub3JnIE1vcmUgbWFqb3Jkb21vDQo+IGluZm8NCj4gPiBhdCAg
aHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQo+IA0KPiBMb29raW5n
IGF0IG15IHBhdGNoZXMgaXQgbG9va3MgbGlrZSBuZnNfbG9va3VwX3JldmFsaWRhdGUgd2FzIGNo
YW5nZWQgYW5kIGF0DQo+IHRoZSB0aW1lIEkgY291bGRuJ3QgZmlndXJlIG91dCB3aGF0IGl0IHdh
cyBjaGFuZ2VkIHRvLg0KDQpIaSBEYXZlLA0KICBUaGVyZSBzaG91bGRuJ3QgYmUgbXVjaCBpbiB0
aGUgd2F5IG9mIGNoYW5nZXMgaW4gbmZzX2xvb2t1cF9yZXZhbGlkYXRlKCk6IEkgd2FzIGp1c3Qg
dHJ5aW5nIHRvIGNsZWFuIGl0IHVwIGluIHByZXBhcmF0aW9uIGZvciB0aGUgYXRvbWljIG9wZW4g
cGF0Y2hlcyB0aGF0IE1pa2xvcyBpcyBjdXJyZW50bHkgd29ya2luZyBvbi4NCkF0IHRoaXMgcG9p
bnQsIGl0IGxvb2tzIGFzIGlmIG1vc3Qgb2YgdGhhdCBmdW5jdGlvbmFsaXR5IHdpbGwgaW4gYW55
IGNhc2UgYmUgbW92ZWQgaW50byB0aGUgc3RydWN0IGZpbGVfb3BlcmF0aW9ucy0+b3BlbiBjYWxs
YmFjaywgc28gdGhhdCB3ZSBjYW4ga2VlcCAtPmRfcmV2YWxpZGF0ZSgpIGFzIGEgcHVyZSBsb29r
dXAgZnVuY3Rpb24uDQoNCkNoZWVycw0KICBUcm9uZA0K
T24gVHVlLCAyMDEyLTA1LTA4IGF0IDAxOjI0IC0wNDAwLCBEYXZlIFF1aWdsZXkgd3JvdGU6DQo+
IE9uIDQvNS8yMDEyIDEwOjIwIFBNLCBNeWtsZWJ1c3QsIFRyb25kIHdyb3RlOg0KPiA+PiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBEYXZpZCBRdWlnbGV5IFttYWlsdG86
ZHBxdWlnbEBkYXZlcXVpZ2xleS5jb21dDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNSwg
MjAxMiAyOjM4IFBNDQo+ID4+IFRvOiBNeWtsZWJ1c3QsIFRyb25kDQo+ID4+IENjOiBsaW51eC1u
ZnNAdmdlci5rZXJuZWwub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBBbm90aGVyIHRyeSBhdCBMTkZT
Pw0KPiA+Pg0KPiA+PiBPbiAwNC8wNS8yMDEyIDE3OjI2LCBEYXZpZCBRdWlnbGV5IHdyb3RlOg0K
PiA+Pj4gT24gMDQvMDUvMjAxMiAxMzoxNSwgTXlrbGVidXN0LCBUcm9uZCB3cm90ZToNCj4gPj4+
PiBPbiBUaHUsIDIwMTItMDQtMDUgYXQgMTM6MDIgLTA0MDAsIERhdmlkIFF1aWdsZXkgd3JvdGU6
DQo+ID4+Pj4+IE5vdyB0aGF0IHdlJ3JlIHBhc3QgdGhlIDMuNCBtZXJnZSB3aW5kb3cgc2hvdWxk
IEkgcG9zdCB0aGUgTE5GUw0KPiA+Pj4+PiBtb2RpZmljYXRpb25zIGZvciByZXZpZXcgZm9yIHdo
ZW4gMy41IHJvbGxzIGFyb3VuZD8NCj4gPj4+Pg0KPiA+Pj4+IFRoZSBzb29uZXIgdGhlIGJldHRl
ci4gSXQgbG9va3MgYXMgaWYgdGhlcmUgd2lsbCBiZSBxdWl0ZSBhIGJpdCBvZg0KPiA+Pj4+IHN0
dWZmIGdvaW5nIGludG8gMy41LCBzbyBpdCB3b3VsZCBiZSBuaWNlIHRvIG1heGltaXNlIG91ciB0
ZXN0aW5nDQo+ID4+Pj4gd2luZG93Lg0KPiA+Pj4+DQo+ID4+Pj4gVGhhbmtzIQ0KPiA+Pj4+ICAg
IFRyb25kDQo+ID4+Pg0KPiA+Pj4gSSBoYXZlIGEgbW9zdGx5IHdvcmtpbmcgY29weSBmb3IgMy4y
IHdoaWNoIEkgY2FuIGZvcndhcmQgcG9ydCBidXQgSSdtDQo+ID4+PiBoYXZpbmcgYW4gaXNzdWUg
d2l0aCBpdC4gVGhlIHJldmFsaWRhdGUgY29kZSBjaGFuZ2VkIGF0IHNvbWUgcG9pbnQgYW5kDQo+
ID4+PiBqdXN0IHRvIGdldCB0aGluZ3Mgd29ya2luZyBJIGRyb3BwZWQgYSBwaWVjZSBvZiBjb2Rl
IGZyb20gdGhlIHBhdGNoDQo+ID4+PiBzZXQgdGhhdCBJIGNvdWxkbid0IGZpZ3VyZSBvdXQgaG93
IHRvIHRyYW5zaXRpb24gdG8gdGhlIG5ldyByZXZhbGlkYXRlDQo+ID4+PiBjb2RlLiBVbmZvcnR1
bmF0ZWx5IHRoaXMgaXMgdGhlIGluaXRpYWwgZ2V0IG9mIHRoZSBzZWN1cml0eSBsYWJlbCBzbw0K
PiA+Pj4gdGhlIHNlY3VyaXR5IGxhYmVsIGlzIGludmFsaWQgdW50aWwgdGhlIGZpcnN0IGNhY2hl
IGludmFsaWRhdGlvbi4gQW55DQo+ID4+PiBzdWdnZXN0aW9ucyBvbiB3aGVyZSB0byBwbGFjZSB0
aGlzIGNvZGU/IEkgY2FuIGdpdmUgeW91IHRoZSBvcmlnaW5hbA0KPiA+Pj4gY29kZSBzbmlwcGV0
IHdoZW4gSSBnZXQgaG9tZSB0aGF0IEkgZHJvcHBlZC4NCj4gPj4+DQo+ID4+PiBEYXZlDQo+ID4+
PiAtLQ0KPiA+Pj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUg
InVuc3Vic2NyaWJlIGxpbnV4LW5mcyINCj4gPj4+IGluDQo+ID4+PiB0aGUgYm9keSBvZiBhIG1l
c3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZyBNb3JlIG1ham9yZG9tbw0KPiA+PiBp
bmZvDQo+ID4+PiBhdCAgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1s
DQo+ID4+DQo+ID4+IExvb2tpbmcgYXQgbXkgcGF0Y2hlcyBpdCBsb29rcyBsaWtlIG5mc19sb29r
dXBfcmV2YWxpZGF0ZSB3YXMgY2hhbmdlZCBhbmQgYXQNCj4gPj4gdGhlIHRpbWUgSSBjb3VsZG4n
dCBmaWd1cmUgb3V0IHdoYXQgaXQgd2FzIGNoYW5nZWQgdG8uDQo+ID4NCj4gPiBIaSBEYXZlLA0K
PiA+ICAgIFRoZXJlIHNob3VsZG4ndCBiZSBtdWNoIGluIHRoZSB3YXkgb2YgY2hhbmdlcyBpbiBu
ZnNfbG9va3VwX3JldmFsaWRhdGUoKTogSSB3YXMganVzdCB0cnlpbmcgdG8gY2xlYW4gaXQgdXAg
aW4gcHJlcGFyYXRpb24gZm9yIHRoZSBhdG9taWMgb3BlbiBwYXRjaGVzIHRoYXQgTWlrbG9zIGlz
IGN1cnJlbnRseSB3b3JraW5nIG9uLg0KPiA+IEF0IHRoaXMgcG9pbnQsIGl0IGxvb2tzIGFzIGlm
IG1vc3Qgb2YgdGhhdCBmdW5jdGlvbmFsaXR5IHdpbGwgaW4gYW55IGNhc2UgYmUgbW92ZWQgaW50
byB0aGUgc3RydWN0IGZpbGVfb3BlcmF0aW9ucy0+b3BlbiBjYWxsYmFjaywgc28gdGhhdCB3ZSBj
YW4ga2VlcCAtPmRfcmV2YWxpZGF0ZSgpIGFzIGEgcHVyZSBsb29rdXAgZnVuY3Rpb24uDQo+ID4N
Cj4gPiBDaGVlcnMNCj4gPiAgICBUcm9uZA0KPiANCj4gDQo+IE9rIEkgbG9va2VkIGF0IHRoZSBj
b2RlIGFnYWluIGZpbmFsbHkgYW5kIEkgdGhpbmsgSSBmaWd1cmVkIG91dCB0aGUgDQo+IHByb2Js
ZW0uIG5mc19wcmltZV9kY2FjaGUgaXMgbmV3IGFuZCB0aGVyZSBhcmUgYSBjb3VwbGUgb2YgY2Fs
bHMgaW4gDQo+IHRoZXJlIHRoYXQgc2hvdWxkIGJlIHRha2luZyBhIGxhYmVsIHRoYXQgSSBqdXN0
IHBhc3NlZCBudWxsIHRvLiBXZSBkb24ndCANCj4gc3RvcmUgdGhlIG5mczRfbGFiZWwgaW4gdGhl
IGlub2RlIHNvIEknbSBub3Qgc3VyZSBob3cgdG8gZ2V0IHRoZSBsYWJlbCANCj4gYmFjayBmb3Ig
dGhlIG5mc19yZWZyZXNoX2lub2RlIGNhbGwgYW5kIHRoZW4gd2UgaGF2ZSBhIGNhbGwgdG8gbmZz
X2ZoZ2V0IA0KPiB3aGljaCB3b3VsZCBub3JtYWxseSBnZXQgdXMgbGFiZWwgZGF0YS4gSSB0aGlu
ayB0aGUgbmF0dXJlIG9mIHRoaXMgDQo+IGZ1bmN0aW9uIGlzIHdoYXQgSSBkb24ndCBxdWl0ZSB1
bmRlcnN0YW5kLiBXaGVuIGlzIGl0IGNhbGxlZD8gV2hhdCBJIA0KPiB0aGluayBpcyBoYXBwZW5p
bmcgaXMgdGhhdCBJIHNob3VsZCBiZSBwdWxsaW5nIHRoZSBsYWJlbCBkYXRhIGludG8gdGhlIA0K
PiBpbm9kZSBpbiB0aGlzIGZ1bmN0aW9uIGJ1dCBJJ20gbm90IGJlY2F1c2UgSSdtIHBhc3Npbmcg
bnVsbHMgaGVyZS4gaWYgSSANCj4gZmlndXJlIG91dCBob3cgdG8gZ2V0IHJlYWwgbGFiZWwgZGF0
YSBpbnRvIHRoZSBpbm9kZSBhdCB0aGlzIHBvaW50IEkgDQo+IHNob3VsZCBiZSBhYmxlIHRvIGZp
eCB0aGUgYnVnIHdoZXJlIHdlIGFyZW4ndCBnZXR0aW5nIGxhYmVscyB1bnRpbCB0aGUgDQo+IGZp
cnN0IGNhY2hlIGludmFsaWRhdGlvbi4NCj4gDQo+IERhdmUNCg0KbmZzX3ByaW1lX2RjYWNoZSBp
cyBjYWxsZWQgYWZ0ZXIgYSBSRUFERElSUExVUyBvcGVyYXRpb24uIEluIHRoZSBjYXNlIG9mDQpO
RlN2NCwgdGhhdCBtZWFucyB0aGF0IHdlIHJlcXVlc3QgYSBmaWxlaGFuZGxlIGFuZCBmdWxsIGZp
bGUgYXR0cmlidXRlcw0KaW4gb3VyIFJFQURESVIgb3BlcmF0aW9uLiBXZSB0aGVuIHVzZSB0aGUg
cmVzdWx0cyB0byBjcmVhdGUgZGVudHJpZXMNCnRoYXQgd2UgdGhlbiBwb3B1bGF0ZSB0aGUgZGNh
Y2hlIHdpdGg6DQpJT1c6IGFzIGZhciBhcyB0aGUgVkZTIGlzIGNvbmNlcm5lZCwgaXQgbG9va3Mg
YXMgaWYgd2UndmUgZG9uZSBhIGJ1bmNoDQpvZiBsb29rdXBzIG9mIHRoZXNlIGZpbGVzLg0KDQot
LSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFw
cA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQoNCg==
On 4/5/2012 10:20 PM, Myklebust, Trond wrote:
>> -----Original Message-----
>> From: David Quigley [mailto:[email protected]]
>> Sent: Thursday, April 05, 2012 2:38 PM
>> To: Myklebust, Trond
>> Cc: [email protected]
>> Subject: Re: Another try at LNFS?
>>
>> On 04/05/2012 17:26, David Quigley wrote:
>>> On 04/05/2012 13:15, Myklebust, Trond wrote:
>>>> On Thu, 2012-04-05 at 13:02 -0400, David Quigley wrote:
>>>>> Now that we're past the 3.4 merge window should I post the LNFS
>>>>> modifications for review for when 3.5 rolls around?
>>>>
>>>> The sooner the better. It looks as if there will be quite a bit of
>>>> stuff going into 3.5, so it would be nice to maximise our testing
>>>> window.
>>>>
>>>> Thanks!
>>>> Trond
>>>
>>> I have a mostly working copy for 3.2 which I can forward port but I'm
>>> having an issue with it. The revalidate code changed at some point and
>>> just to get things working I dropped a piece of code from the patch
>>> set that I couldn't figure out how to transition to the new revalidate
>>> code. Unfortunately this is the initial get of the security label so
>>> the security label is invalid until the first cache invalidation. Any
>>> suggestions on where to place this code? I can give you the original
>>> code snippet when I get home that I dropped.
>>>
>>> Dave
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
>>> in
>>> the body of a message to [email protected] More majordomo
>> info
>>> at http://vger.kernel.org/majordomo-info.html
>>
>> Looking at my patches it looks like nfs_lookup_revalidate was changed and at
>> the time I couldn't figure out what it was changed to.
>
> Hi Dave,
> There shouldn't be much in the way of changes in nfs_lookup_revalidate(): I was just trying to clean it up in preparation for the atomic open patches that Miklos is currently working on.
> At this point, it looks as if most of that functionality will in any case be moved into the struct file_operations->open callback, so that we can keep ->d_revalidate() as a pure lookup function.
>
> Cheers
> Trond
Ok I looked at the code again finally and I think I figured out the
problem. nfs_prime_dcache is new and there are a couple of calls in
there that should be taking a label that I just passed null to. We don't
store the nfs4_label in the inode so I'm not sure how to get the label
back for the nfs_refresh_inode call and then we have a call to nfs_fhget
which would normally get us label data. I think the nature of this
function is what I don't quite understand. When is it called? What I
think is happening is that I should be pulling the label data into the
inode in this function but I'm not because I'm passing nulls here. if I
figure out how to get real label data into the inode at this point I
should be able to fix the bug where we aren't getting labels until the
first cache invalidation.
Dave
On 05/08/2012 10:46, Myklebust, Trond wrote:
> On Tue, 2012-05-08 at 01:24 -0400, Dave Quigley wrote:
>> On 4/5/2012 10:20 PM, Myklebust, Trond wrote:
>> >> -----Original Message-----
>> >> From: David Quigley [mailto:[email protected]]
>> >> Sent: Thursday, April 05, 2012 2:38 PM
>> >> To: Myklebust, Trond
>> >> Cc: [email protected]
>> >> Subject: Re: Another try at LNFS?
>> >>
>> >> On 04/05/2012 17:26, David Quigley wrote:
>> >>> On 04/05/2012 13:15, Myklebust, Trond wrote:
>> >>>> On Thu, 2012-04-05 at 13:02 -0400, David Quigley wrote:
>> >>>>> Now that we're past the 3.4 merge window should I post the
>> LNFS
>> >>>>> modifications for review for when 3.5 rolls around?
>> >>>>
>> >>>> The sooner the better. It looks as if there will be quite a bit
>> of
>> >>>> stuff going into 3.5, so it would be nice to maximise our
>> testing
>> >>>> window.
>> >>>>
>> >>>> Thanks!
>> >>>> Trond
>> >>>
>> >>> I have a mostly working copy for 3.2 which I can forward port
>> but I'm
>> >>> having an issue with it. The revalidate code changed at some
>> point and
>> >>> just to get things working I dropped a piece of code from the
>> patch
>> >>> set that I couldn't figure out how to transition to the new
>> revalidate
>> >>> code. Unfortunately this is the initial get of the security
>> label so
>> >>> the security label is invalid until the first cache
>> invalidation. Any
>> >>> suggestions on where to place this code? I can give you the
>> original
>> >>> code snippet when I get home that I dropped.
>> >>>
>> >>> Dave
>> >>> --
>> >>> To unsubscribe from this list: send the line "unsubscribe
>> linux-nfs"
>> >>> in
>> >>> the body of a message to [email protected] More
>> majordomo
>> >> info
>> >>> at http://vger.kernel.org/majordomo-info.html
>> >>
>> >> Looking at my patches it looks like nfs_lookup_revalidate was
>> changed and at
>> >> the time I couldn't figure out what it was changed to.
>> >
>> > Hi Dave,
>> > There shouldn't be much in the way of changes in
>> nfs_lookup_revalidate(): I was just trying to clean it up in
>> preparation for the atomic open patches that Miklos is currently
>> working on.
>> > At this point, it looks as if most of that functionality will in
>> any case be moved into the struct file_operations->open callback, so
>> that we can keep ->d_revalidate() as a pure lookup function.
>> >
>> > Cheers
>> > Trond
>>
>>
>> Ok I looked at the code again finally and I think I figured out the
>> problem. nfs_prime_dcache is new and there are a couple of calls in
>> there that should be taking a label that I just passed null to. We
>> don't
>> store the nfs4_label in the inode so I'm not sure how to get the
>> label
>> back for the nfs_refresh_inode call and then we have a call to
>> nfs_fhget
>> which would normally get us label data. I think the nature of this
>> function is what I don't quite understand. When is it called? What I
>> think is happening is that I should be pulling the label data into
>> the
>> inode in this function but I'm not because I'm passing nulls here.
>> if I
>> figure out how to get real label data into the inode at this point I
>> should be able to fix the bug where we aren't getting labels until
>> the
>> first cache invalidation.
>>
>> Dave
>
> nfs_prime_dcache is called after a READDIRPLUS operation. In the case
> of
> NFSv4, that means that we request a filehandle and full file
> attributes
> in our READDIR operation. We then use the results to create dentries
> that we then populate the dcache with:
> IOW: as far as the VFS is concerned, it looks as if we've done a
> bunch
> of lookups of these files.
Does it seem like this might be the problem area though or am I barking
up the wrong tree? I could look through my porting again and make sure I
didn't miss anything but that would take a lot of time I don't have at
the moment. I have a telecon tonight at 9pm with some people in Asia who
want to help with development so I may have them look into this bug and
try to take care of it. After that it should just be a forward port to
3.5/3.6.
Dave