On Tue, May 19, 2020 at 11:09:07PM +, Andrew Doran wrote:
> vnode locks are not held during getpages/putpages.
^ for fault handling, anyway. for read/write they are held by the caller to
ubc_uiomove().
Andrew
On Sun, May 17, 2020 at 11:49:52PM +, m...@netbsd.org wrote:
> On Sun, May 17, 2020 at 09:47:50PM +, m...@netbsd.org wrote:
> > On Sun, May 17, 2020 at 07:39:15PM +, Andrew Doran wrote:
> > > Module Name: src
> > > Committed By: ad
> > > Date: Sun May 17 19:39:15 U
On Sun, May 17, 2020 at 09:47:50PM +, m...@netbsd.org wrote:
> On Sun, May 17, 2020 at 07:39:15PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Sun May 17 19:39:15 UTC 2020
> >
> > Modified Files:
> > src/sys/fs/tmpfs: tmpfs.h tmp
On Sun, May 17, 2020 at 07:39:15PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Sun May 17 19:39:15 UTC 2020
>
> Modified Files:
> src/sys/fs/tmpfs: tmpfs.h tmpfs_subr.c tmpfs_vnops.c
>
> Log Message:
> PR kern/55268: tmpfs is slow
>
> tmpfs_getpages():
On Wed, Jan 11, 2017 at 09:12:33PM +, David Holland wrote:
> On Wed, Jan 11, 2017 at 12:12:33PM +, Joerg Sonnenberger wrote:
> > Modified Files:
> >src/sys/fs/tmpfs: tmpfs_vnops.c
> >
> > Log Message:
> > Remove RO check in tmpfs_putpages for now, the syncer doesn't like the
> >
On Wed, Jan 11, 2017 at 12:12:33PM +, Joerg Sonnenberger wrote:
> Modified Files:
> src/sys/fs/tmpfs: tmpfs_vnops.c
>
> Log Message:
> Remove RO check in tmpfs_putpages for now, the syncer doesn't like the
> error code.
Either removing it is wrong or it should be changed to KASSERT
On Jan 8, 2014, at 5:11 PM, pedro martelletto wrote:
> Module Name: src
> Committed By: pedro
> Date: Wed Jan 8 16:11:04 UTC 2014
>
> Modified Files:
> src/sys/fs/tmpfs: tmpfs_subr.c
>
> Log Message:
> Allocate direntp on the stack in tmpfs_dir_getdents(), thus saving
> calls to
"J. Hannken-Illjes" wrote:
> On Jan 8, 2014, at 5:11 PM, pedro martelletto wrote:
>
> > Module Name:src
> > Committed By: pedro
> > Date: Wed Jan 8 16:11:04 UTC 2014
> >
> > Modified Files:
> > src/sys/fs/tmpfs: tmpfs_subr.c
> >
> > Log Message:
> > Allocate di
On Jan 3, 2014, at 10:18 PM, J. Hannken-Illjes wrote:
> On Jan 3, 2014, at 10:13 PM, Mindaugas Rasiukevicius wrote:
>
>> "Juergen Hannken-Illjes" wrote:
>>> Module Name:src
>>> Committed By: hannken
>>> Date: Fri Jan 3 09:53:12 UTC 2014
>>>
>>> Modified Files:
>>>
On Jan 3, 2014, at 10:13 PM, Mindaugas Rasiukevicius wrote:
> "Juergen Hannken-Illjes" wrote:
>> Module Name: src
>> Committed By:hannken
>> Date:Fri Jan 3 09:53:12 UTC 2014
>>
>> Modified Files:
>> src/sys/fs/tmpfs: tmpfs_subr.c tmpfs_vnops.c
>>
>> Log Message:
>
"Juergen Hannken-Illjes" wrote:
> Module Name: src
> Committed By: hannken
> Date: Fri Jan 3 09:53:12 UTC 2014
>
> Modified Files:
> src/sys/fs/tmpfs: tmpfs_subr.c tmpfs_vnops.c
>
> Log Message:
> Fix a race where thread1 runs VOP_REMOVE() and gets preempted in
> tmpfs_reclaim()
"J. Hannken-Illjes" wrote:
> > Module Name:src
> > Committed By: rmind
> > Date: Fri Nov 8 15:44:23 UTC 2013
> >
> <...>
>
> The tests fs/vfs/t_union/tmpfs_basic and fs/vfs/t_union/tmpfs_whiteout
> start failing after this commit.
>
Fixed.
--
Mindaugas
On Nov 8, 2013, at 4:44 PM, Mindaugas Rasiukevicius wrote:
> Module Name: src
> Committed By: rmind
> Date: Fri Nov 8 15:44:23 UTC 2013
>
> Modified Files:
> src/sys/fs/tmpfs: tmpfs.h tmpfs_rename.c tmpfs_subr.c tmpfs_vfsops.c
> tmpfs_vnops.c
>
> Log Message:
> tmpfs:
On Thu, Aug 18, 2011 at 09:51:50PM +, Taylor R Campbell wrote:
> Forgot to add that this also fixes a space leak in tmpfs_rename,
> introduced a couple months ago, which nobody reported as far as I
> know. The leak sometimes caused tmpfs_renamerace_dirs to fail with
> ENOSPC. The problem
Forgot to add that this also fixes a space leak in tmpfs_rename,
introduced a couple months ago, which nobody reported as far as I
know. The leak sometimes caused tmpfs_renamerace_dirs to fail with
ENOSPC. The problem was that renaming a directory over an empty
directory would fail to decrement t
On May 14, 2011, at 1:43 PM, Martin Husemann wrote:
> On Sat, May 14, 2011 at 10:34:05AM +0200, Marc Balmer wrote:
>> What is the current state of C99 vs. older Cs? Do all arches /
>> compilers we have support C99?
>
> We have lost the playstation2 port, because we don't have a working C99
> co
On Sat, May 14, 2011 at 10:34:05AM +0200, Marc Balmer wrote:
> What is the current state of C99 vs. older Cs? Do all arches /
> compilers we have support C99?
We have lost the playstation2 port, because we don't have a working C99
compiler for it (so a -current kernel can not be compiled).
Marti
14.05.2011, 10:38, "Masao Uebayashi" :
> I disagree. If variables are declared in the middle of context, those
> variables have narrower contexts. Narrowing context is always a win
> IMO.
That's true only if you don't use gotos. Otherwise, you might jump past
an initialization point with obvious
On Sat, May 14, 2011 at 12:07:20PM -0400, Christos Zoulas wrote:
> If we are going to be compiling the kernel in c99 mode, then I
> suggest that we do the same for userland instead of turning it on
> for userland piecemeal.
+1
is there anything we expect to break?
--
David A. Holland
dholl..
On May 14, 12:00pm, rm...@netbsd.org (Mindaugas Rasiukevicius) wrote:
-- Subject: Re: CVS commit: src/sys/fs/tmpfs
| Benefit is code readability. It is easier to track the variables when
| they are defined and initialised in the beginning of context.
|
| If code is longer and/or complex - it
Masao Uebayashi wrote:
> >> The kernel explicitly allows C99 and actually C99 is encouraged.
> >> So that should reverted :)
> >
> > Generally - C99 is encouraged. However, I disagree that variables
> > should be declared in the middle of context (for a minimum scope),
> > unless there is a *clea
On Sat, 14 May 2011, Marc Balmer wrote:
> What is the current state of C99 vs. older Cs? Do all arches /
> compilers we have support C99? I assume gcc, llvm/clang are safe, but
> what about pcc wrt C99?
>
> I'd like a short clarification here, since this might influence my
> coding... tnx.
pcc
Am 14.05.11 10:45, schrieb Anders Magnusson:
[...]
>> What is the current state of C99 vs. older Cs? Do all arches /
>> compilers we have support C99? I assume gcc, llvm/clang are safe, but
>> what about pcc wrt C99?
> pcc should be C99 compliant. If something do not work as expected, I'll
> fix
On 05/14/2011 10:34 AM, Marc Balmer wrote:
Am 10.05.11 02:34, schrieb Matt Thomas:
Module Name:src
Committed By: matt
Date: Tue May 10 00:34:26 UTC 2011
Modified Files:
src/sys/fs/tmpfs: tmpfs_vnops.c
Log Message:
yes, more C99 please (back out previous change).
After
Am 10.05.11 02:34, schrieb Matt Thomas:
> Module Name: src
> Committed By: matt
> Date: Tue May 10 00:34:26 UTC 2011
>
> Modified Files:
> src/sys/fs/tmpfs: tmpfs_vnops.c
>
> Log Message:
> yes, more C99 please (back out previous change).
After this committ/back-out/back-out-pf-th
On Sat, May 14, 2011 at 2:37 AM, Mindaugas Rasiukevicius
wrote:
> Matt Thomas wrote:
>>
>> On May 7, 2011, at 5:03 PM, Christos Zoulas wrote:
>>
>> > Module Name: src
>> > Committed By: christos
>> > Date: Sun May 8 00:03:35 UTC 2011
>> >
>> > Modified Files:
>> >
On Fri, May 13, 2011 at 06:37:53PM +0100, Mindaugas Rasiukevicius wrote:
> Generally - C99 is encouraged. However, I disagree that variables
> should be declared in the middle of context (for a minimum scope),
> unless there is a *clear* benefit. Otherwise, it makes code harder
> to read, esp
Matt Thomas wrote:
>
> On May 7, 2011, at 5:03 PM, Christos Zoulas wrote:
>
> > Module Name:src
> > Committed By: christos
> > Date: Sun May 8 00:03:35 UTC 2011
> >
> > Modified Files:
> > src/sys/fs/tmpfs: tmpfs_vnops.c
> >
> > Log Message:
> > no c99 please.
In message
on Tue, 10 May 2011 07:19:51 +0100 (BST),
Iain Hibbert wrote:
> On Tue, 10 May 2011, Takahiro Kambe wrote:
>
>> In message <20110509170006.GA15831@marx.bitnet>
>> on Mon, 9 May 2011 20:00:06 +0300,
>> Jukka Ruohonen wrote:
>> > On Mon, May 09, 2011 at 06:50:
On Tue, 10 May 2011, Takahiro Kambe wrote:
> In message <20110509170006.GA15831@marx.bitnet>
> on Mon, 9 May 2011 20:00:06 +0300,
> Jukka Ruohonen wrote:
> > On Mon, May 09, 2011 at 06:50:08PM +0200, Adam Hoka wrote:
> >> So can we use "for (int i = 0; ..." ? :p
> lint(1) support them
On May 9, 2011, at 10:00 AM, Jukka Ruohonen wrote:
> On Mon, May 09, 2011 at 06:50:08PM +0200, Adam Hoka wrote:
>> So can we use "for (int i = 0; ..." ? :p
>
> Hopefully not...
For the kernel, "for (int ... " is allowed.
On May 9, 2011, at 4:35 PM, Christos Zoulas wrote:
> | Been doing DEBUG builds with tmpfs for a long time with no problems.
> |
> | > In this case it thinks that "i" is used out of the loop.
> |
> | Where? After the for loop, it returns.
>
> Well, just add back the commented out #CPPFLAGS+=-D
In message <20110509170006.GA15831@marx.bitnet>
on Mon, 9 May 2011 20:00:06 +0300,
Jukka Ruohonen wrote:
> On Mon, May 09, 2011 at 06:50:08PM +0200, Adam Hoka wrote:
>> So can we use "for (int i = 0; ..." ? :p
lint(1) support them?
> Hopefully not...
Me, too.
--
Takahiro Kambe
On May 9, 10:23am, m...@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: CVS commit: src/sys/fs/tmpfs
|
| On May 9, 2011, at 5:25 AM, Christos Zoulas wrote:
|
| > On May 8, 9:21pm, m...@3am-software.com (Matt Thomas) wrote:
| > -- Subject: Re: CVS commit: src/sys/fs/tmpfs
| >=20
On May 9, 2011, at 5:25 AM, Christos Zoulas wrote:
> On May 8, 9:21pm, m...@3am-software.com (Matt Thomas) wrote:
> -- Subject: Re: CVS commit: src/sys/fs/tmpfs
>
> | The kernel explicitly allows C99 and actually C99 is encouraged.
> | So that should reverted :)
>
> T
On Mon, May 09, 2011 at 06:50:08PM +0200, Adam Hoka wrote:
> So can we use "for (int i = 0; ..." ? :p
Hopefully not...
- Jukka.
On Sun, 8 May 2011 21:21:56 -0700
Matt Thomas wrote:
>
> On May 7, 2011, at 5:03 PM, Christos Zoulas wrote:
>
> > Module Name:src
> > Committed By: christos
> > Date: Sun May 8 00:03:35 UTC 2011
> >
> > Modified Files:
> > src/sys/fs/tmpfs: tmpfs_vnops.c
> >
>
On May 8, 9:21pm, m...@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: CVS commit: src/sys/fs/tmpfs
| The kernel explicitly allows C99 and actually C99 is encouraged.
| So that should reverted :)
Test it. Build a DEBUG kernel and when it works, you can or I will revert it.
In this case it
On May 7, 2011, at 5:03 PM, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sun May 8 00:03:35 UTC 2011
>
> Modified Files:
> src/sys/fs/tmpfs: tmpfs_vnops.c
>
> Log Message:
> no c99 please.
The kernel explicitly allows C99 and actually C99 is encour
hi,
> Mindaugas Rasiukevicius wrote:
>
>> Module Name: src
>> Committed By:rmind
>> Date:Wed Nov 11 09:59:42 UTC 2009
>>
>> Modified Files:
>>
>> src/sys/fs/tmpfs: tmpfs_subr.c
>>
>> Log Message:
>>
>> Simplify tmpfs_itimes() and use vfs_timestamp(). [ ... ]
>
>
Simon Burge wrote:
> >
> > Simplify tmpfs_itimes() and use vfs_timestamp(). [ ... ]
>
> Was changing from getnanotime() to effectively nanotime() (via
> vfs_timestamp()) deliberate? The original intention of using
> getnanotime() for filesystem timestamps was that having a "perfect"
> timestam
Mindaugas Rasiukevicius wrote:
> Module Name: src
> Committed By: rmind
> Date: Wed Nov 11 09:59:42 UTC 2009
>
> Modified Files:
>
> src/sys/fs/tmpfs: tmpfs_subr.c
>
> Log Message:
>
> Simplify tmpfs_itimes() and use vfs_timestamp(). [ ... ]
Was changing from getnanotime() to
On Tue Apr 28 2009 at 00:29:05 +, YAMAMOTO Takashi wrote:
> >> Hmm, does this work correctly if you find the component via the
> >> cache_lookup() path?
> >
> > Ok, I dug into this a little. Short answer: no, but ...
> >
> > It seems that cache_lookup() always returns false if MAKEENTRY is n
hi,
> On Fri Apr 24 2009 at 18:00:45 +0300, Antti Kantee wrote:
>> On Sat Apr 11 2009 at 20:42:59 +, Andrew Doran wrote:
>> > On Sat, Apr 11, 2009 at 12:21:57AM +, Perry E. Metzger wrote:
>> >
>> > > Modified Files:
>> > > src/sys/fs/tmpfs: tmpfs_vnops.c
>> > >
>> > > Log Message:
>> >
On Fri Apr 24 2009 at 18:00:45 +0300, Antti Kantee wrote:
> On Sat Apr 11 2009 at 20:42:59 +, Andrew Doran wrote:
> > On Sat, Apr 11, 2009 at 12:21:57AM +, Perry E. Metzger wrote:
> >
> > > Modified Files:
> > > src/sys/fs/tmpfs: tmpfs_vnops.c
> > >
> > > Log Message:
> > > SAVENAME was
On Sat Apr 11 2009 at 20:42:59 +, Andrew Doran wrote:
> On Sat, Apr 11, 2009 at 12:21:57AM +, Perry E. Metzger wrote:
>
> > Modified Files:
> > src/sys/fs/tmpfs: tmpfs_vnops.c
> >
> > Log Message:
> > SAVENAME was not set for rename and delete as required
> >
> > Patch from christos,
hi,
> On Wed Apr 15 2009 at 11:41:26 +, YAMAMOTO Takashi wrote:
>> Module Name: src
>> Committed By:yamt
>> Date:Wed Apr 15 11:41:26 UTC 2009
>>
>> Modified Files:
>> src/sys/fs/tmpfs: tmpfs_vnops.c
>>
>> Log Message:
>> plug some pnbuf leaks.
>
> Shouldn't that
On Fri, Apr 10, 2009 at 10:36:38PM +, Andrew Doran wrote:
> > Might be. I filed a PR for that ages ago and had forgotten all about
> > it by now. See kern/38188.
>
> On the face of it what do you think of:
>
> - preserve pnbuf across entirety of operations that use it
> - retire SAVE
On Fri Apr 10 2009 at 22:36:38 +, Andrew Doran wrote:
> On Sat, Apr 11, 2009 at 01:32:09AM +0300, Antti Kantee wrote:
>
> > On Fri Apr 10 2009 at 21:34:10 +, Andrew Doran wrote:
> > > On Fri, Apr 10, 2009 at 06:57:45PM +0200, Frank Kardel wrote:
> > >
> > > > It may be related: I am now s
On Wed Apr 15 2009 at 11:41:26 +, YAMAMOTO Takashi wrote:
> Module Name: src
> Committed By: yamt
> Date: Wed Apr 15 11:41:26 UTC 2009
>
> Modified Files:
> src/sys/fs/tmpfs: tmpfs_vnops.c
>
> Log Message:
> plug some pnbuf leaks.
Shouldn't that, theoretically, check for SAVES
Andrew Doran writes:
> On Sat, Apr 11, 2009 at 12:21:57AM +, Perry E. Metzger wrote:
>
>> Modified Files:
>> src/sys/fs/tmpfs: tmpfs_vnops.c
>>
>> Log Message:
>> SAVENAME was not set for rename and delete as required
>>
>> Patch from christos, fixes pr 41183
>
> Now it leaks pathname
On Sat, Apr 11, 2009 at 12:21:57AM +, Perry E. Metzger wrote:
> Modified Files:
> src/sys/fs/tmpfs: tmpfs_vnops.c
>
> Log Message:
> SAVENAME was not set for rename and delete as required
>
> Patch from christos, fixes pr 41183
Now it leaks pathname buffers.
Who reviewed this change
On Sat, Apr 11, 2009 at 01:32:09AM +0300, Antti Kantee wrote:
> On Fri Apr 10 2009 at 21:34:10 +, Andrew Doran wrote:
> > On Fri, Apr 10, 2009 at 06:57:45PM +0200, Frank Kardel wrote:
> >
> > > It may be related: I am now seeing a tmpfs uvm_fault():
> > >
> > > hand copied bt:
> > > uvm_faul
On Fri Apr 10 2009 at 21:34:10 +, Andrew Doran wrote:
> On Fri, Apr 10, 2009 at 06:57:45PM +0200, Frank Kardel wrote:
>
> > It may be related: I am now seeing a tmpfs uvm_fault():
> >
> > hand copied bt:
> > uvm_fault()
> > tmpfs_do_detach()
> > tmpfs_remove()
> > VOP_REMOVE()
> > do_sys_unli
On Fri, Apr 10, 2009 at 06:57:45PM +0200, Frank Kardel wrote:
> It may be related: I am now seeing a tmpfs uvm_fault():
>
> hand copied bt:
> uvm_fault()
> tmpfs_do_detach()
> tmpfs_remove()
> VOP_REMOVE()
> do_sys_unlink()
> syscall()
It may be this: http://gnats.netbsd.org/41183
Hello Antti !
It may be related: I am now seeing a tmpfs uvm_fault():
hand copied bt:
uvm_fault()
tmpfs_do_detach()
tmpfs_remove()
VOP_REMOVE()
do_sys_unlink()
syscall()
Frank
Antti Kantee wrote:
Module Name:src
Committed By: pooka
Date: Fri Apr 3 14:47:41 UTC 2009
Modified
56 matches
Mail list logo
