Bug#1087900: kernel BUG at fs/nfsd/nfs4recover.c:534 Oops: invalid opcode: 0000

2024-12-28 Thread Chuck Lever
On 12/28/24 1:09 AM, Salvatore Bonaccorso wrote: Hi, On Fri, Dec 27, 2024 at 04:31:44PM -0500, Chuck Lever wrote: On 12/27/24 1:36 AM, Salvatore Bonaccorso wrote: Hi, On Thu, Dec 26, 2024 at 08:17:45PM +0100, Salvatore Bonaccorso wrote: Hi Chuck, hi all, On Thu, Dec 26, 2024 at 11:33:01AM

Bug#1091439: kernel BUG at fs/nfsd/nfs4recover.c:534 Oops: invalid opcode: 0000

2024-12-27 Thread Chuck Lever
On 12/27/24 1:36 AM, Salvatore Bonaccorso wrote: Hi, On Thu, Dec 26, 2024 at 08:17:45PM +0100, Salvatore Bonaccorso wrote: Hi Chuck, hi all, On Thu, Dec 26, 2024 at 11:33:01AM -0500, Chuck Lever wrote: On 12/26/24 11:24 AM, Salvatore Bonaccorso wrote: Hi Jur, On Mon, Dec 09, 2024 at 04:50

Bug#1091439: kernel BUG at fs/nfsd/nfs4recover.c:534 Oops: invalid opcode: 0000

2024-12-26 Thread Chuck Lever
lib/nfs/nfsdcld/ and sqlite3 /var/lib/nfs/nfsdcld/main.sqlite < -- Chuck Lever

Bug#1067829: Fails to build on arm{el,hf} with 64bit time_t: export-cache.c:110:51: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘time_t’ {aka ‘long long int’} [-We

2024-04-06 Thread Chuck Lever III
Vladimir > to properly credit the patch origin. > > Let me know if that works. I changed it slightly and only casting to > long long, and made it almost checkpatch clean. I suppose strftime(3) might be nicer, but this works. Reviewed-by: Chuck Lever mailto:chuck.le...@oracle

Bug#940821: NFS Caching broken in 4.19.37

2021-02-20 Thread Chuck Lever
0% reproducible with any kernel from 4.9 to 5.4, stable or backports. It > may exist in earlier versions, but I do not have a machine with anything > before 4.9 to test at present. Confirming you are varying client-side kernels. Should the Linux NFS client maintainers be Cc'd? > From 1-2 make clean && make cycles to one afternoon depending on the number > of machine cores. More cores/threads the faster it does it. > > I tried playing with protocol minor versions, caching options, etc - it is > still reproducible for any nfs4 settings as long as there is client side > caching of metadata. > > A. > >> >> Regards, >> Salvatore >> > > -- > Anton R. Ivanov > Cambridgegreys Limited. Registered in England. Company Number 10273661 > https://www.cambridgegreys.com/ -- Chuck Lever

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

2018-05-18 Thread Chuck Lever
> On May 17, 2018, at 5:48 PM, Moritz Schlarb wrote: > > 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 Schumak

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

2018-05-17 Thread Chuck Lever
t_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

Bug#494001: Bug: mount: "user" mounts broken when /etc/mtab is a symlink

