date:20180517

Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?

2018-05-17 Thread Moritz Schlarb

Hi Chuck,

On 17.05.2018 16:15, Chuck Lever wrote:

> Just a shot in the dark: Wondering if v3.16 needs
> 
> commit ea96d1ecbe4fcb1df487d99309d3157b4ff5fc02
> Author: Anna Schumaker 
> AuthorDate: Fri Apr 3 14:35:59 2015 -0400
> Commit: Trond Myklebust 
> CommitDate: Thu Apr 23 14:43:54 2015 -0400
> 
> nfs: Fetch MOUNTED_ON_FILEID when updating an inode

Gosh, it seems you're right!
When I take that patch and apply it, the referrals are being followed again!

Thanks for your idea!
Now how do we make sure it gets applied soonish?

Regards,
Moritz

Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?

2018-05-17 Thread Chuck Lever



> On May 17, 2018, at 3:53 AM, Moritz Schlarb  wrote:
> 
> Hi everyone,
> 
> there might be a regression coming from this patch:
> Since it got included in 3.16.54, our clients running a recent 3.16
> kernel (like from Debian jessie-security) did not follow NFS 4.1
> referrals (issued by nfs-ganesha) anymore.
> I have built that exact Debian kernel package with just this patch
> reversed and it worked again, so I got pretty confident that this patch
> is at least strongly related to the problem.
> Pradeep also confirmed the problem happening in 3.16.54 but not in 3.16.51.
> Interestingly, this does *not* happen with 4.9 kernels, although the
> patch was part of 4.9.80...
> 
> I have attached a pcap file of a machine running 3.16.56-1+deb8u1 in
> which I try to login as a user where my home directory is
> /uni-mainz.de/homes/schlarbm (with nfsrefer.zdv.uni-mainz.de:/ on
> /uni-mainz.de) which is then referred to
> fs02.uni-mainz.de:/vol/ma17/homes/schlarbm but that referral is not
> followed by the client.
> 
> Please let me know if you need additional information to reproduce or
> have suggestions on what we could try.

Just a shot in the dark: Wondering if v3.16 needs

commit ea96d1ecbe4fcb1df487d99309d3157b4ff5fc02
Author: Anna Schumaker 
AuthorDate: Fri Apr 3 14:35:59 2015 -0400
Commit: Trond Myklebust 
CommitDate: Thu Apr 23 14:43:54 2015 -0400

nfs: Fetch MOUNTED_ON_FILEID when updating an inode


