[PATCH] [2/2many] - FInd the maintainer(s) for a patch - MAINTAINERS
Describe the new F: pattern Signed-off-by: Joe Perches <[EMAIL PROTECTED]> diff --git a/MAINTAINERS b/MAINTAINERS index 0d7f856..d3a0684 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -83,13 +83,6 @@ S: Status, one of the following: it has been replaced by a better system and you should be using that. -F: Files and directories with wildcard patterns. - A trailing slash includes all files and subdirectory files. - F: drivers/net/all files in and below drivers/net - F: drivers/net/* all files in drivers/net, but not below - F: */net/* all files in "any top level directory"/net - One pattern per line. Multiple F: lines acceptable. - 3C359 NETWORK DRIVER P: Mike Phillips M: [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: [PATCH 0/5] Add some missing Documentation/*/00-INDEX files
On Sunday 12 August 2007 4:47:17 pm Stefan Richter wrote: > Rob Landley wrote: > > On Sunday 12 August 2007 3:17:38 pm Stefan Richter wrote: > >> - it's a little bit faster to create these headers than to add them > >> to 00-INDEX: Just move the existing title to the top. > > ... > > > What variant of "fast" do you mean? Processing the entire directory > > takes a fraction of a second on my laptop. > > I meant the speed of people, not the speed of text processors. Gotcha. Populating 00-INDEX from the first nonblank line of each file, skipping lines that are entirely punctuation, is a good suggestion. A human has to go clean up the result, but I could do this thing... :) Thanks for the suggestion. Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl
I grew weary of looking up the appropriate
maintainer email address(es) to CC: for a patch.
I added flags to the MAINTAINERS file
F: file pattern
for each maintained block and a script to parse
the modified blocks for maintainer and list
email addresses.
perl scripts/get_maintainer.pl
gives the appropriate maintainer(s).
Modifications since last post:
Added options to control email address style and multiple address separator
Please apply.
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
new file mode 100755
index 000..3e5cc6c
--- /dev/null
+++ b/scripts/get_maintainer.pl
@@ -0,0 +1,217 @@
+#!/usr/bin/perl -w
+# (c) 2007, Joe Perches <[EMAIL PROTECTED]>
+# created from checkpatch.pl
+# Licensed under the terms of the GNU GPL License version 2
+
+use strict;
+
+my $P = $0;
+$P =~ [EMAIL PROTECTED]/@@g;
+
+my $V = '0.02';
+
+use Getopt::Long qw(:config no_auto_abbrev);
+
+my $tree = "./";
+my $email_maintainer = 1;
+my $email_maintainer_name = 1;
+my $email_list = 1;
+my $email_subscriber_list = 0;
+my $email_separator = ", ";
+my %saw;
+
+GetOptions(
+ 'tree=s' => \$tree,
+ 'm!' => \$email_maintainer,
+ 'n!' => \$email_maintainer_name,
+ 'l!' => \$email_list,
+ 's!' => \$email_subscriber_list,
+ 'separator=s' => \$email_separator,
+ ) or exit;
+
+my $exit = 0;
+
+if ($#ARGV < 0 ||
+($email_maintainer == 0 && $email_list == 0 && $email_subscriber_list ==
0)) {
+print "usage: $P [options] patchfile\n";
+print "version: $V\n";
+print " --tree [path] => linux kernel source path\n";
+print " --m => include maintainer(s) if any\n";
+print " --n => include maintainer name 'Full Name <[EMAIL PROTECTED]>'\n";
+print " --l => include list(s) if any\n";
+print " --s => include subscriber only list(s) if any\n";
+print " --separator [, ] => separator for multiple addresses\n";
+print "Default: [--m --l --separator \", \"]\n";
+print "Be sure to select something...\n";
+exit(1);
+}
+
+if ($tree && !top_of_kernel_tree($tree)) {
+if (${tree} ne "") {
+ print "'${tree}' ";
+} else {
+ print "The current directory ";
+}
+print "doesn't appear to be a linux kernel source tree\n";
+exit(2);
+}
+
+## Read MAINTAINERS for type/value pairs
+
+my @typevalue = ();
+open(MAINT, "<${tree}MAINTAINERS") || die "$P: Can't open
${tree}MAINTAINERS\n";
+while () {
+if (m/^(\C):\s*(.*)/) {
+ my $type = $1;
+ my $value = $2;
+ if ($type eq "F") { ##Filename pattern matching
+ $value =~ [EMAIL PROTECTED]@[EMAIL PROTECTED]; ##Convert . to
\.
+ $value =~ s/\*/\.\*/g; ##Convert * to .*
+ }
+ push(@typevalue, "$type:$value");
+} elsif (!/^(\s)*$/) {
+ push(@typevalue, $_);
+}
+}
+close(MAINT);
+
+## Find the patched filenames
+
+my @patchedfiles = ();
+open(PATCH, "<$ARGV[0]") or die "Can't open $ARGV[0]\n";
+while () {
+if (m/^\+\+\+\s+(\S+)/) {
+ my $file = $1;
+ $file =~ [EMAIL PROTECTED]/]*/@@;
+ $file =~ [EMAIL PROTECTED]@@;
+ push(@patchedfiles, $file);
+}
+}
+close(PATCH);
+
+# Sort and uniq patchedfiles
+
+undef %saw;
[EMAIL PROTECTED] = sort @patchedfiles;
[EMAIL PROTECTED] = grep(!$saw{$_}++, @patchedfiles);
+
+# Find responsible parties
+
+my @email_to = ();
+foreach (@patchedfiles) {
+my $patchedfile = $_;
+my $tvi = 0;
+
+foreach (@typevalue) {
+ if (m/^(\C):(.*)/) {
+ my $type = $1;
+ my $value = $2;
+ if ($type eq 'F') {
+ if (file_match_pattern($patchedfile, $value)) {
+ my $ptvi = $tvi - 1;
+ while ($ptvi >= 0) {
+ my $tv = $typevalue[$ptvi];
+ if ($tv =~ m/^(\C):(.*)/) {
+ my $ptype = $1;
+ my $pvalue = $2;
+ if ($ptype eq "L") {
+ my $subscr = $pvalue;
+ if ($subscr =~ m/\s*\(subscribers-only\)/) {
+ if ($email_subscriber_list > 0) {
+ $subscr =~ s/\s*\(subscribers-only\)//g;
+ push(@email_to, $subscr);
+ }
+ } else {
+ if ($email_list > 0) {
+ push(@email_to, $pvalue);
+ }
+ }
+ } elsif ($ptype eq "M") {
+ if ($email_maintainer > 0) {
+ if ($ptvi >= 0) {
+ my $tv = $typevalue[$ptvi - 1];
+ if ($tv =~ m/^(\C):(.*)/) {
+ if
Re: [RFC] FUSE: mnotify (was: [RFC] VFS: mnotify)
On Sun, 2007-08-12 at 13:24 +0200, Jan Engelhardt wrote: > On Aug 12 2007 06:32, Al Boldi wrote: > >Al Boldi wrote: > >> Jakob Oestergaard wrote: > >> > Why on earth would you cripple the kernel defaults for ext3 (which is a > >> > fine FS for boot/root filesystems), when the *fundamental* problem you > >> > really want to solve lie much deeper in the implementation of the > >> > filesystem? Noatime doesn't solve the problem, it just makes it "less > >> > horrible". > >> > >> inotify could easily solve the atime problem, but it's got the drawback of > >> forcing the user to register each and every file/dir of interest, which > >> isn't really reasonable on TB-filesystems. > > What inotify needs is some kind of SUBDIR flag on a watch so that one does not > run out of fds, then the TB issue becomes a bit lighter I think. > There's no risk of running out of fds; inotify only requires one. You still have to register every directory you're interested in, though, but that's a limitation caused by the Unix VFS philosophy and the resulting filesystem design it inspired rather than of inotify itself. Come up with a filesystem where given an inode you can find every directory that has links to that inode with very little effort, convince everybody to switch from ext3 to this new filesystem, and then maybe inotify could start doing recursive subtree watches. Otherwise, it's just not feasible. -- Nicholas Miell <[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: Block device throttling [Re: Distributed storage.]
(previous incomplete message sent accidentally) On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote: > On Tue, Aug 07, 2007 at 10:55:38PM +0200, Jens Axboe wrote: > > So, what did we decide? To bloat bio a bit (add a queue pointer) or > to use physical device limits? The latter requires to replace all > occurence of bio->bi_bdev = something_new with blk_set_bdev(bio, > somthing_new), where queue limits will be appropriately charged. So > far I'm testing second case, but I only changed DST for testing, can > change all other users if needed though. Adding a queue pointer to struct bio and using physical device limits as in your posted patch both suffer from the same problem: you release the throttling on the previous queue when the bio moves to a new one, which is a bug because memory consumption on the previous queue then becomes unbounded, or limited only by the number of struct requests that can be allocated. In other words, it reverts to the same situation we have now as soon as the IO stack has more than one queue. (Just a shorter version of my previous post.) We can solve this by having the bio only point at the queue to which it was originally submitted, since throttling the top level queue automatically throttles all queues lower down the stack. Alternatively the bio can point at the block_device or straight at the backing_dev_info, which is the per-device structure it actually needs to touch. Note! There are two more issues I forgot to mention earlier. 1) One throttle count per submitted bio is too crude a measure. A bio can carry as few as one page or as many as 256 pages. If you take only one throttle count per bio and that data will be transferred over the network then you have to assume that (a little more than) 256 pages of sk_alloc reserve will be needed for every bio, resulting in a grossly over-provisioned reserve. The precise reserve calculation we want to do is per-block device, and you will find hooks like this already living in backing_dev_info. We need to place our own fn+data there to calculate the throttle draw for each bio. Unthrottling gets trickier with variable size throttle draw. In ddsnap, we simply write the amount we drew from the throttle into (the private data of) bio for use later by unthrottle, thus avoiding the issue that the bio fields we used to calculate might have changed during the lifetime of the bio. This would translate into one more per-bio field. 2) Exposing the per-block device throttle limits via sysfs or similar is really not a good long term solution for system administration. Imagine our help text: "just keep trying smaller numbers until your system deadlocks". We really need to figure this out internally and get it correct. I can see putting in a temporary userspace interface just for experimentation, to help determine what really is safe, and what size the numbers should be to approach optimal throughput in a fully loaded memory state. Regards, Daniel Regards, Daniel - 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-rc2-mm2 (libertas)
On Thu, 9 Aug 2007 22:42:54 -0700 Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc2/2.6.23-rc2-mm2/ > > - Various problems from 2.6.23-rc2-mm1 were fixed libertas wireless warnings on x86_64: drivers/net/wireless/libertas/if_cs.c:462: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' drivers/net/wireless/libertas/if_cs.c:538: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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: Block device throttling [Re: Distributed storage.]
On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote: > On Tue, Aug 07, 2007 at 10:55:38PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote: > > So, what did we decide? To bloat bio a bit (add a queue pointer) or > to use physical device limits? The latter requires to replace all > occurence of bio->bi_bdev = something_new with blk_set_bdev(bio, > somthing_new), where queue limits will be appropriately charged. So > far I'm testing second case, but I only changed DST for testing, can > change all other users if needed though. Adding a queue pointer to struct bio and using physical device limits as in your posted patch both suffer from the same problem: you release the throttling on the previous queue when the bio moves to a new one, which is a bug because memory consumption on the previous queue then becomes unbounded, or limited only by the number of struct requests that can be allocated. In other words, it reverts to the same situation we have now as soon as the IO stack has more than one queue. (Just a shorter version of my previous post.) We can solve this by having the bio only point at the queue to which it was originally submitted, since throttling the top level queue automatically throttles all queues lower down the stack. Alternatively the bio can point at the block_device or straight at the backing_dev_info, which is the per-device structure it actually needs to touch. Note! There are two more issues I forgot to mention earlier. 1) One throttle count per submitted bio is too crude a measure. A bio can carry as few as one page or as many as 256 pages. If you take only one throttle count per bio and that data will be transferred over the network then you have to assume that (a little more than) 256 pages of sk_alloc reserve will be needed for every bio, resulting in a grossly over-provisioned reserve. The precise reserve calculation we want to do is per-block device, and you will find hooks like this already living in backing_dev_info. We need to place our own fn+data there to calculate the throttle draw for each bio. Unthrottling gets trickier with variable size throttle draw. In ddsnap, we simply write the amount we drew from the throttle into (the private data of) bio for use later by unthrottle, thus avoiding the issue that the bio fields we used to calculate might have changed during the lifetime of the bio. This would translate into one more per-bio field. the throttling performs another function: keeping a reasonable amount of IO in flight for the device. The definition of "reasonable" is complex. For a hard disk it depends on the physical distance between sector addresses of the bios in flight. In ddsnap we make a crude but workable approximation that In general, a per block device The throttle count needs to cover Regards, Daniel - 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 6/24] make atomic_read() behave consistently on frv
Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
>> Chris Snook <[EMAIL PROTECTED]> wrote:
>> >
>> > cpu_relax() contains a barrier, so it should do the right thing. For
>> > non-smp architectures, I'm concerned about interacting with interrupt
>> > handlers. Some drivers do use atomic_* operations.
>>
>> What problems with interrupt handlers? Access to int/long must
>> be atomic or we're in big trouble anyway.
>
> Reordering due to compiler optimizations. CPU reordering does not
> affect interactions with interrupt handlers on a given CPU, but
> reordering due to compiler code-movement optimization does. Since
> volatile can in some cases suppress code-movement optimizations,
> it can affect interactions with interrupt handlers.
If such reordering matters, then you should use one of the
*mb macros or barrier() rather than relying on possibly
hidden volatile cast.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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/
How to make -mm a more viable testbed (was: [PATCH] [1/12] x86: Work around mmio config space quirk on AMD)
Linus Torvalds wrote: > On Sun, 12 Aug 2007, Dave Jones wrote: > > > > This does make me wonder, why these weren't caught in -mm ? > > I'm worried that -mm isn't getting a lot of exposure these days. People do > run it, but I wonder how many.. Well, I'm not running it because it's got too much garbage in it, which makes it a pretty unrealistic testbed. And to make matters worse, I also stay away from rc's as a consequence. To make -mm more viable, it may be advisable to restructure -mm in such a way as to be a Kconfig option to mainline. This would probably involve some patch management functionality to apply experimental submissions on a per-patch basis, as opposed to being a 'take it or leave it slam onto mainline' patch. 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/
PROBLEM: Dell Inspiron 1501 fails to boot in 2.6.21+
Nope. I tried nolapic_timer and pressing keys when the system stops. Neither works for me. Mark - 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: encrypted hibernation (was Re: Hibernation considerations)
Hello, We already have a sample at: http://wiki.tuxonice.net/EncryptedSwapAndRoot It stores the keys of mounted partitions on an encrypted swap, which has the same encryption with different keyset. It also shows how to resume from encrypted swap, And you can optionally store the keys on hardware device such as smartcards. Best Regards, Alon Bar-Lev On 8/13/07, Michael Chang <[EMAIL PROTECTED]> wrote: > On 8/11/07, Dr. David Alan Gilbert <[EMAIL PROTECTED]> wrote: > > * Pavel Machek ([EMAIL PROTECTED]) wrote: > > > Hi! > > > > > > > > > Two things which I think would be nice to consider are: > > > > > >1) Encryption - I'd actually prefer if my luks device did not > > > > > >remember the key accross a hibernation; I want to be forced > to > > > > > >reenter the phrase. However I don't know what the best > thing > > > > > >to do to partitions/applications using the luks device is. > > > > > > > > > > Encryption is possible with both the userland hibernation (aka > uswsusp) and > > > > > TuxOnIce (formerly known as suspend2). Still, I don't consider it > as a "must > > > > > have" feature for a framework to be generally useful (many users > don't use it > > > > > anyway). > > > > > > > > If a user uses an encrypted filesystem, then he also needs an > encrypted > > > > swap and encrypted hibernation image: Otherwise the fileystem > encryption > > > > is not very useful. > > > > > > Actually, we can do most of that stuff already. > > > > > > We can encrypt filesystems, encrypt swaps (LVM), and encrypt > hibernation. > > > > But can you do what my original question was; find a way to lose a luks > > encrypted device key and cleanly unmount the filesystem that was > > using it? (and preferably put it all back together after resume). > > > > If you lose the device key, how are you going to get luks to find it > again when resuming? Wouldn't it make more sense to have it remember > the key? I can't see it being advisable to allow input or similar > before resume has completed... > > -- > Michael Chang > > Please avoid sending me Word or PowerPoint attachments. Send me ODT, > RTF, or HTML instead. > See http://www.gnu.org/philosophy/no-word-attachments.html > Thank you. > - > 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/ > - 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.23-rc3
Either people really are calming down, and figuring out that we're in the stabilization phase, or it's just that it's the middle of August, and most everybody at least in Europe are off on vacation. Regardless of why, -rc3 is out, and doesn't have the tons of changes that -rc2 did. But there's some scheduler updates, sparc64 and powerpc changes, and random driver updates (the lpfc SCSI driver kind of stands out in the diffstat). Shortlog appended, I don't know what I can add to it.. Please do give it a good testing, unless you're on a beach sunning yourself (and who are we kidding: you're pasty white, and sand is hard to get out of the keyboard - beaches are overrated). Linus --- Adrian Bunk (9): sony-laptop: sony_nc_ids[] can become static. ACPI: EC: acpi_ec_remove(): fix use-after-free ACPI: sbs: remove dead code [2.6 patch] ocfs2_insert_extent(): remove dead code remove mm/filemap.c:file_send_actor() cris: drivers/cdrom/Kconfig no longer exists i386: really stop MCEs during code patching ACPI: static sched: make global code static Adrian McMenamin (2): pvr2fb: Consolidated cleanup of pvr2fb.c pvr2fb: update Documentation/fb/pvr2fb.txt Al Viro (2): take sched_debug.c out of nasal demon territory fix oops in __audit_signal_info() Alan Cox (2): remove dubious legal statment from uio-howto fix serial buffer memory leak Alan D. Brunelle (1): Fix remap handling by blktrace Alan Stern (1): hex_dump: add missing "const" qualifiers Alexey Dobriyan (2): sched: remove binary sysctls from kernel.sched_domain Remove unused struct proc_dir_entry::set Alexey Starikovskiy (5): ACPI: EC: Remove noisy debug printk fron EC driver. ACPI: Battery: Synchronize battery operations. ACPI: EC: If ECDT is not found, look up EC in DSDT. ACPI: EC: Switch from boot_ec as soon as we find its desc in DSDT. ACPI EC: remove potential deadlock from EC Andi Kleen (6): x86_64: Don't mark __exitcall as __cold x86: Disable CLFLUSH support again i386: Make patching more robust, fix paravirt issue i386: Use global flag to disable broken local apic timer on AMD CPUs. i386: Add warning in Documentation that zero-page is not a stable ABI i386: Fix start_kernel warning Andre Detsch (1): [POWERPC] cell: Move SPU affinity init to spu_management_of_ops Andrew Morton (1): mtdchar build fix Andy Whitcroft (1): update checkpatch.pl to version 0.09 Anton Vorontsov (2): spi_mpc83xx: in "QE mode", use sysclk/2 spi_mpc83xx: fix prescale modulus calculation Antonino A. Daplas (2): fbcon: Kill compile warning pvr2fb: Fix oops when pseudo_palette is written Artem Bityutskiy (1): hexdump: use const notation Avi Kivity (1): KVM: x86 emulator: fix debug reg mov instructions Badari Pulavarty (1): direct-io: fix error-path crashes Benjamin Herrenschmidt (2): [POWERPC] Fix initialization and usage of dma_mask [POWERPC] Fix size check for hugetlbfs Boaz Harrosh (6): [SCSI] aha152x: fix debug mode symbol conflict [SCSI] aha152x: use bounce buffer [SCSI] aha152x: preliminary fixes and some comments [SCSI] aha152x: Clean Reset path [SCSI] aha152x: Fix check_condition code-path [SCSI] aha152x: use data accessors and !use_sg cleanup Brian King (1): ibmveth: Fix rx pool deactivate oops Bryan Wu (1): Blackfin arch: after removing fs.h from mm.h, fix the broken on Blackfin arch Christoph Hellwig (1): sysace: HDIO_GETGEO has it's own method for ages Christoph Lameter (2): SLUB: Remove checks for MAX_PARTIAL from kmem_cache_shrink SLUB: Fix dynamic dma kmalloc cache creation Chuck Ebbert (2): [NETFILTER]: Add xt_statistic.h to the header list for usermode programs i386: Fix double fault handler Cornelia Huck (1): [S390] cio: avoid memory leak on error in css_alloc_subchannel(). Dan Williams (2): [ARM] 4541/1: iop: defconfig updates async_tx: update MAINTAINERS for async_tx and iop-adma Daniel Drake (2): mac80211: missing dev_put in ieee80211_master_start_xmit mac80211: don't allow scanning in monitor mode Daniel Ritz (1): drivers/char/pcmcia/cm40x0_cs.c: fix release function call Dave Airlie (1): drm/i915: Fix i965 secured batchbuffer usage David Brownell (1): spidev warning fix David Howells (2): BLOCK: Hide the contents of linux/bio.h if CONFIG_BLOCK=n FRV: connect up fallocate David Miller (1): [SCSI] ESP: Revert ESP_BUS_TIMEOUT back down to 250 David S. Miller (4): [SPARC]: Centralize find_in_proplist() instead of duplicating N times. [SPARC64]: Fix hard-coding of cpu type output in /proc/cpuinfo on sun4v. [SPARC64]: Do not assume sun4v chips have load-twin/store-init support. [SPARC64]: Fix memory
Re: [PATCH] gfs2: better code for translating characters
rae l wrote: > On 8/13/07, Denis Cheng <[EMAIL PROTECTED]> wrote: >> the original code could work, but I think this code could work better. >> >> Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> >> --- >> fs/gfs2/ops_fstype.c |3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) >> >> diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c >> index cf5aa50..b9a7759 100644 >> --- a/fs/gfs2/ops_fstype.c >> +++ b/fs/gfs2/ops_fstype.c >> @@ -145,7 +145,8 @@ static int init_names(struct gfs2_sbd *sdp, int silent) >> snprintf(sdp->sd_proto_name, GFS2_FSNAME_LEN, "%s", proto); >> snprintf(sdp->sd_table_name, GFS2_FSNAME_LEN, "%s", table); >> >> - while ((table = strchr(sdp->sd_table_name, '/'))) >> + table = sdp->sd_table_name; >> + while ((table = strchr(table, '/'))) >> *table = '_'; > Sorry, I don't know what the while loop really means, what's the > common case that slash character exists? if the '/' appears multiple, > the latter code would be better; however, if slash appears rarely, the > original would still be better. > Only if the compiler is stupid. -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: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > > > If you have no interest in categorizing the SELinux access vectors, > then how do you expect to categorize the LSM hooks, which are almost > 1-to-1 mapped with the SELinux access vectors? Those that refer to object accesses and those that do not. The former are generally interesting, the latter are generally not. That's a rule of thumb, mind you. Anyway, have a look at the hook table, it's in smack_lsm.c > > The point you make, that you need to have that in order to create a > > policy description, is one of the reasons for Smack. Simplified. > > Well yes, but a simplified policy is useless if it uses no LSM > hooks. As above, that's smack_lsm.c, a little over 2000 lines of good old fashioned C code. > I will write you a Perl script which will generate a complete > and functionally equivalent SELinux policy (assuming I have enough > free time) given a file with your policy language. But I can do this > if and only if you tell me which of the SELinux access vectors you > care about (In other words, which of the LSM hooks you want to > require "read", "write", or "execute" privileges for). With such a > little script you could write all the "simplified" policy you want, > without having to change the kernel code at all. It's all spelled out in the module. Go wild. > > > My point is your policy format is SO simple it doesn't even need the > SELinux MLS code to handle it. From the way you've described it the > base policy (~200 lines) would be *identical* regardless of the > entries in your policy language, and the rest could be generated by a > script directly from the "C Unclass rx"-type stuff. Ok. > >> Whoops, I think I must have smashed the delete key or something > >> while sending. Here's the paragraphs which got elided: > >> > >> Well, yes, but a policy which completely ignores future > >> expandability can't be expanded upon regardless. It would also be > >> very hard to add new policy without a lot of duplication under > >> your system. On the other hand, with SELinux you can very easily > >> add attribute-based policy so adding new capabilities is as simple > >> as sticking existing attributes on newly defined types. For example: > >> > >> type my_log_t, file_type, log_file; > >> type my_log_daemon, daemon; > >> > >> Right there I just gave permission for the logrotate to recycle > >> files labelled my_log_t, which the sysadmin and audit admin can > >> also read (and the audit admin can delete). I also gave > >> permission for my daemon to send SIGCHLD to init, and for init/ > >> initscripts to send it a SIGTERM/SIGQUIT. All without writing a > >> SINGLE policy rule. Basically all of those existing behaviors are > >> found in allow rules built on the "file_type", "log_file", and > >> "daemon" attributes. > > > > Ah, now you're refering to the reference policy, right? > > Yes, precisely. For most of that functionality there are existing > attributes and types defined in the reference policy to make custom > policy much easier. Furthermore, there are interface files which > allow me to say something like "Let this program spawn an Apache > daemon in the right domain" with a single line. If I only want to do > that when the "httpd" module is loaded I can put the line in an > "optional" block. A policy for a basic network daemon with a couple > log files, a config file, and a little database is all of 30 lines, > maybe 50 if you throw in comments. After you have the 400,000 lines of reference policy behind it. > >>> They can be added or changed one by one as required while the > >>> system is running, and there are uses that exploit that. One > >>> example is to put the label "Game" on certain programs and: > >>> > >>>at 8:00am "Worker Game no" > >>>at 5:00pm "Worker Game x" > >>> > >>> Thus Worker processes can access Game files only during off hours. > >> > >> This is fundamentally broken: > >> [...] > >> Secondly, you can already do the same thing with DAC and a PAM > >> groups-from-time-of-day module, I don't see why such a thing is > >> special enough to need MAC. Thirdly, I could do exactly the same > >> thing with an SELinux boolean and a cronjob (once we get proper > >> revoke support): > > > > There is usually a way to address any particular problem using DAC, > > it's often sufficiently painful that MAC looks like a better approach. > > No, generally the only reason to use MAC is when it's security- > critical (system compromise, classified data, critical > infrastructure, etc). Denying users access to games during the > workday is hardly "security-critical". If that system's CPU time was > exclusively needed for a life support machine during the day then > maybe, but that's what renice or realtime scheduling are for and why > the hell are you installing games on a heart monitor? HeeHee. Don't think heart
[PATCH 5 of 5 ] /drivers/char/watchdog ioremap balancing/ returncode check
patchset against 2.6.23-rc2 and this set is an audit of
/drivers/char/a*
through drivers/char .
this corrects missing ioremap return checks and balancing on
iounmap calls..
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/char/watchdog/iTCO_wdt.c
b/drivers/char/watchdog/iTCO_wdt.c
index cd5a565..81c5901 100644
--- a/drivers/char/watchdog/iTCO_wdt.c
+++ b/drivers/char/watchdog/iTCO_wdt.c
@@ -621,6 +621,12 @@ static int iTCO_wdt_init(struct pci_dev *pdev,
const struct pci_device_id *ent,
pci_read_config_dword(pdev, 0xf0, _address);
RCBA = base_address & 0xc000;
iTCO_wdt_private.gcs = ioremap((RCBA + 0x3410),4);
+ if (!iTCO_wdt_private.gcs) {
+ printk(KERN_ERR PFX "failed to ioremap\n");
+ ret = -ENOMEM;
+ goto out;
+ }
+
}
/* Check chipset's NO_REBOOT bit */
-
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 of 5 ] /drivers/char/rio ioremap balancing/ returncode check
patchset against 2.6.23-rc2 and this set is an audit of
/drivers/char/a*
through drivers/char .
this corrects missing ioremap return checks and balancing on
iounmap calls..
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/char/rio/rio_linux.c
b/drivers/char/rio/rio_linux.c
index 0ce9667..fdaf44f 100644
--- a/drivers/char/rio/rio_linux.c
+++ b/drivers/char/rio/rio_linux.c
@@ -924,6 +924,11 @@ static void fix_rio_pci(struct pci_dev *pdev)
hwbase = pci_resource_start(pdev, 0);
rebase = ioremap(hwbase, 0x80);
+ if (!rebase) {
+ printk(KERN_DEBUG "rio: unable to perform cntrl reg fix as
ioremap call failed\n");
+ return;
+ }
+
t = readl(rebase + CNTRL_REG_OFFSET);
if (t != CNTRL_REG_GOODVALUE) {
printk(KERN_DEBUG "rio: performing cntrl reg fix: %08x ->
%08x\n", t, CNTRL_REG_GOODVALUE);
@@ -996,6 +1001,11 @@ static int __init rio_init(void)
if (((1 << hp->Ivec) & rio_irqmask) == 0)
hp->Ivec = 0;
hp->Caddr = ioremap(p->RIOHosts[p->RIONumHosts].PaddrP,
RIO_WINDOW_LEN);
+ if (!hp->Caddr) {
+ printk(KERN_ERR "RIO: Unable to ioremap.\n");
+ return -ENOMEM;
+ }
+
hp->CardP = (struct DpRam __iomem *) hp->Caddr;
hp->Type = RIO_PCI;
hp->Copy = rio_copy_to_card;
@@ -1049,6 +1059,10 @@ static int __init rio_init(void)
hp->Ivec = 0;
hp->Ivec |= 0x8000; /* Mark as non-sharable */
hp->Caddr = ioremap(p->RIOHosts[p->RIONumHosts].PaddrP,
RIO_WINDOW_LEN);
+ if (!hp->Caddr) {
+ printk(KERN_ERR "RIO: Unable to ioremap.\n");
+ return -ENOMEM;
+ }
hp->CardP = (struct DpRam __iomem *) hp->Caddr;
hp->Type = RIO_PCI;
hp->Copy = rio_copy_to_card;
-
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 of 5 ] /drivers/char/drm ioremap balancing/ returncode check
patchset against 2.6.23-rc2 and this set is an audit of
/drivers/char/a*
through drivers/char .
this corrects missing ioremap return checks and balancing on
iounmap calls..
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/char/drm/drm_bufs.c
b/drivers/char/drm/drm_bufs.c
index 923174c..448488b 100644
--- a/drivers/char/drm/drm_bufs.c
+++ b/drivers/char/drm/drm_bufs.c
@@ -177,8 +177,13 @@ static int drm_addmap_core(struct drm_device *
dev, unsigned int offset,
MTRR_TYPE_WRCOMB, 1);
}
}
- if (map->type == _DRM_REGISTERS)
+ if (map->type == _DRM_REGISTERS) {
map->handle = ioremap(map->offset, map->size);
+ if (!map->handle) {
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ return -ENOMEM;
+ }
+ }
break;
case _DRM_SHM:
list = drm_find_matching_map(dev, map);
-
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 of 5 ] /drivers/char/agp ioremap balancing/ returncode check
patchset against 2.6.23-rc2 and this set is an audit of
/drivers/char/a*
through drivers/char .
this corrects missing ioremap return checks and balancing on
iounmap calls..
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-
k7-agp.c
index df0ddf1..ad946fd 100644
--- a/drivers/char/agp/amd-k7-agp.c
+++ b/drivers/char/agp/amd-k7-agp.c
@@ -223,7 +223,9 @@ static int amd_irongate_configure(void)
pci_read_config_dword(agp_bridge->dev, AMD_MMBASE, );
temp = (temp & PCI_BASE_ADDRESS_MEM_MASK);
amd_irongate_private.registers = (volatile u8 __iomem *)
ioremap(temp, 4096);
-
+ if (!amd_irongate_private.registers)
+ return -ENOMEM;
+
/* Write out the address of the gatt table */
writel(agp_bridge->gatt_bus_addr,
amd_irongate_private.registers+AMD_ATTBASE);
readl(amd_irongate_private.registers+AMD_ATTBASE); /* PCI
Posting. */
diff --git a/drivers/char/agp/ati-agp.c b/drivers/char/agp/ati-agp.c
index da7513d..95200f8 100644
--- a/drivers/char/agp/ati-agp.c
+++ b/drivers/char/agp/ati-agp.c
@@ -213,6 +213,9 @@ static int ati_configure(void)
temp = (temp & 0xf000);
ati_generic_private.registers = (volatile u8 __iomem *)
ioremap(temp, 4096);
+ if (!ati_generic_private.registers)
+ return -ENOMEM;
+
if (is_r200())
pci_write_config_dword(agp_bridge->dev, ATI_RS100_IG_AGPMODE,
0x2);
else
diff --git a/drivers/char/agp/hp-agp.c b/drivers/char/agp/hp-agp.c
index bcdb149..313a133 100644
--- a/drivers/char/agp/hp-agp.c
+++ b/drivers/char/agp/hp-agp.c
@@ -221,6 +221,7 @@ hp_zx1_lba_init (u64 hpa)
if (cap != PCI_CAP_ID_AGP) {
printk(KERN_ERR PFX "Invalid capability ID 0x%02x at 0x%x\n",
cap, hp->lba_cap_offset);
+ iounmap(hp->lba_regs);
return -ENODEV;
}
diff --git a/drivers/char/agp/i460-agp.c b/drivers/char/agp/i460-
agp.c
index 53354bf..75d2aca 100644
--- a/drivers/char/agp/i460-agp.c
+++ b/drivers/char/agp/i460-agp.c
@@ -249,6 +249,10 @@ static int i460_create_gatt_table (struct
agp_bridge_data *bridge)
num_entries = A_SIZE_8(temp)->num_entries;
i460.gatt = ioremap(INTEL_I460_ATTBASE, PAGE_SIZE << page_order);
+ if (!i460.gatt) {
+ printk(KERN_ERR PFX "ioremap failed\n");
+ return -ENOMEM;
+ }
/* These are no good, the should be removed from the agp_bridge
strucure... */
agp_bridge->gatt_table_real = NULL;
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-
agp.c
index 294cdbf..ffa7cdf 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -930,8 +930,10 @@ static int intel_i915_create_gatt_table(struct
agp_bridge_data *bridge)
temp &= 0xfff8;
intel_private.registers = ioremap(temp,128 * 4096);
- if (!intel_private.registers)
+ if (!intel_private.registers) {
+ iounmap(intel_private.gtt);
return -ENOMEM;
+ }
temp = readl(intel_private.registers+I810_PGETBL_CTL) &
0xf000;
global_cache_flush(); /* FIXME: ? */
@@ -985,13 +987,15 @@ static int
intel_i965_create_gatt_table(struct agp_bridge_data *bridge)
temp &= 0xfff0;
intel_private.gtt = ioremap((temp + (512 * 1024)) , 512 *
1024);
- if (!intel_private.gtt)
- return -ENOMEM;
+ if (!intel_private.gtt)
+ return -ENOMEM;
intel_private.registers = ioremap(temp,128 * 4096);
- if (!intel_private.registers)
- return -ENOMEM;
+ if (!intel_private.registers) {
+ iounmap(intel_private.gtt);
+ return -ENOMEM;
+ }
temp = readl(intel_private.registers+I810_PGETBL_CTL) &
0xf000;
global_cache_flush(); /* FIXME: ? */
diff --git a/drivers/char/agp/nvidia-agp.c
b/drivers/char/agp/nvidia-agp.c
index 6cd7373..225ed2a 100644
--- a/drivers/char/agp/nvidia-agp.c
+++ b/drivers/char/agp/nvidia-agp.c
@@ -157,6 +157,9 @@ static int nvidia_configure(void)
nvidia_private.aperture =
(volatile u32 __iomem *) ioremap(apbase, 33 * PAGE_SIZE);
+ if (!nvidia_private.aperture)
+ return -ENOMEM;
+
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/
[PATCH 1 of 5 ] /drivers/char ioremap balancing/ returncode check
patchset against 2.6.23-rc2 and this set is an audit of
/drivers/char/a*
through drivers/char .
this corrects missing ioremap return checks and balancing on
iounmap calls..
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index 77bf4aa..53d233e 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -936,6 +936,12 @@ static acpi_status hpet_resources(struct
acpi_resource *res, void *data)
hdp->hd_phys_address = addr.minimum;
hdp->hd_address = ioremap(addr.minimum, addr.address_length);
+ if (!hdp->hd_address) {
+ printk(KERN_DEBUG "%s: ioremap failed\n",
+ __FUNCTION__);
+ return -ENOMEM;
+ }
+
if (hpet_is_known(hdp)) {
printk(KERN_DEBUG "%s: 0x%lx is busy\n",
__FUNCTION__, hdp->hd_phys_address);
@@ -953,6 +959,12 @@ static acpi_status hpet_resources(struct
acpi_resource *res, void *data)
hdp->hd_address = ioremap(fixmem32->address,
HPET_RANGE_SIZE);
+ if (!hdp->hd_address) {
+ printk(KERN_DEBUG "%s: ioremap failed\n",
+ __FUNCTION__);
+ return -ENOMEM;
+ }
+
if (hpet_is_known(hdp)) {
printk(KERN_DEBUG "%s: 0x%lx is busy\n",
__FUNCTION__, hdp->hd_phys_address);
diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c
index ed76f0a..094323d 100644
--- a/drivers/char/moxa.c
+++ b/drivers/char/moxa.c
@@ -447,6 +447,13 @@ static int __init moxa_init(void)
for (i = 0; i < numBoards; i++) {
moxa_boards[i].basemem = ioremap(moxa_boards[i].baseAddr,
0x4000);
+ if (!moxa_boards[i].basemem) {
+ for (;i > 0;i--)
+ if (moxa_boards[i].basemem)
+ iounmap(moxa_boards[i].basemem);
+
+ return -ENOMEM;
+ }
}
return retval;
diff --git a/drivers/char/sx.c b/drivers/char/sx.c
index 85a2328..30829ed 100644
--- a/drivers/char/sx.c
+++ b/drivers/char/sx.c
@@ -2627,6 +2627,12 @@ static void __devinit fix_sx_pci(struct
pci_dev *pdev, struct sx_board *board)
pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, );
hwbase &= PCI_BASE_ADDRESS_MEM_MASK;
rebase = ioremap(hwbase, 0x80);
+ if (!rebase) {
+ printk(KERN_DEBUG
+ "sx:ioremap fail, unable to perform cntrl reg fix\n");
+ return;
+ }
+
t = readl(rebase + CNTRL_REG_OFFSET);
if (t != CNTRL_REG_GOODVALUE) {
printk(KERN_DEBUG "sx: performing cntrl reg fix: %08x -> "
diff --git a/drivers/char/vr41xx_giu.c b/drivers/char/vr41xx_giu.c
index e5ed091..2381162 100644
--- a/drivers/char/vr41xx_giu.c
+++ b/drivers/char/vr41xx_giu.c
@@ -639,8 +639,10 @@ static int __devinit giu_probe(struct
platform_device *dev)
}
irq = platform_get_irq(dev, 0);
- if (irq < 0 || irq >= NR_IRQS)
+ if (irq < 0 || irq >= NR_IRQS) {
+ iounmap(giu_base);
return -EBUSY;
+ }
return cascade_irq(irq, giu_get_irq);
}
-
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/12] x86: Work around mmio config space quirk on AMD Fam10h
On Sun, 12 Aug 2007, Linus Torvalds wrote: > On Sun, 12 Aug 2007, Dave Jones wrote: > > > > This does make me wonder, why these weren't caught in -mm ? > > I'm worried that -mm isn't getting a lot of exposure these days. People do > run it, but I wonder how many.. andrew caught it in -mm and reverted it. it crashed his vaio. -dean - 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 ] /drivers/atm ioremap balancing/ returncode check
patchset against 2.6.23-rc2.
corrects missing ioremap return checks and balancing on iounmap
calls in /drivers/atm...
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index 405ee5e..99e4ae4 100644
--- a/drivers/atm/fore200e.c
+++ b/drivers/atm/fore200e.c
@@ -795,8 +795,9 @@ fore200e_sba_map(struct fore200e* fore200e)
fore200e->regs.sba.isr = sbus_ioremap(_dev->resource[2],
0, SBA200E_ISR_LENGTH, "SBA ISR");
fore200e->virt_base= sbus_ioremap(_dev->resource[3],
0, SBA200E_RAM_LENGTH, "SBA RAM");
-if (fore200e->virt_base == NULL) {
+if (!fore200e->regs.sba.hcr || !fore200e->regs.sba.bsr ||
!fore200e->regs.sba.isr || !fore200e->virt_base) {
printk(FORE200E "unable to map RAM of device %s\n", fore200e-
>name);
+ fore200e_sba_unmap(fore200e);
return -EFAULT;
}
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index d33aba6..92d0d51 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -1107,6 +1107,7 @@ he_start(struct atm_dev *dev)
status = he_readl(he_dev, RESET_CNTL);
if ((status & BOARD_RST_STATUS) == 0) {
hprintk("reset failed\n");
+ iounmap(he_dev->membase);
return -EINVAL;
}
@@ -1170,8 +1171,10 @@ he_start(struct atm_dev *dev)
he_writel(he_dev, lb_swap, LB_SWAP);
/* 4.10 initialize the interrupt queues */
- if ((err = he_init_irq(he_dev)) != 0)
+ if ((err = he_init_irq(he_dev)) != 0) {
+ iounmap(he_dev->membase);
return err;
+ }
#ifdef USE_TASKLET
tasklet_init(_dev->tasklet, he_tasklet, (unsigned long)
he_dev);
@@ -1226,6 +1229,7 @@ he_start(struct atm_dev *dev)
if (nvpibits != -1 && nvcibits != -1 && nvpibits+nvcibits !=
HE_MAXCIDBITS) {
hprintk("nvpibits + nvcibits != %d\n", HE_MAXCIDBITS);
+ iounmap(he_dev->membase);
return -ENODEV;
}
@@ -1474,9 +1478,10 @@ he_start(struct atm_dev *dev)
/* 5.1.8 cs block connection memory initialization */
- if (he_init_cs_block_rcm(he_dev) < 0)
+ if (he_init_cs_block_rcm(he_dev) < 0) {
+ iounmap(he_dev->membase);
return -ENOMEM;
-
+ }
/* 5.1.10 initialize host structures */
he_init_tpdrq(he_dev);
@@ -1486,6 +1491,7 @@ he_start(struct atm_dev *dev)
sizeof(struct he_tpd), TPD_ALIGNMENT, 0);
if (he_dev->tpd_pool == NULL) {
hprintk("unable to create tpd pci_pool\n");
+ iounmap(he_dev->membase);
return -ENOMEM;
}
@@ -1493,8 +1499,10 @@ he_start(struct atm_dev *dev)
#else
he_dev->tpd_base = (void *) pci_alloc_consistent(he_dev->pci_dev,
CONFIG_NUMTPDS * sizeof(struct he_tpd),
_dev->tpd_base_phys);
- if (!he_dev->tpd_base)
+ if (!he_dev->tpd_base) {
+ iounmap(he_dev->membase);
return -ENOMEM;
+ }
for (i = 0; i < CONFIG_NUMTPDS; ++i) {
he_dev->tpd_base[i].status = (i << TPD_ADDR_SHIFT);
@@ -1505,8 +1513,10 @@ he_start(struct atm_dev *dev)
he_dev->tpd_end = _dev->tpd_base[CONFIG_NUMTPDS - 1];
#endif
- if (he_init_group(he_dev, 0) != 0)
+ if (he_init_group(he_dev, 0) != 0) {
+ iounmap(he_dev->membase);
return -ENOMEM;
+ }
for (group = 1; group < HE_NUM_GROUPS; ++group) {
he_writel(he_dev, 0x0, G0_RBPS_S + (group * 32));
@@ -1540,6 +1550,7 @@ he_start(struct atm_dev *dev)
sizeof(struct he_hsp), _dev->hsp_phys);
if (he_dev->hsp == NULL) {
hprintk("failed to allocate host status page\n");
+ iounmap(he_dev->membase);
return -ENOMEM;
}
memset(he_dev->hsp, 0, sizeof(struct he_hsp));
-
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 ] /drivers/ata ioremap returncode check (pata_ixp4xx_cf.c)
patch against 2.6.23-rc2. this corrects two missing ioremap return
checks.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/ata/pata_ixp4xx_cf.c
b/drivers/ata/pata_ixp4xx_cf.c
index 4ca7fd6..eaebc4d 100644
--- a/drivers/ata/pata_ixp4xx_cf.c
+++ b/drivers/ata/pata_ixp4xx_cf.c
@@ -189,6 +189,14 @@ static __devinit int ixp4xx_pata_probe(struct
platform_device *pdev)
data->cs0 = devm_ioremap(>dev, cs0->start, 0x1000);
data->cs1 = devm_ioremap(>dev, cs1->start, 0x1000);
+ if (!data->cs0 || !data->cs1) {
+ if (data->cs0)
+ iounmap(data->cs0);
+ if (data->cs1)
+ iounmap(data->cs1);
+ return -ENOMEM;
+ }
+
irq = platform_get_irq(pdev, 0);
if (irq)
set_irq_type(irq, IRQT_RISING);
-
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/12] x86: Work around mmio config space quirk on AMD Fam10h
On Sun, 12 Aug 2007, Dave Jones wrote: > > This does make me wonder, why these weren't caught in -mm ? I'm worried that -mm isn't getting a lot of exposure these days. People do run it, but I wonder how many.. That said, a lot of machines won't ever use MMCFG (especially the old ones - and most of the new ones would run x86-64), so that probably explains at least that one. But the x86-64 alternates code would hit anybody who had the "use rep movs for best performance" code, and I'm surprised that one wasn't caught earlier. X86_FEATURE_REP_GOOD is not uncommon (Core 2 has it). So I assume that one wasn't really in -mm at all. 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] Immediate Values - i386 Optimization - fix warnings
Immediate Values - i386 optimization - fix warnings 2 warnings creps in caused by my recent work with text lock edit. arch/i386/kernel/immediate.c: In function 'arch_immediate_update': arch/i386/kernel/immediate.c:228: warning: passing argument 1 of '__constant_memcpy' makes pointer from integer without a cast arch/i386/kernel/immediate.c:228: warning: passing argument 1 of '__memcpy' makes pointer from integer without a cast arch/i386/kernel/immediate.c:185: warning: unused variable 'bypass_immediate' This trivial patch fixes this issue. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> --- arch/i386/kernel/immediate.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: linux-2.6-lttng/arch/i386/kernel/immediate.c === --- linux-2.6-lttng.orig/arch/i386/kernel/immediate.c 2007-08-12 23:19:19.0 -0400 +++ linux-2.6-lttng/arch/i386/kernel/immediate.c2007-08-12 23:19:56.0 -0400 @@ -182,7 +182,6 @@ __kprobes int arch_immediate_update(cons int ret; size_t insn_size = _immediate_get_insn_size(immediate->size); long insn = immediate->immediate - insn_size; - long bypass_immediate; #ifdef CONFIG_KPROBES /* @@ -225,7 +224,7 @@ __kprobes int arch_immediate_update(cons after_immediate = immediate->immediate + immediate->size; kernel_text_mark_rw((unsigned long)bypass_eip, NR_NOPS); - memcpy(bypass_eip, (void*)insn, insn_size + immediate->size); + memcpy((void*)bypass_eip, (void*)insn, insn_size + immediate->size); /* * Fill the rest with nops. */ -- 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: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
per the message below MD (or DM) would need to be modified to work reasonably well with one of the disk components being over an unreliable link (like a network link) are the MD/DM maintainers interested in extending their code in this direction? or would they prefer to keep it simpler by being able to continue to assume that the raid components are connected over a highly reliable connection? if they are interested in adding (and maintaining) this functionality then there is a real possibility that NBD+MD/DM could eliminate the need for DRDB. however if they are not interested in adding all the code to deal with the network type issues, then the argument that DRDB should not be merged becouse you can do the same thing with MD/DM + NBD is invalid and can be dropped/ignored David Lang On Sun, 12 Aug 2007, Paul Clements wrote: Iustin Pop wrote: On Sun, Aug 12, 2007 at 07:03:44PM +0200, Jan Engelhardt wrote: > On Aug 12 2007 09:39, [EMAIL PROTECTED] wrote: > > now, I am not an expert on either option, but three are a couple > > things that I > > would question about the DRDB+MD option > > > > 1. when the remote machine is down, how does MD deal with it for reads > > and > > writes? > I suppose it kicks the drive and you'd have to re-add it by hand unless > done by > a cronjob. Yes, and with a bitmap configured on the raid1, you just resync the blocks that have been written while the connection was down. >From my tests, since NBD doesn't have a timeout option, MD hangs in the write to that mirror indefinitely, somewhat like when dealing with a broken IDE driver/chipset/disk. Well, if people would like to see a timeout option, I actually coded up a patch a couple of years ago to do just that, but I never got it into mainline because you can do almost as well by doing a check at user-level (I basically ping the nbd connection periodically and if it fails, I kill -9 the nbd-client). > > 2. MD over local drive will alternate reads between mirrors (or so > > I've been > > told), doing so over the network is wrong. > Certainly. In which case you set "write_mostly" (or even write_only, not > sure > of its name) on the raid component that is nbd. > > > 3. when writing, will MD wait for the network I/O to get the data > > saved on the > > backup before returning from the syscall? or can it sync the data out > > lazily > Can't answer this one - ask Neil :) MD has the write-mostly/write-behind options - which help in this case but only up to a certain amount. You can configure write_behind (aka, asynchronous writes) to buffer as much data as you have RAM to hold. At a certain point, presumably, you'd want to just break the mirror and take the hit of doing a resync once your network leg falls too far behind. -- Paul - 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: Improving read/write/close system call reliability when used with pthreads
> 2) Do close reader fd, but what results can then applications > reliably expect? What would be the sane intention of applications > closing reader fd? Do programmers expect all of the current results? > Fredrik Since there's no atomic "unlock and read" function, any code that could ever close a socket in one thread while another thread is blocked on read might call close just before another thread blocks in read. Nothing stops another thread from opening something, getting the same file descriptor, and then allowing the thread to call "read" on the wrong file descriptor entirely. Since this can never be made sane in general, I see little point in making one variation of what can go wrong a bit saner. It is still irresponsible to code like this. DS - 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: Software based ECC ?
On Sun, 12 Aug 2007 18:51:31 +0200, Folkert van Heusden said: > a question and an idea: Q: is ecc guaranteed to detect all bitflips? It depends on the exact ECC function the hardware implements. Usually it provides performance such as: "Correct all 1-bit errors. Detect all 2-bit errors, and most 3 and higher, but not correct". (Of course, "correct all 1 or 2 bit and detect all 3 bit" can be done, it just takes more bits of ECC.) > Idea: what about a multicore system (3 or more) that runs the same > processes on 2 cores and a third core verifying that they both do the > same? As I think it is not only ram that can become faulty. This is actually done for high-reliability systems (Google for "tell me twice" and "tell me three times"). The problem is that it takes a lot of extra hardware. The G5 and later IBM Z-series mainframe chipsets (not to be confused with the PowerPC G5) implemented dual computation units and a comparator that signals a 'Machine Check' condition if the two CPUs don't end up in the same exact state (as an added bonus, at the end of each instruction that both *do* compare good, it latches the *entire* state of the CPU out, and then does the following: 1) Retry the instruction on the same CPU - if it compares correctly, keep going and flag a "soft" error. 2) If it still fails, read out the last "known good" status latch, and load it into a spare CPU, and fire it up, and flag the failing one as bad. http://www.research.ibm.com/journal/rd/435/spainhower.pdf http://www.research.ibm.com/journal/rd/435/mueller.pdf These guys have forgotten more about designing highly reliable systems than most of us will ever know. ;) Needless to say, not everybody is willing to pay the costs of the hardware overhead of this approach. pgpCmbxDYMQib.pgp Description: PGP signature
Re: [PATCH] gfs2: better code for translating characters
On 8/13/07, Denis Cheng <[EMAIL PROTECTED]> wrote: > the original code could work, but I think this code could work better. > > Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> > --- > fs/gfs2/ops_fstype.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c > index cf5aa50..b9a7759 100644 > --- a/fs/gfs2/ops_fstype.c > +++ b/fs/gfs2/ops_fstype.c > @@ -145,7 +145,8 @@ static int init_names(struct gfs2_sbd *sdp, int silent) > snprintf(sdp->sd_proto_name, GFS2_FSNAME_LEN, "%s", proto); > snprintf(sdp->sd_table_name, GFS2_FSNAME_LEN, "%s", table); > > - while ((table = strchr(sdp->sd_table_name, '/'))) > + table = sdp->sd_table_name; > + while ((table = strchr(table, '/'))) > *table = '_'; Sorry, I don't know what the while loop really means, what's the common case that slash character exists? if the '/' appears multiple, the latter code would be better; however, if slash appears rarely, the original would still be better. > > out: > -- > 1.5.2.2 > > -- Denis Cheng Linux Application Developer "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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/12] x86: Work around mmio config space quirk on AMD Fam10h
On Sun, Aug 12, 2007 at 12:15:26PM -0700, Linus Torvalds wrote: > Bugs happen, but (a) they should happen during the merge window, not when > we're in stabilization phase and (b) the percentages here were just not > very good. This does make me wonder, why these weren't caught in -mm ? Andrew lines up Andi's quilt series in each run afaik, or was the last patchbombing all stuff that bypassed -mm for some reason? Dave -- http://www.codemonkey.org.uk - 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] gfs2: better code for translating characters
the original code could work, but I think this code could work better. Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> --- fs/gfs2/ops_fstype.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c index cf5aa50..b9a7759 100644 --- a/fs/gfs2/ops_fstype.c +++ b/fs/gfs2/ops_fstype.c @@ -145,7 +145,8 @@ static int init_names(struct gfs2_sbd *sdp, int silent) snprintf(sdp->sd_proto_name, GFS2_FSNAME_LEN, "%s", proto); snprintf(sdp->sd_table_name, GFS2_FSNAME_LEN, "%s", table); - while ((table = strchr(sdp->sd_table_name, '/'))) + table = sdp->sd_table_name; + while ((table = strchr(table, '/'))) *table = '_'; out: -- 1.5.2.2 - 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] Smack: Simplified Mandatory Access Control Kernel
Kyle Moffett wrote: On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote: Your boolean solution requires more forthought than the Smack rule solution, but I'll give it to you once you've fleshed out your "##" lines. How does it require more forethought? When I want to turn it on, I write and load the 5 line policy then add the cronjobs. Yours involves giving cron unconditional permission to write to your security database (always a bad idea) and then adding similar cronjobs. nit: without the selinux policy server (which is not production ready by any means) we have to grant the same to cron in this case (or at least to the domain that cron runs the cronjobs in). SELinux and Smack alike need special permissions to modify the running policy, no surprises there. - 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] Smack: Simplified Mandatory Access Control Kernel
On Aug 12, 2007, at 22:36:15, Joshua Brindle wrote: Kyle Moffett wrote: On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote: Your boolean solution requires more forthought than the Smack rule solution, but I'll give it to you once you've fleshed out your "##" lines. How does it require more forethought? When I want to turn it on, I write and load the 5 line policy then add the cronjobs. Yours involves giving cron unconditional permission to write to your security database (always a bad idea) and then adding similar cronjobs. nit: without the selinux policy server (which is not production ready by any means) we have to grant the same to cron in this case (or at least to the domain that cron runs the cronjobs in). SELinux and Smack alike need special permissions to modify the running policy, no surprises there. Yeah, I figured this out a couple minutes ago. Turns out you can get a similar effect with a little properly labeled shell script though (text included in my last email), but it does decrease overall system security. Cheers, Kyle Moffett - 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: encrypted hibernation (was Re: Hibernation considerations)
On 8/11/07, Dr. David Alan Gilbert <[EMAIL PROTECTED]> wrote: > * Pavel Machek ([EMAIL PROTECTED]) wrote: > > Hi! > > > > > > > Two things which I think would be nice to consider are: > > > > >1) Encryption - I'd actually prefer if my luks device did not > > > > >remember the key accross a hibernation; I want to be forced to > > > > >reenter the phrase. However I don't know what the best thing > > > > >to do to partitions/applications using the luks device is. > > > > > > > > Encryption is possible with both the userland hibernation (aka uswsusp) > > > > and > > > > TuxOnIce (formerly known as suspend2). Still, I don't consider it as a > > > > "must > > > > have" feature for a framework to be generally useful (many users don't > > > > use it > > > > anyway). > > > > > > If a user uses an encrypted filesystem, then he also needs an encrypted > > > swap and encrypted hibernation image: Otherwise the fileystem encryption > > > is not very useful. > > > > Actually, we can do most of that stuff already. > > > > We can encrypt filesystems, encrypt swaps (LVM), and encrypt hibernation. > > But can you do what my original question was; find a way to lose a luks > encrypted device key and cleanly unmount the filesystem that was > using it? (and preferably put it all back together after resume). > If you lose the device key, how are you going to get luks to find it again when resuming? Wouldn't it make more sense to have it remember the key? I can't see it being advisable to allow input or similar before resume has completed... -- Michael Chang Please avoid sending me Word or PowerPoint attachments. Send me ODT, RTF, or HTML instead. See http://www.gnu.org/philosophy/no-word-attachments.html Thank you. - 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: [linux-pm] Re: When to use a freezeable workqueue?
On Mon, 13 Aug 2007, Rafael J. Wysocki wrote: > On Sunday, 12 August 2007 10:11, Stefan Richter wrote: > > In which situations is create_freezeable_workqueue() to be preferred > > over create_singlethread_workqueue()? > > > > Is a freezable worqueue preferable whenever the worker thread /can/ be > > frozen, or is it only to be used if the thread /must/ be frozen during > > suspend? > > The latter, IMO. > > Generally, if you want it to be frozen. A good example of a reason for making a workqueue freezable is that the workqueue contains entries which would cause a suspended device to be resumed. Obviously you don't want such things to happen while the system is going to sleep. A little less obviously, there might also be problems if such a routine ran while the system was waking up. Another reason might be that the workqueue contains entries which would try to register or unregister a device. Such actions aren't a good idea at times when the PM core is iterating through a list of all devices in order to suspend or resume them. And in the future such actions may block, effectively freezing the workqueue anyway -- which could be troublesome if you don't want the workqueue to be frozen! Alan Stern - 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] x86_64 vDSO: install unstripped copies on disk
While integrating these with the Fedora kernel build, I worked out a few kinks. This patch replaces x86_64-vdso-install-unstripped-copies-on-disk.patch and expects x86_64-ia32-vdso-install-unstripped-copies-on-disk.patch was applied first. Thanks, Roland --- This keeps an unstripped copy of the vDSO images built before they are stripped and embedded in the kernel. The unstripped copies get installed in $(MODLIB)/vdso/ by "make install" (or you can explicitly use the subtarget "make vdso_install"). These files can be useful when they contain source-level debugging information. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- arch/x86_64/Makefile |1 + arch/x86_64/vdso/Makefile | 20 2 files changed, 17 insertions(+), 4 deletions(-) diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile index 93fc1f2..c0905ae 100644 --- a/arch/x86_64/Makefile +++ b/arch/x86_64/Makefile @@ -112,6 +112,7 @@ vdso_install: ifeq ($(CONFIG_IA32_EMULATION),y) $(Q)$(MAKE) $(build)=arch/x86_64/ia32 $@ endif + $(Q)$(MAKE) $(build)=arch/x86_64/vdso $@ archclean: $(Q)$(MAKE) $(clean)=$(boot) diff --git a/arch/x86_64/vdso/Makefile b/arch/x86_64/vdso/Makefile index faaa72f..20ecf05 100644 --- a/arch/x86_64/vdso/Makefile +++ b/arch/x86_64/vdso/Makefile @@ -13,7 +13,7 @@ vobjs := $(foreach F,$(vobjs-y),$(obj)/$F) $(obj)/vdso.o: $(obj)/vdso.so -targets += vdso.so vdso.lds $(vobjs-y) vdso-syms.o +targets += vdso.so vdso.so.dbg vdso.lds $(vobjs-y) vdso-syms.o # The DSO images are built using a special linker script. quiet_cmd_syscall = SYSCALL $@ @@ -25,14 +25,18 @@ export CPPFLAGS_vdso.lds += -P -C -U$(ARCH) vdso-flags = -fPIC -shared -Wl,-soname=linux-vdso.so.1 \ $(call ld-option, -Wl$(comma)--hash-style=sysv) \ -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 -SYSCFLAGS_vdso.so = $(vdso-flags) +SYSCFLAGS_vdso.so.dbg = $(vdso-flags) $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so -$(obj)/vdso.so: $(src)/vdso.lds $(vobjs) FORCE +$(obj)/vdso.so.dbg: $(src)/vdso.lds $(vobjs) FORCE $(call if_changed,syscall) -CFL := $(PROFILING) -mcmodel=small -fPIC -g0 -O2 -fasynchronous-unwind-tables -m64 +$(obj)/%.so: OBJCOPYFLAGS := -S +$(obj)/%.so: $(obj)/%.so.dbg FORCE + $(call if_changed,objcopy) + +CFL := $(PROFILING) -mcmodel=small -fPIC $(if $(CONFIG_DEBUG_INFO),-g,-g0) -O2 -fasynchronous-unwind-tables -m64 $(obj)/vclock_gettime.o: CFLAGS = $(CFL) $(obj)/vgetcpu.o: CFLAGS = $(CFL) @@ -47,3 +51,11 @@ $(obj)/built-in.o: ld_flags += -R $(obj)/vdso-syms.o SYSCFLAGS_vdso-syms.o = -r -d $(obj)/vdso-syms.o: $(src)/vdso.lds $(vobjs) FORCE $(call if_changed,syscall) + +quiet_cmd_vdso_install = INSTALL $@ + cmd_vdso_install = cp $(obj)/[EMAIL PROTECTED] $(MODLIB)/vdso/$@ +vdso.so: + @mkdir -p $(MODLIB)/vdso + $(call cmd,vdso_install) + +vdso_install: vdso.so - 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] x86_64 ia32 vDSO: install unstripped copies on disk
While integrating these with the Fedora kernel build, I worked out a few kinks. This patch replaces x86_64-ia32-vdso-install-unstripped-copies-on-disk.patch Thanks, Roland --- This keeps an unstripped copy of the vDSO images built before they are stripped and embedded in the kernel. The unstripped copies get installed in $(MODLIB)/vdso/ by "make install" (or you can explicitly use the subtarget "make vdso_install"). These files can be useful when they contain source-level debugging information. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> Cc: Sam Ravnborg <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> --- arch/x86_64/Makefile |3 +++ arch/x86_64/ia32/Makefile | 25 + 2 files changed, 24 insertions(+), 4 deletions(-) diff -puN arch/x86_64/Makefile~x86_64-ia32-vdso-install-unstripped-copies-on-disk arch/x86_64/Makefile --- a/arch/x86_64/Makefile~x86_64-ia32-vdso-install-unstripped-copies-on-disk +++ a/arch/x86_64/Makefile @@ -105,9 +105,14 @@ bzdisk: vmlinux fdimage fdimage144 fdimage288 isoimage: vmlinux $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(BOOTIMAGE) $@ -install: +install: vdso_install $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(BOOTIMAGE) $@ +vdso_install: +ifeq ($(CONFIG_IA32_EMULATION),y) + $(Q)$(MAKE) $(build)=arch/x86_64/ia32 $@ +endif + archclean: $(Q)$(MAKE) $(clean)=$(boot) diff -puN arch/x86_64/ia32/Makefile~x86_64-ia32-vdso-install-unstripped-copies-on-disk arch/x86_64/ia32/Makefile --- a/arch/x86_64/ia32/Makefile~x86_64-ia32-vdso-install-unstripped-copies-on-disk +++ a/arch/x86_64/ia32/Makefile @@ -18,18 +18,35 @@ $(obj)/syscall32_syscall.o: \ $(foreach F,sysenter syscall,$(obj)/vsyscall-$F.so) # Teach kbuild about targets -targets := $(foreach F,sysenter syscall,vsyscall-$F.o vsyscall-$F.so) +targets := $(foreach F,$(addprefix vsyscall-,sysenter syscall),\ +$F.o $F.so $F.so.dbg) # The DSO images are built using a special linker script quiet_cmd_syscall = SYSCALL $@ - cmd_syscall = $(CC) -m32 -nostdlib -shared -s \ + cmd_syscall = $(CC) -m32 -nostdlib -shared \ $(call ld-option, -Wl$(comma)--hash-style=sysv) \ -Wl,-soname=linux-gate.so.1 -o $@ \ -Wl,-T,$(filter-out FORCE,$^) -$(obj)/vsyscall-sysenter.so $(obj)/vsyscall-syscall.so: \ -$(obj)/vsyscall-%.so: $(src)/vsyscall.lds $(obj)/vsyscall-%.o FORCE +$(obj)/%.so: OBJCOPYFLAGS := -S +$(obj)/%.so: $(obj)/%.so.dbg FORCE + $(call if_changed,objcopy) + +$(obj)/vsyscall-sysenter.so.dbg $(obj)/vsyscall-syscall.so.dbg: \ +$(obj)/vsyscall-%.so.dbg: $(src)/vsyscall.lds $(obj)/vsyscall-%.o FORCE $(call if_changed,syscall) AFLAGS_vsyscall-sysenter.o = -m32 -Wa,-32 AFLAGS_vsyscall-syscall.o = -m32 -Wa,-32 + +vdsos := vdso32-sysenter.so vdso32-syscall.so + +quiet_cmd_vdso_install = INSTALL $@ + cmd_vdso_install = cp $(@:vdso32-%.so=$(obj)/vsyscall-%.so.dbg) \ + $(MODLIB)/vdso/$@ + +$(vdsos): + @mkdir -p $(MODLIB)/vdso + $(call cmd,vdso_install) + +vdso_install: $(vdsos) - 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] i386 vDSO: install unstripped copies on disk
While integrating these with the Fedora kernel build, I worked out a few kinks. This patch replaces i386-vdso-install-unstripped-copies-on-disk.patch and i386-vdso-install-unstripped-copies-on-disk-fix.patch Thanks, Roland --- This keeps an unstripped copy of the vDSO images built before they are stripped and embedded in the kernel. The unstripped copies get installed in $(MODLIB)/vdso/ by "make install" (or you can explicitly use the subtarget "make vdso_install"). These files can be useful when they contain source-level debugging information. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> Cc: Sam Ravnborg <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> --- arch/i386/Makefile|1 + arch/i386/kernel/Makefile | 27 ++- 2 files changed, 23 insertions(+), 5 deletions(-) diff -puN arch/i386/Makefile~i386-vdso-install-unstripped-copies-on-disk arch/i386/Makefile --- a/arch/i386/Makefile~i386-vdso-install-unstripped-copies-on-disk +++ a/arch/i386/Makefile @@ -141,9 +141,12 @@ zdisk bzdisk: vmlinux fdimage fdimage144 fdimage288 isoimage: vmlinux $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) $@ -install: +install: vdso_install $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install +vdso_install: + $(Q)$(MAKE) $(build)=arch/i386/kernel vdso_install + archclean: $(Q)$(MAKE) $(clean)=arch/i386/boot diff -puN arch/i386/kernel/Makefile~i386-vdso-install-unstripped-copies-on-disk arch/i386/kernel/Makefile --- a/arch/i386/kernel/Makefile~i386-vdso-install-unstripped-copies-on-disk +++ a/arch/i386/kernel/Makefile @@ -52,7 +52,8 @@ obj-$(CONFIG_SCx200) += scx200.o # We must build both images before we can assemble it. # Note: kbuild does not track this dependency due to usage of .incbin $(obj)/vsyscall.o: $(obj)/vsyscall-int80.so $(obj)/vsyscall-sysenter.so -targets += $(foreach F,int80 sysenter,vsyscall-$F.o vsyscall-$F.so) +targets += $(foreach F,$(addprefix vsyscall-,int80 sysenter),\ +$F.o $F.so $F.so.dbg) targets += vsyscall-note.o vsyscall.lds # The DSO images are built using a special linker script. @@ -62,16 +63,32 @@ quiet_cmd_syscall = SYSCALL $@ export CPPFLAGS_vsyscall.lds += -P -C -U$(ARCH) -vsyscall-flags = -shared -s -Wl,-soname=linux-gate.so.1 \ +vsyscall-flags = -shared -Wl,-soname=linux-gate.so.1 \ $(call ld-option, -Wl$(comma)--hash-style=sysv) -SYSCFLAGS_vsyscall-sysenter.so = $(vsyscall-flags) -SYSCFLAGS_vsyscall-int80.so= $(vsyscall-flags) +SYSCFLAGS_vsyscall-sysenter.so.dbg = $(vsyscall-flags) +SYSCFLAGS_vsyscall-int80.so.dbg= $(vsyscall-flags) -$(obj)/vsyscall-int80.so $(obj)/vsyscall-sysenter.so: \ -$(obj)/vsyscall-%.so: $(src)/vsyscall.lds \ - $(obj)/vsyscall-%.o $(obj)/vsyscall-note.o FORCE +$(obj)/vsyscall-int80.so.dbg $(obj)/vsyscall-sysenter.so.dbg: \ +$(obj)/vsyscall-%.so.dbg: $(src)/vsyscall.lds \ + $(obj)/vsyscall-%.o $(obj)/vsyscall-note.o FORCE $(call if_changed,syscall) +$(obj)/%.so: OBJCOPYFLAGS := -S +$(obj)/%.so: $(obj)/%.so.dbg FORCE + $(call if_changed,objcopy) + +vdsos := vdso-int80.so vdso-sysenter.so + +quiet_cmd_vdso_install = INSTALL $@ + cmd_vdso_install = cp $(@:vdso-%.so=$(obj)/vsyscall-%.so.dbg) \ + $(MODLIB)/vdso/$@ + +$(vdsos): + @mkdir -p $(MODLIB)/vdso + $(call cmd,vdso_install) + +vdso_install: $(vdsos) + # We also create a special relocatable object that should mirror the symbol # table and layout of the linked DSO. With ld -R we can then refer to # these symbols in the kernel code rather than hand-coded addresses. - 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] powerpc vDSO: install unstripped copies on disk
While integrating these with the Fedora kernel build, I worked out a few kinks. This patch replaces powerpc-vdso-install-unstripped-copies-on-disk.patch Thanks, Roland --- This keeps an unstripped copy of the vDSO images built before they are stripped and embedded in the kernel. The unstripped copies get installed in $(MODLIB)/vdso/ by "make install" (or you can explicitly use the subtarget "make vdso_install"). These files can be useful when they contain source-level debugging information. Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> Cc: Sam Ravnborg <[EMAIL PROTECTED]> Cc: Paul Mackerras <[EMAIL PROTECTED]> Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- arch/powerpc/Makefile |5 - arch/powerpc/kernel/vdso32/Makefile | 20 +--- arch/powerpc/kernel/vdso64/Makefile | 19 --- 3 files changed, 37 insertions(+), 7 deletions(-) diff -puN arch/powerpc/Makefile~powerpc-vdso-install-unstripped-copies-on-disk arch/powerpc/Makefile --- a/arch/powerpc/Makefile~powerpc-vdso-install-unstripped-copies-on-disk +++ a/arch/powerpc/Makefile @@ -166,9 +166,15 @@ define archhelp @echo ' *_defconfig - Select default config from arch/$(ARCH)/configs' endef -install: +install: vdso_install $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install +vdso_install: +ifeq ($(CONFIG_PPC64),y) + $(Q)$(MAKE) $(build)=arch/$(ARCH)/kernel/vdso64 $@ +endif + $(Q)$(MAKE) $(build)=arch/$(ARCH)/kernel/vdso32 $@ + archclean: $(Q)$(MAKE) $(clean)=$(boot) diff -puN arch/powerpc/kernel/vdso32/Makefile~powerpc-vdso-install-unstripped-copies-on-disk arch/powerpc/kernel/vdso32/Makefile --- a/arch/powerpc/kernel/vdso32/Makefile~powerpc-vdso-install-unstripped-copies-on-disk +++ a/arch/powerpc/kernel/vdso32/Makefile @@ -9,11 +9,11 @@ ifeq ($(CONFIG_PPC32),y) CROSS32CC := $(CC) endif -targets := $(obj-vdso32) vdso32.so +targets := $(obj-vdso32) vdso32.so vdso32.so.dbg obj-vdso32 := $(addprefix $(obj)/, $(obj-vdso32)) -EXTRA_CFLAGS := -shared -s -fno-common -fno-builtin +EXTRA_CFLAGS := -shared -fno-common -fno-builtin EXTRA_CFLAGS += -nostdlib -Wl,-soname=linux-vdso32.so.1 \ $(call ld-option, -Wl$(comma)--hash-style=sysv) EXTRA_AFLAGS := -D__VDSO32__ -s @@ -26,9 +26,14 @@ CPPFLAGS_vdso32.lds += -P -C -Upowerpc $(obj)/vdso32_wrapper.o : $(obj)/vdso32.so # link rule for the .so file, .lds has to be first -$(obj)/vdso32.so: $(src)/vdso32.lds $(obj-vdso32) +$(obj)/vdso32.so.dbg: $(src)/vdso32.lds $(obj-vdso32) $(call if_changed,vdso32ld) +# strip rule for the .so file +$(obj)/%.so: OBJCOPYFLAGS := -S +$(obj)/%.so: $(obj)/%.so.dbg FORCE + $(call if_changed,objcopy) + # assembly rules for the .S files $(obj-vdso32): %.o: %.S $(call if_changed_dep,vdso32as) @@ -39,3 +44,12 @@ quiet_cmd_vdso32ld = VDSO32L $@ quiet_cmd_vdso32as = VDSO32A $@ cmd_vdso32as = $(CROSS32CC) $(a_flags) -c -o $@ $< +# install commands for the unstripped file +quiet_cmd_vdso_install = INSTALL $@ + cmd_vdso_install = cp $(obj)/[EMAIL PROTECTED] $(MODLIB)/vdso/$@ + +vdso32.so: $(obj)/vdso32.so.dbg + @mkdir -p $(MODLIB)/vdso + $(call cmd,vdso_install) + +vdso_install: vdso32.so diff -puN arch/powerpc/kernel/vdso64/Makefile~powerpc-vdso-install-unstripped-copies-on-disk arch/powerpc/kernel/vdso64/Makefile --- a/arch/powerpc/kernel/vdso64/Makefile~powerpc-vdso-install-unstripped-copies-on-disk +++ a/arch/powerpc/kernel/vdso64/Makefile @@ -4,10 +4,10 @@ obj-vdso64 = sigtramp.o gettimeofday.o d # Build rules -targets := $(obj-vdso64) vdso64.so +targets := $(obj-vdso64) vdso64.so vdso64.so.dbg obj-vdso64 := $(addprefix $(obj)/, $(obj-vdso64)) -EXTRA_CFLAGS := -shared -s -fno-common -fno-builtin +EXTRA_CFLAGS := -shared -fno-common -fno-builtin EXTRA_CFLAGS += -nostdlib -Wl,-soname=linux-vdso64.so.1 \ $(call ld-option, -Wl$(comma)--hash-style=sysv) EXTRA_AFLAGS := -D__VDSO64__ -s @@ -20,9 +20,14 @@ CPPFLAGS_vdso64.lds += -P -C -U$(ARCH) $(obj)/vdso64_wrapper.o : $(obj)/vdso64.so # link rule for the .so file, .lds has to be first -$(obj)/vdso64.so: $(src)/vdso64.lds $(obj-vdso64) +$(obj)/vdso64.so.dbg: $(src)/vdso64.lds $(obj-vdso64) $(call if_changed,vdso64ld) +# strip rule for the .so file +$(obj)/%.so: OBJCOPYFLAGS := -S +$(obj)/%.so: $(obj)/%.so.dbg FORCE + $(call if_changed,objcopy) + # assembly rules for the .S files $(obj-vdso64): %.o: %.S $(call if_changed_dep,vdso64as) @@ -33,4 +38,12 @@ quiet_cmd_vdso64ld = VDSO64L $@ quiet_cmd_vdso64as = VDSO64A $@ cmd_vdso64as = $(CC) $(a_flags) -c -o $@ $< +# install commands for the unstripped file +quiet_cmd_vdso_install = INSTALL $@ + cmd_vdso_install = cp $(obj)/[EMAIL PROTECTED] $(MODLIB)/vdso/$@ + +vdso64.so: $(obj)/vdso64.so.dbg + @mkdir -p $(MODLIB)/vdso + $(call cmd,vdso_install) +vdso_install: vdso64.so - To unsubscribe from this list: send the
Re: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
Iustin Pop wrote: On Sun, Aug 12, 2007 at 07:03:44PM +0200, Jan Engelhardt wrote: On Aug 12 2007 09:39, [EMAIL PROTECTED] wrote: now, I am not an expert on either option, but three are a couple things that I would question about the DRDB+MD option 1. when the remote machine is down, how does MD deal with it for reads and writes? I suppose it kicks the drive and you'd have to re-add it by hand unless done by a cronjob. Yes, and with a bitmap configured on the raid1, you just resync the blocks that have been written while the connection was down. From my tests, since NBD doesn't have a timeout option, MD hangs in the write to that mirror indefinitely, somewhat like when dealing with a broken IDE driver/chipset/disk. Well, if people would like to see a timeout option, I actually coded up a patch a couple of years ago to do just that, but I never got it into mainline because you can do almost as well by doing a check at user-level (I basically ping the nbd connection periodically and if it fails, I kill -9 the nbd-client). 2. MD over local drive will alternate reads between mirrors (or so I've been told), doing so over the network is wrong. Certainly. In which case you set "write_mostly" (or even write_only, not sure of its name) on the raid component that is nbd. 3. when writing, will MD wait for the network I/O to get the data saved on the backup before returning from the syscall? or can it sync the data out lazily Can't answer this one - ask Neil :) MD has the write-mostly/write-behind options - which help in this case but only up to a certain amount. You can configure write_behind (aka, asynchronous writes) to buffer as much data as you have RAM to hold. At a certain point, presumably, you'd want to just break the mirror and take the hit of doing a resync once your network leg falls too far behind. -- Paul - 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] Smack: Simplified Mandatory Access Control Kernel
On Aug 12, 2007, at 15:41:46, Casey Schaufler wrote: --- Kyle Moffett <[EMAIL PROTECTED]> wrote: On Aug 11, 2007, at 21:21:55, Casey Schaufler wrote: --- Kyle Moffett <[EMAIL PROTECTED]> wrote: I was considering compiling the complete list, but such an exercise would take me at least an hour to do properly and which categories individual permissions should be placed in could be argued for weeks. I will be happy to consider your arguement when you are willing to present the complete argument. Here's my complete argument: Regardless of how you categorize "read", "write", "execute", and "doesnt-need-protection" in your policy language, I can write an SELinux policy and a list of labels which expresses that policy. Moreover, without too much work I can probably write a Perl script to do it for you. On the other hand I can only do that if you tell me exactly how you want to categorize those things, though. In my personal opinion they cannot be reasonably categorized without breaking all sorts of tools or leaving gaping holes; precisely the reason that SELinux uses such a fine-grained list. This identifies an important design philosophy issue, that being what granularity is appropriate. I have no interest in composing a description of Smack at the granularity that SELinux uses. If you have no interest in categorizing the SELinux access vectors, then how do you expect to categorize the LSM hooks, which are almost 1-to-1 mapped with the SELinux access vectors? The point you make, that you need to have that in order to create a policy description, is one of the reasons for Smack. Simplified. Well yes, but a simplified policy is useless if it uses no LSM hooks. I will write you a Perl script which will generate a complete and functionally equivalent SELinux policy (assuming I have enough free time) given a file with your policy language. But I can do this if and only if you tell me which of the SELinux access vectors you care about (In other words, which of the LSM hooks you want to require "read", "write", or "execute" privileges for). With such a little script you could write all the "simplified" policy you want, without having to change the kernel code at all. Ok, you want sample policy to match your "MLS" sample? For convenience here's one more macro: define(`rx',`r(`$1',`$2') x(`$1',`$2')') type unclass; type c; type s; type ts; rx(c, unclass) rx(s, c) rx(s, unclass) rx(ts, s) rx(ts, c) rx(ts, unclass) In case you don't have the policy you typed into your email, it looks almost identical with a few exceptions for slightly modified syntax: CUnclass rx SC rx SUnclass rx TS S rx TS C rx TS Unclass rx Yup. Your macro invocations look very much like the Smack specification. Your macro definitions are of course unnecessary in Smack, and you really ought to be using the MLS labels SELinux supports, and you need a base policy underneath this. My point is your policy format is SO simple it doesn't even need the SELinux MLS code to handle it. From the way you've described it the base policy (~200 lines) would be *identical* regardless of the entries in your policy language, and the rest could be generated by a script directly from the "C Unclass rx"-type stuff. Whoops, I think I must have smashed the delete key or something while sending. Here's the paragraphs which got elided: Well, yes, but a policy which completely ignores future expandability can't be expanded upon regardless. It would also be very hard to add new policy without a lot of duplication under your system. On the other hand, with SELinux you can very easily add attribute-based policy so adding new capabilities is as simple as sticking existing attributes on newly defined types. For example: type my_log_t, file_type, log_file; type my_log_daemon, daemon; Right there I just gave permission for the logrotate to recycle files labelled my_log_t, which the sysadmin and audit admin can also read (and the audit admin can delete). I also gave permission for my daemon to send SIGCHLD to init, and for init/ initscripts to send it a SIGTERM/SIGQUIT. All without writing a SINGLE policy rule. Basically all of those existing behaviors are found in allow rules built on the "file_type", "log_file", and "daemon" attributes. Ah, now you're refering to the reference policy, right? Yes, precisely. For most of that functionality there are existing attributes and types defined in the reference policy to make custom policy much easier. Furthermore, there are interface files which allow me to say something like "Let this program spawn an Apache daemon in the right domain" with a single line. If I only want to do that when the "httpd" module is loaded I can put the line in an "optional" block. A policy for a basic network daemon with a couple log files, a
Re: [PATCH 3/6] writeback: remove pages_skipped accounting in __block_write_full_page()
On Sun, Aug 12, 2007 at 05:11:23PM +0800, Fengguang Wu wrote: > Miklos Szeredi <[EMAIL PROTECTED]> and me identified a writeback bug: > Basicly they are > - during the dd: ~16M > - after 30s: ~4M > - after 5s: ~4M > - after 5s: ~176M > > The box has 2G memory. > > Question 1: > How come the 5s delays? I run 4 tests in total, 2 of which have such 5s > delays. pdflush runs every five seconds, so that is indicative of the inode being written once for 1024 pages, and then delayed to the next pdflush run 5s later. perhaps the inodes aren't moving between the lists exactly the way you think they are... > --- linux-2.6.23-rc2-mm2.orig/fs/buffer.c > +++ linux-2.6.23-rc2-mm2/fs/buffer.c > @@ -1713,7 +1713,6 @@ done: >* The page and buffer_heads can be released at any time from >* here on. >*/ > - wbc->pages_skipped++; /* We didn't write this page */ > } > return err; H - I suspect XFS is going to need a similar fix as well. I'm moving house so I'm not going to get a chance to look at this for a week... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - 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: Error: unsupported relocation against CSRR0
On Sun, Aug 12, 2007 at 05:04:35PM -0400, mike zheng wrote: > Hi All, > > I have "unsupported relocation against" problem, while compiling entry.S in > 2.4 Kernel against e500 core. Does anyone know what is the problem? Is > there any option I missed? Probably means you haven't included the file with the #defines for these SPR values. > /kernel-> powerpc-linux-gnuspe-gcc -m32 -Wp,-MD,arch/ppc/kernel/.entry.o.d > -nostdinc -isystem > /opt/mtwk/usr/local/gcc-3_4-e500-glibc-2.3.4-dp/powerpc-linux-gnuspe/lib/gcc/powerpc-linux-gnuspe/3.4.3/include > -D__KERNEL__ -Iinclude -Iarch/ppc -D__ASSEMBLY__ -Iarch/ppc -Wa,-me500-c > -o arch/ppc/kernel/entry.o arch/ppc/kernel/entry.S > arch/ppc/kernel/entry.S: Assembler messages: > > entry.S:819: Error: unsupported relocation against CSRR0 > entry.S:820: Error: unsupported relocation against CSRR1 > entry.S:888: Error: unsupported relocation against MCSRR0 > entry.S:889: Error: unsupported relocation against MCSRR1 > entry.S:909: Error: unsupported relocation against CSRR0 > entry.S:911: Error: unsupported relocation against CSRR1 > > > > entry.S > > 819 mtspr CSRR0, r11 > 820 mtspr CSRR1, r12 > ___ > Linuxppc-dev mailing list > [EMAIL PROTECTED] > https://ozlabs.org/mailman/listinfo/linuxppc-dev -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson - 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: Driver-level memory management
Hi Michael, On Sunday 12 August 2007, Michael Bourgeous wrote: > I'm working on a driver for older HDTV cards based on the TL880 chip. > These cards typically have 16MB of their own memory, which is > available to me over the PCI bus. Various functions of the card > require me to manage this memory, allocating and freeing chunks of it > as necessary. I can easily include my own allocation and management > code, Ok. > but I'm sure this is a problem that has been solved before. Yes! in your Kconfig select GENERIC_ALLOCATOR in your driver.c #include Code is in lib/genalloc.c, if you like to take a look. Memory for MANAGING free/allocated space is NOT taken from your on-card memory! That allocator is explicitly developed for such use cases. Happy hacking! Best regards Ingo Oeser - 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: [-mm PATCH 8/9] Memory controller add switch to control what type of pages to limit (v4)
> Choose if we want cached pages to be accounted or not. By default both
> are accounted for. A new set of tunables are added.
>
> echo -n 1 > mem_control_type
>
> switches the accounting to account for only mapped pages
>
> echo -n 2 > mem_control_type
>
> switches the behaviour back
MEM_CONTAINER_TYPE_ALL is 3, not 2.
YAMAMOTO Takashi
> +enum {
> + MEM_CONTAINER_TYPE_UNSPEC = 0,
> + MEM_CONTAINER_TYPE_MAPPED,
> + MEM_CONTAINER_TYPE_CACHED,
> + MEM_CONTAINER_TYPE_ALL,
> + MEM_CONTAINER_TYPE_MAX,
> +} mem_control_type;
> +
> +static struct mem_container init_mem_container;
> + mem = rcu_dereference(mm->mem_container);
> + if (mem->control_type == MEM_CONTAINER_TYPE_ALL)
> + return mem_container_charge(page, mm);
> + else
> + 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: [RFC][PATCH] fix for async scsi scan sysfs problem (resend)
On Sat, Aug 11, 2007 at 04:04:54PM +0100, Jurij Smakov wrote: > [Please keep me on CC, as I'm not on LKML.] > I've recently got a Sun Blade 1000 box with a QLA2200 controller, and > I'm bumping into exact same problem with 2.6.22: Please try http://marc.info/?l=linux-scsi=118289275414202 which fixes a number of problems with the async scanning code. -- "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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: [BUGFIX] NULL pointer dereference in __vm_enough_memory()
On Sun, Aug 12, 2007 at 08:21:43PM +0400, Cyrill Gorcunov wrote:
> [Alan Cox - Sun, Aug 12, 2007 at 04:17:44PM +0100]
> | Try this (it compiles but isnt tested). Its a weekend here, the sun is
> | shining, the beach is a short walk, and I have more interesting things to
> | do right now 8)
> |
> |
[...]
> | -int __vm_enough_memory(long pages, int cap_sys_admin)
> | +int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
> | {
> | unsigned long free, allowed;
> |
> | @@ -166,7 +166,7 @@
> |
> | /* Don't let a single process grow too big:
> |leave 3% of the size of this process for other processes */
> | - allowed -= current->mm->total_vm / 32;
> | + allowed -= mm->total_vm / 32;
>
> So mm->total_vm is 0 for __bprm_mm_init case. Is that ok? Or I miss
> something?
Yeah, Alan adds mm to the interfaces and leaves us the question of
"what mm to pass in when current->mm == NULL?" ;)
-
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: [BUGFIX] NULL pointer dereference in __vm_enough_memory()
On 08/12/2007 05:17 PM, Alan Cox wrote: Try this (it compiles but isnt tested). Its a weekend here, the sun is shining, the beach is a short walk, and I have more interesting things to do right now 8) Oh come on, you have a beard. You can't go to the beach. Rene. - 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] [MTD] Fix CFI build error with meaningless nonfunctional .config
On Sun, 2007-08-12 at 18:24 +0200, Ingo Molnar wrote:
> just found another one via randconfig, it fails with:
>
> In file included from drivers/mtd/chips/map_rom.c:16:
> include/linux/mtd/map.h:128:2: error: #error "No bus width supported. What's
> the point?"
>
> config attached below. Because it's so nice to be able to keep a
> randconfig build-test running overnight, i think this needs to be
> fixed too. (even if with just a runtime BUG())
On Fri, 2007-08-10 at 11:50 +0800, David Woodhouse wrote:
> -#error "No bus width supported. What's the point?"
> +#warning "No CONFIG_MTD_MAP_BANK_WIDTH_xx selected. No NOR chip support can
> work"
> +static inline int map_bankwidth(void *map)
> +{
> + BUG();
>
--
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: Distributed storage.
On Tuesday 07 August 2007 13:55, Jens Axboe wrote: > I don't like structure bloat, but I do like nice design. Overloading > is a necessary evil sometimes, though. Even today, there isn't enough > room to hold bi_rw and bi_flags in the same variable on 32-bit archs, > so that concern can be scratched. If you read bio.h, that much is > obvious. Sixteen bits in bi_rw are consumed by queue priority. Is there a reason this lives in struct bio instead of struct request? > If you check up on the iommu virtual merging, you'll understand the > front and back size members. They may smell dubious to you, but > please take the time to understand why it looks the way it does. Virtual merging is only needed at the physical device, so why do these fields live in struct bio instead of struct request? > Changing the number of bvecs is integral to how bio buildup current > works. Right, that is done by bi_vcnt. I meant bi_max_vecs, which you can derive efficiently from BIO_POOL_IDX() provided the bio was allocated in the standard way. This leaves a little bit of clean up to do for bios not allocated from a standard pool. Incidentally, why does the bvl need to be memset to zero on allocation? bi_vcnt already tells you which bvecs are valid and the only field in a bvec that can reasonably default to zero is the offset, which ought to be set set every time a bvec is initialized anyway. > > bi_destructor could be combined. I don't see a lot of users of > > bi_idx, > > bi_idx is integral to partial io completions. Struct request has a remaining submission sector count so what does bi_idx do that is different? > > that looks like a soft target. See what happened to struct page > > when a couple of folks got serious about attacking it, some really > > deep hacks were done to pare off a few bytes here and there. But > > struct bio as a space waster is not nearly in the same ballpark. > > So show some concrete patches and examples, hand waving and > assumptions is just a waste of everyones time. Average struct bio memory footprint ranks near the bottom of the list of things that suck most about Linux storage. At idle I see 8K in use (reserves); during updatedb it spikes occasionally to 50K; under a heavy load generated by ddsnap on a storage box it sometimes goes to 100K with bio throttling in place. Really not moving the needle. On the other hand, vm writeout deadlock ranks smack dab at the top of the list, so that is where the patching effort must go for the forseeable future. Without bio throttling, the ddsnap load can go to 24 MB for struct bio alone. That definitely moves the needle. in short, we save 3,200 times more memory by putting decent throttling in place than by saving an int in struct bio. That said, I did a little analysis to get an idea of where the soft targets are in struct bio, and to get to know the bio layer a little better. Maybe these few hints will get somebody interested enough to look further. > > It would be interesting to see if bi_bdev could be made read only. > > Generally, each stage in the block device stack knows what the next > > stage is going to be, so why do we have to write that in the bio? > > For error reporting from interrupt context? Anyway, if Evgeniy > > wants to do the patch, I will happily unload the task of convincing > > you that random fields are/are not needed in struct bio :-) > > It's a trade off, otherwise you'd have to pass the block device > around a lot. Which costs very little, probably less than trashing an extra field's worth of cache. > And it's, again, a design issue. A bio contains > destination information, that means device/offset/size information. > I'm all for shaving structure bytes where it matters, but not for the > sake of sacrificing code stability or design. I consider struct bio > quite lean and have worked hard to keep it that way. In fact, iirc, > the only addition to struct bio since 2001 is the iommu front/back > size members. And I resisted those for quite a while. You did not comment on the one about putting the bio destructor in the ->endio handler, which looks dead simple. The majority of cases just use the default endio handler and the default destructor. Of the remaining cases, where a specialized destructor is needed, typically a specialized endio handler is too, so combining is free. There are few if any cases where a new specialized endio handler would need to be written. As far as code stability goes, current kernels are horribly unstable in a variety of contexts because of memory deadlock and slowdowns related to the attempt to fix the problem via dirty memory limits. Accurate throttling of bio traffic is one of the two key requirements to fix this instability, the other other is accurate writeout path reserve management, which is only partially addressed by BIO_POOL. Nice to see you jumping in Jens. Now it is over to the other side of the thread where Evgeniy has posted a
Re: [1/1] Block device throttling [Re: Distributed storage.]
Hi Evgeniy,
Sorry for not getting back to you right away, I was on the road with
limited email access. Incidentally, the reason my mails to you keep
bouncing is, your MTA is picky about my mailer's IP reversing to a real
hostname. I will take care of that pretty soon, but for now my direct
mail to you is going to bounce and you will only see the lkml copy.
On Wednesday 08 August 2007 03:17, Evgeniy Polyakov wrote:
> This throttling mechanism allows to limit maximum amount of queued
> bios per physical device. By default it is turned off and old block
> layer behaviour with unlimited number of bios is used. When turned on
> (queue limit is set to something different than -1U via
> blk_set_queue_limit()), generic_make_request() will sleep until there
> is room in the queue. number of bios is increased in
> generic_make_request() and reduced either in bio_endio(), when bio is
> completely processed (bi_size is zero), and recharged from original
> queue when new device is assigned to bio via blk_set_bdev(). All
> oerations are not atomic, since we do not care about precise number
> of bios, but a fact, that we are close or close enough to the limit.
>
> Tested on distributed storage device - with limit of 2 bios it works
> slow :)
it seems to me you need:
- if (q) {
+ if (q && q->bio_limit != -1) {
This patch is short and simple, and will throttle more accurately than
the current simplistic per-request allocation limit. However, it fails
to throttle device mapper devices. This is because no request is
allocated by the device mapper queue method, instead the mapping call
goes straight through to the mapping function. If the mapping function
allocates memory (typically the case) then this resource usage evades
throttling and deadlock becomes a risk.
There are three obvious fixes:
1) Implement bio throttling in each virtual block device
2) Implement bio throttling generically in device mapper
3) Implement bio throttling for all block devices
Number 1 is the approach we currently use in ddsnap, but it is ugly and
repetitious. Number 2 is a possibility, but I favor number 3 because
it is a system-wide solution to a system-wide problem, does not need to
be repeated for every block device that lacks a queue, heads in the
direction of code subtraction, and allows system-wide reserve
accounting.
Your patch is close to the truth, but it needs to throttle at the top
(virtual) end of each block device stack instead of the bottom
(physical) end. It does head in the direction of eliminating your own
deadlock risk indeed, however there are block devices it does not
cover.
Regards,
Daniel
-
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] Smack: Simplified Mandatory Access Control Kernel
Casey Schaufler wrote: > I respect the design decisions that SELinux has made regarding > granularity without agreeing with them myself. > It isn't even an exclusive decision: both design points can be "right", but aimed at different use cases. Which is why LSM exists, so users can decide on an appropriate mechanism. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor - 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: cciss: warning: right shift count >= width of type
On 08/12/2007 10:32 PM, James Bottomley wrote:
On Sun, 2007-08-12 at 07:58 +0100, Al Viro wrote:
On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:
@@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
} else {
c->Request.CDBLen = 16;
c->Request.CDB[1]= 0;
- c->Request.CDB[2]= (start_blk >> 56) & 0xff; //MSB
- c->Request.CDB[3]= (start_blk >> 48) & 0xff;
- c->Request.CDB[4]= (start_blk >> 40) & 0xff;
- c->Request.CDB[5]= (start_blk >> 32) & 0xff;
- c->Request.CDB[6]= (start_blk >> 24) & 0xff;
- c->Request.CDB[7]= (start_blk >> 16) & 0xff;
- c->Request.CDB[8]= (start_blk >> 8) & 0xff;
+ c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff; //MSB
+ c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
+ c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
+ c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
+ c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
+ c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
+ c->Request.CDB[8]= ((u64)start_blk >> 8) & 0xff;
put_unaligned(cpu_to_be64(start_blk), >Request.CDB[2]);
which is what's happening here anyway.
Well ... this was debated a while ago ad nauseam:
http://marc.info/?t=117699555300010
The main objection to what you propose is that it forces the u64
coercion even in the 32 bit start_blk case. The preferred solution as a
result of that debate was simply to us a macro Andrew introduced:
upper_32_bits()
Which will silently replace zero in the non LBD case. I actually
thought this had already been done.
I see. Will assume it's somewhere in the pipeline.
Rene.
-
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 3/4] signalfd: fix interaction with posix-timers
This only affects signalfd and so the core change seems ok vs status quo. I think it would be better overall not to have anyone like signalfd calling dequeue_signal in its current form at all. (The function is too much an internal piece of the core signals code. The SIGNAL_STOP_DEQUEUED code applying for signalfd calls is probably another problem, for example.) Thanks, Roland - 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/5] 4KSTACKS, remove DEBUG_KERNEL dependency for sh
On 13/08/07, Paul Mundt <[EMAIL PROTECTED]> wrote: > On Sun, Aug 12, 2007 at 10:53:23PM +0200, Jesper Juhl wrote: > > > > 4K Stacks is no longer a debug feature, so remove the DEBUG_KERNEL > > dependancy for 4KSTACKS for sh. > > > > While it may no longer be a debugging feature on i386, it certainly is on > sh. It should stay under DEBUG_KERNEL for now. > Ok. That was the kind of clear response I was looking for - thank you Paul. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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 2/5] 4KSTACKS, remove DEBUG_KERNEL dependency for sh
On Sun, Aug 12, 2007 at 10:53:23PM +0200, Jesper Juhl wrote: > > 4K Stacks is no longer a debug feature, so remove the DEBUG_KERNEL > dependancy for 4KSTACKS for sh. > While it may no longer be a debugging feature on i386, it certainly is on sh. It should stay under DEBUG_KERNEL for now. - 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: troubles with r8169
Vadim Dyadkin <[EMAIL PROTECTED]> : [...] > I need help from developers, may be, because I have some troubles with > r8169 card. Which kernel do you use ? -- Ueimor - 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 6/6][RESEND] Avoid possible NULL pointer deref in 3c359 driver
(Resending old patch originally submitted at 1/7-2007 02:19, 04-Aug-2007 20:31)
In xl_freemem(), if dev_if is NULL, the line
struct xl_private *xl_priv =(struct xl_private *)dev->priv;
will cause a NULL pointer dereference. However, if we move
that assignment below the 'if' statement that tests for a NULL
'dev', then that NULL deref can never happen.
It never hurts to be safe :-)
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/tokenring/3c359.c b/drivers/net/tokenring/3c359.c
index e22a3f5..671f4da 100644
--- a/drivers/net/tokenring/3c359.c
+++ b/drivers/net/tokenring/3c359.c
@@ -1044,15 +1044,17 @@ static void xl_freemem(struct net_device *dev)
static irqreturn_t xl_interrupt(int irq, void *dev_id)
{
struct net_device *dev = (struct net_device *)dev_id;
- struct xl_private *xl_priv =(struct xl_private *)dev->priv;
- u8 __iomem * xl_mmio = xl_priv->xl_mmio ;
- u16 intstatus, macstatus ;
+ struct xl_private *xl_priv;
+ u8 __iomem * xl_mmio;
+ u16 intstatus, macstatus;
if (!dev) {
- printk(KERN_WARNING "Device structure dead, aaa !\n") ;
+ printk(KERN_WARNING "3c359: Device structure dead, aaa!\n");
return IRQ_NONE;
}
+ xl_priv = (struct xl_private *)dev->priv;
+ xl_mmio = xl_priv->xl_mmio;
intstatus = readw(xl_mmio + MMIO_INTSTATUS) ;
if (!(intstatus & 1)) /* We didn't generate the interrupt */
-
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/6][RESEND] Emulex FC HBA driver: fix overflow of statically allocated array
(previously send on 09-Aug-2007 20:47)
Hi,
The Coverity checker noticed that we may overrun a statically allocated
array in drivers/scsi/lpfc/lpfc_sli.c::lpfc_sli_hbqbuf_find().
The case is this; In 'struct lpfc_hba' we have
#define LPFC_MAX_HBQS 4
...
struct lpfc_hba {
...
struct hbq_s hbqs[LPFC_MAX_HBQS];
...
};
But then in lpfc_sli_hbqbuf_find() we have this code
hbqno = tag >> 16;
if (hbqno > LPFC_MAX_HBQS)
return NULL;
if 'hbqno' ends up as exactely 4, then we won't return, and then this
list_for_each_entry(d_buf, >hbqs[hbqno].hbq_buffer_list, list) {
will cause an overflow of the statically allocated array at index 4,
since the valid indices are only 0-3.
I propose this patch, that simply changes the 'hbqno > LPFC_MAX_HBQS'
into 'hbqno >= LPFC_MAX_HBQS' as a possible fix.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Acked-by: James Smart <[EMAIL PROTECTED]>
---
drivers/scsi/lpfc/lpfc_sli.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index ce5ff2b..e5337ad 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -675,7 +675,7 @@ lpfc_sli_hbqbuf_find(struct lpfc_hba *phba, uint32_t tag)
uint32_t hbqno;
hbqno = tag >> 16;
- if (hbqno > LPFC_MAX_HBQS)
+ if (hbqno >= LPFC_MAX_HBQS)
return NULL;
list_for_each_entry(d_buf, >hbqs[hbqno].hbq_buffer_list, list) {
-
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 5/6][RESEND] fix tiny spelling error in comment in cfi_cmdset_0001.c
(previously send on 05-Jul-2007 02:18, 04-Aug-2007 20:31) Trivial fix of a spelling error in a comment in cfi_cmdset_0001.c s/ships/chips/ Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c index 2f19fa7..c266ebc 100644 --- a/drivers/mtd/chips/cfi_cmdset_0001.c +++ b/drivers/mtd/chips/cfi_cmdset_0001.c @@ -526,7 +526,7 @@ static int cfi_intelext_partition_fixup(struct mtd_info *mtd, struct cfi_pri_intelext *extp = cfi->cmdset_priv; /* -* Probing of multi-partition flash ships. +* Probing of multi-partition flash chips. * * To support multiple partitions when available, we simply arrange * for each of them to have their own flchip structure even if they - 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/6][RESEND] Reduce size of the xterm-linux.xpm image by 12 bytes.
(previously send on 04-Aug-2007 20:31)
Ok, this is a bit silly (but also a little fun) :-)
In Documentation/ we have the xterm-linux.xpm image.
Now an XPM image is more or less C code, so I thought it would
be fun to look at it like that and put on the CodingStyle and
space use glasses.
I made two changes, none of which change the actual image.
1) I removed two lines that just had empty comments.
2) I brought the 'image_name' declaration into line with how
we commonly write arrays and pointers.
This saves us an astonishing 12 bytes on the file size ;-)
That's a little less data for every future Linux kernel source
user to download - that can't be bad.
Ok, ok, so it does have the drawback of being 99,999% churn and
you could argue that it'll clutter the git history. So if you
don't apply it I won't hate you (too much) ;-)
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
diff --git a/Documentation/xterm-linux.xpm b/Documentation/xterm-linux.xpm
index f469c1a..93cb180 100644
--- a/Documentation/xterm-linux.xpm
+++ b/Documentation/xterm-linux.xpm
@@ -9,10 +9,8 @@
/** Swiss Federal Institute of Technology **/
/** Central Computing Service **/
/*/
-static char * image_name [] = {
-/**/
+static char *image_name[] = {
"64 38 8 1",
-/**/
" s mask c none",
". c gray70",
"X c gray85",
-
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: beeping patch for debugging acpi sleep
On Thu, Jun 28, 2007 at 02:08:15PM +, Pavel Machek wrote: > > > The results are a bit unclear, I took a 2.6.22-rc4 with beep. > > > Logged into KDE. > > > (hardware: Dell Latitude D810) > > > > > > S = successfull resume > > > D = had to resume 2 times, that means when pressing the power button the > > > LED goes from blinking to on and after a few seconds it goes back to > > > blinking, but without a beep in between; after pressing the power button > > > a second time resume is successfull > > > F = resume failes, NO beep > > > > > > -run 1: D D F > > > -run 2: D D D(some X garbadge) F > > > -run 3: S S S S S S F > > > -run 4: S S F > > > -run 5: D F [..] > It may well be different problem :-(. 100KB diff and I'm not an acpi > expert :-(. > > I just discovered I have problems with s2ram, too, but it looks like > usermodehelper is responsible. Now i think it is a userspace problem, more exactly something in KDE. I got a new laptop(a Dell D830) and discovered that suspend works with gnome and when i directly run /etc/acpi/sleep.sh. (with KDE running, from a xterm... but so somehow it can't interact with the KDE userspace stuff) (i have no remote idea what KDE is doing) So i tried sleep.sh also on my old laptop (D810) once again and it works reliable, well at least for 13 times. Directly afterwards i tried the suspend to ram button again and it failed again as stated above. Can someone else with suspend problems and KDE verify this? i filled a bug against KDE in ubuntu: https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/131855 Christian Leber -- You are searching some interesting studies? http://www.ziti.uni-heidelberg.de/ :-) - 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: When to use a freezeable workqueue?
On Sunday, 12 August 2007 10:11, Stefan Richter wrote: > In which situations is create_freezeable_workqueue() to be preferred > over create_singlethread_workqueue()? > > Is a freezable worqueue preferable whenever the worker thread /can/ be > frozen, or is it only to be used if the thread /must/ be frozen during > suspend? The latter, IMO. Generally, if you want it to be frozen. Greetings, Rafael - 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: encrypted hibernation (was Re: Hibernation considerations)
On Sunday, 12 August 2007 01:43, Dr. David Alan Gilbert wrote: > * Pavel Machek ([EMAIL PROTECTED]) wrote: > > Hi! > > > > > > > Two things which I think would be nice to consider are: > > > > >1) Encryption - I'd actually prefer if my luks device did not > > > > >remember the key accross a hibernation; Why exactly (assuming that the hibernation image is encrypted)? Greetings, Rafael - 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] Minor fix to Documentation/powerpc/00-INDEX
On Sun, 12 Aug 2007 22:16:43 +0200 Jesper Juhl wrote: > On 12/08/07, Rob Landley <[EMAIL PROTECTED]> wrote: > > On Saturday 11 August 2007 4:33:34 pm Randy Dunlap wrote: > > > On Thu, 9 Aug 2007 23:42:35 -0500 Rob Landley wrote: > > > > Signed-off-by: Rob Landley <[EMAIL PROTECTED]> > > > > > > > > I have a python script to convert 00-INDEX files into index.html files, > > > > and a second script to show 404 errors in the result as well as > > > > files/directories nothing links to. (It's not very useful yet, but in > > > > case you're wondering http://kernel.org/doc/docdiridx.py and > > > > http://kernel.org/doc/doclinkcheck.py .) > > > > > > > > Anyway, my simple index.html generator breaks on the > > > > Documentation/powerpc directory because one of the description lines is > > > > two lines long. This patch joins those two lines together into one > > > > line. > > > > This is the only instance (so far) of this problem. > > > > > > If Paul wants to merge this, then OK, but I'm not aware of any rule > > > that the file descriptions inside INDEX files must be only one line > > > long... is that documented somewhere? (if so, where?) > > > > Documentation/00-INDEX line 5: > > > > > Please try and keep the descriptions small enough to fit on one line. OK :) > > There was only one instance of it not being the case. I can use indentation > > level instead (which is what Kconfig uses to identify help text, so I'm not > > leaking pythonisms into the kernel that aren't already there), but the one > > line thing seemed to be an existing standard. > > > The two times that I've done some big updates to > Documentation/00-INDEX I've also stuck to one line for each > description since that was the only form I'd ever seen - I didn't know > if it was a rule or not, but it seemed pretty sensible for an index. > It's also the form I've stuck to for the new files I send patches for > recently. > > So for whatever my oppinion is worth; I think we may as well make it a > rule for the 00-INDEX files. I think that it's a reasonable rule. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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/5] Add some missing Documentation/*/00-INDEX files
Rob Landley wrote: > On Sunday 12 August 2007 3:17:38 pm Stefan Richter wrote: >> - it's a little bit faster to create these headers than to add them >> to 00-INDEX: Just move the existing title to the top. ... > What variant of "fast" do you mean? Processing the entire directory takes a > fraction of a second on my laptop. I meant the speed of people, not the speed of text processors. -- 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/
Re: [PATCH] Smack: Simplified Mandatory Access Control Kernel
--- Andi Kleen <[EMAIL PROTECTED]> wrote: > On Sun, Aug 12, 2007 at 10:48:05AM -0700, Casey Schaufler wrote: > > > > --- Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > > > Entries are never deleted, although they can be modified. > > > > > > The modification case still seems racy then. > > > > Fair enough. I'll look into real list management. > > You don't necessarily need more list management if you don't > plan to remove entries, but just replace them. > > e.g. what could work to atomically replace is: > > - Make the buffer a pointer to an allocated buffer that also > contains a struct rcu_head. > - Reader: Does rcu_read_lock() around list walk (that just disables > preemption on preemptible kernels and is otherwise a nop). > Also uses rcu_reference for reading the pointer. > - Writer: Continues using the mutex to protect against other writers. > When changing an entry allocate a new buffer + rcu_head. Initialize > buffer. Replace pointer. Free old buffer using call_rcu() > > The RCU would just make sure the buffer is not freed while other > CPUs are still accessing it. It also means they can use stale > rules for a time, but it is a strictly bounded time > (bounded to max time walking the list plus max time any interrupt > handlers inbetween run [admittedly that can be very long in theory, > but it's all logically only a single rule check]) Thank you. You have no idea how helpful that little suggestion was. Casey Schaufler [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/
Kernel 2.6.23-rc2 git4 & git5
This morning I reported an issue which cause a failure of the 2.6.23-rc2-git4 kernel to boot on my system. The contents of my post may be viewed here: http://www.ussg.iu.edu/hypermail/linux/kernel/0708.1/1959.html After 3 separate builds from "virgin sources" I still had the boot failure with the git4 level kernel. This afternoon I picked up the git5 patch and it comes up and appears to run without problem. Same base system. Same hardware. Same build process. So even though I have only been building and running "pre-release" kernels for a short time I feel confident in saying that something was not kosher with the git4 patch - at least when it came to my system. (system configuration data is in the original post) I would not normally burn the valuable time of others with a rhetorical post but I looked at the changes out into the git5 patch and did not spot anything that looked like it would have resolved the issue I was having and I hate not being able to correlate a cause and effect here. Any clues, or did I just get lucky with this one? - 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] Smack: Simplified Mandatory Access Control Kernel
On Sun, Aug 12, 2007 at 10:48:05AM -0700, Casey Schaufler wrote: > > --- Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > Entries are never deleted, although they can be modified. > > > > The modification case still seems racy then. > > Fair enough. I'll look into real list management. You don't necessarily need more list management if you don't plan to remove entries, but just replace them. e.g. what could work to atomically replace is: - Make the buffer a pointer to an allocated buffer that also contains a struct rcu_head. - Reader: Does rcu_read_lock() around list walk (that just disables preemption on preemptible kernels and is otherwise a nop). Also uses rcu_reference for reading the pointer. - Writer: Continues using the mutex to protect against other writers. When changing an entry allocate a new buffer + rcu_head. Initialize buffer. Replace pointer. Free old buffer using call_rcu() The RCU would just make sure the buffer is not freed while other CPUs are still accessing it. It also means they can use stale rules for a time, but it is a strictly bounded time (bounded to max time walking the list plus max time any interrupt handlers inbetween run [admittedly that can be very long in theory, but it's all logically only a single rule check]) -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/
Re: Finding out socket/pipe connectivity status
On Aug 12 2007 19:42, Alan Cox wrote: >> write(stdout, request); >> /* reference point [A] */ >> read(stdin, response); >> >> So my idea had been to launch another thread that monitors stdin for >> 'breakage' and unmount the fs before a user can start an operation on >> myfs. So I've been trying to complete the idea to code. You say a >> broken socket raises the read flag, so: > >Your connection can break at any point even mid-write so you must handle >it. You have no real choice. Yes, of course. I was just saying that when the filesystem is in an operation, `df` -> sys_statvfs() -> [fuse magic] -> my_fuse_fs_statfs() I cannot cancel that operation in a way such that df (or /proc/mounts if you like) does not show the mount anymore when the peer is dead. I have to return something. I am fine with that. >You can try and spot it earlier by using select/poll and checking for >error. In which case I'd use poll() as it is a bit more clear about what >event you get > >Then poll stdin and stdout. The kernel will give you back > >POLLERR - an error condition >POLLHUP - a hangup > >if at the point you poll an error has already occurred. You can do this >with select and the socket error and related stuff buts its uglier poll() alone seems to do just what I want, thank you very much. When the socket breaks, poll raises POLLIN, POLLHUP and POLLRDHUP, but not POLLERR. What exactly is the difference between HUP and RDHUP? The manpage is not too verbose on that. (A guess would be that RDHUP is only for sockets, not pipes.) thanks, Jan -- - 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/8] Immediate Values
* Arjan van de Ven ([EMAIL PROTECTED]) wrote: > > > > > > I have a concern; you seem to be patching potentially "live" code > > > > > > there are basically two options > > > 1) you run the risk of triple faulting (patching an instruction while > > > some other core/cpu may be decoding it may cause a triple fault) > > > 2) you do an IPI to all other cpus and prevent them from executing any > > > code except a small loop during the patching... this is expensive. > > > > > > To be honest, neither sound very attractive to me ;( > > > > > > > Yup, the concern is appropriate. That's why I dealt with it in the > > "Immediate Values - i386 Optimization" patch. (I guess your concern > > is specific to i386, x86_64 and ia64). > > it's specific to all smp architectures I suppose I would wait to see the references before doing such presumptions.. AFAIK, powerpc does not suffer from such problems. I have also seen nothing of this kind about AMD processors, so it seems to be Intel specific. > > > > I have currently only implemented the i386 optimization, but x86_64 and > > ia64 should be similar. > > > > The triple fault in question is discussed in Intel's errata under the > > title "Centrino Duo Processor Technology Specification Update, AH33. > > Unsynchronized Cross-Modifying Code Operations Can Cause Unexpected > > Instruction Execution Results." (if you refer to something else, please > > tell me). > > Core2DUO is only one generation of Intel processors; however I know that > several other (if not all of them) have issues with this kind of thing > in ring 0; all subtly different ;( > Yes, this errata can be found starting at the Pentium III (as explained in my patch). Can you elaborate a little more on the differences ? From what I have seem, the basic problem is always the same from PIII to core2 Duo: instruction prefetch. > All other alternatives are ok right now (they all run in UP mode), > but... I'm just very nervous about the amount of CPU errata in this kind > of scenario. And I'm not just talking Intel, I wouldn't be surprised if > the other x86 CPU vendors also have issues with this; I don't know how > well they specify their errata though.. > > You seem to be pointing out to a lot of erratas, when there is, from what I reckon, only one (basically the same) from PIII to Core 2 Duo, which is Intel specific. I have looked around and ia64 also seems to be affected by this. Can you point us out to other documentation sources please ? Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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/5] Add some missing Documentation/*/00-INDEX files
On Sunday 12 August 2007 3:17:38 pm Stefan Richter wrote: > > This heuristic seems to need about as much cleanup as just fixing > > 00-INDEX.txt in all the directories. > > I didn't think of heuristics but rather of a style guideline. Maybe > prepend this metadata line with "Subject: " or so to distinguish it from > data. That's just extra markup for me to filter out. Either the first line nonblank has a special meaning or it doesn't. Currently, it doesn't. > What's the difference to 00-INDEX? It's inline. Hence, > - as soon as a majority of files have that header, authors of new > files will start to provide that header automatically. Or am I too > optimistic? You're too optimistic, but if it's something we can check automatically we can find and fix instances that don't. (Although in this case "automatic" means we generate the index, put it on the web, and either we notice mistakes or people point them out to us.) > - it's a little bit faster to create these headers than to add them > to 00-INDEX: Just move the existing title to the top. You are aware that some of the files in Documentation aren't text, right? There's example code in C, there's docbook, there's a gif and an xpm... What variant of "fast" do you mean? Processing the entire directory takes a fraction of a second on my laptop. I'm not really invested in 00-INDEX, but I point out that it currently exists and I've indicated a willingness to do work to update it. If you want to do your own work to update something else, be my guest. I'll be over here. > There could also be "From: " and/or "Cc: " headers for authorship and > maintainership metadata. You're adding complexity again. Why are you adding complexity? > (Of course maintainership metadata could also > go into extra files like 00-INDEX or MAINTAINERS. 00-INDEX is a bad place for it, and MAINTAINERS hasn't go the granularity. > Authorship metadata > of more recent documentation files is actually available in the source > control system.) I was wondering if this would be noticed... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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: Use of directories to hold root?
Jan Engelhardt wrote: > On Aug 12 2007 21:23, Al Viro wrote: >>> pivot_root is atomic afaict, for `mount --move` (which I think Al meant >>> which MS_MOVE - or some C program using mount(2) of your own), you'd >>> need multiple calls to mount. >> Move itself is done by a single syscall anyway... >> > Yes, but you need needed 2 mounts, 1 chdir and one chroot. Plus, you > have not freed the data in the rootfs. (Well, neither does > pivot_root, but run-init from klibc will.) Yes, which is why it is highly inappropriate for this particular case, since they have multiple roots that they presumably don't want deleted! -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: [patch 0/8] Immediate Values
> > > > I have a concern; you seem to be patching potentially "live" code > > > > there are basically two options > > 1) you run the risk of triple faulting (patching an instruction while > > some other core/cpu may be decoding it may cause a triple fault) > > 2) you do an IPI to all other cpus and prevent them from executing any > > code except a small loop during the patching... this is expensive. > > > > To be honest, neither sound very attractive to me ;( > > > > Yup, the concern is appropriate. That's why I dealt with it in the > "Immediate Values - i386 Optimization" patch. (I guess your concern > is specific to i386, x86_64 and ia64). it's specific to all smp architectures I suppose > > I have currently only implemented the i386 optimization, but x86_64 and > ia64 should be similar. > > The triple fault in question is discussed in Intel's errata under the > title "Centrino Duo Processor Technology Specification Update, AH33. > Unsynchronized Cross-Modifying Code Operations Can Cause Unexpected > Instruction Execution Results." (if you refer to something else, please > tell me). Core2DUO is only one generation of Intel processors; however I know that several other (if not all of them) have issues with this kind of thing in ring 0; all subtly different ;( All other alternatives are ok right now (they all run in UP mode), but... I'm just very nervous about the amount of CPU errata in this kind of scenario. And I'm not just talking Intel, I wouldn't be surprised if the other x86 CPU vendors also have issues with this; I don't know how well they specify their errata though.. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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: troubles with r8169
Alistair John Strachan пишет: >> Thank for your answer. This problem never shows up if I use only nvidia >> driver (the work without network), or if I use only r8169 (without >> x.org). If I use both of them I have the hang. Usually the hang appears >> if OpenGL is used or network rate is maximal. I tested this regimes many >> times before. > > If you haven't already, I'd drop [EMAIL PROTECTED] an email to see if they > have any insight. I haven't done it yet. I'm going to do it. > Not that this can't be a kernel bug, just that it's a bit > difficult for kernel developers to debug when you're using a driver for which > we don't have the sources. > > As for changing the IRQ assignments, I don't have any immediate suggestions. > I > notice that this laptop has a dual core processor, so I'm guessing disabling > APIC isn't an option. Have you tried that anyway, just to see if the IRQ > assignment differs? If I've correctly understood your suggestion I should load kernel with 'noapic' option. In that case the situation even worse: ** CPU0 CPU1 0: 106543 11922XT-PIC-XTtimer 1: 53 8XT-PIC-XTi8042 2: 0 0XT-PIC-XTcascade 5: 0 0XT-PIC-XTsdhci:slot0 7: 14250 126092XT-PIC-XTehci_hcd:usb2 8: 2 0XT-PIC-XTrtc 9: 1168190XT-PIC-XTacpi 10:338181XT-PIC-XTHDA Intel 11: 7167 1052XT-PIC-XTohci_hcd:usb1, yenta, eth0, nvidia 12:123 9XT-PIC-XTi8042 14: 19 32XT-PIC-XTide0 15: 10936 1112XT-PIC-XTide1 NMI: 0 0 LOC: 11921 106401 ERR: 41370 MIS: 0 *** Now, pcmcia and usb 1.1 share the same IRQ. Plus, dmesg says: * irq 7: nobody cared (try booting with the "irqpoll" option) [] __report_bad_irq+0x24/0x80 [] note_interrupt+0x226/0x260 [] usb_hcd_irq+0x2b/0x60 [usbcore] [] handle_IRQ_event+0x25/0x50 [] handle_level_irq+0x93/0x100 [] do_IRQ+0x3b/0x70 [] sys_sigreturn+0xce/0xe0 [] common_interrupt+0x23/0x28 === handlers: [] (usb_hcd_irq+0x0/0x60 [usbcore]) Disabling IRQ #7 ** Vadim - 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/5] Add some missing Documentation/*/00-INDEX files
On Sunday 12 August 2007 3:11:06 pm Jesper Juhl wrote: > On 12/08/07, Rob Landley <[EMAIL PROTECTED]> wrote: > > On Sunday 12 August 2007 7:48:37 am Stefan Richter wrote: > > > Isn't it with 00-INDEX just like with the "Last Updated:" footers in > > > documentation texts? > > > > > > They are metadata which will be almost always out of date. > > > > If nothing is using them, they'll bit-rot, yes. Way of the world. But > > I've found a use for them. Therefore, I'm interested in getting them up > > to date and then keeping them there. > > So, do you want me to create more of these? Yes please. > If you want them, could you perhaps start by ACK'ing the first 5 > patches to help me get them merged? Just did. :) > Once I see the first 5 merged I'll start creating more, but I don't > want to waste time doing so before that. Sorry it took so long, but my net access is still a touch intermittent just now. I recently moved back to Austin and we haven't unpacked the wireless router yet. (So although there's internet at home my wife is usually the one using it. I'm out at a wireless laundromat at the moment. Yes, Austin has such things.) > >I already wrote an automatic checker to tell me > > how they differ from reality, which is half the battle. > > I started writing such a script myself yesterday, but it's not done > yet. If you already have one that works could I have a copy please? > That would make my life easier if I'm to help you with this. I posted a link to it in the message at the start of this thread: http://lkml.org/lkml/2007/8/9/584 Here's the release announcement for it: http://marc.info/?l=linux-doc=118671778606001=2 Here's the source control for it: http://landley.net/hg/kdocs/file/tip/make/ You need to run the index.html generator first, because the link checker works on the html and not on 00-INDEX itself. Both scripts expect Documentation to be a subdirectory of the current directory, and do the whole directory. And I need to update it so it filters out index.html, but my laundry's done. :) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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 5/5] 4KSTACKS, make 'default y', -mm patch only.
To get more testing of 4K Stacks, make the feature 'default y'. note: this patch is *NOT* intended for mainline atm, only for -mm. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig index d4988cd..15b1a25 100644 --- a/arch/i386/Kconfig +++ b/arch/i386/Kconfig @@ -924,6 +924,7 @@ config COMPAT_VDSO config 4KSTACKS bool "Use 4Kb for kernel stacks instead of 8Kb" + default y help If you say Y here the kernel will use a 4Kb stacksize for the kernel stack attached to each process/thread. This facilitates - 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/5] 4KSTACKS, move out of Kernel hacking menu (i386)
Since 4KSTACKS is nolonger a debug only feature, move it out of the Kernel Hacking menu (i386). Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig index f952493..d4988cd 100644 --- a/arch/i386/Kconfig +++ b/arch/i386/Kconfig @@ -922,6 +922,15 @@ config COMPAT_VDSO If unsure, say Y. +config 4KSTACKS + bool "Use 4Kb for kernel stacks instead of 8Kb" + help + If you say Y here the kernel will use a 4Kb stacksize for the + kernel stack attached to each process/thread. This facilitates + running more threads on a system and also reduces the pressure + on the VM subsystem for higher order allocations. This option + will also use IRQ stacks to compensate for the reduced stackspace. + endmenu config ARCH_ENABLE_MEMORY_HOTPLUG diff --git a/arch/i386/Kconfig.debug b/arch/i386/Kconfig.debug index 7131a16..90cc3a0 100644 --- a/arch/i386/Kconfig.debug +++ b/arch/i386/Kconfig.debug @@ -56,15 +56,6 @@ config DEBUG_RODATA portion of the kernel code won't be covered by a 2MB TLB anymore. If in doubt, say "N". -config 4KSTACKS - bool "Use 4Kb for kernel stacks instead of 8Kb" - help - If you say Y here the kernel will use a 4Kb stacksize for the - kernel stack attached to each process/thread. This facilitates - running more threads on a system and also reduces the pressure - on the VM subsystem for higher order allocations. This option - will also use IRQ stacks to compensate for the reduced stackspace. - config X86_FIND_SMP_CONFIG bool depends on X86_LOCAL_APIC || X86_VOYAGER - 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/5] 4KSTACKS, move out of Kernel hacking menu (sh)
Since 4KSTACKS is nolonger a debug only feature, move it out of the Kernel Hacking menu (sh). Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 54878f0..43e79f4 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -205,6 +205,15 @@ config CPU_HAS_PTEA config CPU_HAS_DSP bool +config 4KSTACKS + bool "Use 4Kb for kernel stacks instead of 8Kb" + help + If you say Y here the kernel will use a 4Kb stacksize for the + kernel stack attached to each process/thread. This facilitates + running more threads on a system and also reduces the pressure + on the VM subsystem for higher order allocations. This option + will also use IRQ stacks to compensate for the reduced stackspace. + endmenu menu "Board support" diff --git a/arch/sh/Kconfig.debug b/arch/sh/Kconfig.debug index 5bb4bd7..0c2992b 100644 --- a/arch/sh/Kconfig.debug +++ b/arch/sh/Kconfig.debug @@ -72,15 +72,6 @@ config DEBUG_STACK_USAGE This option will slow down process creation somewhat. -config 4KSTACKS - bool "Use 4Kb for kernel stacks instead of 8Kb" - help - If you say Y here the kernel will use a 4Kb stacksize for the - kernel stack attached to each process/thread. This facilitates - running more threads on a system and also reduces the pressure - on the VM subsystem for higher order allocations. This option - will also use IRQ stacks to compensate for the reduced stackspace. - config SH_KGDB bool "Include KGDB kernel debugger" select FRAME_POINTER - 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: splice question
On Sun, Aug 12, 2007 at 12:41:54PM -0700, Linus Torvalds wrote: On Sun, 12 Aug 2007, David H?rdeman wrote: Otherwise I guess I'd have to add a second pipe, then (in a loop) tee() from the first to the second pipe and then splice from the second pipe to a socket. Doesn't sound very elegant and would need quite a lot of extra syscalls. You really should think of this as a memcpy(), and you'll be in the right mindframe. The system calls themselves are cheap. Ok, I've implemented it using two pipes, and it works. But it does seem a bit wasteful...in case one client is not keeping up, the data will have to be tee():ed first from pipe1 to pipe2, only to then find out that the splice() from pipe2 to socket only does a partial transfer after which the data in pipe2 has to be thrown away and then the loop starts over with the next client. A tee() from pipe1 to the socket could (I imagine) realize immediately that the socket does not have enough buffer space and return EWOULDBLOCK and avoid at least one copy? -- David Härdeman - 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/5] 4KSTACKS, remove DEBUG_KERNEL dependency for sh
4K Stacks is no longer a debug feature, so remove the DEBUG_KERNEL dependancy for 4KSTACKS for sh. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- diff --git a/arch/sh/Kconfig.debug b/arch/sh/Kconfig.debug index 52f6a99..5bb4bd7 100644 --- a/arch/sh/Kconfig.debug +++ b/arch/sh/Kconfig.debug @@ -74,7 +74,6 @@ config DEBUG_STACK_USAGE config 4KSTACKS bool "Use 4Kb for kernel stacks instead of 8Kb" - depends on DEBUG_KERNEL help If you say Y here the kernel will use a 4Kb stacksize for the kernel stack attached to each process/thread. This facilitates - 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: Use of directories to hold root?
On Aug 12 2007 21:23, Al Viro wrote: >> >> pivot_root is atomic afaict, for `mount --move` (which I think Al meant >> which MS_MOVE - or some C program using mount(2) of your own), you'd >> need multiple calls to mount. > >Move itself is done by a single syscall anyway... > Yes, but you need needed 2 mounts, 1 chdir and one chroot. Plus, you have not freed the data in the rootfs. (Well, neither does pivot_root, but run-init from klibc will.) Jan -- - 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/5] 4KSTACKS, remove DEBUG_KERNEL dependency for i386
4K Stacks is no longer a debug feature, so remove the DEBUG_KERNEL dependancy for 4KSTACKS for i386. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- diff --git a/arch/i386/Kconfig.debug b/arch/i386/Kconfig.debug index f03531e..7131a16 100644 --- a/arch/i386/Kconfig.debug +++ b/arch/i386/Kconfig.debug @@ -58,7 +58,6 @@ config DEBUG_RODATA config 4KSTACKS bool "Use 4Kb for kernel stacks instead of 8Kb" - depends on DEBUG_KERNEL help If you say Y here the kernel will use a 4Kb stacksize for the kernel stack attached to each process/thread. This facilitates - 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/5] 4KSTACKS no longer a debug feature and doesn't belong in "Kernel hacking".
Hi, The short story: This is a series of 5 patches to a) lift 4KSTACKS from a debug feature to a non-debug feature and b) move it out of the Kernel hacking menu and into the Processor types and features menu and c) make it 'default y', but only for -mm. Some more explanation is probably needed, so here's the longer story: About a month back I posted a RFC patch with the subject "[PATCH][RFC] 4K stacks default, not a debug thing any more...?" to find out if I was right in assuming that 4K stacks were no longer considered a debug only feature and whether or not it would be sensible to make them default. You can find the head of the thread (100+ mesages) in the lkml.org archives here: http://lkml.org/lkml/2007/7/11/294 . Based on the comments in that thread I conclude that 4KSTACKS are not really considered a debug-only feature any longer, but the time is not right (yet) to make them the default - and it's certainly not yet the time to get rid of 8K stacks. In that thread I promised to provide some patches that would lift 4KSTACKS out of debug-only feature status, which is what the first two patches in this series do. I also said I would provide a patch to make 4KSTACKS 'default y' to get more testing, but restrict that patch to -mm - that's the fifth patch in this series. Patches 3 & 4 in this series move the config option out of the Kernel hacking menu and into Processor types and features - this makes sense once it is no longer a debug feature and the location is in line with m68knommu (which is the only arch with this config symbol in addition to i386 & sh) which already place that symbol there. Now for a bit on the actual patches. These are the patches in this series : [PATCH 1/5] 4KSTACKS, remove DEBUG_KERNEL dependency for i386 [PATCH 2/5] 4KSTACKS, remove DEBUG_KERNEL dependency for sh [PATCH 3/5] 4KSTACKS, move out of Kernel hacking menu (i386) [PATCH 4/5] 4KSTACKS, move out of Kernel hacking menu (sh) [PATCH 5/5] 4KSTACKS, make 'default y', -mm patch only. Andrew; as i386 & -mm maintainer I'm sending you patches 1, 3 & 5 - patches 2 & 4 for Super-H I would like a maintainer ACK on before they go further, so I'm not Cc'ing you on those (they are on LKML if you want them anyway). Paul; in the thread I mention above I was focusing 100% on i386. I don't really know the status of 4KSTACKS on sh, so I'd like your input. I'm adding a few people from the previous thread to Cc, but far from everyone as then the Cc list would become too big. For the patches themselves I'm just sending them to LKML, Andrew & Paul, so pick them up on LKML please (sending as replies to this mail). Kind regards, Jesper Juhl - 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/5] Add some missing Documentation/*/00-INDEX files
On Sunday 12 August 2007 12:10:56 pm Jesper Juhl wrote: > > Isn't it with 00-INDEX just like with the "Last Updated:" footers in > > documentation texts? > > That is certainly a risk, yes. But it shouldn't be hard to write a > small script to check if the 00-INDEX files are up-to-date, that will > make it pretty simple to update them once in a while if people forget. Already done: http://marc.info/?l=linux-doc=118671778606001=2 It checks the index.html files so you have to run http://kernel.org/doc/make/docdiridx.py and then run http://kernel.org/doc/make/doclinkcheck.py afterwards. It shows you the files 00-index links to which aren't there (the 404 errors), and then the files that nothing links to. I notice that I'm not filtering out the generated index.html files, but oh well. I'll fix that... :) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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/5] Add some missing Documentation/*/00-INDEX files
On Saturday 11 August 2007 5:45:02 pm Jesper Juhl wrote: > So please do the ACK/NACK/Merge dance with these patches and > let me know if more are wanted or not. :-) Acked-by: Rob Landley <[EMAIL PROTECTED]> Just tried 'em: they worked for me. :) Thanks, Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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: v2.6.23-rc2 locks up during boot (without acpi=off)
On Sun, 12 Aug 2007, Andrew Morton wrote: > On Sun, 12 Aug 2007 20:15:51 +0300 (EEST) "Ilpo Järvinen" <[EMAIL PROTECTED]> > wrote: > > > Hmm, it was really worth of it, I did: > > $ git-fetch linus > > $ git-reset --hard linus > > [...make & install & boot...] > > > > ...and voila, the problem went away, so something else seems to have > > fixed it between: ac07860264bd and 963c6527e0a0e. As you can notice, > > I didn't even have to revert it (I was just double checking current > > mainline first). > > > > Is there a need to get a more detailed view about the cause or something, > > or are details of this issue clear enough to everyone? I can do some more > > research if necessary, though expect a bit longer latencies during the > > next week... > > > > In case none, thanks everyone, this issue seems solved. :-) > > We just had an acpi commit. Something like > ed3110efb538d7acbf635095c1382118f7414f75 > might have fixed this. ...Yeah, it's very likely the same issue as bisect in that case seemed to end up to the very same commit I found, and it was answered with that fix... -- i.
Re: troubles with r8169
On Sunday 12 August 2007 21:06:43 Vadim Dyadkin wrote: > Robert Hancock пишет: > > This could well be a problem with the nvidia driver as it shares the > > same IRQ. The first step would be to see if the problem still shows up > > without the nvidia binary module loaded. > > Thank for your answer. This problem never shows up if I use only nvidia > driver (the work without network), or if I use only r8169 (without > x.org). If I use both of them I have the hang. Usually the hang appears > if OpenGL is used or network rate is maximal. I tested this regimes many > times before. If you haven't already, I'd drop [EMAIL PROTECTED] an email to see if they have any insight. Not that this can't be a kernel bug, just that it's a bit difficult for kernel developers to debug when you're using a driver for which we don't have the sources. As for changing the IRQ assignments, I don't have any immediate suggestions. I notice that this laptop has a dual core processor, so I'm guessing disabling APIC isn't an option. Have you tried that anyway, just to see if the IRQ assignment differs? -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - 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: cciss: warning: right shift count >= width of type
On Sun, 2007-08-12 at 07:58 +0100, Al Viro wrote:
> On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:
> > @@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
> > } else {
> > c->Request.CDBLen = 16;
> > c->Request.CDB[1]= 0;
> > - c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
> > - c->Request.CDB[3]= (start_blk >> 48) & 0xff;
> > - c->Request.CDB[4]= (start_blk >> 40) & 0xff;
> > - c->Request.CDB[5]= (start_blk >> 32) & 0xff;
> > - c->Request.CDB[6]= (start_blk >> 24) & 0xff;
> > - c->Request.CDB[7]= (start_blk >> 16) & 0xff;
> > - c->Request.CDB[8]= (start_blk >> 8) & 0xff;
> > + c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff;
> > //MSB
> > + c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
> > + c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
> > + c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
> > + c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
> > + c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
> > + c->Request.CDB[8]= ((u64)start_blk >> 8) & 0xff;
>
> put_unaligned(cpu_to_be64(start_blk), >Request.CDB[2]);
>
> which is what's happening here anyway.
Well ... this was debated a while ago ad nauseam:
http://marc.info/?t=117699555300010
The main objection to what you propose is that it forces the u64
coercion even in the 32 bit start_blk case. The preferred solution as a
result of that debate was simply to us a macro Andrew introduced:
upper_32_bits()
Which will silently replace zero in the non LBD case. I actually
thought this had already been done.
James
James
-
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: Use of directories to hold root?
On Sun, Aug 12, 2007 at 09:49:02PM +0200, Jan Engelhardt wrote: > > On Aug 12 2007 15:39, Mark Cannon wrote: > >> >> No, but you can use pivot_root. > >> > > >> >Or better yet, use an initramfs with MS_MOVE; same as you would with the > >> >"normal" use of initramfs. > > > >I am not sure I understand initramfs with MS_MOVE concept. I will look into > >it. Any pointers for documentation? > > pivot_root is atomic afaict, for `mount --move` (which I think Al meant > which MS_MOVE - or some C program using mount(2) of your own), you'd > need multiple calls to mount. Move itself is done by a single syscall anyway... - 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/5] Add some missing Documentation/*/00-INDEX files
Rob Landley wrote: > On Sunday 12 August 2007 12:34:30 pm Stefan Richter wrote: >> Or use the first line of each text file to describe what the file is about. ... > This heuristic seems to need about as much cleanup as just fixing > 00-INDEX.txt > in all the directories. I didn't think of heuristics but rather of a style guideline. Maybe prepend this metadata line with "Subject: " or so to distinguish it from data. What's the difference to 00-INDEX? It's inline. Hence, - as soon as a majority of files have that header, authors of new files will start to provide that header automatically. Or am I too optimistic? - it's a little bit faster to create these headers than to add them to 00-INDEX: Just move the existing title to the top. There could also be "From: " and/or "Cc: " headers for authorship and maintainership metadata. (Of course maintainership metadata could also go into extra files like 00-INDEX or MAINTAINERS. Authorship metadata of more recent documentation files is actually available in the source control system.) >> And BTW, if authors insist on "Last Updated:", make it a header rather >> than a footer. Increases the chance that submitters remember to update it. > > Why not just use the source control system to review the actual revision > history of the file? Just to clarify: I'm *not* one of those who want the date in there. -- 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/
Re: [PATCH] Minor fix to Documentation/powerpc/00-INDEX
On 12/08/07, Rob Landley <[EMAIL PROTECTED]> wrote: > On Saturday 11 August 2007 4:33:34 pm Randy Dunlap wrote: > > On Thu, 9 Aug 2007 23:42:35 -0500 Rob Landley wrote: > > > Signed-off-by: Rob Landley <[EMAIL PROTECTED]> > > > > > > I have a python script to convert 00-INDEX files into index.html files, > > > and a second script to show 404 errors in the result as well as > > > files/directories nothing links to. (It's not very useful yet, but in > > > case you're wondering http://kernel.org/doc/docdiridx.py and > > > http://kernel.org/doc/doclinkcheck.py .) > > > > > > Anyway, my simple index.html generator breaks on the > > > Documentation/powerpc directory because one of the description lines is > > > two lines long. This patch joins those two lines together into one line. > > > This is the only instance (so far) of this problem. > > > > If Paul wants to merge this, then OK, but I'm not aware of any rule > > that the file descriptions inside INDEX files must be only one line > > long... is that documented somewhere? (if so, where?) > > Documentation/00-INDEX line 5: > > > Please try and keep the descriptions small enough to fit on one line. > > There was only one instance of it not being the case. I can use indentation > level instead (which is what Kconfig uses to identify help text, so I'm not > leaking pythonisms into the kernel that aren't already there), but the one > line thing seemed to be an existing standard. > The two times that I've done some big updates to Documentation/00-INDEX I've also stuck to one line for each description since that was the only form I'd ever seen - I didn't know if it was a rule or not, but it seemed pretty sensible for an index. It's also the form I've stuck to for the new files I send patches for recently. So for whatever my oppinion is worth; I think we may as well make it a rule for the 00-INDEX files. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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 3/4] Linux Kernel Markers - Documentation
Mathieu Desnoyers <[EMAIL PROTECTED]> writes: > [...] > +A marker placed in your code provides a hook to call a function (probe) that > +you can provide at runtime. A marker can be "on" (a probe is connected to it) > +or "off" (no probe is attached). When a marker is "off" it has no > +effect. [...] Add something like, ", except for a (how?) small time/space penalty." > +[...] > +trace_mark(subsystem_event, "%d %s", someint, somestring); > +Where : > +- subsystem_event is an identifier unique to your event > +- subsystem is the name of your subsystem. > +- event is the name of the event to mark. > +[...] It would be useful to clarify that this "subsystem_event" scheme is only a suggested naming convention intended to limit collisions. > +Connecting a function (probe) to a marker is done by providing a > probe +(function to call) for the specific marker through > marker_probe_register() and +can be activated by calling > marker_arm(). It would help to spell out the nature of the marker namespace. Is it global to the kernel? Per-module? Are conflicting "subsystem_event" names but different format strings considered separate markers? > + [...] Marker disactivation [...] "deactivation" - FChE - 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/5] Add some missing Documentation/*/00-INDEX files
On 12/08/07, Rob Landley <[EMAIL PROTECTED]> wrote: > On Sunday 12 August 2007 7:48:37 am Stefan Richter wrote: > > Isn't it with 00-INDEX just like with the "Last Updated:" footers in > > documentation texts? > > > > They are metadata which will be almost always out of date. > > If nothing is using them, they'll bit-rot, yes. Way of the world. But I've > found a use for them. Therefore, I'm interested in getting them up to date > and then keeping them there. So, do you want me to create more of these? If you want them, could you perhaps start by ACK'ing the first 5 patches to help me get them merged? Once I see the first 5 merged I'll start creating more, but I don't want to waste time doing so before that. >I already wrote an automatic checker to tell me > how they differ from reality, which is half the battle. I started writing such a script myself yesterday, but it's not done yet. If you already have one that works could I have a copy please? That would make my life easier if I'm to help you with this. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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: troubles with r8169
Robert Hancock пишет: > This could well be a problem with the nvidia driver as it shares the > same IRQ. The first step would be to see if the problem still shows up > without the nvidia binary module loaded. Thank for your answer. This problem never shows up if I use only nvidia driver (the work without network), or if I use only r8169 (without x.org). If I use both of them I have the hang. Usually the hang appears if OpenGL is used or network rate is maximal. I tested this regimes many times before. Vadim - 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/
2.6.23-rc2 swsusp, suddenly increased uptime
Hi, today I saw this (output from my suspend script): -> woke up at Sun Aug 12 11:39:17 CEST 2007 -> uptime is 11:39am up 8 days 0:41, 10 users, load average: 26.12, 6.35, 2.17 Then I did a software suspend. After waking up, I saw this: -> woke up at Sun Aug 12 14:41:56 CEST 2007 -> uptime is 2:41pm up 44 days 9:11, 12 users, load average: 35.17, 9.17, 3.33 my config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc2 # Sat Aug 4 10:53:47 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y # CONFIG_KALLSYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 # CONFIG_HPET_TIMER is not set # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_DMIID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_3G_OPT is not set # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_2G_OPT is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC000 # CONFIG_X86_PAE is not set
Re: [PATCH 0/5] Add some missing Documentation/*/00-INDEX files
On Sunday 12 August 2007 7:48:37 am Stefan Richter wrote: > Isn't it with 00-INDEX just like with the "Last Updated:" footers in > documentation texts? > > They are metadata which will be almost always out of date. If nothing is using them, they'll bit-rot, yes. Way of the world. But I've found a use for them. Therefore, I'm interested in getting them up to date and then keeping them there. I already wrote an automatic checker to tell me how they differ from reality, which is half the battle. (It won't help if the file contents change so much the description needs to be updated, but that's not a common event.) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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: Are we properly prepared to handle 3 Socket setups?
On 08/12/2007 10:35 AM, Andrew Morton wrote: On Sun, 12 Aug 2007 05:17:10 +0200 Rene Herman <[EMAIL PROTECTED]> wrote: The line just below where it does that _does_ seem to have a problem: /* * Maximum threshold is 125 */ threshold = min(125, threshold); as either the comment or the code is wrong and it seems it's the code. Added Andrew Morton to the CC for that. Yes, that's inconsistent. And looking at Christoph's df9ecaba it's unclear whether the comment is wrong or the code is wrong. The code is wrong, I expect. Extremely friendly of you to pretend I wasn't being thick at all but don't worry, I can take it. Anyways, since Christoph wasn't in CC on that one: On 08/12/2007 05:29 AM, Roland Dreier wrote: What's the problem? That line sets threshold to the smaller of the current value or 125, which is exactly what one would want to do if the maximum value is 125. Just do a couple of examples: eg if threshold is 100 going into that line, then the value is left alone; if threshold is 150 then it gets set to 125; and that seems exactly correct. Rene. - 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] Minor fix to Documentation/powerpc/00-INDEX
On Saturday 11 August 2007 4:33:34 pm Randy Dunlap wrote: > On Thu, 9 Aug 2007 23:42:35 -0500 Rob Landley wrote: > > Signed-off-by: Rob Landley <[EMAIL PROTECTED]> > > > > I have a python script to convert 00-INDEX files into index.html files, > > and a second script to show 404 errors in the result as well as > > files/directories nothing links to. (It's not very useful yet, but in > > case you're wondering http://kernel.org/doc/docdiridx.py and > > http://kernel.org/doc/doclinkcheck.py .) > > > > Anyway, my simple index.html generator breaks on the > > Documentation/powerpc directory because one of the description lines is > > two lines long. This patch joins those two lines together into one line. > > This is the only instance (so far) of this problem. > > If Paul wants to merge this, then OK, but I'm not aware of any rule > that the file descriptions inside INDEX files must be only one line > long... is that documented somewhere? (if so, where?) Documentation/00-INDEX line 5: > Please try and keep the descriptions small enough to fit on one line. There was only one instance of it not being the case. I can use indentation level instead (which is what Kconfig uses to identify help text, so I'm not leaking pythonisms into the kernel that aren't already there), but the one line thing seemed to be an existing standard. I'm also relying on the first file in the list being documentation for 00-INDEX itself. (If it breaks, I'll either try to derive a new heuristic and change the script, or submit a patch to change the index. That one would be a more difficult heuristic to replace, though.) > Maybe the script should allow for this? *shrug* I can go either way on that, but people get all funny about whitespace being significant and the one line thing wasn't my idea. :) Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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/4] posix-timers: fix creation race
On 08/12, Oleg Nesterov wrote:
>
> > > -
> > > spin_unlock_irqrestore(>sighand->siglock, flags);
> > > process = NULL;
> > > }
> > > + spin_unlock_irqrestore(>sighand->siglock,
> > > flags);
>
> i'll resend this patch tomorrow. We can't do
> spin_unlock_irqrestore(>...)
> if we set process = NULL above.
Another attempt, no cleanups, just a minimal fix for now.
[PATCH 2/4] posix-timers: fix creation race
sys_timer_create() sets ->it_process and unlocks ->siglock, then checks
tmr->it_sigev_notify to define if get_task_struct() is needed.
We already passed ->it_id to the caller, another thread can delete this
timer and free its memory in between.
As a minimal fix, move this code under ->siglock, sys_timer_delete() takes
it too before calling release_posix_timer(). A proper serialization would
be to take ->it_lock, we add a partly initialized timer on posix_timers_id,
not good.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- t/kernel/posix-timers.c~2007-08-12 23:50:46.0 +0400
+++ t/kernel/posix-timers.c 2007-08-12 23:52:07.0 +0400
@@ -547,9 +547,9 @@ sys_timer_create(const clockid_t which_c
new_timer->it_process = process;
list_add(_timer->list,
>signal->posix_timers);
-
spin_unlock_irqrestore(>sighand->siglock, flags);
if (new_timer->it_sigev_notify ==
(SIGEV_SIGNAL|SIGEV_THREAD_ID))
get_task_struct(process);
+
spin_unlock_irqrestore(>sighand->siglock, flags);
} else {
spin_unlock_irqrestore(>sighand->siglock, flags);
process = NULL;
-
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: cciss: warning: right shift count >= width of type
On 08/12/2007 08:58 AM, Al Viro wrote:
On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:
+ c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff; //MSB
+ c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
+ c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
+ c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
+ c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
+ c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
+ c->Request.CDB[8]= ((u64)start_blk >> 8) & 0xff;
put_unaligned(cpu_to_be64(start_blk), >Request.CDB[2]);
which is what's happening here anyway.
Well, yes. There are a few more of these in the driver and this wants a
maintainer (whom I can't reach @hp.com) comment.
Is that 16-bit one for CCISS_READ_10 really right? Either:
put_unaligned(cpu_to_be32(creq->nr_sectors), >Request.CDB[6]);
or possibly:
put_unaligned(cpu_to_be16(creq->nr_sectors), >Request.CDB[8]);
would look less surprising than the current 16-bit in 24-bit thing and the
"sect >> 24" comment there seems to imply the first?
(the implcit downcasting in that case is fine, right?)
Rene.
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..9fb6b3c 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1711,10 +1712,7 @@ static int fill_cmd(CommandList_struct *c, __u8 cmd, int
ctlr, void *buff, size_
c->Request.Type.Direction = XFER_READ;
c->Request.Timeout = 0;
c->Request.CDB[0] = cmd;
- c->Request.CDB[6] = (size >> 24) & 0xFF;//MSB
- c->Request.CDB[7] = (size >> 16) & 0xFF;
- c->Request.CDB[8] = (size >> 8) & 0xFF;
- c->Request.CDB[9] = size & 0xFF;
+ put_unaligned(cpu_to_be32(size), >Request.CDB[6]);
break;
case CCISS_READ_CAPACITY:
@@ -1735,12 +1733,7 @@ static int fill_cmd(CommandList_struct *c, __u8 cmd, int
ctlr, void *buff, size_
c->Request.Timeout = 0;
c->Request.CDB[0] = cmd;
c->Request.CDB[1] = 0x10;
- c->Request.CDB[10] = (size >> 24) & 0xFF;
- c->Request.CDB[11] = (size >> 16) & 0xFF;
- c->Request.CDB[12] = (size >> 8) & 0xFF;
- c->Request.CDB[13] = size & 0xFF;
- c->Request.Timeout = 0;
- c->Request.CDB[0] = cmd;
+ put_unaligned(cpu_to_be32(size), >Request.CDB[10]);
break;
case CCISS_CACHE_FLUSH:
c->Request.CDBLen = 12;
@@ -2598,29 +2591,15 @@ static void do_cciss_request(request_queue_t *q)
if (likely(blk_fs_request(creq))) {
if(h->cciss_read == CCISS_READ_10) {
c->Request.CDB[1] = 0;
- c->Request.CDB[2] = (start_blk >> 24) & 0xff; //MSB
- c->Request.CDB[3] = (start_blk >> 16) & 0xff;
- c->Request.CDB[4] = (start_blk >> 8) & 0xff;
- c->Request.CDB[5] = start_blk & 0xff;
- c->Request.CDB[6] = 0; // (sect >> 24) & 0xff; MSB
- c->Request.CDB[7] = (creq->nr_sectors >> 8) & 0xff;
- c->Request.CDB[8] = creq->nr_sectors & 0xff;
+ put_unaligned(cpu_to_be32(start_blk),
>Request.CDB[2]);
+ c->Request.CDB[6] = 0;
+ put_unaligned(cpu_to_be16(creq->nr_sectors),
>Request.CDB[7]);
c->Request.CDB[9] = c->Request.CDB[11] =
c->Request.CDB[12] = 0;
} else {
c->Request.CDBLen = 16;
c->Request.CDB[1]= 0;
- c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
- c->Request.CDB[3]= (start_blk >> 48) & 0xff;
- c->Request.CDB[4]= (start_blk >> 40) & 0xff;
- c->Request.CDB[5]= (start_blk >> 32) & 0xff;
- c->Request.CDB[6]= (start_blk >> 24) & 0xff;
- c->Request.CDB[7]= (start_blk >> 16) & 0xff;
- c->Request.CDB[8]= (start_blk >> 8) & 0xff;
- c->Request.CDB[9]= start_blk & 0xff;
- c->Request.CDB[10]= (creq->nr_sectors >> 24) & 0xff;
- c->Request.CDB[11]= (creq->nr_sectors >> 16) & 0xff;
- c->Request.CDB[12]= (creq->nr_sectors >> 8) & 0xff;
- c->Request.CDB[13]= creq->nr_sectors & 0xff;
+
