mysqld prevents s2ram [Re: 2.6.23-mm1]
On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ Ok, now that it boots let's go for more. I cannot suspend if mysqld is running. mysql isn't atually doing anything useful anyway. This is the failed suspend tasks dump of mysql: [0.00] Linux version 2.6.23-mm1-1 ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-3)) #5 SMP PREEMPT Sun Oct 21 13:50:54 JST 2007 ... [ 271.736214] PM: Preparing system for mem sleep [ 271.738185] Freezing user space processes ... [ 291.918090] Freezing of tasks failed after 20.19 seconds (1 tasks refusing to freeze): [ 291.918156] taskPC stack pid father ... [ 292.043105] === [ 292.043175] mysqld_safe D c03d40c0 0 2393 1 [ 292.043343]c26b3eac 0082 c03d0eb0 c03d40c0 c011a850 c011a843 c2626aa0 c2626bd4 [ 292.043803]c17fd0c0 c26b3e88 c26cc380 c26b3ea8 c011b83a c26b3ea0 [ 292.044322]08104d08 08104d08 c26b3eb8 c0141de0 c26b3fb8 [ 292.044843] Call Trace: [ 292.044969] [] refrigerator+0xcf/0xdb [ 292.045091] [] get_signal_to_deliver+0x33/0x414 [ 292.045214] [] do_notify_resume+0x81/0x61e [ 292.045335] [] work_notifysig+0x13/0x19 [ 292.045456] === [ 292.045524] mysqldD c03d40c0 0 2430 2393 [ 292.045692]c25d0eac 0086 c03d0eb0 c03d40c0 c0119eb5 c1c98550 c1c98684 [ 292.046184]c18060c0 0001 c25d0e88 c2603000 c25d0ea8 c011b83a c25d0ea0 [ 292.046705] c25d0eb8 c0141de0 c25d0fb8 [ 292.047272] Call Trace: [ 292.049112] [] refrigerator+0xcf/0xdb [ 292.049234] [] get_signal_to_deliver+0x33/0x414 [ 292.049357] [] do_notify_resume+0x81/0x61e [ 292.049477] [] work_notifysig+0x13/0x19 [ 292.049598] === [ 292.049666] mysqldD c03d40c0 0 2433 2393 [ 292.049834]c3000eac 0086 c03d0eb0 c03d40c0 c1c98aa0 c1c98bd4 [ 292.050306]c17fd0c0 c3000e88 c2603000 c3000ea8 c011b83a c3000ea0 [ 292.050827] 0001 0001 c3000eb8 c0141de0 c3000fb8 [ 292.051353] Call Trace: [ 292.051479] [] refrigerator+0xcf/0xdb [ 292.051599] [] get_signal_to_deliver+0x33/0x414 [ 292.051721] [] do_notify_resume+0x81/0x61e [ 292.051842] [] work_notifysig+0x13/0x19 [ 292.051962] === [ 292.052031] mysqldD c03d40c0 0 2434 2393 [ 292.052198]c27b6eac 0086 c03d0eb0 c03d40c0 c02d95a9 c27b6e8c c1d76aa0 c1d76bd4 [ 292.052660]c17fd0c0 c27b6e88 c2603000 c27b6ea8 c011b83a c27b6ea0 [ 292.053179] 0007 0007 c27b6eb8 c0141de0 c27b6fb8 [ 292.053699] Call Trace: [ 292.053825] [] refrigerator+0xcf/0xdb [ 292.053958] [] get_signal_to_deliver+0x33/0x414 [ 292.054081] [] do_notify_resume+0x81/0x61e [ 292.054203] [] work_notifysig+0x13/0x19 [ 292.054323] === [ 292.054392] mysqldD c03d40c0 0 2435 2393 [ 292.054560]c26b2eac 0086 c03d0eb0 c03d40c0 c0119eb5 c1c42ff0 c1c43124 [ 292.055028]c18060c0 0001 c26b2e88 c2603000 c26b2ea8 c011b83a c26b2ea0 [ 292.055548] 0013 0013 c26b2eb8 c0141de0 c26b2fb8 [ 292.056087] Call Trace: [ 292.056214] [] refrigerator+0xcf/0xdb [ 292.056335] [] get_signal_to_deliver+0x33/0x414 [ 292.056458] [] do_notify_resume+0x81/0x61e [ 292.056579] [] work_notifysig+0x13/0x19 [ 292.056700] === [ 292.056769] mysqldD c03d40c0 0 2436 2393 [ 292.056937]c2776eac 0086 c03d0eb0 c03d40c0 c02d95a9 c2776e8c c26a7a90 c26a7bc4 [ 292.057398]c17fd0c0 c2776e88 c2603000 c2776ea8 c011b83a c2776ea0 [ 292.057930] 0003 0003 c2776eb8 c0141de0 c2776fb8 [ 292.058450] Call Trace: [ 292.058576] [] refrigerator+0xcf/0xdb [ 292.058696] [] get_signal_to_deliver+0x33/0x414 [ 292.058819] [] do_notify_resume+0x81/0x61e [ 292.058945] [] work_notifysig+0x13/0x19 [ 292.059065] === [ 292.059134] mysqldD c03d40c0 0 2438 2393 [ 292.059301]c254deac 0086 c03d0eb0 c03d40c0 c1c9fa90 c1c9fbc4 [ 292.059762]c18060c0 0001 c254de88 c2603000 c254dea8 c011b83a c254dea0 [ 292.060281] b3435390 b3435390 c254deb8 c0141de0 c254dfb8 [ 292.060801] Call Trace: [ 292.060927] [] refrigerator+0xcf/0xdb [ 292.061047] [] get_signal_to_deliver+0x33/0x414 [ 292.061169] [] do_notify_resume+0x81/0x61e [ 292.061290] [] work_notifysig+0x13/0x19 [ 292.061411] === [ 292.061479] mysqldD
Re: oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]
On Sat, Oct 20, 2007 at 07:18:26AM -0500, Dave Kleikamp wrote: > On Fri, 2007-10-19 at 22:34 -0700, Andrew Morton wrote: > > On Sat, 20 Oct 2007 13:57:54 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > > > > On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > > > > > Hey there!! > > > fails to boot here with this friendly oops: > > > http://oioio.altervista.org/linux/dsc01702.jpg > > > > > > .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1 > > > > > > 2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet > > > (no s2ram with mysql running and some net WARNING). > > > Let's see if .23-mm1 still has those first. > > > > > > I'm adding Cc: linux-scsi > > > > > > PS: I'll hardly be able to bisect in the next days... :P > > > > That looks like a Jens and Dave production to me. > > Yes, and it's been fixed: > http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d8fe64237646fdd2c2de2722ec4189a5999119d thanks this fixes it -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] block: Isolate the buffer cache in it's own mappings.
On Sunday 21 October 2007 14:53, Eric W. Biederman wrote: > Nick Piggin <[EMAIL PROTECTED]> writes: > > On Saturday 20 October 2007 07:27, Eric W. Biederman wrote: > >> Andrew Morton <[EMAIL PROTECTED]> writes: > >> > I don't think we little angels want to tread here. There are so many > >> > weirdo things out there which will break if we bust the coherence > >> > between the fs and /dev/hda1. > >> > >> We broke coherence between the fs and /dev/hda1 when we introduced > >> the page cache years ago, > > > > Not for metadata. And I wouldn't expect many filesystem analysis > > tools to care about data. > > Well tools like dump certainly weren't happy when we made the change. Doesn't that give you any suspicion that other tools mightn't be happy if we make this change, then? > >> and weird hacky cases like > >> unmap_underlying_metadata don't change that. > > > > unmap_underlying_metadata isn't about raw block device access at > > all, though (if you write to the filesystem via the blockdevice > > when it isn't expecting it, it's going to blow up regardless). > > Well my goal with separating things is so that we could decouple two > pieces of code that have different usage scenarios, and where > supporting both scenarios simultaneously appears to me to needlessly > complicate the code. > > Added to that we could then tune the two pieces of code for their > different users. I don't see too much complication from it. If we can actually simplify things or make useful tuning, maybe it will be worth doing. > >> Currently only > >> metadata is more or less in sync with the contents of /dev/hda1. > > > > It either is or it isn't, right? And it is, isn't it? (at least > > for the common filesystems). > > ext2 doesn't store directories in the buffer cache. Oh that's what you mean. OK, agreed there. But for the filesystems and types of metadata that can now expect to have coherency, doing this will break that expectation. Again, I have no opinions either way on whether we should do that in the long run. But doing it as a kneejerk response to braindead rd.c code is wrong because of what *might* go wrong and we don't know about. > Journaling filesystems and filesystems that do ordered writes > game the buffer cache. Putting in data that should not yet > be written to disk. That gaming is where reiserfs goes BUG > and where JBD moves the dirty bit to a different dirty bit. Filesystems really want better control of writeback, I think. This isn't really a consequence of the unified blockdev pagecache / metadata buffer cache, it is just that most of the important things they do are with metadata. If they have their own metadata inode, then they'll need to game the cache for it, or the writeback code for that inode somehow too. > So as far as I can tell what is in the buffer cache is not really > in sync with what should be on disk at any given movement except > when everything is clean. Naturally. It is a writeback cache. > My suspicion is that actually reading from disk is likely to > give a more coherent view of things. Because there at least > we have the writes as they are expected to be seen by fsck > to recover the data, and a snapshot there should at least > be recoverable. Whereas a snapshot provides not such guarantees. ext3 fsck I don't think is supposed to be run under a read/write filesystem, so it's going to explode if you do that regardless. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rd: Use a private inode for backing storage
On Sunday 21 October 2007 15:10, Eric W. Biederman wrote: > Nick Piggin <[EMAIL PROTECTED]> writes: > > On Saturday 20 October 2007 08:51, Eric W. Biederman wrote: > >> Currently the ramdisk tries to keep the block device page cache pages > >> from being marked clean and dropped from memory. That fails for > >> filesystems that use the buffer cache because the buffer cache is not > >> an ordinary buffer cache user and depends on the generic block device > >> address space operations being used. > >> > >> To fix all of those associated problems this patch allocates a private > >> inode to store the ramdisk pages in. > >> > >> The result is slightly more memory used for metadata, an extra copying > >> when reading or writing directly to the block device, and changing the > >> software block size does not loose the contents of the ramdisk. Most > >> of all this ensures we don't loose data during normal use of the > >> ramdisk. > >> > >> I deliberately avoid the cleanup that is now possible because this > >> patch is intended to be a bug fix. > > > > This just breaks coherency again like the last patch. That's a > > really bad idea especially for stable (even if nothing actually > > was to break, we'd likely never know about it anyway). > > Not a chance. Yes it does. It is exactly breaking the coherency between block device and filesystem metadata coherency that Andrew cared about. Whether or not that matters, that is a much bigger conceptual change than simply using slightly more (reclaimable) memory in some situations that my patch does. If you want to try convincing people to break that coherency, fine, but it has to be done consistently and everywhere rather than for a special case in rd.c. > The only way we make it to that inode is through block > device I/O so it lives at exactly the same level in the hierarchy as > a real block device. No, it doesn't. A real block device driver does have its own buffer cache as it's backing store. It doesn't know about readpage or writepage or set_page_dirty or buffers or pagecache. > My patch is the considered rewrite boiled down > to it's essentials and made a trivial patch. What's the considered rewrite here? The rewrite I posted is the only one so far that's come up that I would consider [worthy], while these patches are just more of the same wrongness. > It fundamentally fixes the problem, and doesn't attempt to reconcile > the incompatible expectations of the ramdisk code and the buffer cache. It fixes the bug in question, but not because it makes any fundamental improvement to the conceptual ickyness of rd.c. I don't know what you mean about attempting to reconcile the incompatible [stuff]? > > Christian's patch should go upstream and into stable. For 2.6.25-6, > > my rewrite should just replace what's there. Using address spaces > > to hold the ramdisk pages just confuses the issue even if they > > *aren't* actually wired up to the vfs at all. Saving 20 lines is > > not a good reason to use them. > > Well is more like saving 100 lines. Not having to reexamine complicated > infrastructure code and doing things the same way ramfs is. Using radix_tree_insert instead of add_to_page_cache is hardly complicated. If anything it is simpler because it isn't actually confusing the issues and it is much better fit with real block device drivers, which is actually the thing that is familiar to block device driver maintainers. > I think > that combination is a good reason. Especially since I can do with a > 16 line patch as I just demonstrated. It is a solid and simple > incremental change. My opinion is that it is a much bigger behavioural change because it results in incoherent buffer cache / blockdev cache, and it results in code which is still ugly and conceptually wrong. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: oops, Linus tree: 2.6.23-g4fa4d23f, BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
Guillaume Chazarain wrote: >>> BUG: unable to handle kernel NULL pointer dereference at virtual address >>> 0004 > > This should be fixed in recent git by > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9b013e05e0289c190a53d78ca029e2f21c0e4485 > Maybe we encounter same condition, at least the symbol name is same -- sock_setsockopt. This happens in kernel bootup and makes network can not work properly -- I can not connect to internet the whole weekend. Same as you, I am not a network guy, I tried to understand what happened, but it seems not so easy for me ^_^. Here is the oops message: [ 4327.550035] BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 [ 4327.550047] printing eip: c02ad991 *pdpt = 06062001 <1>*pde = [ 4327.550061] Oops: [#1] SMP [ 4327.550071] Modules linked in: arc4 ieee80211_crypt_wep af_packet ip6t_LOG nf_conntrack_ipv6 xt_pkttype ipt_LOG xt_limit deflate zlib_deflate twofish twofish_common camellia serpent blowfish des_generic cbc ecb geode_aes blkcipher aes_i586 aes_generic xcbc sha256_generic sha1_generic crypto_null af_key snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device microcode ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle nf_conntrack_ipv4 nf_conntrack ip_tables ip6table_filter ip6_tables x_tables ipv6 cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq speedstep_lib loop dm_mod pcmcia nsc_ircc parport_pc irda parport ipw2200 rtc_cmos ieee80211 yenta_socket rsrc_nonstatic crc_ccitt pcmcia_core thinkpad_acpi hwmon nvram rtc_core ieee80211_crypt firmware_class snd_intel8x0 sdhci rtc_lib battery snd_intel8x0m snd_ac97_codec ac97_bus output ac mmc_core snd_pcm snd_timer snd soundcore sr_mod i2c_i801 i2c_core iTCO_wdt button snd_page_alloc iTCO_vendor_support cdrom intel_agp agpgart tg3 uinput sg ehci_hcd uhci_hcd sd_mod usbcore edd ext3 mbcache jbd fan ata_piix ahci libata scsi_mod thermal processor [ 4327.550286] CPU:0 [ 4327.550288] EIP:0060:[]Not tainted VLI [ 4327.550291] EFLAGS: 00010282 (2.6.23-bigsmp-g4fa4d23f #6) [ 4327.550305] EIP is at sk_filter_delayed_uncharge+0x1/0x23 [ 4327.550312] eax: c614f738 ebx: ecx: 0003 edx: [ 4327.550319] esi: c60d97b0 edi: c614f738 ebp: c61e2ef8 esp: c61e2ec8 [ 4327.550326] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 4327.550333] Process dhclient (pid: 7024, ti=c61e2000 task=c61e5120 task.ti=c61e2000) [ 4327.550338] Stack: c61e2ef8 c02adb57 0002 0001 c02adaff 0068 c60d97c0 0058 [ 4327.550356] c614f738 c61e2f24 c65c63f0 c61e2f48 c029c87f c61e2fb0 c030642f [ 4327.550374]0001 0246 001a 8005000b fff2 8005000b c03042ae 8005000b [ 4327.550391] Call Trace: [ 4327.550396] [] show_trace_log_lvl+0x1a/0x2f [ 4327.550409] [] show_stack_log_lvl+0x9b/0xa3 [ 4327.550419] [] show_registers+0x1b8/0x28a [ 4327.550429] [] die+0x10b/0x1ee [ 4327.550438] [] do_page_fault+0x7d4/0x8b9 [ 4327.550449] [] error_code+0x72/0x80 [ 4327.550458] [] sock_setsockopt+0x46f/0x4c2 [ 4327.550469] [] sys_setsockopt+0x5a/0x90 [ 4327.550478] [] sys_socketcall+0x1e8/0x241 [ 4327.550486] [] syscall_call+0x7/0xb [ 4327.550495] === [ 4327.550499] Code: 43 4e 39 d3 0f 8c 36 fe ff ff 0f b7 44 d1 f8 83 e0 07 83 f8 06 0f 94 c0 0f b6 c0 48 83 e0 ea eb 05 b8 ea ff ff ff 5b 5e 5d c3 55 <8b> 4a 04 89 e5 8d 0c cd 10 00 00 00 90 29 88 cc 00 00 00 8d 42 [ 4327.550590] EIP: [] sk_filter_delayed_uncharge+0x1/0x23 SS:ESP 0068:c61e2ec8 > HTH. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rd: Use a private inode for backing storage
Nick Piggin <[EMAIL PROTECTED]> writes: > On Saturday 20 October 2007 08:51, Eric W. Biederman wrote: >> Currently the ramdisk tries to keep the block device page cache pages >> from being marked clean and dropped from memory. That fails for >> filesystems that use the buffer cache because the buffer cache is not >> an ordinary buffer cache user and depends on the generic block device >> address space operations being used. >> >> To fix all of those associated problems this patch allocates a private >> inode to store the ramdisk pages in. >> >> The result is slightly more memory used for metadata, an extra copying >> when reading or writing directly to the block device, and changing the >> software block size does not loose the contents of the ramdisk. Most >> of all this ensures we don't loose data during normal use of the >> ramdisk. >> >> I deliberately avoid the cleanup that is now possible because this >> patch is intended to be a bug fix. > > This just breaks coherency again like the last patch. That's a > really bad idea especially for stable (even if nothing actually > was to break, we'd likely never know about it anyway). Not a chance. The only way we make it to that inode is through block device I/O so it lives at exactly the same level in the hierarchy as a real block device. My patch is the considered rewrite boiled down to it's essentials and made a trivial patch. It fundamentally fixes the problem, and doesn't attempt to reconcile the incompatible expectations of the ramdisk code and the buffer cache. > Christian's patch should go upstream and into stable. For 2.6.25-6, > my rewrite should just replace what's there. Using address spaces > to hold the ramdisk pages just confuses the issue even if they > *aren't* actually wired up to the vfs at all. Saving 20 lines is > not a good reason to use them. Well is more like saving 100 lines. Not having to reexamine complicated infrastructure code and doing things the same way ramfs is. I think that combination is a good reason. Especially since I can do with a 16 line patch as I just demonstrated. It is a solid and simple incremental change. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] block: Isolate the buffer cache in it's own mappings.
Nick Piggin <[EMAIL PROTECTED]> writes: > On Saturday 20 October 2007 07:27, Eric W. Biederman wrote: >> Andrew Morton <[EMAIL PROTECTED]> writes: >> > I don't think we little angels want to tread here. There are so many >> > weirdo things out there which will break if we bust the coherence between >> > the fs and /dev/hda1. >> >> We broke coherence between the fs and /dev/hda1 when we introduced >> the page cache years ago, > > Not for metadata. And I wouldn't expect many filesystem analysis > tools to care about data. Well tools like dump certainly weren't happy when we made the change. >> and weird hacky cases like >> unmap_underlying_metadata don't change that. > > unmap_underlying_metadata isn't about raw block device access at > all, though (if you write to the filesystem via the blockdevice > when it isn't expecting it, it's going to blow up regardless). Well my goal with separating things is so that we could decouple two pieces of code that have different usage scenarios, and where supporting both scenarios simultaneously appears to me to needlessly complicate the code. Added to that we could then tune the two pieces of code for their different users. >> Currently only >> metadata is more or less in sync with the contents of /dev/hda1. > > It either is or it isn't, right? And it is, isn't it? (at least > for the common filesystems). ext2 doesn't store directories in the buffer cache. Journaling filesystems and filesystems that do ordered writes game the buffer cache. Putting in data that should not yet be written to disk. That gaming is where reiserfs goes BUG and where JBD moves the dirty bit to a different dirty bit. So as far as I can tell what is in the buffer cache is not really in sync with what should be on disk at any given movement except when everything is clean. My suspicion is that actually reading from disk is likely to give a more coherent view of things. Because there at least we have the writes as they are expected to be seen by fsck to recover the data, and a snapshot there should at least be recoverable. Whereas a snapshot provides not such guarantees. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] iptables: mangle table obsoletes filter table
On Sun, 21 Oct 2007 07:31:58 +0300, Al Boldi said: > > Well, for example to stop any transient packets being forwarded. You could > > probably hack around this using mark's, but you can't stop the implied > > route lookup, unless you stop it in prerouting. > > Basically, you have one big unintended gaping whole in your firewall, that > could easily be exploited for DoS attacks at the least, unless you put in > specific rules to limit this. OK, the light bulb just went on... ;) We actually *do* have an issue with the flip side of that - it's a frikking pain to make packets that show up on eth0 with a destination of 127.0.0.1 go away un-noticed - or at least I'm assuming it's the flip side of the same issue. pgpCSr8Ev6JBT.pgp Description: PGP signature
Re: tristate and bool not enogh for Kconfig anymore
On Sat, 20 Oct 2007 21:17:00 +0200, Sam Ravnborg said: > On Sat, Oct 20, 2007 at 02:42:38PM +0200, Henrik Carlqvist wrote: > > I think there is a need for Kconfig to specify that a functionality could > > be built as a module or not built at all. > > I assume > depends on MODULES > > should do the trick. Umm... I think that will work backwards, and give you CONFIG_FOO=y if.f the kernel *supports* modules. What he needs is to be able to say CONFIG_FOO=n or CONFIG_FOO=m, but *ban* CONFIG_FOO=y. (At least, in my kernel, I have MODULES=y, and several other things from init/Kconfig have 'depends on MODULES' and also end up 'y': % zgrep MODULE /proc/config.gz CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_MODULE_VERIFY_ELF=y pgpmLO5qm6tqG.pgp Description: PGP signature
Re: [PATCH] rd: Use a private inode for backing storage
On Saturday 20 October 2007 08:51, Eric W. Biederman wrote: > Currently the ramdisk tries to keep the block device page cache pages > from being marked clean and dropped from memory. That fails for > filesystems that use the buffer cache because the buffer cache is not > an ordinary buffer cache user and depends on the generic block device > address space operations being used. > > To fix all of those associated problems this patch allocates a private > inode to store the ramdisk pages in. > > The result is slightly more memory used for metadata, an extra copying > when reading or writing directly to the block device, and changing the > software block size does not loose the contents of the ramdisk. Most > of all this ensures we don't loose data during normal use of the > ramdisk. > > I deliberately avoid the cleanup that is now possible because this > patch is intended to be a bug fix. This just breaks coherency again like the last patch. That's a really bad idea especially for stable (even if nothing actually was to break, we'd likely never know about it anyway). Christian's patch should go upstream and into stable. For 2.6.25-6, my rewrite should just replace what's there. Using address spaces to hold the ramdisk pages just confuses the issue even if they *aren't* actually wired up to the vfs at all. Saving 20 lines is not a good reason to use them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] iptables: mangle table obsoletes filter table
[EMAIL PROTECTED] wrote: > On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said: > > Sure, the idea was to mark the filter table obsolete as to make people > > start using the mangle table to do their filtering for new setups. The > > filter table would then still be available for legacy/special setups. > > But this would only be possible if we at least ported the REJECT target > > to mangle. > > That's *half* the battle. The other half is explaining why I should move > from a perfectly functional setup that uses the filter table. What gains > do I get from doing so? What isn't working that I don't know about? etc? > > In other words - why do I want to move from filter to mangle? This has already been explained in this thread; here it is again: Al Boldi wrote: >>>The problem is that people think they are safe with the filter table, >>>when in fact they need the prerouting chain to seal things. Right now >>>this is only possible in the mangle table. >> >>Why do they need PREROUTING? > > Well, for example to stop any transient packets being forwarded. You could > probably hack around this using mark's, but you can't stop the implied > route lookup, unless you stop it in prerouting. Basically, you have one big unintended gaping whole in your firewall, that could easily be exploited for DoS attacks at the least, unless you put in specific rules to limit this. Plus, it's outrageously incorrect to accept invalid packets, just because your filtering infrastructure can only reject packets after they have been prerouted. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: Hi, usually I'll wait for rc1 and test compile external module to see which are broken and what need fixing but while I need virtualbox for some tests I test compile it on current git and it failed badly. Maybe something is missing from x86 merge ? Here is what I get : ... /linux/memobj-r0drv-linux.c In file included from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/atomic_32.h:265, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/atomic.h:2, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/spinlock_32.h:4, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/spinlock.h:2, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/linux/spinlock.h:87, from /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/src/VBox/Runtime/r0drv/linux/the-linux-kernel.h:53, from /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/src/VBox/Runtime/r0drv/linux/alloc-r0drv-linux.c:22: /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm-generic/atomic.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'atomic_long_t' I have been unable to make heads or tails of the maze of twisty dependencies that VirtualBox wants, but the fact that it gets to line 23 of means it has gotten past: 21 #if BITS_PER_LONG == 64 22 23 typedef atomic64_t atomic_long_t; BITS_PER_LONG was originally set in : 39 #ifdef CONFIG_X86_32 40 # define BITS_PER_LONG 32 41 #else 42 # define BITS_PER_LONG 64 43 #endif The most obvious reason for failure is that the symbol CONFIG_X86_32 isn't being defined where expected. From that point on everything goes to hell. Have you done "make oldconfig && make prepare" in your kernel tree since you last updated it? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] block: Isolate the buffer cache in it's own mappings.
On Saturday 20 October 2007 07:27, Eric W. Biederman wrote: > Andrew Morton <[EMAIL PROTECTED]> writes: > > I don't think we little angels want to tread here. There are so many > > weirdo things out there which will break if we bust the coherence between > > the fs and /dev/hda1. > > We broke coherence between the fs and /dev/hda1 when we introduced > the page cache years ago, Not for metadata. And I wouldn't expect many filesystem analysis tools to care about data. > and weird hacky cases like > unmap_underlying_metadata don't change that. unmap_underlying_metadata isn't about raw block device access at all, though (if you write to the filesystem via the blockdevice when it isn't expecting it, it's going to blow up regardless). > Currently only > metadata is more or less in sync with the contents of /dev/hda1. It either is or it isn't, right? And it is, isn't it? (at least for the common filesystems). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request_firmware() and in-kernel modules
On Fri, Oct 19, 2007 at 12:35:38PM -0500, Timur Tabi wrote: > If my driver is compiled in-kernel (and I have module support turned off), > can I still use request_firmware()? Yes. > If my driver is loaded before the file system drivers are loaded, how > can a user process copy the firmware to the > /sys/class/firwmare/.../data device? I'd recommend using the non-blocking mode, that way, when userspace finally gets running, it can handle the firmware events properly, and your kernel code will have not timed out already. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops: [RFC] LinuxPPS (pre)patch
On Fri, Oct 19, 2007 at 07:53:24PM +0200, Rodolfo Giometti wrote:
> +/* The main struct */
> +struct pps_device {
> + struct pps_source_info info;/* PSS source info */
> +
> + struct pps_kparams params; /* PPS's current params */
> +
> + __u32 assert_sequence; /* PPS' assert event seq # */
> + __u32 clear_sequence; /* PPS' clear event seq # */
> + struct pps_ktime assert_tu;
> + struct pps_ktime clear_tu;
> + int current_mode; /* PPS mode at event time */
> +
> + int go; /* PPS event is arrived? */
> + wait_queue_head_t queue;/* PPS event queue */
> +
> + unsigned int id;/* PPS source unique ID */
> + struct cdev cdev;
> + struct device *dev;
> + int devno;
> + struct fasync_struct *async_queue; /* fasync method */
> + spinlock_t lock;
> +
> + atomic_t usage; /* usage count */
> + wait_queue_head_t usage_queue;
> +
> + struct class_device class_dev;
> +};
Please use a 'struct class' instead of a 'struct class_device'. We have
almost rid the kernel of all usages of 'struct class_device' and want to
remove that structure entirely soon. I'm aiming for 2.6.25 and it's
looking good.
So please don't add new instances of it, you can do all the same things
with a 'struct device' and it should be a very trivial change.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] MultiAdmin 1.0.7
On Sun, 21 Oct 2007 01:51:50 +0200 (CEST) Jan Engelhardt <[EMAIL PROTECTED]> wrote: > As per James's request, I am reposting the MultiAdmin LSM That's very nice, but ... what is it? It would be really helpful if each patch series came with some kind of description of what problem the patches try to solve and how it solves it :) -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: sparse breakage triggered by rcu_read_lock() lockdep annotations
Christopher Li wrote: > OK, I get a trivial fix after all. The test case is fixed now. > I haven't done much test otherwise. > > See the patch attached. Nice work Chris! Patch applied and pushed out. I may roll an 0.4.1 release in the near future to fix kernel builds with Sparse. - Josh Triplett signature.asc Description: OpenPGP digital signature
[PATCH] oom_kill bug
Wrong order of arguments
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 824cade..91a081a 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -496,7 +496,7 @@ retry:
panic("Out of memory and no killable processes...\n");
}
- if (oom_kill_process(p, points, gfp_mask, order,
+ if (oom_kill_process(p, gfp_mask, order, points,
"Out of memory"))
goto retry;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vfc_dev conversion to mutex: fallout
commit 7b96dc023a1b487bce59256fde14b8bb28b45aea had missed one
place.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/sbus/char/vfc_dev.c b/drivers/sbus/char/vfc_dev.c
index e7a1642..d4f8fcd 100644
--- a/drivers/sbus/char/vfc_dev.c
+++ b/drivers/sbus/char/vfc_dev.c
@@ -134,7 +134,7 @@ int init_vfc_hw(struct vfc_dev *dev)
int init_vfc_devstruct(struct vfc_dev *dev, int instance)
{
dev->instance=instance;
- init_MUTEX(>device_lock_sem);
+ mutex_init(>device_lock_mtx);
dev->control_reg=0;
dev->busy=0;
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] irq_flags_t: intro and core annotations
On Sun, Oct 21, 2007 at 03:55:46AM +0400, Alexey Dobriyan wrote: > * irq_flags_t is marked with __bitwise__ which means sparse(1) will warn > developer when he accidently uses wrong type or totally wrong variable. > * irq_flags_t allows conversion to struct instead of typedef without flag day. > This will give compile-time breakage of buggy users later. > * irq_flags_t allows arch maintainers to eventually switch to something > smaller than "unsigned long" if they want to. > P.S.: Anyone checking for differences in sparse logs -- don't panic, > just remove __bitwise__ . Umm... Could you make that conditional on something, so that it could be done with e.g. -D__CHECK_IRQFLAGS__? We could make that unconditional closer to the end of conversion. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] UUID: Time-based RFC 4122 UUID generator
The current Linux kernel currently contains the generate_random_uuid()
function, which creates - based on RFC 4122 - truly random UUIDs and
provides them to userspace through /proc/sys/kernel/random/boot_id
and /proc/sys/kernel/random/uuid.
The attached patch additionally adds the "Time-based UUID" variant
of RFC 4122 to the Linux Kernel.
With this patch applied, userspace applications may easily get real unique
time-based UUIDs through /proc/sys/kernel/random/uuid_time.
The attached implementation uses getnstimeofday() to get more fine-grained
granularity than what would be possible with gettimeofday() in userspace.
As such it's in principle possible to provide a lot more UUIDs (if needed) per
time than in userspace.
Additionally a mutex takes care of the proper locking against a mistaken
double creation of UUIDs for simultanious running processes.
Signed-off-by: Helge Deller <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
drivers/char/random.c | 160 +++--
include/linux/sysctl.h |5 -
2 files changed, 145 insertions(+), 20 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 1756b1f..3d6b6e0 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -239,6 +239,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1174,12 +1177,134 @@ EXPORT_SYMBOL(generate_random_uuid);
static int min_read_thresh = 8, min_write_thresh;
static int max_read_thresh = INPUT_POOL_WORDS * 32;
static int max_write_thresh = INPUT_POOL_WORDS * 32;
-static char sysctl_bootid[16];
+static unsigned char sysctl_bootid[16] __read_mostly;
/*
- * These functions is used to return both the bootid UUID, and random
- * UUID. The difference is in whether table->data is NULL; if it is,
- * then a new UUID is generated and returned to the user.
+ * Generate time based UUID (RFC 4122)
+ *
+ * This function is protected with a mutex to ensure system-wide
+ * uniqiness of the new time based UUID.
+ */
+static void generate_random_uuid_time(unsigned char uuid_out[16])
+{
+ static DEFINE_MUTEX(uuid_mutex);
+ static u64 last_time_all;
+ static u16 clock_seq, clock_seq_started;
+ static unsigned char last_mac[ETH_ALEN];
+ static int clock_seq_initialized __read_mostly;
+
+ struct timespec ts;
+ u64 time_all;
+ struct net_device *d;
+ int netdev_found = 0;
+
+ mutex_lock(_mutex);
+
+ /* Determine 60-bit timestamp value. For UUID version 1, this is
+* represented by Coordinated Universal Time (UTC) as a count of 100-
+* nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of
+* Gregorian reform to the Christian calendar).
+*/
+try_again:
+ getnstimeofday();
+ time_all = ((u64) ts.tv_sec) * (NSEC_PER_SEC/100);
+ time_all += ts.tv_nsec / 100;
+
+ /* add offset from Gregorian Calendar to Jan 1 1970 */
+ time_all += 1221929280ULL * (NSEC_PER_MSEC/100);
+ time_all &= 0x0fffULL; /* limit to 60 bits */
+ uuid_out[3] = (u8) time_all;
+ uuid_out[2] = (u8) (time_all >> 8);
+ uuid_out[1] = (u8) (time_all >> 16);
+ uuid_out[0] = (u8) (time_all >> 24);
+ uuid_out[5] = (u8) (time_all >> 32);
+ uuid_out[4] = (u8) (time_all >> 40);
+ uuid_out[7] = (u8) (time_all >> 48);
+ uuid_out[6] = (u8) (time_all >> 56);
+
+ /* Determine clock sequence (max. 14 bit) */
+ if (unlikely(!clock_seq_initialized)) {
+ get_random_bytes(_seq, sizeof(clock_seq));
+ clock_seq &= 0x3fff;
+ clock_seq_started = clock_seq;
+ clock_seq_initialized = 1;
+ } else {
+ if (unlikely(time_all <= last_time_all)) {
+inc_clock_seq: clock_seq = (clock_seq+1) & 0x3fff;
+ if (unlikely(clock_seq == clock_seq_started)) {
+ clock_seq = (clock_seq-1) & 0x3fff;
+ goto try_again; /* wait until time advanced */
+ }
+ } else
+ clock_seq_started = clock_seq;
+ }
+ last_time_all = time_all;
+
+ uuid_out[8] = clock_seq >> 8;
+ uuid_out[9] = clock_seq & 0xff;
+
+ /* Set the spatially unique node identifier */
+#ifdef CONFIG_NET
+ read_lock(_base_lock);
+ for_each_netdev(_net, d) {
+ if (d->type == ARPHRD_ETHER && d->addr_len == ETH_ALEN
+ && d != init_net.loopback_dev) {
+ memcpy(_out[10], d->dev_addr, ETH_ALEN);
+ netdev_found = 1;
+ break;
+ }
+ }
+ read_unlock(_base_lock);
+#endif
+ if (unlikely(!netdev_found)) {
+ /* use bootid's nodeID if no network interface found */
+ if (sysctl_bootid[8] == 0)
+ generate_random_uuid(sysctl_bootid);
+
[PATCH 1/2] UUID: set multicast bit in pseudo-random MAC address
Fix a bug in the current random UUID generator:
Section 4.1.6 of RFC 4122 states regarding the "NodeID" of a UUID:
: For systems with no IEEE address, a randomly or pseudo-randomly
: generated value may be used; see Section 4.5. The multicast bit must
: be set in such addresses, in order that they will never conflict with
: addresses obtained from network cards.
So up to now it was just pure ("random") luck if this bit was set or not.
This tiny patch sets the bit explicitely.
Signed-off-by: Helge Deller <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
random.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1157,6 +1158,8 @@ void generate_random_uuid(unsigned char uuid_out[16])
uuid_out[6] = (uuid_out[6] & 0x0F) | 0x40;
/* Set the UUID variant to DCE */
uuid_out[8] = (uuid_out[8] & 0x3F) | 0x80;
+ /* Set multicast bit to avoid conflicts with NIC MAC addresses */
+ uuid_out[10] |= 0x80;
}
EXPORT_SYMBOL(generate_random_uuid);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Time-based RFC 4122 UUID generator
Andrew, this is a series of two patches for the kernels UUID generator which was already posted two weeks ago to LKML for discussion: http://lkml.org/lkml/2007/10/6/37 1) The first patch fixes a real (although not too critical) bug in the current UUID random generator. It would be great if this could go to Linus soon. 2) The second patch implements a time-based UUID generator acording to RFC 4122. It would be great if you could apply this patch to your mm tree for broader testing. I did tested the patches sucessfully on x86-32 and hppa (big-endian). Helge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix sched_domain sysctl registration again
Thanks for catching these, Milton. I had done my testing against 2.6.23-rc8-mm2 and earlier, so had not picked up your earlier debug sysctl patches from Oct 12 or so that first fixed this, so had not noticed that the resulting merge of your work and mine was borked. ... somedays even the latest *-mm just isn't good enough. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tristate and bool not enogh for Kconfig anymore
On Sat, 20 Oct 2007 21:17:00 +0200 Sam Ravnborg wrote: > On Sat, Oct 20, 2007 at 02:42:38PM +0200, Henrik Carlqvist wrote: > > I think there is a need for Kconfig to specify that a functionality could > > be built as a module or not built at all. > > I assume > depends on MODULES > > should do the trick. Some modules use (e.g.) depends on PCMCIA and m but using MODULES does make more sense to me. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.16.56-rc1
Security fixes since 2.6.16.55: - CVE-2007-3739: Don't allow the stack to grow into hugetlb reserved regions - CVE-2007-4133: hugetlb: fix prio_tree unit Location: ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/ git tree: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git RSS feed of the git tree: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss Changes since 2.6.16.55: Adam Litke (1): Don't allow the stack to grow into hugetlb reserved regions (CVE-2007-3739) Adrian Bunk (2): drivers/video/macmodes.c:mac_find_mode() mustn't be __init Linux 2.6.16.56-rc1 Andreas Arens (1): DVB: get_dvb_firmware: update script for new location of tda10046 firmware Arthur Othieno (1): hugetlbfs: add Kconfig help text David S. Miller (2): [NET]: Zero length write() on socket should not simply return 0. [SPARC64]: Fix bugs in SYSV IPC handling in 64-bit processes. Hugh Dickins (1): hugetlb: fix prio_tree unit (CVE-2007-4133) Ilpo Järvinen (2): [PKT_SCHED] RED: Fix overflow in calculation of queue average [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed Jan Altenberg (1): m68knommu: ptrace.h typo fix Ken Chen (1): x86: HUGETLBFS and DEBUG_PAGEALLOC are incompatible Kumar Gala (1): [POWERPC] Fix handling of stfiwx math emulation Michael Krufky (1): DVB: get_dvb_firmware: update script for new location of sp8870 firmware Mike Frysinger (1): alpha: fix epoll syscall enumerations Randy Dunlap (1): hugetlbfs doc. update Stephen Hemminger (1): [PKT_SCHED] cls_u32: error code isn't been propogated properly Stephen Smalley (1): SELinux: clear parent death signal on SID transitions Ulrich Drepper (1): make UML compile (FC6/x86-64) Zhang Yanmin (1): [IA64] lazy_mmu_prot_update needs to be aware of huge pages Documentation/dvb/get_dvb_firmware | 26 +- Documentation/vm/hugetlbpage.txt | 20 ++-- Makefile |2 +- arch/i386/Kconfig.debug|2 +- arch/ia64/mm/init.c|8 +++- arch/ppc/math-emu/math.c | 13 + arch/sparc64/kernel/sys_sparc.c| 15 --- arch/um/include/kern_util.h|1 - arch/um/sys-x86_64/stub_segv.c |1 - drivers/video/macmodes.c |4 ++-- fs/Kconfig |6 ++ fs/hugetlbfs/inode.c | 24 +++- include/asm-alpha/unistd.h | 11 --- include/asm-m68knommu/ptrace.h |2 +- include/net/red.h |2 +- mm/mmap.c |7 +++ net/ipv4/tcp_input.c |3 +++ net/sched/cls_u32.c|2 +- net/socket.c |2 -- security/selinux/hooks.c |3 +++ 20 files changed, 88 insertions(+), 66 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Ok. I just put a program on something like http://www.kernel.org/~chris/vt6307ohciver.c Anybody with OHCI-1.0 VT6307* Firewire chip may want to try. Obviously it's based on undocumented features, it may blow your machine etc. Please remove your ohci1394 or firewire-ohci driver before using this program. Compile with the usual spell: gcc -Wall -O2 vt6307ohciver.c -o vt6307ohciver Examine (and backup) the EEPROM data first: # /sbin/lspci | grep 1394 01:04.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) # ./vt6307ohciver 01:04.0 [some debug info] It seems your VT6307 chip is connected to I^2C (24c01 or similar) EEPROM EEPROM dump: 00: 00 10 DC 00 01 01 D4 F2 04 04 32 55 F8 00 A2 02 10: A1 00 40 63 62 14 0D 25 03 DF 40 80 00 20 00 73 20: 3C 10 00 00 00 00 FF FF FF FF FF FF FF FF FF FF ^^ Your VT6307 chip is in OHCI 1.0 mode (If you have only one VIA firewire chip you can use "" as the argument.) I'd check if there is a small SMD 8-pin 24c01 or similar EEPROM near VT6307 if I were you. Alternatively the program may say you have 93c46, also a small 8-pin chip. Now you can try upgrading to OHCI-1.1: # ./vt6307ohciver "" 1.1 It seems your VT6307 chip is connected to I^2C (24c01 or similar) EEPROM writing 0x08 at address 0x22 Please reboot People with 93c46 will see 0x11 address. Do as commanded, reboot (PCI reset) is required for the VT6307 to reload the configuration from its EEPROM. Please let me know if it doesn't work. This program may possibly run on VT6306-based board/card as well, though I don't know what would happen (I suspect it could work, but may need some modifications). The "dump" function should work with any OHCI firewire device, though for non-VIA chips you would have to change PCI device/vendor ID in the source. If you have a VT6306-based card and you run this program, I'd appreciate it if you let me know the EEPROM contents (make sure you mention chip type) and, if you tried "upgrading" or "downgrading", if it worked. In theory VT6306 should be able to run in OHCI-1.1 mode, but I don't really know. VT6306 only supports 93c46 EEPROM so if the program says 24c01 you may want to force it (edit the source) and let me know. VT6305 users may not bother, this chip doesn't support OHCI-1.1. Not sure if anything like it ever existed, though. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] PCI: disable MSI on more ATI NorthBridges
If the pci_intx change will be applied to the SATA driver, can it be applied for the ATI USB-HCDs too? See http://lkml.org/lkml/2006/12/21/47 for more details. That should help most of the ATI MSI quirks. It helped me (Acer Aspire 502x laptop with ATI RS480/SB400). > When I used "here", I was just meaning our youthful linux southbridge > drivers team instead of the whole AMD. Sorry for the confusion to you. I am still somewhat confused: most people developing the Linux kernel are limited to look at this hardware from the outside. They had to find out by trial and error. I really hope your colleagues will be more actively helping your team and (other) Linux kernel developers. But I'm glad AMD has such a team. (So while you're at it, ask about the ATI USB HCDs and any other MSI quirk too) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Smackv8: Safe lockless {cipso,load} read operation
Hi,
Utilizing Al's concers about using smack_cipso_count without locking,
here's a patch that remove smack_cipso_count and uses simple list
traversing in read() without any counting mechanism.
CC: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Please apply over omit-non-cipso-lables-in-cipso-seq-start.patch
Using smack_{list,cipso}_count in the read context was useless
anyway cause we were just traversing the list.
diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
index b061cd0..c38d0d0 100644
--- a/security/smack/smackfs.c
+++ b/security/smack/smackfs.c
@@ -63,16 +63,17 @@ int smack_cipso_direct = SMACK_CIPSO_DIRECT_DEFAULT;
static int smk_cipso_doi_value = SMACK_CIPSO_DOI_DEFAULT;
static int smack_list_count;
-static int smack_cipso_count;
struct smk_list_entry *smack_list;
+#define SEQ_READ_FINISHED 1
+
/*
* Seq_file read operations for /smack/load
*/
static void *load_seq_start(struct seq_file *s, loff_t *pos)
{
- if (*pos >= smack_list_count)
+ if (*pos == SEQ_READ_FINISHED)
return NULL;
return smack_list;
@@ -80,8 +81,13 @@ static void *load_seq_start(struct seq_file *s, loff_t *pos)
static void *load_seq_next(struct seq_file *s, void *v, loff_t *pos)
{
- (*pos)++;
- return ((struct smk_list_entry *) v)->smk_next;
+ struct smk_list_entry *skp = ((struct smk_list_entry *) v)->smk_next;
+
+ if (skp)
+ return skp;
+
+ *pos = SEQ_READ_FINISHED;
+ return NULL;
}
static int load_seq_show(struct seq_file *s, void *v)
@@ -306,7 +312,7 @@ static void *cipso_seq_start(struct seq_file *s, loff_t
*pos)
{
struct smack_known *skp = smack_known;
- if (*pos >= smack_cipso_count)
+ if (*pos == SEQ_READ_FINISHED)
return NULL;
while (skp && !skp->smk_cipso)
@@ -319,12 +325,14 @@ static void *cipso_seq_next(struct seq_file *s, void *v,
loff_t *pos)
{
struct smack_known *skp = ((struct smack_known *) v)->smk_next;
- (*pos)++;
-
while (skp && !skp->smk_cipso)
skp = skp->smk_next;
- return skp;
+ if (skp)
+ return skp;
+
+ *pos = SEQ_READ_FINISHED;
+ return NULL;
}
/*
@@ -488,7 +496,6 @@ static ssize_t smk_write_cipso(struct file *file, const
char __user *buf,
rc = -ENOMEM;
break;
}
- ++smack_cipso_count;
} else
scp = NULL;
--
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: git/cscope with x86 merge
On Sat, Oct 20, 2007 at 12:36:17PM -0700, Linus Torvalds wrote: > > > On Sat, 20 Oct 2007, Sam Ravnborg wrote: > > > > I pulled next branch of git and applied your patch. > > > > When running > > git log --follow -B arch/x86/kernel/vmlinux_64.lds.S > > > > I got no output at all (in a newly pulled linux kernel dir). > > Try with "-p". > > It's possible (nay, likely) that "next" has the bug where "--follow" > without a patch generating thing (-p or --stat or one of the other flags > that enable diffs) doesn't work at all. Yep - that did the trick, thanks. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
what to call it after 2.6.23 but before 2.6.24-rc1?
Linus, is there a preferred name to refer to the kernel version in your tree after 2.6.23 is out (and the official 2.6.23.y git was created) but before you release 2.6.24-rc1? I've seen online references to it as "2.6.24", "2.6.24++", "2.6.24-rc0", etc. Since your top-level Makefile still says "2.6.23", it is sometimes a bit confusing when one is testing code against your tree as well as the previously released stable kernel. I usually will stick a localversion file in my cloned copy of your tree, saying "2.6.24-pre-rc" or so. Perhaps you can come up with a definitive name for this "limbo" state and put it in your Makefile? Anyway, 'tis just a minor quibble (which I hope won't start yet another major "naming" flame war :-0 Thanks, Erez. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/8] track highest prio queued on runqueue
--
On Sat, 20 Oct 2007, Dmitry Adamushko wrote:
> On 19/10/2007, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > [ ... ]
> >
> ===
> > --- linux-test.git.orig/kernel/sched.c 2007-10-19 12:33:09.0 -0400
> > +++ linux-test.git/kernel/sched.c 2007-10-19 12:34:32.0 -0400
> > @@ -324,6 +324,8 @@ struct rq {
> > int push_cpu;
> > /* cpu of this runqueue: */
> > int cpu;
> > + /* highest queued rt task prio */
> > + int highest_prio;
>
> again, could it be moved to 'struct rt_rq' ?
> (so we want to cache it as we don't want to trash more per-cpu bytes
> calling smth like
> if (!rt_nr_running) sched_find_first_bit() from other CPUs)
Thanks Dmitry, I'll look into moving these around.
>
>
> > @@ -972,6 +974,8 @@ static void activate_task(struct rq *rq,
> >
> > enqueue_task(rq, p, wakeup);
> > inc_nr_running(p, rq);
> > +
> > + rq_prio_add_task(rq, p);
> > }
> >
> > /*
> > @@ -984,6 +988,8 @@ static void deactivate_task(struct rq *r
> >
> > dequeue_task(rq, p, sleep);
> > dec_nr_running(p, rq);
> > +
> > + rq_prio_remove_task(rq, p);
> > }
>
> {enqueue,dequeue}_task_rt() would be more appropriate places.
Yep, I already have that done in my second queue (not yet posted).
>
>
> > +static inline void rq_prio_add_task(struct rq *rq, struct task_struct *p)
> > +{
> > + if (unlikely(rt_task(p)) && p->prio < rq->highest_prio)
> > + rq->highest_prio = p->prio;
> > +}
> > +
> > +static inline void rq_prio_remove_task(struct rq *rq, struct task_struct
> > *p)
> > +{
> > + struct rt_prio_array *array;
> > +
> > + if (unlikely(rt_task(p))) {
> > + if (rq->rt_nr_running) {
> > + if (p->prio >= rq->highest_prio) {
> > + /* recalculate */
> > + array = >rt.active;
> > + rq->highest_prio =
> > + sched_find_first_bit(array->bitmap);
> > + } /* otherwise leave rq->highest prio alone */
> > + } else
> > + rq->highest_prio = MAX_RT_PRIO;
> > + }
> > +}
> > +#endif /* CONFIG_SMP */
> > +
>
> (just a few thoughts)
>
> we call sched_find_first_bit() in pick_next_task_rt() in the case when
> rt_nr_running != 0.
>
> So if we can tolerate the 'latency' of updating the 'highest_prio' ==
> the interval of time between deactivate_task() and pick_next_task() in
> schedule() then rq_prio_remove_task() would just need to do a single
> thing:
>
> /* No more RT tasks: */
> if (!rt_nr_running)
> highest_prio = MAX_RT_PRIO;
>
> and then,
>
> static struct task_struct *pick_next_task_rt(struct rq *rq)
> {
> struct rt_prio_array *array = >rt.active;
> struct task_struct *next;
> struct list_head *queue;
> int idx;
>
> -idx = sched_find_first_bit(array->bitmap);
> + rq->highest_prio = idx = sched_find_first_bit(array->bitmap);
>
> [ ... ]
>
> additionally, if we can tolerate the 'latency' (of updating
> highest_prio) == the worst case scheduling latency, then
> rq_prio_add_task() is not necessary at all.
In my logging of test runs, having this 'latency' of highest_prio caused
missed migrations. I tried various things to do like what you said, but
they failed the rt-migrate-test program.
Seemed like the only place to modify highest_prio is from the queue and
dequeue. Othrewise, my tests failed.
Thanks!
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/8] Add rt_nr_running accounting
Hi Dmitry,
--
On Sat, 20 Oct 2007, Dmitry Adamushko wrote:
> On 19/10/2007, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > [ ... ]
> > Index: linux-test.git/kernel/sched.c
> > ===
> > --- linux-test.git.orig/kernel/sched.c 2007-10-19 12:32:39.0 -0400
> > +++ linux-test.git/kernel/sched.c 2007-10-19 12:33:09.0 -0400
> > @@ -300,6 +300,8 @@ struct rq {
> > */
> > unsigned long nr_uninterruptible;
> >
> > + unsigned long rt_nr_running;
>
> could it be a part of the 'struct rt_rq' instead?
Maybe. I didn't really look too hard to where to put it. Currently, in the
-rt patch, it is located in struct rq, so I just did the same. I may be
able to move it.
>
> >
> > +static inline void inc_rt_tasks(struct task_struct *p, struct rq *rq)
> > +{
> > + if (rt_task(p))
> > + rq->rt_nr_running++;
> > +}
> > +
> > +static inline void dec_rt_tasks(struct task_struct *p, struct rq *rq)
> > +{
> > + if (rt_task(p)) {
> > + WARN_ON(!rq->rt_nr_running);
> > + rq->rt_nr_running--;
> > + }
> > +}
> > +
> > static void enqueue_task_rt(struct rq *rq, struct task_struct *p, int
> > wakeup)
> > {
> > struct rt_prio_array *array = >rt.active;
> >
> > list_add_tail(>run_list, array->queue + p->prio);
> > __set_bit(p->prio, array->bitmap);
> > +
> > + inc_rt_tasks(p, rq);
>
> why do you need the rt_task(p) check in {inc,dec}_rt_tasks() ?
Me being paranoid ;-)
>
> {enqueue,dequeue}_task_rt() seem to be the only callers and they will
> crash (or corrupt memory) anyway in the case of ! rt_task(p) (sure,
> this case would mean something is broken somewhere wrt sched_class
> handling).
Exactly, I was just being safe. We could add a WARN_ON(!rt_task) there.
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LSM conversion to static interface
On Sat, 20 Oct 2007, Jan Engelhardt wrote: > >I'd like to note that I asked people who were actually affected, and had > >examples of their real-world use to step forward and explain their use, > >and that I explicitly mentioned that this is something we can easily > >re-visit. > > > > I do have a pseudo LSM called "multiadm" at > http://freshmeat.net/p/multiadm/ , quoting: > Based on Linus' criteria, this appears to be a case for reverting the static LSM patch. Jan, I remember you posting this last year and IIRC, there were really only coding style issues to be addressed. There were some review queries and suggestions (e.g. decomposing CAP_SYS_ADMIN), but no deal-breakers -- certainly not now that security architecture and security model objections are out of bounds. So, I would suggest reposting the code for upstream inclusion, which would be better at least in terms of upstream maintenance, as your code will be visible in the tree. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git/cscope with x86 merge
> Try with "-p". > > It's possible (nay, likely) that "next" has the bug where "--follow" > without a patch generating thing (-p or --stat or one of the other flags > that enable diffs) doesn't work at all. It's not only next. The latest release (1.5.3.4) has this problem. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] MultiAdmin 1.0.7
[PATCH 4/4] MultiAdmin module
- Add the MultiAdmin to the mainline tree.
I hope the rest is self-explanatory :)
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>, May 01 2006
Modified July 11 2006
---
security/Kconfig| 17 +
security/Makefile |3
security/multiadm.c | 628
3 files changed, 648 insertions(+)
Index: linux-2.6.23.1/security/Kconfig
===
--- linux-2.6.23.1.orig/security/Kconfig
+++ linux-2.6.23.1/security/Kconfig
@@ -81,6 +81,23 @@ config SECURITY_NETWORK_XFRM
IPSec.
If you are unsure how to answer this question, answer N.
+config SECURITY_MULTIADM
+ tristate "MultiAdmin security module"
+ depends on SECURITY
+ select SECURITY_CAPABILITIES
+ ---help---
+The MultiAdmin security kernel module provides means to have multiple
+"root" users with unique UIDs. This fixes collation order problems
+which for example appear with NSCD, allows to have files with
+determinable owner and allows to track the quota usage for every
+user, since they now have a unique uid.
+
+It also implements a "sub-admin", a partially restricted root user
+(or enhanced normal user, depending on the way you see it), who has
+full read-only access to most subsystems, and additional write rights
+only to a limited subset, e.g. writing to files or killing processes
+only of certain users.
+
config SECURITY_CAPABILITIES
tristate "Default Linux Capabilities"
depends on SECURITY
Index: linux-2.6.23.1/security/Makefile
===
--- linux-2.6.23.1.orig/security/Makefile
+++ linux-2.6.23.1/security/Makefile
@@ -2,6 +2,9 @@
# Makefile for the kernel security code
#
+obj-$(CONFIG_SECURITY_MULTIADM)+= multiadm.o
+CFLAGS_multiadm.o += $(if $(wildcard security/apparmor),-DAPPARMOR,)
+
obj-$(CONFIG_KEYS) += keys/
subdir-$(CONFIG_SECURITY_SELINUX) += selinux
Index: linux-2.6.23.1/security/multiadm.c
===
--- /dev/null
+++ linux-2.6.23.1/security/multiadm.c
@@ -0,0 +1,628 @@
+/*
+ * MultiAdmin Security Module
+ * Copyright © Jan Engelhardt , 2005 - 2007
+ * v1.0.7, July 2007
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 or 3 as published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Out of tree helper */
+#if !defined(CONFIG_SECURITY_CAPABILITIES) && \
+!defined(CONFIG_SECURITY_CAPABILITIES_MODULE)
+# error You need to have CONFIG_SECURITY_CAPABILITIES=y or =m \
+ for MultiAdmin to compile successfully.
+#endif
+
+#define BASENAME "multiadm"
+#define PREFIX BASENAME ": "
+
+static gid_t Supergid = -1;
+static gid_t Subgid = -1;
+static uid_t Superuid_start = 0;
+static uid_t Superuid_end = 0;
+static uid_t Subuid_start = -1;
+static uid_t Subuid_end = -1;
+static uid_t Wrtuid_start = -1;
+static uid_t Wrtuid_end = -1;
+static unsigned int Secondary = 0;
+
+module_param(Supergid, int, S_IRUSR | S_IWUSR);
+module_param(Superuid_start, int, S_IRUSR | S_IWUSR);
+module_param(Superuid_end, int, S_IRUSR | S_IWUSR);
+module_param(Subuid_start, int, S_IRUSR | S_IWUSR);
+module_param(Subuid_end, int, S_IRUSR | S_IWUSR);
+module_param(Subgid, int, S_IRUSR | S_IWUSR);
+module_param(Wrtuid_start, int, S_IRUGO | S_IWUSR);
+module_param(Wrtuid_end, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(Wrtuid_start, "First UID of the write-enabled user range");
+MODULE_PARM_DESC(Wrtuid_end, "Last UID of the write-enabled user range");
+MODULE_PARM_DESC(Superuid_start, "First UIDs of the superadmin range");
+MODULE_PARM_DESC(Superuid_end, "Last UID of the superadmin range");
+MODULE_PARM_DESC(Supergid, "Superadmin GID");
+MODULE_PARM_DESC(Subuid_start, "First UIDs of the subadmin range");
+MODULE_PARM_DESC(Subuid_end, "Last UID of the subadmin range");
+MODULE_PARM_DESC(Subgid, "Subadmin GID");
+
+static inline void chg2_superadm(kernel_cap_t *c)
+{
+ cap_set_full(*c);
+ cap_lower(*c, CAP_SETPCAP);
+ /* Flag 31 is unused, but set */
+ cap_lower(*c, 31);
+ printk(KERN_WARNING "Changed to superadm\n");
+ return;
+}
+
+static inline void chg2_subadm(kernel_cap_t *c)
+{
+ cap_clear(*c);
+ cap_raise(*c, CAP_CHOWN);
+ cap_raise(*c, CAP_DAC_OVERRIDE);
+ cap_raise(*c, CAP_DAC_READ_SEARCH);
+ cap_raise(*c, CAP_FOWNER);
+
[PATCH] Fix oom_kill_process() printout
CHECK mm/oom_kill.c
mm/oom_kill.c:499:27: warning: incorrect type in argument 2 (different base
types)
mm/oom_kill.c:499:27:expected restricted unsigned int [usertype] gfp_mask
mm/oom_kill.c:499:27:got unsigned long [unsigned] [addressable] points
mm/oom_kill.c:499:35: warning: incorrect type in argument 3 (different base
types)
mm/oom_kill.c:499:35:expected int [signed] order
mm/oom_kill.c:499:35:got restricted unsigned int [usertype] gfp_mask
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
mm/oom_kill.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -496,7 +496,7 @@ retry:
panic("Out of memory and no killable processes...\n");
}
- if (oom_kill_process(p, points, gfp_mask, order,
+ if (oom_kill_process(p, gfp_mask, order, points,
"Out of memory"))
goto retry;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] MultiAdmin 1.0.7
[PATCH 3/4] task_post_setgid()
- Implement the task_post_setgid() LSM hook which is required by
MultiAdmin to switch between classes.
(task_post_setuid also switches between classes -- and already exists)
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>, May 01 2006
Modified July 11 2006
---
include/linux/security.h | 13 +
kernel/sys.c | 15 ---
security/dummy.c |7 +++
3 files changed, 32 insertions(+), 3 deletions(-)
Index: linux-2.6.23.1/include/linux/security.h
===
--- linux-2.6.23.1.orig/include/linux/security.h
+++ linux-2.6.23.1/include/linux/security.h
@@ -1400,6 +1400,7 @@ struct security_operations {
#endif /* CONFIG_KEYS */
int (*cap_extra)(struct task_struct *, unsigned int);
+ int (*task_post_setgid)(gid_t, gid_t, gid_t, unsigned int);
};
/* global variables */
@@ -2139,6 +2140,12 @@ static inline int security_cap_extra(str
return security_ops->cap_extra(task, cap);
}
+static inline int security_task_post_setgid(gid_t real, gid_t effective,
+gid_t saved, unsigned int type)
+{
+ return security_ops->task_post_setgid(real, effective, saved, type);
+}
+
/* prototypes */
extern int security_init (void);
extern int register_security (struct security_operations *ops);
@@ -2799,6 +2806,12 @@ static inline int security_cap_extra(str
return 0;
}
+static inline int security_task_post_setgid(gid_t real, gid_t effective,
+gid_t saved, unsigned int type)
+{
+ return 0;
+}
+
static inline struct dentry *securityfs_create_dir(const char *name,
struct dentry *parent)
{
Index: linux-2.6.23.1/kernel/sys.c
===
--- linux-2.6.23.1.orig/kernel/sys.c
+++ linux-2.6.23.1/kernel/sys.c
@@ -1052,7 +1052,8 @@ asmlinkage long sys_setregid(gid_t rgid,
current->gid = new_rgid;
key_fsgid_changed(current);
proc_id_connector(current, PROC_EVENT_GID);
- return 0;
+ return security_task_post_setgid(old_rgid, old_egid,
+ (gid_t)-1, LSM_SETID_RE);
}
/*
@@ -1062,6 +1063,7 @@ asmlinkage long sys_setregid(gid_t rgid,
*/
asmlinkage long sys_setgid(gid_t gid)
{
+ gid_t old_rgid = current->gid;
int old_egid = current->egid;
int retval;
@@ -1087,7 +1089,8 @@ asmlinkage long sys_setgid(gid_t gid)
key_fsgid_changed(current);
proc_id_connector(current, PROC_EVENT_GID);
- return 0;
+ return security_task_post_setgid(old_rgid, (gid_t)-1,
+ (gid_t)-1, LSM_SETID_ID);
}
static int set_user(uid_t new_ruid, int dumpclear)
@@ -1290,6 +1293,9 @@ asmlinkage long sys_getresuid(uid_t __us
*/
asmlinkage long sys_setresgid(gid_t rgid, gid_t egid, gid_t sgid)
{
+ gid_t old_rgid = current->gid;
+ gid_t old_egid = current->egid;
+ gid_t old_sgid = current->sgid;
int retval;
retval = security_task_setgid(rgid, egid, sgid, LSM_SETID_RES);
@@ -1322,7 +1328,8 @@ asmlinkage long sys_setresgid(gid_t rgid
key_fsgid_changed(current);
proc_id_connector(current, PROC_EVENT_GID);
- return 0;
+ return security_task_post_setgid(old_rgid, old_egid,
+ old_sgid, LSM_SETID_RES);
}
asmlinkage long sys_getresgid(gid_t __user *rgid, gid_t __user *egid, gid_t
__user *sgid)
@@ -1391,6 +1398,8 @@ asmlinkage long sys_setfsgid(gid_t gid)
key_fsgid_changed(current);
proc_id_connector(current, PROC_EVENT_GID);
}
+ security_task_post_setgid(old_fsgid, (gid_t)-1,
+ (gid_t)-1, LSM_SETID_FS);
return old_fsgid;
}
Index: linux-2.6.23.1/security/dummy.c
===
--- linux-2.6.23.1.orig/security/dummy.c
+++ linux-2.6.23.1/security/dummy.c
@@ -698,6 +698,12 @@ static int dummy_cap_extra(struct task_s
return 0;
}
+static int dummy_task_post_setgid(gid_t real, gid_t effective,
+gid_t saved, unsigned int type)
+{
+ return 0;
+}
+
#ifdef CONFIG_SECURITY_NETWORK
static int dummy_unix_stream_connect (struct socket *sock,
struct socket *other,
@@ -1138,5 +1144,6 @@ void security_fixup_ops (struct security
#endif /* CONFIG_KEYS */
set_to_dummy_if_null(ops, cap_extra);
+ set_to_dummy_if_null(ops, task_post_setgid);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] MultiAdmin 1.0.7
[PATCH 3/4] task_post_setgid()
- Implement the task_post_setgid() LSM hook which is required by
MultiAdmin to switch between classes.
(task_post_setuid also switches between classes -- and already exists)
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>, May 01 2006
Modified July 11 2006
---
include/linux/security.h | 13 +
kernel/sys.c | 15 ---
security/dummy.c |7 +++
3 files changed, 32 insertions(+), 3 deletions(-)
Index: linux-2.6.23.1/include/linux/security.h
===
--- linux-2.6.23.1.orig/include/linux/security.h
+++ linux-2.6.23.1/include/linux/security.h
@@ -1400,6 +1400,7 @@ struct security_operations {
#endif /* CONFIG_KEYS */
int (*cap_extra)(struct task_struct *, unsigned int);
+ int (*task_post_setgid)(gid_t, gid_t, gid_t, unsigned int);
};
/* global variables */
@@ -2139,6 +2140,12 @@ static inline int security_cap_extra(str
return security_ops->cap_extra(task, cap);
}
+static inline int security_task_post_setgid(gid_t real, gid_t effective,
+gid_t saved, unsigned int type)
+{
+ return security_ops->task_post_setgid(real, effective, saved, type);
+}
+
/* prototypes */
extern int security_init (void);
extern int register_security (struct security_operations *ops);
@@ -2799,6 +2806,12 @@ static inline int security_cap_extra(str
return 0;
}
+static inline int security_task_post_setgid(gid_t real, gid_t effective,
+gid_t saved, unsigned int type)
+{
+ return 0;
+}
+
static inline struct dentry *securityfs_create_dir(const char *name,
struct dentry *parent)
{
Index: linux-2.6.23.1/kernel/sys.c
===
--- linux-2.6.23.1.orig/kernel/sys.c
+++ linux-2.6.23.1/kernel/sys.c
@@ -1052,7 +1052,8 @@ asmlinkage long sys_setregid(gid_t rgid,
current->gid = new_rgid;
key_fsgid_changed(current);
proc_id_connector(current, PROC_EVENT_GID);
- return 0;
+ return security_task_post_setgid(old_rgid, old_egid,
+ (gid_t)-1, LSM_SETID_RE);
}
/*
@@ -1062,6 +1063,7 @@ asmlinkage long sys_setregid(gid_t rgid,
*/
asmlinkage long sys_setgid(gid_t gid)
{
+ gid_t old_rgid = current->gid;
int old_egid = current->egid;
int retval;
@@ -1087,7 +1089,8 @@ asmlinkage long sys_setgid(gid_t gid)
key_fsgid_changed(current);
proc_id_connector(current, PROC_EVENT_GID);
- return 0;
+ return security_task_post_setgid(old_rgid, (gid_t)-1,
+ (gid_t)-1, LSM_SETID_ID);
}
static int set_user(uid_t new_ruid, int dumpclear)
@@ -1290,6 +1293,9 @@ asmlinkage long sys_getresuid(uid_t __us
*/
asmlinkage long sys_setresgid(gid_t rgid, gid_t egid, gid_t sgid)
{
+ gid_t old_rgid = current->gid;
+ gid_t old_egid = current->egid;
+ gid_t old_sgid = current->sgid;
int retval;
retval = security_task_setgid(rgid, egid, sgid, LSM_SETID_RES);
@@ -1322,7 +1328,8 @@ asmlinkage long sys_setresgid(gid_t rgid
key_fsgid_changed(current);
proc_id_connector(current, PROC_EVENT_GID);
- return 0;
+ return security_task_post_setgid(old_rgid, old_egid,
+ old_sgid, LSM_SETID_RES);
}
asmlinkage long sys_getresgid(gid_t __user *rgid, gid_t __user *egid, gid_t
__user *sgid)
@@ -1391,6 +1398,8 @@ asmlinkage long sys_setfsgid(gid_t gid)
key_fsgid_changed(current);
proc_id_connector(current, PROC_EVENT_GID);
}
+ security_task_post_setgid(old_fsgid, (gid_t)-1,
+ (gid_t)-1, LSM_SETID_FS);
return old_fsgid;
}
Index: linux-2.6.23.1/security/dummy.c
===
--- linux-2.6.23.1.orig/security/dummy.c
+++ linux-2.6.23.1/security/dummy.c
@@ -698,6 +698,12 @@ static int dummy_cap_extra(struct task_s
return 0;
}
+static int dummy_task_post_setgid(gid_t real, gid_t effective,
+gid_t saved, unsigned int type)
+{
+ return 0;
+}
+
#ifdef CONFIG_SECURITY_NETWORK
static int dummy_unix_stream_connect (struct socket *sock,
struct socket *other,
@@ -1138,5 +1144,6 @@ void security_fixup_ops (struct security
#endif /* CONFIG_KEYS */
set_to_dummy_if_null(ops, cap_extra);
+ set_to_dummy_if_null(ops, task_post_setgid);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] MultiAdmin 1.0.7
[PATCH 2/4] Use of capable_light()
capable() now behaves like (capable_light() && is_superadm). Since some
operations are allowed by subadmins too, it suffices to use
capable_light().
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>, May 01 2006
Modified July 11 2006
---
arch/alpha/kernel/pci-noop.c |2 +-
drivers/char/lp.c|2 +-
drivers/firmware/efivars.c |2 +-
drivers/pci/pci-sysfs.c |2 +-
drivers/pci/proc.c |2 +-
drivers/pci/syscall.c|2 +-
fs/quota.c |8
ipc/msg.c|2 +-
ipc/sem.c|2 +-
ipc/shm.c|4 ++--
10 files changed, 14 insertions(+), 14 deletions(-)
Index: linux-2.6.23.1/arch/alpha/kernel/pci-noop.c
===
--- linux-2.6.23.1.orig/arch/alpha/kernel/pci-noop.c
+++ linux-2.6.23.1/arch/alpha/kernel/pci-noop.c
@@ -89,7 +89,7 @@ asmlinkage long
sys_pciconfig_read(unsigned long bus, unsigned long dfn,
unsigned long off, unsigned long len, void *buf)
{
- if (!capable(CAP_SYS_ADMIN))
+ if (!capable_light(CAP_SYS_ADMIN))
return -EPERM;
else
return -ENODEV;
Index: linux-2.6.23.1/drivers/char/lp.c
===
--- linux-2.6.23.1.orig/drivers/char/lp.c
+++ linux-2.6.23.1/drivers/char/lp.c
@@ -627,7 +627,7 @@ static int lp_ioctl(struct inode *inode,
if (copy_to_user(argp, _STAT(minor),
sizeof(struct lp_stats)))
return -EFAULT;
- if (capable(CAP_SYS_ADMIN))
+ if (capable_light(CAP_SYS_ADMIN))
memset(_STAT(minor), 0,
sizeof(struct lp_stats));
break;
Index: linux-2.6.23.1/drivers/firmware/efivars.c
===
--- linux-2.6.23.1.orig/drivers/firmware/efivars.c
+++ linux-2.6.23.1/drivers/firmware/efivars.c
@@ -351,7 +351,7 @@ static ssize_t efivar_attr_show(struct k
struct efivar_attribute *efivar_attr = to_efivar_attr(attr);
ssize_t ret = -EIO;
- if (!capable(CAP_SYS_ADMIN))
+ if (!capable_light(CAP_SYS_ADMIN))
return -EACCES;
if (efivar_attr->show) {
Index: linux-2.6.23.1/drivers/pci/pci-sysfs.c
===
--- linux-2.6.23.1.orig/drivers/pci/pci-sysfs.c
+++ linux-2.6.23.1/drivers/pci/pci-sysfs.c
@@ -222,7 +222,7 @@ pci_read_config(struct kobject *kobj, st
u8 *data = (u8*) buf;
/* Several chips lock up trying to read undefined config space */
- if (capable(CAP_SYS_ADMIN)) {
+ if (capable_light(CAP_SYS_ADMIN)) {
size = dev->cfg_size;
} else if (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
size = 128;
Index: linux-2.6.23.1/drivers/pci/proc.c
===
--- linux-2.6.23.1.orig/drivers/pci/proc.c
+++ linux-2.6.23.1/drivers/pci/proc.c
@@ -59,7 +59,7 @@ proc_bus_pci_read(struct file *file, cha
* undefined locations (think of Intel PIIX4 as a typical example).
*/
- if (capable(CAP_SYS_ADMIN))
+ if (capable_light(CAP_SYS_ADMIN))
size = dev->cfg_size;
else if (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
size = 128;
Index: linux-2.6.23.1/drivers/pci/syscall.c
===
--- linux-2.6.23.1.orig/drivers/pci/syscall.c
+++ linux-2.6.23.1/drivers/pci/syscall.c
@@ -26,7 +26,7 @@ sys_pciconfig_read(unsigned long bus, un
long err;
long cfg_ret;
- if (!capable(CAP_SYS_ADMIN))
+ if (!capable_light(CAP_SYS_ADMIN))
return -EPERM;
err = -ENODEV;
Index: linux-2.6.23.1/fs/quota.c
===
--- linux-2.6.23.1.orig/fs/quota.c
+++ linux-2.6.23.1/fs/quota.c
@@ -82,11 +82,11 @@ static int generic_quotactl_valid(struct
if (cmd == Q_GETQUOTA) {
if (((type == USRQUOTA && current->euid != id) ||
(type == GRPQUOTA && !in_egroup_p(id))) &&
- !capable(CAP_SYS_ADMIN))
+ !capable_light(CAP_SYS_ADMIN))
return -EPERM;
}
else if (cmd != Q_GETFMT && cmd != Q_SYNC && cmd != Q_GETINFO)
- if (!capable(CAP_SYS_ADMIN))
+ if (!capable_light(CAP_SYS_ADMIN))
return -EPERM;
return 0;
@@ -133,10 +133,10 @@ static int xqm_quotactl_valid(struct sup
if (cmd == Q_XGETQUOTA) {
if (((type == XQM_USRQUOTA && current->euid != id) ||
[PATCH 1/4] MultiAdmin 1.0.7
[PATCH 1/4] security_cap_extra() and more
- Renames capable() to capable_light().
This function is used if only a capability is to be checked.
- Implement a new capable that calls security_cap_extra().
Since a subadmin has almost the same capabilities as a
superadmin, an extra helper is needed to decide whether an
action is allowed, based on the philosophy of the LSM.
- implement the .cap_extra LSM hook
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>, May 01 2006
July 11 2006
---
include/linux/capability.h |2 ++
include/linux/security.h | 13 +
kernel/capability.c| 19 ++-
security/dummy.c |6 ++
4 files changed, 39 insertions(+), 1 deletion(-)
Index: linux-2.6.23.1/include/linux/capability.h
===
--- linux-2.6.23.1.orig/include/linux/capability.h
+++ linux-2.6.23.1/include/linux/capability.h
@@ -358,6 +358,8 @@ static inline kernel_cap_t cap_invert(ke
#define cap_is_fs_cap(c) (CAP_TO_MASK(c) & CAP_FS_MASK)
+bool capable_light(unsigned int);
+bool __capable_light(struct task_struct *, unsigned int);
int capable(int cap);
int __capable(struct task_struct *t, int cap);
Index: linux-2.6.23.1/include/linux/security.h
===
--- linux-2.6.23.1.orig/include/linux/security.h
+++ linux-2.6.23.1/include/linux/security.h
@@ -1399,6 +1399,7 @@ struct security_operations {
#endif /* CONFIG_KEYS */
+ int (*cap_extra)(struct task_struct *, unsigned int);
};
/* global variables */
@@ -2132,6 +2133,12 @@ static inline void security_release_secc
return security_ops->release_secctx(secdata, seclen);
}
+static inline int security_cap_extra(struct task_struct *task,
+unsigned int cap)
+{
+ return security_ops->cap_extra(task, cap);
+}
+
/* prototypes */
extern int security_init (void);
extern int register_security (struct security_operations *ops);
@@ -2786,6 +2793,12 @@ static inline int security_netlink_recv
return cap_netlink_recv (skb, cap);
}
+static inline int security_cap_extra(struct task_struct *task,
+unsigned int cap)
+{
+ return 0;
+}
+
static inline struct dentry *securityfs_create_dir(const char *name,
struct dentry *parent)
{
Index: linux-2.6.23.1/kernel/capability.c
===
--- linux-2.6.23.1.orig/kernel/capability.c
+++ linux-2.6.23.1/kernel/capability.c
@@ -238,7 +238,7 @@ out:
int __capable(struct task_struct *t, int cap)
{
- if (security_capable(t, cap) == 0) {
+ if (security_capable(t, cap) == 0 && security_cap_extra(t, cap) == 0) {
t->flags |= PF_SUPERPRIV;
return 1;
}
@@ -251,3 +251,20 @@ int capable(int cap)
return __capable(current, cap);
}
EXPORT_SYMBOL(capable);
+
+bool __capable_light(struct task_struct *t, unsigned int cap)
+{
+ if (security_capable(t, cap) == 0) {
+ t->flags |= PF_SUPERPRIV;
+ return true;
+ }
+ return false;
+}
+EXPORT_SYMBOL(__capable_light);
+
+bool capable_light(unsigned int cap)
+{
+ return __capable_light(current, cap);
+}
+EXPORT_SYMBOL(capable_light);
+
Index: linux-2.6.23.1/security/dummy.c
===
--- linux-2.6.23.1.orig/security/dummy.c
+++ linux-2.6.23.1/security/dummy.c
@@ -693,6 +693,11 @@ static int dummy_netlink_recv (struct sk
return 0;
}
+static int dummy_cap_extra(struct task_struct *task, unsigned int cap)
+{
+ return 0;
+}
+
#ifdef CONFIG_SECURITY_NETWORK
static int dummy_unix_stream_connect (struct socket *sock,
struct socket *other,
@@ -1132,5 +1137,6 @@ void security_fixup_ops (struct security
set_to_dummy_if_null(ops, key_permission);
#endif /* CONFIG_KEYS */
+ set_to_dummy_if_null(ops, cap_extra);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] MultiAdmin 1.0.7
As per James's request, I am reposting the MultiAdmin LSM in its current form (2.6.23.1, still with the modular LSM interface). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix sched_domain sysctl registration again
commit 029190c515f15f512ac85de8fc686d4dbd0ae731 (cpuset
sched_load_balance flag) was not tested SCHED_DEBUG enabled as
committed as it dereferences NULL when used and it reordered
the sysctl registration to cause it to never show any domains
or their tunables.
Fixes:
1) restore arch_init_sched_domains ordering
we can't walk the domains before we build them
presently we register cpus with empty directories (no domain
directories or files).
2) make unregister_sched_domain_sysctl do nothing when already unregistered
detach_destroy_domains is now called one set of cpus at a time
unregister_syctl dereferences NULL if called with a null.
While the the function would always dereference null if called
twice, in the previous code it was always called once and then
was followed a register. So only the hidden bug of the
sysctl_root_table not being allocated followed by an attempt to
free it would have shown the error.
3) always call unregister and register in partition_sched_domains
The code is "smart" about unregistering only needed domains.
Since we aren't guaranteed any calls to unregister, always
unregister. Without calling register on the way out we
will not have a table or any sysctl tree.
4) warn if register is called without unregistering
The previous table memory is lost, leaving pointers to the
later freed memory in sysctl and leaking the memory of the
tables.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
[resend with From set]
against e8b8c977734193adedf2b0f607d6252c78e86394
Before this patch on a 2-core 4-thread box compiled for SMT and NUMA,
the domains appear empty (there are actually 3 levels per cpu). And as
soon as two domains a null pointer is dereferenced (unreliable in this
case is stack garbage):
bu19a:~# ls -R /proc/sys/kernel/sched_domain/
/proc/sys/kernel/sched_domain/:
cpu0 cpu1 cpu2 cpu3
/proc/sys/kernel/sched_domain/cpu0:
/proc/sys/kernel/sched_domain/cpu1:
/proc/sys/kernel/sched_domain/cpu2:
/proc/sys/kernel/sched_domain/cpu3:
bu19a:~# mkdir /dev/cpuset
bu19a:~# mount -tcpuset cpuset /dev/cpuset/
bu19a:~# cd /dev/cpuset/
bu19a:/dev/cpuset# echo 0 > sched_load_balance
bu19a:/dev/cpuset# mkdir one
bu19a:/dev/cpuset# echo 1 > one/cpus
bu19a:/dev/cpuset# echo 0 > one/sched_load_balance
Unable to handle kernel paging request for data at address 0x0018
Faulting instruction address: 0xc006b608
NIP: c006b608 LR: c006b604 CTR:
REGS: c00018d973f0 TRAP: 0300 Not tainted (2.6.23-bml)
MSR: 90009032 CR: 28242442 XER:
DAR: 0018, DSISR: 4000
TASK = c0001912e340[1987] 'bash' THREAD: c00018d94000 CPU: 2
..
NIP [c006b608] .unregister_sysctl_table+0x38/0x110
LR [c006b604] .unregister_sysctl_table+0x34/0x110
Call Trace:
[c00018d97670] [c7017270] 0xc7017270 (unreliable)
[c00018d97720] [c0058710] .detach_destroy_domains+0x30/0xb0
[c00018d977b0] [c005cf1c] .partition_sched_domains+0x1bc/0x230
[c00018d97870] [c009fdc4] .rebuild_sched_domains+0xb4/0x4c0
[c00018d97970] [c00a02e8] .update_flag+0x118/0x170
[c00018d97a80] [c00a1768] .cpuset_common_file_write+0x568/0x820
[c00018d97c00] [c009d95c] .cgroup_file_write+0x7c/0x180
[c00018d97cf0] [c00e76b8] .vfs_write+0xe8/0x1b0
[c00018d97d90] [c00e810c] .sys_write+0x4c/0x90
[c00018d97e30] [c000852c] syscall_exit+0x0/0x40
diff --git a/kernel/sched.c b/kernel/sched.c
index afe76ec..2af50ec 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -5463,11 +5463,12 @@ static void register_sched_domain_sysctl(void)
struct ctl_table *entry = sd_alloc_ctl_entry(cpu_num + 1);
char buf[32];
+ WARN_ON(sd_ctl_dir[0].child);
+ sd_ctl_dir[0].child = entry;
+
if (entry == NULL)
return;
- sd_ctl_dir[0].child = entry;
-
for_each_online_cpu(i) {
snprintf(buf, 32, "cpu%d", i);
entry->procname = kstrdup(buf, GFP_KERNEL);
@@ -5475,14 +5476,19 @@ static void register_sched_domain_sysctl(void)
entry->child = sd_alloc_ctl_cpu_table(i);
entry++;
}
+
+ WARN_ON(sd_sysctl_header);
sd_sysctl_header = register_sysctl_table(sd_ctl_root);
}
+/* may be called multiple times per register */
static void unregister_sched_domain_sysctl(void)
{
- unregister_sysctl_table(sd_sysctl_header);
+ if (sd_sysctl_header)
+ unregister_sysctl_table(sd_sysctl_header);
sd_sysctl_header = NULL;
- sd_free_ctl_entry(_ctl_dir[0].child);
+ if (sd_ctl_dir[0].child)
+ sd_free_ctl_entry(_ctl_dir[0].child);
}
#else
static void register_sched_domain_sysctl(void)
@@ -6426,13 +6432,17 @@
[PATCH] Fix sched_domain sysctl registration again
commit 029190c515f15f512ac85de8fc686d4dbd0ae731 (cpuset
sched_load_balance flag) was not tested SCHED_DEBUG enabled as
committed as it dereferences NULL when used and it reordered
the sysctl registration to cause it to never show any domains
or their tunables.
Fixes:
1) restore arch_init_sched_domains ordering
we can't walk the domains before we build them
presently we register cpus with empty directories (no domain
directories or files).
2) make unregister_sched_domain_sysctl do nothing when already unregistered
detach_destroy_domains is now called one set of cpus at a time
unregister_syctl dereferences NULL if called with a null.
While the the function would always dereference null if called
twice, in the previous code it was always called once and then
was followed a register. So only the hidden bug of the
sysctl_root_table not being allocated followed by an attempt to
free it would have shown the error.
3) always call unregister and register in partition_sched_domains
The code is "smart" about unregistering only needed domains.
Since we aren't guaranteed any calls to unregister, always
unregister. Without calling register on the way out we
will not have a table or any sysctl tree.
4) warn if register is called without unregistering
The previous table memory is lost, leaving pointers to the
later freed memory in sysctl and leaking the memory of the
tables.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
against e8b8c977734193adedf2b0f607d6252c78e86394
Before this patch on a 2-core 4-thread box compiled for SMT and NUMA,
the domains appear empty (there are actually 3 levels per cpu). And as
soon as two domains a null pointer is dereferenced (unreliable in this
case is stack garbage):
bu19a:~# ls -R /proc/sys/kernel/sched_domain/
/proc/sys/kernel/sched_domain/:
cpu0 cpu1 cpu2 cpu3
/proc/sys/kernel/sched_domain/cpu0:
/proc/sys/kernel/sched_domain/cpu1:
/proc/sys/kernel/sched_domain/cpu2:
/proc/sys/kernel/sched_domain/cpu3:
bu19a:~# mkdir /dev/cpuset
bu19a:~# mount -tcpuset cpuset /dev/cpuset/
bu19a:~# cd /dev/cpuset/
bu19a:/dev/cpuset# echo 0 > sched_load_balance
bu19a:/dev/cpuset# mkdir one
bu19a:/dev/cpuset# echo 1 > one/cpus
bu19a:/dev/cpuset# echo 0 > one/sched_load_balance
Unable to handle kernel paging request for data at address 0x0018
Faulting instruction address: 0xc006b608
NIP: c006b608 LR: c006b604 CTR:
REGS: c00018d973f0 TRAP: 0300 Not tainted (2.6.23-bml)
MSR: 90009032 CR: 28242442 XER:
DAR: 0018, DSISR: 4000
TASK = c0001912e340[1987] 'bash' THREAD: c00018d94000 CPU: 2
..
NIP [c006b608] .unregister_sysctl_table+0x38/0x110
LR [c006b604] .unregister_sysctl_table+0x34/0x110
Call Trace:
[c00018d97670] [c7017270] 0xc7017270 (unreliable)
[c00018d97720] [c0058710] .detach_destroy_domains+0x30/0xb0
[c00018d977b0] [c005cf1c] .partition_sched_domains+0x1bc/0x230
[c00018d97870] [c009fdc4] .rebuild_sched_domains+0xb4/0x4c0
[c00018d97970] [c00a02e8] .update_flag+0x118/0x170
[c00018d97a80] [c00a1768] .cpuset_common_file_write+0x568/0x820
[c00018d97c00] [c009d95c] .cgroup_file_write+0x7c/0x180
[c00018d97cf0] [c00e76b8] .vfs_write+0xe8/0x1b0
[c00018d97d90] [c00e810c] .sys_write+0x4c/0x90
[c00018d97e30] [c000852c] syscall_exit+0x0/0x40
diff --git a/kernel/sched.c b/kernel/sched.c
index afe76ec..2af50ec 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -5463,11 +5463,12 @@ static void register_sched_domain_sysctl(void)
struct ctl_table *entry = sd_alloc_ctl_entry(cpu_num + 1);
char buf[32];
+ WARN_ON(sd_ctl_dir[0].child);
+ sd_ctl_dir[0].child = entry;
+
if (entry == NULL)
return;
- sd_ctl_dir[0].child = entry;
-
for_each_online_cpu(i) {
snprintf(buf, 32, "cpu%d", i);
entry->procname = kstrdup(buf, GFP_KERNEL);
@@ -5475,14 +5476,19 @@ static void register_sched_domain_sysctl(void)
entry->child = sd_alloc_ctl_cpu_table(i);
entry++;
}
+
+ WARN_ON(sd_sysctl_header);
sd_sysctl_header = register_sysctl_table(sd_ctl_root);
}
+/* may be called multiple times per register */
static void unregister_sched_domain_sysctl(void)
{
- unregister_sysctl_table(sd_sysctl_header);
+ if (sd_sysctl_header)
+ unregister_sysctl_table(sd_sysctl_header);
sd_sysctl_header = NULL;
- sd_free_ctl_entry(_ctl_dir[0].child);
+ if (sd_ctl_dir[0].child)
+ sd_free_ctl_entry(_ctl_dir[0].child);
}
#else
static void register_sched_domain_sysctl(void)
@@ -6426,13 +6432,17 @@ static cpumask_t
Re: [Rt2400-devel] rt73usb: support for wireless in Kohjinsha subnotebook
Hi,
> Kohjinsha subnotebook seems to contain wifi with USB IDs 0x18e8,
> 0x6206... I hope that to be compatible with
> net/wireless/rt2x00/rt73usb.c .
Is there any reason you assume it is a rt73usb device,
or are you just making wild guesses about what the chipset is?
> [Sidenote: could we add some real author info into rt73usb.c?]
You mean expanding the project name to the full list of developers in
the project? I don't see any need for that.
> I did this on 2.6.23-rc8-mm1 kernel (The RT hack may not be
> neccessary), but then it oopses somewhere in softmac layer. I'll try
> to play with it some more.
>
> If you have any ideas, let me know.
> Pavel
>
> --- clean-mm/drivers/net/wireless/rt2x00/rt73usb.c2007-10-09
> 09:32:08.0 +0200
> +++ linux-mm/drivers/net/wireless/rt2x00/rt73usb.c2007-10-19
> 22:19:45.0 +0200
> @@ -1580,7 +1580,6 @@
>
> if (!rt2x00_rev(>chip, 0x25730)) {
> ERROR(rt2x00dev, "Invalid RT chipset detected.\n");
> - return -ENODEV;
> }
>
> if (!rt2x00_rf(>chip, RF5226) &&
> @@ -1588,7 +1587,6 @@
> !rt2x00_rf(>chip, RF5225) &&
> !rt2x00_rf(>chip, RF2527)) {
> ERROR(rt2x00dev, "Invalid RF chipset detected.\n");
> - return -ENODEV;
> }
Both removals of -ENODEV are completely wrong. If the device does not pass the
above
2 checks it is _not_ a rt73usb device. And forcing the driver to work with the
device will
result in all kinds of problems.
If rt2x00 is loaded and detected the device, it should print out a debug
message that starts with:
"Chipset detected - " What is in your case the complete line?
Ivo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] irq_flags_t: intro and core annotations
One of type of bugs steadily being fought is the following one:
unsigned int flags;
spin_lock_irqsave(, flags);
where "flags" should be "unsigned long". Here is far from complete list of
commits fixing such bugs:
099575b6cb7eaf18211ba72de56264f67651b90b
5efee174f8a101cafb1607d2b629bed353701457
c53421b18f205c5f97c604ae55c6a921f034b0f6(many)
ca7e235f5eb960d83b45cef4384b490672538cd9
361f6ed1d00f666a1a7c33f3e9aaccb713f9b9e4
So far remedies were:
a) grep(1) -- obviously fragile. I tried at some point grepping for
spin_lock_irqsave(), found quite a few, but it became bring quickly.
b) BUILD_BUG_ON(sizeof(flags) != sizeof(unsigned long)) -- was tried,
brutally broke some arches, survived one commit before revert :^)
Doesn't work on i386 where sizeof(unsigned int) == sizeof(unsigned long).
So it would be nice to have something more robust.
irq_flags_t
New type for use with spin_lock_irqsave() and friends.
* irq_flags_t is unsigned long which shouldn't change any code
(except broken one)
* irq_flags_t is marked with __bitwise__ which means sparse(1) will warn
developer when he accidently uses wrong type or totally wrong variable.
* irq_flags_t allows conversion to struct instead of typedef without flag day.
This will give compile-time breakage of buggy users later.
* irq_flags_t allows arch maintainers to eventually switch to something
smaller than "unsigned long" if they want to.
Typical code after conversion:
irq_flags_t flags;
spin_lock_irqsave(, flags);
[stuff]
spin_unlock_irqrestore(, flags);
This patch adds type itself, annotates core locking functions in generic
headers and i386 arch.
P.S.: Anyone checking for differences in sparse logs -- don't panic,
just remove __bitwise__ .
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
include/asm-x86/irqflags_32.h| 20 ++--
include/asm-x86/paravirt.h | 14 +++---
include/linux/interrupt.h| 10 +-
include/linux/irqflags.h |2 +-
include/linux/spinlock_api_smp.h | 14 +++---
include/linux/spinlock_up.h |2 +-
include/linux/types.h|1 +
kernel/spinlock.c| 24
8 files changed, 44 insertions(+), 43 deletions(-)
--- a/include/asm-x86/irqflags_32.h
+++ b/include/asm-x86/irqflags_32.h
@@ -12,14 +12,14 @@
#include
#ifndef __ASSEMBLY__
-static inline unsigned long native_save_fl(void)
+static inline irq_flags_t native_save_fl(void)
{
- unsigned long f;
+ irq_flags_t f;
asm volatile("pushfl ; popl %0":"=g" (f): /* no input */);
return f;
}
-static inline void native_restore_fl(unsigned long f)
+static inline void native_restore_fl(irq_flags_t f)
{
asm volatile("pushl %0 ; popfl": /* no output */
:"g" (f)
@@ -52,12 +52,12 @@ static inline void native_halt(void)
#else
#ifndef __ASSEMBLY__
-static inline unsigned long __raw_local_save_flags(void)
+static inline irq_flags_t __raw_local_save_flags(void)
{
return native_save_fl();
}
-static inline void raw_local_irq_restore(unsigned long flags)
+static inline void raw_local_irq_restore(irq_flags_t flags)
{
native_restore_fl(flags);
}
@@ -93,9 +93,9 @@ static inline void halt(void)
/*
* For spinlocks, etc:
*/
-static inline unsigned long __raw_local_irq_save(void)
+static inline irq_flags_t __raw_local_irq_save(void)
{
- unsigned long flags = __raw_local_save_flags();
+ irq_flags_t flags = __raw_local_save_flags();
raw_local_irq_disable();
@@ -118,14 +118,14 @@ static inline unsigned long __raw_local_irq_save(void)
#define raw_local_irq_save(flags) \
do { (flags) = __raw_local_irq_save(); } while (0)
-static inline int raw_irqs_disabled_flags(unsigned long flags)
+static inline int raw_irqs_disabled_flags(irq_flags_t flags)
{
- return !(flags & X86_EFLAGS_IF);
+ return !((unsigned long __force)flags & X86_EFLAGS_IF);
}
static inline int raw_irqs_disabled(void)
{
- unsigned long flags = __raw_local_save_flags();
+ irq_flags_t flags = __raw_local_save_flags();
return raw_irqs_disabled_flags(flags);
}
--- a/include/asm-x86/paravirt.h
+++ b/include/asm-x86/paravirt.h
@@ -136,8 +136,8 @@ struct pv_irq_ops {
* returned from save_fl are undefined, and may be ignored by
* restore_fl.
*/
- unsigned long (*save_fl)(void);
- void (*restore_fl)(unsigned long);
+ irq_flags_t (*save_fl)(void);
+ void (*restore_fl)(irq_flags_t);
void (*irq_disable)(void);
void (*irq_enable)(void);
void (*safe_halt)(void);
@@ -1014,9 +1014,9 @@ struct paravirt_patch_site {
extern struct paravirt_patch_site __parainstructions[],
__parainstructions_end[];
-static inline unsigned long __raw_local_save_flags(void)
Re: what to call it after 2.6.23 but before 2.6.24-rc1?
In message <[EMAIL PROTECTED]>, Linus Torvalds writes: > On Sat, 20 Oct 2007, Erez Zadok wrote: [...] > - if you are a git user, and got it that way, just use the git name, and >use "git describe" to get it. > >So my current head is called "v2.6.23-6562-g8add244" which tells you >three things: > (a) it's based on 2.6.23 > (b) there's been 6562 commits since 2.6.23 > (c) the top-of-tree abbreviated commit is "8add244". Bingo. git-describe is what I was looking for. It's more accurate to use as a reference even after rcN come out. My current cloned tree of yours sez: v2.6.23-6562-g8add244 One more small git question: I keep a separate tree for unionfs, which I rebase often based on your tree. But my tree sez: $ git-describe v2.6.21-rc1-22880-g3a1848d "v2.6.21-rc1"? What am I missing (some tags I forgot to pull?) Why isn't git-describe saying that I'm based on your latest tree? Thanks, Erez. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] PCI: disable MSI on more ATI NorthBridges
On Fri, 2007-10-19 at 16:21 -0400, Jeff Garzik wrote: > Take a look at tg3.c net driver change > 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar situation. > > However, it may turn out that removing the pci_intx() stuff as a > general > rule is easier than quirking these devices, if enough of them turn > out > to have this hardware bug. We'd have to count how many have this bug vs. how many will emit both intx and msi unless pci_intx is cleared, and then how many do that regardless of pci_intx :-) yuck Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Smackv8: Omit non-cipso labels in cipso_seq_start
Hi!,
[Casey, sending patches in public to get an early review]
Omit non-cipso labels in cipso_seq_start().
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
stopping seq_show() if smk_cipso = NULL only fixes the bug
symptom. We'll issue a BUG() in that case cause it signals a
serious misbehavior in the list entries.
diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
index 55ba2dc..b061cd0 100644
--- a/security/smack/smackfs.c
+++ b/security/smack/smackfs.c
@@ -297,14 +297,22 @@ void smk_cipso_doi(void)
/*
* Seq_file read operations for /smack/cipso
+ *
+ * Omit labels with no associated cipso values from being
+ * displayed in seq_show()
*/
static void *cipso_seq_start(struct seq_file *s, loff_t *pos)
{
+ struct smack_known *skp = smack_known;
+
if (*pos >= smack_cipso_count)
return NULL;
- return smack_known;
+ while (skp && !skp->smk_cipso)
+ skp = skp->smk_next;
+
+ return skp;
}
static void *cipso_seq_next(struct seq_file *s, void *v, loff_t *pos)
@@ -313,9 +321,6 @@ static void *cipso_seq_next(struct seq_file *s, void *v,
loff_t *pos)
(*pos)++;
- /*
-* Omit labels with no associated cipso value
-*/
while (skp && !skp->smk_cipso)
skp = skp->smk_next;
@@ -336,12 +341,11 @@ static int cipso_seq_show(struct seq_file *s, void *v)
int i;
unsigned char m;
- if (scp == NULL)
- return 0;
+ BUG_ON(!scp);
+ cbp = scp->smk_catset;
seq_printf(s, "%s %3d", (char *)>smk_known, scp->smk_level);
- cbp = scp->smk_catset;
for (i = 0; i < SMK_LABELLEN; i++)
for (m = 0x80; m != 0; m >>= 1) {
if (m & cbp[i]) {
--
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: git/cscope with x86 merge
On Sat, 20 Oct 2007, Sam Ravnborg wrote: > > I pulled next branch of git and applied your patch. > > When running > git log --follow -B arch/x86/kernel/vmlinux_64.lds.S > > I got no output at all (in a newly pulled linux kernel dir). Try with "-p". It's possible (nay, likely) that "next" has the bug where "--follow" without a patch generating thing (-p or --stat or one of the other flags that enable diffs) doesn't work at all. It should be fixed in "master". Sadly, Junio has been away for personal reasons for two weeks, so we haven't had that known bug fixed in the regular git tree. Shawn Pearce maintains a repo with known fixes at "git://repo.or.cz/git/spearce.git" in the meantime. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: what to call it after 2.6.23 but before 2.6.24-rc1?
On Sat, 20 Oct 2007, Erez Zadok wrote: > > Linus, is there a preferred name to refer to the kernel version in your tree > after 2.6.23 is out (and the official 2.6.23.y git was created) but before > you release 2.6.24-rc1? Well, since you can only get one of those kernels in two ways, there's a very unambiguous naming policy. - if you got one of the nightly snapshots, name it by the snapshot name (I still call them "nightly snapshots", but they do in fact happen twice a day if there have been changes, so that's not technically correct) So the last snapshot would be linux-2.6.23-git15 This is an exact name, because you can go to kernel.org and look up the exact commit ID that was used to generate it (there's an "ID" file associated with each snapshot there). For bonus points, if you report a bug against such a snapshot, look up the ID yourself, so that others don't have to do that.. - if you are a git user, and got it that way, just use the git name, and use "git describe" to get it. So my current head is called "v2.6.23-6562-g8add244" which tells you three things: (a) it's based on 2.6.23 (b) there's been 6562 commits since 2.6.23 (c) the top-of-tree abbreviated commit is "8add244". > I've seen online references to it as "2.6.24", "2.6.24++", "2.6.24-rc0", > etc. Yeah, please don't use those names. They don't actually tell anything about where in the cycle it is, and as you can see above, there's been 6500+ commits since 2.6.23, so saying "2.6.23-rc0" or similar really isn't very helpful if anybody actually cares about just where in the release cycle you are. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git/cscope with x86 merge
On Sat, 20 Oct 2007, Andi Kleen wrote: > > It's not only next. The latest release (1.5.3.4) has this problem. Yes. It's ok in the master branch, but due to unlucky timing with noticing this bug, and Junio being away, no releases got cut with the fix. In general, the kernel people haven't done many renames (I think it's something we have avoided historically, just because it makes diffs almost totally unreadable - even while git supports "rename diffs", they are turned off by default just to be compatible with people who use quilt and raw patch). So we've basically had a "perfect storm" of (a) Junio being away, (b) a really stupid bug that got introduced recently, (c) a few broken heuristics that had little testing because the kernel almost never does renames anyway and (d) suddenly lots of renames in the kernel all at once. (It's not even just the x86 stuff - we had all the watchdog drivers being moved around too, so we probably had almost as many renames the last two weeks than we've had in the two years preceding it ;) [ Just for fun, I checked. Yup. In the last two weeks, git finds 1120 copies and renames. Over the last two and a half years (ie the whole git timeframe), we have 2136 of them. So we really have done more renames in the last two weeks than we have over the whole rest of the git history, and it wasn't just my imagination ] Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ibmpex: Change printk to dev_{info,err} macros
On Fri, 19 Oct 2007 16:35:07 -0700, Darrick J. Wong wrote:
> Ok, I'll change the message to be a bit more accurate.
> ---
> Clean up printk use in ibmpex.
>
> Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]>
> ---
Acked-by: Jean Delvare <[EMAIL PROTECTED]>
>
> drivers/hwmon/ibmpex.c | 48
> +++-
> 1 files changed, 23 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/hwmon/ibmpex.c b/drivers/hwmon/ibmpex.c
> index c462824..9c9cdb0 100644
> --- a/drivers/hwmon/ibmpex.c
> +++ b/drivers/hwmon/ibmpex.c
> @@ -140,10 +140,10 @@ static int ibmpex_send_message(struct ibmpex_bmc_data
> *data)
>
> return 0;
> out1:
> - printk(KERN_ERR "%s: request_settime=%x\n", __FUNCTION__, err);
> + dev_err(data->bmc_device, "request_settime=%x\n", err);
> return err;
> out:
> - printk(KERN_ERR "%s: validate_addr=%x\n", __FUNCTION__, err);
> + dev_err(data->bmc_device, "validate_addr=%x\n", err);
> return err;
> }
>
> @@ -161,14 +161,14 @@ static int ibmpex_ver_check(struct ibmpex_bmc_data
> *data)
> data->sensor_major = data->rx_msg_data[0];
> data->sensor_minor = data->rx_msg_data[1];
>
> - printk(KERN_INFO DRVNAME ": Found BMC with sensor interface "
> -"v%d.%d %d-%02d-%02d on interface %d\n",
> -data->sensor_major,
> -data->sensor_minor,
> -extract_value(data->rx_msg_data, 2),
> -data->rx_msg_data[4],
> -data->rx_msg_data[5],
> -data->interface);
> + dev_info(data->bmc_device, "Found BMC with sensor interface "
> + "v%d.%d %d-%02d-%02d on interface %d\n",
> + data->sensor_major,
> + data->sensor_minor,
> + extract_value(data->rx_msg_data, 2),
> + data->rx_msg_data[4],
> + data->rx_msg_data[5],
> + data->interface);
>
> return 0;
> }
> @@ -212,8 +212,8 @@ static int ibmpex_query_sensor_data(struct
> ibmpex_bmc_data *data, int sensor)
> wait_for_completion(>read_complete);
>
> if (data->rx_result || data->rx_msg_len < 26) {
> - printk(KERN_ERR "Error reading sensor %d, please check.\n",
> -sensor);
> + dev_err(data->bmc_device, "Error reading sensor %d.\n",
> + sensor);
> return -ENOENT;
> }
>
> @@ -456,8 +456,7 @@ static void ibmpex_register_bmc(int iface, struct device
> *dev)
>
> data = kzalloc(sizeof(*data), GFP_KERNEL);
> if (!data) {
> - printk(KERN_ERR DRVNAME ": Insufficient memory for BMC "
> -"interface %d.\n", data->interface);
> + dev_err(dev, "Insufficient memory for BMC interface.\n");
> return;
> }
>
> @@ -471,9 +470,8 @@ static void ibmpex_register_bmc(int iface, struct device
> *dev)
> err = ipmi_create_user(data->interface, _data.ipmi_hndlrs,
> data, >user);
> if (err < 0) {
> - printk(KERN_ERR DRVNAME ": Error, unable to register user with "
> -"ipmi interface %d\n",
> -data->interface);
> + dev_err(dev, "Unable to register user with IPMI "
> + "interface %d\n", data->interface);
> goto out;
> }
>
> @@ -495,9 +493,9 @@ static void ibmpex_register_bmc(int iface, struct device
> *dev)
> data->hwmon_dev = hwmon_device_register(data->bmc_device);
>
> if (IS_ERR(data->hwmon_dev)) {
> - printk(KERN_ERR DRVNAME ": Error, unable to register hwmon "
> -"class device for interface %d\n",
> -data->interface);
> + dev_err(data->bmc_device, "Unable to register hwmon "
> + "device for IPMI interface %d\n",
> + data->interface);
> goto out_user;
> }
>
> @@ -508,7 +506,7 @@ static void ibmpex_register_bmc(int iface, struct device
> *dev)
> /* Now go find all the sensors */
> err = ibmpex_find_sensors(data);
> if (err) {
> - printk(KERN_ERR "Error %d allocating memory\n", err);
> + dev_err(data->bmc_device, "Error %d finding sensors\n", err);
> goto out_register;
> }
>
> @@ -561,10 +559,10 @@ static void ibmpex_msg_handler(struct ipmi_recv_msg
> *msg, void *user_msg_data)
> struct ibmpex_bmc_data *data = (struct ibmpex_bmc_data *)user_msg_data;
>
> if (msg->msgid != data->tx_msgid) {
> - printk(KERN_ERR "Received msgid (%02x) and transmitted "
> -"msgid (%02x) mismatch!\n",
> -(int)msg->msgid,
> -(int)data->tx_msgid);
> + dev_err(data->bmc_device, "Mismatch between received msgid "
> + "(%02x) and transmitted msgid (%02x)!\n",
> + (int)msg->msgid,
> +
Re: what to call it after 2.6.23 but before 2.6.24-rc1?
On Sat, 20 Oct 2007, Erez Zadok wrote: > > One more small git question: I keep a separate tree for unionfs, which I > rebase often based on your tree. But my tree sez: > > $ git-describe > v2.6.21-rc1-22880-g3a1848d > > "v2.6.21-rc1"? What am I missing (some tags I forgot to pull?) Why isn't > git-describe saying that I'm based on your latest tree? Sounds like you don't have the tags. Do git fetch --tags to get them. There can be several reasons why you don't have the tags, but the two most likely ones are: - really old versions of git didn't fetch tags by default. (not very likely, because it's *really* old, but still, worth mentioning as one possible reason) - if you don't fetch into a "tracking" branch, but instead do an "anonymous" fetch into FETCH_HEAD that is then directly merged (or you just rebase your work on top of it), git won't fetch tags, since it assumes that you only want to fetch the one head you mentioned. but regardless, you can always fetch the tags manually. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in: Driver core: convert block from raw kobjects to core devices
On Sat, 20 Oct 2007, Kay Sievers wrote:
> Here is what I see, the error handler hangs without the final put and
> the kobject never gets cleaned up. Note the missing:
> kobject sdb: cleaning up
>
> What is your CONFIG_SYSFS_DEPRECATED option? I have it unset, and that
> may be the difference in the behavior if you have it set.
It's unset in my config also. No, the difference lies somewhere else.
The plug-in parts are the same, but we differ in the remove parts. On
your system, unlink_gendisk ends up dropping only one reference instead
of two. This suggests that something strange is happening to the
request_queue on your machine.
Can you try running the attached patch (without the previous patch)?
It traces the various release routines. The idea is that both the
scsi_disk and the scsi_device hold references to the request_queue,
and these references get dropped in their respective release routines.
Just for the record, here's what happens with this patch on my system,
without the put_device call in del_gendisk (the patch comments it out).
I plugged in a USB drive and let things settle down. Then unplugging
the drive gave this:
[ 457.916995] usb 6-4: USB disconnect, address 3
[ 457.918459] usb 6-4: unregistering device
[ 457.920570] usb 6-4: usb_disable_device nuking all URBs
[ 457.920859] usb 6-4: unregistering interface 6-4:1.0
[ 457.958990] disk_release: kobj cedcda50
The line above refers to the /dev/sda1 partition. Ignore it.
[ 458.012317] del_gendisk sda, kobj ce8be990, queue cd9b2000, refcount before
put_device 2
2 references: one from the scsi_disk and one from the request_queue.
[ 458.013133] scsi_disk_release: disk sda, kobj ce8be990, refcount before
put_disk 2
[ 458.032420] scsi_device_dev_release: rq cd9b2000
These lines show where the two references to the request_queue get
dropped. As a result the queue is released, causing the gendisk to be
released as well:
[ 458.032766] blk_release_queue: rq cd9b2000, parent ce8be990
[ 458.032973] disk_release: kobj ce8be990
[ 458.051641] usb 6-4:1.0: uevent
[ 458.052001] usb 6-4:1.0: uevent
[ 458.068665] usb 6-4: uevent
If you don't get a similar sequence of events, it must indicate that
something on your system continues to hold an outstanding reference.
Maybe an automounter program, or something like that.
Alan Stern
Index: 2.6.23/block/genhd.c
===
--- 2.6.23.orig/block/genhd.c
+++ 2.6.23/block/genhd.c
@@ -496,6 +496,7 @@ static void disk_release(struct device *
{
struct gendisk *disk = dev_to_disk(dev);
+ printk(KERN_INFO "disk_release: kobj %p\n", >dev.kobj);
kfree(disk->random);
kfree(disk->part);
free_disk_stats(disk);
Index: 2.6.23/block/ll_rw_blk.c
===
--- 2.6.23.orig/block/ll_rw_blk.c
+++ 2.6.23/block/ll_rw_blk.c
@@ -1781,6 +1781,8 @@ static void blk_release_queue(struct kob
container_of(kobj, struct request_queue, kobj);
struct request_list *rl = >rq;
+ printk(KERN_INFO "blk_release_queue: rq %p, parent %p\n",
+ q, q->kobj.parent);
blk_sync_queue(q);
if (rl->rq_pool)
Index: 2.6.23/drivers/scsi/scsi_sysfs.c
===
--- 2.6.23.orig/drivers/scsi/scsi_sysfs.c
+++ 2.6.23/drivers/scsi/scsi_sysfs.c
@@ -238,6 +238,8 @@ static void scsi_device_dev_release_user
list_del(>starved_entry);
spin_unlock_irqrestore(sdev->host->host_lock, flags);
+ printk(KERN_INFO "scsi_device_dev_release: rq %p\n",
+ sdev->request_queue);
if (sdev->request_queue) {
sdev->request_queue->queuedata = NULL;
/* user context needed to free queue */
Index: 2.6.23/fs/partitions/check.c
===
--- 2.6.23.orig/fs/partitions/check.c
+++ 2.6.23/fs/partitions/check.c
@@ -516,5 +516,9 @@ void del_gendisk(struct gendisk *disk)
sysfs_remove_link(_depr, disk->dev.bus_id);
#endif
device_del(>dev);
- put_device(>dev);
+ printk(KERN_INFO "del_gendisk %s, kobj %p, queue %p, "
+ "refcount before put_device %d\n",
+ disk->dev.bus_id, >dev.kobj, disk->queue,
+ atomic_read(>dev.kobj.kref.refcount));
+// put_device(>dev);
}
Index: 2.6.23/drivers/scsi/sd.c
===
--- 2.6.23.orig/drivers/scsi/sd.c
+++ 2.6.23/drivers/scsi/sd.c
@@ -1738,6 +1738,10 @@ static void scsi_disk_release(struct cla
spin_unlock(_index_lock);
disk->private_data = NULL;
+ printk(KERN_INFO "scsi_disk_release: disk %s, kobj %p, "
+ "refcount before put_disk %d\n",
+ disk->dev.bus_id, >dev.kobj,
+
[PATCH 2/2] irq_flags_t: annotate kernel/
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
include/linux/sched.h|4 +-
kernel/audit.c | 10 +++---
kernel/cpu_acct.c|2 -
kernel/delayacct.c |6 +--
kernel/hrtimer.c | 16 -
kernel/irq/chip.c| 16 -
kernel/irq/manage.c | 12 +++
kernel/irq/migration.c |2 -
kernel/irq/proc.c|2 -
kernel/latency.c |6 +--
kernel/mutex.c |6 +--
kernel/notifier.c|4 +-
kernel/panic.c |2 -
kernel/pid.c |2 -
kernel/posix-cpu-timers.c|2 -
kernel/posix-timers.c| 24 +++---
kernel/power/process.c |4 +-
kernel/printk.c | 10 +++---
kernel/profile.c |3 +
kernel/ptrace.c |2 -
kernel/rcupdate.c|4 +-
kernel/rtmutex.c | 14
kernel/sched.c | 54 -
kernel/sched_debug.c |4 +-
kernel/signal.c | 28 -
kernel/softirq.c |8 ++--
kernel/sys.c |2 -
kernel/taskstats.c |4 +-
kernel/time/clockevents.c|2 -
kernel/time/clocksource.c| 12 +++
kernel/time/tick-broadcast.c | 17 +-
kernel/time/tick-common.c|8 ++--
kernel/time/tick-sched.c |5 +--
kernel/time/timekeeping.c|8 ++--
kernel/time/timer_list.c |2 -
kernel/time/timer_stats.c|4 +-
kernel/timer.c | 10 +++---
kernel/user.c| 12 +++
kernel/wait.c| 12 +++
kernel/workqueue.c |2 -
40 files changed, 175 insertions(+), 172 deletions(-)
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1767,10 +1767,10 @@ static inline void task_unlock(struct task_struct *p)
}
extern struct sighand_struct *lock_task_sighand(struct task_struct *tsk,
- unsigned long *flags);
+ irq_flags_t *flags);
static inline void unlock_task_sighand(struct task_struct *tsk,
- unsigned long *flags)
+ irq_flags_t *flags)
{
spin_unlock_irqrestore(>sighand->siglock, *flags);
}
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -176,7 +176,7 @@ static inline int audit_rate_check(void)
static unsigned longlast_check = 0;
static int messages = 0;
static DEFINE_SPINLOCK(lock);
- unsigned long flags;
+ irq_flags_t flags;
unsigned long now;
unsigned long elapsed;
int retval = 0;
@@ -212,7 +212,7 @@ void audit_log_lost(const char *message)
{
static unsigned longlast_msg = 0;
static DEFINE_SPINLOCK(lock);
- unsigned long flags;
+ irq_flags_t flags;
unsigned long now;
int print;
@@ -914,7 +914,7 @@ __setup("audit=", audit_enable);
static void audit_buffer_free(struct audit_buffer *ab)
{
- unsigned long flags;
+ irq_flags_t flags;
if (!ab)
return;
@@ -935,7 +935,7 @@ static void audit_buffer_free(struct audit_buffer *ab)
static struct audit_buffer * audit_buffer_alloc(struct audit_context *ctx,
gfp_t gfp_mask, int type)
{
- unsigned long flags;
+ irq_flags_t flags;
struct audit_buffer *ab = NULL;
struct nlmsghdr *nlh;
@@ -993,7 +993,7 @@ unsigned int audit_serial(void)
static DEFINE_SPINLOCK(serial_lock);
static unsigned int serial = 0;
- unsigned long flags;
+ irq_flags_t flags;
unsigned int ret;
spin_lock_irqsave(_lock, flags);
--- a/kernel/cpu_acct.c
+++ b/kernel/cpu_acct.c
@@ -160,7 +160,7 @@ void cpuacct_charge(struct task_struct *task, cputime_t
cputime)
{
struct cpuacct *ca;
- unsigned long flags;
+ irq_flags_t flags;
if (!cpuacct_subsys.active)
return;
--- a/kernel/delayacct.c
+++ b/kernel/delayacct.c
@@ -62,7 +62,7 @@ static void delayacct_end(struct timespec *start, struct
timespec *end,
{
struct timespec ts;
s64 ns;
- unsigned long flags;
+ irq_flags_t flags;
do_posix_clock_monotonic_gettime(end);
ts = timespec_sub(*end, *start);
@@ -101,7 +101,7 @@ int __delayacct_add_tsk(struct taskstats *d, struct
task_struct *tsk)
s64 tmp;
unsigned long t1;
unsigned long long t2, t3;
- unsigned long flags;
+ irq_flags_t flags;
struct timespec ts;
/* Though tsk->delays accessed later, early exit avoids
@@ -156,7
Re: nfsv2 ref leak in 2.6.24?
In message <[EMAIL PROTECTED]>, Erez Zadok writes:
> In message <[EMAIL PROTECTED]>, Trond Myklebust writes:
[...]
> > Looking at
> > nfs_proc_create(), there is indeed a missing call to
> > nfs_mark_for_revalidate(). The reason why you need such a call being the
> > usual one: NFSv2 doesn't provide post-op attributes for the directory.
> >
> > The patch below ought to fix the problem.
>
> It fixes some, but breaks others. The test script I sent yesterday indeed
> passes. And more of my unionfs-on-nfs2 tests pass, but not all. Three of
> my unionfs tests (create w/ copyup, unlink open files, and unlink with a
> whiteout) fail b/c they detect leftover silly-renamed files. Worse, now the
> same three tests also fail when I use unionfs on top of nfs3/nfs4: before
> the one line fix below, unionfs-on-nfsv3/4 worked fine.
>
> Was there any significant semantic change in the behaviour of silly-renamed
> files in nfs in 2.6.24? If so, then I may have to change how unionfs
> handles refcounts and such.
>
> I'll try to dig deeper and see if I can come up with a small test case that
> doesn't involve unionfs.
>
> Thanks,
> Erez.
>
> > Cheers
> > Trond
> > -- CUT HERE ---
> > From: Trond Myklebust <[EMAIL PROTECTED]>
> > Date: Sat, 20 Oct 2007 13:07:21 -0400
> > NFSv2: Ensure that the directory metadata gets revalidated on file create
> >
> > Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
> > ---
> >
> > fs/nfs/proc.c |1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/nfs/proc.c b/fs/nfs/proc.c
> > index 97669ed..4f80d88 100644
> > --- a/fs/nfs/proc.c
> > +++ b/fs/nfs/proc.c
> > @@ -211,6 +211,7 @@ nfs_proc_create(struct inode *dir, struct dentry
> > *dentry, struct iattr *sattr,
> > nfs_fattr_init();
> > dprintk("NFS call create %s\n", dentry->d_name.name);
> > status = rpc_call_sync(NFS_CLIENT(dir), , 0);
> > + nfs_mark_for_revalidate(dir);
> > if (status == 0)
> > status = nfs_instantiate(dentry, , );
> > dprintk("NFS reply create: %d\n", status);
>
> Erez.
Trond, I verified that w/ the above patch the problem is w/ nfs: the client
leaves .nfsXXX files behind for every file unlinked while open. Let me know
when you get a fix and I'll test it.
Cheers,
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: tristate and bool not enogh for Kconfig anymore
On Sat, Oct 20, 2007 at 02:42:38PM +0200, Henrik Carlqvist wrote: > I think there is a need for Kconfig to specify that a functionality could > be built as a module or not built at all. I assume depends on MODULES should do the trick. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git/cscope with x86 merge
On Sat, Oct 20, 2007 at 11:49:51AM -0700, Linus Torvalds wrote: > > > On Sat, 20 Oct 2007, Linus Torvalds wrote: > > > > I could perhaps look at making "git log --follow" also break up files that > > got totally rewritten (git already has a notion of "-B" to do that), but > > no, we don't do it right now. > > Ok, if you guys have a current git source, and want to try something out, > this fairly small patch does this. I pulled next branch of git and applied your patch. When running git log --follow -B arch/x86/kernel/vmlinux_64.lds.S I got no output at all (in a newly pulled linux kernel dir). When I ran git log arch/x86/kernel/vmlinux_64.lds.S I got: commit 250c22777fe1ccd7ac588579a6c16db4c0161cc5 Author: Thomas Gleixner <[EMAIL PROTECTED]> Date: Thu Oct 11 11:17:24 2007 +0200 x86_64: move kernel Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> With -B alone I got same output. When I add --follow I get no output. I could not get back to my previous git binary - I replaced it with the new one. cat ~/.gitconfig [diff] renamelimit = 0 Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nfsv2 ref leak in 2.6.24?
In message <[EMAIL PROTECTED]>, Trond Myklebust writes:
>
> On Fri, 2007-10-19 at 22:33 -0400, Erez Zadok wrote:
> > Trond, good news. I was able to narrow down the problem to purely the
> > client-side, probably dcache/readdir related, and I have a shell script that
> > deterministically triggers the problem each time for me (this is a FC6 image
> > under Vmware 6.0.1). Here's a short shell script which reliably triggers
> > the "lost files" problem -- I create a file via nfs2 on the client side, and
> > sometimes it doesn't show up in readdir, but it is there if you stat it
> > directly.
>
> Ah... I got confused as to what you were measuring and where.
Yeah, I wasn't sure myself until I narrowed it down to a small test case.
> Looking at
> nfs_proc_create(), there is indeed a missing call to
> nfs_mark_for_revalidate(). The reason why you need such a call being the
> usual one: NFSv2 doesn't provide post-op attributes for the directory.
>
> The patch below ought to fix the problem.
It fixes some, but breaks others. The test script I sent yesterday indeed
passes. And more of my unionfs-on-nfs2 tests pass, but not all. Three of
my unionfs tests (create w/ copyup, unlink open files, and unlink with a
whiteout) fail b/c they detect leftover silly-renamed files. Worse, now the
same three tests also fail when I use unionfs on top of nfs3/nfs4: before
the one line fix below, unionfs-on-nfsv3/4 worked fine.
Was there any significant semantic change in the behaviour of silly-renamed
files in nfs in 2.6.24? If so, then I may have to change how unionfs
handles refcounts and such.
I'll try to dig deeper and see if I can come up with a small test case that
doesn't involve unionfs.
Thanks,
Erez.
> Cheers
> Trond
> -- CUT HERE ---
> From: Trond Myklebust <[EMAIL PROTECTED]>
> Date: Sat, 20 Oct 2007 13:07:21 -0400
> NFSv2: Ensure that the directory metadata gets revalidated on file create
>
> Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
> ---
>
> fs/nfs/proc.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/fs/nfs/proc.c b/fs/nfs/proc.c
> index 97669ed..4f80d88 100644
> --- a/fs/nfs/proc.c
> +++ b/fs/nfs/proc.c
> @@ -211,6 +211,7 @@ nfs_proc_create(struct inode *dir, struct dentry *dentry,
> struct iattr *sattr,
> nfs_fattr_init();
> dprintk("NFS call create %s\n", dentry->d_name.name);
> status = rpc_call_sync(NFS_CLIENT(dir), , 0);
> + nfs_mark_for_revalidate(dir);
> if (status == 0)
> status = nfs_instantiate(dentry, , );
> dprintk("NFS reply create: %d\n", status);
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: merge required-features.h
On Sat, 20 Oct 2007, Brian Gerst wrote: > Signed-off-by: Brian Gerst <[EMAIL PROTECTED]> > --- > include/asm-x86/required-features.h| 73 ++- > include/asm-x86/required-features_32.h | 55 > include/asm-x86/required-features_64.h | 46 > 3 files changed, 70 insertions(+), 104 deletions(-) > delete mode 100644 include/asm-x86/required-features_32.h > delete mode 100644 include/asm-x86/required-features_64.h Applied, thanks. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git/cscope with x86 merge
On Sat, 20 Oct 2007, Linus Torvalds wrote: > > I could perhaps look at making "git log --follow" also break up files that > got totally rewritten (git already has a notion of "-B" to do that), but > no, we don't do it right now. Ok, if you guys have a current git source, and want to try something out, this fairly small patch does this. As mentioned, git already supports the notion of "try to break files with the same name if the contents are too dissimilar". In other words, even if a file exists under the same name in both the old revision and in the newer one, we'll look at just how big the changes are, and if git decides that it looks like the whole file was rewritten, then git will split up the diff into a "delete old contents" and "create new contents". That then allows it to consider the file for rename detection. (The rename detection may, of course, decide that the original file was the best source after all.. ;) However, "git log --follow" didn't ever actually enable that for the logic that tries to figure out where a file came from, so you would only see this when generating the diffs, never in the file history logic. That's an easy one-liner to tree-diff.c: try_to_follow_renames(). However, when I actually tried it, it turns out that the break logic was broken - nobody has ever really depended on it. So while it was a one-liner to make "git log --follow" understand to break files that seem to be totally rewritten, it still didn't actually work, because the changes that totally rewrote vmlinux.lds.S wouldn't trigger the break logic. So most of this (still fairly small patch) is just fixing the break logic in diffcore-break.c:should_break(). It hasn't gotten a lot of testing, but it does actually improve other cases too, so I think this is the right thign to do. I'll bring it up on the git lists. Oh, and with this patch, the "break same filename" is still off by default. You need to do git log --follow -B arch/x86/kernel/vmlinux_64.lds.S to enable the file-rewritten-so-break-associations detection. I suspect it makes sense to enable -B by default when using --follow (--follow already obviously implies rename detection), but that's a separate and independent issue. Linus diffcore-break.c | 11 +++ tree-diff.c |1 + 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/diffcore-break.c b/diffcore-break.c index ae8a7d0..c71a226 100644 --- a/diffcore-break.c +++ b/diffcore-break.c @@ -45,8 +45,8 @@ static int should_break(struct diff_filespec *src, * The value we return is 1 if we want the pair to be broken, * or 0 if we do not. */ - unsigned long delta_size, base_size, src_copied, literal_added, - src_removed; + unsigned long delta_size, base_size, max_size; + unsigned long src_copied, literal_added, src_removed; *merge_score_p = 0; /* assume no deletion --- "do not break" * is the default. @@ -63,7 +63,8 @@ static int should_break(struct diff_filespec *src, return 0; /* error but caught downstream */ base_size = ((src->size < dst->size) ? src->size : dst->size); - if (base_size < MINIMUM_BREAK_SIZE) + max_size = ((src->size > dst->size) ? src->size : dst->size); + if (max_size < MINIMUM_BREAK_SIZE) return 0; /* we do not break too small filepair */ if (diffcore_count_changes(src, dst, @@ -89,12 +90,14 @@ static int should_break(struct diff_filespec *src, * less than the minimum, after rename/copy runs. */ *merge_score_p = (int)(src_removed * MAX_SCORE / src->size); + if (*merge_score_p > break_score) + return 1; /* Extent of damage, which counts both inserts and * deletes. */ delta_size = src_removed + literal_added; - if (delta_size * MAX_SCORE / base_size < break_score) + if (delta_size * MAX_SCORE / max_size < break_score) return 0; /* If you removed a lot without adding new material, that is diff --git a/tree-diff.c b/tree-diff.c index 26bdbdd..7c261fd 100644 --- a/tree-diff.c +++ b/tree-diff.c @@ -319,6 +319,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co diff_opts.detect_rename = DIFF_DETECT_RENAME; diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT; diff_opts.single_follow = opt->paths[0]; + diff_opts.break_opt = opt->break_opt; paths[0] = NULL; diff_tree_setup_paths(paths, _opts); if (diff_setup_done(_opts) < 0) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] restore arch/ppc/boot cflags
On Sat, Oct 20, 2007 at 03:58:03AM -0500, Milton Miller wrote:
> Commit 9a39e273d4df0560c724c5fe71f6314a0583ca2b removed the boot directory
> addition to CFLAGS that was being used by the subdirectory builds. For the
> other files, that patch set EXTRA_CFLAGS, but Makefile.build explicitly
> sets that to empty as it is explicitly for a single directory only.
> Append to KBUILD_CFLAGS instead.
Neat - I had not figured out that the assignmnet took effect
recursively.
I have applied following patch.
Sam
>From 437374e9a95062fe310b901e48585691edaf5dd0 Mon Sep 17 00:00:00 2001
From: Milton Miller <[EMAIL PROTECTED]>
Date: Sat, 20 Oct 2007 03:58:03 -0500
Subject: [PATCH] kbuild: restore arch/{ppc/xtensa}/boot cflags
Commit 9a39e273d4df0560c724c5fe71f6314a0583ca2b removed the boot directory
addition to CFLAGS that was being used by the subdirectory builds. For the
other files, that patch set EXTRA_CFLAGS, but Makefile.build explicitly
sets that to empty as it is explicitly for a single directory only.
Append to KBUILD_CFLAGS instead.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
arch/ppc/boot/Makefile|2 ++
arch/xtensa/boot/Makefile |3 ++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/boot/Makefile b/arch/ppc/boot/Makefile
index 487dc66..500497e 100644
--- a/arch/ppc/boot/Makefile
+++ b/arch/ppc/boot/Makefile
@@ -13,6 +13,8 @@
# modified by Cort ([EMAIL PROTECTED])
#
+# KBUILD_CFLAGS used when building rest of boot (takes effect recursively)
+KBUILD_CFLAGS += -fno-builtin -D__BOOTER__ -Iarch/$(ARCH)/boot/include
HOSTCFLAGS += -Iarch/$(ARCH)/boot/include
BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd
diff --git a/arch/xtensa/boot/Makefile b/arch/xtensa/boot/Makefile
index 9c5185f..40aa55b 100644
--- a/arch/xtensa/boot/Makefile
+++ b/arch/xtensa/boot/Makefile
@@ -8,7 +8,8 @@
#
-EXTRA_CFLAGS += -fno-builtin -Iarch/$(ARCH)/boot/include
+# KBUILD_CFLAGS used when building rest of boot (takes effect recursively)
+KBUILD_CFLAGS += -fno-builtin -Iarch/$(ARCH)/boot/include
HOSTFLAGS += -Iarch/$(ARCH)/boot/include
BIG_ENDIAN := $(shell echo -e __XTENSA_EB__ | $(CC) -E - | grep -v "\#")
--
1.5.3.4.206.g58ba4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
rt73usb: support for wireless in Kohjinsha subnotebook
Hi!
Kohjinsha subnotebook seems to contain wifi with USB IDs 0x18e8,
0x6206... I hope that to be compatible with
net/wireless/rt2x00/rt73usb.c .
[Sidenote: could we add some real author info into rt73usb.c?]
I did this on 2.6.23-rc8-mm1 kernel (The RT hack may not be
neccessary), but then it oopses somewhere in softmac layer. I'll try
to play with it some more.
If you have any ideas, let me know.
Pavel
--- clean-mm/drivers/net/wireless/rt2x00/rt73usb.c 2007-10-09
09:32:08.0 +0200
+++ linux-mm/drivers/net/wireless/rt2x00/rt73usb.c 2007-10-19
22:19:45.0 +0200
@@ -1580,7 +1580,6 @@
if (!rt2x00_rev(>chip, 0x25730)) {
ERROR(rt2x00dev, "Invalid RT chipset detected.\n");
- return -ENODEV;
}
if (!rt2x00_rf(>chip, RF5226) &&
@@ -1588,7 +1587,6 @@
!rt2x00_rf(>chip, RF5225) &&
!rt2x00_rf(>chip, RF2527)) {
ERROR(rt2x00dev, "Invalid RF chipset detected.\n");
- return -ENODEV;
}
/*
@@ -2080,6 +2078,7 @@
{ USB_DEVICE(0x148f, 0x2671), USB_DEVICE_DATA(_ops) },
/* Qcom */
{ USB_DEVICE(0x18e8, 0x6196), USB_DEVICE_DATA(_ops) },
+ { USB_DEVICE(0x18e8, 0x6206), USB_DEVICE_DATA(_ops) },
{ USB_DEVICE(0x18e8, 0x6229), USB_DEVICE_DATA(_ops) },
{ USB_DEVICE(0x18e8, 0x6238), USB_DEVICE_DATA(_ops) },
/* Senao */
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/7] Immediate Values - i386 Optimization
Mathieu Desnoyers wrote: I have tried generating asm-to-"register" c variables for char, short and int on i386 and I do not see this happening. The char opcode is always 1 byte, short 2 bytes and int 1 byte. Result: The comment was referring to x86-64, but I incorrectly remembered that applying to "movq $imm,%reg" as opposed to loading from an absolute address. gas actually has a special opcode (movabs) for the 64-bit version of the latter variant, which is only available with %rax and its subregisters. Nevermind, in other words. It's still true, though, that the immediate will always be the last thing in the instruction -- that's a fixture of the instruction format. gcc version 4.1.3 20070812 (prerelease) (Debian 4.1.2-15) 8: b3 02 mov$0x2,%bl a: b1 03 mov$0x3,%cl c: b2 04 mov$0x4,%dl e: b0 05 mov$0x5,%al 4f: 66 be 06 00 mov$0x6,%si 53: 66 bb 07 00 mov$0x7,%bx 57: 66 b9 08 00 mov$0x8,%cx 5b: 66 ba 09 00 mov$0x9,%dx 5f: 66 b8 0a 00 mov$0xa,%ax 9f: bb 0b 00 00 00 mov$0xb,%ebx a4: be 0c 00 00 00 mov$0xc,%esi a9: b9 0d 00 00 00 mov$0xd,%ecx ae: ba 0e 00 00 00 mov$0xe,%edx b3: b8 0f 00 00 00 mov$0xf,%eax I notice that having a "=r" inline assembly that outputs to the first "register char" variable seems to be problematic. It fails with the following error: /tmp/ccy35Hq1.s: Assembler messages: /tmp/ccy35Hq1.s:15: Error: bad register name `%sil' 'r' is wrong for 8-bit variables on i386. It needs to be 'q'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Laptop keyboard unusable when ACPI is active was Re: [2.6.22] i8042, ACPI, ipw2100 and issues reported by psmouse.c atkbd.c
Hi! > > Try disabling acpi embedded controller. > > > How can I accomplish this? Are you referring to the i8042? rmmod acpi_ec or how is it called. But I'm not sure how easy this is. > > Try watching keyboard interrupts. Are they lost? > > > I am pretty sure they are. I think that ACPI pauses interrupts for a > while (100ms?) and so some keyboard interrupts are lost. input layer can poll keyboard on its own, perhaps that helps? Can you try to measure the interrupt latencies? Does this happen in init=/bin/bash? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xconfig: set title bar
On Sat, Oct 20, 2007 at 11:18:47AM -0700, Randy Dunlap wrote:
> On Sat, 20 Oct 2007 19:14:03 +0200 Sam Ravnborg wrote:
>
> > I found this one to work:
> > + setCaption("hello my little world");
>
> Thanks, your search expressions were better than mine.
>
> > We should show the prompt associated with mainmenu here.
>
> You want all 3 of them converted to
> symbol_value(mainmenu) + $KERNELVERSION
Well - if mainmenu should serve any purpose then yes.
> ?
>
> ---
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Put kernel version info on title bar in xconfig (qconf) instead of
> defaulting to "qconf".
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
> ---
> scripts/kconfig/qconf.cc |4
> 1 file changed, 4 insertions(+)
>
> --- linux-2.6.23-git13.orig/scripts/kconfig/qconf.cc
> +++ linux-2.6.23-git13/scripts/kconfig/qconf.cc
> @@ -1274,8 +1274,12 @@ ConfigMainWindow::ConfigMainWindow(void)
> QMenuBar* menu;
> bool ok;
> int x, y, width, height;
> + char title[256];
>
> QWidget *d = configApp->desktop();
> + sprintf(title, _("Linux Kernel v%s Configuration"),
I made this look like this:
> + snprintf(title, sizeof(title), _("Linux Kernel v%s Configuration"),
because we may append to the KERNELVERSION using EXTRAVERSION and people could
go insane.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
I'll try to, but it may take some time. Jan >>> Sam Ravnborg <[EMAIL PROTECTED]> 10/20/07 6:50 PM >>> Jan - I assume you will look into this. And thanks to David/Randy for narrowing this down. Thanks, Sam On Fri, Oct 19, 2007 at 09:25:55PM -0700, Linus Torvalds wrote: > > > On Fri, 19 Oct 2007, David Brownell wrote: > > > > My (quick, meaning that I may have missed something) testing > > > indicates that the problem is in the patches attached. > > > > Yes, reverting this seems to resolve the problem: > > > > > a5bf3d891a6a0fb5aa122792d965e3774108b923 > > > > > > Change kconfig behavior so that mixing bool and tristate config settings > > > in > > > a choice is possible and has the desired effect of offering just the > > > tristate options individually if the choice gets set to M, and a normal > > > boolean selection if the choice gets set to Y. > > > > Reverting this patch also fixes a second problem that I didn't > > mention: various dependent options couldn't be enabled. > > > > Again in drivers/usb/gadget/Kconfig, examples include the > > ability to configure the Ethernet gadget to act as an RNDIS > > peripheral; or enabling Mass Storage gadget debug options. > > > > > > Good sleuthing, and thanks! > > > > Now we just need to see that patch reverted before RC1... I don't > > know how Linus deals with all his LKML mail, so I cc'd him in > > the hope that direct messages get through a bit faster. > > Ok, I'll revert it, but wanted to make sure that the parties that pushed > the change are aware of this. > > Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git/cscope with x86 merge
On Sat, 20 Oct 2007, Sam Ravnborg wrote:
>
> But you do not see the rename arch/x86_64/kernel/{vmlinux.lds.S =>
> vmlinux.lds.S}
Umm. What you are describing isn't a rename - that's the same name. Do you
perhaps mean vmlinux.lds.S => vmlinux_64.lds.S ?
And yes, it doesn't show that as a rename, because of the fact that the
arch/x86_64/kernel/vmlinux.lds.S
file actually *remained*, so it wasn't really a rename. It just got almost
all of its data changed.
So there was never really a rename: there was a "copy" and a "rewrite".
And "git --follow" doesn't follow copies.
However, "git blame" does do so. So if you do
git blame -C arch/x86/kernel/vmlinux_64.lds.S
(where that -C tells it to follow data across file copies), it will
actually show the history down, line for line!
But when you try to follow the history of the whole *file*, git sees that
the filename still existed of the source, so it won't consider that a
candidate for renames!
I could perhaps look at making "git log --follow" also break up files that
got totally rewritten (git already has a notion of "-B" to do that), but
no, we don't do it right now. (But one of the advantages of the git model
is that none of this is hardcoded in the repository data itself, so we can
improve the rename following and it will automatically work with any repo,
even one created with older git versions)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xconfig: set title bar
On Sat, 20 Oct 2007 19:14:03 +0200 Sam Ravnborg wrote:
> I found this one to work:
> + setCaption("hello my little world");
Thanks, your search expressions were better than mine.
> We should show the prompt associated with mainmenu here.
You want all 3 of them converted to
symbol_value(mainmenu) + $KERNELVERSION
?
---
From: Randy Dunlap <[EMAIL PROTECTED]>
Put kernel version info on title bar in xconfig (qconf) instead of
defaulting to "qconf".
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
scripts/kconfig/qconf.cc |4
1 file changed, 4 insertions(+)
--- linux-2.6.23-git13.orig/scripts/kconfig/qconf.cc
+++ linux-2.6.23-git13/scripts/kconfig/qconf.cc
@@ -1274,8 +1274,12 @@ ConfigMainWindow::ConfigMainWindow(void)
QMenuBar* menu;
bool ok;
int x, y, width, height;
+ char title[256];
QWidget *d = configApp->desktop();
+ sprintf(title, _("Linux Kernel v%s Configuration"),
+ getenv("KERNELVERSION"));
+ setCaption(title);
width = configSettings->readNumEntry("/window width", d->width() - 64);
height = configSettings->readNumEntry("/window height", d->height() -
64);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/8] track highest prio queued on runqueue
On 19/10/2007, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> [ ... ]
>
===
> --- linux-test.git.orig/kernel/sched.c 2007-10-19 12:33:09.0 -0400
> +++ linux-test.git/kernel/sched.c 2007-10-19 12:34:32.0 -0400
> @@ -324,6 +324,8 @@ struct rq {
> int push_cpu;
> /* cpu of this runqueue: */
> int cpu;
> + /* highest queued rt task prio */
> + int highest_prio;
again, could it be moved to 'struct rt_rq' ?
(so we want to cache it as we don't want to trash more per-cpu bytes
calling smth like
if (!rt_nr_running) sched_find_first_bit() from other CPUs)
> @@ -972,6 +974,8 @@ static void activate_task(struct rq *rq,
>
> enqueue_task(rq, p, wakeup);
> inc_nr_running(p, rq);
> +
> + rq_prio_add_task(rq, p);
> }
>
> /*
> @@ -984,6 +988,8 @@ static void deactivate_task(struct rq *r
>
> dequeue_task(rq, p, sleep);
> dec_nr_running(p, rq);
> +
> + rq_prio_remove_task(rq, p);
> }
{enqueue,dequeue}_task_rt() would be more appropriate places.
> +static inline void rq_prio_add_task(struct rq *rq, struct task_struct *p)
> +{
> + if (unlikely(rt_task(p)) && p->prio < rq->highest_prio)
> + rq->highest_prio = p->prio;
> +}
> +
> +static inline void rq_prio_remove_task(struct rq *rq, struct task_struct *p)
> +{
> + struct rt_prio_array *array;
> +
> + if (unlikely(rt_task(p))) {
> + if (rq->rt_nr_running) {
> + if (p->prio >= rq->highest_prio) {
> + /* recalculate */
> + array = >rt.active;
> + rq->highest_prio =
> + sched_find_first_bit(array->bitmap);
> + } /* otherwise leave rq->highest prio alone */
> + } else
> + rq->highest_prio = MAX_RT_PRIO;
> + }
> +}
> +#endif /* CONFIG_SMP */
> +
(just a few thoughts)
we call sched_find_first_bit() in pick_next_task_rt() in the case when
rt_nr_running != 0.
So if we can tolerate the 'latency' of updating the 'highest_prio' ==
the interval of time between deactivate_task() and pick_next_task() in
schedule() then rq_prio_remove_task() would just need to do a single
thing:
/* No more RT tasks: */
if (!rt_nr_running)
highest_prio = MAX_RT_PRIO;
and then,
static struct task_struct *pick_next_task_rt(struct rq *rq)
{
struct rt_prio_array *array = >rt.active;
struct task_struct *next;
struct list_head *queue;
int idx;
-idx = sched_find_first_bit(array->bitmap);
+ rq->highest_prio = idx = sched_find_first_bit(array->bitmap);
[ ... ]
additionally, if we can tolerate the 'latency' (of updating
highest_prio) == the worst case scheduling latency, then
rq_prio_add_task() is not necessary at all.
--
Best regards,
Dmitry Adamushko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xconfig: set title bar
On Sat, 20 Oct 2007 20:12:02 +0200 Sam Ravnborg wrote:
> On Sat, Oct 20, 2007 at 07:14:03PM +0200, Sam Ravnborg wrote:
> > On Fri, Oct 19, 2007 at 02:55:28PM -0700, Randy Dunlap wrote:
> > > From: Randy Dunlap <[EMAIL PROTECTED]>
> > >
> > > menuconfig and gconfig already place a title (or caption) on the top
> > > bar of their window (or whatever that is properly called). However,
> > > qconf (xconfig) just says "qconf". I tried to find a Qt API to set
> > > the title but did not find one, so set the program title (caption)
> > > by using the "-title " command line option instead.
> >
> > I found this one to work:
> > diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
> > index e4eeb59..4905cd1 100644
> > --- a/scripts/kconfig/qconf.cc
> > +++ b/scripts/kconfig/qconf.cc
> > @@ -1277,6 +1277,7 @@ ConfigMainWindow::ConfigMainWindow(void)
> >
> > QWidget *d = configApp->desktop();
> >
> > + setCaption("hello my little world");
> > width = configSettings->readNumEntry("/window width", d->width() -
> > 64);
> > height = configSettings->readNumEntry("/window height", d->height()
> > - 64);
> > resize(width, height);
> >
> > We should show the prompt associated with mainmenu here.
>
> After a closer looks it revealed that kconfig does not even save
> the mainmenu prompt?!??!
> See following snippet from zconf.y:
>
> stmt_list:
> /* empty */
> | stmt_list common_stmt
> | stmt_list choice_stmt
> | stmt_list menu_stmt
> | stmt_list T_MAINMENU prompt nl
>
> So it seems no frontend displays the mainmenu prompt.
Yes, I was going to make that same comment.
I'll have qconf.cc using the same title as gconfig and menuconfig
soon...
---
~Randy
[switched email addr due to some odd mail server problem]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xconfig: set title bar
On Sat, Oct 20, 2007 at 07:14:03PM +0200, Sam Ravnborg wrote:
> On Fri, Oct 19, 2007 at 02:55:28PM -0700, Randy Dunlap wrote:
> > From: Randy Dunlap <[EMAIL PROTECTED]>
> >
> > menuconfig and gconfig already place a title (or caption) on the top
> > bar of their window (or whatever that is properly called). However,
> > qconf (xconfig) just says "qconf". I tried to find a Qt API to set
> > the title but did not find one, so set the program title (caption)
> > by using the "-title " command line option instead.
>
> I found this one to work:
> diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
> index e4eeb59..4905cd1 100644
> --- a/scripts/kconfig/qconf.cc
> +++ b/scripts/kconfig/qconf.cc
> @@ -1277,6 +1277,7 @@ ConfigMainWindow::ConfigMainWindow(void)
>
> QWidget *d = configApp->desktop();
>
> + setCaption("hello my little world");
> width = configSettings->readNumEntry("/window width", d->width() -
> 64);
> height = configSettings->readNumEntry("/window height", d->height() -
> 64);
> resize(width, height);
>
> We should show the prompt associated with mainmenu here.
After a closer looks it revealed that kconfig does not even save
the mainmenu prompt?!??!
See following snippet from zconf.y:
stmt_list:
/* empty */
| stmt_list common_stmt
| stmt_list choice_stmt
| stmt_list menu_stmt
| stmt_list T_MAINMENU prompt nl
So it seems no frontend displays the mainmenu prompt.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: merge required-features.h
Signed-off-by: Brian Gerst <[EMAIL PROTECTED]> --- include/asm-x86/required-features.h| 73 ++- include/asm-x86/required-features_32.h | 55 include/asm-x86/required-features_64.h | 46 3 files changed, 70 insertions(+), 104 deletions(-) delete mode 100644 include/asm-x86/required-features_32.h delete mode 100644 include/asm-x86/required-features_64.h diff --git a/include/asm-x86/required-features.h b/include/asm-x86/required-features.h index 8b64f3e..7400d3a 100644 --- a/include/asm-x86/required-features.h +++ b/include/asm-x86/required-features.h @@ -1,5 +1,72 @@ -#ifdef CONFIG_X86_32 -# include "required-features_32.h" +#ifndef _ASM_REQUIRED_FEATURES_H +#define _ASM_REQUIRED_FEATURES_H 1 + +/* Define minimum CPUID feature set for kernel These bits are checked + really early to actually display a visible error message before the + kernel dies. Make sure to assign features to the proper mask! + + Some requirements that are not in CPUID yet are also in the + CONFIG_X86_MINIMUM_CPU_FAMILY which is checked too. + + The real information is in arch/x86/Kconfig.cpu, this just converts + the CONFIGs into a bitmask */ + +#ifndef CONFIG_MATH_EMULATION +# define NEED_FPU (1<<(X86_FEATURE_FPU & 31)) #else -# include "required-features_64.h" +# define NEED_FPU 0 +#endif + +#if defined(CONFIG_X86_PAE) || defined(CONFIG_X86_64) +# define NEED_PAE (1<<(X86_FEATURE_PAE & 31)) +# define NEED_CX8 (1<<(X86_FEATURE_CX8 & 31)) +#else +# define NEED_PAE 0 +# define NEED_CX8 0 +#endif + +#if defined(CONFIG_X86_CMOV) || defined(CONFIG_X86_64) +# define NEED_CMOV (1<<(X86_FEATURE_CMOV & 31)) +#else +# define NEED_CMOV 0 +#endif + +#ifdef CONFIG_X86_USE_3DNOW +# define NEED_3DNOW(1<<(X86_FEATURE_3DNOW & 31)) +#else +# define NEED_3DNOW0 +#endif + +#ifdef CONFIG_X86_64 +#define NEED_PSE (1<<(X86_FEATURE_PSE & 31)) +#define NEED_MSR (1<<(X86_FEATURE_MSR & 31)) +#define NEED_PGE (1<<(X86_FEATURE_PGE & 31)) +#define NEED_FXSR (1<<(X86_FEATURE_FXSR & 31)) +#define NEED_XMM (1<<(X86_FEATURE_XMM & 31)) +#define NEED_XMM2 (1<<(X86_FEATURE_XMM2 & 31)) +#define NEED_LM(1<<(X86_FEATURE_LM & 31)) +#else +#define NEED_PSE 0 +#define NEED_MSR 0 +#define NEED_PGE 0 +#define NEED_FXSR 0 +#define NEED_XMM 0 +#define NEED_XMM2 0 +#define NEED_LM0 +#endif + +#define REQUIRED_MASK0 (NEED_FPU|NEED_PSE|NEED_MSR|NEED_PAE|\ +NEED_CX8|NEED_PGE|NEED_FXSR|NEED_CMOV|\ +NEED_XMM|NEED_XMM2) +#define SSE_MASK (NEED_XMM|NEED_XMM2) + +#define REQUIRED_MASK1 (NEED_LM|NEED_3DNOW) + +#define REQUIRED_MASK2 0 +#define REQUIRED_MASK3 0 +#define REQUIRED_MASK4 0 +#define REQUIRED_MASK5 0 +#define REQUIRED_MASK6 0 +#define REQUIRED_MASK7 0 + #endif diff --git a/include/asm-x86/required-features_32.h b/include/asm-x86/required-features_32.h deleted file mode 100644 index 618feb9..000 --- a/include/asm-x86/required-features_32.h +++ /dev/null @@ -1,55 +0,0 @@ -#ifndef _ASM_REQUIRED_FEATURES_H -#define _ASM_REQUIRED_FEATURES_H 1 - -/* Define minimum CPUID feature set for kernel These bits are checked - really early to actually display a visible error message before the - kernel dies. Make sure to assign features to the proper mask! - - Some requirements that are not in CPUID yet are also in the - CONFIG_X86_MINIMUM_CPU_FAMILY which is checked too. - - The real information is in arch/i386/Kconfig.cpu, this just converts - the CONFIGs into a bitmask */ - -#ifndef CONFIG_MATH_EMULATION -# define NEED_FPU (1<<(X86_FEATURE_FPU & 31)) -#else -# define NEED_FPU 0 -#endif - -#ifdef CONFIG_X86_PAE -# define NEED_PAE (1<<(X86_FEATURE_PAE & 31)) -#else -# define NEED_PAE 0 -#endif - -#ifdef CONFIG_X86_CMOV -# define NEED_CMOV (1<<(X86_FEATURE_CMOV & 31)) -#else -# define NEED_CMOV 0 -#endif - -#ifdef CONFIG_X86_PAE -# define NEED_CX8 (1<<(X86_FEATURE_CX8 & 31)) -#else -# define NEED_CX8 0 -#endif - -#define REQUIRED_MASK0 (NEED_FPU|NEED_PAE|NEED_CMOV|NEED_CX8) - -#ifdef CONFIG_X86_USE_3DNOW -# define NEED_3DNOW(1<<(X86_FEATURE_3DNOW & 31)) -#else -# define NEED_3DNOW0 -#endif - -#define REQUIRED_MASK1 (NEED_3DNOW) - -#define REQUIRED_MASK2 0 -#define REQUIRED_MASK3 0 -#define REQUIRED_MASK4 0 -#define REQUIRED_MASK5 0 -#define REQUIRED_MASK6 0 -#define REQUIRED_MASK7 0 - -#endif diff --git a/include/asm-x86/required-features_64.h b/include/asm-x86/required-features_64.h deleted file mode 100644 index e80d576..000 --- a/include/asm-x86/required-features_64.h +++ /dev/null @@ -1,46 +0,0 @@ -#ifndef _ASM_REQUIRED_FEATURES_H -#define _ASM_REQUIRED_FEATURES_H 1 - -/* Define minimum CPUID feature set for kernel These bits are checked - really early to actually display a visible error message before the - kernel dies.
Re: git/cscope with x86 merge
On Sat, 20 Oct 2007, Sam Ravnborg wrote:
> On Sat, Oct 20, 2007 at 08:56:18AM -0700, Linus Torvalds wrote:
> > so it definitely works for me.
>
> But you do not see the rename arch/x86_64/kernel/{vmlinux.lds.S =>
> vmlinux.lds.S}
> And this is I thing the important step here.
>
> For vmlinux.lds.S we have two renames.
> First the vmlinux.lds.S => vmlinux_64.lds.S
> But this may be a copy instead of a rename thus preventing us
> to see the old history of vmlinux.lds.S?
Yes, it's a copy. vmlinux.lds.S is one of the few source files, which
needed a stub, which includes the 32/64 bit one to avoid a complete
mess in tons of Kbuild/Makefiles.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bug fix for the s390 dcssblk driver
Frans Pop wrote: > emist wrote: >> The following patch fixes and issue in the s390 dcssblk driver. The >> issue is caused when an unsuccessful attempt is made in order to change >> a segment's type through the device attribute file "shared". This causes >> the driver to remove the device in question, removing with it the device >> attribute which is currently handling the call. The result is a hang on >> the driver as it removes memory from under its feet. >> >> Not exactly sure if this explanation makes sense or its entirely >> accurate. This is what I believe at this point from encountering and >> fixing the error. Anyway here is the patch, hope it helps. > > Hi, > > If you don't get any reactions to your patch during the next few days, I > suggest you resend it and then CC the [EMAIL PROTECTED] list and > possibly also the maintainer at [EMAIL PROTECTED] > > In general you should always try to CC the relevant list/people as listed in > the MAINTAINERS file and not just the linux-kernel list, both for patches > and when reporting problems. > > Cheers, > Frans Pop > Thanks Frans, I will do as you suggest. Have a good one, Igor H. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [GIT] NFS client fixes for 2.6.23++
On Fri, 2007-10-19 at 20:41 -0500, Olof Johansson wrote:
> nfs: Fix build break with CONFIG_NFS_V4=n
>
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Acked-by: Trond Myklebust <[EMAIL PROTECTED]>
with apologies.
> ---
>
>
> On Fri, Oct 19, 2007 at 05:23:13PM -0400, Trond Myklebust wrote:
> > Hi Linus,
> >
> > Please pull from the repository at
> >
> >git pull git://git.linux-nfs.org/pub/linux/nfs-2.6.git
> >
> > This will update the following files through the appended changesets.
> >
> [...]
> > @@ -522,8 +522,12 @@ void put_nfs_open_context(struct nfs_open_context *ctx)
> > return;
> > list_del(>list);
> > spin_unlock(>i_lock);
> > - if (ctx->state != NULL)
> > - nfs4_close_state(>path, ctx->state, ctx->mode);
> > + if (ctx->state != NULL) {
> > + if (wait)
> > + nfs4_close_sync(>path, ctx->state, ctx->mode);
> > + else
> > + nfs4_close_state(>path, ctx->state, ctx->mode);
> > + }
> > if (ctx->cred != NULL)
> > put_rpccred(ctx->cred);
> > dput(ctx->path.dentry);
>
> This gives me build errors on most PPC defconfigs, which don't enable NFSv4.
>
> This seems sufficient to fix it.
>
>
> diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h
> index a4e3b96..b35069a 100644
> --- a/fs/nfs/nfs4_fs.h
> +++ b/fs/nfs/nfs4_fs.h
> @@ -236,6 +236,7 @@ extern struct svc_version nfs4_callback_version1;
> #else
>
> #define nfs4_close_state(a, b, c) do { } while (0)
> +#define nfs4_close_sync(a, b, c) do { } while (0)
>
> #endif /* CONFIG_NFS_V4 */
> #endif /* __LINUX_FS_NFS_NFS4_FS.H */
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> NFS maillist - [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/nfs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [GIT] NFS client fixes for 2.6.23++
On Fri, 2007-10-19 at 19:32 -0700, Linus Torvalds wrote: > > On Fri, 19 Oct 2007, Erez Zadok wrote: > > > > Trond, with Linus's latest tree, you need to #include in > > fs/nfs/unlink.c, else I get: > > > > CC [M] fs/nfs/unlink.o > > fs/nfs/unlink.c: In function 'nfs_dec_sillycount': > > fs/nfs/unlink.c:67: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in > > this function) > ... > > Hmm? Which architecture? > > That said, I do think that there is a distinct lack of proper includes in > that file. It seems to depend on getting much of the includes indirectly > from and friends. And with different architectures having > different header files.. > > Linus This ought to fix it. From: Trond Myklebust <[EMAIL PROTECTED]> Date: Sat, 20 Oct 2007 13:21:04 -0400 NFS: Fix the include files needed by fs/nfs/unlink.c Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]> --- fs/nfs/unlink.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c index 6ecd46c..057e6ce 100644 --- a/fs/nfs/unlink.c +++ b/fs/nfs/unlink.c @@ -5,9 +5,14 @@ * */ +#include +#include #include #include -#include +#include +#include +#include +#include #include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xconfig: set title bar
On Fri, Oct 19, 2007 at 02:55:28PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> menuconfig and gconfig already place a title (or caption) on the top
> bar of their window (or whatever that is properly called). However,
> qconf (xconfig) just says "qconf". I tried to find a Qt API to set
> the title but did not find one, so set the program title (caption)
> by using the "-title " command line option instead.
I found this one to work:
diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index e4eeb59..4905cd1 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -1277,6 +1277,7 @@ ConfigMainWindow::ConfigMainWindow(void)
QWidget *d = configApp->desktop();
+ setCaption("hello my little world");
width = configSettings->readNumEntry("/window width", d->width() - 64);
height = configSettings->readNumEntry("/window height", d->height() -
64);
resize(width, height);
We should show the prompt associated with mainmenu here.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: nfsv2 ref leak in 2.6.24?
On Fri, 2007-10-19 at 22:33 -0400, Erez Zadok wrote:
> Trond, good news. I was able to narrow down the problem to purely the
> client-side, probably dcache/readdir related, and I have a shell script that
> deterministically triggers the problem each time for me (this is a FC6 image
> under Vmware 6.0.1). Here's a short shell script which reliably triggers
> the "lost files" problem -- I create a file via nfs2 on the client side, and
> sometimes it doesn't show up in readdir, but it is there if you stat it
> directly.
Ah... I got confused as to what you were measuring and where. Looking at
nfs_proc_create(), there is indeed a missing call to
nfs_mark_for_revalidate(). The reason why you need such a call being the
usual one: NFSv2 doesn't provide post-op attributes for the directory.
The patch below ought to fix the problem.
Cheers
Trond
-- CUT HERE ---
From: Trond Myklebust <[EMAIL PROTECTED]>
Date: Sat, 20 Oct 2007 13:07:21 -0400
NFSv2: Ensure that the directory metadata gets revalidated on file create
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---
fs/nfs/proc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/nfs/proc.c b/fs/nfs/proc.c
index 97669ed..4f80d88 100644
--- a/fs/nfs/proc.c
+++ b/fs/nfs/proc.c
@@ -211,6 +211,7 @@ nfs_proc_create(struct inode *dir, struct dentry *dentry,
struct iattr *sattr,
nfs_fattr_init();
dprintk("NFS call create %s\n", dentry->d_name.name);
status = rpc_call_sync(NFS_CLIENT(dir), , 0);
+ nfs_mark_for_revalidate(dir);
if (status == 0)
status = nfs_instantiate(dentry, , );
dprintk("NFS reply create: %d\n", status);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git Kconfig regression
Jan - I assume you will look into this. And thanks to David/Randy for narrowing this down. Thanks, Sam On Fri, Oct 19, 2007 at 09:25:55PM -0700, Linus Torvalds wrote: > > > On Fri, 19 Oct 2007, David Brownell wrote: > > > > My (quick, meaning that I may have missed something) testing > > > indicates that the problem is in the patches attached. > > > > Yes, reverting this seems to resolve the problem: > > > > > a5bf3d891a6a0fb5aa122792d965e3774108b923 > > > > > > Change kconfig behavior so that mixing bool and tristate config settings > > > in > > > a choice is possible and has the desired effect of offering just the > > > tristate options individually if the choice gets set to M, and a normal > > > boolean selection if the choice gets set to Y. > > > > Reverting this patch also fixes a second problem that I didn't > > mention: various dependent options couldn't be enabled. > > > > Again in drivers/usb/gadget/Kconfig, examples include the > > ability to configure the Ethernet gadget to act as an RNDIS > > peripheral; or enabling Mass Storage gadget debug options. > > > > > > Good sleuthing, and thanks! > > > > Now we just need to see that patch reverted before RC1... I don't > > know how Linus deals with all his LKML mail, so I cc'd him in > > the hope that direct messages get through a bit faster. > > Ok, I'll revert it, but wanted to make sure that the parties that pushed > the change are aware of this. > > Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git/cscope with x86 merge
On Sat, Oct 20, 2007 at 08:56:18AM -0700, Linus Torvalds wrote:
>
>
> On Sat, 20 Oct 2007, Yinghai Lu wrote:
> >
> > git log -p --follow arch/x86/kernel/vmlinux_64.lds.S
> >
> > can not trace to arch/x86_64/kernel/vmlinux.lds.S
>
> Hmm. I get:
>
> [EMAIL PROTECTED] linux]$ git log --stat --follow
> arch/x86/kernel/vmlinux_64.lds.S
> commit 250c22777fe1ccd7ac588579a6c16db4c0161cc5
> Author: Thomas Gleixner <[EMAIL PROTECTED]>
> Date: Thu Oct 11 11:17:24 2007 +0200
>
> x86_64: move kernel
>
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
>
>arch/{x86_64 => x86}/kernel/vmlinux_64.lds.S |0
>1 files changed, 0 insertions(+), 0 deletions(-)
>
> commit 13a9cd42466e12113859c4d7b41561e8bbcaf09d
> Author: Thomas Gleixner <[EMAIL PROTECTED]>
> Date: Thu Oct 11 11:14:21 2007 +0200
>
> x86_64: prepare shared kernel/vmlinux.lds.S
>
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
>
>arch/x86_64/kernel/vmlinux_64.lds.S | 235
> +++
>1 files changed, 235 insertions(+), 0 deletions(-)
>
>
> so it definitely works for me.
But you do not see the rename arch/x86_64/kernel/{vmlinux.lds.S =>
vmlinux.lds.S}
And this is I thing the important step here.
For vmlinux.lds.S we have two renames.
First the vmlinux.lds.S => vmlinux_64.lds.S
But this may be a copy instead of a rename thus preventing us
to see the old history of vmlinux.lds.S?
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/7] Immediate Values - i386 Optimization
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote: > H. Peter Anvin wrote: > > Allowing different registers should be doable, but if so, one would have > > to put 0: at the *end* of the instruction and use (0f)-4 instead, since > > the non-%eax forms are one byte longer. > > > > OK, that's already a problem since its using "=r" as the constraint. > Hi Jeremy, I have tried generating asm-to-"register" c variables for char, short and int on i386 and I do not see this happening. The char opcode is always 1 byte, short 2 bytes and int 1 byte. Result: gcc version 4.1.3 20070812 (prerelease) (Debian 4.1.2-15) 8: b3 02 mov$0x2,%bl a: b1 03 mov$0x3,%cl c: b2 04 mov$0x4,%dl e: b0 05 mov$0x5,%al 4f: 66 be 06 00 mov$0x6,%si 53: 66 bb 07 00 mov$0x7,%bx 57: 66 b9 08 00 mov$0x8,%cx 5b: 66 ba 09 00 mov$0x9,%dx 5f: 66 b8 0a 00 mov$0xa,%ax 9f: bb 0b 00 00 00 mov$0xb,%ebx a4: be 0c 00 00 00 mov$0xc,%esi a9: b9 0d 00 00 00 mov$0xd,%ecx ae: ba 0e 00 00 00 mov$0xe,%edx b3: b8 0f 00 00 00 mov$0xf,%eax I notice that having a "=r" inline assembly that outputs to the first "register char" variable seems to be problematic. It fails with the following error: /tmp/ccy35Hq1.s: Assembler messages: /tmp/ccy35Hq1.s:15: Error: bad register name `%sil' But it seems to be specific to "register" variables, which I do not use in my immediate values. > > This also seems "safer", since an imm32 is always the last thing in the > > instruction. > > Good idea. If gas/gcc generates entirely the wrong addressing mode, > then we've got bigger problems. > I am still trying to figure out if we must assume that gas will produce different length opcodes for mov instructions. The choice is: - Either I use a "r" constraint and let gcc produce the instructions, that I need to assume to have correct size so I can align their immediate values (therefore, taking the offset from the end of the instruction will not help). Here, if gas changes its behavior dramatically for a given immediate value size, it will break. - Second choice is to stick to a particular register, choosing the one with the less side-effect, and encoding the instruction ourselves. I start to think that this second solution might be safer, even though we wouldn't let the compiler select the register which has the less impact by itself. Any comments about this ? -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/8] Add rt_nr_running accounting
On 19/10/2007, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> [ ... ]
> Index: linux-test.git/kernel/sched.c
> ===
> --- linux-test.git.orig/kernel/sched.c 2007-10-19 12:32:39.0 -0400
> +++ linux-test.git/kernel/sched.c 2007-10-19 12:33:09.0 -0400
> @@ -300,6 +300,8 @@ struct rq {
> */
> unsigned long nr_uninterruptible;
>
> + unsigned long rt_nr_running;
could it be a part of the 'struct rt_rq' instead?
>
> +static inline void inc_rt_tasks(struct task_struct *p, struct rq *rq)
> +{
> + if (rt_task(p))
> + rq->rt_nr_running++;
> +}
> +
> +static inline void dec_rt_tasks(struct task_struct *p, struct rq *rq)
> +{
> + if (rt_task(p)) {
> + WARN_ON(!rq->rt_nr_running);
> + rq->rt_nr_running--;
> + }
> +}
> +
> static void enqueue_task_rt(struct rq *rq, struct task_struct *p, int wakeup)
> {
> struct rt_prio_array *array = >rt.active;
>
> list_add_tail(>run_list, array->queue + p->prio);
> __set_bit(p->prio, array->bitmap);
> +
> + inc_rt_tasks(p, rq);
why do you need the rt_task(p) check in {inc,dec}_rt_tasks() ?
{enqueue,dequeue}_task_rt() seem to be the only callers and they will
crash (or corrupt memory) anyway in the case of ! rt_task(p) (sure,
this case would mean something is broken somewhere wrt sched_class
handling).
--
Best regards,
Dmitry Adamushko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compat_ioctl: introduce generic_compat_ioctl helper
On Saturday 20 October 2007, Christoph Hellwig wrote: > At least for the unlocked_ioctl case this is not nessecary because > the driver an simply set both the unlocked_ioctl and compat_ioctl > handlers to the same function. For the drivers not using unlocked_ioctl > yet a function like this makes sense in theory, but I'd prefer to > just switch them to ->unlocked_ioctl. > There is still the problem with s390 compat_ptr() conversion, a driver using the same handler for both may interpret a pointer with the high bit set as out of range. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compat_ioctl: introduce generic_compat_ioctl helper
On Sat, Oct 20, 2007 at 05:50:57PM +0200, Arnd Bergmann wrote: > Many drivers use only compatible ioctl numbers. In order to > avoid having to write a special compat_ioctl handler for each > of them or listing every ioctl number in fs/compat_ioctl.c, > let's introduce a generic handler that simply calls the > driver specific f_op->unlocked_ioctl() or f_op->ioctl() handler. At least for the unlocked_ioctl case this is not nessecary because the driver an simply set both the unlocked_ioctl and compat_ioctl handlers to the same function. For the drivers not using unlocked_ioctl yet a function like this makes sense in theory, but I'd prefer to just switch them to ->unlocked_ioctl. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hiddev: simplify 32bit ioctl compatibilty
hiddev has both entries in fs/compat_ioctl.c and its own
compat_ioctl() handler. Remove both and use the new generic_compat_ioctl
helper instead.
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/hid/hidraw.c
===
--- linux-2.6.orig/drivers/hid/hidraw.c
+++ linux-2.6/drivers/hid/hidraw.c
@@ -268,6 +268,7 @@ static const struct file_operations hidr
.open = hidraw_open,
.release = hidraw_release,
.ioctl =hidraw_ioctl,
+ .compat_ioctl = generic_compat_ioctl,
};
void hidraw_report_event(struct hid_device *hid, u8 *data, int len)
Index: linux-2.6/drivers/hid/usbhid/hiddev.c
===
--- linux-2.6.orig/drivers/hid/usbhid/hiddev.c
+++ linux-2.6/drivers/hid/usbhid/hiddev.c
@@ -739,14 +739,6 @@ inval:
return -EINVAL;
}
-#ifdef CONFIG_COMPAT
-static long hiddev_compat_ioctl(struct file *file, unsigned int cmd, unsigned
long arg)
-{
- struct inode *inode = file->f_path.dentry->d_inode;
- return hiddev_ioctl(inode, file, cmd, compat_ptr(arg));
-}
-#endif
-
static const struct file_operations hiddev_fops = {
.owner =THIS_MODULE,
.read = hiddev_read,
@@ -756,9 +748,7 @@ static const struct file_operations hidd
.release = hiddev_release,
.ioctl =hiddev_ioctl,
.fasync = hiddev_fasync,
-#ifdef CONFIG_COMPAT
- .compat_ioctl = hiddev_compat_ioctl,
-#endif
+ .compat_ioctl = generic_compat_ioctl,
};
static struct usb_class_driver hiddev_class = {
Index: linux-2.6/fs/compat_ioctl.c
===
--- linux-2.6.orig/fs/compat_ioctl.c
+++ linux-2.6/fs/compat_ioctl.c
@@ -102,8 +102,6 @@
#include
#include
-#include
-
#include
#include
#include
@@ -2575,23 +2573,6 @@ COMPATIBLE_IOCTL(SIOCSIWPOWER)
COMPATIBLE_IOCTL(SIOCGIWPOWER)
COMPATIBLE_IOCTL(SIOCSIWAUTH)
COMPATIBLE_IOCTL(SIOCGIWAUTH)
-/* hiddev */
-COMPATIBLE_IOCTL(HIDIOCGVERSION)
-COMPATIBLE_IOCTL(HIDIOCAPPLICATION)
-COMPATIBLE_IOCTL(HIDIOCGDEVINFO)
-COMPATIBLE_IOCTL(HIDIOCGSTRING)
-COMPATIBLE_IOCTL(HIDIOCINITREPORT)
-COMPATIBLE_IOCTL(HIDIOCGREPORT)
-COMPATIBLE_IOCTL(HIDIOCSREPORT)
-COMPATIBLE_IOCTL(HIDIOCGREPORTINFO)
-COMPATIBLE_IOCTL(HIDIOCGFIELDINFO)
-COMPATIBLE_IOCTL(HIDIOCGUSAGE)
-COMPATIBLE_IOCTL(HIDIOCSUSAGE)
-COMPATIBLE_IOCTL(HIDIOCGUCODE)
-COMPATIBLE_IOCTL(HIDIOCGFLAG)
-COMPATIBLE_IOCTL(HIDIOCSFLAG)
-COMPATIBLE_IOCTL(HIDIOCGCOLLECTIONINDEX)
-COMPATIBLE_IOCTL(HIDIOCGCOLLECTIONINFO)
/* dvb */
COMPATIBLE_IOCTL(AUDIO_STOP)
COMPATIBLE_IOCTL(AUDIO_PLAY)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Kconfig.instrumentation sourcing missing on i386 and x86_64
The same happened on i386 and x86_64. I guess some bits from the combine-instrumentation-menus-in-kernel-kconfiginstrumentation.patch were lost during the mainline merge. Andrew, could you forward this patch to Linus ? It applies on top of the current 2.6.23 git HEAD. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> --- arch/i386/Kconfig |2 ++ arch/x86_64/Kconfig |2 ++ 2 files changed, 4 insertions(+) Index: linux-2.6-lttng.stable/arch/i386/Kconfig === --- linux-2.6-lttng.stable.orig/arch/i386/Kconfig 2007-10-20 11:59:39.0 -0400 +++ linux-2.6-lttng.stable/arch/i386/Kconfig2007-10-20 11:59:41.0 -0400 @@ -1258,6 +1258,8 @@ source "drivers/Kconfig" source "fs/Kconfig" +source "kernel/Kconfig.instrumentation" + source "arch/i386/Kconfig.debug" source "security/Kconfig" Index: linux-2.6-lttng.stable/arch/x86_64/Kconfig === --- linux-2.6-lttng.stable.orig/arch/x86_64/Kconfig 2007-10-20 12:00:09.0 -0400 +++ linux-2.6-lttng.stable/arch/x86_64/Kconfig 2007-10-20 12:00:18.0 -0400 @@ -801,6 +801,8 @@ source "drivers/firmware/Kconfig" source fs/Kconfig +source "kernel/Kconfig.instrumentation" + source "arch/x86_64/Kconfig.debug" source "security/Kconfig" -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git/cscope with x86 merge
On Sat, 20 Oct 2007, Yinghai Lu wrote:
>
> git log -p --follow arch/x86/kernel/vmlinux_64.lds.S
>
> can not trace to arch/x86_64/kernel/vmlinux.lds.S
Hmm. I get:
[EMAIL PROTECTED] linux]$ git log --stat --follow
arch/x86/kernel/vmlinux_64.lds.S
commit 250c22777fe1ccd7ac588579a6c16db4c0161cc5
Author: Thomas Gleixner <[EMAIL PROTECTED]>
Date: Thu Oct 11 11:17:24 2007 +0200
x86_64: move kernel
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
arch/{x86_64 => x86}/kernel/vmlinux_64.lds.S |0
1 files changed, 0 insertions(+), 0 deletions(-)
commit 13a9cd42466e12113859c4d7b41561e8bbcaf09d
Author: Thomas Gleixner <[EMAIL PROTECTED]>
Date: Thu Oct 11 11:14:21 2007 +0200
x86_64: prepare shared kernel/vmlinux.lds.S
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
arch/x86_64/kernel/vmlinux_64.lds.S | 235
+++
1 files changed, 235 insertions(+), 0 deletions(-)
so it definitely works for me.
But it might be the same old rename limit issue. Try doing
git config --global diff.renamelimit 0
first,
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] compat_ioctl: introduce generic_compat_ioctl helper
Many drivers use only compatible ioctl numbers. In order to
avoid having to write a special compat_ioctl handler for each
of them or listing every ioctl number in fs/compat_ioctl.c,
let's introduce a generic handler that simply calls the
driver specific f_op->unlocked_ioctl() or f_op->ioctl() handler.
Signed-off-by: Arnd Bergman <[EMAIL PROTECTED]>
---
On Saturday 13 October 2007, Al Viro wrote:
> Just how many instances of that sucker do we need? It's nothing but
>
> struct inode *inode = file->f_path.dentry->d_inode;
> return file->f_op->ioctl(inode, file, cmd, compat_ptr(arg));
Is this what you had in mind? I've been meaning to do something like
it for some time, but had forgotten about it.
I guess we can kill a significant amount of COMPATIBLE_IOCTL
lines in fs/compat_ioctl.c with this.
Index: linux-2.6/fs/compat_ioctl.c
===
--- linux-2.6.orig/fs/compat_ioctl.c
+++ linux-2.6/fs/compat_ioctl.c
@@ -1877,6 +1877,30 @@ lp_timeout_trans(unsigned int fd, unsign
return sys_ioctl(fd, cmd, (unsigned long)tn);
}
+/*
+ * Helper function for device drivers that only have COMPATIBLE_IOCTL
+ * numbers. This can be used as f_op->compat_ioctl without any #ifdef
+ * and will simply call the native ioctl handler with the argument
+ * pointer.
+ * Don't use for drivers that interpret arg as an unsigned long instead
+ * of a pointer.
+ */
+long generic_compat_ioctl(struct file *file, unsigned int cmd, unsigned long
arg)
+{
+ int ret = -ENOTTY;
+ arg = (unsigned long)compat_ptr(arg);
+
+ if (file->f_op->unlocked_ioctl)
+ ret = file->f_op->unlocked_ioctl(file, cmd, arg);
+ else if (file->f_op->ioctl) {
+ lock_kernel();
+ ret = file->f_op->ioctl(file->f_dentry->d_inode, file, cmd,
arg);
+ unlock_kernel();
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(generic_compat_ioctl);
typedef int (*ioctl_trans_handler_t)(unsigned int, unsigned int,
unsigned long, struct file *);
Index: linux-2.6/include/linux/fs.h
===
--- linux-2.6.orig/include/linux/fs.h
+++ linux-2.6/include/linux/fs.h
@@ -1807,6 +1807,12 @@ extern void do_generic_mapping_read(stru
extern int generic_segment_checks(const struct iovec *iov,
unsigned long *nr_segs, size_t *count, int access_flags);
+#ifdef CONFIG_COMPAT
+extern long generic_compat_ioctl(struct file *file, unsigned int cmd, unsigned
long arg);
+#else
+#define generic_compat_ioctl (long (*)(struct file *, unsigned int, unsigned
long))NULL
+#endif
+
/* fs/splice.c */
extern ssize_t generic_file_splice_read(struct file *, loff_t *,
struct pipe_inode_info *, size_t, unsigned int);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.23.1 host freezes when running kvm
* Bart Trojanowski <[EMAIL PROTECTED]> [071019 20:03]: > * Bart Trojanowski <[EMAIL PROTECTED]> [071019 17:00]: > > > > > Once the system is booted, I attached using vnc, then I ssh in and ran > > 'svn update'... and the host machine froze. > > > > The last messages I on my serial console are: > > > > kvm: unhandled rdmsr: 0x417 > > kvm: unhandled rdmsr: 0xc400 > > > I noticed that linus merged a bunch of KVM changes last week. I will > > try those out next. > > It looks like Linus' tree has the fix already. I spoke too soon. The latest from Linus' tree also freezes... but it took overnight to get there. There was no particular load on it. This system was previously running 2.6.22.y w/o problems with a similar kvm pattern. This time it froze w/o showing any kvm rdmsr messages. And while it froze sometime over night, I cannot be sure when. Here is the SysRq's "showPc" output: SysRq : Show Regs CPU 2: Modules linked in: kvm_amd kvm rtc_cmos rtc_core rtc_lib cpufreq_userspace cpufreq_powersave cpufreq_conservative ipv6 bridge ext2 mbcache loop pcspkr button dm_mirror dm_snapshot dm_mod ide_generic ide_cd pata_acpi ata_generic serverworks generic ide_core Pid: 0, comm: swapper Not tainted 2.6.23-git-kvm-gc4ec2071 #1 RIP: 0010:[] [] default_idle+0x29/0x3d RSP: 0018:810140a55f30 EFLAGS: 0246 RAX: RBX: 8066a040 RCX: RDX: RSI: 0001 RDI: 805c3350 RBP: 8066fa00 R08: 810140040560 R09: 8101006e7e70 R10: 810143e0a900 R11: 8066fa00 R12: 8024bc8e R13: 810140a55ec8 R14: 0d6ed51a R15: 8066fa00 FS: 2aaea92f0bf0() GS:810140a1d300() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2add9e236140 CR3: 000143def000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Call Trace: [] cpu_idle+0x93/0xbb Are there things I should be looking for? -Bart -- WebSig: http://www.jukie.net/~bart/sig/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-mm1 - autofs broken
On Sat, 20 Oct 2007 01:54:45 -0400 Rik van Riel <[EMAIL PROTECTED]> wrote: > On Sat, 20 Oct 2007 01:54:04 -0400 > Rik van Riel <[EMAIL PROTECTED]> wrote: > > > On Fri, 19 Oct 2007 22:39:00 -0700 > > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel <[EMAIL PROTECTED]> > > > wrote: > > > > > > > On Thu, 11 Oct 2007 21:31:26 -0700 > > > > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > > > > > > > > > - I've been largely avoiding applying anything since rc8-mm2 > > > > > in an attempt to stabilise things for the 2.6.23 merge. > > > > > > > > Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the > > > > -mm kernel. > > > > > > > > Instead of mounting my home directory, I get these messages in > > > > /var/log/messages: > > > > > > > > Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent > > > > cache rwlock lock failed > > > > Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads > > > > error: 11 at 65 in cache.c > > > > > > > > I am not sure if this is due to autofs changes or changes in > > > > some other code that was merged. If you can think of any > > > > suspicious change that I should test, please let me know. > > > > > > I don't think anything changed in autofs in that period. I'd be > > > suspecting the r-o-bind-mounts patches, but they didn't change > > > much in that time either. > > > > > > Does current mainline work OK? If so, pretty much the only thing > > > in that area left unmerged is r-o-bind-mounts and hch's exportfs > > > stuff. > > > > Yes, 2.6.23 mainline works fine. > > Let me clarify: 2.6.23 vanilla works. > > I have not yet tried the latest 2.6.23+ git tree. I just tried it. In the latest git tree, autofs still works. The regression is in -mm only. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] PCI: disable MSI on more ATI NorthBridges
Quoting "David G" > "Here" as in "here at AMD"?! I'm stunned... > Both AMD and the former ATI should have quite some experience?! When I used "here", I was just meaning our youthful linux southbridge drivers team instead of the whole AMD. Sorry for the confusion to you. Quoting "Linas" > As someone else pointed out, AMD should have *lots* of people with > pci and msi experience on the payroll. (Folks here buy AMD-designed > pci chips ...) Yes, absolutely AMD has lots of people with PCI and MSI experience, but this MSI issue is mainly under the debug of our team now. I think our team will cooperate with other teams more closely to provide linux chipset support besides fixing the MSI problem in the future. Quoting "Jeff" > Take a look at tg3.c net driver change > 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar > situation. However, it may turn out that removing the pci_intx() > stuff as a general rule is easier than quirking these devices, if enough > of them turn out to have this hardware bug. The tg3.c change should > illustrate how to fix immediately, though. Thanks for your suggestion. I will continue to debug this problem next Monday when I'm back to the office. Thanks Best Regards Shane _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create_url=/friends.aspx=en-us - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]
On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ Hey there!! fails to boot here with this friendly oops: http://oioio.altervista.org/linux/dsc01702.jpg .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1 2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet (no s2ram with mysql running and some net WARNING). Let's see if .23-mm1 still has those first. I'm adding Cc: linux-scsi PS: I'll hardly be able to bisect in the next days... :P -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with reiserfs in 2.6.23-mm1
Hello. Whenever I log into xfce with gdm my computer will freeze when i use reiserfs as my /home on 2.6.23-mm1. Logging into the VT works perfectly fine. Previously my system would crash when logging into the VT but the make-reiserfs-stop-using-struct-file-for-internal.patch patch fixed the issue(and possibly introduced the issue I currently have). My system works perfectly fine using 2.6.23-rc6-mm1 and prior. /home is mounted with the following options: /dev/sda3 on /home type reiserfs (rw,nosuid,nodev,noatime,acl) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: 2.6.23-rc9 okay, 2.6.23.1 resume problems
Pavel Machek wrote: Hi! Since upgrading to 2.6.23.1 from 2.6.23-rc9, resume-from-RAM has been misbehaving here. It takes much (+5-7 seconds) longer to resume *sometimes*, but not all/most of the time. I suspend those long delays may have something to do with USB, as it takes longer for my hub + mouse to come back to life during the sequence. But I have since then re-applied the powertop patches, and the long delays vanished. Back with -rc9 I normally also had those powertop fixes, and so this problem could be much older and was never noticed until I ran without them. I'm no longer actively investigating, as the delays are gone (powertop patches), and the crashes are much less frequent since patching. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth: hidp core debug code wrong argument fix
Hi Dave, > In the debug code of the hidp_queue_report function, the "device" variable > does not exist, replace it with "session->hid" applied to my tree. Thanks. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bluez-devel] [PATCH] bluetooth: Eliminate checks for impossible conditions in irq handler
Hi Jeff, > [BLUETOOTH] Eliminate checks for impossible conditions in irq handler > > Our info structure and info->hdev is always passed to the irq handler, > so we don't have to worry about these checks in every interrupt. > > Leave a BUG_ON() just to help unwary programmers, but these could > probably be removed as well. applied to my tree. Thanks. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG at mm/filemap.c:1749 (2.6.24, jffs2, unionfs)
On Fri, 2007-10-19 at 13:38 -0400, Erez Zadok wrote: > Nick, the patch worked. All of my unionfs-over-jffs2 tests passed. Can I have a Signed-off-by: for it please? -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA VT6307 OHCI version?
Krzysztof Halasa wrote: > (the datasheet seems to suggest that) Well, as mentioned, I don't put much trust into the datasheet. It is incomplete regarding the 1.0/1.1 issue. > I wonder if OHCI 1.0 hardware based on VT6307 (and 6306) is > a common thing, or is it just an exception. Both chips are quite widespread. From what I remember to have seen, most VT6307 are programmed in OHCI 1.1 mode while all VT6306 seem to be OHCI 1.0. -- Stefan Richter -=-=-=== =-=- =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