> Best regards,
> Moritz
> 
> On 05.11.2017 21:45, Chuck Lever wrote:
>> Before traversing a referral and performing a mount, the mounted-on
>> directory looks strange:
>> 
>> dr-xr-xr-x. 2 4294967294 4294967294 0 Dec 31  1969 dir.0
>> 
>> nfs4_get_referral is wiping out any cached attributes with what was
>> returned via GETATTR(fs_locations), but the bit mask for that
>> operation does not request any file attributes.
>> 
>> Retrieve owner and timestamp information so that the memcpy in
>> nfs4_get_referral fills in more attributes.
>> 
>> Changes since v1:
>> - Don't request attributes that the client unconditionally replaces
>> - Request only MOUNTED_ON_FILEID or FILEID attribute, not both
>> - encode_fs_locations() doesn't use the third bitmask word
>> 
>> Fixes: 6b97fd3da1ea ("NFSv4: Follow a referral")
>> Suggested-by: Pradeep Thomas 
>> Signed-off-by: Chuck Lever 
>> Cc: sta...@vger.kernel.org
>> ---
>> fs/nfs/nfs4proc.c |   18 --
>> 1 file changed, 8 insertions(+), 10 deletions(-)
>> 
>> I could send this as an incremental, but that just seems to piss
>> off distributors, who will just squash them all together anyway.
>> 
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
>> index 6c61e2b..2662879 100644
>> --- a/fs/nfs/nfs4proc.c
>> +++ b/fs/nfs/nfs4proc.c
>> @@ -254,15 +254,12 @@ static int nfs4_map_errors(int err)
>> };
>> 
>> const u32 nfs4_fs_locations_bitmap[3] = {
>> -FATTR4_WORD0_TYPE
>> -| FATTR4_WORD0_CHANGE
>> +FATTR4_WORD0_CHANGE
>>  | FATTR4_WORD0_SIZE
>>  | FATTR4_WORD0_FSID
>>  | FATTR4_WORD0_FILEID
>>  | FATTR4_WORD0_FS_LOCATIONS,
>> -FATTR4_WORD1_MODE
>> -| FATTR4_WORD1_NUMLINKS
>> -| FATTR4_WORD1_OWNER
>> +FATTR4_WORD1_OWNER
>>  | FATTR4_WORD1_OWNER_GROUP
>>  | FATTR4_WORD1_RAWDEV
>>  | FATTR4_WORD1_SPACE_USED
>> @@ -6763,9 +6760,7 @@ static int _nfs4_proc_fs_locations(struct rpc_clnt 
>> *client, struct inode *dir,
>> struct page *page)
>> {
>>  struct nfs_server *server = NFS_SERVER(dir);
>> -u32 bitmask[3] = {
>> -[0] = FATTR4_WORD0_FSID | FATTR4_WORD0_FS_LOCATIONS,
>> -};
>> +u32 bitmask[3];
>>  struct nfs4_fs_locations_arg args = {
>>  .dir_fh = NFS_FH(dir),
>>  .name = name,
>> @@ -6784,12 +6779,15 @@ static int _nfs4_proc_fs_locations(struct rpc_clnt 
>> *client, struct inode *dir,
>> 
>>  dprintk("%s: start\n", __func__);
>> 
>> +bitmask[0] = nfs4_fattr_bitmap[0] | FATTR4_WORD0_FS_LOCATIONS;
>> +bitmask[1] = nfs4_fattr_bitmap[1];
>> +
>>  /* Ask for the fileid of the absent filesystem if mounted_on_fileid
>>   * is not supported */
>>  if (NFS_SERVER(dir)->attr_bitmask[1] & FATTR4_WORD1_MOUNTED_ON_FILEID)
>> -bitmask[1] |= FATTR4_WORD1_MOUNTED_ON_FILEID;
>> +bitmask[0] &= ~FATTR4_WORD0_FILEID;
>>  else
>> -bitmask[0] |= FATTR4_WORD0_FILEID;
>> +bitmask[1] &= ~FATTR4_WORD1_MOUNTED_ON_FILEID;
>> 
>>  nfs_fattr_init(_locations->fattr);
>>  fs_locations->server = server;
>> 
> 

--
Chuck Lever

Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail

2018-05-17 Thread Holger Schröder


Any news to fix this behavior?


Greetings...

Bug#898907: ethtool -K tso setting output noise msg "Cannot get device udp-fragmentation-offload settings: Operation not supported"

2018-05-17 Thread Xinliang Liu

Package: ethtool
Version: 1:4.8-1+b1

# uname -a
Linux debian 4.16.0-0.bpo.1-arm64 #1 SMP Debian 4.16.5-1~bpo9+1
(2018-05-06) aarch64 GNU/Linux

udp-fragmentation-offload is remove by the kernel.
ethtool should remvoe it. related patch link:
http://patchwork.ozlabs.org/patch/814796/

debian ethtool doesn't remove udp-fragmentation-offload. When setting
tso, it does can set, but it will output noise msg:

# ethtool -K eth0 tso on
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
# ethtool -k eth0
Features for eth0:
Cannot get device udp-fragmentation-offload settings: Operation not supported
.
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: on
tx-tcp6-segmentation: on
..

# ethtool -K eth0 tso off
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported

# ethtool -k eth0
Features for eth0:
Cannot get device udp-fragmentation-offload settings: Operation not supported
.
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off

Bug#862013: initramfs-tools-core: /run tmpfs size hardcoded at 10% RAM, but 16.0 MiB free required in /run/systemd

2018-05-17 Thread Benjamin Drung

Hi,

Using 10% of RAM for /run is a good default, but not suitable for all
systems. 10% might be too small for system with less memory (e.g.
virtual machine with 160 MiB RAM) or too big (VM host with 256/512 GiB
RAM). A too small /run partition leads to not enough space on it. If
the
/run partition is huge, systemd's journald will consume lot of memory,
because it defaults to using at most 15% of the respective file system
of /run/log/journal.

Adjusting the size of /run via an entry in /etc/fstab is not sufficient
since journald calculates it limits before systemd remounts /run with
the small size. Therefore journald could occupy the full /run partition
with its logs.

Allow specifying the size of /run by adding a RUNSIZE configuration
variable and a ramsize= boot argument. Mounting /run must be done after
reading the configuration.

A tested patch is attached and I created a merge proposal:
https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/2

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL: https://www.profitbricks.de

Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B
Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph SteffensFrom 6569b72cad0145843b55022fa6bc9e00a75a6d79 Mon Sep 17 00:00:00 2001
From: Benjamin Drung 
Date: Tue, 15 May 2018 12:12:56 +0200
Subject: [PATCH] Make size of /run configurable

Using 10% of RAM for /run is a good default, but not suitable for all
systems. 10% might be too small for system with less memory (e.g.
virtual machine with 160 MiB RAM) or too big (VM host with 256/512 GiB
RAM). A too small /run partition leads to not enough space on it. If the
/run partition is huge, systemd's journald will consume lot of memory,
because it defaults to using at most 15% of the respective file system
of /run/log/journal.

Adjusting the size of /run via an entry in /etc/fstab is not sufficient
since journald calculates it limits before systemd remounts /run with
the small size. Therefore journald could occupy the full /run partition
with its logs.

Allow specifying the size of /run by adding a RUNSIZE configuration
variable and a ramsize= boot argument. Mounting /run must be done after
reading the configuration.

Closes: #862013
Signed-off-by: Benjamin Drung 
---
 conf/initramfs.conf | 11 +++
 init| 19 ++-
 initramfs-tools.8   |  7 +++
 3 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/conf/initramfs.conf b/conf/initramfs.conf
index f0f5071..da862bc 100644
--- a/conf/initramfs.conf
+++ b/conf/initramfs.conf
@@ -62,3 +62,14 @@ DEVICE=
 
 NFSROOT=auto
 
+#
+# RUNSIZE: ...
+#
+# The size of the /run mount point in bytes, and rounded up to entire pages.
+# This option accepts a suffix % to limit the instance to that percentage of
+# your physical RAM or a suffix k, m or g for Ki, Mi, Gi (binary kilo (kibi),
+# binary mega (mebi) and binary giga (gibi)).
+# Overridden by optional ramsize= bootarg
+#
+
+RUNSIZE=10%
diff --git a/init b/init
index 8a40b42..aa2fae6 100755
--- a/init
+++ b/init
@@ -33,8 +33,6 @@ export quiet
 mount -t devtmpfs -o nosuid,mode=0755 udev /dev
 mkdir /dev/pts
 mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /dev/pts || true
-mount -t tmpfs -o "noexec,nosuid,size=10%,mode=0755" tmpfs /run
-mkdir -m 0755 /run/initramfs
 
 # Export the dpkg architecture
 export DPKG_ARCH=
@@ -101,6 +99,9 @@ for x in $(cat /proc/cmdline); do
 			;;
 		esac
 		;;
+	runsize=*)
+		RUNSIZE="${x#runsize=}"
+		;;
 	nfsroot=*)
 		NFSROOT="${x#nfsroot=}"
 		;;
@@ -147,9 +148,9 @@ for x in $(cat /proc/cmdline); do
 		debug=y
 		quiet=n
 		if [ -n "${netconsole}" ]; then
-			exec >/dev/kmsg 2>&1
+			log_output=/dev/kmsg
 		else
-			exec >/run/initramfs/initramfs.debug 2>&1
+			log_output=/run/initramfs/initramfs.debug
 		fi
 		set -x
 		;;
@@ -169,7 +170,7 @@ for x in $(cat /proc/cmdline); do
 		;;
 	netconsole=*)
 		netconsole=${x#netconsole=}
-		[ "x$debug" = "xy" ] && exec >/dev/kmsg 2>&1
+		[ "x$debug" = "xy" ] && log_output=/dev/kmsg
 		;;
 	BOOTIF=*)
 		BOOTIF=${x#BOOTIF=}
@@ -201,6 +202,14 @@ else
 	resume=${RESUME:-}
 fi
 
+mount -t tmpfs -o "noexec,nosuid,size=${RUNSIZE:-10%},mode=0755" tmpfs /run
+mkdir -m 0755 /run/initramfs
+
+if [ -n "$log_output" ]; then
+	exec >$log_output 2>&1
+	unset log_output
+fi
+
 maybe_break top
 
 # Don't do log messages here to avoid confusing graphical boots
diff --git a/initramfs-tools.8 b/initramfs-tools.8
index 0eee050..61a2fcb 100644
--- a/initramfs-tools.8
+++ b/initramfs-tools.8
@@ -88,6 +88,13 @@ mounts the rootfs read-only.
 \fB\fI rw
 mounts the rootfs read-write.
 
+.TP
+\fB\fI ramsize
+The size of the /run mount point in bytes, and rounded up to entire pages.
+This option accepts a suffix % to limit the instance to that percentage of
+your

Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?

2018-05-17 Thread Moritz Schlarb

Hi everyone,

there might be a regression coming from this patch:
Since it got included in 3.16.54, our clients running a recent 3.16
kernel (like from Debian jessie-security) did not follow NFS 4.1
referrals (issued by nfs-ganesha) anymore.
I have built that exact Debian kernel package with just this patch
reversed and it worked again, so I got pretty confident that this patch
is at least strongly related to the problem.
Pradeep also confirmed the problem happening in 3.16.54 but not in 3.16.51.
Interestingly, this does *not* happen with 4.9 kernels, although the
patch was part of 4.9.80...

I have attached a pcap file of a machine running 3.16.56-1+deb8u1 in
which I try to login as a user where my home directory is
/uni-mainz.de/homes/schlarbm (with nfsrefer.zdv.uni-mainz.de:/ on
/uni-mainz.de) which is then referred to
fs02.uni-mainz.de:/vol/ma17/homes/schlarbm but that referral is not
followed by the client.

Please let me know if you need additional information to reproduce or
have suggestions on what we could try.

Best regards,
Moritz

On 05.11.2017 21:45, Chuck Lever wrote:
> Before traversing a referral and performing a mount, the mounted-on
> directory looks strange:
> 
> dr-xr-xr-x. 2 4294967294 4294967294 0 Dec 31  1969 dir.0
> 
> nfs4_get_referral is wiping out any cached attributes with what was
> returned via GETATTR(fs_locations), but the bit mask for that
> operation does not request any file attributes.
> 
> Retrieve owner and timestamp information so that the memcpy in
> nfs4_get_referral fills in more attributes.
> 
> Changes since v1:
> - Don't request attributes that the client unconditionally replaces
> - Request only MOUNTED_ON_FILEID or FILEID attribute, not both
> - encode_fs_locations() doesn't use the third bitmask word
> 
> Fixes: 6b97fd3da1ea ("NFSv4: Follow a referral")
> Suggested-by: Pradeep Thomas 
> Signed-off-by: Chuck Lever 
> Cc: sta...@vger.kernel.org
> ---
>  fs/nfs/nfs4proc.c |   18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> I could send this as an incremental, but that just seems to piss
> off distributors, who will just squash them all together anyway.
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index 6c61e2b..2662879 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -254,15 +254,12 @@ static int nfs4_map_errors(int err)
>  };
>  
>  const u32 nfs4_fs_locations_bitmap[3] = {
> - FATTR4_WORD0_TYPE
> - | FATTR4_WORD0_CHANGE
> + FATTR4_WORD0_CHANGE
>   | FATTR4_WORD0_SIZE
>   | FATTR4_WORD0_FSID
>   | FATTR4_WORD0_FILEID
>   | FATTR4_WORD0_FS_LOCATIONS,
> - FATTR4_WORD1_MODE
> - | FATTR4_WORD1_NUMLINKS
> - | FATTR4_WORD1_OWNER
> + FATTR4_WORD1_OWNER
>   | FATTR4_WORD1_OWNER_GROUP
>   | FATTR4_WORD1_RAWDEV
>   | FATTR4_WORD1_SPACE_USED
> @@ -6763,9 +6760,7 @@ static int _nfs4_proc_fs_locations(struct rpc_clnt 
> *client, struct inode *dir,
>  struct page *page)
>  {
>   struct nfs_server *server = NFS_SERVER(dir);
> - u32 bitmask[3] = {
> - [0] = FATTR4_WORD0_FSID | FATTR4_WORD0_FS_LOCATIONS,
> - };
> + u32 bitmask[3];
>   struct nfs4_fs_locations_arg args = {
>   .dir_fh = NFS_FH(dir),
>   .name = name,
> @@ -6784,12 +6779,15 @@ static int _nfs4_proc_fs_locations(struct rpc_clnt 
> *client, struct inode *dir,
>  
>   dprintk("%s: start\n", __func__);
>  
> + bitmask[0] = nfs4_fattr_bitmap[0] | FATTR4_WORD0_FS_LOCATIONS;
> + bitmask[1] = nfs4_fattr_bitmap[1];
> +
>   /* Ask for the fileid of the absent filesystem if mounted_on_fileid
>* is not supported */
>   if (NFS_SERVER(dir)->attr_bitmask[1] & FATTR4_WORD1_MOUNTED_ON_FILEID)
> - bitmask[1] |= FATTR4_WORD1_MOUNTED_ON_FILEID;
> + bitmask[0] &= ~FATTR4_WORD0_FILEID;
>   else
> - bitmask[0] |= FATTR4_WORD0_FILEID;
> + bitmask[1] &= ~FATTR4_WORD1_MOUNTED_ON_FILEID;
>  
>   nfs_fattr_init(_locations->fattr);
>   fs_locations->server = server;
> 


nfs-referral-broken.pcap
Description: application/vnd.tcpdump.pcap
<>

signature.asc
Description: OpenPGP digital signature

Bug#898165: marked as forwarded (linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals)

2018-05-17 Thread Debian Bug Tracking System

Your message dated Thu, 17 May 2018 09:53:33 +0200
with message-id <19d4d696-3abc-42cd-28fb-86a24b572...@uni-mainz.de>
has caused the   report #898165,
regarding linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals
to be marked as having been forwarded to the upstream software
author(s) 

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
898165: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898165
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Hi everyone,

there might be a regression coming from this patch:
Since it got included in 3.16.54, our clients running a recent 3.16
kernel (like from Debian jessie-security) did not follow NFS 4.1
referrals (issued by nfs-ganesha) anymore.
I have built that exact Debian kernel package with just this patch
reversed and it worked again, so I got pretty confident that this patch
is at least strongly related to the problem.
Pradeep also confirmed the problem happening in 3.16.54 but not in 3.16.51.
Interestingly, this does *not* happen with 4.9 kernels, although the
patch was part of 4.9.80...

I have attached a pcap file of a machine running 3.16.56-1+deb8u1 in
which I try to login as a user where my home directory is
/uni-mainz.de/homes/schlarbm (with nfsrefer.zdv.uni-mainz.de:/ on
/uni-mainz.de) which is then referred to
fs02.uni-mainz.de:/vol/ma17/homes/schlarbm but that referral is not
followed by the client.

Please let me know if you need additional information to reproduce or
have suggestions on what we could try.

Best regards,
Moritz

On 05.11.2017 21:45, Chuck Lever wrote:
> Before traversing a referral and performing a mount, the mounted-on
> directory looks strange:
> 
> dr-xr-xr-x. 2 4294967294 4294967294 0 Dec 31  1969 dir.0
> 
> nfs4_get_referral is wiping out any cached attributes with what was
> returned via GETATTR(fs_locations), but the bit mask for that
> operation does not request any file attributes.
> 
> Retrieve owner and timestamp information so that the memcpy in
> nfs4_get_referral fills in more attributes.
> 
> Changes since v1:
> - Don't request attributes that the client unconditionally replaces
> - Request only MOUNTED_ON_FILEID or FILEID attribute, not both
> - encode_fs_locations() doesn't use the third bitmask word
> 
> Fixes: 6b97fd3da1ea ("NFSv4: Follow a referral")
> Suggested-by: Pradeep Thomas 
> Signed-off-by: Chuck Lever 
> Cc: sta...@vger.kernel.org
> ---
>  fs/nfs/nfs4proc.c |   18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> I could send this as an incremental, but that just seems to piss
> off distributors, who will just squash them all together anyway.
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index 6c61e2b..2662879 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -254,15 +254,12 @@ static int nfs4_map_errors(int err)
>  };
>  
>  const u32 nfs4_fs_locations_bitmap[3] = {
> - FATTR4_WORD0_TYPE
> - | FATTR4_WORD0_CHANGE
> + FATTR4_WORD0_CHANGE
>   | FATTR4_WORD0_SIZE
>   | FATTR4_WORD0_FSID
>   | FATTR4_WORD0_FILEID
>   | FATTR4_WORD0_FS_LOCATIONS,
> - FATTR4_WORD1_MODE
> - | FATTR4_WORD1_NUMLINKS
> - | FATTR4_WORD1_OWNER
> + FATTR4_WORD1_OWNER
>   | FATTR4_WORD1_OWNER_GROUP
>   | FATTR4_WORD1_RAWDEV
>   | FATTR4_WORD1_SPACE_USED
> @@ -6763,9 +6760,7 @@ static int _nfs4_proc_fs_locations(struct rpc_clnt 
> *client, struct inode *dir,
>  struct page *page)
>  {
>   struct nfs_server *server = NFS_SERVER(dir);
> - u32 bitmask[3] = {
> - [0] = FATTR4_WORD0_FSID | FATTR4_WORD0_FS_LOCATIONS,
> - };
> + u32 bitmask[3];
>   struct nfs4_fs_locations_arg args = {
>   .dir_fh = NFS_FH(dir),
>   .name = name,
> @@ -6784,12 +6779,15 @@ static int _nfs4_proc_fs_locations(struct rpc_clnt 
> *client, struct inode *dir,
>  
>   dprintk("%s: start\n", __func__);
>  
> + bitmask[0] = nfs4_fattr_bitmap[0] | FATTR4_WORD0_FS_LOCATIONS;
> + bitmask[1] = nfs4_fattr_bitmap[1];
> +
>   /* Ask for the fileid of the absent filesystem if mounted_on_fileid
>* is not supported */
>   if (NFS_SERVER(dir)->attr_bitmask[1] & FATTR4_WORD1_MOUNTED_ON_FILEID)
> - bitmask[1] |= FATTR4_WORD1_MOUNTED_ON_FILEID;
> + bitmask[0] &= ~FATTR4_WORD0_FILEID;
>   else
> - bitmask[0] |= FATTR4_WORD0_FILEID;
> + bitmask[1] &= ~FATTR4_WORD1_MOUNTED_ON_FILEID;
>  
>

Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?

Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?

Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail

Bug#898907: ethtool -K tso setting output noise msg "Cannot get device udp-fragmentation-offload settings: Operation not supported"

Bug#862013: initramfs-tools-core: /run tmpfs size hardcoded at 10% RAM, but 16.0 MiB free required in /run/systemd

Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?

Bug#898165: marked as forwarded (linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals)

7 matches

Site Navigation

Mail list logo

Footer information