As noted in passing elsewhere, it seems that process_write() in
spiflash.c allocates a scratch buffer on every call... and leaks it on
every call too. This clearly isn't a good thing.
Meanwhile the size of buffer it tries to allocate doesn't have any
obvious bound; I suspect it's limited to MAXPHY
On Sun, Sep 06, 2015 at 02:36:07PM +0200, Maxime Villard wrote:
> Le 30/08/2015 06:43, David Holland a ?crit :
> > On Fri, Aug 28, 2015 at 11:17:24AM +0200, Maxime Villard wrote:
> > > _11/ UNINITIALIZED VAR: sys/dev/ic/sgec.c
> > > _12/ USE-AFTER-FREE: sys/arch/mips/alchemy/dev/aupcmcia.c
>
On Mon, Sep 07, 2015 at 09:13:11PM +0100, David Laight wrote:
> > There's another problem this thread hasn't mentioned, which is that
> > the result of vnode_to_path for non-directories isn't necessarily
> > unique or deterministic even if the object hasn't been moved about.
>
> Perhaps the k
On 2015/09/08 0:59, Jonathan A. Kollasch wrote:
> - abuse of the pcitag_t (I have patches that fix this.)
Your patches? Where? your local?
> - pci_conf_size() is unnecessary
Why?
--
MAEKAWA Masahide
https://github.com/cvsync
Use the Source, Luke
On Mon, Sep 07, 2015 at 07:01:45PM +, David Holland wrote:
> On Mon, Sep 07, 2015 at 11:13:35AM +0200, Joerg Sonnenberger wrote:
> > > Two nits:
> > >
> > > 1) vnode_to_path(9) is undocumented
> > > 2) it only works if you are lucky (IIUC) - which you mostly are
> > >
> > > The former
On Mon, Sep 07, 2015 at 11:13:35AM +0200, Joerg Sonnenberger wrote:
> > Two nits:
> >
> > 1) vnode_to_path(9) is undocumented
> > 2) it only works if you are lucky (IIUC) - which you mostly are
> >
> > The former is easy to fix, the latter IMHO is a killer before we expose
> > this inter
> - too much ACPI dependence, there's nothing that says you have to use
>ACPI MCFG to get this information
in particular, there is way too much ACPI specific code in pci_machdep.c
with this change. whatever of that code remains should mostly be moved
into an ACPI specific file (possibly acpi
On Mon, Sep 07, 2015 at 06:14:59PM +0900, Masanobu SAITOH wrote:
> Hi, all.
>
> nonaka@ wrote code to access PCI extended configuration area.
> Currently, the diff supoorts only on x86.
>
>
> http://ftp.netbsd.org/pub/NetBSD/misc/nonaka/tmp/nbsd-pci-extconf-support.diff
>
> Is it OK to
Hello there,
Le 2015-09-07 12:24, Kamil Rytarowski a écrit :
I'm here to get the support for it. At the moment it (cache nits)
exceeds my comprehension too.
Are the other bits ok? KAUTH usage,
I wouldn't create an action/subaction (AUTH_PROCESS_REALPATH and
KAUTH_REQ_PROCESS_REALPATH_GET) sp
Date:Mon, 07 Sep 2015 12:24:58 +0200
From:Kamil Rytarowski
Message-ID: <55ed65fa.1000...@gmx.com>
| I'm here to get the support for it. At the moment it (cache nits)
| exceeds my comprehension too.
What is the semantic you're hoping to provide? The path that wa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07.09.2015 10:47, Stephan wrote:
> Wasn´t this the same as with RPATH and the name cache?
>
> 2015-09-07 9:23 GMT+02:00 Martin Husemann :
>> On Mon, Sep 07, 2015 at 03:50:21AM +0200, Kamil Rytarowski
>> wrote:
>>> + error = vnode_to_path(path
Hi, all.
nonaka@ wrote code to access PCI extended configuration area.
Currently, the diff supoorts only on x86.
http://ftp.netbsd.org/pub/NetBSD/misc/nonaka/tmp/nbsd-pci-extconf-support.diff
Is it OK to commit?
--
---
SAIT
On Mon, Sep 07, 2015 at 09:23:21AM +0200, Martin Husemann wrote:
> On Mon, Sep 07, 2015 at 03:50:21AM +0200, Kamil Rytarowski wrote:
> > + error = vnode_to_path(path, MAXPATHLEN,vp, l, p);
>
> Two nits:
>
> 1) vnode_to_path(9) is undocumented
> 2) it only works if you are lucky (IIUC) - which
Wasn´t this the same as with RPATH and the name cache?
2015-09-07 9:23 GMT+02:00 Martin Husemann :
> On Mon, Sep 07, 2015 at 03:50:21AM +0200, Kamil Rytarowski wrote:
>> + error = vnode_to_path(path, MAXPATHLEN,vp, l, p);
>
> Two nits:
>
> 1) vnode_to_path(9) is undocumented
> 2) it only wor
On Mon, Sep 07, 2015 at 03:50:21AM +0200, Kamil Rytarowski wrote:
> + error = vnode_to_path(path, MAXPATHLEN,vp, l, p);
Two nits:
1) vnode_to_path(9) is undocumented
2) it only works if you are lucky (IIUC) - which you mostly are
The former is easy to fix, the latter IMHO is a killer befor
15 matches
Mail list logo