audit_log_d_path() is a d_path() wrapper that is used by the audit code. To use a struct path in audit_log_d_path() I need to embed it into struct avc_audit_data. Signed-off-by: Jan Blunck <jblunck@suse.de> --- include/linux/audit.h | 5 ++--- kernel/audit.c | 12 ++++++------ kernel/auditsc.c | 28 +++++++++++----------------- security/selinux/avc.c | 13 ++++++++----- security/selinux/hooks.c | 28 ++++++++++++---------------...

proc_get_link() is always called with a dentry and a vfsmount from a struct path. Make proc_get_link() take it directly as an argument. Signed-off-by: Jan Blunck <jblunck@suse.de> --- fs/proc/base.c | 60 ++++++++++++++++++++---------------------------- fs/proc/internal.h | 2 - fs/proc/task_mmu.c | 6 ++-- fs/proc/task_nommu.c | 6 ++-- include/linux/proc_fs.h | 2 - 5 files changed, 34 insertions(+), 42 deletions(-) Index: b/fs/proc/base.c ========...

d_path() is used on a <dentry,vfsmount> pair. Lets use a struct path to reflect this. Signed-off-by: Jan Blunck <jblunck@suse.de> --- drivers/md/bitmap.c | 8 +------- drivers/usb/gadget/file_storage.c | 3 +-- fs/compat_ioctl.c | 2 +- fs/dcache.c | 12 +++++------- fs/dcookies.c | 2 +- fs/ecryptfs/super.c | 5 ++--- fs/nfsd/export.c | 3 ++- fs/proc/base.c ...

All callers to __d_path pass the dentry and vfsmount of a struct path to __d_path. Pass the struct path directly, instead. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Signed-off-by: Jan Blunck <jblunck@suse.de> --- fs/dcache.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) Index: b/fs/dcache.c =================================================================== --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1778,9 +1778,8 @@ shouldnt_be_hashed: * * "bu...

Linus, please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git a couple of cleanups and bugfixes along with a compile/runtime irrelevant doc change. The iommu.h -> gart.h rename needs to go in before we have the namespace polution all over the place. Thanks, tglx Adrian Bunk (4): x86: kernel/setup_32.c: unexport machine_id x86: mm/discontig_32.c: make code static x86: merge EARLY_PRINTK options remove the dead X86_REMO...

