Bug#399904: gnupg: --list-keys hangs at ctrl-C

2013-07-11 Thread NIIBE Yutaka
This is follow up to the bug #399904 in Debian. It is now assigned to libc6, but I think that this would be a bug of GnuPG 1.4.x. The call sequence in question is: g10/signal.c:got_fatal_signal - util/dotlock.c:dotlock_remove_lockfiles - util/dotlock.c:dotlock_destroy -

Bug#561203: threads and fork on machine with VIPT-WB cache

2010-04-04 Thread NIIBE Yutaka
Thanks a lot for the discussion. James Bottomley wrote: So your theory is that the data the kernel sees doing the page copy can be stale because of dirty cache lines in userspace (which is certainly possible in the ordinary way)? Yes. By design that shouldn't happen: the idea behind COW

Bug#561203: threads and fork on machine with VIPT-WB cache

2010-04-04 Thread NIIBE Yutaka
retitle 561203 threads and fork on machine with VIPT-WB cache reassign 561203 linux-2.6 thanks As I am sure that this bug lives in kernel, I do reassign and retitle. -- -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Bug#561203: threads and fork on machine with VIPT-WB cache

2010-04-02 Thread NIIBE Yutaka
NIIBE Yutaka wrote: To have same semantics as other archs, I think that VIPT-WB cache machine should have cache flush at ptep_set_wrprotect, so that memory of the page has up-to-date data. Yes, it will be huge performance impact for fork. But I don't find any good solution other than this yet

Bug#561203: threads and fork on machine with VIPT-WB cache

2010-04-01 Thread NIIBE Yutaka
Hi there, I think that I am catching a bug for threads and fork. I found it when debugging FTBFS of Gauche, a Scheme interpreter. As I think that the Debian bug #561203 has same cause, I am CC:-ing to the BTS too. Please send Cc: to me, I am not on linux-parisc list. Here, I am talking

Bug#561203: threads and fork on machine with VIPT-WB cache

2010-04-01 Thread NIIBE Yutaka
Thanks for your quick reply. James Bottomley wrote: In COW breaking, the page table entry is copied, so A and B no longer have page table entries at the same physical location. If the COW is intact, A and B have the same physical page, but it's also accessed by the same virtual address,

Bug#575351: [HPPA] This is not the bug of GCC but glibc

2010-03-29 Thread NIIBE Yutaka
I am looking the file: eglibc-2.10.2/ports/sysdeps/unix/sysv/linux/hppa/nptl/sysdep-cancel.h It doesn't have any cfi directives. I think that it is the cause of this problem. When adding cfi directives, it would be good to add nocancel version of functions. -- -- To UNSUBSCRIBE, email to

Bug#283597: [PATCH] more patch

2004-11-29 Thread NIIBE Yutaka
Sorry, two more files are needed. Please apply this patch after applying the patch I send earlier. GNU C library has successfully (cross) compiled with those header files. * include/asm-m32r/{m32r.h,page.h}: New files. -- NIIBE Yutaka [EMAIL PROTECTED] Tue, 30 Nov 2004 11:50:50 +0900 diff