2011-02-19 Thread Chuck Lever
would be appreciated, thanks!) > > -- > .''`. Roger Leigh > : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ > `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ > `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

2010-08-08 Thread Chuck Lever
On Aug 8, 2010, at 12:59 AM, Ben Hutchings wrote: > On Tue, 2010-07-06 at 13:05 -0400, Chuck Lever wrote: >> On 06/ 9/10 10:41 AM, Steven Shiau wrote: >>> >>> >>> On 2010年06月06日 04:29, Ben Hutchings wrote: >>>> On Thu, 2010-06-03 at 17:08 -040

Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

2010-07-06 Thread Chuck Lever
On 06/ 9/10 10:41 AM, Steven Shiau wrote: On 2010年06月06日 04:29, Ben Hutchings wrote: On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote: On 05/24/10 11:22 AM, Chuck Lever wrote: [...] We can probably remove the reverse mapping constraint for presentation addresses. A simple fix might be

Bug#583435: rpcbind: Insecure handling of state files

2010-06-03 Thread Chuck Lever
On 06/ 2/10 07:25 AM, Aníbal Monsalve Salazar wrote: On Tue, Jun 01, 2010 at 02:09:07PM +0200, Guillem Jover wrote: Hi! On Thu, 2010-05-27 at 19:09:08 +0200, Guillem Jover wrote: Package: rpcbind Version: 0.2.0-4 Severity: serious Tags: security The rpcbind daemon, which runs as root, uses

Bug#583435: rpcbind: Insecure handling of state files

2010-06-03 Thread Chuck Lever
On 06/ 3/10 05:07 PM, Guillem Jover wrote: On Thu, 2010-06-03 at 16:34:01 -0400, Chuck Lever wrote: On 06/ 3/10 04:27 PM, Guillem Jover wrote: The second problem is that those files get created by the daemon on shutdown, and they *do* follow symlinks. So a user can drop two symlinks there

Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

2010-06-03 Thread Chuck Lever
On 05/24/10 11:22 AM, Chuck Lever wrote: On 05/21/10 09:38 PM, Ben Hutchings wrote: On Sat, 2010-05-22 at 07:49 +0800, Steven Shiau wrote: Same problem here. However, mine is on the client side. On sid system, running kernel is 2.6.32-5-686, nfs-common is 1:1.2.2-1. When I mount my NFS server

Bug#583435: rpcbind: Insecure handling of state files

2010-06-03 Thread Chuck Lever
On 06/ 3/10 04:27 PM, Guillem Jover wrote: Hi! On Thu, 2010-06-03 at 16:07:50 -0400, Chuck Lever wrote: On 06/ 2/10 07:25 AM, Aníbal Monsalve Salazar wrote: On Tue, Jun 01, 2010 at 02:09:07PM +0200, Guillem Jover wrote: On Thu, 2010-05-27 at 19:09:08 +0200, Guillem Jover wrote: Package

Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

2010-05-24 Thread Chuck Lever
debian for SM_MON of 192.168.120.254 May 21 08:52:44 debian rpc.statd[1298]: No canonical hostname found for 192.168.120.254 [...] nfs-utils 1.2.2 includes the change: commit 8ce130c4c828b9d13d429f22160f992b9c1d45cd Author: Chuck Lever Date: Thu Jan 14 12:24:15 2010 -0500 statd: Suppo

Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs

2008-10-15 Thread Chuck Lever
On Oct 15, 2008, at 12:57 PM, Steve Dickson wrote: Chuck Lever wrote: Easy... the mount.nfs subcommand in nfs-utils-1.1.3 switches to legacy mode on old kernels (pre 2.6.23). What I meant by "you need to force the use of the legacy mount command" is that you need to force the u

Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs

2008-10-15 Thread Chuck Lever
On Oct 15, 2008, at 2:18 PM, Steve Dickson wrote: Chuck Lever wrote: Ok... The client has the nfs-utils-1.1.3 mount.nfs binary using an FC-7 (2.6.21) kernel. New text mount interface with old binary kernel interface. I have two servers: ServerA has the nfs-utils-1.1.3 rpc.mountd binary

Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs

2008-10-06 Thread Chuck Lever
On Oct 6, 2008, at 5:12 AM, Rasmus Bøg Hansen wrote: Chuck Lever skrev: Hi Steve- As I understand it, the documented bug refers to running nfs-utils 1.1.3 on kernels older than 2.6.22 (ie the problem is with the legacy mount command, not with the in-kernel mount parser, which has a different

Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs

2008-10-02 Thread Chuck Lever
2 09:24:00 rawhat kernel: NFS: sending MNT request for madhat:/ home Oct 2 09:24:00 rawhat kernel: NFS: MNT request succeeded steved. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#492970: (was: nfs-utils-1.1.3 released)

2008-08-07 Thread Chuck Lever
On Aug 7, 2008, at 11:05 AM, Lucas Nussbaum wrote: On 06/08/08 at 12:21 -0400, Chuck Lever wrote: On Aug 5, 2008, at 3:28 PM, Rasmus Bøg Hansen wrote: Chuck Lever <[EMAIL PROTECTED]> writes: On Aug 4, 2008, at 4:55 PM, Paul Collins wrote: Chuck Lever <[EMAIL PROTECTED]> write

Bug#492970: (was: nfs-utils-1.1.3 released)

2008-08-06 Thread Chuck Lever
On Aug 5, 2008, at 3:28 PM, Rasmus Bøg Hansen wrote: Chuck Lever <[EMAIL PROTECTED]> writes: On Aug 4, 2008, at 4:55 PM, Paul Collins wrote: Chuck Lever <[EMAIL PROTECTED]> writes: On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote: On Mon, Aug 04, 2008 at 12:37:19AM +1200,

Bug#492970: (was: nfs-utils-1.1.3 released)

2008-08-05 Thread Chuck Lever
On Aug 4, 2008, at 4:55 PM, Paul Collins wrote: Chuck Lever <[EMAIL PROTECTED]> writes: On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote: On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote: "J. Bruce Fields" <[EMAIL PROTECTED]> writes: On Fri, Aug 01, 20

Bug#492970: (was: nfs-utils-1.1.3 released)

2008-08-04 Thread Chuck Lever
fect the sec= option. Paul, which kernel are you running on your clients? -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#476577: corrected patch

2008-04-21 Thread Chuck Lever
Hi Joey- On Apr 21, 2008, at 12:53 PM, Joey Hess wrote: Chuck Lever wrote: What if /etc/mtab is a symlink to a valid writable file that is not / proc/mounts? The test you introduce below will prevent that case from working properly. Note that util-linux mount does the same thing in this

Bug#476577: corrected patch

2008-04-21 Thread Chuck Lever
mtab(); mtab = nfs_setmntent(MOUNTED, "a+"); -- Homepage: http://www.sesse.net/ -- 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 --