Hi Linus,
Please pull from the signed tag "nfs-for-3.4-2" in the repository at
git pull git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tag nfs-for-3.4-2
This will update the following files through the appended changesets.
Cheers,
Trond
----
fs/nfs/nfs4filelayout.c | 1 -
fs/nfs/nfs4proc.c | 43 +++++++++++++++++++++++--------------------
net/sunrpc/rpcb_clnt.c | 2 +-
3 files changed, 24 insertions(+), 22 deletions(-)
commit 14977489ffdb80d4caf5a184ba41b23b02fbacd9
Author: Trond Myklebust <[email protected]>
Date: Tue Mar 27 18:31:25 2012 -0400
NFSv4: Minor cleanups for nfs4_handle_exception and nfs4_async_handle_error
Signed-off-by: Trond Myklebust <[email protected]>
commit e59d27e05a6435f8c04d5ad843f37fa795f2eaaa
Author: Trond Myklebust <[email protected]>
Date: Tue Mar 27 18:22:19 2012 -0400
NFSv4.1: Fix layoutcommit error handling
Firstly, task->tk_status will always return negative error values,
so the current tests for 'NFS4ERR_DELEG_REVOKED' etc. are all being
ignored.
Secondly, clean up the code so that we only need to test
task->tk_status once!
Signed-off-by: Trond Myklebust <[email protected]>
Cc: [email protected]
commit 05e9cfb408b24debb3a85fd98edbfd09dd148881
Author: Trond Myklebust <[email protected]>
Date: Tue Mar 27 18:13:02 2012 -0400
NFSv4: Fix two infinite loops in the mount code
We can currently loop forever in nfs4_lookup_root() and in
nfs41_proc_secinfo_no_name(), if the first iteration returns a
NFS4ERR_DELAY or something else that causes exception.retry to get
set.
Reported-by: Weston Andros Adamson <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Cc: [email protected]
commit 864cf9bf99f62d2095c8e6cc3a87af80b263984e
Author: Bryan Schumaker <[email protected]>
Date: Tue Mar 27 13:46:32 2012 -0400
SUNRPC: Use the already looked-up xprt in rpcb_getport_async()
rbcb_getport_async() was looking up the rpc_xprt (reference++) and then
later looking it up again (reference++) to pass through the
rpcbind_args. The xprt would only be dereferenced once, when we were
done with the rpcbind_args (reference--). This leaves an extra
reference to the transport that would never go away.
Signed-off-by: Bryan Schumaker <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit d44fc387997c0750125cfb0c2c803a3171b649f4
Author: Fred Isaman <[email protected]>
Date: Thu Mar 22 01:39:34 2012 -0400
NFS4.1: remove duplicate variable declaration in filelayout_clear_request_commit
inode is declared twice for no good reason
Signed-off-by: Fred Isaman <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
commit 20e0fa98b751facf9a1101edaefbc19c82616a68
Author: Sachin Prabhu <[email protected]>
Date: Thu Mar 22 16:46:28 2012 +0000
Fix length of buffer copied in __nfs4_get_acl_uncached
_copy_from_pages() used to copy data from the temporary buffer to the
user passed buffer is passed the wrong size parameter when copying
data. res.acl_len contains both the bitmap and acl lenghts while
acl_len contains the acl length after adjusting for the bitmap size.
Signed-off-by: Sachin Prabhu <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On Wed, 2012-03-28 at 19:20 -0700, Linus Torvalds wrote:
> On Wed, Mar 28, 2012 at 7:08 PM, Myklebust, Trond
> <[email protected]> wrote:
> >
> > Sure thing... I wasn't aware of that semantic difference, but I'm quite
> > happy to add it to my script...
>
> Thanks. And I noticed that it's supposed to be "tags/xyz" with a "s".
>
> Of course, you might as well just say "xyz" without mentioning the
> tag[s] part at all, unless you have a branch with the same name and
> want to explicitly disambiguate.
>
> Linus
The reason for adding the 'tags' label originally was precisely because
I had an identically named branch, and I wanted to be able to send you
the signed tag instead.
I've attached the script that I use to generate pull requests just in
case someone else doesn't have their own version. It should be fairly
obvious to modify...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On Wed, Mar 28, 2012 at 6:59 PM, Myklebust, Trond
<[email protected]> wrote:
>
> Please pull from the signed tag "nfs-for-3.4-2" in the repository at
>
> ? git pull git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tag nfs-for-3.4-2
Btw, please change your pull request to say "tag/nfs-for-3.4-2"
instead of "tag nfs-for-3.4-2".
Both work, but there's a subtle difference: the "pull tag xyz" is
basically asking me to not just pull, but also add the tag to my set
of tags, which I'm not interested in. In contrast "pull tag/xyz" asks
me to just pull the tag contents.
Anyway, pulled.
Linus
On 03/28/2012 07:28 PM, Myklebust, Trond wrote:
> On Wed, 2012-03-28 at 19:20 -0700, Linus Torvalds wrote:
>> On Wed, Mar 28, 2012 at 7:08 PM, Myklebust, Trond
>> <[email protected]> wrote:
>>>
>>> Sure thing... I wasn't aware of that semantic difference, but I'm quite
>>> happy to add it to my script...
>>
>> Thanks. And I noticed that it's supposed to be "tags/xyz" with a "s".
>>
>> Of course, you might as well just say "xyz" without mentioning the
>> tag[s] part at all, unless you have a branch with the same name and
>> want to explicitly disambiguate.
>>
>> Linus
>
> The reason for adding the 'tags' label originally was precisely because
> I had an identically named branch, and I wanted to be able to send you
> the signed tag instead.
>
> I've attached the script that I use to generate pull requests just in
> case someone else doesn't have their own version. It should be fairly
> obvious to modify...
>
That's funny after my 20th time of running the command by hand and
doing a "man git-request-pull" because I can never remember the order
of things, and I always get the URL wrong 3 times, I decided I should write
a script, boom here it is sent on the mailing list.
Thank you Trond for sharing, here is a new user
Boaz
T24gV2VkLCAyMDEyLTAzLTI4IGF0IDE5OjA2IC0wNzAwLCBMaW51cyBUb3J2YWxkcyB3cm90ZToN
Cj4gT24gV2VkLCBNYXIgMjgsIDIwMTIgYXQgNjo1OSBQTSwgTXlrbGVidXN0LCBUcm9uZA0KPiA8
VHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20+IHdyb3RlOg0KPiA+DQo+ID4gUGxlYXNlIHB1bGwg
ZnJvbSB0aGUgc2lnbmVkIHRhZyAibmZzLWZvci0zLjQtMiIgaW4gdGhlIHJlcG9zaXRvcnkgYXQN
Cj4gPg0KPiA+ICAgZ2l0IHB1bGwgZ2l0Oi8vZ2l0LmxpbnV4LW5mcy5vcmcvcHJvamVjdHMvdHJv
bmRteS9saW51eC1uZnMuZ2l0IHRhZyBuZnMtZm9yLTMuNC0yDQo+IA0KPiBCdHcsIHBsZWFzZSBj
aGFuZ2UgeW91ciBwdWxsIHJlcXVlc3QgdG8gc2F5ICJ0YWcvbmZzLWZvci0zLjQtMiINCj4gaW5z
dGVhZCBvZiAidGFnIG5mcy1mb3ItMy40LTIiLg0KPiANCj4gQm90aCB3b3JrLCBidXQgdGhlcmUn
cyBhIHN1YnRsZSBkaWZmZXJlbmNlOiB0aGUgInB1bGwgdGFnIHh5eiIgaXMNCj4gYmFzaWNhbGx5
IGFza2luZyBtZSB0byBub3QganVzdCBwdWxsLCBidXQgYWxzbyBhZGQgdGhlIHRhZyB0byBteSBz
ZXQNCj4gb2YgdGFncywgd2hpY2ggSSdtIG5vdCBpbnRlcmVzdGVkIGluLiBJbiBjb250cmFzdCAi
cHVsbCB0YWcveHl6IiBhc2tzDQo+IG1lIHRvIGp1c3QgcHVsbCB0aGUgdGFnIGNvbnRlbnRzLg0K
DQpTdXJlIHRoaW5nLi4uIEkgd2Fzbid0IGF3YXJlIG9mIHRoYXQgc2VtYW50aWMgZGlmZmVyZW5j
ZSwgYnV0IEknbSBxdWl0ZQ0KaGFwcHkgdG8gYWRkIGl0IHRvIG15IHNjcmlwdC4uLg0KDQotLSAN
ClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFwcA0K
VHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQoNCg==
T24gV2VkLCAyMDEyLTAzLTI4IGF0IDIwOjQ0IC0wNzAwLCBMaW51cyBUb3J2YWxkcyB3cm90ZToN
Cj4gT24gV2VkLCBNYXIgMjgsIDIwMTIgYXQgODoxNyBQTSwgQm9heiBIYXJyb3NoIDxiaGFycm9z
aEBwYW5hc2FzLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBUaGFuayB5b3UgVHJvbmQgZm9yIHNoYXJp
bmcsIGhlcmUgaXMgYSBuZXcgdXNlcg0KPiANCj4gT2gsICpwbGVhc2UqIHVzZSBnaXQgcHVsbC1y
ZXF1ZXN0IGluc3RlYWQuIEl0IGRvZXMgYSBsb3Qgb2YgdGhpbmdzDQo+IG11Y2ggYmV0dGVyLCBp
bmNsdWRpbmcgdGhlIGRpZmZzdGF0L3Nob3J0bG9nIGFuZCB0aGUgdGFnIG1lc3NhZ2UsIG5vbmUN
Cj4gb2Ygd2hpY2ggVHJvbmQncyBkb2VzLg0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgIExp
bnVzDQoNCk1heWJlIEknbSBydW5uaW5nIGFuIG9sZGVyIHZlcnNpb24gb2YgZ2l0IChGZWRvcmEg
MTYgbGF0ZXN0IHVwZGF0ZSksIGJ1dA0Kd2hlbiBJIGRvDQoNCmdpdCByZXF1ZXN0LXB1bGwgdjMu
MyBnaXQ6Ly9naXQubGludXgtbmZzLm9yZy9wcm9qZWN0cy90cm9uZG15L2xpbnV4LW5mcy5naXQg
bmZzLWZvci0zLjQtMQ0KDQpJIGdldDoNCg0KICAgICAgICAgICAgICAgIFRoZSBmb2xsb3dpbmcg
Y2hhbmdlcyBzaW5jZSBjb21taXQgYzE2ZmE0ZjJhZDE5OTA4YTQ3YzYzZDhmYTQzNmExMTc4NDM4
YzdlNzoNCiAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgIExpbnV4IDMuMyAoMjAx
Mi0wMy0xOCAxNjoxNTozNCAtMDcwMCkNCiAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg
ICBhcmUgYXZhaWxhYmxlIGluIHRoZSBnaXQgcmVwb3NpdG9yeSBhdDoNCiAgICAgICAgICAgICAg
ICAgIGdpdDovL2dpdC5saW51eC1uZnMub3JnL3Byb2plY3RzL3Ryb25kbXkvbGludXgtbmZzLmdp
dCAuLkJSQU5DSC5OT1QuVkVSSUZJRUQuLg0KICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg
ICAgIEFuZHkgQWRhbXNvbiAoNCk6DQogICAgICAgICAgICAgICAgICAgICAgU1VOUlBDOiBhZGQg
c2VuZGluZyxwZW5kaW5nIHF1ZXVlIGFuZCBtYXggc2xvdCB0byB4cHJ0IHN0YXRzDQogICAgICAg
ICAgICAgICAgICAgICAgTkZTdjQuMSBzZXQgaGlnaGVzdF91c2VkX3Nsb3RpZCB0byBORlM0X05P
X1NMT1QNCiAgICAgICAgICAgICAgICAgICAgICBORlN2NC4xIGhhbmRsZSBEUyBzdGF0ZWlkIGVy
cm9ycw0KICAgICAgICAgICAgICAgICAgICAgIE5GU3Y0LjEgY2xlYW51cCBEUyBzdGF0ZWlkIGVy
cm9yIGhhbmRsaW5nDQogICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgLi4uLg0KICAg
ICAgICAgICAgICAgIGxvdHMgb2Ygc2hvcnRsb2cgc3R1ZmYgZm9sbG93ZWQgYnkgdGhlIGRpZmZz
dGF0Lg0KICAgICAgICAgICAgICAgIC4uLi4NCg0KYW5kIHRoYXQncyBhbGwuLi4NCg0KDQpJJ20g
cHJldHR5IHN1cmUgdGhhdCBhIHJlcXVlc3QgdG8gcHVsbCBmcm9tICIuLkJSQU5DSC5OT1QuVkVS
SUZJRUQuLiINCndvdWxkIHBpc3MgeW91IG9mZiwgd2hpY2ggaXMgd2h5IEknbGwgc3RpY2sgdG8g
bXkgc2NyaXB0IGZvciBub3cuIEl0DQphbHJlYWR5IGhhcyBhICctcycgb3B0aW9uIHRvIGdpdmUg
eW91IHRoZSBzaG9ydGxvZywgYW5kIGl0IHdpbGwgZ2l2ZSB5b3UNCnRoZSBkaWZmc3RhdCBieSBk
ZWZhdWx0LiBBbGwgaXQgaXMgbWlzc2luZyBpcyB0aGUgdGFnIG1lc3NhZ2UuLi4NCg0KLS0gDQpU
cm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRy
b25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0KDQo=
On Mar 29, 2012, at 12:20 AM, Linus Torvalds wrote:
> On Wed, Mar 28, 2012 at 9:08 PM, Myklebust, Trond
> <[email protected]> wrote:
>>
>> Maybe I'm running an older version of git (Fedora 16 latest update), but
>> when I do
>
> Yeah, you need git 1.7.9 to get the tag content support.
>
> With older git versions, spell out "tags/xyz" instead of just "xyz",
> and it will all work, but it still won't actually show the tag
> content.
When I do the tags/nfs-for-3.4-1, it still gives me that ..BRANCH.NOT.VERIFIED.. crap in the pull message.
Furthermore, it fails to actually push the tag to my upstream repository, meaning that I'm still prone to the 'Linus tried to pull, and the commit wasn't there" syndrome.
Could we perhaps set up a best practices webpage/wiki for this sort of thing with a pointer to that webpage in Documentations/SubmittingPatches? That way maintainers would have a source of information for which versions of 'git' that they need to use in order to provide you with the information that you want.
Cheers
Trond
On Wed, Mar 28, 2012 at 9:08 PM, Myklebust, Trond
<[email protected]> wrote:
>
> Maybe I'm running an older version of git (Fedora 16 latest update), but
> when I do
Yeah, you need git 1.7.9 to get the tag content support.
With older git versions, spell out "tags/xyz" instead of just "xyz",
and it will all work, but it still won't actually show the tag
content.
Linus
On Wed, Mar 28, 2012 at 8:17 PM, Boaz Harrosh <[email protected]> wrote:
>
> Thank you Trond for sharing, here is a new user
Oh, *please* use git pull-request instead. It does a lot of things
much better, including the diffstat/shortlog and the tag message, none
of which Trond's does.
Linus
On Wed, Mar 28, 2012 at 9:38 PM, Myklebust, Trond
<[email protected]> wrote:
>
> When I do the tags/nfs-for-3.4-1, it still gives me that ..BRANCH.NOT.VERIFIED.. crap in the pull message.
Hmm. Maybe it does end up only working for a branch in the pre-1.7.9
days. I haven't tested - I don't use old git versions.
> Furthermore, it fails to actually push the tag to my upstream repository, meaning that I'm still prone to the 'Linus tried to pull, and the commit wasn't there" syndrome.
Well, that's a separate issue. Yes, you obviously need to push first.
I would not object to you scripting the "push before pull request". I
just object to people using a script that is *worse* than what git
actually contains natively to actually generate the pull request.
> Could we perhaps set up a best practices webpage/wiki for this sort of thing with a pointer to that webpage in Documentations/SubmittingPatches? That way maintainers would have a source of information for which versions of 'git' that they need to use in order to provide you with the information that you want.
The nice signed tag understanding came in 1.7.9. But I actually
seriously suggest that all kernel developers use something even more
recent than that, since what changes in 1.7.10 (not released yet, but
the git 'master' branch is at rc3 now) is the extremely nice "make
people actually explain their merges" change.
There have been kernel developers that apparently never even noticed
that they were creating extraneous merges, so I really encourage
everybody to upgrade to current pre-1.7.10 git just so that you are
asked to write a nice merge message when you create a merge. That's
totally independent of the signed tag issue and the nice pull-request
format, though.
And it really is *trivial* to use a modern git instead of whatever
distro version you have. It's literally:
git clone git://github.com/gitster/git
cd git
make
make install
all as a *regular*user* (do not 'sudo make install'!). That installs
git in your own ~/bin directory, there's no fighting with whatever
distro git versions. No need to uninstall things or worry about
/usr/local or anything like that.
The git master branch is extremely stable, it's not very scary at all
to be up-to-date. And it's almost always better than whatever distro
version you have, and as seen above it really isn't hard to do. You
may need to install a few libraries, but git doesn't really even have
very complex dependencies. The two that might bite some people is the
need for the curl-devel and expat-devel packages.
(If you don't have any development environment at *all*, you need to
install gcc, make, zlib-devel, openssl-devel, and gettext, but those
tend to be in the development base, so you almost certainly already
have them)
Obviously you then need to have something like
PATH="$(HOME)/bin:$PATH"
in your .bashrc to make sure that your own private binaries override
the system ones, but hey, that's just a good idea regardless if you
are a developer and ever want to use your own programs.
Linus
On Wed, Mar 28, 2012 at 7:08 PM, Myklebust, Trond
<[email protected]> wrote:
>
> Sure thing... I wasn't aware of that semantic difference, but I'm quite
> happy to add it to my script...
Thanks. And I noticed that it's supposed to be "tags/xyz" with a "s".
Of course, you might as well just say "xyz" without mentioning the
tag[s] part at all, unless you have a branch with the same name and
want to explicitly disambiguate.
Linus