[PATCH 1/3] ext2fs: remove inappropriate assertion
find_block may very well return no error but set block to zero. This indicates that the block in question has not been allocated. Skip those blocks instead. * ext2fs/pager.c (file_pager_write_page): Skip unallocated blocks. --- ext2fs/pager.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/ext2fs/pager.c b/ext2fs/pager.c index 6e99c83..4ea4b74 100644 --- a/ext2fs/pager.c +++ b/ext2fs/pager.c @@ -398,8 +398,10 @@ file_pager_write_page (struct node *node, vm_offset_t offset, void *buf) err = find_block (node, offset, block, lock); if (err) break; - assert (block); - pending_blocks_add (pb, block); + if (block) + pending_blocks_add (pb, block); + else + pending_blocks_skip (pb); offset += block_size; left -= block_size; } -- 1.9.0
[PATCH 2/3] isofs: also copy the terminating zero in read_symlink_hook
* isofs/inode.c (read_symlink_hook): Use memcpy, also copy terminating
zero.
---
isofs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/isofs/inode.c b/isofs/inode.c
index f9d4c41..f542d18 100644
--- a/isofs/inode.c
+++ b/isofs/inode.c
@@ -492,7 +492,7 @@ read_disknode (struct node *np, struct dirrect *dr,
static error_t
read_symlink_hook (struct node *np, char *buf)
{
- bcopy (np-dn-link_target, buf, np-dn_stat.st_size);
+ memcpy (buf, np-dn-link_target, np-dn_stat.st_size + 1);
return 0;
}
error_t (*diskfs_read_symlink_hook) (struct node *, char *)
--
1.9.0
[PATCH 3/3] libdiskfs: fix string termination
Found using the Clang Static Analyzer.
* libdiskfs/fsys-getroot.c (diskfs_S_fsys_getroot): Fix string
termination.
---
libdiskfs/fsys-getroot.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libdiskfs/fsys-getroot.c b/libdiskfs/fsys-getroot.c
index 5212214..10793c8 100644
--- a/libdiskfs/fsys-getroot.c
+++ b/libdiskfs/fsys-getroot.c
@@ -101,15 +101,17 @@ diskfs_S_fsys_getroot (struct diskfs_control *pt,
{
/* Handle symlink interpretation */
char pathbuf[diskfs_root_node-dn_stat.st_size + 1];
- size_t amt;
if (diskfs_read_symlink_hook)
err = (*diskfs_read_symlink_hook) (diskfs_root_node, pathbuf);
if (!diskfs_read_symlink_hook || err == EINVAL)
- err = diskfs_node_rdwr (diskfs_root_node, pathbuf, 0,
+ {
+ size_t amt = 0;
+ err = diskfs_node_rdwr (diskfs_root_node, pathbuf, 0,
diskfs_root_node-dn_stat.st_size, 0,
0, amt);
- pathbuf[amt] = '\0';
+ pathbuf[amt] = '\0';
+ }
pthread_mutex_unlock (diskfs_root_node-lock);
pthread_rwlock_unlock (diskfs_fsys_lock);
--
1.9.0
various fixes
Hi :) [PATCH 1/3] ext2fs: remove inappropriate assertion This is an rfc. I had a root fs die because this assertion failed, and from what I have seen it is not appropriate to assert (block) here. Then again, this pager business is all new to me and I'm not really sure if it is okay to skip blocks like this patch does or if we should instead write a block of zeros here. [PATCH 2/3] isofs: also copy the terminating zero in [PATCH 3/3] libdiskfs: fix string termination To everyone who wants to help out with the Hurd development: Looking through the static analyzer reports is a great way to get started if you know c but are otherwise new to the Hurd. There are still some low-hanging reports left, like the one this patch is addressing: http://darnassus.sceen.net/~teythoon/qa/hurd/scan-build/2014-02-21/report-Y64Nfa.html#EndPath Justus
Re: GNU accepted as a mentoring organization in GSOC 2014
Hi Thomas. On Tue, Feb 25, 2014 at 4:53 PM, Thomas Schwinge tho...@codesourcery.comwrote: GDB: »catch syscall«; pretty-printing of mach_msg. https://www.gnu.org/software/hurd/open_issues/gdb_catch_syscall.html, https://sourceware.org/gdb/onlinedocs/gdb/Set-Catchpoints.html. That translates to us to »break mach_msg« with suitable RPC name matching. Pretty printing of mach_msg arguments à la rpctrace. Might these days be implemented as a Python pretty-printer in GDB. I have some interesting with this ideal. Can I have the permission to participate GSoC twice in Hurd project? With the experience in last summer, I think I can implement this ideal. But I am not sure if a student can apply a project for twice. -- Yue Lu (陆岳)
Re: [GSOC] Porting Valgrind to Hurd
Hello, Subhashish Pradhan, le Wed 19 Mar 2014 02:48:53 +0530, a écrit : Previously I had some discussions and queries related to this project on this mailing list, but disappeared for a while, my apologies. No problem, welcome back :) I am working on implementing PRE() and POST() wrappers for a custom ioctl on Linux. Ok, out of curiosity, what are you working on? With that as reference, I have the following (broad) steps in mind to complete the project: 1. Investigate into the workings of the 46 system calls in gnumach/include/mach/syscall_sw.h and make a report of how to approach them (to be done before the coding period starts) Yes, it is good that you get an idea of what this looks like, at least to show that you understand how the work will look like. You can however already note that a good part of them are not actually needed: syscall_sw.h gives the declaration, but see kern/syscall_sw.c to see which of them are actually implemented, that's actually a lot less, boiling down to perhaps two dozens. 2. Implement the PRE() POST() wrappers for each of the 46 system calls in valgrind source. (Specifically valgrind/coregrind/m_syswrap/syswrap-hurd.c) Probably starting from the easiest ones (e.g. mach_task_self) and try that already before trying more of them. But even before that I guess you will have to explain valgrind what a syscall looks like on Mach (i.e. it's actually a trap). The big part will be explaining valgrind how mach_msg_trap works, and it's a complex one. But once it's done, you'll get all the RPCs (done through it) done. 4. Build a working source under an instance of Hurd - generation of makefiles, dependencies, and scripts. (The first deliverable) That will probably be very early in the coding period actually. Better get that working, then implement some PRE/POST, and check that those are working. 5. If the time permits, my second deliverable would be a binary package for Debian/Hurd. That should actually probably be quite easy: simply apply your patch to the existing package, and see it compiled. Q1 - May I port the newest version of Valgrind or should it pose a problem? Better start with the latest rather than having to merge with a newer version. Q2 - Is there an equivalent of tracing program like strace in linux which can show what syscalls are being executed for a given program? Mmm, I don't know about something for syscalls. We do have rpctrace which shows RPC calls, and that's usually what people need since it shows filesystem operations etc. and even Mach functions are usually performed via RPCs, not syscalls. Syscalls are actually a rare thing in a Hurd system: processes mostly make mach_msg_trap syscalls, to perform RPCs. Anybody knows about tracing the syscalls? I don't see anything for that in the kernel. Samuel
Re: GNU accepted as a mentoring organization in GSOC 2014
Hi! Welcome back! ;-) On Thu, 20 Mar 2014 22:40:13 +0800, Yue Lu hacklu.newb...@gmail.com wrote: On Tue, Feb 25, 2014 at 4:53 PM, Thomas Schwinge tho...@codesourcery.comwrote: GDB: »catch syscall«; pretty-printing of mach_msg. https://www.gnu.org/software/hurd/open_issues/gdb_catch_syscall.html, https://sourceware.org/gdb/onlinedocs/gdb/Set-Catchpoints.html. That translates to us to »break mach_msg« with suitable RPC name matching. Pretty printing of mach_msg arguments à la rpctrace. Might these days be implemented as a Python pretty-printer in GDB. I have some interesting with this ideal. Also, your gdbserver work still needs to be integrated upstream, so that is another thing to work on. Can I have the permission to participate GSoC twice in Hurd project? With the experience in last summer, I think I can implement this ideal. But I am not sure if a student can apply a project for twice. Yes, that is possible, http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page#9._I_am_a_student_who_has_already. The requirement, of course, is that you're still a student, http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2014/help_page#2._Whos_eligible_to_participate_as_a. The deadline for sending in your project proposal is tomorrow, so don't miss that, and it will then be discussed in the following weeks. Grüße, Thomas pgpRBRyvQwbKR.pgp Description: PGP signature
Re: [GSOC] Porting Valgrind to Hurd
Hello, Thanks for feedback! On Thu, Mar 20, 2014 at 9:00 PM, Samuel Thibault samuel.thiba...@gnu.org wrote: Hello, Subhashish Pradhan, le Wed 19 Mar 2014 02:48:53 +0530, a écrit : Previously I had some discussions and queries related to this project on this mailing list, but disappeared for a while, my apologies. No problem, welcome back :) I am working on implementing PRE() and POST() wrappers for a custom ioctl on Linux. Ok, out of curiosity, what are you working on? The starter task (teaching valgrind about ioctls; to use read/write primitives of Valgrind) is performed as follows: 1 - writing of a dummy kernel module 2 - insmod-ing it into a running kernel 3 - writing a user program that uses this ioctl 4 - compiling valgrind 5 - invoking valgrind on the user application 6 - It reports there is an unhandled ioctl 0x6b00 with no size/redirection hints and redirects me to a faq documentatiion README_MISSING_SYSCALL_OR_IOCTL to write PRE() and POST() wrappers - the syscall wrappers. 7 - I was stuck reading the code of valgrind/coregrind/m_syswrap/syswrap-linux.c @ lines 5451 8 - a strace on the client tells me that the ioctl takes two parameters so 9 - from this and the ioctl wrapper code it seems that, I have to add some code to switch(ARG2 /* request */) but have been lazy to do so; May I do so after the student application deadline passes? - it's making me unfocused ... You can however already note that a good part of them are not actually needed: syscall_sw.h gives the declaration, but see kern/syscall_sw.c to see which of them are actually implemented, that's actually a lot less, boiling down to perhaps two dozens. 2. Implement the PRE() POST() wrappers for each of the 46 system calls in valgrind source. (Specifically valgrind/coregrind/m_syswrap/syswrap-hurd.c) Probably starting from the easiest ones (e.g. mach_task_self) and try that already before trying more of them. But even before that I guess you will have to explain valgrind what a syscall looks like on Mach (i.e. it's actually a trap). The big part will be explaining valgrind how mach_msg_trap works, and it's a complex one. But once it's done, you'll get all the RPCs (done through it) done. I found kern/syscall_sw.c couple of days ago and was wondering about the difference between the .h and .c variants; but I waited for your feedback. The implemented traps matter. But are the others a dummy filler to be implemented when required? I also found that there is a coregrind/m_syswrap/syswrap-darwin.c which has some mach wrappers. It'd be an interesting reference but I haven't gone through the code. Can a Darwin VM be used to study that or would it be a waste of time? I think that if I delve into that I should do that during community bonding period. 4. Build a working source under an instance of Hurd - generation of makefiles, dependencies, and scripts. (The first deliverable) That will probably be very early in the coding period actually. Better get that working, then implement some PRE/POST, and check that those are working. Hmm. Yes, that would be a better way - I could write client programs that use those RPCs and then invoke rpctrace and Valgrind on them and then proceed like the workflow on the starter task. ... Q1 - May I port the newest version of Valgrind or should it pose a problem? Better start with the latest rather than having to merge with a newer version. By latest do you mean the trunk version, I presume? Or the current release? Sorry for the big, detailed reply. I guess I should start blogging my reports. Regards, Subhashish Pradhan
GSoC deadline for proposals
Hello, Apparently, the deadline for proposals is tomorrow (March 21). Students indenting to participate should be careful not to miss it. -- Richard Braun
Re: [GSOC] Porting Valgrind to Hurd
Hi :) Quoting Samuel Thibault (2014-03-20 16:30:23) Anybody knows about tracing the syscalls? I don't see anything for that in the kernel. http://www.gnu.org/software/hurd/gnumach-doc/Syscall-Emulation.html Justus
libpthread fails to build as an add-on
(Hurd people: this is about a configure error when cross-compiling glibc with libpthread as an add-on.) Manolis Ragkousis manolis...@gmail.com skribis: when building glibc with libpthread as an addon I get this configure: running configure fragment for add-on libpthread configure: WARNING: you should use --build, --host, --target configure: WARNING: you should use --build, --host, --target checking build system type... Invalid configuration `dummy': machine `dummy' not recognized configure: error: /gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash ../source/scripts/config.sub dummy failed Normally the flags passed to glibc's configure should be passed to libpthread as well. Why isn't it happening? Actually libc’s configure doesn’t use the normal AC_CONFIG_SUBDIRS mechanism, and instead runs add-on configure scripts by itself, without arguments AFAICS. [...] It was created by GNU C Library configure (see version.h), which was generated by GNU Autoconf 2.68. Invocation command line was $ ../source/configure dummy readelf (This is libpthread’s config.log, right?) I don’t understand where those arguments come from. Ideas? Thanks, Ludo’.
Re: libpthread fails to build as an add-on
(This is libpthread's config.log, right?) It's the config.log generated in the build folder of glibc. There is no config.log file generated from libpthread. Manolis starting phase `configure' source directory: /tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-4/source (relative from build: ../source) build directory: /tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-4/build configure flags: (CONFIG_SHELL=/gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash SHELL=/gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash --prefix=/gnu/store/38sz5a5r2mimzg31jg2wdvk1f173iphx-glibc-hurd-cross-i686-pc-gnu-2.18 --enable-fast-install --target=i686-pc-gnu --without-cvs --enable-add-ons=libpthread --build=i686-pc-gnu --disable-profile --disable-multi-arch --disable-sanity-checks libc_cv_localedir=/gnu/store/17kg9lw4laxglif9kdcgy6vc2yz366yx-glibc-hurd-cross-i686-pc-gnu-2.18-locales/share/locale BASH_SHELL=/gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash) checking build system type... i686-pc-gnu checking host system type... i686-pc-gnu checking for gcc... gcc checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for readelf... readelf checking for sysdeps preconfigure fragments... x86_64 configure: running configure fragment for add-on libpthread configure: WARNING: you should use --build, --host, --target configure: WARNING: you should use --build, --host, --target checking build system type... Invalid configuration `dummy': machine `dummy' not recognized configure: error: /gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash ../source/scripts/config.sub dummy failed phase `configure' failed after 0 seconds This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU C Library configure (see version.h), which was generated by GNU Autoconf 2.68. Invocation command line was $ ../source/configure dummy readelf ## - ## ## Platform. ## ## - ## hostname = localhost uname -m = x86_64 uname -r = 3.13.6-1-ARCH uname -s = Linux uname -v = #1 SMP PREEMPT Fri Mar 7 22:47:48 CET 2014 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /gnu/store/6bg25h0pzgscds0br7dzs7lf3vqskl96-gcc-cross-hurd-sans-libc-i686-pc-gnu-4.8.2/bin PATH: /gnu/store/nkrr16lw55p75483z2an0c67nnqdm4l5-binutils-cross-i686-pc-gnu-2.23.2/bin PATH: /gnu/store/m2qn6kv6n00ris4l9mwfl7wadxrbll6g-mig-cross-1.4/bin PATH: /gnu/store/qdd0hz0sclms1rz3ss01f75r3ys8r58z-perl-5.16.1/bin PATH: /gnu/store/bvw355kwjr21kcfckzlm22ag03xamj27-autoconf-wrapper-2.69/bin PATH: /gnu/store/yvfsm45m5g8m2ikj8gvnq6260azwbrbk-automake-1.14.1/bin PATH: /gnu/store/nr4xwiv2v7n97ib29dpf8gi2562y5294-libtool-2.4.2-bin/bin PATH: /gnu/store/x26nnlh6azmnd0ibdyfwafdc6rkzx17w-bash-light-4.2/bin PATH: /gnu/store/f4v605p9fva9kjragznh3l28nfpzmcqp-tar-1.27.1/bin PATH: /gnu/store/7267cq3clzcbgd1k7s5rg0i0vp2yklpl-gzip-1.6/bin PATH: /gnu/store/a1ir9y0bgaazp6n58y3qbhmfymjq3yxq-bzip2-1.0.6/bin PATH: /gnu/store/1zs7xnaby6vl49195sid1klx3gk03mwd-xz-5.0.4/bin PATH: /gnu/store/2ly72pfnmg28ps7jdj83516gvbn6371j-diffutils-3.3/bin PATH: /gnu/store/1qdk13ly4c5iqqz7nay0x4fn6ls5r1b9-patch-2.7.1/bin PATH: /gnu/store/gjl05yl9lvgjhznz5v985mys861svp34-coreutils-8.21/bin PATH: /gnu/store/sj5ivydxwm1943y2g06vhwfwpn9hc1a1-sed-4.2.2/bin PATH: /gnu/store/v2q2595q6n4gs32j15ga65bgy0yqg76g-grep-2.15/bin PATH: /gnu/store/r534qbhj6jni2x30q4rgl8ry8rilarak-findutils-4.4.2/bin PATH: /gnu/store/3j4pxqg9rskk9365m6jqi59pvcyq1d82-gawk-4.1.0/bin PATH: /gnu/store/pwm61di9kpfks4acn0k6kp2rwa0wjl5j-make-4.0/bin PATH: /gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin PATH: /gnu/store/r7lpkp8d2df74rw24ndcivxvjzdgxn8d-ld-wrapper-0/bin PATH: /gnu/store/xbryfykc21adgrq3z56g4c6xvv2lb645-binutils-2.23.2/bin PATH: /gnu/store/z8qifq9172ad17a7mxg9w8jq51axwwqr-gcc-4.8.2/bin PATH: /gnu/store/5v11czsqd9x9xqvsww9dk7h5i47laym0-glibc-2.18/bin PATH: /gnu/store/5v11czsqd9x9xqvsww9dk7h5i47laym0-glibc-2.18/sbin ## --- ## ## Core tests. ## ## --- ## configure:2338: checking build system type configure:2349: error: /gnu/store/281n6ma5jxy9sb3nwc09mzpqx43vczr6-bash-4.2/bin/bash ../source/scripts/config.sub dummy failed ## ## ## Cache variables. ## ## ## ac_cv_build= ac_cv_env_CCC_set= ac_cv_env_CCC_value= ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value=
Re: [GSOC] Porting Valgrind to Hurd
Justus Winter, le Thu 20 Mar 2014 18:27:58 +0100, a écrit : Quoting Samuel Thibault (2014-03-20 16:30:23) Anybody knows about tracing the syscalls? I don't see anything for that in the kernel. http://www.gnu.org/software/hurd/gnumach-doc/Syscall-Emulation.html Ah, right. But do we have tools using that? Samuel
