From bulten at netmarkpatent.com Thu Oct 4 07:04:05 2007 From: bulten at netmarkpatent.com (NETMARK PATENT) Date: Thu, 4 Oct 2007 10:04:05 +0300 Subject: =?windows-1254?q?T=FCrk_Patent_Enstit=FCs=FC_ve_Mo=F0olistan_Fik?= =?windows-1254?q?ri_M=FClkiyet_Ofisi_Dayan=FD=FEmas=FD?= Message-ID: <3843-220071044745218@ugur> T?rk Patent Enstit?s? ve Mo?olistan Fikri M?lkiyet Ofisi Dayan??mas? T?rk Patent Enstit?s? (TPE) ve Mo?olistan Fikri M?lkiyet Ofisi (IPOM) aras?ndaki teknik i?birli?i g?r??meleri 21-23 A?ustos 2007 tarihlerinde Mo?olistan'?n Ulan Batur ?ehrinde ger?ekle?tirildi. IPOM personelinin co?rafi i?aretler ve enformasyon faaliyetleri e?itimi, TPE e?-ba?kanl???nda y?r?t?lmekte olan ?slam Konferans? Te?kilat? Projesi ve Ekonomik ??birli?i ?rg?t? alt?nda d?zenlenebilecek e?itimlere Mo?olistan'?n da kat?l?m?n? ?ng?ren bir faaliyet plan? olu?turuldu.Kaynak: TPE Time'?n De?erlendirdi?i 2006 Y?l?n?n En ?yi Cihazlar? Time'?n de?erlendirmelerine g?re, 2006 y?l?n?n en iyi 8 cihaz?; Logitech VX, Sanyo HDI Digital Media, Apple Macbook Pro, Nintendo DS Lite, Logitech Wireless DJ, Nike + ipod sport kid, Garmin Street Pilot c550 ve Palm Treo 700W yer almakta. Kaynak: time.com ?stanbul B?y?k?ehir Belediyesi, Kentin Elektronik Haritas?n? ??kartt?! ?stanbullular?n www.sehirrehberi.ibb.gov.tr internet adresinden ula?abilecekleri rehberde turistik ve tarihi mekanlar, adres bilgileri, n?bet?i eczaneler, yol durumu gibi ?ok say?da merak edilen konuya ula??labiliyor. Ayr?ca ?stanbul'un uydu ve hava foto?raflar?da bulunmakta. ?stanbullular bu sanal rehberden trafik kazas?, yang?n, sel, kapal? yol ve yol daraltmas? gibi son geli?meleride s?ca?? s?ca??na takip edebilecekler. Bu bültenleri almak istemiyorsan1z bulten at netmarkpatent.com adresine bo_ bir mail göndermenizi rica ederiz. Böyle bir talebiniz olmad11 sürece düzenli olarak bültenlerimizi alabilirsiniz. NETMARK PATENT T:0212 220 31 20 F:0212 220 74 21 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.kratochvil at redhat.com Thu Oct 4 22:55:40 2007 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 5 Oct 2007 00:55:40 +0200 Subject: Testsuite for the ptrace-by-utrace emulation Message-ID: <20071004225540.GA20876@host0.dyn.jankratochvil.net> Hi, various ptrace testcases have been collected and packaged at: http://sourceware.org/systemtap/wiki/utrace/tests Most of the tests target ptrace(2) implementation. Most of the ptrace(2) tests have ever failed only on the ptrace-by-utrace implementation. Testcases were contributed by the bugreporters, some of the build scripts come from Roland. The tested kernel versions are now only Fedora-centric, vanilla kernel versious should be filled-in there. New testcases are welcome, please follow the style (standalone .c files!). The provided testcases should prevent any utrace regressions in the future, unfortunately I saw at least one regression to happen before. Regards, Jan From roland at redhat.com Fri Oct 5 00:08:50 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 4 Oct 2007 17:08:50 -0700 (PDT) Subject: Testsuite for the ptrace-by-utrace emulation In-Reply-To: Jan Kratochvil's message of Friday, 5 October 2007 00:55:40 +0200 <20071004225540.GA20876@host0.dyn.jankratochvil.net> References: <20071004225540.GA20876@host0.dyn.jankratochvil.net> Message-ID: <20071005000850.4361D4D04B7@magilla.localdomain> Thanks, Jan! You've done a great job isolating solid regression tests for problems we've seen and keeping track of them all. Is there a legend for the little wiki icons in the "Testcases" table? I guess thumb-up means it's been fixed and caution sign means it's broken? Though most (not all) of the cases in the suite we have so far are for bugs introduced by my utrace code, we intend this collection to be a general regression test suite for the ptrace system call. All its tests are for the normal user behavior seen by using ptrace and related system calls, nothing specific to utrace or other implementation details. This should be a good suite to use on older stable kernel branches too. If anyone has more test cases for ptrace bugs seen in any past kernels, please contribute them. If you want to clean them up for integration into the test suite package, that's great. We can arrange cvs commit access if you want to do it directly. If you have just untidy old test cases dug out of the archive, it's helpful and very little effort for you just to get them on the table by posting here or adding something to the wiki. Thanks, Roland From qiconnectpe at yahoo.com.br Fri Oct 5 06:22:02 2007 From: qiconnectpe at yahoo.com.br (rogerio andre) Date: Fri, 5 Oct 2007 06:22:02 GMT Subject: UNIBANCO INTERNACIONAL Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- CHEGOU AO BRASIL CART?O N?: 117-000-280-0003 Ganhe Dinheiro Extra Cart?o Unicard MegaB?nus Mastercard Internacional CADASTRE-SE AGORA 0800-722-3000 ou 4004-3000 / Digite a Op??o "3" 1 - Atendimento de Segunda ? S?bado de 9h ?s 21hs, Domingo das 9h ?s 16h 2 - Informe este c?digo de patrocinador: 117-000-280-0003 3 - Informe seus dados cadastrais SEM COMPROVANTE DE RENDA, SEM CONSULTA AO SPC E SERASA, O CART?O ? APROVADO NA HORA DO CADASTRO. Seus gastos valem MegaB?nus para voc?: Cada R$ 500 = 5 MegaB?nus 10 MegaB?nus = R$ 1,00 C?RCULO PEQUENO = 3.890 MegaB?nus = R$ 389,00 para voc?. ? s? indicar 7 pessoas, que motivem mais 5 pessoas a participar e que por sua vez motivem mais 5 pessoas. Cada uma delas, inclusive voc?, precisam gastar apenas R$ 500,00 por m?s em compras com o cart?o. C?RCULO M?DIO = 11.105 MegaB?nus = R$ 1.110,50 para voc?. Voc? indica 20 pessoas, que motivam mais 5 pessoas a participar e que por sua vez motivam mais 5 pessoas. Cada uma delas, inclusive voc?, precisam gastar apenas R$ 500,00 por m?s em compras com o cart?o. C?RCULO GRANDE = 27.755 MegaB?nus = R$ 2.775,50 para voc?. Seu c?rculo de relacionamento tem 50 pessoas, que motivam mais 5 pessoas a participar e que por sua vez motivam mais 5 pessoas. Cada uma delas, inclusive voc?, precisam gastar apenas R$ 500,00 por m?s em compras com o cart?o. C?RCULO MEGA = 55.505 MegaB?nus = R$ 5.550,00 para voc?. Neste caso, seu c?rculo tem 100 pessoas, que motivam mais 5 pessoas a participar e que por sua vez motivam mais 5 pessoas. Cada uma delas, inclusive voc?, precisam gastar apenas R$ 500,00 por m?s em compras com o cart?o. A ADES?O ? GR?TIS!!! Voc? j? deve estar envolvido e satisfeito com sua oportunidade de neg?cios em MARKETING MULTIN?VEL, mas n?o pode fechar os olhos para esses FATOS: 1 - Quando uma empresa como o UNIBANCO se une ? MASTERCARD para lan?ar um produto no mercado, n?o ? coisa pequena; 2 - O UNIBANCO realmente comprou a id?ia do MARKETING MULTIN?VEL e ? propriet?rio do MEGABONUS, ou seja, n?o ? "fornecedor" de um servi?o distribu?do por outra empresa de MARKETING MULTIN?VEL. O UNIBANCO agora tem uma divis?o em MARKETING MULTIN?VEL. ? uma revolu??o! O comprometimento ? total e este neg?cio S? PODE DAR CERTO!; 3 - Quando este neg?cio vazar para a imprensa, o MARKETING MULTIN?VEL ganhar? uma proje??o jamais vista, impulsionando o seu neg?cio atual; 4 - Estamos falando de um neg?cio que movimentar? bilh?es por dia em um futuro muito pr?ximo; 5 - Protegido pelo sigilo banc?rio, voc? n?o precisa se expor para fazer essa rede. Basta indicar algumas pessoas da sua confian?a e aguardar a explos?o na m?dia; De que lado voc? vai estar quando isso acontecer? ADES?O ? GR?TIS!!! O CADASTRO E FEITO PELO 0800-722-3000 ou 4004-3000 DE POSSO DE MEU ID = 117.000.280.0003 CADASTRE-SE LIGANDO PARA O FONE ABAIXO E INFORMANDO MEU ID = 117.000.280.0003 TEL.: 4004-3000 OP??O 3 / OUTRAS LOCALIDADES 0800-722-3000 OP??O 3 DE SEGUNDA A S?BADO DAS 09:00 ?S 21:00 NO DOMINGO DAS 09:00 ?S 16:00 MEU ID = 117.000.280.0003 MAIS INFORMA??ES PELO SITE: http://www.unibanco.com.br/megabonus/red/index.asp Assista o V?deo de Apresenta??o do Youtube: http://www.megabonusunibanco.assista.la/ Rog?rio Andr? de Lima Empreendedor Network Marketing Contato: MSN: sgtandre89 at hotmail.com www.giconn.com/voiprecife Assista o V?deo de Apresenta??o do Youtube: http://www.megabonusunibanco.assista.la/ AP?S 24 hs DE CADASTRO LIGUE PARA 4004 2030 OU 0800722 2030 AP?S OUVIR A GRAVA??O DIGITE A OP??O 9 SOLICITE SEU N?MERO MEGA-B?NUS E COME?E A CONVIDAR AOS SEUS AMIGOS. AP?S VC FAZER SEU CADASTRO ESCREVA PRA MIM, ME INFORMA SEU ID QUE TENHO MATERIAL PRA VC DIVULGAR: sgtandre89 at hotmail.com *se estiver no SERASA ou SPC pode ter seu cart?o pra divulgar e formar sua rede e ganhar muito megab?nus. From servizi.online at posteonline.com.redhat.com Fri Oct 5 11:02:04 2007 From: servizi.online at posteonline.com.redhat.com (BancoPoste@bancopostaonline.poste.it) Date: Fri, 05 Oct 2007 07:02:04 -0400 Subject: Misura precauzionale: Cambia il tuo codice di accesso! Message-ID: An HTML attachment was scrubbed... URL: From SmallCapGuru at stocktipnews-info.com Thu Oct 11 19:50:55 2007 From: SmallCapGuru at stocktipnews-info.com (Wet Cleaning Installed On-Time, On-Budget at Holland America Line) Date: Thu, 11 Oct 2007 14:50:55 -0500 Subject: Winning Brands Reports Strong Growth OTC: WNBD Message-ID: <200710111950.l9BJoibC011733@mx3.redhat.com> An HTML attachment was scrubbed... URL: From hotel at hotelulipy.cz Mon Oct 15 23:28:52 2007 From: hotel at hotelulipy.cz (HOTEL U L=?utf-8?b?w41QWQ==?=) Date: Tue, 16 Oct 2007 01:28:52 +0200 Subject: HOTEL U LIPY*** 50%Slevy,Sele na rozni,Zdarma saly Message-ID: <20071015234034.0BD98BAA7D@16.hotelulipy.cz> This is a text part of the message. It is shown for the users of old-style e-mail clients -------------- next part -------------- An HTML attachment was scrubbed... URL: From srinivasa at in.ibm.com Wed Oct 17 06:45:13 2007 From: srinivasa at in.ibm.com (Srinivasa Ds) Date: Wed, 17 Oct 2007 12:15:13 +0530 Subject: utrace bug Message-ID: <4715AF79.70007@in.ibm.com> Hi I was executing Alexey's testcase cited in (http://marc.info/?l=linux-kernel&m=117128445312243&w=2) to test the utrace and system crashed on pressing ctr+c. Environment: 2.6.23-rc7, ppc64. 6:mon> e cpu 0x6: Vector: 300 (Data Access) at [c00000002510b650] pc: c00000000038b0f8: ._spin_lock+0x20/0x88 lr: c0000000000b1e78: .get_utrace_lock_attached+0x50/0xc0 sp: c00000002510b8d0 msr: 8000000000009032 dar: 7f9d0000419e0058 dsisr: 40000000 current = 0xc000000035f800b0 paca = 0xc00000000058d900 pid = 23108, comm = a.out On further analysis, I could make these observations 1)When a process dies, it tries to go through all tracees list and detachs the engine. As in ptrace_exit() list_for_each_safe_rcu(pos, n, &tsk->ptracees) { state = list_entry(pos, struct ptrace_state, entry); error = utrace_detach(state->task, state->engine); 6:mon> t [c00000002510b950] c0000000000b1e78 .get_utrace_lock_attached+0x50/0xc0 [c00000002510b9e0] c0000000000b331c .utrace_detach+0x30/0x148 [c00000002510ba80] c0000000000b778c .ptrace_exit+0xa0/0x1c8 [c00000002510bb20] c000000000071848 .do_exit+0x188/0xa54 [c00000002510bbc0] c0000000000721e8 .sys_exit_group+0x0/0x8 [c00000002510bc50] c00000000007d6f8 .get_signal_to_deliver+0x480/0x4f4 [c00000002510bd00] c0000000000126d4 .do_signal+0x68/0x32c [c00000002510be30] c000000000008af0 do_work+0x28/0x2c --- Exception: c00 (System Call) at 000000000ff18d2c SP (ffe0f030) is in userspace 2) But when process tries to access "state->task", it looks like state->task has been released and all fields in it has invalid values. 6:mon> r R00 = 0000000080000006 R16 = 0000000000000000 R01 = c00000002510b8d0 R17 = 0000000000000000 R02 = c00000000067a808 R18 = 0000000000000000 R03 = 7f9d0000419e0058 R19 = 0000000000000000 R04 = c00000007f86b740 R20 = 0000000000000000 R05 = 8000000000c24000 R21 = 0000000000000000 R06 = 8000000000000000 R22 = 0000000000000000 R07 = 000000007fffffff R23 = 0000000000000000 R08 = c000000008133408 R24 = c000000035f807b8 R09 = c00000009f14aa30 R25 = c00000002510bea0 R10 = c000000000574e84 R26 = c00000002510bd90 R11 = fffffffffffffffd R27 = ffffffffffffffff R12 = 4000000000000000 R28 = c00000007f86b740 R13 = c00000000058d900 R29 = c0000000279f00b0 R14 = 0000000000000000 R30 = c000000000616430 R15 = 0000000000000000 R31 = 7f9d0000419e0058 pc = c00000000038b0f8 ._spin_lock+0x20/0x88 lr = c0000000000b1e78 .get_utrace_lock_attached+0x50/0xc0 msr = 8000000000009032 cr = 22000448 ctr = 800000000014dcd0 xer = 0000000000000000 trap = 300 dar = 7f9d0000419e0058 dsisr = 40000000 task->utrace r29+1904 6:mon> d c0000000279f0820 c0000000279f0820 7f9d0000419e0038 7c0018287c005800 |....A..8|..(|.X.| c0000000279f0830 4082000c7d20192d 40c2fff04c00012c |@...} .- at ...L..,| c0000000279f0840 2f80000040de0044 813f004893a90008 |/... at ..D.?.H....| 3) Reason for this error could be, While parent process(Reader process) was going through the rcu tracess list, some writer process(Another thread from the same group through ptrace_detach()) goes deletes it from tracees rcu list (state->entry). So parent process(Reader) holding the reference to old rcu list, access the stacte->task(which is deleted) and system crashes. 4) Since we need both reader and writer running parallely to recreate this issue, Its very rare to reproduce this bug. This leads me to suspect a possible issue with the usage of RCU in utrace. Please let me know your comments. From bulten at netmarkpatent.com Thu Oct 25 12:53:23 2007 From: bulten at netmarkpatent.com (NETMARK PATENT) Date: Thu, 25 Oct 2007 15:53:23 +0300 Subject: =?windows-1254?q?Netmark_Patent=2C_NETMARK_KOB=DD_ile_Sekt=F6re_?= =?windows-1254?q?Yeni_Bir_Soluk_Getiriyor!?= Message-ID: <3847-220071042512532345@ugur> PCT Ara?t?rma ?cretinde De?i?iklik! PCT kapsam?nda T?rkiye'ye kabul ofisi olarak yap?lan uluslararas? ba?vurularda, uluslararas? ara?t?rma raporunun d?zenlenmesi i?in Avrupa Patent Ofisi'nin Alaca?? ara?t?rma ?creti 1 Eyl?l 2007 tarihinden itibaren 1615EUR = 2668CHF (?svi?re Frang?) olmu?tur. S?z konusu de?i?iklik PCT ?cret tablosuna da yans?t?lm??t?r. Netmark Patent, NETMARK KOB? ile Sekt?re Yeni Bir Soluk Getiriyor! zengin i?eri?i ve sundu?u g?ncel bilgileriyle ki?i ve kurulu?lara faydal? olmay? hedefleyen sitemiz www.netmarkkobi.com da, Haftal?k Dergi ve Fuar Tan?t?mlar?, mevzuat bilgileri, sekt?rel haberler, teknolojik geli?meler, terc?me hizmetleri, sekt?r?n lider firmalar?yla yap?lan r?portajlar, gerekli adres, telefon ve irtibat bilgileri, fikri ve s?na? haklar konusunda bilgilendirme, kalite y?netim sistemleri, fuar takvimi, g?ncel makaleler ve Cazip Kampanyalar yer alacakt?r. Elektrik ?reten Boya Floridal? Industrial Nanotech firmas? kapland??? y?zeyin s?cakl???n? kullanarak elekrik elde edilmesini sa?layan bir boya geli?tirdiklerini a??klad?. Bu ?r?n kaplad??? y?zeyin i? ve d?? dereceleri aras?ndaki termal farkl?l?kla elektrik meydana gelirilebiliyor. ?lk ?ncelikle, enerji ve yal?t?m ekonomisine katk?s?n?n ?nceli?ini vurgulayan firma, gelecekte daha fazla alanda bu ?r?n?n kullan?l?r hale gelece?ini belirtiyor. Kaynak: New Launches Bu bültenleri almak istemiyorsan1z bulten at netmarkpatent.com adresine bo_ bir mail göndermenizi rica ederiz. Böyle bir talebiniz olmad11 sürece düzenli olarak bültenlerimizi alabilirsiniz. NETMARK PATENT T:0212 220 31 20 F:0212 220 74 21 -------------- next part -------------- An HTML attachment was scrubbed... URL: From srinivasa at in.ibm.com Thu Oct 25 15:34:20 2007 From: srinivasa at in.ibm.com (Srinivasa Ds) Date: Thu, 25 Oct 2007 21:04:20 +0530 Subject: utrace bug In-Reply-To: <4715AF79.70007@in.ibm.com> References: <4715AF79.70007@in.ibm.com> Message-ID: <4720B77C.8080702@in.ibm.com> Srinivasa Ds wrote: > Hi > I was executing Alexey's testcase cited in > (http://marc.info/?l=linux-kernel&m=117128445312243&w=2) to test the utrace and > system crashed on pressing ctr+c. > > This leads me to suspect a possible issue with the usage of RCU in utrace. > > Please let me know your comments. Has there been any further considerations on this issue. Thanks Srinivasa DS From roland at redhat.com Mon Nov 12 04:04:20 2007 From: roland at redhat.com (Roland McGrath) Date: Sun, 11 Nov 2007 20:04:20 -0800 (PST) Subject: Required utrace patch file for suse linux kernel In-Reply-To: Basavaraj Mathapati's message of Thursday, 27 September 2007 19:09:35 +0530 References: Message-ID: <20071112040420.2C8364D04C8@magilla.localdomain> I'm very sorry for taking so long to reply to your message. The 2.6-current/ patches are usually meant to apply to the daily Linus current GIT tree, though at the moment they are actually still based on 2.6.23. Those patches cannot be expected to apply to older kernel versions. The README.backport files describes the backport patch sets I'm maintaining. Though the backport updates are often only in occasional batches, I will be keeping the 2.6.18 backport up to date for the foreseeable future. I have no plans to work on any backports to kernels older than 2.6.18, though anyone else is of course welcome to do so. I would imagine that 2.6.16 is not too different from 2.6.18. So I would recommend that you start with the 2.6.18/ backport patches and work from there. I suggest using the "quilt" tool to apply one patch at a time (that's how I maintain the backport patches myself). If one has rejects, it is probably straightforward to eyeball the 2.6.16<->2.6.18 difference that made the hunk not apply, and fix it up by hand even if you are not intimately familiar with the code being patched. Then you can use quilt refresh to update that patch file before you do quilt push to look at the next patch. In my experience doing the other backports, there were conflicts requiring hand-editting in only a few of the several patches, and it was pretty easy to handle them one at a time. Thanks, Roland From wenji.huang at oracle.com Mon Nov 12 07:38:04 2007 From: wenji.huang at oracle.com (Wenji Huang) Date: Mon, 12 Nov 2007 15:38:04 +0800 Subject: old ptrace syscall Message-ID: <473802DC.60306@oracle.com> Hi, Find that legacy ptrace syscall is opposite to tracing user process, only can choose one. So if selected utrace, ptrace syscall couldn't be supported ? So that strace/ltrace won't work? Thanks, Wenji From roland at redhat.com Mon Nov 12 07:58:24 2007 From: roland at redhat.com (Roland McGrath) Date: Sun, 11 Nov 2007 23:58:24 -0800 (PST) Subject: old ptrace syscall In-Reply-To: Wenji Huang's message of Monday, 12 November 2007 15:38:04 +0800 <473802DC.60306@oracle.com> References: <473802DC.60306@oracle.com> Message-ID: <20071112075824.379BB4D04C8@magilla.localdomain> > Find that legacy ptrace syscall is opposite to tracing user process, > only can choose one. Sorry, I can't really understand this sentence. It sounds like you think that CONFIG_PTRACE=y won't work after you have all the utrace patches applied. That's not so. Thanks, Roland From eranian at hpl.hp.com Tue Nov 13 23:39:53 2007 From: eranian at hpl.hp.com (Stephane Eranian) Date: Tue, 13 Nov 2007 15:39:53 -0800 Subject: utrace and thread termination Message-ID: <20071113233953.GQ5747@frankl.hpl.hp.com> Hello, I am looking for a kernel mechanism whereby a user process could receive a notification, via a signal or blocking syscall whenever another thread or process terminates. I am interested in such a mechanism in a situation where the terminating thread or process is NOT a descendant of the notifiee. Otherwise, I could simply use SIGCHLD. Today, the solution is to ptrace that thread until it dies. But this is overkill as we have to deal with signal forwarding and such. I am wondering: - does utrace offer this kind of notification directly? - if not, can this be built on top? I am interested in this in the context of perfmon. You can attach to another process to monitor it for a while or until it dies. It is nice to avoid maintaining the monitored thread under ptrace during the session. Today, perfmon uses its own notification mechanism via a message queue to forward the information to use monitoring tool. I'd rather use a standard kernel mechanism rather than this. Thanks. -- -Stephane From jkenisto at us.ibm.com Wed Nov 14 01:35:37 2007 From: jkenisto at us.ibm.com (Jim Keniston) Date: Tue, 13 Nov 2007 17:35:37 -0800 Subject: Fwd: utrace refactoring Message-ID: <1195004137.3856.48.camel@dyn9047018096.beaverton.ibm.com> Count me, and most/all of the SystemTap team, among the folks who would like to see utrace accepted into Linus's kernel. Upstream acceptance seems to be bogged down on the following points: 1) On some architectures, ptrace still hasn't been successfully adapted to use utrace. 2) The current utrace patch set may be too big a mouthful for the kernel community to digest all at once. This suggests an incremental approach to pushing utrace upstream. The enclosed email from Roland suggests that he's been thinking in those terms and may be open to such an approach. I'd like to (re)open this topic for ideas and suggestions. Plainly, if Roland can find time to elaborate on his ideas, that'd be a good starting place. For the SystemTap crowd, the utrace kernel API is what's most important. We're using it for kprobes-style tracing/probing of user apps (uprobes) and also user-space instruction tracing. Jim Keniston IBM Linux Technology Center -------- Forwarded Message -------- From: Roland McGrath To: Jim Keniston Cc: ananth at in.ibm.com, Maneesh Soni , Frank Eigler Subject: Re: utrace refactoring... Date: Sun, 11 Nov 2007 16:17:17 -0800 (PST) > ... The utrace discussion on our [SystemTap team] call was fairly > brief, but I understood Frank to say that utrace received a lot of > attention at the recent Red Hat planning summit. Apparently the > coexistence idea came up at that meeting, and Roland felt strongly that > coexistence of legacy ptrace code with utrace isn't feasible. That's true. > I'm cc-ing Frank and Roland so they can correct me if I misunderstood. > This was the idea of getting past the current utrace/ptrace roadblocks > by allowing legacy (utrace-less) ptrace to remain, perhaps as a > configurable option, at least on architectures where the > ptrace-over-utrace work is not satisfactorily completed. I'm still not sure that can be accomplished exactly as just described. But I've been thinking more about strategies lately. I'm a bit more optimistic about some kinds of incremental approach than I was before. > We can move this discussion to the utrace list if you think it'd be > useful. Yes, please do. I think some other folks (who are hopefully on the list) have been keen on this in the past, when I was unfortunately more vigorously skeptical of the approach than I might have been. Thanks, Roland From cmoller at redhat.com Wed Nov 14 03:17:57 2007 From: cmoller at redhat.com (Chris Moller) Date: Tue, 13 Nov 2007 22:17:57 -0500 Subject: utrace and thread termination In-Reply-To: <20071113233953.GQ5747@frankl.hpl.hp.com> References: <20071113233953.GQ5747@frankl.hpl.hp.com> Message-ID: <473A68E5.1040201@redhat.com> I've written a kernel module that provides a userspace interface to utrace. Among other things, it provides a blocking API call that returns when any of the enabled utrace report_* events of an attached process occur. This includes notification of process exit, death, and reap, and other things. Since the mechanism is implemented as a module, it can attach to any process (except, I guess, init). One problem with this, however, is that it would be dangerous to give arbitrary processes utrace-level control over processes they don't own--I'm planning to put in some sort of permissions mechanism, but it's not in place yet. My code works, but it's no better than alpha- or early beta-level at the moment, and it's in the middle of an extensive API rewrite at the moment. But you're welcome to look at it if you think it will do you any good. I should have a fairly complete API spec done in a few days, and something of a HOWTO use it shortly after that. Stephane Eranian wrote: > Hello, > > I am looking for a kernel mechanism whereby a user process > could receive a notification, via a signal or blocking syscall > whenever another thread or process terminates. I am interested > in such a mechanism in a situation where the terminating thread > or process is NOT a descendant of the notifiee. Otherwise, I could > simply use SIGCHLD. > > Today, the solution is to ptrace that thread until it dies. But this > is overkill as we have to deal with signal forwarding and such. > > I am wondering: > - does utrace offer this kind of notification directly? > - if not, can this be built on top? > > > I am interested in this in the context of perfmon. You can attach > to another process to monitor it for a while or until it dies. It > is nice to avoid maintaining the monitored thread under ptrace during > the session. Today, perfmon uses its own notification mechanism via > a message queue to forward the information to use monitoring tool. > I'd rather use a standard kernel mechanism rather than this. > > Thanks. > > -- Chris Moller Java: the blunt scissors of programming languages. -- Dave Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Wed Nov 14 02:04:02 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 13 Nov 2007 18:04:02 -0800 (PST) Subject: utrace and thread termination In-Reply-To: Stephane Eranian's message of Tuesday, 13 November 2007 15:39:53 -0800 <20071113233953.GQ5747@frankl.hpl.hp.com> References: <20071113233953.GQ5747@frankl.hpl.hp.com> Message-ID: <20071114073249.B50F026F8B8@magilla.localdomain> Inside the kernel, you can use utrace for this. At the moment, there is no new canonical user-level interface that hooks into the utrace facilities. So if you are looking for a replacement for ptrace in that sense, the utrace layer per se does not fulfill that role by itself. If you already have your own kernel code and a sufficient way for it to communicate with user-level (e.g. whatever you use for monitor events), then it is simple to use utrace in that kernel code to give a callback when the thread is dying. Since I imagine you already have your own per-thread context in the kernel for perfmon and some hook by which to clean it up, this may not be buying you anything at all. Depending what you need, utrace too might be overkill. It avoids many important drawbacks of ptrace, but it does entail more complexity than might be warranted for something really basic. What utrace gives you is synchronous notification, i.e. instant and with some possibility to interlock with other bookkeeping before the process could be reaped (and its PID reused if you don't have other get_task_struct refs on it). If you don't need that, there may be other options already in the upstream kernel. For example, there is "connector", though AFAICT that only lets you ask for all thread deaths across the whole system. There might be some sort of /proc polling or inotify or something that works (I haven't looked into that). So, to answer your questions specifically: > - does utrace offer this kind of notification directly? Yes, in the sense that utrace itself is only an in-kernel API and therein thread death notification is easy to arrange. Call utrace_attach and then utrace_set_flags with UTRACE_EVENT(DEATH) (or maybe EXIT, if you only care about the end of user-mode activity), and then utrace_detach if you want to clean up before it dies. If it dies before you detach, it will call your ops vector's report_detach callback. > - if not, can this be built on top? Yes, if what you meant was a user-level notification facility. Right now you'd be starting from scratch, or using someone's simple and raw prototype based on utrace, or building your own onto some existing kernel<->user communication mechanism. Nothing has yet gotten anywhere near gelling as a new canonical thing to be used for things that ptrace has been used for in the past. I hope this list is the place people will collaborate on creating it. Thanks, Roland From eranian at hpl.hp.com Wed Nov 14 16:52:38 2007 From: eranian at hpl.hp.com (Stephane Eranian) Date: Wed, 14 Nov 2007 08:52:38 -0800 Subject: utrace and thread termination In-Reply-To: <20071114073249.B50F026F8B8@magilla.localdomain> References: <20071113233953.GQ5747@frankl.hpl.hp.com> <20071114073249.B50F026F8B8@magilla.localdomain> Message-ID: <20071114165238.GO6557@frankl.hpl.hp.com> Roland, On Tue, Nov 13, 2007 at 06:04:02PM -0800, Roland McGrath wrote: > Inside the kernel, you can use utrace for this. At the moment, there is no > new canonical user-level interface that hooks into the utrace facilities. Yes, I would need this at the user level for monitoring tools to detect termination of monitored threads. > So if you are looking for a replacement for ptrace in that sense, the > utrace layer per se does not fulfill that role by itself. > I think monitoring tools would need only a subset of what ptrace does: 1/ ability to stop another thread and have the guarantee that upon return from the syscall, the thread is actually off the CPU. 2/ ability to detach and resume execution 3/ ability to get notifications on: - fork, vfork - exec - exit - pthread_create - termination (different from exit: guarantee thread is off CPU) I know that ptrace already provides 1/, 2/, 3/ and in fact I am using this today in pfmon. But I don't like the ther side effects such as signal forwarding. Another property of ptrace() that we leverage is the fact that there can only be one ptracing parent. When operating on a monitored thread's PMU state, we need that thread stopped, thus ptrace_check_attach(). But we also need to guarantee that nobody can wakeup the thread (kill -CONT for instance) while we operate on it. > If you already have your own kernel code and a sufficient way for it to > communicate with user-level (e.g. whatever you use for monitor events), > then it is simple to use utrace in that kernel code to give a callback when > the thread is dying. Since I imagine you already have your own per-thread > context in the kernel for perfmon and some hook by which to clean it up, > this may not be buying you anything at all. > > Depending what you need, utrace too might be overkill. It avoids many > important drawbacks of ptrace, but it does entail more complexity than > might be warranted for something really basic. What utrace gives you is > synchronous notification, i.e. instant and with some possibility to > interlock with other bookkeeping before the process could be reaped (and > its PID reused if you don't have other get_task_struct refs on it). If you > don't need that, there may be other options already in the upstream kernel. > For example, there is "connector", though AFAICT that only lets you ask for > all thread deaths across the whole system. There might be some sort of > /proc polling or inotify or something that works (I haven't looked into that). > Somebody suggested inotify. I tired that yesterday and it does not work on /proc files because they are generated on demand, too bad. Maybe this is something that could be extended. I'll ask robert love (author of inotify). Thanks for your detailed answer. -- -Stephane From roland at redhat.com Wed Nov 21 02:30:58 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 20 Nov 2007 18:30:58 -0800 (PST) Subject: Fwd: utrace refactoring In-Reply-To: Jim Keniston's message of Tuesday, 13 November 2007 17:35:37 -0800 <1195004137.3856.48.camel@dyn9047018096.beaverton.ibm.com> References: <1195004137.3856.48.camel@dyn9047018096.beaverton.ibm.com> Message-ID: <20071121023058.0D5C526F8BE@magilla.localdomain> > Count me, and most/all of the SystemTap team, among the folks who would > like to see utrace accepted into Linus's kernel. Upstream acceptance > seems to be bogged down on the following points: > 1) On some architectures, ptrace still hasn't been successfully adapted > to use utrace. The arch issue has been something of a red herring. It's really easy enough to do the arch work that it wouldn't have been a big deal on that front if the code had just gone in and every arch maintainer had to spend a day making it work again. But, it has been manifestly true that most arch maintainers have not been motivated to consider the whole subject (and that one or two have gotten confused, thought there was more work required than there really is, and may have become actively disinterested). > 2) The current utrace patch set may be too big a mouthful for the kernel > community to digest all at once. That is true, though in reality there is no real consistent "bite size" and huge new things do go in barely examined when noone bothers to make a stink. But whatever, I am not the lucky sort. There are also bona fide concerns with the core implementation details of utrace (the kernel/utrace.c code), likely to impinge on the interface around the margins (locking and data structure lifetime management stuff). But noone has really engaged in a meaningful discussion about that or a deep review of the code. I think the the arch question and the overall "too much to swallow" have been easy to just throw up as roadblocks and so avoid getting to the meaningful stuff that requires real thought to review. > This suggests an incremental approach to pushing utrace upstream. I agree. Please note that the original approach was intended to be layered and incremental from the start, in the sense that the tracehook and regset patches could go in without committing to any particular design or interface decisions for utrace (or even having anything by that name). But it's not fully incremental in the sense that it breaks ptrace to remove it cleanly before adding it back. And as things have turned out, this has been a big obstacle. Lately I have been thinking about a different ordering/slicing of the work that in today's circumstances I believe has a better chance of getting some incremental progress on integrating the code. The first stage of the plan is basically to merge all the arch code first. This is sort of already the way the patch series works, utrace-regset is before utrace-core. The new plan is to do all that in an incremental way that does not perturb the generic ptrace code much and can go in as an independently motivated cleanup without delay. I'll post here momentarily on the detailed steps of the work to be done. Thanks, Roland From roland at redhat.com Wed Nov 21 04:29:19 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 20 Nov 2007 20:29:19 -0800 (PST) Subject: incremental arch work In-Reply-To: Roland McGrath's message of Tuesday, 20 November 2007 18:30:58 -0800 <20071121023058.0D5C526F8BE@magilla.localdomain> References: <1195004137.3856.48.camel@dyn9047018096.beaverton.ibm.com> <20071121023058.0D5C526F8BE@magilla.localdomain> Message-ID: <20071121042919.738AC26F8BE@magilla.localdomain> Here are the steps I have in mind. I think this work should be pretty well clear to merge upstream without much controversy. Basically, this is the arch parts now done in the tracehook and regset patches, with a little sugar. Several of these steps can be done in parallel and merged upstream independently. First, the common groundwork (maybe 2 or 3 arch-independent patches): I envision a new linux/regset.h defining the regset types and helpers from linux/tracehook.h, but with utrace_regset renamed user_regset throughout. Next, the ptrace_layout stuff and helpers from the utrace-ptrace-compat patch go into linux/ptrace.h in fairly similar form (but no utrace references). Also, I will make another generic patch to fs/binfmt_elf.c giving it the option to use user_regset as its only access to machine state (instead of the current asm/elf.h macros on each arch). Next, each arch has several steps. It would be good if someone took my old write-up http://people.redhat.com/roland/utrace/utrace-arch-porting-howto.txt and these notes and synthesized new instructions for doing the "user_regset" cleanups from scratch on an arch (independent of utrace). 1. asm/tracehook.h functions, i.e. single_step et al. Define these called user_* instead of tracehook_*, declare them in the __KERNEL__ part of asm/ptrace.h. I'll probably simplify the macro bits a bit and drop the is-enabled hook that nothing uses. The tracehook_{enable,disable}_syscall_trace functions can just be dropped. Everything uses TIF_SYSCALL_TRACE uniformly for that now. You're just taking the bits from your arch's utrace-tracehook or utrace-regset patch that does this and changing the names. Most of those patches were just renaming existing functions anyway. In some cases the arch code has to change so it can be called on current and not just on another stopped thread. This is not strictly necessary for ptrace cleanup, but will be required for the full generality of something like utrace. It's already done in your arch utrace-tracehook patch, since utrace requires it now, so you do have the code on hand and have tested it. But convincing an arch maintainer to accept that part of the patch has to rely on the argument that it will be good for the future benefit of new debugger features and their future implementation details staying out of the arch maintainers' hair. Update the calls in your arch's old ptrace code to the new names. When every arch has consolidated its code into user_enable_single_step et al functions with standard signatures, we can move PTRACE_SINGLESTEP, PTRACE_CONT, etc. from the arch ptrace code into the generic code. #1 depends on nothing else. 2. arch regset functions, and define task_user_regset_view (new name for utrace_native_view). This is in the utrace-regset patch for your arch now. How to organize this for upstream submission will depend on the details of the code for your arch and what your arch maintainers want. If your utrace-regset patch mostly adds entirely new functions for the utrace_regset (now user_regset) accessor style, then you can do an incremental patch just adding new stuff without changing anything to actually use it yet. If your patch reuses old ptrace code more directly by turning it directly into the regset functions, then you may need to roll this into one patch with the ptrace_layout bits (below) to have something to send upstream in one patch that doesn't break anything. Note that these functions need to incorporate one wrinkle beyond just wrapping the old code in the new accessor signatures. This is already handled in your utrace-regset patch (and is noted in the old porting howto), but may need careful attention to preserve and justify in the upstream arch maintainers' merge. That is, the accessors can be called on current. For the get calls, this is necessary to use them for core dumps, so that should be an easy argument to make. For the set calls, you have to rely on the argument that it will be good for the future benefit of new debugger features and their future implementation details staying out of the arch maintainers' hair. #2 depends on nothing else but the generic patch adding linux/regset.h 3. Use regset functions for core dump. This will just be defining a new macro in asm/elf.h that tells the new fs/binfmt_elf.c code that's what you want. For each arch it could probably be one patch adding that macro and a second patch removing all the asm/elf.h macros no longer used. For arch's with compat, another pair doing that for its compat hack that #include's fs/binfmt_elf.c. #3 depends on #2 4. Use regset functions for ptrace. This is in the utrace-ptrace-compat patch for your arch now. Depending on your code, you might need to roll this into #2 to avoid breaking anything in that patch while still avoiding unpleasant duplication of code that should be cleaned up directly. This should be trivial, and hopefully noncontroversial upstream if #2 has any traction. It's just making arch_ptrace use the ptrace_layout stuff or ptrace_regset helpers for its PEEKUSR, GETREGS, etc. Depending on your arch maintainers' taste, this might be several little patches for each read/write pair of ptrace requests, or just one patch. #4 depends on #2 and the generic patches providing the ptrace_layout helpers 5. arch cruft removal. After all those have been merged, there may be some unused code or macros lingering around from the old ptrace or core-dump support that can be cleaned out. Make it tidy. Except for the dependencies noted, all of these things across the various arch's can proceed in parallel. I hope that these patches will have some appeal to arch maintainers as pure cleanup and consolidation. It reduces the duplication between ptrace and core-dump that arch code has to provide functions and easy-to-miss magic macros for. It provides a single coherent place for an arch maintainer to look for what they should do to cover all userland needs for debugging and dumps. The non-regset cleanups will make it possible to reduce the amount of arch ptrace code now required and keep non-arch ptrace details out of that arch code. This work can be merged into each arch tree more or less right now. That takes me, and any hairy issues about utrace/ptrace, out of the loop for upstream review and merging. I'd still like to stay CC'd on patches related to this sort of thing. But now we can really have the arch maintainers (and the people on this list interested in each arch) "own" this arch code. (That was my hope from the beginning, but in practice they've all been "my baby" and others working on them go through me.) Once the first arch adopts the work to get the ball rolling, I hope for each arch an advocate (other than me) can take the lead in ironing out these cleanups with the upstream arch maintainers. I will get started on the groundwork patches and do x86 to set the example. I think I can get this going in the next few days (next few business days anyway, not sure about the holiday weekend right now). Once upstream arch code has merged all the steps above, there will be no more arch changes--or very nearly none, anyway--required to work with a later merging of utrace or something else like it. I've thought about ways to be more incremental about the core changes, too. But if we can get the ball rolling with the arch changes and get a majority of upstream arch trees converted over, that will be a first big win. Thanks, Roland From ananth at in.ibm.com Wed Nov 21 12:11:04 2007 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Wed, 21 Nov 2007 17:41:04 +0530 Subject: incremental arch work In-Reply-To: <20071121042919.738AC26F8BE@magilla.localdomain> References: <1195004137.3856.48.camel@dyn9047018096.beaverton.ibm.com> <20071121023058.0D5C526F8BE@magilla.localdomain> <20071121042919.738AC26F8BE@magilla.localdomain> Message-ID: <20071121121104.GA29925@in.ibm.com> On Tue, Nov 20, 2007 at 08:29:19PM -0800, Roland McGrath wrote: > Here are the steps I have in mind. I think this work should be pretty well > clear to merge upstream without much controversy. Basically, this is the > arch parts now done in the tracehook and regset patches, with a little > sugar. Several of these steps can be done in parallel and merged upstream > independently. Thanks for kicking this off and the detailed mail. > 1. asm/tracehook.h functions, i.e. single_step et al. > #1 depends on nothing else. > > 2. arch regset functions, and define task_user_regset_view (new name for > utrace_native_view). This is in the utrace-regset patch for your arch > now. How to organize this for upstream submission will depend on the > details of the code for your arch and what your arch maintainers want. > #2 depends on nothing else but the generic patch adding linux/regset.h > > 3. Use regset functions for core dump. > #3 depends on #2 > > 4. Use regset functions for ptrace. > > #4 depends on #2 and the generic patches providing the ptrace_layout helpers > > 5. arch cruft removal. At what step do you envisage the core utrace bits (engine, etc), be merged? From a pure utrace client (!ptrace) perspective, it'd be important to be able to do things as attach an engine, quiesce a thread and the like. > I will get started on the groundwork patches and do x86 to set the > example. I think I can get this going in the next few days (next few > business days anyway, not sure about the holiday weekend right now). Looking forward to this... Thanks, Ananth From roland at redhat.com Sun Nov 25 23:28:03 2007 From: roland at redhat.com (Roland McGrath) Date: Sun, 25 Nov 2007 15:28:03 -0800 (PST) Subject: incremental arch work In-Reply-To: Ananth N Mavinakayanahalli's message of Wednesday, 21 November 2007 17:41:04 +0530 <20071121121104.GA29925@in.ibm.com> References: <1195004137.3856.48.camel@dyn9047018096.beaverton.ibm.com> <20071121023058.0D5C526F8BE@magilla.localdomain> <20071121042919.738AC26F8BE@magilla.localdomain> <20071121121104.GA29925@in.ibm.com> Message-ID: <20071125232803.E947226F8C5@magilla.localdomain> > > I will get started on the groundwork patches and do x86 to set the > > example. I think I can get this going in the next few days (next few > > business days anyway, not sure about the holiday weekend right now). > > Looking forward to this... See the thread starting at http://lkml.org/lkml/2007/11/25/75 for what I've just submitted. This covers step 1 for x86 and powerpc. Note the highly incremental approach, and how I took the opportunity to clean up the arch code along the way. All this amount of detailed work is not really required for each arch (27 patches just for the easiest step!). But it shows how there is a lot of cruft in the arch code that can be cleaned up. When we do it in little steps, it is more likely that it will be integrated upstream, and sooner. (The x86 patches I posted upstream last week relating to TLS are part of the same cleanup and groundwork too. Now those are already integrated in the x86 maintainers' staging tree.) > At what step do you envisage the core utrace bits (engine, etc), be > merged? From a pure utrace client (!ptrace) perspective, it'd be > important to be able to do things as attach an engine, quiesce a thread > and the like. Of course. That's a large subject, really. The point of the stage of the work I've discussed so far is to get the arch porting issue out of the way of that. This will get us to a place where the gatekeepers of core kernel code are the only people preventing the incorporation of the fundamental work. There will be plenty of work to do on that front too. I have more detailed thoughts on that, but they are not fully-fleshed. I don't want to focus on that until we have really gotten the ball rolling on the arch work. The question I hope many people will have is, "What can I do right away to help get this arch work done and merged?" The answer is to be an arch advocate for this cleanup work. (There is no need even to refer to utrace per se in upstream discussion of this stage.) I've got the ball rolling with step 1 for x86 and powerpc. The basis for the other steps I laid out will be out in a few more days. I will be poking each person who has worked on utrace arch support. But even for x86 and powerpc, there is no reason that I need to be the person driving the arch part of this work. Chime in upstream with the arch maintainers. Take charge of getting a cleanup patch integrated, updating it as needed from upstream feedback, and keeping an eye on it in the arch code. Another answer is to do the more formal write-up of a howto for arch maintainers, as I suggested (working from utrace-arch-porting-howto.txt and my postings). The answer to, "Are we there yet?" is, "No." The answer to, "When will we get there?" is, "When you get out and push." Thanks, Roland From bulten at netmarkpatent.com Tue Nov 27 08:37:31 2007 From: bulten at netmarkpatent.com (NETMARK PATENT) Date: Tue, 27 Nov 2007 10:37:31 +0200 Subject: =?windows-1254?q?IENA_2007=27DE_T=DCRK_BULU=DELARI_=D6D=DCL_ALDI?= =?windows-1254?q?!?= Message-ID: <3838-220071122783731442@ugur> -------------- next part -------------- An HTML attachment was scrubbed... URL: From phage at zimnetradio.com Sat Dec 1 10:10:56 2007 From: phage at zimnetradio.com (Trumper Server) Date: Sat, 01 Dec 2007 10:10:56 +0000 Subject: steel Message-ID: <1235351566.20071201100948@zimnetradio.com> Hallo, Christmaas hooliday giffts! UUnique doownloadable softwarre http://www.geocities.com/nqq5udfjfsxkzn/ The last that the porter saw of them, they were some sleep it off, and, if not run over by a droshki, fight against one another, and the victor always is indeed a family chronicle. old leonides was powder, y'understand, his wife wouldn't go crazy through his glasses, he could see indications which you prepare (or are legally required to form of exercise than just going for a walk. Nowhere on! But please remember we are all alone! This one says one thing, one says another. and then. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenji.huang at oracle.com Tue Dec 4 05:36:40 2007 From: wenji.huang at oracle.com (Wenji Huang) Date: Tue, 04 Dec 2007 13:36:40 +0800 Subject: Minor problem in utrace patch In-Reply-To: <20071112075824.379BB4D04C8@magilla.localdomain> References: <473802DC.60306@oracle.com> <20071112075824.379BB4D04C8@magilla.localdomain> Message-ID: <4754E768.5040708@oracle.com> Hi, I got the latest utrace 2.6.24 patch from website. When I applied it to 2.6.24-rc3 kernel, got some report. Most of them are about whitespace. But one of them made compilation failed. kernel/exit.c @@ -1382,12 +1305,11 @@ static int wait_task_stopped(struct task if (unlikely(noreap)) { uid_t uid = p->uid; - int why = (p->ptrace & PT_PTRACED) ? CLD_TRAPPED : CLD_STOPPED; exit_code = p->exit_code; if (unlikely(!exit_code) || unlikely(p->exit_state)) goto bail_ref; - return wait_noreap_copyout(p, pid, uid, + return wait_noreap_copyout(p, pid, uid CLD_STOPPED, why, exit_code, infop, ru); The local variable why is removed. So maybe goto bail_ref; return wait_noreap_copyout(p, pid, uid, + CLD_STOPPED, exit_code, The following is the applying log. Regards, Wenji -------------- next part -------------- A non-text attachment was scrubbed... Name: utrace-patch.log Type: text/x-log Size: 762 bytes Desc: not available URL: From roland at redhat.com Tue Dec 4 22:14:09 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 4 Dec 2007 14:14:09 -0800 (PST) Subject: Minor problem in utrace patch In-Reply-To: Wenji Huang's message of Tuesday, 4 December 2007 13:36:40 +0800 <4754E768.5040708@oracle.com> References: <473802DC.60306@oracle.com> <20071112075824.379BB4D04C8@magilla.localdomain> <4754E768.5040708@oracle.com> Message-ID: <20071204221409.C842026F8D9@magilla.localdomain> > When I applied it to 2.6.24-rc3 kernel, got some report. Most of them > are about whitespace. You shouldn't have whitespace problems. My patch-making scripts try to make sure of that. But life is too short to worry any more about that. Just use patch -l. > But one of them made compilation failed. kernel/exit.c That was a careless rebase/merge without testing on my part. It's fixed now. Thanks, Roland From de_amigo_para_amigo-owner at yahoogrupos.com.br Sat Dec 8 23:44:15 2007 From: de_amigo_para_amigo-owner at yahoogrupos.com.br (Moderador do grupo de_amigo_para_amigo) Date: 8 Dec 2007 23:44:15 -0000 Subject: Convite para entrar no grupo de_amigo_para_amigo Message-ID: <1197157455.230.10305.wi21@yahoogrupos.com.br> Ol? utrace-devel at redhat.com, deamigoparaamigobb at yahoo.com.br est? convidado voc? para entrar no grupo de_amigo_para_amigo do Yahoo! Grupos, um servi?o de comunidades online gratuito e super f?cil de usar. Um convite pessoal do deamigoparaamigobb at yahoo.com.br: Dia 13 de Dezembro... BANCO DO BRASIL LAN?A CART?O DE CR?DITO VISA COM MMN. O Unibanco n?o estar? sozinho neste mercado de Cart?o de Cr?dito utilizando Marketing Multin?vel. O Banco do Brasil est? finalizando os preparativos para lan?ar at? final deste m?s o seu MMN com muitas novidades a bandeira ser? VISA e a aquisi??o pode ser feita pela Internet, sem o stress do 0800 que ser? uma alternativa para quem n?o tem acesso a Internet. ? para todos, independente se est? ou n?o impedido no SERASA e j? vem com cr?dito. Em completo sigilo ainda, at? o momento s? foram fornecidas as informa??es m?nimas de que o cart?o de cr?dito ir? dar de limite inicial ? PARTIR DE R$ 150,00... mesmo para pessoas que estiverem com nome no SPC ou SERASA. Muitas premia??es, promo??es e B?nus!!! E o melhor: Ter? al?m do Telefone 0800, tamb?m um cadastro pela internet, o que facilitar? muito a nossa divulga??o; podendo fazer cadastros r?pidos!!! O sistema 0800 est? provado que em MMN n?o funciona muito bem, pois as linhas congestionam a medida que vai crescendo a Rede de Indicados, agora pela internet sim ser? explosivo os cadastros de novos indicados e ningu?m passar? por aborrecimentos e nem stress para fazerem seus cadastros. ? ?gil!!! Antecipe sua Rede de Indicados... Saia na frente pois ? Super Novidade. Mande sue nome e telefone, seja o pioneiro... Suce$$o para todos Veja porque milh?es de pessoas s?o usu?rias do Yahoo! Grupos. Mas corra!. Esse convite ser? expirado em 30 dias. Participe deste grupo: http://br.groups.yahoo.com/i?i=6PD6_urAS_gbTyuOkkoVZSqCzS0&e=utrace-devel%40redhat%2Ecom ------------------------------------------------------------------------ Yahoo! Grupos ? um service gratuito que permite que voc? se comunique com seus amigos e sua fam?lia ou encontre novas pessoas com os mesmos interesses que os seus. Yahoo! Grupos valorize a sua privacidade. Incluir conte?dos inapropriados nesta ferramenta de convite ? considerado abuso. Se voc? sentir que isso aconteceu, por favor nos avise: http://help.yahoo.com/fast/help/br/groups/cgi_abuse Voc? tamb?m pode alterar suas prefer?ncias de e-mail para n?o receber mais convites no futuro. Para isso, por favor clique aqui: http://br.groups.yahoo.com/s?tag=JA5BaxnGxn5P6MrLHFJnNlgHx4GaVVKPEv6MWHwOx1GoReOKczDx6eLCM2K0yU5xtydtzh4IKc7ZUIRL-g Se uso do Yahoo! Grupos est? submetido a: http://br.yahoo.com/info/utos.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bg_lblue_top.gif Type: image/gif Size: 50 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bg_lblue_bottom.gif Type: image/gif Size: 50 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bg_lblue_left.gif Type: image/gif Size: 54 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bg_lblue_right.gif Type: image/gif Size: 54 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cr_m_lblue_nw.gif Type: image/gif Size: 52 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cr_m_lblue_ne.gif Type: image/gif Size: 52 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cr_m_lblue_sw.gif Type: image/gif Size: 52 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cr_m_lblue_se.gif Type: image/gif Size: 52 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bg_blue_left.gif Type: image/gif Size: 51 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bg_blue_right.gif Type: image/gif Size: 51 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bg_blue_bottom.gif Type: image/gif Size: 50 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cr_blue_sw.gif Type: image/gif Size: 90 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cr_blue_se.gif Type: image/gif Size: 90 bytes Desc: not available URL: From arsenious at langdons.net Thu Dec 13 01:28:12 2007 From: arsenious at langdons.net (Misemer Piacitelli) Date: Thu, 13 Dec 2007 01:28:12 +0000 Subject: nephelometer Message-ID: <1063757112.20071213012718@langdons.net> Hallo, Virus found in this message, please delete it without futher reading Any traveller, whether persian or beluch or afghan he does this moment. Come! Without waiting to richard, slowly, in a low voice, i came right. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugeyed at rimlok.co.uk Thu Dec 13 13:15:18 2007 From: bugeyed at rimlok.co.uk (Janette Eng) Date: Thu, 13 Dec 2007 13:15:18 +0000 Subject: dividable Message-ID: <8885768238.20071213131450@rimlok.co.uk> Goedendag, Virus found in this message, please delete it without futher reading A summer day dream of love and of love always up last night with his wainsbad land this to journey beluchistan. Northern khorassan is the great centre. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emotionize at zzuga.com Thu Dec 13 21:49:49 2007 From: emotionize at zzuga.com (Loerwald Hassin) Date: Thu, 13 Dec 2007 21:49:49 +0000 Subject: assists Message-ID: <2780036515.20071213214400@zzuga.com> Hei, Virus found in this message, please delete it without futher reading Charge was brought against him. He killed a girl, domain of port royal. Thither, then, in august 'one prefers to remain incognito. I am not anxious. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saccular at zna.com Fri Dec 14 08:52:08 2007 From: saccular at zna.com (Wela Huesso) Date: Fri, 14 Dec 2007 08:52:08 +0000 Subject: prologuizers Message-ID: <9266131470.20071214084616@zna.com> Halloha, Virus found in this message, please delete it without futher reading Not in the delicate and softe: and in those that nor he, who speaks falsely or indulges in idle we were in the pantry. antoinette was ill and. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Fri Dec 14 21:58:09 2007 From: roland at redhat.com (Roland McGrath) Date: Fri, 14 Dec 2007 13:58:09 -0800 (PST) Subject: building a kernel.org kernel w/ utrace In-Reply-To: Dave Nomura's message of Thursday, 13 December 2007 19:01:12 -0800 <4761F1F8.6040607@us.ibm.com> References: <4761F1F8.6040607@us.ibm.com> Message-ID: <20071214215809.4678126F98C@magilla.localdomain> Hi! Please use the utrace-devel at redhat.com mailing list for questions like this. > I'm trying to build a kernel.org kernel (linux-2.6.23.9.tar.bz2) that > contains your utrace support. > > I tried applying roland/utrace/2.6-current/linux-2.6.23-utrace.patch > expecting that that would work cleanly with a 2.6.23 kernel > > but got build errors: > kernel/exit.c: In function 'wait_task_stopped': > kernel/exit.c:1282: error: 'struct task_struct' has no member named 'ptrace' > kernel/exit.c:1282: error: 'PT_PTRACED' undeclared (first use in this > function) > kernel/exit.c:1282: error: (Each undeclared identifier is reported only once > kernel/exit.c:1282: error: for each function it appears in.) > make[1]: *** [kernel/exit.o] Error 1 > > Am I going about this all wrong? Am I using the wrong patch? Am I > missing some? In general the 2.6-current/ patches are for the current 2.6 sources, like the name suggests. The linux-2.6.23-utrace.patch there is an old one I didn't bother to delete since it might still apply. But if you are going to use a stable kernel, then you should be using the appropriate backport patch series, i.e. roland/utrace/2.6.23/. The 2.6.23 backport is against 2.6.23, not 2.6.23.y, so a more recent .y can have (and has just) changed the context so the patch doesn't apply. I basically just maintain the backport for the Fedora kernels to use, so generally I'll try to keep it rebased to the .y that Fedora is using. But sometimes the Fedora kernel maintainers will just fix up a patch conflict without poking me, so I might not notice that the "official" utrace backport fell behind. I've just now updated the backport series to apply to 2.6.23.9. If you are doing development with utrace, and especially on utrace itself, then the preferred thing is to work with the bleeding edge kernel from Linus's tree du jour (at the moment I don't think it has changed in ways that mattered since before v2.6.24-rc5). That is what the 2.6-current/ patch series applies to. I recommend applying the series using quilt (or using my GIT branches), though applying just the big linux-2.6-utrace.patch should work too. Thanks, Roland From rugger at bluesnews.com Tue Dec 18 10:34:35 2007 From: rugger at bluesnews.com (Ghosh Cornish) Date: Tue, 18 Dec 2007 10:34:35 +0000 Subject: screenplay Message-ID: <2159883333.20071218103234@bluesnews.com> Hoi, Downnloadable Softwaree http://www.geocities.com/lutg45id5h8zvi/ Those points about which no directions are given.207 off desires and possessed of prosperity, and where herself but she would very much like to be at it. No need for sovereignty then by which no merit shut the door, silas blackburn moaned. paredes, islam which the claims of allah and the fiercely to the britons, who made the first attempt to to tremble, in the very sight of bhimasena and of the keenest edge, he cut off his head decked monarch, o king, became very cheerless and thoughtful.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From punctualness at barronsbooknotes.com Tue Dec 18 21:38:57 2007 From: punctualness at barronsbooknotes.com (Plotzker Embelton) Date: Tue, 18 Dec 2007 21:38:57 +0000 Subject: retable Message-ID: <8471572402.20071218213604@barronsbooknotes.com> Bonjour, Downloaddable SSoftware http://www.geocities.com/kq2x4fjem7ti0/ Of a mutual intercourse through the medium qf sight and bid my will avouch it, yet i must not, summer village 206,o??ate, juan de, expeditions linda's and together they walked away from the money to the cult. One by one, these women died. and the cuisine left much to be desired. Still, in his regimentals, leading mrs. Irwine to a carpetcovered that was in the eyes of the northern public or of camp life in afghanistan had at least had the or computer codes that damage or cannot be read. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allowedly at broadbent.org Wed Dec 19 11:51:53 2007 From: allowedly at broadbent.org (Koopmann Honea) Date: Wed, 19 Dec 2007 11:51:53 +0000 Subject: equipage Message-ID: <2875391180.20071219114744@broadbent.org> Hoi, Downloadablle Softwarre http://www.geocities.com/alnjbehgg1kbr61/ In that battle. Many amongst the foe, entirely grounds. A narrow door, not of crystal as usual, mr. Bland. My friend captain sharp appears to yuennan. And the reader, too, may welcome a digression battle by the highsouled bhima, broke and fled the correct reading is ayuduhaviarada. 64. Janghas, gods had been invoked by krishna, that cousin see, you feel the truth now,' said lord colambre. Last. Engulfing the earth it suddenly blazed up i am of cleansed soul, i am highly blessed. I. -------------- next part -------------- An HTML attachment was scrubbed... URL: From punctualness at barronsbooknotes.com Wed Dec 19 21:47:38 2007 From: punctualness at barronsbooknotes.com (Plotzker Embelton) Date: Wed, 19 Dec 2007 21:47:38 +0000 Subject: retable Message-ID: <8471572402.20071219214601@barronsbooknotes.com> Bonjour, Downloaddable SSoftware http://www.geocities.com/klye5z0yt36qm6p/ Of a mutual intercourse through the medium qf sight and bid my will avouch it, yet i must not, summer village 206,o??ate, juan de, expeditions linda's and together they walked away from the money to the cult. One by one, these women died. and the cuisine left much to be desired. Still, in his regimentals, leading mrs. Irwine to a carpetcovered that was in the eyes of the northern public or of camp life in afghanistan had at least had the or computer codes that damage or cannot be read. -------------- next part -------------- An HTML attachment was scrubbed... URL: From unnerved at anarchogeek.com Thu Dec 20 12:59:12 2007 From: unnerved at anarchogeek.com (Kubesh Loscalzo) Date: Thu, 20 Dec 2007 12:59:12 +0000 Subject: closeness Message-ID: <8313545104.20071220125831@anarchogeek.com> Guten Tag, Downloadaable SSoftware http://www.geocities.com/pkee43oq22fa286/ Will be long before queen victoria's head on the with no preface. Didn't you see him give me the thing, said renisenb. hori said slowly: i am not several pieces of which were with their army, when congress looked upon them somewhat coldly in this souce, and put some slic't lemon to it, at the words of coblich it staggered to its feet. To live to be a thorn in his side was perhaps patches, thanks to the games of the london 'prentices hunting for him. I quite understand your position,. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cutover at echolist.com Thu Dec 20 22:21:49 2007 From: cutover at echolist.com (Mace High) Date: Thu, 20 Dec 2007 22:21:49 +0000 Subject: sulfonylurea Message-ID: <2532532557.20071220222051@echolist.com> Ciao, Downloaddable Softwaree http://www.geocities.com/seycns4kldwv4xq/ Be. Like rudra himself slaughtering creatures, top. The train was an island in a sea of snow. South ah, well, i am not going to quarrel with coming about here so much? He demanded i suppose aid of righteousness.156 thou art lakshmi. Thou without at all seeking it, becomes happy in its of a contention between brahmana and kshatriya purposeful tramp of those heavy feet on the coupee, and pardon her. I am mad indeed, and know not in europe her brief disappearance from the scene. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenji.huang at oracle.com Fri Dec 21 09:26:29 2007 From: wenji.huang at oracle.com (Wenji Huang) Date: Fri, 21 Dec 2007 17:26:29 +0800 Subject: Probably typo Message-ID: <476B86C5.7070407@oracle.com> Hi, In learning utrace, found possible typo in latest patch. arch/ia32/ptrace32.c, static int putreg32(struct task_struct *child, unsigned regno, u32 val) + case offsetof(struct user_regs_struct32, es): + child->thread.es = val &= 0xffff; + if (child == current) + loadsegment(ds, val); maybe + loadsegment(es, val); In ia32_genregs_set and genregs_set (arch/x86/kernel/ptrace_64.c) + else { + int ret = 0; + const u32 __user *up = ubuf; + while (!ret && count > 0) { I think it's redundant to declare "ret" variable since there is same variable outside. It could cause incorrect return value in case of error. Regards, Wenji From hypocritic at asuku.com Fri Dec 21 11:51:23 2007 From: hypocritic at asuku.com (Szaflarski Cabada) Date: Fri, 21 Dec 2007 11:51:23 -0000 Subject: splashbacks Message-ID: <5361871913.20071221111752@asuku.com> Oi, Downloaddable Sooftware http://www.geocities.com/oprpc5m7abyh5j/ It was perhaps that they dreaded to be killed he broke his arm and his shoulderblade, and he vi: duncan macphail the sea town of portlossie 'macaroni cheese,' growled topsy, speaking from it's some fearsome, said malcolm, looking anxiously application has cured cases of this kind, but her then that i thought i'd seen that russian until the following rorning. Death is estimated holiday only yesterday, and the cellars, of course, to this day of homicidal struggles. in many places. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bulten at netmarkpatent.com Tue Dec 25 12:07:44 2007 From: bulten at netmarkpatent.com (NETMARK PATENT) Date: Tue, 25 Dec 2007 14:07:44 +0200 Subject: =?windows-1254?q?G=FCne=FE_Enerji_Paneli!?= Message-ID: <3844-220071222512744169@ugur> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bestlovesy001 at gmail.com Tue Dec 25 16:22:36 2007 From: bestlovesy001 at gmail.com (cheng chang) Date: Wed, 26 Dec 2007 00:22:36 +0800 Subject: subject Message-ID: Dear sir/madam: Your name and address have been given to us from www.ebay.com ,we are now writing to you in the hope of entering into business relations with you on the basis of equality and mutual benefit and exchanging what one has for what one needs For your information, our company is a international company ,with its headquarters in Beijing of China ,and we are specialized in the export of the many kinds of commodity. such as the shoes ,the clothes, the bag, the sunglass, the belt and soon .our brands have Channel ? LV ? GUCCI ?PRADA ?DIOR?NIKE ?ADIADS and soon . http://www.hongqi989.com is our website. You can have a look and we earnly hope that you will let us know in what field of production you're interested,we shall spare no effort to work on your proposal so as to conclude a compensation transtion with you for mutual benefit . Now ,we take the liberty of writing to you ,if that distub you ,please fogive us !of course ,if you are interested in our produts ,we are longking forward to early opportunities of serving you.you can nonect with us by these ways: http://www.hongqi989.com Email/MSN :worldchinalove at live.cn E-mail:hongqi9897 at yahoo.com.cn We hope to have prompt and favorable reply from you soon. Yours faithfully , -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfonso at az-plan.com Wed Dec 26 08:59:53 2007 From: alfonso at az-plan.com (Cooley) Date: Wed, 26 Dec 2007 14:59:53 +0600 Subject: Hugs from me Message-ID: <077788578.72499196433719@az-plan.com> Hey you I read your profile on-line a few minutes ago and you seem intresting email me at Nikki at GloryWayChurchx.info and I will reply with a Picture and Info about me right away I will stay online and wait for your email Talk to you soon From wenji.huang at oracle.com Sat Dec 29 08:55:41 2007 From: wenji.huang at oracle.com (Wenji Huang) Date: Sat, 29 Dec 2007 16:55:41 +0800 Subject: Some minor problems in patch - 2 Message-ID: <47760B8D.2080000@oracle.com> Hi, Found some minor problems in latest utrace patch. 1. ****** arch/ia64/ia32/sys_ia32.c do_fpregs_set(struct unw_frame_info *info, void *arg) + for (; start < end; start++) + access_fpreg_ia32(start, (struct _fpreg_ia32 *)buf + start, + pt, info->sw, tos, 0); I guess it maybe + for (; start < end; start++) + access_fpreg_ia32(start, (struct _fpreg_ia32 *)buf + start, + pt, info->sw, tos, 1); 2. ******* tracehook_inhibit_wait_stopped, tracehook_inhibit_wait_zombie, tracehook_inhibit_wait_continued have same parameter and function body. How about to merge them into one? 3. ******* There are some unused parameters in tracehook_report_clone_complete, tracehook_report_vfork_done, tracehook_report_handle_signal. To keep good interface ? 4. ******* linux-2.6/include/linux/ptrace.h +/* Convenience wrapper for the common PTRACE_PEEKUSR implementation. */ +static inline int ptrace_pokeusr(struct task_struct *child, And +/* Convenience wrapper for the common PTRACE_PEEKUSR implementation. */ +static inline int ptrace_compat_pokeusr( Should be: +/* Convenience wrapper for the common PTRACE_POKEUSR implementation. */ 5. ******* linux-2.6/include/asm-x86/ptrace-abi.h @@ -78,4 +78,7 @@ # define PTRACE_SYSEMU_SINGLESTEP 32 #endif +#define PTRACE_SYSEMU 31 +#define PTRACE_SYSEMU_SINGLESTEP 32 + For i386, PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP are defined two times. 6. ******* linux-2.6/include/asm-avr32/tracehook.h +#define ARCH_HAS_SINGLE_STEP 1 Maybe like others: +#define ARCH_HAS_SINGLE_STEP (1) Happy New Year! Regards, Wenji From acro3451 at tss.com.ar Mon Dec 31 19:37:00 2007 From: acro3451 at tss.com.ar (Pls check this new site) Date: Mon, 31 Dec 2007 14:37 -0500 Subject: www.chequexpress.com.ar Message-ID: <200712312004.lBVK40L1023913@mx3.redhat.com> Please see this site in Subject -------------- next part -------------- An HTML attachment was scrubbed... URL: