On 3 Nov 2019, at 16:20, Samuel Thibault wrote:
>
> Hello,
>
> Joan Lledó via Bug reports for the GNU Hurd, le dim. 03 nov. 2019 10:38:28
> +0100, a ecrit:
>> * pci-arbiter/pcifs.c:
>>* create_dir_entry:
>> Limit to NAME_SIZE-1 when calling strncpy().
>>
On 19 Jul 2019, at 23:15, Almudena Garcia wrote:
>
> Forwarded to bug-hurd maillist
>
> -- Forwarded message -
> De: Andrew Eggenberger
> Date: vie., 19 jul. 2019 a las 20:11
> Subject: mapped-time interface
> To:
>
>
> This gnu Mach reference manual page [1] refers to a
On 15 Feb 2019, at 13:33, Almudena Garcia wrote:
> El vie., 15 feb. 2019 a las 14:28, James Clarke ()
> escribió:
>> On 15 Feb 2019, at 13:21, Samuel Thibault wrote:
>> >
>> > Almudena Garcia, le ven. 15 févr. 2019 14:13:17 +0100, a ecrit:
>> >> This
On 15 Feb 2019, at 13:21, Samuel Thibault wrote:
>
> Almudena Garcia, le ven. 15 févr. 2019 14:13:17 +0100, a ecrit:
>> This is defined in imps/cpu_number.h , included in kern/cpu_number.h
>
> cswitch.S includes i386/cpu_number.h, not kern/cpu_number.h
>
> Really, make sure it gets defined,
On 8 Jun 2018, at 18:06, Joshua Branson wrote:
>
> Almudena Garcia writes:
>
>> Hi all:
>>
>> Reading this post in Hurd FAQ, I read that Mach has SMP support, but It was
>> disabled because the Linux device drivers glue code isn't thread-safe.
>>
>>
On 26 Mar 2018, at 18:20, Svante Signell wrote:
> On Mon, 2018-03-26 at 19:06 +0200, Samuel Thibault wrote:
>> Svante Signell, on lun. 26 mars 2018 18:50:20 +0200, wrote:
>>> I just saw:
>>> https://anonscm.debian.org/viewvc/gcccvs?view=revision=10084
>>>
>>> This is
On 18 Dec 2017, at 17:09, Samuel Thibault <samuel.thiba...@gnu.org> wrote:
> James Clarke, on lun. 18 déc. 2017 17:06:28 +, wrote:
>> On 18 Dec 2017, at 16:28, Samuel Thibault <samuel.thiba...@gnu.org> wrote:
>>> Joan Lledó, on lun. 18 déc. 2017 17:10:42 +0100, wr
On 18 Dec 2017, at 16:28, Samuel Thibault wrote:
> Joan Lledó, on lun. 18 déc. 2017 17:10:42 +0100, wrote:
>> 2017-12-18 14:46 GMT+01:00 Samuel Thibault :
>>> We need to know what is not yet in upstream, what will
>>> eventually get to upstream,
On 20 Sep 2017, at 11:08, Joan Lledó wrote:
>
> ---
> eth-multiplexer/Makefile | 2 +-
> eth-multiplexer/device_impl.c | 5 +
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/eth-multiplexer/Makefile b/eth-multiplexer/Makefile
> index
Hi Joan,
On 24 Aug 2017, at 18:49, Joan Lledó wrote:
> ...
> diff --git a/config.make.in b/config.make.in
> index dfbf0c1..f74220e 100644
> --- a/config.make.in
> +++ b/config.make.in
> @@ -99,6 +99,13 @@ HAVE_SUN_RPC = @HAVE_SUN_RPC@
> # Whether we found libgcrypt.
>
> On 4 Jun 2016, at 15:04, James Clarke <jrt...@jrtc27.com> wrote:
>
>> On 3 Jun 2016, at 19:36, Samuel Thibault <samuel.thiba...@gnu.org> wrote:
>>
>> Samuel Thibault, on Fri 03 Jun 2016 20:35:13 +0200, wrote:
>>> Adam Richards, on Fri 03 Jun
> On 3 Mar 2016, at 14:47, Justus Winter <4win...@informatik.uni-hamburg.de>
> wrote:
> Quoting Samuel Thibault (2016-02-28 22:29:52)
>> We'll probably want to have a copyright assignement from you for this
>> work. I have pasted below the form for this. If you're to contribute
>> more to
On 7 Feb 2016, at 14:51, Flavio Cruz wrote:
> - cred = netfs_make_protid (netfs_make_peropen (node, flags, cookie2),
> - user);
> + po = netfs_make_peropen (node, flags, cookie2);
> + if (! po)
> +return errno;
You need to free user.
James
* libnetfs/trans-callback.c (_netfs_translator_callback2_fn): Fixed leaking
iouser and peropen structs on error.
---
libnetfs/trans-callback.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libnetfs/trans-callback.c b/libnetfs/trans-callback.c
index 3f1aee6..7816bd1
> On 7 Feb 2016, at 23:10, Samuel Thibault wrote:
> Flávio Cruz, on Sun 07 Feb 2016 23:57:25 +0100, wrote:
>> Maybe here we should do it as follows:
>>
>> err = errno;
>> netfs_release_peropen (po);
>> iohelp_free_iouser (user);
>> return err;
>
> Yes, you never know
* libnetfs/trans-callback.c (_netfs_translator_callback2_fn): Fixed leaking
iouser and peropen structs on error.
---
libnetfs/trans-callback.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libnetfs/trans-callback.c b/libnetfs/trans-callback.c
index
On 4 Jan 2016, at 22:13, Samuel Thibault wrote:
> Svante Signell, on Mon 04 Jan 2016 23:09:00 +0100, wrote:
>> Obviously the !defined(@val) is
>> no longer allowed, and I don't know how to rewrite that condition.
>
> Perhaps juste !@val?
> I have no idea, I don't know
Signed-off-by: James Clarke <jrt...@jrtc27.com>
---
login-utils/sulogin-consoles.c | 8
1 file changed, 8 insertions(+)
diff --git a/login-utils/sulogin-consoles.c b/login-utils/sulogin-consoles.c
index 39d24d2..1b05b38 100644
--- a/login-utils/sulogin-consoles.c
+++ b/login
This seems to be caused by a segfault, so I imagine this is not intended!
Tracking down the cause...
James
On Tue, 29 Sep 2015, James Clarke wrote:
Whilst looking through the code in utils/login.c, I noticed a security issue.
Even if --paranoid is set, if you give it a UID that doesn’t
The getpwnam_r and similar functions only return non-zero on error, but not
finding the given name/UID/GID does not count as an error. When they return 0,
the value of the result (*result when looking at the arguments in the man pages)
still needs to be checked for null.
*
This stops /bin/login segfaulting when giving it a bad UID. However, the fact
that the UID does not exist is still leaked, since
libshouldbeinlibc/idvec-verify.c:verify_id falls back on asking for the root
password, and indicates this by changing the prompt to "Password for root".
James
Whilst looking through the code in utils/login.c, I noticed a security issue.
Even if --paranoid is set, if you give it a UID that doesn’t exist (login
treats it as a UID if the first character is a digit, with no fallback to
treating it as a username), it will exit without prompting for a
That’s an issue with the current Hurd repo on Savannah. You need this patch
http://darnassus.sceen.net/gitweb/teythoon/packaging/hurd.git/blob/HEAD:/debian/patches/proc-task-notify-0005-proc-fix-build.patch,
from what I gather (at least it fixes it for me).
James
> On 24 Sep 2015, at 13:50,
<samuel.thiba...@gnu.org> wrote:
>
> Hello,
>
> James Clarke, le Sat 12 Sep 2015 00:42:05 +0100, a écrit :
>> This adds support for CSI s and u, which are equivalent to ESC 7 and 8,
>> saving/restoring the cursor position.
>
> Just curious: in which case did you s
This adds support for CSI s and u, which are equivalent to ESC 7 and 8,
saving/restoring the cursor position.
* console/display.c (handle_esc_bracket): Added support for CSI s and u.
---
console/display.c | 12
1 file changed, 12 insertions(+)
diff --git a/console/display.c
* libports/Makefile (installhdrs): Add port-deref-deferred.h for ports.h
---
libports/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libports/Makefile b/libports/Makefile
index b8b82ee..af881f8 100644
--- a/libports/Makefile
+++ b/libports/Makefile
@@ -38,7 +38,7 @@
Yes, that was a mistake, it should call kd_putc_esc.
James
On 29 Aug 2015, at 11:55, Samuel Thibault samuel.thiba...@gnu.org wrote:
James Clarke, le Sat 29 Aug 2015 11:53:57 +0100, a écrit :
I never gave that as an option?
? I understand even less. AIUI, before kd_start had esc support
that was the right decision?
James
On 29 Aug 2015, at 11:20, Samuel Thibault samuel.thiba...@gnu.org wrote:
James Clarke, le Sat 29 Aug 2015 11:15:29 +0100, a écrit :
@@ -1069,33 +1068,12 @@ kdstart(struct tty *tp)
break;
if ((tp-t_outq.c_cc = 0) || (ch = getc(tp-t_outq
I never gave that as an option?
James
On 29 Aug 2015, at 11:44, Samuel Thibault samuel.thiba...@gnu.org wrote:
James Clarke, le Sat 29 Aug 2015 11:42:38 +0100, a écrit :
Yes, it should be; since I didn't catch that I'd guess nothing in Mach/Hurd
is actually using escape codes.
I
* i386/i386at/kd.c (kdstart): Moved escape sequence handling to new
kd_putc_esc function.
(kd_putc_esc): New function with logic from kdstart.
(kdcnputc): Call kd_putc_esc rather than kd_putc to allow for ANSI
escape codes.
* i386/i386at/kd.h (kd_putc_esc): New function.
---
i386/i386at/kd.c | 63
On some systems, ext2fs.static would regularly hang at startup, as a
race condition meant it would process paging requests while remounting.
To fix this, libpager has been altered to allow inhibiting and resuming
its worker threads, and ext2fs uses this to inhibit paging while
remounting.
*
Not sure how I missed that; will grep for any others.
James
On 14 Aug 2015, at 13:16, Justus Winter 4win...@informatik.uni-hamburg.de
wrote:
Quoting James Clarke (2015-07-23 19:33:42)
diff --git a/libdiskfs/disk-pager.c b/libdiskfs/disk-pager.c
index 008aa2d..33b109c 100644
On some systems, ext2fs.static would regularly hang at startup, as a
race condition meant it would process paging requests while remounting.
To fix this, libpager has been altered to allow inhibiting and resuming
its worker threads, and ext2fs uses this to inhibit paging while
remounting.
*
On some systems, ext2fs.static would regularly hang at startup, as a
race condition meant it would process paging requests while reounting.
To fix this, libpager has been altered to allow inhibiting and resuming
its worker threads.
* console/pager.c (pager_requests): New variable.
On some systems, ext2fs.static would regularly hang at startup, as a
race condition meant it would process paging requests while remounting.
To fix this, libpager has been altered to allow inhibiting and resuming
its worker threads, and ext2fs uses this to inhibit paging while
remounting.
*
Perhaps; I was following what diskfs_remount does when inhibiting RPCs, which
stay inhibited on error.
James
On 23 Jul 2015, at 00:51, Diego Nieto Cid dnie...@gmail.com wrote:
Hi
This is me being picky about a corner case :-)
2015-07-22 19:42 GMT-03:00 James Clarke jrt...@jrtc27.com
---
ext2fs/ext2fs.c | 18 +++
ext2fs/ext2fs.h | 6 +++
ext2fs/pager.c | 35 +-
fatfs/fatfs.h| 2 +
fatfs/pager.c| 35 +-
libdiskfs/disk-pager.c | 3 +-
libdiskfs/diskfs-pager.h | 1 +
libpager/demuxer.c
debugger), so I
need to do some more debugging to see why.
James
On 19 Jul 2015, at 15:00, Richard Braun rbr...@sceen.net wrote:
On Sun, Jul 19, 2015 at 02:25:14PM +0100, James Clarke wrote:
Yeah, I tried inhibiting both buckets, but the paging RPCs still got
through, so my guess
4win...@informatik.uni-hamburg.de
wrote:
Hello James :)
Quoting James Clarke (2015-07-15 22:20:57)
I had a look today at what's happening, and it's that the *file*
pager is trying to read from disk. Any thoughts?
There is another thing I forgot. libpager is special, it has its own
/runsystem.sh (look for `XXX').
Quoting Richard Braun (2015-07-13 10:16:14)
On Sun, Jul 12, 2015 at 12:56:31PM +0100, James Clarke wrote:
That doesn’t seem to boot at all. I had tried changing it to inhibiting all
RPCs (it looks like you’ve inhibited an extra class?), but it seems that
paging
Winter 4win...@informatik.uni-hamburg.de
wrote:
Quoting James Clarke (2015-07-11 22:33:44)
I did some more digging around today. I think what’s happening is
that ext2fs tries to handle a pager RPC while the disk is being
remounted
Sounds plausible. Could you try:
http
-request.c:113 (_pager_S_memory_object_data_request)
5 libpager/memory_objectServer.c:443 (_Xmemory_object_data_request)
6 libpager/demuxer.c:215 (worker_func)
7 libpthread/pthread/pt-create.c:64 (entry_point)
James Clarke
On 27 Jun 2015, at 20:34, Richard Braun rbr...@sceen.net wrote
an idea how this situation could be occurring?
James Clarke
43 matches
Mail list logo