From: Randy Dunlap <randy.dunlap@oracle.com> Several media drivers use input_(*) functions so they need to depend on the INPUT config symbol. drivers/built-in.o: In function `bttv_input_fini': linux-2.6.24-rc1-git4/drivers/media/video/bt8xx/bttv-input.c:346: undefined reference to `input_unregister_device' drivers/built-in.o: In function `bttv_input_init': linux-2.6.24-rc1-git4/drivers/media/video/bt8xx/bttv-input.c:204: undefined reference to `input_allocate_device' linux-2.6.24-rc1-git4/d...

Acked-by: Tilman Schmidt <tilman@imap.cc> utters --=20 Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Unge=F6ffnet mindestens haltbar bis: (siehe R=FCckseite)

Applied, thanks tglx -

Hi Dmitri, I watched at 2.6.23 and this is still not done yet. Are there any patches available to use??? Thanks a lot for reply Michal -

From: Randy Dunlap <randy.dunlap@oracle.com> Make iTCO_wdt_probe() be __devinit. Fixes these section warnings: WARNING: vmlinux.o(.text+0x17d8a8): Section mismatch: reference to .init.data: (between 'iTCO_wdt_probe' and 'supermicro_new_unlock_watchdog') WARNING: vmlinux.o(.text+0x17d97e): Section mismatch: reference to .init.data: (between 'iTCO_wdt_probe' and 'supermicro_new_unlock_watchdog') WARNING: vmlinux.o(.text+0x17d989): Section mismatch: reference to .init.data:iTCO_chipset_info (bet...

Why is the TSC better than a paravirt clocksource? In our case this is definitely inaccurate. Paravirt clocksources should be preferred to TSC, and both must be made available in hardware for platforms which do not support paravirt. Also, please cc all the paravirt developers on things related to paravirt, especially things with such broad effect. I think 400 is a good value for a perfect native clocksource. >400 should be reserved for super-real (i.e. paravirt) sources that should always ...

Not every guest support paravirt, but for correctness, all guests require TSC, which must be exposed all the way up to userspace, no matter what the efficiency or accuracy may be. Zach -

Not really. In the case hardware TSC is perfect, the paravirt time counter can be implemented directly in terms of hardware TSC; there is no loss in optimization. This is done transparently. And virtual TSC can be implemented this way too. The real improvement that a paravirt clocksource offers over the TSC clocksource is that the guest does not need to measure the TSC frequency itself against some other constant frequency source (which is problematic on a virtual machine). Instead, the...

i know it's not an optimization issue. Your current pessimisation of even perfect TSCs _is_ an optimization issue. (and note that if the TSC is unstable the guest will/should notice it and will fall back to the hyper clocksource) Ingo -

that's totally broken then. You cannot create an SMP-safe monotonic clocksource via interpolation - native does not do it either. Good thing this problem got exposed, it needs to be fixed. Ingo -

i dont remember us having discussed this before, ever. If there's any "fight" about monotonicity and SMP then it would be a pretty onesided anyway, i agree that this patch cannot go in in its current form. Ingo -

Yes, agreed. The tsc is never the right thing to use if there's a paravirt clocksource available. What's wrong with rating it 300? What inferior clocksource does it lose out to? Shouldn't that clocksource be lowered? (Why don't we just use 1 to 10?) J -

Acked-by: Ingo Molnar <mingo@elte.hu> Ingo -

Hi, Since we already have the Instrumentation menu in kernel/Kconfig.instrumentation and instrumentation code all over the kernel tree: arch/*/oprofile/*.c kernel/kprobes.c arch/*/kernel/kprobes.c kernel/marker.c kernel/profile.c kernel/lockdep.c vm/vmstat.c block/blktrace.c drivers/base/power/trace.c We could move them to instrumentation/ arch/*/instrumentation/ Therefore, we could also move the kprobes and marker samples under instrumentation/samples/ Here is a link to a gi...

But I guess vm stats can be useful to others; a kernel tracer for instance ? Putting stuff in instrumentation/ by no way means that it becomes optional for a subsystem, but merely that it could either export information useful for kernel instrumentation or have some infrastructure parts merged with others. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -

Two more added. Jeff Garzik and Christoph H. sometimes have some comments about this. It would be helpful if we could get comments on this in the next day or two [instead of in 1-2 weeks]. Thanks, --- ~Randy -

And quoting the answer from Valdis.Kletnieks@vt.edu : How so? i n s esc. 4 keystrokes (and still 2 more than D<ESC> ;) Better suggestions are wery welcome. However, in modern shells, auto-completion is cheap nowadays. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -

I'll keep the probes and profile directory name ideas in mind, thanks. This patchset does more than moving things around : its purpose is to gather various kernel files that have similar purpose (instrumentation) into a single directory so that it becomes easier to work on these without duplicating the effort. I see no good reason to have so many different adhoc instrumentation mechanisms for profiling (sched, vm, oprofile) and tracing (blktrace, suspend/resume tracing) all over the place. Merg...

Thomas, On Mon, 29 Oct 2007, Thomas B

This is the next revision of the SCSI event notification infrastructure patchset, enabling SATA Asynchronous Notification ("AN") for CD/DVD devices that support it. For devices that support SATA AN (only very recent ones do), this means that HAL and other userspace utilities no longer need to repeatedly poll the CD/DVD device to determine if the user has changed the media. This revision takes into account James' comments from earlier today, up to patchset revision #4 (this one is revision 5). ...