Module Name:src
Committed By: riastradh
Date: Wed Feb 22 21:49:45 UTC 2023
Modified Files:
src/sys/ufs/ufs: quota1_subr.c quota2.h quota2_subr.c ufs_acl.c
ufs_extattr.c ufs_lookup.c ufs_quota.c ufs_quota1.c ufs_quota2.c
ufs_vfsops.c
Log Message:
Module Name:src
Committed By: riastradh
Date: Wed Feb 22 21:49:45 UTC 2023
Modified Files:
src/sys/ufs/ufs: quota1_subr.c quota2.h quota2_subr.c ufs_acl.c
ufs_extattr.c ufs_lookup.c ufs_quota.c ufs_quota1.c ufs_quota2.c
ufs_vfsops.c
Log Message:
Module Name:src
Committed By: andvar
Date: Mon Jan 30 13:45:26 UTC 2023
Modified Files:
src/sys/ufs/ufs: README.acls
Log Message:
s/isses/issues/
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/sys/ufs/ufs/README.acls
Please note that diffs are not
Module Name:src
Committed By: andvar
Date: Mon Jan 30 13:45:26 UTC 2023
Modified Files:
src/sys/ufs/ufs: README.acls
Log Message:
s/isses/issues/
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/sys/ufs/ufs/README.acls
Please note that diffs are not
Module Name:src
Committed By: hannken
Date: Tue Apr 26 15:37:25 UTC 2022
Modified Files:
src/sys/ufs/ufs: ufs_quota1.c
Log Message:
Keep flag "UFS_QUOTA" set until the last quota is closed.
Prevents a live lock when dqrele() finds a struct with "dq_cnt == 1"
and flag
Module Name:src
Committed By: hannken
Date: Tue Apr 26 15:37:25 UTC 2022
Modified Files:
src/sys/ufs/ufs: ufs_quota1.c
Log Message:
Keep flag "UFS_QUOTA" set until the last quota is closed.
Prevents a live lock when dqrele() finds a struct with "dq_cnt == 1"
and flag
Module Name:src
Committed By: hannken
Date: Mon Feb 21 17:07:45 UTC 2022
Modified Files:
src/sys/ufs/ufs: ufs_readwrite.c
Log Message:
Fix wrong assertion, the negatiopn of "a && b" is "!a || !b" so we
need "DIP(ip, blocks) != 0" here.
Should fix PR kern/56725 (Panic
Module Name:src
Committed By: hannken
Date: Mon Feb 21 17:07:45 UTC 2022
Modified Files:
src/sys/ufs/ufs: ufs_readwrite.c
Log Message:
Fix wrong assertion, the negatiopn of "a && b" is "!a || !b" so we
need "DIP(ip, blocks) != 0" here.
Should fix PR kern/56725 (Panic
Module Name:src
Committed By: christos
Date: Fri Nov 26 17:35:12 UTC 2021
Modified Files:
src/sys/ufs/ufs: ufs_acl.c ufs_vnops.c
Log Message:
use MNT_NFS4ACLS instead of MNT_ACLS (which was changed before to mean
MNT_POSIX1EACLS)
To generate a diff of this commit:
cvs
Module Name:src
Committed By: christos
Date: Fri Nov 26 17:35:12 UTC 2021
Modified Files:
src/sys/ufs/ufs: ufs_acl.c ufs_vnops.c
Log Message:
use MNT_NFS4ACLS instead of MNT_ACLS (which was changed before to mean
MNT_POSIX1EACLS)
To generate a diff of this commit:
cvs
Module Name:src
Committed By: thorpej
Date: Sun Oct 10 23:02:10 UTC 2021
Modified Files:
src/sys/ufs/ufs: ufs_acl.c
Log Message:
Use VN_KNOTE() to send our NOTE_ATTRIB and NOTE_REVOKE events.
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2
Module Name:src
Committed By: thorpej
Date: Sun Oct 10 23:02:10 UTC 2021
Modified Files:
src/sys/ufs/ufs: ufs_acl.c
Log Message:
Use VN_KNOTE() to send our NOTE_ATTRIB and NOTE_REVOKE events.
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2
Le 27/02/2020 à 01:36, Simon Burge a écrit :
> "Maxime Villard" wrote:
>
>> Module Name: src
>> Committed By:maxv
>> Date:Wed Feb 26 18:00:12 UTC 2020
>>
>> Modified Files:
>>
>> src/sys/ufs/ufs: ufs_vnops.c
>>
>> Log Message:
>>
>> Zero out the padding in 'd_namlen',
"Maxime Villard" wrote:
> Module Name: src
> Committed By: maxv
> Date: Wed Feb 26 18:00:12 UTC 2020
>
> Modified Files:
>
> src/sys/ufs/ufs: ufs_vnops.c
>
> Log Message:
>
> Zero out the padding in 'd_namlen', to prevent info leaks. Same logic as
> ufs_makedirentry().
Is it
Module Name:src
Committed By: christos
Date: Mon Aug 19 14:09:12 UTC 2019
Modified Files:
src/sys/ufs/ufs: ufs_extattr.c
Log Message:
- KNF more
- print the full path in error messages
To generate a diff of this commit:
cvs rdiff -u -r1.49 -r1.50
Module Name:src
Committed By: christos
Date: Mon Aug 19 14:09:12 UTC 2019
Modified Files:
src/sys/ufs/ufs: ufs_extattr.c
Log Message:
- KNF more
- print the full path in error messages
To generate a diff of this commit:
cvs rdiff -u -r1.49 -r1.50
Module Name:src
Committed By: christos
Date: Mon Aug 19 09:30:30 UTC 2019
Modified Files:
src/sys/ufs/ufs: ufs_extattr.c
Log Message:
- return (foo) -> return foo
- normalize all error messages to use __func__
- add more messages for startup failure (should perhaps
Module Name:src
Committed By: christos
Date: Mon Aug 19 09:30:30 UTC 2019
Modified Files:
src/sys/ufs/ufs: ufs_extattr.c
Log Message:
- return (foo) -> return foo
- normalize all error messages to use __func__
- add more messages for startup failure (should perhaps
Module Name:src
Committed By: dholland
Date: Mon Jul 1 00:57:06 UTC 2019
Modified Files:
src/sys/ufs/ufs: ufs_vnops.c
Log Message:
Lay down some comments related to the previous few revisions of ufs_vnops.c.
To generate a diff of this commit:
cvs rdiff -u -r1.246
Module Name:src
Committed By: dholland
Date: Mon Jul 1 00:57:06 UTC 2019
Modified Files:
src/sys/ufs/ufs: ufs_vnops.c
Log Message:
Lay down some comments related to the previous few revisions of ufs_vnops.c.
To generate a diff of this commit:
cvs rdiff -u -r1.246
Module Name:src
Committed By: christos
Date: Thu Jun 20 00:52:05 UTC 2019
Modified Files:
src/sys/ufs/ufs: ufs_readwrite.c
Log Message:
unifdef -ULFS_READWRITE ufs_readwrite.c
To generate a diff of this commit:
cvs rdiff -u -r1.123 -r1.124
Module Name:src
Committed By: christos
Date: Thu Jun 20 00:52:05 UTC 2019
Modified Files:
src/sys/ufs/ufs: ufs_readwrite.c
Log Message:
unifdef -ULFS_READWRITE ufs_readwrite.c
To generate a diff of this commit:
cvs rdiff -u -r1.123 -r1.124
On Sun, Feb 24, 2019 at 10:13:40PM +0100, Tobias Nygren wrote:
> On Sun, 24 Feb 2019 19:06:40 +
> Michael van Elst wrote:
>
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.242 -r1.243 src/sys/ufs/ufs/ufs_vnops.c
>
> > + rawbuf -= dropend;
>
> I guess this should be
On Mon, Feb 25, 2019 at 06:07:23AM +, David Holland wrote:
> that one doesn't set dropend correctly for small buffers, outsmarted
> myself while writing it.
Better change (still against 1.242) that makes the logic much
simpler. Will test this overnight...
Index: ufs_vnops.c
On Mon, Feb 25, 2019 at 05:50:08AM +, David Holland wrote:
> Furthermore, this:
>
> > + rawbuf -= dropend;
>
> is entirely wrong (it needs to be "rawbufmax") and without that bound
> on rawbufmax the code is unsafe...
I repaired this bit just now, so it's not an overt hazard
On Sun, Feb 24, 2019 at 07:51:24PM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By:christos
> Date:Mon Feb 25 00:51:24 UTC 2019
>
> Modified Files:
> src/sys/ufs/ufs: ufs_vnops.c
>
> Log Message:
> drop unused
dropping this logic is wrong...
On Sun, 24 Feb 2019 19:06:40 +
Michael van Elst wrote:
> To generate a diff of this commit:
> cvs rdiff -u -r1.242 -r1.243 src/sys/ufs/ufs/ufs_vnops.c
> + rawbuf -= dropend;
I guess this should be rawbufmax, not rawbuf.
On Sun, Feb 24, 2019 at 07:41:59PM +, m...@netbsd.org wrote:
> something like the overflow is undefined behaviour, so it cannot
> happen, so the branch checking that it happened is eliminated.
*Signed* integer overflow is undefined behavior. *Unsigned* integer
overflow is well defined.
Joerg
On Sun, Feb 24, 2019 at 07:41:59PM +, m...@netbsd.org wrote:
> something like the overflow is undefined behaviour, so it cannot
> happen, so the branch checking that it happened is eliminated.
Integer overflow is not undefined, but implemenation defined behaviour.
Martin
On Sun, Feb 24, 2019 at 07:06:40PM +, Michael van Elst wrote:
> While here, also check for arithmetic overflow.
> + /* how much to actually read */
> + rawbufmax = callerbytes + skipstart;
> + if (rawbufmax < callerbytes)
> + return EINVAL;
hmm, I"m under the
Indeed rebooting with an updated kernel will give active NFS clients
problems, but I am not sure we should realy care nor how we could
possibly avoid this one time issue. We have changed encoding of
filehandles before (at least once).
it's a bad thing and worth mentioning in release notes.
Hi
David Holland:
I'm not entirely clear on how this structure is actually used, which
is why I hadn't yet made this change myself after the issue came up. :-/
My observation in sys/fs/cd9660 is probably the initial cause for
this change. PR kern/48799.
I could produce a problem by exporting
On Fri, May 16, 2014 at 12:12:00AM +0200, Joerg Sonnenberger wrote:
I don't think it is a problem by itself as the file handle is opaque,
but it is certainly wasteful to not put ufid_ino first.
That is not possible, the first few bytes of the structure must match
struct fid from fstypes.h.
The
On Fri, May 16, 2014 at 03:54:44PM +, David Holland wrote:
Indeed rebooting with an updated kernel will give active NFS clients
problems, but I am not sure we should realy care nor how we could
possibly avoid this one time issue. We have changed encoding of
filehandles before (at
On Fri, May 16, 2014 at 06:48:06PM +, Martin Husemann wrote:
The problem is that the tokens are memcmp'd, so if they include struct
padding this may not work.
All filesystems I've seen init the struct with a full memset to 0, so
all padding fields should be initialized as well.
On Wed, May 14, 2014 at 01:46:19PM +, Martin Husemann wrote:
Modified Files:
src/sys/ufs/ufs: inode.h
Log Message:
Make filehandles on UFS based filesystems use proper 64bit inodes.
32bit restriction noticed by Taylor R Campbell.
I suspect this isn't going to work:
On Thu, May 15, 2014 at 10:06:18PM +, David Holland wrote:
On Wed, May 14, 2014 at 01:46:19PM +, Martin Husemann wrote:
Modified Files:
src/sys/ufs/ufs: inode.h
Log Message:
Make filehandles on UFS based filesystems use proper 64bit inodes.
32bit restriction noticed
On Fri, May 16, 2014 at 12:12:00AM +0200, Joerg Sonnenberger wrote:
Modified Files:
src/sys/ufs/ufs: inode.h
Log Message:
Make filehandles on UFS based filesystems use proper 64bit inodes.
32bit restriction noticed by Taylor R Campbell.
I suspect this
On Sun, Jan 29, 2012 at 08:49:02AM +, Izumi Tsutsui wrote:
Modified Files:
src/sys/ufs/ufs: ufs_vfsops.c
Log Message:
Fix errors in !defined(QUOTA) !defined(QUOTA2) case.
Whoops, sorry...
--
David A. Holland
dholl...@netbsd.org
On Tue, Oct 11, 2011 at 04:40:02AM +, David Holland wrote:
On Sun, Oct 09, 2011 at 09:15:34PM +, Chuck Silvers wrote:
Modified Files:
src/sys/ufs/ufs: extattr.h
Log Message:
add forward declarations for the VOP args structures
so that fstat can include this file.
On Sun, Oct 09, 2011 at 09:15:34PM +, Chuck Silvers wrote:
Modified Files:
src/sys/ufs/ufs: extattr.h
Log Message:
add forward declarations for the VOP args structures
so that fstat can include this file.
Do we really want fstat using fs-specific headers and interfaces?
(I
On Sun, Jul 17, 2011 at 10:02:27PM +, David A. Holland wrote:
Modified Files:
src/sys/ufs/ufs: ufs_vnops.c
Log Message:
At the end of ufs_rmdir, don't use a dangling vnode pointer to call
fstrans_done. Ok hannken@
Well, for the record it turns out I misread his mail and
On Tue, 25 May 2010, Antti Kantee wrote:
What would I have to do from userland to tickle this bug?
You need to unlink and create a file after the first namei in sys_rename
but before VOP_RENAME runs, i.e. trigger a race condition.
Thanks.
--apb (Alan Barrett)
On Tue, 25 May 2010, Antti Kantee wrote:
Modified Files:
src/sys/ufs/ufs: ufs_wapbl.c
Log Message:
Add a comment describing an observed boom-crash-burn problem in
the code. Fixing it will require a full tank of gas, half a pack
of cigarettes, sunglasses, darkness, and most
On Tue May 25 2010 at 15:55:35 +0200, Alan Barrett wrote:
On Tue, 25 May 2010, Antti Kantee wrote:
Modified Files:
src/sys/ufs/ufs: ufs_wapbl.c
Log Message:
Add a comment describing an observed boom-crash-burn problem in
the code. Fixing it will require a full tank of gas, half
On Tue, May 25, 2010 at 11:02:07AM +, Antti Kantee wrote:
Add a comment describing an observed boom-crash-burn problem in
the code. Fixing it will require a full tank of gas, half a pack
of cigarettes, sunglasses, darkness, and most importantly:
someone else.
Thanks for the merge
Module Name:src
Committed By: pooka
Date: Tue Mar 2 14:45:56 UTC 2010
Modified Files:
src/sys/ufs/ufs: ufs_wapbl.c
Log Message:
scortch ufs_vnops.c cargo cult headers
To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.8 src/sys/ufs/ufs/ufs_wapbl.c
Please note
Module Name:src
Committed By: pooka
Date: Tue Mar 2 14:45:56 UTC 2010
Modified Files:
src/sys/ufs/ufs: ufs_wapbl.c
Log Message:
scortch ufs_vnops.c cargo cult headers
To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.8 src/sys/ufs/ufs/ufs_wapbl.c
Please note
Module Name:src
Committed By: bouyer
Date: Fri Jan 15 19:46:35 UTC 2010
Modified Files:
src/sys/ufs/ufs: ufs_quota.c
Log Message:
vclean() actually sets v_tag to VT_NON but doesn't touch v_type.
getcleanvnode() sets v_type to VNON after releasing v_interlock.
So the
On Tue, Sep 22, 2009 at 10:42:59PM +0300, Antti Kantee wrote:
Blah, I didn't even want to think about this migrane-inducer now.
Maybe people who have recently worked on vnode reclaiming could instead
be the ones to comment?
It's becoming clear that this is something I'm going to need to
On Sep,Tuesday 22 2009, at 9:42 PM, Antti Kantee wrote:
On Tue Sep 22 2009 at 21:04:14 +0200, Manuel Bouyer wrote:
that's not an issue with the reference count. It's an issue with
vclean()
calling VOP_RECLAIM() even if the refcount is greater than 1, and
vrelel() calling vclean() even if
On Wed, Sep 23, 2009 at 06:09:00PM +0200, Adam Hamsik wrote:
Sorry I haven't read this thread until today. I think that it would be
good to test my vreclaim patched kernel it might help to resolve your
problem. But I don't think it is a solution see above.
Your patch won't help. It only
On Wed, Sep 23, 2009 at 03:08:14PM +, David Holland wrote:
It's becoming clear that this is something I'm going to need to wade
into. Much as I've been trying to avoid it. :-/
There's a (perfectly natural) tendency to try to fix synchronization
problems by adding states -- extra flags,
On Sun, Sep 20, 2009 at 08:23:38PM +0300, Antti Kantee wrote:
In ufs_ihashget(), vget() can return a vnode that has been vclean'ed because
vget() can sleep. After vget returns, check that vp is still connected with
ip, and that ip still points to the inode we want. This fix the NULL
On Tue Sep 22 2009 at 20:06:40 +0200, Manuel Bouyer wrote:
On Sun, Sep 20, 2009 at 08:23:38PM +0300, Antti Kantee wrote:
In ufs_ihashget(), vget() can return a vnode that has been vclean'ed
because
vget() can sleep. After vget returns, check that vp is still connected
with
ip,
On Tue, Sep 22, 2009 at 09:23:05PM +0300, Antti Kantee wrote:
On Tue Sep 22 2009 at 20:06:40 +0200, Manuel Bouyer wrote:
On Sun, Sep 20, 2009 at 08:23:38PM +0300, Antti Kantee wrote:
In ufs_ihashget(), vget() can return a vnode that has been vclean'ed
because
vget() can sleep.
On Tue Sep 22 2009 at 21:04:14 +0200, Manuel Bouyer wrote:
that's not an issue with the reference count. It's an issue with vclean()
calling VOP_RECLAIM() even if the refcount is greater than 1, and
vrelel() calling vclean() even if the refcount is greater than 1,
when the file has been
On Tue, Sep 22, 2009 at 10:42:59PM +0300, Antti Kantee wrote:
On Tue Sep 22 2009 at 21:04:14 +0200, Manuel Bouyer wrote:
that's not an issue with the reference count. It's an issue with vclean()
calling VOP_RECLAIM() even if the refcount is greater than 1, and
vrelel() calling vclean() even
On Tue Sep 22 2009 at 21:58:02 +0200, Manuel Bouyer wrote:
[explanations]
This is starting to sound sensible now. You obviously have invested
quite a bit of thought in investigating the problem.
Blah, I didn't even want to think about this migrane-inducer now.
Maybe people who have
On Tue, Sep 22, 2009 at 11:26:21PM +0300, Antti Kantee wrote:
On Tue Sep 22 2009 at 21:58:02 +0200, Manuel Bouyer wrote:
[explanations]
This is starting to sound sensible now. You obviously have invested
quite a bit of thought in investigating the problem.
Yes, it was annoying enough :)
On Sun Sep 20 2009 at 14:00:24 +, Manuel Bouyer wrote:
Module Name: src
Committed By: bouyer
Date: Sun Sep 20 14:00:24 UTC 2009
Modified Files:
src/sys/ufs/ufs: ufs_ihash.c
Log Message:
PR kern/41147: race between nfsd and local rm
Note that the race also exists
61 matches
Mail list logo
