Re: [PATCH] scripts/checkpatch.pl: add a check for the patch level (patch -p)
On Fri, Dec 21, 2007 at 06:12:02PM +, Andy Whitcroft wrote:
> On Tue, Dec 18, 2007 at 06:46:41AM +0100, Borislav Petkov wrote:
> > On Mon, Dec 17, 2007 at 08:11:05AM +0100, Borislav Petkov wrote:
> >
> > A slightly microoptimized version 1.1:
> >
> > ---
> > From: Borislav Petkov <[EMAIL PROTECTED]>
> >
> >
> > Check the patch level of the single hunks in a patch file, however only when
> > checkpatch.pl is called from within the kernel tree.
> >
> > Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
> > --
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 579f50f..3eda27b 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -653,6 +653,18 @@ sub CHK {
> > }
> > }
> >
> > +sub check_patchlevel {
> > +
> > + if ($tree) {
> > + my ($path) = @_;
> > + $path =~ s![^/]*/!!;
> > +
> > + if (!stat($path)) {
> > + WARN("Check the patchlevel (hint: patch option -p)");
> > + }
> > + }
>
> Hmmm that will trigger on all patches which create new files if I am
> grokking you correctly.
>
> I would have thought this would pretty easy to check from the form of
> the names. Hmmm.
Yep, I thought that too. Still, this way of checking the patch level using the
relative file pathname in the kernel tree seemed pretty straightforward so i
sent it. Off the top of my head, we could check for "/dev/null" on the "---"
line and skip that hunk... like so:
---
From: Borislav Petkov <[EMAIL PROTECTED]>
Check the patch level of the diff hunks in a patch text file. It works
only when checkpatch.pl is called from within the kernel tree. The only
case it misses is when the patch creates a new file and the patchlevel is wrong.
However, this cannot be checked for reliably using this approach of stat()ing
the relative url of the patched file.
scripts/checkpatch.pl | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 579f50f..0fe80fb 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -653,6 +653,22 @@ sub CHK {
}
}
+sub check_patchlevel {
+
+ if ($tree) {
+ my ($path, $prev) = @_;
+
+# don't do any checking if it's a newly created file
+ return if $prev =~ m!/dev/null!;
+
+ $path =~ s![^/]*/!!;
+
+ if (!stat($path)) {
+ WARN("Check the patchlevel (hint: patch option -p)");
+ }
+ }
+}
+
sub process {
my $filename = shift;
my @lines = @_;
@@ -713,10 +729,16 @@ sub process {
#extract the filename as it passes
if ($line=~/^\+\+\+\s+(\S+)/) {
$realfile=$1;
+
+ if ($realfile) {
+ check_patchlevel($realfile, $lines[$linenr-2]);
+ }
+
$realfile =~ [EMAIL PROTECTED]/]*/@@;
$in_comment = 0;
next;
}
+
#extract the line range in the file after the patch is applied
if ($line=~/[EMAIL PROTECTED]@ -\d+(?:,\d+)? \+(\d+)(,(\d+))?
[EMAIL PROTECTED]@/) {
$is_patch = 1;
--
Regards/Gruß,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] usb: libusual: locking cleanup
On Sat, 22 Dec 2007 09:01:50 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote: > Then in usu_probe_thread() your basically stopping it at the start of > the function with a down(), and the up() is just ancillary .. So you > could easily move the up() further down in the function and still have > the same level of exclusion.. The unfortunate complication here is request_module. I didn't want to keep a semaphore locked across it, in case child waits for something. I wonder if there may be some deadlock that we cannot foresee. But I guess it won't hurt to try. I tested the patch and it seems to work ok. -- Pete -- 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: Testing RAM from userspace / question about memmap= arguments
Pavel Machek wrote: On Sun 2007-12-23 07:06:58, David Newall wrote: It's kind of hard to run anything over SSH if it has to be run before userspace is up. But the kernel can collect results from a modified memtest, after it chains back. memtest can be ran from userspace, that's the point. I'm not sure I believe that. You need to tinker with hardware tables before you know what physical RAM is being used. Sequential virtual pages might be mapped to sequential physical RAM, but it might also be mapped psuedo-randomly, or even page-reverse-sequential! How can you do a basic walking bit test when you could be accessing pages in random order? 1) if linux fixes some problem with PCI quirk or microcod upload, memtest will not see the fix What are you saying? Linux is going to fix faulty RAM? Yes, that's what CPU microcode update is for. And I want to test my RAM with up-to-date microcode. Don't microcode updates fix CPU bugs? That's not fixing faulty RAM. If base microcode is so faulty as to make RAM access unreliable, the CPU probably won't even POST, let alone boot the kernel and start a whole bunch of userspace stuff, before it can get around to checking to see if there is new microcode for that CPU and download it. I suppose a CPU retains microcode updates, once loaded, until power-down or some hard reboot that you surely can avoid. If it does happen that you have an update that works around something unrelated to the CPU, for example maybe interaction with a bridge, then you can update the CPU before running memtest. Once loaded it's there until power down. These are not RAM faults. The very last thing you want is evidence that you've got a faulty piece of RAM when the fault is actually a hard disk glitch! No, it may be power supply leading to RAM problems. Yes, I want to detect that. I'm sure you don't mean that. I'm sure you don't want a faulty power supply to look like faulty RAM. No amount of replacing pieces of memory is going to solve a faulty power supply. At worst you'll hit on a combination of pieces that pass the test ... and then the system will fail, mysteriously, in production. I'm certain you don't want that. Anyhow, good luck with your idea. I think it's crazy, and that you're doomed to failure. Doomed! I tell 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/
2.6.24-rc6-mm1
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/ - This kernel doesn't work on i386! It oopses late in boot due to an unrevertable change (e3c1b141) in git-x86 which I stared at for a while then I ran out of time and gave up. I would have just abandoned this release until it was fixed but I'll be largely offline for ten days starting tomorrow. The culprits have been notified and hopefully we'll have a patch for hot-fixes/ tomorrow. x86_64 and powerpc work OK though. - git-block is dropped due to more conflicts that I'm prepared to repair with git-scsi-misc - git-perfmon is dropped due to conflicts with git-x86 - git-kgdb is dropped due to conflicts with git-x86 - git-newsetup is dropped due to conflicts with git-x86 - Andi's x86 quilt tree is dropped due to conflicts with git-x86 - Someone broke suspend-to-RAM on the t61p again. It just instantly resumes itself. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail [EMAIL PROTECTED] - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Occasional snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. These probably are at least compilable. - More-than-daily -mm snapshots may be found at http://userweb.kernel.org/~akpm/mmotm/. These are almost certainly not compileable. Changes since 2.6.24-rc5-mm1: origin.patch git-acpi.patch git-alsa.patch git-agpgart.patch git-arm.patch git-avr32.patch git-cpufreq.patch git-powerpc.patch git-drm.patch git-dvb.patch git-hwmon.patch git-gfs2-nmw.patch git-hid.patch git-hrt.patch git-ieee1394.patch git-infiniband.patch git-input.patch git-jfs.patch git-kbuild.patch git-kvm.patch git-lblnet.patch git-leds.patch git-libata-all.patch git-md-accel.patch git-mips.patch git-mmc.patch git-mtd.patch git-ubi.patch git-net.patch git-net-fixup.patch git-netdev-all.patch git-battery.patch git-nfsd.patch git-ocfs2.patch git-selinux.patch git-s390.patch git-sched.patch git-sched-fixup.patch git-sh.patch git-scsi-misc.patch git-unionfs.patch git-v9fs.patch git-watchdog.patch git-watchdog-fixup.patch git-wireless.patch git-ipwireless_cs.patch git-x86.patch git-x86-fixup.patch git-xfs.patch git-cryptodev.patch git-cryptodev-fixup.patch git-xtensa.patch git trees -revert-hibernation-use-temporary-page-tables-for-kernel-text-mapping-on-x86_64.patch -uml-stop-gdb-from-deleting-breakpoints-when-running-uml.patch -alpha-strncpy-strncat-fixes.patch -rtc-at32ap700x-fix-irq-init-oops.patch -parport-dev-timeslice-is-an-unsigned-long-not-an-int.patch -ecryptfs-initialize-new-auth_tokens-before-teardown.patch -knfsd-change-mailing-list-for-nfsd-in-maintainers.patch -fix-lguest-documentation.patch -sparsemem-make-sparsemem_vmemmap-selectable.patch -fs-kconfig-grammar-fix.patch -ext3-ext4-avoid-divide-by-zero.patch -alpha-build-fixes.patch -git-acpi-ia64-build-fix.patch -git-acpi-build-fix.patch -acpi-add-reboot-mechanism.patch -acpi-cleanup-linux-acpih.patch -alsa-nopage.patch -alsa-usx2y-nopage.patch -drivers-char-remove-unnecessary-pci_dev_put.patch -git-cpufreq-query_current_values_with_pending_wait-build-fix.patch -agk-dm-dm-table-detect-io-beyond-device.patch -agk-dm-dm-mpath-hp-requires-scsi.patch -agk-dm-dm-crypt-fix-write-endio.patch -agk-dm-dm-trigger-change-uevent-on-rename.patch -agk-dm-dm-merge-max_hw_sector.patch -agk-dm-dm-crypt-use-bio_add_page.patch -agk-dm-dm-ioctl-move-compat-code-fix.patch -dm-persistent_read_metadata-warning-fix.patch -arch-powerpc-remove-duplicate-includes.patch -arch-ppc-remove-duplicate-includes.patch -arch-ppc-remove-an-unnecessary-pci_dev_put.patch -powerpc-kill-non-existent-symbols-from-ksyms-and-commproch.patch -powerpc-fix-typo-ifdef-ifndef.patch
[PATCH 1/2] UIO: Add a MAINTAINERS entry for Userspace I/O
From: Hans-Jürgen Koch <[EMAIL PROTECTED]> This patch adds an entry for the Userspace I/O framework to MAINTAINERS. Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- MAINTAINERS |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3c7db62..a06ee43 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4054,6 +4054,14 @@ L: [EMAIL PROTECTED] W: http://user-mode-linux.sourceforge.net S: Maintained +USERSPACE I/O (UIO) +P: Hans J. Koch +M: [EMAIL PROTECTED] +P: Greg Kroah-Hartman +M: [EMAIL PROTECTED] +L: linux-kernel@vger.kernel.org +S: Maintained + FAT/VFAT/MSDOS FILESYSTEM: P: OGAWA Hirofumi M: [EMAIL PROTECTED] -- 1.5.3.7 -- 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] Modules: fix memory leak of module names
Due to the change in kobject name handling, the module kobject needs to
have a null release function to ensure that the name it previously set
will be properly cleaned up.
All of this wierdness goes away in 2.6.25 with the rework of the kobject
name and cleanup logic, but this is required for 2.6.24.
Thanks to Alexey Dobriyan for finding the problem, and to Kay Sievers
for pointing out the simple way to fix it after I tried many complex
ways.
Cc: Alexey Dobriyan <[EMAIL PROTECTED]>
Cc: Kay Sievers <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
kernel/params.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/kernel/params.c b/kernel/params.c
index 2a4c514..7686417 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -697,8 +697,18 @@ static struct kset_uevent_ops module_uevent_ops = {
decl_subsys(module, _ktype, _uevent_ops);
int module_sysfs_initialized;
+static void module_release(struct kobject *kobj)
+{
+ /*
+* Stupid empty release function to allow the memory for the kobject to
+* be properly cleaned up. This will not need to be present for 2.6.25
+* with the upcoming kobject core rework.
+*/
+}
+
static struct kobj_type module_ktype = {
.sysfs_ops =_sysfs_ops,
+ .release = module_release,
};
/*
--
1.5.3.7
--
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/
[GIT PATCH] driver core fix for 2.6.24-rc6
Here is one bugfix for a memory leak for every module that is unloaded from the system due to the change in the kobject name code against your 2.6.24-rc6 tree. And an entry for MAINTAINERS for the UIO subsystem so the proper people get the blame :) Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ Patches will be sent as a follow-on to this message to lkml for people to see. thanks, greg k-h MAINTAINERS |8 kernel/params.c | 10 ++ 2 files changed, 18 insertions(+), 0 deletions(-) --- Greg Kroah-Hartman (1): Modules: fix memory leak of module names Hans-J??rgen Koch (1): UIO: Add a MAINTAINERS entry for Userspace I/O -- 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/
[GIT PATCH] USB fixes for 2.6.24-rc5
Here are some USB fixes and new device ids against your 2.6.24-rc6 git tree. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/ The full patches will be sent to the linux-usb mailing list (note the address change), if anyone wants to see them. thanks, greg k-h drivers/usb/gadget/fsl_usb2_udc.c |2 +- drivers/usb/serial/cp2101.c |1 + drivers/usb/serial/sierra.c |2 ++ 3 files changed, 4 insertions(+), 1 deletions(-) --- Kevin R Page (1): USB: VID/PID update for sierra Martin Kusserow (1): USB: New device ID for the CP2101 driver Peter Korsgaard (1): USB: Unbreak fsl_usb2_udc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS EINVAL on open(... | O_TRUNC) on 2.6.23.9
On Dec 22, 2007, at 5:52 AM, Gianluca Alberici wrote: I've run into this problem 2.6.23.9. The open syscall will return "Invalid argument" when O_TRUNC is set on existing files. The same file can be opened for append or removed. The evidence is for example: mars:~# mount localhost:/opt/nfs/ /mnt/tmp mars:~# echo "Hello" > /mnt/tmp/test-file mars:~# echo "Hello" > /mnt/tmp/test-file bash: /mnt/tmp/test-file: Invalid argument Can you show an strace of this please? Also, might suggest "rpcdebug - m nfsd -s all" -- Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver fixes
On Sun, Dec 23, 2007 at 01:42:14AM -0500, Jeff Garzik wrote: > I applied it to #upstream (2.6.25) since forcedeth is not on any > big-endian platforms AFAIK. All right, then... I hadn't been sure if it's onboard-only, that's all. > I have an epic100 card too if you need it (though it sounds like you > have something testable). Picked one for a fiver on ebay, just need to get around to putting it into that U60 box and testing; not a problem, just hadn't got around to doing that yet. -- 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 00/63] ide-cd: redux
On Fri, Dec 21, 2007 at 08:57:49PM +0100, Bartlomiej Zolnierkiewicz wrote: > On Thursday 20 December 2007, Borislav Petkov wrote: > > On Thu, Dec 20, 2007 at 01:48:49AM +0100, Bartlomiej Zolnierkiewicz wrote: > > Hi Bart, > > Hi all, > > > > > PS ide-cd Maintainer position is still open... > > i'd like to take that position if nobody objects. I've done some work > > around the > > kernel here and there and i think its time for me to get serious. > > Great! > > Please send me a patch for MAINTAINERS file updating ide-cd entry. Sure, there it is: --- Reopen ide-cd for maintainership. Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> -- diff --git a/MAINTAINERS b/MAINTAINERS index 3c7db62..fb59941 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1870,8 +1870,10 @@ T: quilt kernel.org/pub/linux/kernel/people/bart/pata-2.6/ S: Maintained IDE/ATAPI CDROM DRIVER +P: Borislav Petkov +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -S: Unmaintained +S: Maintained IDE/ATAPI FLOPPY DRIVERS P: Paul Bristow -- Regards/Gruß, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver fixes
Al Viro wrote: On Sun, Dec 23, 2007 at 12:33:14AM -0500, Jeff Garzik wrote: A couple [minorly] notable wireless bug fixes, and plenty of viro fixes for obscure issues :) Heh... FWIW, forcedeth patch (sent your way about two weeks ago) also belongs in the same set. If you need a resend - tell... I applied it to #upstream (2.6.25) since forcedeth is not on any big-endian platforms AFAIK. Is it .24 material for some obvious reason, which I missed? :) There's another pile in drivers/net/wireless, but that's for linville to forward when he gets around to it. Pure annotation patches belong to past-2.6.24 merge. I also have starfire and epic100 fixes, but that'll have to wait until I get around to putting the cards into sparc box (mcast breakage for starfire and full-driver one for epic100; since nobody had cared for the latter since 2.3.late, well...) I have an epic100 card too if you need it (though it sounds like you have something testable). I think I'll have an ipg fix for you tomorrow, but I want to RTFM first to make sure that it makes sense. And there are several interesting issues in atl1, netxen and cxgb3, but those will have to wait for when I get around to asking maintainers just what the hell did they mean those to do. FWIW, drivers/net is fairly noise-free wrt sparse endianness warnings in my tree; the main exceptions are prism54 (oid_mgt.c and the nightmares it pulls) and skfp (AIX-shared vendor driver; 'nuff said, IMO). Awesome :) BTW, if you still have any documentation for xircom_cb from your fighting tulip-related stuff, it would be welcome - there are some oddities with rx ring handling (assuming that we care about that driver at all and it's not on the way out, that is). xircom_tulip_cb should probably be deleted, since it is the crappier of the two drivers for the same hardware (xircom_cb being the other one). xircom_cb _the driver_ is pretty odd. It is less like tulip than it should be, actually. There are several things that could have been done to improve the throughput/etc. of the driver, but it was more important at the time to simply find a driver that always worked. IIRC its RX filtering was broken, implying the need to enable promisc mode just to receive packets normally. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver fixes
On Sun, Dec 23, 2007 at 12:33:14AM -0500, Jeff Garzik wrote: > > A couple [minorly] notable wireless bug fixes, and plenty of viro fixes > for obscure issues :) Heh... FWIW, forcedeth patch (sent your way about two weeks ago) also belongs in the same set. If you need a resend - tell... There's another pile in drivers/net/wireless, but that's for linville to forward when he gets around to it. Pure annotation patches belong to past-2.6.24 merge. I also have starfire and epic100 fixes, but that'll have to wait until I get around to putting the cards into sparc box (mcast breakage for starfire and full-driver one for epic100; since nobody had cared for the latter since 2.3.late, well...) I think I'll have an ipg fix for you tomorrow, but I want to RTFM first to make sure that it makes sense. And there are several interesting issues in atl1, netxen and cxgb3, but those will have to wait for when I get around to asking maintainers just what the hell did they mean those to do. FWIW, drivers/net is fairly noise-free wrt sparse endianness warnings in my tree; the main exceptions are prism54 (oid_mgt.c and the nightmares it pulls) and skfp (AIX-shared vendor driver; 'nuff said, IMO). BTW, if you still have any documentation for xircom_cb from your fighting tulip-related stuff, it would be welcome - there are some oddities with rx ring handling (assuming that we care about that driver at all and it's not on the way out, that is). -- 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: kobject ->k_name memory leak
On Sat, Dec 22, 2007 at 03:07:21PM +0300, Alexey Dobriyan wrote: > On Thu, Dec 20, 2007 at 02:04:56PM -0800, Greg KH wrote: > > On Sat, Dec 15, 2007 at 04:19:16PM +0100, Kay Sievers wrote: > > > On Sat, 2007-12-15 at 16:34 +0300, Alexey Dobriyan wrote: > > > > On Fri, Dec 14, 2007 at 01:48:23PM -0800, Greg KH wrote: > > > > > On Mon, Dec 03, 2007 at 01:25:51PM -0800, Greg KH wrote: > > > > > > On Tue, Dec 04, 2007 at 12:09:59AM +0300, Alexey Dobriyan wrote: > > > > > > > On Mon, Dec 03, 2007 at 12:47:16PM -0800, Greg KH wrote: > > > > > > > > On Mon, Dec 03, 2007 at 12:26:07PM +0300, Alexey Dobriyan wrote: > > > > > > > > > Hi, Greg! > > > > > > > > > > > > > > > > > > Commit ce2c9cb0259acd2aed184499ebe41ab00da13b25 aka > > > > > > > > > "kobject: remove the static array for the name" introduced > > > > > > > > > memory leak > > > > > > > > > of a module name after modprobe/rmmod. Apparently for modules > > > > > > > > > ->release > > > > > > > > > callback is NULL. > > > > > > > > > > > > > > > > > > kobject_cleanup: ->release = , name = 'foo_sysctl' > > > > > > > > > Pid: 1927, comm: rmmod Not tainted > > > > > > > > > 2.6.24-rc3-e1cca7e8d484390169777b423a7fe46c7021fec1 #5 > > > > > > > > > [] kobject_cleanup+0xb8/0xc0 > > > > > > > > > [] kobject_release+0x0/0x10 > > > > > > > > > [] kref_put+0x2b/0xa0 > > > > > > > > > [] _spin_unlock+0x25/0x40 > > > > > > > > > [] free_module+0x78/0xd0 > > > > > > > > > [] sys_delete_module+0x12f/0x1a0 > > > > > > > > > > > > > > > > Hm, _which_ kobject associated with a module, there are 3 of > > > > > > > > them I > > > > > > > > think :) > > > > > > > > > > > > > > Ouch! > > > > > > > > > > > > > > > They should all have a release function, and if they do not, we > > > > > > > > think > > > > > > > > it's a "static" kobject and it is not safe to free that name. > > > > > > > > > > > > > > > > I've been working on cleaning this up a lot in the -mm tree > > > > > > > > with over 80 > > > > > > > > patches for the kset/kobject apis and interfaces. > > > > > > > > > > > > > > > > But if we have a dynamic kobject, and we aren't freeing it > > > > > > > > properly, > > > > > > > > please let me know which one it is and I'll work to fix it for > > > > > > > > 2.6.24. > > > > > > > > > > > > > > The one which is passed to kobject_set_name() in > > > > > > > mod_sysfs_init().. > > > > > > > > > > > > That one should be set to the module_ktype, which is in > > > > > > kernel/params.c, > > > > > > so the release function there should... oh crap, there is no release > > > > > > function. That's a bug. After I get out of meetings tonight I'll > > > > > > write > > > > > > up a patch for that, unless someone beats me to it :) > > > > > > > > > > Ok, this is a mess. We can't really have a release function for this > > > > > kobject, as the structure it is embedded it has it's own memory > > > > > management issues. > > > > > > > > > > To fix this properly is going to take some major kobject/module > > > > > surgery, > > > > > it's not a simple fix at all. I'll tackle it for 2.6.25, as it fits > > > > > in > > > > > nicely with the other kobject rework that I've already done in the -mm > > > > > tree. > > > > > > > > > > So, for now, can we just live with this tiny memory leak on module > > > > > unload? > > > > > > > > For the record, this leak screws any testing one can do wrt module > > > > unload races. You can't really leave box overnight running > > > > modprobe/rmmod in a loop, because OOM killer will finally kick in. > > > > Hey, this is exactly how it was noticed at all. > > > > > > > > > Or is the above trace something that users will see when unloading > > > > > modules? > > > > > > > > No, it's added debugging. > > > > > > Can't we add an empty release function? It would free the name with the > > > current logic, right? > > > > Doh, that should be easy. > > > > Alexey, can you see if the patch below fixes this issue for you? > > Yep, it helps! Great, thanks for testing, I'll send the fix to Linus in a bit. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] USB Kconfig: Declutter USB Kconfig Menu
On Saturday 22 December 2007, Al Boldi wrote: > Provided there is agreement, and we go with < >, it would mean a slight > change to Host side USB, like this (note new USB Core Config sub-menu): > > --- Support for Host-side USB > [ ] USB Core Config ---> Maybe. Let's see what you turn up. > [ ] USB Host Controller Drivers ---> Having at least one HCD is *NOT* optional. ;) And for that matter, I sometimes look at HCDs as part of the core. The layering there is fuzzier than usual, though it's getting better now that we've started to phase out the old Linux 2.2-ish interface. > --- NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may > --- also be needed; see USB_STORAGE Help for more information > < > USB Mass Storage support ---> > [ ] The shared table of common (or usual) storage devices > [ ] USB Monitor > < > USS720 parport driver > < > USB Serial Converter support ---> > < > USB DSL modem support ---> > [ ] USB Device Class drivers ---> > [ ] USB Imaging devices ---> > [ ] USB Miscellaneous drivers ---> > -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Jeff Garzik wrote: 2) It is legal for PCI-Express to put capabilities anywhere in PCI config space, including extended config space. (I hope our PCI cap walking code checks for overruns...) Uh, not really. The classical capability format only has 8-bit addresses, and the spec requires that all extended config space that is used be claimed by extended capabilities -- a different format chain. -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/
[PATCH] Avoid overflows in kernel/time.c (version 6)
When the conversion factor between jiffies and milli- or microseconds is not a single multiply or divide, as for the case of HZ == 300, we currently do a multiply followed by a divide. The intervening result, however, is subject to overflows, especially since the fraction is not simplified (for HZ == 300, we multiply by 300 and divide by 1000). This is exposed to the user when passing a large timeout to poll(), for example. This patch replaces the multiply-divide with a reciprocal multiplication on 32-bit platforms. When the input is an unsigned long, there is no portable way to do this on 64-bit platforms there is no portable way to do this since it requires a 128-bit intermediate result (which gcc does support on 64-bit platforms but may generate libgcc calls, e.g. on 64-bit s390), but since the output is a 32-bit integer in the cases affected, just simplify the multiply-divide (*3/10 instead of *300/1000). The reciprocal multiply used can have off-by-one errors in the upper half of the valid output range. This could be avoided at the expense of having to deal with a potential 65-bit intermediate result. Since the intent is to avoid overflow problems and most of the other time conversions are only semiexact, the off-by-one errors were considered an acceptable tradeoff. At Ralf Baechle's suggestion, this version uses a Perl script to compute the necessary constants. We already have dependencies on Perl for kernel compiles. This does, however, require the Perl module Math::BigInt, which is included in the standard Perl distribution starting with version 5.8.0. In order to support older versions of Perl, include a table of canned constants in the script itself, and structure the script so that Math::BigInt isn't required if pulling values from said table. Running the script requires that the HZ value is available from the Makefile. Thus, this patch also adds the Kconfig variable CONFIG_HZ to the architectures which didn't already have it (alpha, cris, frv, h8300, m32r, m68k, m68knommu, sparc, v850, and xtensa.) It does *not* touch the sh or sh64 architectures, since Paul Mundt has dealt with those separately in the sh tree. Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> --- This version adds back the _NUM and _DEN constants, which were inadvertently dropped when converting the script to Perl. This version also drops the sh64 fix, since Paul Mundt has fixed sh and sh64 in the sh tree. arch/alpha/Kconfig|5 + arch/cris/Kconfig |4 + arch/frv/Kconfig |4 + arch/h8300/Kconfig|4 + arch/m32r/Kconfig |4 + arch/m68k/Kconfig |4 + arch/m68knommu/Kconfig|5 + arch/sparc/Kconfig|4 + arch/v850/Kconfig |7 + arch/xtensa/Kconfig |4 + include/asm-alpha/param.h | 10 +- include/asm-cris/param.h |2 +- include/asm-frv/param.h |2 +- include/asm-h8300/param.h |2 +- include/asm-m32r/param.h |2 +- include/asm-m68k/param.h |2 +- include/asm-m68knommu/param.h |8 +- include/asm-sh64/param.h |6 +- include/asm-sparc/param.h |2 +- include/asm-v850/anna.h |6 - include/asm-v850/as85ep1.h|6 - include/asm-v850/fpga85e2c.h |6 - include/asm-v850/param.h |3 +- include/asm-v850/rte_cb.h |6 - include/asm-v850/sim.h|5 - include/asm-v850/sim85e2.h|6 - include/asm-xtensa/param.h|2 +- kernel/Makefile |8 + kernel/time.c | 29 ++- kernel/timeconst.pl | 402 + 30 files changed, 487 insertions(+), 73 deletions(-) create mode 100644 kernel/timeconst.pl diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 4c002ba..442e4e7 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -616,6 +616,11 @@ config VERBOSE_MCHECK_ON Take the default (1) unless you want more control or more info. +config HZ + int + default 1200 if ALPHA_RAWHIDE + default 1024 + source "drivers/pci/Kconfig" source "drivers/eisa/Kconfig" diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig index 222da15..fcc6a9e 100644 --- a/arch/cris/Kconfig +++ b/arch/cris/Kconfig @@ -55,6 +55,10 @@ config CRIS bool default y +config HZ + int + default 100 + source "init/Kconfig" menu "General setup" diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig index 43153e7..57bdf2d 100644 --- a/arch/frv/Kconfig +++ b/arch/frv/Kconfig @@ -57,6 +57,10 @@ config ARCH_HAS_ILOG2_U64 bool default y +config HZ + int + default 1000 + mainmenu "Fujitsu FR-V Kernel Configuration" source "init/Kconfig" diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig index ff6a871..8a40a6f 100644 --- a/arch/h8300/Kconfig +++ b/arch/h8300/Kconfig @@ -79,6 +79,10 @@ config PCI bool default n
Re: [PATCH] (UPDATED) ecryptfs: check for existing key_tfm at mount time
Andrew Morton wrote: > On Sat, 22 Dec 2007 11:42:37 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote: > >> Andrew Morton wrote: >> >>> It would all look a lot more solid if this locking was retained and both >>> ecryptfs_tfm_exists() and ecryptfs_add_new_key_tfm() were designed to be >>> called under key_tfm_list_mutex. >> Hmm good point, sorry for missing that. How's this look? > > key_tfm_list_mutex gets used in fs/ecryptfs/main.c but it is static in > fs/ecryptfs/crypto.c > Ah crud that was a bunk-ism in -mm that I missed. I'll send another updated patch soon. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Loic Prylli wrote: Supporting extended-conf-space is independant of the issue of using mmconf for legacy conf-space. True. There is no real reason to use the same method to access both. I have seen several arguments used that were implying that, and they all seem really bogus to me. Not only are the two ranges (<= 256 and >= 256) structurally independant (you have totally independant capabilities lists that are independantly organized in each of them), even if they were not there is no consistency issue that cannot be dealt with a memory barrier, and the concern about taking an extra branch for each pci-conf-space access is also bogus once you look at the numbers. By possibly using different implementations for the two ranges you avoid introducing a new API, you avoid taking risks with mmconf when you don't need it. That doesn't preclude using mmconf for everything either if the user requests it or based on enough knowledge of the system to be sure nothing will break. Are you prepared to guarantee that freely mixing mmconfig and type1 config accesses at runtime will always work, on all chipsets? I'm talking about silicon here, not kernel software. Furthermore, is it best for our users to find problems with mixed config accesses -- not at boot time, not at driver load time, but at some random time when some random driver does its first extended config space access? IMO, no. If you are going to fail, failing in a predictable, visible way is best. Failures are more predictable and more consistent with an all-or-none scenario. The all-or-none solutions are the least complex on the software side, and far more widely tested than any mixed config access scheme. Jeff -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On 12/22/2007 11:52 PM, Jeff Garzik wrote: > > Absolutely. > > But regardless of problems, enabling should be done globally, not per > device... The "enabling globally" requirement, i.e. not per-device, neither depending on reg >= 256 seems a very debatable assumption (IMHO a big mistake) that seems to be responsible for many of the problems seen in the past. There might be for a very long time AMD-architectures where extended-conf-space access for pci-express device works and is beneficial (and where mmconf is not supported by the hardware on non-pci-express devices). You are basically saying you don't want ever to support extended-conf-space globally for those systems, where it would be so easy to precisely use mmconf *only* when attempting *extended-conf-space * (>= 256) to some device (that provides a strong guarantee that you will never break anything unless somebody actually tries to use the extended-conf-space). Supporting extended-conf-space is independant of the issue of using mmconf for legacy conf-space. There is no real reason to use the same method to access both. I have seen several arguments used that were implying that, and they all seem really bogus to me. Not only are the two ranges (<= 256 and >= 256) structurally independant (you have totally independant capabilities lists that are independantly organized in each of them), even if they were not there is no consistency issue that cannot be dealt with a memory barrier, and the concern about taking an extra branch for each pci-conf-space access is also bogus once you look at the numbers. By possibly using different implementations for the two ranges you avoid introducing a new API, you avoid taking risks with mmconf when you don't need it. That doesn't preclude using mmconf for everything either if the user requests it or based on enough knowledge of the system to be sure nothing will break. Loic -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Linus Torvalds wrote: On Sun, 23 Dec 2007, Jeff Garzik wrote: And yes, if you want the capability following to notice automatically when capabilities really do go into the 0x100+ range, that's fine. I suspect Yes, we /must/ do this checking, if we don't already. Hell no. If the user asked for mmconfig to be disabled, it needs to be disabled, because it may well be broken and non-working. It's better to not see some capabilities than to lock up the machine. I think my short response created confusion. I was only saying that we should check for capability overruns, if we don't already[1]. I wasn't saying anything about mmconfig in that sentence, sorry. Let's pop this sub-thread off the stack, and jump to your "Sounds like a plan?" train of thought. Jeff [1] Lioc's response seems to imply my worry about overruns is unfounded. -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Sun, 23 Dec 2007, Jeff Garzik wrote: > > Then let's do it right: disable mmconfig by default on x86, and enable it > when passed "pci=mmconfig". I'm certainly ok with that, but then you say: > > And yes, if you want the capability following to notice automatically when > > capabilities really do go into the 0x100+ range, that's fine. I suspect > > Yes, we /must/ do this checking, if we don't already. Hell no. If the user asked for mmconfig to be disabled, it needs to be disabled, because it may well be broken and non-working. It's better to not see some capabilities than to lock up the machine. So what is it? Is it "some machines do it automatically when needed" or is it "always disabled"? You seem to now say that "always disabled by default" isn't good either. What do I need to do to convince you that the *right* thing to do is: - disabled by default, unless user *explicitly* asks for it with "pci=mmconfig" - but certain events will enable it automatically, unless the user *explicitly* said (or we had a quirk that explicitly disabled it) something like pci=mmconfig See what I'm saying? You don't really seem to be disagreeing. It seems to be, in fact, exactly what you want. I'm saying that yes, the PCI capability code might be one such "enable mmconfig if not explicitly disabled" user. But I also suspect that some drivers might want to do it, and I'm almost certain that some DMI quirks will want to do it (ie "I recognize this machine, and this machine is from 2011, and wants MMCONFIG"). So we need to have an interface for those quirks or other events to also do it, it cannot be just a "PCI capabilities do it". Quite frankly, the fewer drivers that do it, the happier I am. Maybe *no* drivers will do it. If so, "Hallelujah, brother, give me an Amen!". But we clearly want an interface for _some_ things to say "we might want to have mmconfig". Maybe it's only PCI capabilities. Regardless. Even if *no* driver ever does it, the logical interface will clearly be "pci_enable_mmio(pdev)". You can then argue all you want against individual drivers actually ever using it, and I'll support you on that. I think MMCONFIG was/is a total waste of everybodys time. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Sat, Dec 22, 2007 at 07:59:47PM -0500, Steven Rostedt wrote: [...] > But I still scratch my head when ever I need to touch sysfs. Same here. In fact, I've always considered that procfs was for humans while sysfs was for tools. sysfs reminds me too much the unexploitable /devices in Solaris. With the proper tools, I think we can do a lot with it, but it's not as intuitive to find the proper tools as it was to do "ls" followed by "cat" in /proc. Willy -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On 12/22/2007 11:13 PM, Jeff Garzik wrote: > > The facts as they exist today: > > 1) Existing 256-byte config space devices have been known put > capabilities in the high end (>= 0xc8) of config space. > > 2) It is legal for PCI-Express to put capabilities anywhere in PCI > config space, including extended config space. (I hope our PCI cap > walking code checks for overruns...) You make it sound almost as if the capability list that starts in regular conf-space could cross into extended conf-space >= 256). That's not true, the capability lists in the regular conf-space and the extended conf-space are really separate, they use a different structure for linking (different number of bits to define the capability IDs), a different starting point, different capability IDs definition tables. The regular conf-space and the extended conf-space are really independant. > > 3) Most new machines ship with PCI-Express devices with extended > config space. > > Therefore it is provable /possible/, and is indeed logical to conclude > that capabilities in extended config space will follow the same > pattern that existing hw designers have been following... but only > once the current OS's have stable extended-config-space support. > > Maybe that day will never come, but it is nonetheless quite possible > within today's PCI Express spec for this to happen. I agree with that statement. In fact it is already quite useful today. I am doing a lot of support activities where extended-conf-space is a must for troubleshooting. It was important enough for us that we have user-tools that allows us to access mmconfig-space for pci-express even on systems that don't advertise a MCFG attribute (as long as the chipset supports it, we have reverse-engineered the location of the "mmconfig bar" for a few chipsets including nvidia chipsets, for Intel it is well documented, and there are couple others). Loic -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Linus Torvalds wrote: On Sat, 22 Dec 2007, Jeff Garzik wrote: But regardless of problems, enabling should be done globally, not per device... I'm ok with trying the "globally" idea, but it has to be "globally but only if absolutely required". And quite frankly, how do you tell whether it's absolutely required or not? I have an idea: the drivers that really need it will do a "please enable MMCONFIG, because I will need it" thing? Ok? And then, since we *need* such a "pci_enable_mmconfig()" call anyway, why not let the driver give which device it controls too, so that we can print out the information (in case the machine then hangs immediately afterwards), and perhaps - if it is shown to help - only do the MMCONFIG cycles for that particular device? Sounds like a plan? As long as pci_enable_ext_cfg_space(pdev) enables extended accesses for -all- devices, the plan is mostly sound. That largely eliminates the inconsistency issue. The only thing I would worry about is whether "config space suddenly grew larger" condition will confuse userspace -- but that is NOT an objection, just a worry. Jeff -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Linus Torvalds wrote: I want to limit that downside. Right now, the easiest way to limit it seems to be to say that those (very very few) drivers that actually care could enable it. That way, we automatically limit it to only those machines that have hardware that cares. Then let's do it right: disable mmconfig by default on x86, and enable it when passed "pci=mmconfig". For the rare -- you and I agree its very rare -- case where it is REQUIRED, the user can pass pci=mmconfig as instructed by driver documentation somewhere. Let's not bend over backwards and introduce an API for these presently-theoretical cases. Given the complete lack of hw vendor testing and potential to confuse userspace, the two choices for a computer should be "mmconfig off" or "mmconfig on." Kernel hackers developing drivers and code for new machines will know enough to pass pci=mmconfig if they NEED it. That practice will only become annoying when x86 hardware actually starts to NEED extended config space -- at which future time we can revisit, as you describe. And yes, if you want the capability following to notice automatically when capabilities really do go into the 0x100+ range, that's fine. I suspect Yes, we /must/ do this checking, if we don't already. Jeff -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Sat, 22 Dec 2007, Jeff Garzik wrote: > > But regardless of problems, enabling should be done globally, not per > device... I'm ok with trying the "globally" idea, but it has to be "globally but only if absolutely required". And quite frankly, how do you tell whether it's absolutely required or not? I have an idea: the drivers that really need it will do a "please enable MMCONFIG, because I will need it" thing? Ok? And then, since we *need* such a "pci_enable_mmconfig()" call anyway, why not let the driver give which device it controls too, so that we can print out the information (in case the machine then hangs immediately afterwards), and perhaps - if it is shown to help - only do the MMCONFIG cycles for that particular device? Sounds like a plan? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Linus Torvalds wrote: On Sat, 22 Dec 2007, Jeff Garzik wrote: My core assertion: the present situation -- turning off MMCONFIG aggressively -- is greatly preferable to adding pci_enable_mmconfig_accesses(pdev). Well, you do realize that right now we have to have _users_ just doing "pci=nommconf" on the kernel command line, because we apparently don't do it aggressively enough? The fact is, we simply don't know what the breakage is. The only safe situation is to just assume things are broken, and enable it only when necessary. Absolutely. But regardless of problems, enabling should be done globally, not per device... You have three possibilities for an mmconfig-maybe-capable machine: 1) mmconfig disabled globally (for a single computer) Widely tested by users and hw vendors Consistent (all devices use same type of config access) 2) mmconfig enabled globally (for a single computer) Poorly tested by hw vendors, apparently Consistent (all devices use same type of config access) 3) mmconfig might or might not be enabled, depending on which driver is loaded, whether it called an API or not. Even LESS testing by hw vendors than #2. Maybe even "never" Inconsistent (config access depends on device) Choosing solution #3 is to choose the /least/ tested, /least/ likely to get hw vendor testing, /most/ inconsistent solution available. Doing so is not maximizing good engineering attributes :) AFAICS, solution #3 has a much higher chance of breaking userspace (pciutils, X.org, distro installers that read PCI config space, ...) as a result of the inconsistencies introduced. I agree 100% with your summary of the problem. But the per-device enabling solution introduced a "mixed model" for config space accesses is worse than any whitelist or other global [for a single computer] solution. The per-device enabling solution is IMO worse than simply deleting all mmconfig code from the kernel. At least the "kill mmconfig" solution would maintains the "tested" and "consistent" properties :) Jeff -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Sat, 22 Dec 2007, Jeff Garzik wrote: > > Jeff Garzik wrote: > > Maybe that day will never come, but it is nonetheless quite possible without > > today's PCI Express spec for this to happen. > > er, s/without/within/ You're talking specs. I'm talking machines. I agree with you 100% that as per specs, you need to support MMCONFIG, because anything can happen. As per *reality*, though, machines sold today simply don't need it. So there is no upside, and there is definitely downside. I want to limit that downside. Right now, the easiest way to limit it seems to be to say that those (very very few) drivers that actually care could enable it. That way, we automatically limit it to only those machines that have hardware that cares. And yes, if you want the capability following to notice automatically when capabilities really do go into the 0x100+ range, that's fine. I suspect that there aren't really very many cards that do that (because they wouldn't work with WinXP etc), so I doubt it will actually enable MMCONFIG for any noticeable amount of hardware sold today. Which is exactly what I want. I do *not* want to enable MMCONFIG unless it is shown to actually be needed. And no, "specs" do not show it is needed. MMCONFIG is needed depending on the actual *hardware* the kernel runs on, not based on some external specs. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Sat, 22 Dec 2007, Jeff Garzik wrote: > > It should be self-evident that mmconfig doesn't work on old hardware, is not > needed on old hardware, should not be turned on for old hardware, and in > general should never disturb old hardware. .. but it does. How do you figure out when to turn it off? By "old hardware" I don't mean stuff from the last century, that generally doesn't even *have* MMCONFIG. I mean the stuff you can buy *today*, which will be old by the time people really start _needing_ MMCONFIG. The fact is, 99% of the hardware you buy *today* has absolutely zero need for extended PCI config access. In fact, I would not be surprised at all if most hardware sold today generally doesn't have *any* devices that even have config registers in the 0x100+ range. So those are the kinds of machines we want to protect from blowing up. Stuff that isn't sold with Vista, and has never been tested (or where vista does some work-arounds we don't even know about - somebody was mentioning things like looking at the BIOS date etc). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Sat, 22 Dec 2007, Jeff Garzik wrote: > My core assertion: the present situation -- turning off MMCONFIG aggressively > -- is greatly preferable to adding pci_enable_mmconfig_accesses(pdev). Well, you do realize that right now we have to have _users_ just doing "pci=nommconf" on the kernel command line, because we apparently don't do it aggressively enough? The fact is, we simply don't know what the breakage is. The only safe situation is to just assume things are broken, and enable it only when necessary. And if there isn't a driver that needs it, then it sure as *hell* isn't necessary. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Jeff Garzik wrote: Maybe that day will never come, but it is nonetheless quite possible without today's PCI Express spec for this to happen. er, s/without/within/ -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Linus Torvalds wrote: On Sat, 22 Dec 2007, Jeff Garzik wrote: Regardless of whether a driver is loaded or not, you may NEED to see extended capabilities. The system may NEED to see those capabilities just to parse them for sane operation. And that's just not true. I don't know why you even claim so. There is absolutely *zero* need for MMCONFIG for 100% of old hardware, and old hardware is exactly the problem. The hardware that people will run next year isn't the issue. I'm not claiming anything about old hardware. It should be self-evident that mmconfig doesn't work on old hardware, is not needed on old hardware, should not be turned on for old hardware, and in general should never disturb old hardware. There may be an absolute need for MMCONFIG for future machines and future drivers, but there is not a single machine in existence today that really depends on it. You're just making things up. At worst, you lose some not-so-important error reporting, no more. So don't go spreading obvious untruths, The facts as they exist today: 1) Existing 256-byte config space devices have been known put capabilities in the high end (>= 0xc8) of config space. 2) It is legal for PCI-Express to put capabilities anywhere in PCI config space, including extended config space. (I hope our PCI cap walking code checks for overruns...) 3) Most new machines ship with PCI-Express devices with extended config space. Therefore it is provable /possible/, and is indeed logical to conclude that capabilities in extended config space will follow the same pattern that existing hw designers have been following... but only once the current OS's have stable extended-config-space support. Maybe that day will never come, but it is nonetheless quite possible without today's PCI Express spec for this to happen. We must handle this case, even if mmconfig is COMPLETELY DISABLED (i.e. normal mode today). Jeff -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Linus Torvalds wrote: The problem is that it isn't enough that it works on common machines with good hardware. The problem is that we end up chasing insane bugs, wasting peoples valuable time and effort, on those *few* - out of *millions* - of machines that then surprisingly don't work. And "surprisingly" is definitely the watch-word. That includes silently just not booting (because the first time anybody tries to do a PCI config cycle access, the machine just locks up) to some really *odd* behaviour (ie everything works fine *except* that reading the PCI card ID from a few cards returns a value of 0x0001 rather than the correct one). The fact is, we're currently turning off MMCONFIG very aggressively, exactly because it has caused problems. So most people never even use MMCONFIG when it's enabled, because all of our sanity checks that turn it off again. And it still has caused odd problems. Yes, I know all this. I am quite aware of the situation. My core assertion: the present situation -- turning off MMCONFIG aggressively -- is greatly preferable to adding pci_enable_mmconfig_accesses(pdev). IOW, don't add a new API. Keep doing what we're doing today. Today, we have a consistent "all or none" model for mmconfig. Any per-device mmconfig enabling introduces pain and inconsistency, in both the kernel and userland. Users with devices that REQUIRE extended config accesses should buy machines with known good mmconfig. The situation will sort itself out from there. We don't need ugly hacks like pci_enable_mmconfig_for_this_device(). Jeff (second response, for other paragraphs, following in separate email. I wanted to underscore the core API issue...) -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Sat, 22 Dec 2007, Jeff Garzik wrote: > > I forcibly turn on mmconfig on all my machines, and monitor lkml, to make sure > I'm aware of the extent of the problem -- and the extent of peoples' > exaggeration of this problem. Bullshit. You have how many machines? Ten? The problem is that it isn't enough that it works on common machines with good hardware. The problem is that we end up chasing insane bugs, wasting peoples valuable time and effort, on those *few* - out of *millions* - of machines that then surprisingly don't work. And "surprisingly" is definitely the watch-word. That includes silently just not booting (because the first time anybody tries to do a PCI config cycle access, the machine just locks up) to some really *odd* behaviour (ie everything works fine *except* that reading the PCI card ID from a few cards returns a value of 0x0001 rather than the correct one). The fact is, we're currently turning off MMCONFIG very aggressively, exactly because it has caused problems. So most people never even use MMCONFIG when it's enabled, because all of our sanity checks that turn it off again. And it still has caused odd problems. > Regardless of whether a driver is loaded or not, you may NEED to see extended > capabilities. The system may NEED to see those capabilities just to parse > them for sane operation. And that's just not true. I don't know why you even claim so. There is absolutely *zero* need for MMCONFIG for 100% of old hardware, and old hardware is exactly the problem. The hardware that people will run next year isn't the issue. There may be an absolute need for MMCONFIG for future machines and future drivers, but there is not a single machine in existence today that really depends on it. You're just making things up. At worst, you lose some not-so-important error reporting, no more. So don't go spreading obvious untruths, Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Saturday 22 December 2007 4:21:41 am Jean Delvare wrote: > >This patch makes the it87 driver request only the two ports used for the > >Environment Controller device. > > The problem is that the IT87xxF chips do decode 4 ports (recent chips, > 0x294-0x297) or 8 ports (older chips, 0x290-0x297), not 2 as the > datasheets say. The ITE Super-I/O chips differ from the Winbond > Super-I/O chips in this respect. The it87 driver only needs to access > ports 0x295 and 0x296, true, but the device itself decodes more > addresses than that. So, with this proposed patch, ports which are busy > will be shown as being free. This pretty much voids the point of > resource declarations, doesn't it? This might not cause too much > trouble in practice, but to me this still looks like the wrong way to go. Yes, all the ports decoded by the chip should certainly be reserved, but I think the entire range should be reserved at a higher level, like the PNP core, and the driver should reserve only the ports it uses. Then the entire range is reserved even if there is no driver or the driver is not loaded. That's the approach we use for PCI, e.g., e810-e81f : :00:08.0 <-- reserved by PCI core e810-e8102fff : CS46xx_BA1_data0<-- reserved by driver e811-e81137ff : CS46xx_BA1_data1 e812-e8126fff : CS46xx_BA1_pmem e813-e81300ff : CS46xx_BA1_reg > The resource declarations made by these motherboard BIOSes are totally > bogus. 0x290-0x29f is much larger than what the chip decodes. > 0x290-0x294 is a subset that doesn't make any sense. The GA-K8N Ultra 9 > is even funnier with 0x295-0x314, which again doesn't correspond to > anything real. I agree those declarations are probably wrong. But at least they're larger than required, so they should be safe. > All these happen to not intersect with 0x295-0x296 but I > wouldn't count on it. If Gigabyte (and possibly others) care that > little about these declarations, pretty much anything could be seen. So > while your proposed workaround happens to fix the problem at hand, it is > not really correct technically, and could break again soon. > > I'd rather fix the problem at its source, or, as fixing it as the source > isn't very realistic in this case, as near of the source as possible. > That would mean DMI-based quirks for the affected motherboards, that > would discard or adjust the bogus resource declarations. Well, I think the driver change *is* correct, assuming that the entire range can be reserved at a higher level. In this case, it is, via a PNP0C02 device. I think a DMI-based quirk to fix the PNP0C02 resources would be a good approach, but we shouldn't do that until those resources cause some other problem. > I also don't fully understand what pnpacpi is useful for. I have heard > about PCI drivers that might request resources that the motherboard > doesn't want them to touch, but I don't know the details, I also > don't know if it is a theoretical issue or if it really happens on some > systems, and I don't know if there are other uses for pnpacpi. It is a real issue. It's probably not very common because many ACPI devices use "legacy" resources like ports below 0x1000, and the kernel has heuristics to avoid placing other devices there. But I have seen the kernel place a CardBus device on top of an ACPI device, so it does happen. Apart from preventing resource conflicts, PNP has framework for driver/device binding, suspend/resume, etc. Without PNPACPI, we'll fall back to PNPBIOS, but my guess is that nowadays, the ACPI namespace is better-tested than PNPBIOS. And I wouldn't be surprised if PNPBIOS disappears from new boxes. > I'm > asking because I want to know if forcing pnpacpi=off on the faulty > motherboards would be good enough or if we really need finer-grained > quirks (assuming that we go the DMI-based quirks route at all.) The > former would obviously be easier. I'm sure these boxes still have PNPBIOS, so pnpacpi=off would probably work fine. But it feels like a bigger hammer than necessary for this problem. Bjorn -- 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] tty: Fix logic change introduced by wait_event_interruptible_timeout()
Andrew Morton wrote:
> On Thu, 20 Dec 2007 16:39:21 -0500 "Cory T. Tusar" <[EMAIL PROTECTED]> wrote:
>
>> tty: Fix logic change introduced by wait_event_interruptible_timeout()
>>
>> Commit 5a52bd4a2dcb570333ce6fe2e16cd311650dbdc8 introduced a subtle logic
>> change in tty_wait_until_sent(). The original version would only error
>> out of the 'do { ... } while (timeout)' loop if signal_pending() evaluated
>> to true; a timeout or break due to an empty buffer would fall out of the
>> loop and into the tty->driver->wait_until_sent handling. The current
>> implementation will error out on either a pending signal or an empty
>> buffer, falling through to the tty->driver->wait_until_sent handling
>> only on a timeout.
>>
>> This change reverts the logic flow in tty_wait_until_sent() to match that
>> prior to the aforementioned commit.
>>
>> Signed-off-by: Cory T. Tusar <[EMAIL PROTECTED]>
>>
>> ---
>> Please CC me on any replies; I'm not subscribed to lkml. Thanks.
>>
>> drivers/char/tty_ioctl.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/char/tty_ioctl.c b/drivers/char/tty_ioctl.c
>> index 1bdd2bf..e02d592 100644
>> --- a/drivers/char/tty_ioctl.c
>> +++ b/drivers/char/tty_ioctl.c
>> @@ -62,7 +62,7 @@ void tty_wait_until_sent(struct tty_struct * tty, long
>> timeout)
>> if (!timeout)
>> timeout = MAX_SCHEDULE_TIMEOUT;
>> if (wait_event_interruptible_timeout(tty->write_wait,
>> -!tty->driver->chars_in_buffer(tty), timeout))
>> +!tty->driver->chars_in_buffer(tty), timeout) < 0)
>> return;
>> if (tty->driver->wait_until_sent)
>> tty->driver->wait_until_sent(tty, timeout);
>
> OK... So what are the user-visible effects of this regression? The caller
> will run ->wait_until_sent() even after being signalled? So the signal is
> not promptly responded to?
No, the ->wait_until_sent() will not be reached if the buffer empties
before timeout jiffies have elapsed. This behavior differs from that
prior to commit 5a52bd4a2dcb570333ce6fe2e16cd311650dbdc8.
I turned this up while using a little serial download utility to
bootstrap an ARM-based eval board. The util worked fine on 2.6.22.x,
but consistently failed on 2.6.23.x. Once I'd determined that, I
narrowed things down with git bisect, and found the above difference
in logic in tty_wait_until_sent() by inspection.
If you'd like a more in-depth analysis of what's breaking on the
user-space side, I can certainly investigate further and (hopefully) come
up with a simple test case that tickles this issue.
--
Cory T. Tusar
Embedded Systems Engineer
Videon Central, Inc.
2171 Sandy Drive
State College, PA 16803
(814) 235- x316
(814) 235-1118 fax
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies." --Sir Charles Anthony Richard Hoare
--
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] Avoid overflows in kernel/time.c (version 5)
On Mon, 17 Dec 2007 13:53:23 -0800 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > When the conversion factor between jiffies and milli- or microseconds > is not a single multiply or divide, as for the case of HZ == 300, we > currently do a multiply followed by a divide. The intervening > result, however, is subject to overflows, especially since the > fraction is not simplified (for HZ == 300, we multiply by 300 and > divide by 1000). > > This is exposed to the user when passing a large timeout to poll(), > for example. > > This patch replaces the multiply-divide with a reciprocal > multiplication on 32-bit platforms. When the input is an unsigned > long, there is no portable way to do this on 64-bit platforms there is > no portable way to do this since it requires a 128-bit intermediate > result (which gcc does support on 64-bit platforms but may generate > libgcc calls, e.g. on 64-bit s390), but since the output is a 32-bit > integer in the cases affected, just simplify the multiply-divide > (*3/10 instead of *300/1000). alpha allmodconfig: kernel/time.c: In function 'jiffies_to_msecs': kernel/time.c:248: error: 'HZ_TO_MSEC_NUM' undeclared (first use in this function) kernel/time.c:248: error: (Each undeclared identifier is reported only once kernel/time.c:248: error: for each function it appears in.) kernel/time.c:248: error: 'HZ_TO_MSEC_DEN' undeclared (first use in this function) kernel/time.c: In function 'jiffies_to_usecs': kernel/time.c:264: error: 'HZ_TO_USEC_NUM' undeclared (first use in this function) kernel/time.c:264: error: 'HZ_TO_USEC_DEN' undeclared (first use in this function) kernel/time.c: In function 'usecs_to_jiffies': kernel/time.c:486: error: 'm' undeclared (first use in this function) kernel/time.c:489: warning: control reaches end of non-void function kernel/time.c: In function 'jiffies_to_usecs': kernel/time.c:267: warning: control reaches end of non-void function kernel/time.c: In function 'jiffies_to_msecs': kernel/time.c:251: warning: control reaches end of non-void function -- 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 23/24] udf: convert UDF_SB_FREE_BITMAP macro to udf_sb_free_bitmap function
additionally fix sparse warnings:
fs/udf/super.c:1636:4: warning: symbol 'i' shadows an earlier one
fs/udf/super.c:1469:6: originally declared here
fs/udf/super.c:1638:4: warning: symbol 'i' shadows an earlier one
fs/udf/super.c:1469:6: originally declared here
fs/udf/super.c:1712:4: warning: symbol 'i' shadows an earlier one
fs/udf/super.c:1701:6: originally declared here
fs/udf/super.c:1714:4: warning: symbol 'i' shadows an earlier one
fs/udf/super.c:1701:6: originally declared here
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/super.c |8
fs/udf/udf_sb.h | 31 ++-
2 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 1afea58..f6c911b 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -1634,9 +1634,9 @@ error_out:
if (map->s_partition_flags & UDF_PART_FLAG_FREED_TABLE)
iput(map->s_fspace.s_table);
if (map->s_partition_flags & UDF_PART_FLAG_UNALLOC_BITMAP)
- UDF_SB_FREE_BITMAP(sb, udf_sb_partition(sb), s_uspace);
+ udf_sb_free_bitmap(map->s_uspace.s_bitmap);
if (map->s_partition_flags & UDF_PART_FLAG_FREED_BITMAP)
- UDF_SB_FREE_BITMAP(sb, udf_sb_partition(sb), s_fspace);
+ udf_sb_free_bitmap(map->s_fspace.s_bitmap);
if (map->s_partition_type == UDF_SPARABLE_MAP15) {
for (i = 0; i < 4; i++)
brelse(map->s_type_specific.s_sparing.s_spar_map[i]);
@@ -1710,9 +1710,9 @@ static void udf_put_super(struct super_block *sb)
if (map->s_partition_flags & UDF_PART_FLAG_FREED_TABLE)
iput(map->s_fspace.s_table);
if (map->s_partition_flags & UDF_PART_FLAG_UNALLOC_BITMAP)
- UDF_SB_FREE_BITMAP(sb, udf_sb_partition(sb), s_uspace);
+ udf_sb_free_bitmap(map->s_uspace.s_bitmap);
if (map->s_partition_flags & UDF_PART_FLAG_FREED_BITMAP)
- UDF_SB_FREE_BITMAP(sb, udf_sb_partition(sb), s_fspace);
+ udf_sb_free_bitmap(map->s_fspace.s_bitmap);
if (map->s_partition_type == UDF_SPARABLE_MAP15) {
for (i = 0; i < 4; i++)
brelse(map->s_type_specific.s_sparing.s_spar_map[i]);
diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h
index 4cf91f2..8fc2be9 100644
--- a/fs/udf/udf_sb.h
+++ b/fs/udf/udf_sb.h
@@ -171,27 +171,24 @@ static inline struct udf_bitmap
*udf_sb_alloc_bitmap(struct super_block *sb, __u
return bitmap;
}
-#define UDF_SB_FREE_BITMAP(X,Y,Z)\
-{\
- int i;\
- int nr_groups = UDF_SB_BITMAP_NR_GROUPS(X,Y,Z);\
- int size = sizeof(struct udf_bitmap) + (sizeof(struct buffer_head *) *
nr_groups);\
- for (i = 0; i < nr_groups; i++) {\
- if (UDF_SB_BITMAP(X,Y,Z,i))\
- brelse(UDF_SB_BITMAP(X,Y,Z,i));\
- }\
- if (size <= PAGE_SIZE)\
- kfree(udf_sb_partmaps(X)[Y].Z.s_bitmap);\
- else\
- vfree(udf_sb_partmaps(X)[Y].Z.s_bitmap);\
+static inline void udf_sb_free_bitmap(struct udf_bitmap *bitmap)
+{
+ int i;
+ int nr_groups = bitmap->s_nr_groups;
+ int size = sizeof(struct udf_bitmap) + (sizeof(struct buffer_head *) *
nr_groups);
+
+ for (i = 0; i < nr_groups; i++) {
+ if (bitmap->s_block_bitmap[i])
+ brelse(bitmap->s_block_bitmap[i]);
+ }
+ if (size <= PAGE_SIZE)
+ kfree(bitmap);
+ else
+ vfree(bitmap);
}
#define UDF_QUERY_FLAG(X,Y)( udf_sb(X)->s_flags & ( 1 <<
(Y) ) )
#define UDF_SET_FLAG(X,Y) ( udf_sb(X)->s_flags |= ( 1 <<
(Y) ) )
#define UDF_CLEAR_FLAG(X,Y)( udf_sb(X)->s_flags &= ~( 1 <<
(Y) ) )
-#define UDF_SB_BITMAP(X,Y,Z,I) (
udf_sb_partmaps(X)[(Y)].Z.s_bitmap->s_block_bitmap[I] )
-#define UDF_SB_BITMAP_NR_GROUPS(X,Y,Z) (
udf_sb_partmaps(X)[(Y)].Z.s_bitmap->s_nr_groups )
-
-
#endif /* __LINUX_UDF_SB_H */
--
1.5.3.4
--
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 24/24] udf: fix sparse warnings (shadowing & mismatch between declaration and definition)
fix warnings:
fs/udf/super.c:1370:24: warning: symbol 'bh' shadows an earlier one
fs/udf/super.c:1288:21: originally declared here
fs/udf/super.c:450:6: warning: symbol 'udf_write_super' was not declared.
Should it be static?
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/super.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index f6c911b..da68130 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -447,7 +447,7 @@ static int udf_parse_options(char *options, struct
udf_options *uopt)
return 1;
}
-void udf_write_super(struct super_block *sb)
+static void udf_write_super(struct super_block *sb)
{
lock_kernel();
@@ -1367,7 +1367,6 @@ static int udf_load_partition(struct super_block *sb,
kernel_lb_addr *fileset)
map->s_type_specific.s_virtual.s_num_entries =
(udf_sb_vat_inode(sb)->i_size - 36) >>
2;
} else if (map->s_partition_type == UDF_VIRTUAL_MAP20) {
- struct buffer_head *bh = NULL;
uint32_t pos;
pos = udf_block_map(udf_sb_vat_inode(sb), 0);
--
1.5.3.4
--
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 21/24] udf: remove some UDF_SB_* macros
remove macros:
- UDF_SB_PARTTYPE
- UDF_SB_PARTROOT
- UDF_SB_PARTLEN
- UDF_SB_PARTVSN
- UDF_SB_PARTNUM
- UDF_SB_TYPESPAR
- UDF_SB_TYPEVIRT
- UDF_SB_PARTFUNC
- UDF_SB_PARTFLAGS
and replace all uses
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/balloc.c| 76 +++--
fs/udf/inode.c |2 +-
fs/udf/partition.c | 49 --
fs/udf/super.c | 191
fs/udf/udf_sb.h| 16 ++---
5 files changed, 179 insertions(+), 155 deletions(-)
diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
index 23aae18..4fe8635 100644
--- a/fs/udf/balloc.c
+++ b/fs/udf/balloc.c
@@ -155,10 +155,10 @@ static void udf_bitmap_free_blocks(struct super_block *sb,
mutex_lock(>s_alloc_mutex);
if (bloc.logicalBlockNum < 0 ||
- (bloc.logicalBlockNum + count) > UDF_SB_PARTLEN(sb,
bloc.partitionReferenceNum)) {
+ (bloc.logicalBlockNum + count) > udf_sb_partmap(sb,
bloc.partitionReferenceNum)->s_partition_len) {
udf_debug("%d < %d || %d + %d > %d\n",
bloc.logicalBlockNum, 0, bloc.logicalBlockNum, count,
- UDF_SB_PARTLEN(sb, bloc.partitionReferenceNum));
+ udf_sb_partmap(sb,
bloc.partitionReferenceNum)->s_partition_len);
goto error_return;
}
@@ -219,16 +219,18 @@ static int udf_bitmap_prealloc_blocks(struct super_block
*sb,
int bit, block, block_group, group_start;
int nr_groups, bitmap_nr;
struct buffer_head *bh;
+ __u32 part_len;
mutex_lock(>s_alloc_mutex);
- if (first_block < 0 || first_block >= UDF_SB_PARTLEN(sb, partition))
+ part_len = udf_sb_partmap(sb, partition)->s_partition_len;
+ if (first_block < 0 || first_block >= part_len)
goto out;
- if (first_block + block_count > UDF_SB_PARTLEN(sb, partition))
- block_count = UDF_SB_PARTLEN(sb, partition) - first_block;
+ if (first_block + block_count > part_len)
+ block_count = part_len - first_block;
repeat:
- nr_groups = (UDF_SB_PARTLEN(sb, partition) +
+ nr_groups = (udf_sb_partmap(sb, partition)->s_partition_len +
(sizeof(struct spaceBitmapDesc) << 3) +
(sb->s_blocksize * 8) - 1) / (sb->s_blocksize * 8);
block = first_block + (sizeof(struct spaceBitmapDesc) << 3);
@@ -287,7 +289,7 @@ static int udf_bitmap_new_block(struct super_block *sb,
mutex_lock(>s_alloc_mutex);
repeat:
- if (goal < 0 || goal >= UDF_SB_PARTLEN(sb, partition))
+ if (goal < 0 || goal >= udf_sb_partmap(sb, partition)->s_partition_len)
goal = 0;
nr_groups = bitmap->s_nr_groups;
@@ -421,10 +423,10 @@ static void udf_table_free_blocks(struct super_block *sb,
mutex_lock(>s_alloc_mutex);
if (bloc.logicalBlockNum < 0 ||
- (bloc.logicalBlockNum + count) > UDF_SB_PARTLEN(sb,
bloc.partitionReferenceNum)) {
+ (bloc.logicalBlockNum + count) > udf_sb_partmap(sb,
bloc.partitionReferenceNum)->s_partition_len) {
udf_debug("%d < %d || %d + %d > %d\n",
bloc.logicalBlockNum, 0, bloc.logicalBlockNum, count,
- UDF_SB_PARTLEN(sb, bloc.partitionReferenceNum));
+ udf_sb_partmap(sb,
bloc.partitionReferenceNum)->s_partition_len);
goto error_return;
}
@@ -627,7 +629,7 @@ static int udf_table_prealloc_blocks(struct super_block *sb,
struct extent_position epos;
int8_t etype = -1;
- if (first_block < 0 || first_block >= UDF_SB_PARTLEN(sb, partition))
+ if (first_block < 0 || first_block >= udf_sb_partmap(sb,
partition)->s_partition_len)
return 0;
if (UDF_I_ALLOCTYPE(table) == ICBTAG_FLAG_AD_SHORT)
@@ -703,7 +705,7 @@ static int udf_table_new_block(struct super_block *sb,
return newblock;
mutex_lock(>s_alloc_mutex);
- if (goal < 0 || goal >= UDF_SB_PARTLEN(sb, partition))
+ if (goal < 0 || goal >= udf_sb_partmap(sb, partition)->s_partition_len)
goal = 0;
/* We search for the closest matching block to goal. If we find a exact
hit,
@@ -789,22 +791,23 @@ inline void udf_free_blocks(struct super_block *sb,
uint32_t count)
{
uint16_t partition = bloc.partitionReferenceNum;
+ struct udf_part_map *map = udf_sb_partmap(sb, partition);
- if (UDF_SB_PARTFLAGS(sb, partition) & UDF_PART_FLAG_UNALLOC_BITMAP) {
+ if (map->s_partition_flags & UDF_PART_FLAG_UNALLOC_BITMAP) {
return udf_bitmap_free_blocks(sb, inode,
-
udf_sb_partmaps(sb)[partition].s_uspace.s_bitmap,
+
[PATCH 22/24] udf: convert UDF_SB_ALLOC_BITMAP macro to udf_sb_alloc_bitmap function
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/super.c |4 ++--
fs/udf/udf_sb.h | 37 -
2 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 33ccf66..1afea58 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -949,7 +949,7 @@ static int udf_load_partdesc(struct super_block *sb, struct
buffer_head *bh)
i,
map->s_uspace.s_table->i_ino);
}
if (phd->unallocSpaceBitmap.extLength) {
- UDF_SB_ALLOC_BITMAP(sb, i, s_uspace);
+ map->s_uspace.s_bitmap =
udf_sb_alloc_bitmap(sb, i);
if (map->s_uspace.s_bitmap != NULL) {
map->s_uspace.s_bitmap->s_extLength =
le32_to_cpu(phd->unallocSpaceBitmap.extLength);
@@ -979,7 +979,7 @@ static int udf_load_partdesc(struct super_block *sb, struct
buffer_head *bh)
i,
map->s_fspace.s_table->i_ino);
}
if (phd->freedSpaceBitmap.extLength) {
- UDF_SB_ALLOC_BITMAP(sb, i, s_fspace);
+ map->s_fspace.s_bitmap =
udf_sb_alloc_bitmap(sb, i);
if (map->s_fspace.s_bitmap != NULL) {
map->s_fspace.s_bitmap->s_extLength =
le32_to_cpu(phd->freedSpaceBitmap.extLength);
diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h
index a5805c5..4cf91f2 100644
--- a/fs/udf/udf_sb.h
+++ b/fs/udf/udf_sb.h
@@ -2,6 +2,7 @@
#define __LINUX_UDF_SB_H
#include
+#include
/* Since UDF 2.01 is ISO 13346 based... */
#define UDF_SUPER_MAGIC0x15013346
@@ -149,23 +150,25 @@ static inline void udf_update_revision(struct super_block
*sb, __u16 revision)
udf_sb(sb)->s_udfrev = revision;
}
-#define UDF_SB_ALLOC_BITMAP(X,Y,Z)\
-{\
- int nr_groups = ((udf_sb_partmap((X),(Y))->s_partition_len +
(sizeof(struct spaceBitmapDesc) << 3) +\
- ((X)->s_blocksize * 8) - 1) / ((X)->s_blocksize * 8));\
- int size = sizeof(struct udf_bitmap) + (sizeof(struct buffer_head *) *
nr_groups);\
- if (size <= PAGE_SIZE)\
- udf_sb_partmaps(X)[(Y)].Z.s_bitmap = kmalloc(size, GFP_KERNEL);\
- else\
- udf_sb_partmaps(X)[(Y)].Z.s_bitmap = vmalloc(size);\
- if (udf_sb_partmaps(X)[(Y)].Z.s_bitmap != NULL) {\
- memset(udf_sb_partmaps(X)[(Y)].Z.s_bitmap, 0x00, size);\
- udf_sb_partmaps(X)[(Y)].Z.s_bitmap->s_block_bitmap =\
- (struct buffer_head
**)(udf_sb_partmaps(X)[(Y)].Z.s_bitmap + 1);\
- udf_sb_partmaps(X)[(Y)].Z.s_bitmap->s_nr_groups = nr_groups;\
- } else {\
- udf_error(X, __FUNCTION__, "Unable to allocate space for bitmap
and %d buffer_head pointers", nr_groups);\
- }\
+static inline struct udf_bitmap *udf_sb_alloc_bitmap(struct super_block *sb,
__u32 index)
+{
+ struct udf_part_map *map = udf_sb_partmap(sb, index);
+ int nr_groups = (map->s_partition_len + (sizeof(struct spaceBitmapDesc)
<< 3) +
+ (sb->s_blocksize * 8) - 1) / (sb->s_blocksize * 8);
+ int size = sizeof(struct udf_bitmap) + (sizeof(struct buffer_head *) *
nr_groups);
+ struct udf_bitmap *bitmap;
+
+ if (size <= PAGE_SIZE)
+ bitmap = kmalloc(size, GFP_KERNEL);
+ else
+ bitmap = vmalloc(size);
+ if (bitmap != NULL) {
+ memset(bitmap, 0x00, size);
+ bitmap->s_block_bitmap = (struct buffer_head **)(bitmap + 1);
+ bitmap->s_nr_groups = nr_groups;
+ } else
+ udf_error(sb, __FUNCTION__, "Unable to allocate space for
bitmap and %d buffer_head pointers", nr_groups);
+ return bitmap;
}
#define UDF_SB_FREE_BITMAP(X,Y,Z)\
--
1.5.3.4
--
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 19/24] udf: check if udf_load_logicalvol failed
udf_load_logicalvol may fail eg in out of memory conditions - check it
and propagate error further
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/super.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 4aef612..f8c5794 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -1141,6 +1141,7 @@ static int udf_process_sequence(struct super_block *sb,
long block,
uint32_t vdsn;
uint16_t ident;
long next_s = 0, next_e = 0;
+ int ret;
memset(vds, 0, sizeof(struct udf_vds_record) * VDS_POS_LENGTH);
@@ -1216,7 +1217,11 @@ static int udf_process_sequence(struct super_block *sb,
long block,
if (i == VDS_POS_PRIMARY_VOL_DESC) {
udf_load_pvoldesc(sb, bh);
} else if (i == VDS_POS_LOGICAL_VOL_DESC) {
- udf_load_logicalvol(sb, bh, fileset); /* TODO:
check return value */
+ ret = udf_load_logicalvol(sb, bh, fileset);
+ if (ret != 0) {
+ brelse(bh);
+ return ret;
+ }
} else if (i == VDS_POS_PARTITION_DESC) {
struct buffer_head *bh2 = NULL;
if (udf_load_partdesc(sb, bh)) {
--
1.5.3.4
--
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 20/24] udf: convert UDF_UPDATE_UDFREV macro to udf_update_revision function
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/ialloc.c |2 +-
fs/udf/udf_sb.h |8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/udf/ialloc.c b/fs/udf/ialloc.c
index 269f588..4d1684c 100644
--- a/fs/udf/ialloc.c
+++ b/fs/udf/ialloc.c
@@ -123,7 +123,7 @@ struct inode *udf_new_inode(struct inode *dir, int mode,
int *err)
UDF_I_USE(inode) = 0;
if (UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_USE_EXTENDED_FE)) {
UDF_I_EFE(inode) = 1;
- UDF_UPDATE_UDFREV(inode->i_sb, UDF_VERS_USE_EXTENDED_FE);
+ udf_update_revision(inode->i_sb, UDF_VERS_USE_EXTENDED_FE);
UDF_I_DATA(inode) = kzalloc(inode->i_sb->s_blocksize -
sizeof(struct extendedFileEntry), GFP_KERNEL);
} else {
UDF_I_EFE(inode) = 0;
diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h
index 565c9ef..aee5942 100644
--- a/fs/udf/udf_sb.h
+++ b/fs/udf/udf_sb.h
@@ -138,6 +138,12 @@ static inline struct inode *udf_sb_vat_inode(struct
super_block *sb)
return udf_sb(sb)->s_vat_inode;
}
+static inline void udf_update_revision(struct super_block *sb, __u16 revision)
+{
+ if (revision > udf_sb_revision(sb))
+ udf_sb(sb)->s_udfrev = revision;
+}
+
#define UDF_SB_ALLOC_BITMAP(X,Y,Z)\
{\
int nr_groups = ((UDF_SB_PARTLEN((X),(Y)) + (sizeof(struct
spaceBitmapDesc) << 3) +\
@@ -176,8 +182,6 @@ static inline struct inode *udf_sb_vat_inode(struct
super_block *sb)
#define UDF_SET_FLAG(X,Y) ( udf_sb(X)->s_flags |= ( 1 <<
(Y) ) )
#define UDF_CLEAR_FLAG(X,Y)( udf_sb(X)->s_flags &= ~( 1 <<
(Y) ) )
-#define UDF_UPDATE_UDFREV(X,Y) ( ((Y) > udf_sb_revision(X)) ?
udf_sb(X)->s_udfrev = (Y) : udf_sb_revision(X) )
-
#define UDF_SB_PARTTYPE(X,Y) (
udf_sb_partmaps(X)[(Y)].s_partition_type )
#define UDF_SB_PARTROOT(X,Y) (
udf_sb_partmaps(X)[(Y)].s_partition_root )
#define UDF_SB_PARTLEN(X,Y)(
udf_sb_partmaps(X)[(Y)].s_partition_len )
--
1.5.3.4
--
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 17/24] udf: convert UDF_SB_VAT macro to udf_sb_vat_inode function
- change UDF_SB_VAT macro to udf_sb_vat_inode inline function
- rename s_vat field to s_vat_inode
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/partition.c|6 +++---
fs/udf/super.c| 24
fs/udf/udf_sb.h |6 +-
include/linux/udf_fs_sb.h |2 +-
4 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/fs/udf/partition.c b/fs/udf/partition.c
index c904ddf..99640a6 100644
--- a/fs/udf/partition.c
+++ b/fs/udf/partition.c
@@ -67,7 +67,7 @@ uint32_t udf_get_pblock_virt15(struct super_block *sb,
uint32_t block,
index = UDF_SB_TYPEVIRT(sb,partition).s_start_offset /
sizeof(uint32_t) + block;
}
- loc = udf_block_map(UDF_SB_VAT(sb), newblock);
+ loc = udf_block_map(udf_sb_vat_inode(sb), newblock);
if (!(bh = sb_bread(sb, loc))) {
udf_debug("get_pblock(UDF_VIRTUAL_MAP:%p,%d,%d) VAT: %d[%d]\n",
@@ -79,13 +79,13 @@ uint32_t udf_get_pblock_virt15(struct super_block *sb,
uint32_t block,
brelse(bh);
- if (UDF_I_LOCATION(UDF_SB_VAT(sb)).partitionReferenceNum == partition) {
+ if (UDF_I_LOCATION(udf_sb_vat_inode(sb)).partitionReferenceNum ==
partition) {
udf_debug("recursive call to udf_get_pblock!\n");
return 0x;
}
return udf_get_pblock(sb, loc,
-
UDF_I_LOCATION(UDF_SB_VAT(sb)).partitionReferenceNum,
+
UDF_I_LOCATION(udf_sb_vat_inode(sb)).partitionReferenceNum,
offset);
}
diff --git a/fs/udf/super.c b/fs/udf/super.c
index c520543..dcab9e8 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -1343,28 +1343,28 @@ static int udf_load_partition(struct super_block *sb,
kernel_lb_addr *fileset)
if (j == udf_sb_num_parts(sb))
return 1;
- UDF_SB_VAT(sb) = udf_iget(sb, ino);
- if (!UDF_SB_VAT(sb))
+ udf_sb(sb)->s_vat_inode = udf_iget(sb, ino);
+ if (!udf_sb_vat_inode(sb))
return 1;
if (UDF_SB_PARTTYPE(sb, i) == UDF_VIRTUAL_MAP15) {
UDF_SB_TYPEVIRT(sb, i).s_start_offset =
- udf_ext0_offset(UDF_SB_VAT(sb));
+ udf_ext0_offset(udf_sb_vat_inode(sb));
UDF_SB_TYPEVIRT(sb, i).s_num_entries =
- (UDF_SB_VAT(sb)->i_size - 36) >> 2;
+ (udf_sb_vat_inode(sb)->i_size - 36) >>
2;
} else if (UDF_SB_PARTTYPE(sb, i) == UDF_VIRTUAL_MAP20)
{
struct buffer_head *bh = NULL;
uint32_t pos;
- pos = udf_block_map(UDF_SB_VAT(sb), 0);
+ pos = udf_block_map(udf_sb_vat_inode(sb), 0);
bh = sb_bread(sb, pos);
if (!bh)
return 1;
UDF_SB_TYPEVIRT(sb, i).s_start_offset =
le16_to_cpu(((struct
virtualAllocationTable20 *)bh->b_data +
-
udf_ext0_offset(UDF_SB_VAT(sb)))->lengthHeader) +
- udf_ext0_offset(UDF_SB_VAT(sb));
- UDF_SB_TYPEVIRT(sb, i).s_num_entries =
(UDF_SB_VAT(sb)->i_size -
+
udf_ext0_offset(udf_sb_vat_inode(sb)))->lengthHeader) +
+ udf_ext0_offset(udf_sb_vat_inode(sb));
+ UDF_SB_TYPEVIRT(sb, i).s_num_entries =
(udf_sb_vat_inode(sb)->i_size -
UDF_SB_TYPEVIRT(sb, i).s_start_offset) >> 2;
brelse(bh);
}
@@ -1609,8 +1609,8 @@ static int udf_fill_super(struct super_block *sb, void
*options, int silent)
return 0;
error_out:
- if (UDF_SB_VAT(sb))
- iput(UDF_SB_VAT(sb));
+ if (udf_sb_vat_inode(sb))
+ iput(udf_sb_vat_inode(sb));
if (udf_sb_num_parts(sb)) {
if (UDF_SB_PARTFLAGS(sb, udf_sb_partition(sb)) &
UDF_PART_FLAG_UNALLOC_TABLE)
iput(udf_sb_partmaps(sb)[udf_sb_partition(sb)].s_uspace.s_table);
@@ -1684,8 +1684,8 @@ static void udf_put_super(struct super_block *sb)
{
int i;
- if (UDF_SB_VAT(sb))
- iput(UDF_SB_VAT(sb));
+ if (udf_sb_vat_inode(sb))
+ iput(udf_sb_vat_inode(sb));
if (udf_sb_num_parts(sb)) {
[PATCH 18/24] udf: convert UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps function
- change UDF_SB_ALLOC_PARTMAPS macro to udf_sb_alloc_partition_maps inline
function
- convert kmalloc + memset to kzalloc
- check if kzalloc failed (partially)
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/super.c |6 --
fs/udf/udf_sb.h | 27 +++
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index dcab9e8..4aef612 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -1013,7 +1013,9 @@ static int udf_load_logicalvol(struct super_block *sb,
struct buffer_head *bh,
lvd = (struct logicalVolDesc *)bh->b_data;
- UDF_SB_ALLOC_PARTMAPS(sb, le32_to_cpu(lvd->numPartitionMaps));
+ i = udf_sb_alloc_partition_maps(sb, le32_to_cpu(lvd->numPartitionMaps));
+ if (i != 0)
+ return i;
for (i = 0, offset = 0;
i < udf_sb_num_parts(sb) && offset <
le32_to_cpu(lvd->mapTableLength);
@@ -1214,7 +1216,7 @@ static int udf_process_sequence(struct super_block *sb,
long block,
if (i == VDS_POS_PRIMARY_VOL_DESC) {
udf_load_pvoldesc(sb, bh);
} else if (i == VDS_POS_LOGICAL_VOL_DESC) {
- udf_load_logicalvol(sb, bh, fileset);
+ udf_load_logicalvol(sb, bh, fileset); /* TODO:
check return value */
} else if (i == VDS_POS_PARTITION_DESC) {
struct buffer_head *bh2 = NULL;
if (udf_load_partdesc(sb, bh)) {
diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h
index fa09d50..565c9ef 100644
--- a/fs/udf/udf_sb.h
+++ b/fs/udf/udf_sb.h
@@ -1,6 +1,8 @@
#ifndef __LINUX_UDF_SB_H
#define __LINUX_UDF_SB_H
+#include
+
/* Since UDF 2.01 is ISO 13346 based... */
#define UDF_SUPER_MAGIC0x15013346
@@ -46,6 +48,19 @@ static inline struct udf_part_map *udf_sb_partmaps(struct
super_block *sb)
return udf_sb(sb)->s_partmaps;
}
+static inline int __must_check udf_sb_alloc_partition_maps(struct super_block
*sb, __u32 count)
+{
+ struct udf_sb_info *info = udf_sb(sb);
+ info->s_partmaps = kzalloc(sizeof(struct udf_part_map) * count,
GFP_KERNEL);
+ if (info->s_partmaps != NULL)
+ info->s_partitions = count;
+ else {
+ info->s_partitions = 0;
+ udf_error(sb, __FUNCTION__, "Unable to allocate space for %d
partition maps", count);
+ }
+ return info->s_partmaps != NULL ? 0 : -ENOMEM;
+}
+
static inline void udf_sb_free(struct super_block *sb)
{
struct udf_sb_info *sb_info = udf_sb(sb);
@@ -123,18 +138,6 @@ static inline struct inode *udf_sb_vat_inode(struct
super_block *sb)
return udf_sb(sb)->s_vat_inode;
}
-#define UDF_SB_ALLOC_PARTMAPS(X,Y)\
-{\
- udf_sb(X)->s_partmaps = kmalloc(sizeof(struct udf_part_map) * Y,
GFP_KERNEL);\
- if (udf_sb_partmaps(X) != NULL) {\
- udf_sb(X)->s_partitions = Y;\
- memset(udf_sb_partmaps(X), 0x00, sizeof(struct udf_part_map) *
Y);\
- } else {\
- udf_sb(X)->s_partitions = 0;\
- udf_error(X, __FUNCTION__, "Unable to allocate space for %d
partition maps", Y);\
- }\
-}
-
#define UDF_SB_ALLOC_BITMAP(X,Y,Z)\
{\
int nr_groups = ((UDF_SB_PARTLEN((X),(Y)) + (sizeof(struct
spaceBitmapDesc) << 3) +\
--
1.5.3.4
--
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 14/24] udf: convert UDF_SB_RECORDTIME macro to udf_sb_record_time function
- change UDF_SB_RECORDTIME macro to udf_sb_record_time inline function
- rename s_recordtime field to s_record_time
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/inode.c| 14 +++---
fs/udf/super.c|6 +++---
fs/udf/udf_sb.h |6 +-
include/linux/udf_fs_sb.h |2 +-
4 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 5afa19e..8c725e2 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1160,7 +1160,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
inode->i_atime.tv_sec = convtime;
inode->i_atime.tv_nsec = convtime_usec * 1000;
} else {
- inode->i_atime = UDF_SB_RECORDTIME(inode->i_sb);
+ inode->i_atime = udf_sb_record_time(inode->i_sb);
}
if (udf_stamp_to_time(, _usec,
@@ -1168,7 +1168,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
inode->i_mtime.tv_sec = convtime;
inode->i_mtime.tv_nsec = convtime_usec * 1000;
} else {
- inode->i_mtime = UDF_SB_RECORDTIME(inode->i_sb);
+ inode->i_mtime = udf_sb_record_time(inode->i_sb);
}
if (udf_stamp_to_time(, _usec,
@@ -1176,7 +1176,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
inode->i_ctime.tv_sec = convtime;
inode->i_ctime.tv_nsec = convtime_usec * 1000;
} else {
- inode->i_ctime = UDF_SB_RECORDTIME(inode->i_sb);
+ inode->i_ctime = udf_sb_record_time(inode->i_sb);
}
UDF_I_UNIQUE(inode) = le64_to_cpu(fe->uniqueID);
@@ -1192,7 +1192,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
inode->i_atime.tv_sec = convtime;
inode->i_atime.tv_nsec = convtime_usec * 1000;
} else {
- inode->i_atime = UDF_SB_RECORDTIME(inode->i_sb);
+ inode->i_atime = udf_sb_record_time(inode->i_sb);
}
if (udf_stamp_to_time(, _usec,
@@ -1200,7 +1200,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
inode->i_mtime.tv_sec = convtime;
inode->i_mtime.tv_nsec = convtime_usec * 1000;
} else {
- inode->i_mtime = UDF_SB_RECORDTIME(inode->i_sb);
+ inode->i_mtime = udf_sb_record_time(inode->i_sb);
}
if (udf_stamp_to_time(, _usec,
@@ -1208,7 +1208,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
UDF_I_CRTIME(inode).tv_sec = convtime;
UDF_I_CRTIME(inode).tv_nsec = convtime_usec * 1000;
} else {
- UDF_I_CRTIME(inode) = UDF_SB_RECORDTIME(inode->i_sb);
+ UDF_I_CRTIME(inode) = udf_sb_record_time(inode->i_sb);
}
if (udf_stamp_to_time(, _usec,
@@ -1216,7 +1216,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
inode->i_ctime.tv_sec = convtime;
inode->i_ctime.tv_nsec = convtime_usec * 1000;
} else {
- inode->i_ctime = UDF_SB_RECORDTIME(inode->i_sb);
+ inode->i_ctime = udf_sb_record_time(inode->i_sb);
}
UDF_I_UNIQUE(inode) = le64_to_cpu(efe->uniqueID);
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 6c14c4d..eb01f25 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -867,8 +867,8 @@ static void udf_load_pvoldesc(struct super_block *sb,
struct buffer_head *bh)
recording, recording_usec,
ts.year, ts.month, ts.day, ts.hour,
ts.minute, ts.typeAndTimezone);
- UDF_SB_RECORDTIME(sb).tv_sec = recording;
- UDF_SB_RECORDTIME(sb).tv_nsec = recording_usec * 1000;
+ udf_sb(sb)->s_record_time.tv_sec = recording;
+ udf_sb(sb)->s_record_time.tv_nsec = recording_usec * 1000;
}
if (!udf_build_ustr(, pvoldesc->volIdent, 32)) {
@@ -1578,7 +1578,7 @@ static int udf_fill_super(struct super_block *sb, void
*options, int silent)
if (!silent) {
kernel_timestamp ts;
- udf_time_to_stamp(, UDF_SB_RECORDTIME(sb));
+ udf_time_to_stamp(, udf_sb_record_time(sb));
udf_info("UDF %s (%s) Mounting volume '%s', "
"timestamp %04u/%02u/%02u
[PATCH 15/24] udf: convert UDF_SB_SERIALNUM macro to udf_sb_serial_number function
- change UDF_SB_SERIALNUM macro to udf_sb_serial_number inline function
- rename s_serialnum field to s_serial_number
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/inode.c|2 +-
fs/udf/misc.c |2 +-
fs/udf/super.c|2 +-
fs/udf/udf_sb.h |6 +-
include/linux/udf_fs_sb.h |2 +-
5 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 8c725e2..46cf40c 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1541,7 +1541,7 @@ static int udf_update_inode(struct inode *inode, int
do_sync)
fe->descTag.descVersion = cpu_to_le16(3);
else
fe->descTag.descVersion = cpu_to_le16(2);
- fe->descTag.tagSerialNum = cpu_to_le16(UDF_SB_SERIALNUM(inode->i_sb));
+ fe->descTag.tagSerialNum =
cpu_to_le16(udf_sb_serial_number(inode->i_sb));
fe->descTag.tagLocation =
cpu_to_le32(UDF_I_LOCATION(inode).logicalBlockNum);
crclen += UDF_I_LENEATTR(inode) + UDF_I_LENALLOC(inode) - sizeof(tag);
fe->descTag.descCRCLength = cpu_to_le16(crclen);
diff --git a/fs/udf/misc.c b/fs/udf/misc.c
index 95baad5..42d731a 100644
--- a/fs/udf/misc.c
+++ b/fs/udf/misc.c
@@ -88,7 +88,7 @@ struct genericFormat *udf_add_extendedattr(struct inode
*inode, uint32_t size,
eahd->descTag.descVersion = cpu_to_le16(3);
else
eahd->descTag.descVersion = cpu_to_le16(2);
- eahd->descTag.tagSerialNum =
cpu_to_le16(UDF_SB_SERIALNUM(inode->i_sb));
+ eahd->descTag.tagSerialNum =
cpu_to_le16(udf_sb_serial_number(inode->i_sb));
eahd->descTag.tagLocation =
cpu_to_le32(UDF_I_LOCATION(inode).logicalBlockNum);
eahd->impAttrLocation = cpu_to_le32(0x);
eahd->appAttrLocation = cpu_to_le32(0x);
diff --git a/fs/udf/super.c b/fs/udf/super.c
index eb01f25..5a2c474 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -894,7 +894,7 @@ static void udf_load_fileset(struct super_block *sb, struct
buffer_head *bh,
*root = lelb_to_cpu(fset->rootDirectoryICB.extLocation);
- UDF_SB_SERIALNUM(sb) = le16_to_cpu(fset->descTag.tagSerialNum);
+ udf_sb(sb)->s_serial_number = le16_to_cpu(fset->descTag.tagSerialNum);
udf_debug("Rootdir at block=%d, partition=%d\n",
root->logicalBlockNum, root->partitionReferenceNum);
diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h
index e9346c2..bae6a74 100644
--- a/fs/udf/udf_sb.h
+++ b/fs/udf/udf_sb.h
@@ -108,6 +108,11 @@ static inline struct timespec udf_sb_record_time(struct
super_block *sb)
return udf_sb(sb)->s_record_time;
}
+static inline __u16 udf_sb_serial_number(struct super_block *sb)
+{
+ return udf_sb(sb)->s_serial_number;
+}
+
#define UDF_SB_ALLOC_PARTMAPS(X,Y)\
{\
udf_sb(X)->s_partmaps = kmalloc(sizeof(struct udf_part_map) * Y,
GFP_KERNEL);\
@@ -172,7 +177,6 @@ static inline struct timespec udf_sb_record_time(struct
super_block *sb)
#define UDF_SB_BITMAP(X,Y,Z,I) (
udf_sb_partmaps(X)[(Y)].Z.s_bitmap->s_block_bitmap[I] )
#define UDF_SB_BITMAP_NR_GROUPS(X,Y,Z) (
udf_sb_partmaps(X)[(Y)].Z.s_bitmap->s_nr_groups )
-#define UDF_SB_SERIALNUM(X)( udf_sb(X)->s_serialnum )
#define UDF_SB_UDFREV(X) ( udf_sb(X)->s_udfrev )
#define UDF_SB_VAT(X) ( udf_sb(X)->s_vat )
diff --git a/include/linux/udf_fs_sb.h b/include/linux/udf_fs_sb.h
index adfecc6..dd16deb 100644
--- a/include/linux/udf_fs_sb.h
+++ b/include/linux/udf_fs_sb.h
@@ -97,7 +97,7 @@ struct udf_sb_info
struct timespec s_record_time;
/* Fileset Info */
- __u16 s_serialnum;
+ __u16 s_serial_number;
/* highest UDF revision we have recorded to this media */
__u16 s_udfrev;
--
1.5.3.4
--
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 16/24] udf: convert UDF_SB_UDFREV macro to udf_sb_revision function
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/balloc.c |2 +-
fs/udf/inode.c| 14 +++---
fs/udf/misc.c |2 +-
fs/udf/namei.c|2 +-
fs/udf/super.c| 10 +-
fs/udf/truncate.c |6 +++---
fs/udf/udf_sb.h |8 ++--
7 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
index 4c31666..23aae18 100644
--- a/fs/udf/balloc.c
+++ b/fs/udf/balloc.c
@@ -559,7 +559,7 @@ static void udf_table_free_blocks(struct super_block *sb,
}
epos.offset = sizeof(struct allocExtDesc);
}
- if (UDF_SB_UDFREV(sb) >= 0x0200)
+ if (udf_sb_revision(sb) >= 0x0200)
udf_new_tag(epos.bh->b_data, TAG_IDENT_AED, 3,
1,
epos.block.logicalBlockNum,
sizeof(tag));
else
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 46cf40c..1cdb381 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1537,7 +1537,7 @@ static int udf_update_inode(struct inode *inode, int
do_sync)
ICBTAG_FLAG_SETGID | ICBTAG_FLAG_STICKY));
fe->icbTag.flags = cpu_to_le16(icbflags);
- if (UDF_SB_UDFREV(inode->i_sb) >= 0x0200)
+ if (udf_sb_revision(inode->i_sb) >= 0x0200)
fe->descTag.descVersion = cpu_to_le16(3);
else
fe->descTag.descVersion = cpu_to_le16(2);
@@ -1667,7 +1667,7 @@ int8_t udf_add_aext(struct inode * inode, struct
extent_position * epos,
mark_inode_dirty(inode);
}
}
- if (UDF_SB_UDFREV(inode->i_sb) >= 0x0200)
+ if (udf_sb_revision(inode->i_sb) >= 0x0200)
udf_new_tag(nbh->b_data, TAG_IDENT_AED, 3, 1,
epos->block.logicalBlockNum, sizeof(tag));
else
@@ -1690,7 +1690,7 @@ int8_t udf_add_aext(struct inode * inode, struct
extent_position * epos,
}
if (epos->bh) {
if (!UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_STRICT) ||
- UDF_SB_UDFREV(inode->i_sb) >= 0x0201)
+ udf_sb_revision(inode->i_sb) >= 0x0201)
udf_update_tag(epos->bh->b_data, loffset);
else
udf_update_tag(epos->bh->b_data, sizeof(struct
allocExtDesc));
@@ -1711,7 +1711,7 @@ int8_t udf_add_aext(struct inode * inode, struct
extent_position * epos,
aed = (struct allocExtDesc *)epos->bh->b_data;
aed->lengthAllocDescs =
cpu_to_le32(le32_to_cpu(aed->lengthAllocDescs) +
adsize);
- if (!UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_STRICT) ||
UDF_SB_UDFREV(inode->i_sb) >= 0x0201)
+ if (!UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_STRICT) ||
udf_sb_revision(inode->i_sb) >= 0x0201)
udf_update_tag(epos->bh->b_data, epos->offset + (inc ?
0 : adsize));
else
udf_update_tag(epos->bh->b_data, sizeof(struct
allocExtDesc));
@@ -1754,7 +1754,7 @@ int8_t udf_write_aext(struct inode * inode, struct
extent_position * epos,
if (epos->bh) {
if (!UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_STRICT) ||
- UDF_SB_UDFREV(inode->i_sb) >= 0x0201) {
+ udf_sb_revision(inode->i_sb) >= 0x0201) {
struct allocExtDesc *aed = (struct allocExtDesc
*)epos->bh->b_data;
udf_update_tag(epos->bh->b_data,
le32_to_cpu(aed->lengthAllocDescs) +
sizeof(struct allocExtDesc));
@@ -1907,7 +1907,7 @@ int8_t udf_delete_aext(struct inode * inode, struct
extent_position epos,
aed->lengthAllocDescs =
cpu_to_le32(le32_to_cpu(aed->lengthAllocDescs)
- (2 * adsize));
if (!UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_STRICT) ||
- UDF_SB_UDFREV(inode->i_sb) >= 0x0201)
+ udf_sb_revision(inode->i_sb) >= 0x0201)
udf_update_tag(oepos.bh->b_data, oepos.offset -
(2 * adsize));
else
udf_update_tag(oepos.bh->b_data, sizeof(struct
allocExtDesc));
@@ -1923,7 +1923,7 @@ int8_t udf_delete_aext(struct inode * inode, struct
extent_position epos,
aed->lengthAllocDescs =
cpu_to_le32(le32_to_cpu(aed->lengthAllocDescs)
- adsize);
if (!UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_STRICT) ||
- UDF_SB_UDFREV(inode->i_sb) >= 0x0201)
+
[PATCH 12/24] udf: convert UDF_SB_LVIDIU macro to udf_sb_lvidiu function
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/ialloc.c | 16
fs/udf/super.c | 34 +-
fs/udf/udf_sb.h | 10 --
3 files changed, 33 insertions(+), 27 deletions(-)
diff --git a/fs/udf/ialloc.c b/fs/udf/ialloc.c
index ddbf1e6..269f588 100644
--- a/fs/udf/ialloc.c
+++ b/fs/udf/ialloc.c
@@ -45,11 +45,11 @@ void udf_free_inode(struct inode *inode)
mutex_lock(>s_alloc_mutex);
if (sbi->s_lvid_bh) {
if (S_ISDIR(inode->i_mode))
- UDF_SB_LVIDIU(sb)->numDirs =
-
cpu_to_le32(le32_to_cpu(UDF_SB_LVIDIU(sb)->numDirs) - 1);
+ udf_sb_lvidiu(sb)->numDirs =
+
cpu_to_le32(le32_to_cpu(udf_sb_lvidiu(sb)->numDirs) - 1);
else
- UDF_SB_LVIDIU(sb)->numFiles =
-
cpu_to_le32(le32_to_cpu(UDF_SB_LVIDIU(sb)->numFiles) - 1);
+ udf_sb_lvidiu(sb)->numFiles =
+
cpu_to_le32(le32_to_cpu(udf_sb_lvidiu(sb)->numFiles) - 1);
mark_buffer_dirty(sbi->s_lvid_bh);
}
@@ -93,11 +93,11 @@ struct inode *udf_new_inode(struct inode *dir, int mode,
int *err)
uint64_t uniqueID;
lvhd = (struct logicalVolHeaderDesc
*)(udf_sb_lvid(sb)->logicalVolContentsUse);
if (S_ISDIR(mode))
- UDF_SB_LVIDIU(sb)->numDirs =
-
cpu_to_le32(le32_to_cpu(UDF_SB_LVIDIU(sb)->numDirs) + 1);
+ udf_sb_lvidiu(sb)->numDirs =
+
cpu_to_le32(le32_to_cpu(udf_sb_lvidiu(sb)->numDirs) + 1);
else
- UDF_SB_LVIDIU(sb)->numFiles =
-
cpu_to_le32(le32_to_cpu(UDF_SB_LVIDIU(sb)->numFiles) + 1);
+ udf_sb_lvidiu(sb)->numFiles =
+
cpu_to_le32(le32_to_cpu(udf_sb_lvidiu(sb)->numFiles) + 1);
UDF_I_UNIQUE(inode) = uniqueID = le64_to_cpu(lvhd->uniqueID);
if (!(++uniqueID & 0xUL))
uniqueID += 16;
diff --git a/fs/udf/super.c b/fs/udf/super.c
index f9109c5..6c14c4d 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -476,7 +476,7 @@ static int udf_remount_fs(struct super_block *sb, int
*flags, char *options)
udf_sb(sb)->s_umask = uopt.umask;
if (udf_sb_lvid_bh(sb)) {
- int write_rev = le16_to_cpu(UDF_SB_LVIDIU(sb)->minUDFWriteRev);
+ int write_rev = le16_to_cpu(udf_sb_lvidiu(sb)->minUDFWriteRev);
if (write_rev > UDF_MAX_WRITE_VERSION)
*flags |= MS_RDONLY;
}
@@ -1381,8 +1381,8 @@ static void udf_open_lvid(struct super_block *sb)
int i;
kernel_timestamp cpu_time;
- UDF_SB_LVIDIU(sb)->impIdent.identSuffix[0] = UDF_OS_CLASS_UNIX;
- UDF_SB_LVIDIU(sb)->impIdent.identSuffix[1] = UDF_OS_ID_LINUX;
+ udf_sb_lvidiu(sb)->impIdent.identSuffix[0] = UDF_OS_CLASS_UNIX;
+ udf_sb_lvidiu(sb)->impIdent.identSuffix[1] = UDF_OS_ID_LINUX;
if (udf_time_to_stamp(_time, CURRENT_TIME))
udf_sb_lvid(sb)->recordingDateAndTime =
cpu_to_lets(cpu_time);
udf_sb_lvid(sb)->integrityType = LVID_INTEGRITY_TYPE_OPEN;
@@ -1407,16 +1407,16 @@ static void udf_close_lvid(struct super_block *sb)
if (udf_sb_lvid_bh(sb) &&
udf_sb_lvid(sb)->integrityType == LVID_INTEGRITY_TYPE_OPEN) {
- UDF_SB_LVIDIU(sb)->impIdent.identSuffix[0] = UDF_OS_CLASS_UNIX;
- UDF_SB_LVIDIU(sb)->impIdent.identSuffix[1] = UDF_OS_ID_LINUX;
+ udf_sb_lvidiu(sb)->impIdent.identSuffix[0] = UDF_OS_CLASS_UNIX;
+ udf_sb_lvidiu(sb)->impIdent.identSuffix[1] = UDF_OS_ID_LINUX;
if (udf_time_to_stamp(_time, CURRENT_TIME))
udf_sb_lvid(sb)->recordingDateAndTime =
cpu_to_lets(cpu_time);
- if (UDF_MAX_WRITE_VERSION >
le16_to_cpu(UDF_SB_LVIDIU(sb)->maxUDFWriteRev))
- UDF_SB_LVIDIU(sb)->maxUDFWriteRev =
cpu_to_le16(UDF_MAX_WRITE_VERSION);
- if (UDF_SB_UDFREV(sb) >
le16_to_cpu(UDF_SB_LVIDIU(sb)->minUDFReadRev))
- UDF_SB_LVIDIU(sb)->minUDFReadRev =
cpu_to_le16(UDF_SB_UDFREV(sb));
- if (UDF_SB_UDFREV(sb) >
le16_to_cpu(UDF_SB_LVIDIU(sb)->minUDFWriteRev))
- UDF_SB_LVIDIU(sb)->minUDFWriteRev =
cpu_to_le16(UDF_SB_UDFREV(sb));
+ if (UDF_MAX_WRITE_VERSION >
le16_to_cpu(udf_sb_lvidiu(sb)->maxUDFWriteRev))
+ udf_sb_lvidiu(sb)->maxUDFWriteRev =
cpu_to_le16(UDF_MAX_WRITE_VERSION);
+ if (UDF_SB_UDFREV(sb) >
[PATCH 13/24] udf: remove unused macros
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]> CC: Ben Fennema <[EMAIL PROTECTED]> CC: Jan Kara <[EMAIL PROTECTED]> --- fs/udf/udf_sb.h |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h index a9ff8fb..8683b71 100644 --- a/fs/udf/udf_sb.h +++ b/fs/udf/udf_sb.h @@ -167,13 +167,9 @@ static inline struct logicalVolIntegrityDescImpUse *udf_sb_lvidiu(struct super_b #define UDF_SB_BITMAP(X,Y,Z,I) ( udf_sb_partmaps(X)[(Y)].Z.s_bitmap->s_block_bitmap[I] ) #define UDF_SB_BITMAP_NR_GROUPS(X,Y,Z) ( udf_sb_partmaps(X)[(Y)].Z.s_bitmap->s_nr_groups ) -#define UDF_SB_UMASK(X)( udf_sb(X)->s_umask ) -#define UDF_SB_GID(X) ( udf_sb(X)->s_gid ) -#define UDF_SB_UID(X) ( udf_sb(X)->s_uid ) #define UDF_SB_RECORDTIME(X) ( udf_sb(X)->s_recordtime ) #define UDF_SB_SERIALNUM(X)( udf_sb(X)->s_serialnum ) #define UDF_SB_UDFREV(X) ( udf_sb(X)->s_udfrev ) -#define UDF_SB_FLAGS(X)( udf_sb(X)->s_flags ) #define UDF_SB_VAT(X) ( udf_sb(X)->s_vat ) #endif /* __LINUX_UDF_SB_H */ -- 1.5.3.4 -- 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 10/24] udf: convert UDF_SB_LVIDBH macro to udf_sb_lvid_bh function
- change UDF_SB_LVIDBH macro to udf_sb_lvid_bh inline function
- rename s_lvidbh field to s_lvid_bh
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/balloc.c | 26 +-
fs/udf/ialloc.c |8
fs/udf/namei.c|8
fs/udf/super.c| 26 +-
fs/udf/udf_sb.h |8 ++--
include/linux/udf_fs_sb.h |2 +-
6 files changed, 41 insertions(+), 37 deletions(-)
diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
index e313d80..d689d16 100644
--- a/fs/udf/balloc.c
+++ b/fs/udf/balloc.c
@@ -188,7 +188,7 @@ do_more:
} else {
if (inode)
DQUOT_FREE_BLOCK(inode, 1);
- if (UDF_SB_LVIDBH(sb)) {
+ if (udf_sb_lvid_bh(sb)) {
UDF_SB_LVID(sb)->freeSpaceTable[udf_sb_partition(sb)] =
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[udf_sb_partition(sb)])
+ 1);
}
@@ -202,8 +202,8 @@ do_more:
}
error_return:
sb->s_dirt = 1;
- if (UDF_SB_LVIDBH(sb))
- mark_buffer_dirty(UDF_SB_LVIDBH(sb));
+ if (udf_sb_lvid_bh(sb))
+ mark_buffer_dirty(udf_sb_lvid_bh(sb));
mutex_unlock(>s_alloc_mutex);
return;
}
@@ -261,10 +261,10 @@ repeat:
if (block_count > 0)
goto repeat;
out:
- if (UDF_SB_LVIDBH(sb)) {
+ if (udf_sb_lvid_bh(sb)) {
UDF_SB_LVID(sb)->freeSpaceTable[partition] =
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[partition]) -
alloc_count);
- mark_buffer_dirty(UDF_SB_LVIDBH(sb));
+ mark_buffer_dirty(udf_sb_lvid_bh(sb));
}
sb->s_dirt = 1;
mutex_unlock(>s_alloc_mutex);
@@ -389,10 +389,10 @@ got_block:
mark_buffer_dirty(bh);
- if (UDF_SB_LVIDBH(sb)) {
+ if (udf_sb_lvid_bh(sb)) {
UDF_SB_LVID(sb)->freeSpaceTable[partition] =
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[partition]) - 1);
- mark_buffer_dirty(UDF_SB_LVIDBH(sb));
+ mark_buffer_dirty(udf_sb_lvid_bh(sb));
}
sb->s_dirt = 1;
mutex_unlock(>s_alloc_mutex);
@@ -432,10 +432,10 @@ static void udf_table_free_blocks(struct super_block *sb,
but.. oh well */
if (inode)
DQUOT_FREE_BLOCK(inode, count);
- if (UDF_SB_LVIDBH(sb)) {
+ if (udf_sb_lvid_bh(sb)) {
UDF_SB_LVID(sb)->freeSpaceTable[udf_sb_partition(sb)] =
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[udf_sb_partition(sb)])
+ count);
- mark_buffer_dirty(UDF_SB_LVIDBH(sb));
+ mark_buffer_dirty(udf_sb_lvid_bh(sb));
}
start = bloc.logicalBlockNum + offset;
@@ -670,10 +670,10 @@ static int udf_table_prealloc_blocks(struct super_block
*sb,
brelse(epos.bh);
- if (alloc_count && UDF_SB_LVIDBH(sb)) {
+ if (alloc_count && udf_sb_lvid_bh(sb)) {
UDF_SB_LVID(sb)->freeSpaceTable[partition] =
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[partition]) -
alloc_count);
- mark_buffer_dirty(UDF_SB_LVIDBH(sb));
+ mark_buffer_dirty(udf_sb_lvid_bh(sb));
sb->s_dirt = 1;
}
mutex_unlock(>s_alloc_mutex);
@@ -771,10 +771,10 @@ static int udf_table_new_block(struct super_block *sb,
udf_delete_aext(table, goal_epos, goal_eloc, goal_elen);
brelse(goal_epos.bh);
- if (UDF_SB_LVIDBH(sb)) {
+ if (udf_sb_lvid_bh(sb)) {
UDF_SB_LVID(sb)->freeSpaceTable[partition] =
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[partition]) - 1);
- mark_buffer_dirty(UDF_SB_LVIDBH(sb));
+ mark_buffer_dirty(udf_sb_lvid_bh(sb));
}
sb->s_dirt = 1;
diff --git a/fs/udf/ialloc.c b/fs/udf/ialloc.c
index 92dc9ae..5cfac06 100644
--- a/fs/udf/ialloc.c
+++ b/fs/udf/ialloc.c
@@ -43,7 +43,7 @@ void udf_free_inode(struct inode *inode)
clear_inode(inode);
mutex_lock(>s_alloc_mutex);
- if (sbi->s_lvidbh) {
+ if (sbi->s_lvid_bh) {
if (S_ISDIR(inode->i_mode))
UDF_SB_LVIDIU(sb)->numDirs =
cpu_to_le32(le32_to_cpu(UDF_SB_LVIDIU(sb)->numDirs) - 1);
@@ -51,7 +51,7 @@ void udf_free_inode(struct inode *inode)
UDF_SB_LVIDIU(sb)->numFiles =
cpu_to_le32(le32_to_cpu(UDF_SB_LVIDIU(sb)->numFiles) - 1);
- mark_buffer_dirty(sbi->s_lvidbh);
+ mark_buffer_dirty(sbi->s_lvid_bh);
[PATCH 11/24] udf: convert UDF_SB_LVID macro to udf_sb_lvid function
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/balloc.c | 24
fs/udf/ialloc.c |2 +-
fs/udf/namei.c |4 ++--
fs/udf/super.c | 40
fs/udf/udf_sb.h |8 ++--
5 files changed, 41 insertions(+), 37 deletions(-)
diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
index d689d16..4c31666 100644
--- a/fs/udf/balloc.c
+++ b/fs/udf/balloc.c
@@ -189,8 +189,8 @@ do_more:
if (inode)
DQUOT_FREE_BLOCK(inode, 1);
if (udf_sb_lvid_bh(sb)) {
-
UDF_SB_LVID(sb)->freeSpaceTable[udf_sb_partition(sb)] =
-
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[udf_sb_partition(sb)])
+ 1);
+
udf_sb_lvid(sb)->freeSpaceTable[udf_sb_partition(sb)] =
+
cpu_to_le32(le32_to_cpu(udf_sb_lvid(sb)->freeSpaceTable[udf_sb_partition(sb)])
+ 1);
}
}
}
@@ -262,8 +262,8 @@ repeat:
goto repeat;
out:
if (udf_sb_lvid_bh(sb)) {
- UDF_SB_LVID(sb)->freeSpaceTable[partition] =
-
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[partition]) -
alloc_count);
+ udf_sb_lvid(sb)->freeSpaceTable[partition] =
+
cpu_to_le32(le32_to_cpu(udf_sb_lvid(sb)->freeSpaceTable[partition]) -
alloc_count);
mark_buffer_dirty(udf_sb_lvid_bh(sb));
}
sb->s_dirt = 1;
@@ -390,8 +390,8 @@ got_block:
mark_buffer_dirty(bh);
if (udf_sb_lvid_bh(sb)) {
- UDF_SB_LVID(sb)->freeSpaceTable[partition] =
-
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[partition]) - 1);
+ udf_sb_lvid(sb)->freeSpaceTable[partition] =
+
cpu_to_le32(le32_to_cpu(udf_sb_lvid(sb)->freeSpaceTable[partition]) - 1);
mark_buffer_dirty(udf_sb_lvid_bh(sb));
}
sb->s_dirt = 1;
@@ -433,8 +433,8 @@ static void udf_table_free_blocks(struct super_block *sb,
if (inode)
DQUOT_FREE_BLOCK(inode, count);
if (udf_sb_lvid_bh(sb)) {
- UDF_SB_LVID(sb)->freeSpaceTable[udf_sb_partition(sb)] =
-
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[udf_sb_partition(sb)])
+ count);
+ udf_sb_lvid(sb)->freeSpaceTable[udf_sb_partition(sb)] =
+
cpu_to_le32(le32_to_cpu(udf_sb_lvid(sb)->freeSpaceTable[udf_sb_partition(sb)])
+ count);
mark_buffer_dirty(udf_sb_lvid_bh(sb));
}
@@ -671,8 +671,8 @@ static int udf_table_prealloc_blocks(struct super_block *sb,
brelse(epos.bh);
if (alloc_count && udf_sb_lvid_bh(sb)) {
- UDF_SB_LVID(sb)->freeSpaceTable[partition] =
-
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[partition]) -
alloc_count);
+ udf_sb_lvid(sb)->freeSpaceTable[partition] =
+
cpu_to_le32(le32_to_cpu(udf_sb_lvid(sb)->freeSpaceTable[partition]) -
alloc_count);
mark_buffer_dirty(udf_sb_lvid_bh(sb));
sb->s_dirt = 1;
}
@@ -772,8 +772,8 @@ static int udf_table_new_block(struct super_block *sb,
brelse(goal_epos.bh);
if (udf_sb_lvid_bh(sb)) {
- UDF_SB_LVID(sb)->freeSpaceTable[partition] =
-
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[partition]) - 1);
+ udf_sb_lvid(sb)->freeSpaceTable[partition] =
+
cpu_to_le32(le32_to_cpu(udf_sb_lvid(sb)->freeSpaceTable[partition]) - 1);
mark_buffer_dirty(udf_sb_lvid_bh(sb));
}
diff --git a/fs/udf/ialloc.c b/fs/udf/ialloc.c
index 5cfac06..ddbf1e6 100644
--- a/fs/udf/ialloc.c
+++ b/fs/udf/ialloc.c
@@ -91,7 +91,7 @@ struct inode *udf_new_inode(struct inode *dir, int mode, int
*err)
if (udf_sb_lvid_bh(sb)) {
struct logicalVolHeaderDesc *lvhd;
uint64_t uniqueID;
- lvhd = (struct logicalVolHeaderDesc
*)(UDF_SB_LVID(sb)->logicalVolContentsUse);
+ lvhd = (struct logicalVolHeaderDesc
*)(udf_sb_lvid(sb)->logicalVolContentsUse);
if (S_ISDIR(mode))
UDF_SB_LVIDIU(sb)->numDirs =
cpu_to_le32(le32_to_cpu(UDF_SB_LVIDIU(sb)->numDirs) + 1);
diff --git a/fs/udf/namei.c b/fs/udf/namei.c
index 4122d2b..4a18bfc 100644
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -1017,7 +1017,7 @@ static int udf_symlink(struct inode *dir, struct dentry
*dentry,
if (udf_sb_lvid_bh(inode->i_sb)) {
struct logicalVolHeaderDesc *lvhd;
uint64_t uniqueID;
- lvhd =
[PATCH 09/24] udf: convert UDF_SB_LASTBLOCK macro to udf_sb_last_block function
- change UDF_SB_LASTBLOCK macro to udf_sb_last_block inline function
- rename s_lastblock field to s_last_block
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/super.c| 20 ++--
fs/udf/udf_sb.h |6 +-
include/linux/udf_fs_sb.h |2 +-
3 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 0120ac6..e641d8f 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -639,7 +639,7 @@ static int udf_vrs(struct super_block *sb, int silent)
*/
static void udf_find_anchor(struct super_block *sb)
{
- int lastblock = UDF_SB_LASTBLOCK(sb);
+ int lastblock = udf_sb_last_block(sb);
struct buffer_head *bh = NULL;
uint16_t ident;
uint32_t location;
@@ -759,7 +759,7 @@ static void udf_find_anchor(struct super_block *sb)
}
}
- UDF_SB_LASTBLOCK(sb) = lastblock;
+ udf_sb(sb)->s_last_block = lastblock;
}
static int udf_find_fileset(struct super_block *sb,
@@ -1261,8 +1261,8 @@ static int udf_check_valid(struct super_block *sb, int
novrs, int silent)
if (block == -1) {
udf_debug("Failed to read byte 32768. Assuming open "
"disc. Skipping validity check\n");
- if (!UDF_SB_LASTBLOCK(sb))
- UDF_SB_LASTBLOCK(sb) = udf_get_last_block(sb);
+ if (!udf_sb_last_block(sb))
+ udf_sb(sb)->s_last_block =
udf_get_last_block(sb);
return 0;
} else
return !block;
@@ -1319,12 +1319,12 @@ static int udf_load_partition(struct super_block *sb,
kernel_lb_addr *fileset)
switch (UDF_SB_PARTTYPE(sb, i)) {
case UDF_VIRTUAL_MAP15:
case UDF_VIRTUAL_MAP20:
- if (!UDF_SB_LASTBLOCK(sb)) {
- UDF_SB_LASTBLOCK(sb) = udf_get_last_block(sb);
+ if (!udf_sb_last_block(sb)) {
+ udf_sb(sb)->s_last_block =
udf_get_last_block(sb);
udf_find_anchor(sb);
}
- if (!UDF_SB_LASTBLOCK(sb)) {
+ if (!udf_sb_last_block(sb)) {
udf_debug("Unable to determine Lastblock (For "
"Virtual Partition)\n");
return 1;
@@ -1335,7 +1335,7 @@ static int udf_load_partition(struct super_block *sb,
kernel_lb_addr *fileset)
UDF_SB_PARTVSN(sb, i) == UDF_SB_PARTVSN(sb,
j) &&
UDF_SB_PARTNUM(sb, i) == UDF_SB_PARTNUM(sb,
j)) {
ino.partitionReferenceNum = j;
- ino.logicalBlockNum =
UDF_SB_LASTBLOCK(sb) - UDF_SB_PARTROOT(sb, j);
+ ino.logicalBlockNum =
udf_sb_last_block(sb) - UDF_SB_PARTROOT(sb, j);
break;
}
}
@@ -1512,7 +1512,7 @@ static int udf_fill_super(struct super_block *sb, void
*options, int silent)
udf_debug("Multi-session=%d\n", udf_sb_session(sb));
- UDF_SB_LASTBLOCK(sb) = uopt.lastblock;
+ udf_sb(sb)->s_last_block = uopt.lastblock;
udf_sb_anchor(sb)[0] = udf_sb_anchor(sb)[1] = 0;
udf_sb_anchor(sb)[2] = uopt.anchor;
udf_sb_anchor(sb)[3] = 256;
@@ -1537,7 +1537,7 @@ static int udf_fill_super(struct super_block *sb, void
*options, int silent)
goto error_out;
}
- udf_debug("Lastblock=%d\n", UDF_SB_LASTBLOCK(sb));
+ udf_debug("Lastblock=%d\n", udf_sb_last_block(sb));
if (UDF_SB_LVIDBH(sb)) {
uint16_t minUDFReadRev =
le16_to_cpu(UDF_SB_LVIDIU(sb)->minUDFReadRev);
diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h
index f00524f..ea4ec0f 100644
--- a/fs/udf/udf_sb.h
+++ b/fs/udf/udf_sb.h
@@ -80,6 +80,11 @@ static inline __u32 *udf_sb_anchor(struct super_block *sb)
return udf_sb(sb)->s_anchor;
}
+static inline __u32 udf_sb_last_block(struct super_block *sb)
+{
+ return udf_sb(sb)->s_last_block;
+}
+
#define UDF_SB_ALLOC_PARTMAPS(X,Y)\
{\
udf_sb(X)->s_partmaps = kmalloc(sizeof(struct udf_part_map) * Y,
GFP_KERNEL);\
@@ -144,7 +149,6 @@ static inline __u32 *udf_sb_anchor(struct super_block *sb)
#define UDF_SB_BITMAP(X,Y,Z,I) (
udf_sb_partmaps(X)[(Y)].Z.s_bitmap->s_block_bitmap[I] )
#define UDF_SB_BITMAP_NR_GROUPS(X,Y,Z) (
udf_sb_partmaps(X)[(Y)].Z.s_bitmap->s_nr_groups )
-#define UDF_SB_LASTBLOCK(X)( udf_sb(X)->s_lastblock )
#define UDF_SB_LVIDBH(X) (
[PATCH 07/24] udf: convert UDF_SB_SESSION macro to udf_sb_session function
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/misc.c |8
fs/udf/super.c | 28 ++--
fs/udf/udf_sb.h |6 +-
3 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/fs/udf/misc.c b/fs/udf/misc.c
index 15297de..95baad5 100644
--- a/fs/udf/misc.c
+++ b/fs/udf/misc.c
@@ -197,10 +197,10 @@ struct buffer_head *udf_read_tagged(struct super_block
*sb, uint32_t block,
if (block == 0x)
return NULL;
- bh = udf_tread(sb, block + UDF_SB_SESSION(sb));
+ bh = udf_tread(sb, block + udf_sb_session(sb));
if (!bh) {
udf_debug("block=%d, location=%d: read failed\n",
- block + UDF_SB_SESSION(sb), location);
+ block + udf_sb_session(sb), location);
return NULL;
}
@@ -210,7 +210,7 @@ struct buffer_head *udf_read_tagged(struct super_block *sb,
uint32_t block,
if (location != le32_to_cpu(tag_p->tagLocation)) {
udf_debug("location mismatch block %u, tag %u != %u\n",
- block + UDF_SB_SESSION(sb),
le32_to_cpu(tag_p->tagLocation), location);
+ block + udf_sb_session(sb),
le32_to_cpu(tag_p->tagLocation), location);
goto error_out;
}
@@ -240,7 +240,7 @@ struct buffer_head *udf_read_tagged(struct super_block *sb,
uint32_t block,
return bh;
}
udf_debug("Crc failure block %d: crc = %d, crclen = %d\n",
- block + UDF_SB_SESSION(sb), le16_to_cpu(tag_p->descCRC),
+ block + udf_sb_session(sb), le16_to_cpu(tag_p->descCRC),
le16_to_cpu(tag_p->descCRCLength));
error_out:
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 452e6f6..903c0ec 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -548,7 +548,7 @@ static int udf_vrs(struct super_block *sb, int silent)
else
sectorsize = sb->s_blocksize;
- sector += (UDF_SB_SESSION(sb) << sb->s_blocksize_bits);
+ sector += (udf_sb_session(sb) << sb->s_blocksize_bits);
udf_debug("Starting at sector %u (%ld byte sectors)\n",
(sector >> sb->s_blocksize_bits), sb->s_blocksize);
@@ -614,7 +614,7 @@ static int udf_vrs(struct super_block *sb, int silent)
return nsr03;
else if (nsr02)
return nsr02;
- else if (sector - (UDF_SB_SESSION(sb) << sb->s_blocksize_bits) == 32768)
+ else if (sector - (udf_sb_session(sb) << sb->s_blocksize_bits) == 32768)
return -1;
else
return 0;
@@ -675,15 +675,15 @@ static void udf_find_anchor(struct super_block *sb)
}
if (ident == TAG_IDENT_AVDP) {
- if (location == last[i] - UDF_SB_SESSION(sb)) {
- lastblock = last[i] -
UDF_SB_SESSION(sb);
+ if (location == last[i] - udf_sb_session(sb)) {
+ lastblock = last[i] -
udf_sb_session(sb);
UDF_SB_ANCHOR(sb)[0] = lastblock;
UDF_SB_ANCHOR(sb)[1] = lastblock - 256;
- } else if (location ==
udf_variable_to_fixed(last[i]) - UDF_SB_SESSION(sb)) {
+ } else if (location ==
udf_variable_to_fixed(last[i]) - udf_sb_session(sb)) {
UDF_SET_FLAG(sb, UDF_FLAG_VARCONV);
- lastblock =
udf_variable_to_fixed(last[i]) - UDF_SB_SESSION(sb);
+ lastblock =
udf_variable_to_fixed(last[i]) - udf_sb_session(sb);
UDF_SB_ANCHOR(sb)[0] = lastblock;
- UDF_SB_ANCHOR(sb)[1] = lastblock - 256
- UDF_SB_SESSION(sb);
+ UDF_SB_ANCHOR(sb)[1] = lastblock - 256
- udf_sb_session(sb);
} else {
udf_debug("Anchor found at block %d,
location mismatch %d.\n",
last[i], location);
@@ -704,13 +704,13 @@ static void udf_find_anchor(struct super_block *sb)
}
if (ident == TAG_IDENT_AVDP &&
- location == last[i] - 256 -
UDF_SB_SESSION(sb)) {
+ location == last[i] - 256 -
udf_sb_session(sb)) {
lastblock = last[i];
UDF_SB_ANCHOR(sb)[1] = last[i] - 256;
} else {
ident = location = 0;
-
[PATCH 08/24] udf: convert UDF_SB_ANCHOR macro to udf_sb_anchor function
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/super.c | 44 ++--
fs/udf/udf_sb.h |6 +-
2 files changed, 27 insertions(+), 23 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 903c0ec..0120ac6 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -677,20 +677,20 @@ static void udf_find_anchor(struct super_block *sb)
if (ident == TAG_IDENT_AVDP) {
if (location == last[i] - udf_sb_session(sb)) {
lastblock = last[i] -
udf_sb_session(sb);
- UDF_SB_ANCHOR(sb)[0] = lastblock;
- UDF_SB_ANCHOR(sb)[1] = lastblock - 256;
+ udf_sb_anchor(sb)[0] = lastblock;
+ udf_sb_anchor(sb)[1] = lastblock - 256;
} else if (location ==
udf_variable_to_fixed(last[i]) - udf_sb_session(sb)) {
UDF_SET_FLAG(sb, UDF_FLAG_VARCONV);
lastblock =
udf_variable_to_fixed(last[i]) - udf_sb_session(sb);
- UDF_SB_ANCHOR(sb)[0] = lastblock;
- UDF_SB_ANCHOR(sb)[1] = lastblock - 256
- udf_sb_session(sb);
+ udf_sb_anchor(sb)[0] = lastblock;
+ udf_sb_anchor(sb)[1] = lastblock - 256
- udf_sb_session(sb);
} else {
udf_debug("Anchor found at block %d,
location mismatch %d.\n",
last[i], location);
}
} else if (ident == TAG_IDENT_FE || ident ==
TAG_IDENT_EFE) {
lastblock = last[i];
- UDF_SB_ANCHOR(sb)[3] = 512;
+ udf_sb_anchor(sb)[3] = 512;
} else {
ident = location = 0;
if (last[i] >= 256) {
@@ -706,7 +706,7 @@ static void udf_find_anchor(struct super_block *sb)
if (ident == TAG_IDENT_AVDP &&
location == last[i] - 256 -
udf_sb_session(sb)) {
lastblock = last[i];
- UDF_SB_ANCHOR(sb)[1] = last[i] - 256;
+ udf_sb_anchor(sb)[1] = last[i] - 256;
} else {
ident = location = 0;
if (last[i] >= 312 +
udf_sb_session(sb)) {
@@ -723,7 +723,7 @@ static void udf_find_anchor(struct super_block *sb)
location ==
udf_variable_to_fixed(last[i]) - 256) {
UDF_SET_FLAG(sb,
UDF_FLAG_VARCONV);
lastblock =
udf_variable_to_fixed(last[i]);
- UDF_SB_ANCHOR(sb)[1] =
lastblock - 256;
+ udf_sb_anchor(sb)[1] =
lastblock - 256;
}
}
}
@@ -744,17 +744,17 @@ static void udf_find_anchor(struct super_block *sb)
}
}
- for (i = 0; i < ARRAY_SIZE(UDF_SB_ANCHOR(sb)); i++) {
- if (UDF_SB_ANCHOR(sb)[i]) {
- bh = udf_read_tagged(sb, UDF_SB_ANCHOR(sb)[i],
-UDF_SB_ANCHOR(sb)[i], );
+ for (i = 0; i < ARRAY_SIZE(udf_sb(sb)->s_anchor); i++) {
+ if (udf_sb_anchor(sb)[i]) {
+ bh = udf_read_tagged(sb, udf_sb_anchor(sb)[i],
+udf_sb_anchor(sb)[i], );
if (!bh)
- UDF_SB_ANCHOR(sb)[i] = 0;
+ udf_sb_anchor(sb)[i] = 0;
else {
brelse(bh);
if ((ident != TAG_IDENT_AVDP) &&
(i || (ident != TAG_IDENT_FE && ident !=
TAG_IDENT_EFE)))
- UDF_SB_ANCHOR(sb)[i] = 0;
+ udf_sb_anchor(sb)[i] = 0;
}
}
}
@@ -1280,10 +1280,10 @@ static int udf_load_partition(struct super_block *sb,
kernel_lb_addr *fileset)
if (!sb)
return 1;
- for (i = 0; i < ARRAY_SIZE(UDF_SB_ANCHOR(sb)); i++) {
- if (UDF_SB_ANCHOR(sb)[i] &&
- (bh =
[PATCH 04/24] udf: convert UDF_SB_VOLIDENT macro to udf_sb_volume_ident function
- change UDF_SB_VOLIDENT macro to udf_sb_volume_ident inline function
- rename s_volident field to s_volume_ident
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/file.c |2 +-
fs/udf/super.c|6 +++---
fs/udf/udf_sb.h |6 +-
include/linux/udf_fs_sb.h |2 +-
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/fs/udf/file.c b/fs/udf/file.c
index 7c7a1b3..7b61dae 100644
--- a/fs/udf/file.c
+++ b/fs/udf/file.c
@@ -192,7 +192,7 @@ int udf_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd,
switch (cmd) {
case UDF_GETVOLIDENT:
return copy_to_user((char __user *)arg,
- UDF_SB_VOLIDENT(inode->i_sb), 32) ? -EFAULT
: 0;
+ udf_sb_volume_ident(inode->i_sb), 32) ?
-EFAULT : 0;
case UDF_RELOCATE_BLOCKS:
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 2c68272..42de326 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -873,9 +873,9 @@ static void udf_load_pvoldesc(struct super_block *sb,
struct buffer_head *bh)
if (!udf_build_ustr(, pvoldesc->volIdent, 32)) {
if (udf_CS0toUTF8(, )) {
- strncpy(UDF_SB_VOLIDENT(sb), outstr.u_name,
+ strncpy(udf_sb_volume_ident(sb), outstr.u_name,
outstr.u_len > 31 ? 31 : outstr.u_len);
- udf_debug("volIdent[] = '%s'\n", UDF_SB_VOLIDENT(sb));
+ udf_debug("volIdent[] = '%s'\n",
udf_sb_volume_ident(sb));
}
}
@@ -1582,7 +1582,7 @@ static int udf_fill_super(struct super_block *sb, void
*options, int silent)
udf_info("UDF %s (%s) Mounting volume '%s', "
"timestamp %04u/%02u/%02u %02u:%02u (%x)\n",
UDFFS_VERSION, UDFFS_DATE,
-UDF_SB_VOLIDENT(sb), ts.year, ts.month, ts.day,
ts.hour, ts.minute,
+udf_sb_volume_ident(sb), ts.year, ts.month, ts.day,
ts.hour, ts.minute,
ts.typeAndTimezone);
}
if (!(sb->s_flags & MS_RDONLY))
diff --git a/fs/udf/udf_sb.h b/fs/udf/udf_sb.h
index 46ddfb0..fa7fdff 100644
--- a/fs/udf/udf_sb.h
+++ b/fs/udf/udf_sb.h
@@ -55,6 +55,11 @@ static inline void udf_sb_free(struct super_block *sb)
}
}
+static inline __u8 *udf_sb_volume_ident(struct super_block *sb)
+{
+ return udf_sb(sb)->s_volume_ident;
+}
+
#define UDF_SB_ALLOC_PARTMAPS(X,Y)\
{\
udf_sb(X)->s_partmaps = kmalloc(sizeof(struct udf_part_map) * Y,
GFP_KERNEL);\
@@ -119,7 +124,6 @@ static inline void udf_sb_free(struct super_block *sb)
#define UDF_SB_BITMAP(X,Y,Z,I) (
udf_sb_partmaps(X)[(Y)].Z.s_bitmap->s_block_bitmap[I] )
#define UDF_SB_BITMAP_NR_GROUPS(X,Y,Z) (
udf_sb_partmaps(X)[(Y)].Z.s_bitmap->s_nr_groups )
-#define UDF_SB_VOLIDENT(X) ( udf_sb(X)->s_volident )
#define UDF_SB_NUMPARTS(X) ( udf_sb(X)->s_partitions )
#define UDF_SB_PARTITION(X)( udf_sb(X)->s_partition )
#define UDF_SB_SESSION(X) ( udf_sb(X)->s_session )
diff --git a/include/linux/udf_fs_sb.h b/include/linux/udf_fs_sb.h
index 80ae9ef..a1addf6 100644
--- a/include/linux/udf_fs_sb.h
+++ b/include/linux/udf_fs_sb.h
@@ -75,7 +75,7 @@ struct udf_part_map
struct udf_sb_info
{
struct udf_part_map *s_partmaps;
- __u8s_volident[32];
+ __u8s_volume_ident[32];
/* Overall info */
__u16 s_partitions;
--
1.5.3.4
--
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 05/24] udf: convert UDF_SB_NUMPARTS macro to udf_sb_num_parts function
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/partition.c |6 +++---
fs/udf/super.c | 20 ++--
fs/udf/udf_sb.h| 10 +++---
3 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/fs/udf/partition.c b/fs/udf/partition.c
index aaab24c..c904ddf 100644
--- a/fs/udf/partition.c
+++ b/fs/udf/partition.c
@@ -31,7 +31,7 @@
inline uint32_t udf_get_pblock(struct super_block *sb, uint32_t block,
uint16_t partition, uint32_t offset)
{
- if (partition >= UDF_SB_NUMPARTS(sb)) {
+ if (partition >= udf_sb_num_parts(sb)) {
udf_debug("block=%d, partition=%d, offset=%d: invalid
partition\n",
block, partition, offset);
return 0x;
@@ -133,7 +133,7 @@ int udf_relocate_blocks(struct super_block *sb, long
old_block, long *new_block)
uint32_t packet;
int i, j, k, l;
- for (i = 0; i < UDF_SB_NUMPARTS(sb); i++) {
+ for (i = 0; i < udf_sb_num_parts(sb); i++) {
if (old_block > UDF_SB_PARTROOT(sb,i) &&
old_block < UDF_SB_PARTROOT(sb,i) + UDF_SB_PARTLEN(sb,i)) {
sdata = _SB_TYPESPAR(sb,i);
@@ -194,7 +194,7 @@ int udf_relocate_blocks(struct super_block *sb, long
old_block, long *new_block)
} /* if old_block */
}
- if (i == UDF_SB_NUMPARTS(sb)) {
+ if (i == udf_sb_num_parts(sb)) {
/* outside of partitions */
/* for now, fail =) */
return 1;
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 42de326..10eaba7 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -790,7 +790,7 @@ static int udf_find_fileset(struct super_block *sb,
/* --> cvg: FIXME - is it reasonable? */
return 1;
- for (newfileset.partitionReferenceNum = UDF_SB_NUMPARTS(sb) - 1;
+ for (newfileset.partitionReferenceNum = udf_sb_num_parts(sb) -
1;
(newfileset.partitionReferenceNum != 0x &&
fileset->logicalBlockNum == 0x &&
fileset->partitionReferenceNum == 0x);
@@ -907,7 +907,7 @@ static int udf_load_partdesc(struct super_block *sb, struct
buffer_head *bh)
p = (struct partitionDesc *)bh->b_data;
- for (i = 0; i < UDF_SB_NUMPARTS(sb); i++) {
+ for (i = 0; i < udf_sb_num_parts(sb); i++) {
udf_debug("Searching map: (%d == %d)\n",
udf_sb_partmaps(sb)[i].s_partition_num,
le16_to_cpu(p->partitionNumber));
if (udf_sb_partmaps(sb)[i].s_partition_num ==
le16_to_cpu(p->partitionNumber)) {
@@ -991,7 +991,7 @@ static int udf_load_partdesc(struct super_block *sb, struct
buffer_head *bh)
break;
}
}
- if (i == UDF_SB_NUMPARTS(sb)) {
+ if (i == udf_sb_num_parts(sb)) {
udf_debug("Partition (%d) not found in partition map\n",
le16_to_cpu(p->partitionNumber));
} else {
@@ -1016,7 +1016,7 @@ static int udf_load_logicalvol(struct super_block *sb,
struct buffer_head *bh,
UDF_SB_ALLOC_PARTMAPS(sb, le32_to_cpu(lvd->numPartitionMaps));
for (i = 0, offset = 0;
-i < UDF_SB_NUMPARTS(sb) && offset <
le32_to_cpu(lvd->mapTableLength);
+i < udf_sb_num_parts(sb) && offset <
le32_to_cpu(lvd->mapTableLength);
i++, offset += ((struct genericPartitionMap
*)&(lvd->partitionMaps[offset]))->partitionMapLength) {
type = ((struct genericPartitionMap
*)&(lvd->partitionMaps[offset]))->partitionMapType;
if (type == 1) {
@@ -1314,7 +1314,7 @@ static int udf_load_partition(struct super_block *sb,
kernel_lb_addr *fileset)
} else
udf_debug("Using anchor in block %d\n", UDF_SB_ANCHOR(sb)[i]);
- for (i = 0; i < UDF_SB_NUMPARTS(sb); i++) {
+ for (i = 0; i < udf_sb_num_parts(sb); i++) {
kernel_lb_addr uninitialized_var(ino);
switch (UDF_SB_PARTTYPE(sb, i)) {
case UDF_VIRTUAL_MAP15:
@@ -1330,7 +1330,7 @@ static int udf_load_partition(struct super_block *sb,
kernel_lb_addr *fileset)
return 1;
}
- for (j = 0; j < UDF_SB_NUMPARTS(sb); j++) {
+ for (j = 0; j < udf_sb_num_parts(sb); j++) {
if (j != i &&
UDF_SB_PARTVSN(sb, i) == UDF_SB_PARTVSN(sb,
j) &&
UDF_SB_PARTNUM(sb, i) == UDF_SB_PARTNUM(sb,
j)) {
@@ -1340,7 +1340,7 @@ static int udf_load_partition(struct super_block *sb,
kernel_lb_addr *fileset)
}
}
- if (j == UDF_SB_NUMPARTS(sb))
+
[PATCH 06/24] udf: convert UDF_SB_PARTITION macro to udf_sb_partition function
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/balloc.c | 10
fs/udf/super.c | 68 +++---
fs/udf/udf_sb.h |6 -
3 files changed, 44 insertions(+), 40 deletions(-)
diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
index b5d09ae..e313d80 100644
--- a/fs/udf/balloc.c
+++ b/fs/udf/balloc.c
@@ -88,7 +88,7 @@ static int read_block_bitmap(struct super_block *sb,
kernel_lb_addr loc;
loc.logicalBlockNum = bitmap->s_extPosition;
- loc.partitionReferenceNum = UDF_SB_PARTITION(sb);
+ loc.partitionReferenceNum = udf_sb_partition(sb);
bh = udf_tread(sb, udf_get_lb_pblock(sb, loc, block));
if (!bh) {
@@ -189,8 +189,8 @@ do_more:
if (inode)
DQUOT_FREE_BLOCK(inode, 1);
if (UDF_SB_LVIDBH(sb)) {
-
UDF_SB_LVID(sb)->freeSpaceTable[UDF_SB_PARTITION(sb)] =
-
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[UDF_SB_PARTITION(sb)])
+ 1);
+
UDF_SB_LVID(sb)->freeSpaceTable[udf_sb_partition(sb)] =
+
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[udf_sb_partition(sb)])
+ 1);
}
}
}
@@ -433,8 +433,8 @@ static void udf_table_free_blocks(struct super_block *sb,
if (inode)
DQUOT_FREE_BLOCK(inode, count);
if (UDF_SB_LVIDBH(sb)) {
- UDF_SB_LVID(sb)->freeSpaceTable[UDF_SB_PARTITION(sb)] =
-
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[UDF_SB_PARTITION(sb)])
+ count);
+ UDF_SB_LVID(sb)->freeSpaceTable[udf_sb_partition(sb)] =
+
cpu_to_le32(le32_to_cpu(UDF_SB_LVID(sb)->freeSpaceTable[udf_sb_partition(sb)])
+ count);
mark_buffer_dirty(UDF_SB_LVIDBH(sb));
}
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 10eaba7..452e6f6 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -840,7 +840,7 @@ static int udf_find_fileset(struct super_block *sb,
fileset->logicalBlockNum,
fileset->partitionReferenceNum);
- UDF_SB_PARTITION(sb) = fileset->partitionReferenceNum;
+ udf_sb(sb)->s_partition = fileset->partitionReferenceNum;
udf_load_fileset(sb, bh, root);
brelse(bh);
return 0;
@@ -1566,7 +1566,7 @@ static int udf_fill_super(struct super_block *sb, void
*options, int silent)
goto error_out;
}
- if (UDF_SB_PARTFLAGS(sb, UDF_SB_PARTITION(sb)) &
UDF_PART_FLAG_READ_ONLY) {
+ if (UDF_SB_PARTFLAGS(sb, udf_sb_partition(sb)) &
UDF_PART_FLAG_READ_ONLY) {
printk(KERN_NOTICE "UDF-fs: Partition marked readonly; forcing
readonly mount\n");
sb->s_flags |= MS_RDONLY;
}
@@ -1612,17 +1612,17 @@ error_out:
if (UDF_SB_VAT(sb))
iput(UDF_SB_VAT(sb));
if (udf_sb_num_parts(sb)) {
- if (UDF_SB_PARTFLAGS(sb, UDF_SB_PARTITION(sb)) &
UDF_PART_FLAG_UNALLOC_TABLE)
-
iput(udf_sb_partmaps(sb)[UDF_SB_PARTITION(sb)].s_uspace.s_table);
- if (UDF_SB_PARTFLAGS(sb, UDF_SB_PARTITION(sb)) &
UDF_PART_FLAG_FREED_TABLE)
-
iput(udf_sb_partmaps(sb)[UDF_SB_PARTITION(sb)].s_fspace.s_table);
- if (UDF_SB_PARTFLAGS(sb, UDF_SB_PARTITION(sb)) &
UDF_PART_FLAG_UNALLOC_BITMAP)
- UDF_SB_FREE_BITMAP(sb, UDF_SB_PARTITION(sb), s_uspace);
- if (UDF_SB_PARTFLAGS(sb, UDF_SB_PARTITION(sb)) &
UDF_PART_FLAG_FREED_BITMAP)
- UDF_SB_FREE_BITMAP(sb, UDF_SB_PARTITION(sb), s_fspace);
- if (UDF_SB_PARTTYPE(sb, UDF_SB_PARTITION(sb)) ==
UDF_SPARABLE_MAP15) {
+ if (UDF_SB_PARTFLAGS(sb, udf_sb_partition(sb)) &
UDF_PART_FLAG_UNALLOC_TABLE)
+
iput(udf_sb_partmaps(sb)[udf_sb_partition(sb)].s_uspace.s_table);
+ if (UDF_SB_PARTFLAGS(sb, udf_sb_partition(sb)) &
UDF_PART_FLAG_FREED_TABLE)
+
iput(udf_sb_partmaps(sb)[udf_sb_partition(sb)].s_fspace.s_table);
+ if (UDF_SB_PARTFLAGS(sb, udf_sb_partition(sb)) &
UDF_PART_FLAG_UNALLOC_BITMAP)
+ UDF_SB_FREE_BITMAP(sb, udf_sb_partition(sb), s_uspace);
+ if (UDF_SB_PARTFLAGS(sb, udf_sb_partition(sb)) &
UDF_PART_FLAG_FREED_BITMAP)
+ UDF_SB_FREE_BITMAP(sb, udf_sb_partition(sb), s_fspace);
+ if (UDF_SB_PARTTYPE(sb, udf_sb_partition(sb)) ==
UDF_SPARABLE_MAP15) {
for (i = 0; i < 4; i++)
- brelse(UDF_SB_TYPESPAR(sb,
UDF_SB_PARTITION(sb)).s_spar_map[i]);
+
[PATCH 03/24] udf: convert some macros to inline functions
macro UDF_SB_PARTMAPS -> function udf_sb_partmaps
macro UDF_SB_FREE -> function udf_sb_free
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/balloc.c | 24 ++--
fs/udf/super.c | 52 ++--
fs/udf/udf_sb.h | 65 +-
3 files changed, 73 insertions(+), 68 deletions(-)
diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
index 8374c91..b5d09ae 100644
--- a/fs/udf/balloc.c
+++ b/fs/udf/balloc.c
@@ -792,19 +792,19 @@ inline void udf_free_blocks(struct super_block *sb,
if (UDF_SB_PARTFLAGS(sb, partition) & UDF_PART_FLAG_UNALLOC_BITMAP) {
return udf_bitmap_free_blocks(sb, inode,
-
UDF_SB_PARTMAPS(sb)[partition].s_uspace.s_bitmap,
+
udf_sb_partmaps(sb)[partition].s_uspace.s_bitmap,
bloc, offset, count);
} else if (UDF_SB_PARTFLAGS(sb, partition) &
UDF_PART_FLAG_UNALLOC_TABLE) {
return udf_table_free_blocks(sb, inode,
-
UDF_SB_PARTMAPS(sb)[partition].s_uspace.s_table,
+
udf_sb_partmaps(sb)[partition].s_uspace.s_table,
bloc, offset, count);
} else if (UDF_SB_PARTFLAGS(sb, partition) &
UDF_PART_FLAG_FREED_BITMAP) {
return udf_bitmap_free_blocks(sb, inode,
-
UDF_SB_PARTMAPS(sb)[partition].s_fspace.s_bitmap,
+
udf_sb_partmaps(sb)[partition].s_fspace.s_bitmap,
bloc, offset, count);
} else if (UDF_SB_PARTFLAGS(sb, partition) & UDF_PART_FLAG_FREED_TABLE)
{
return udf_table_free_blocks(sb, inode,
-
UDF_SB_PARTMAPS(sb)[partition].s_fspace.s_table,
+
udf_sb_partmaps(sb)[partition].s_fspace.s_table,
bloc, offset, count);
} else {
return;
@@ -818,19 +818,19 @@ inline int udf_prealloc_blocks(struct super_block *sb,
{
if (UDF_SB_PARTFLAGS(sb, partition) & UDF_PART_FLAG_UNALLOC_BITMAP) {
return udf_bitmap_prealloc_blocks(sb, inode,
-
UDF_SB_PARTMAPS(sb)[partition].s_uspace.s_bitmap,
+
udf_sb_partmaps(sb)[partition].s_uspace.s_bitmap,
partition, first_block,
block_count);
} else if (UDF_SB_PARTFLAGS(sb, partition) &
UDF_PART_FLAG_UNALLOC_TABLE) {
return udf_table_prealloc_blocks(sb, inode,
-
UDF_SB_PARTMAPS(sb)[partition].s_uspace.s_table,
+
udf_sb_partmaps(sb)[partition].s_uspace.s_table,
partition, first_block,
block_count);
} else if (UDF_SB_PARTFLAGS(sb, partition) &
UDF_PART_FLAG_FREED_BITMAP) {
return udf_bitmap_prealloc_blocks(sb, inode,
-
UDF_SB_PARTMAPS(sb)[partition].s_fspace.s_bitmap,
+
udf_sb_partmaps(sb)[partition].s_fspace.s_bitmap,
partition, first_block,
block_count);
} else if (UDF_SB_PARTFLAGS(sb, partition) & UDF_PART_FLAG_FREED_TABLE)
{
return udf_table_prealloc_blocks(sb, inode,
-
UDF_SB_PARTMAPS(sb)[partition].s_fspace.s_table,
+
udf_sb_partmaps(sb)[partition].s_fspace.s_table,
partition, first_block,
block_count);
} else {
return 0;
@@ -845,20 +845,20 @@ inline int udf_new_block(struct super_block *sb,
if (UDF_SB_PARTFLAGS(sb, partition) & UDF_PART_FLAG_UNALLOC_BITMAP) {
ret = udf_bitmap_new_block(sb, inode,
-
UDF_SB_PARTMAPS(sb)[partition].s_uspace.s_bitmap,
+
udf_sb_partmaps(sb)[partition].s_uspace.s_bitmap,
partition, goal, err);
return ret;
} else if (UDF_SB_PARTFLAGS(sb, partition) &
UDF_PART_FLAG_UNALLOC_TABLE) {
return udf_table_new_block(sb, inode,
-
UDF_SB_PARTMAPS(sb)[partition].s_uspace.s_table,
+
udf_sb_partmaps(sb)[partition].s_uspace.s_table,
[PATCH 01/24] udf: fix coding style of super.c
fix coding style errors found by checkpatch:
- assignments in if conditions
- braces {} around single statement blocks
- no spaces after commas
- printks without KERN_*
- lines longer than 80 characters
before: total: 50 errors, 207 warnings, 1835 lines checked
after: total: 0 errors, 164 warnings, 1872 lines checked
all 164 warnings left are lines longer than 80 characters;
this file has too much indentation with really long expressions
to break all those lines
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/super.c | 295 +++
1 files changed, 166 insertions(+), 129 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 4360c7a..57788f1 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -33,8 +33,8 @@
* 10/17/98 added freespace count for "df"
* 11/11/98 gr added novrs option
* 11/26/98 dgb added fileset,anchor mount options
- * 12/06/98 blf really hosed things royally. vat/sparing support. sequenced
vol descs
- *rewrote option handling based on isofs
+ * 12/06/98 blf really hosed things royally. vat/sparing support. sequenced
+ *vol descs. rewrote option handling based on isofs
* 12/20/98 find the free space bitmap (if it exists)
*/
@@ -116,7 +116,7 @@ static struct kmem_cache *udf_inode_cachep;
static struct inode *udf_alloc_inode(struct super_block *sb)
{
struct udf_inode_info *ei;
- ei = (struct udf_inode_info *)kmem_cache_alloc(udf_inode_cachep,
GFP_KERNEL);
+ ei = kmem_cache_alloc(udf_inode_cachep, GFP_KERNEL);
if (!ei)
return NULL;
@@ -561,47 +561,52 @@ static int udf_vrs(struct super_block *sb, int silent)
/* Look for ISO descriptors */
vsd = (struct volStructDesc *)(bh->b_data +
- (sector & (sb->s_blocksize -
1)));
+ (sector & (sb->s_blocksize - 1)));
if (vsd->stdIdent[0] == 0) {
brelse(bh);
break;
- } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_CD001,
VSD_STD_ID_LEN)) {
+ } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_CD001,
+ VSD_STD_ID_LEN)) {
iso9660 = sector;
switch (vsd->structType) {
case 0:
udf_debug("ISO9660 Boot Record found\n");
break;
case 1:
- udf_debug
- ("ISO9660 Primary Volume Descriptor
found\n");
+ udf_debug("ISO9660 Primary Volume Descriptor "
+ "found\n");
break;
case 2:
- udf_debug
- ("ISO9660 Supplementary Volume Descriptor
found\n");
+ udf_debug("ISO9660 Supplementary Volume "
+ "Descriptor found\n");
break;
case 3:
- udf_debug
- ("ISO9660 Volume Partition Descriptor
found\n");
+ udf_debug("ISO9660 Volume Partition Descriptor "
+ "found\n");
break;
case 255:
- udf_debug
- ("ISO9660 Volume Descriptor Set Terminator
found\n");
+ udf_debug("ISO9660 Volume Descriptor Set "
+ "Terminator found\n");
break;
default:
udf_debug("ISO9660 VRS (%u) found\n",
vsd->structType);
break;
}
- } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_BEA01,
VSD_STD_ID_LEN)) {
- } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_TEA01,
VSD_STD_ID_LEN)) {
+ } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_BEA01,
+ VSD_STD_ID_LEN))
+ ; /* nothing */
+ else if (!strncmp(vsd->stdIdent, VSD_STD_ID_TEA01,
+ VSD_STD_ID_LEN)) {
brelse(bh);
break;
- } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_NSR02,
VSD_STD_ID_LEN)) {
+ } else if (!strncmp(vsd->stdIdent, VSD_STD_ID_NSR02,
+ VSD_STD_ID_LEN))
nsr02 =
[PATCH 02/24] udf: rename UDF_SB to udf_sb
rename UDF_SB function to udf_sb
Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]>
CC: Ben Fennema <[EMAIL PROTECTED]>
CC: Jan Kara <[EMAIL PROTECTED]>
---
fs/udf/balloc.c | 12 ++--
fs/udf/ialloc.c |4 ++--
fs/udf/inode.c |6 +++---
fs/udf/super.c | 32
fs/udf/udf_sb.h | 42 +-
fs/udf/unicode.c |4 ++--
6 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
index ab26176..8374c91 100644
--- a/fs/udf/balloc.c
+++ b/fs/udf/balloc.c
@@ -144,7 +144,7 @@ static void udf_bitmap_free_blocks(struct super_block *sb,
kernel_lb_addr bloc, uint32_t offset,
uint32_t count)
{
- struct udf_sb_info *sbi = UDF_SB(sb);
+ struct udf_sb_info *sbi = udf_sb(sb);
struct buffer_head *bh = NULL;
unsigned long block;
unsigned long block_group;
@@ -214,7 +214,7 @@ static int udf_bitmap_prealloc_blocks(struct super_block
*sb,
uint16_t partition, uint32_t first_block,
uint32_t block_count)
{
- struct udf_sb_info *sbi = UDF_SB(sb);
+ struct udf_sb_info *sbi = udf_sb(sb);
int alloc_count = 0;
int bit, block, block_group, group_start;
int nr_groups, bitmap_nr;
@@ -276,7 +276,7 @@ static int udf_bitmap_new_block(struct super_block *sb,
struct udf_bitmap *bitmap, uint16_t partition,
uint32_t goal, int *err)
{
- struct udf_sb_info *sbi = UDF_SB(sb);
+ struct udf_sb_info *sbi = udf_sb(sb);
int newbit, bit = 0, block, block_group, group_start;
int end_goal, nr_groups, bitmap_nr, i;
struct buffer_head *bh = NULL;
@@ -411,7 +411,7 @@ static void udf_table_free_blocks(struct super_block *sb,
kernel_lb_addr bloc, uint32_t offset,
uint32_t count)
{
- struct udf_sb_info *sbi = UDF_SB(sb);
+ struct udf_sb_info *sbi = udf_sb(sb);
uint32_t start, end;
uint32_t elen;
kernel_lb_addr eloc;
@@ -620,7 +620,7 @@ static int udf_table_prealloc_blocks(struct super_block *sb,
struct inode *table, uint16_t partition,
uint32_t first_block, uint32_t block_count)
{
- struct udf_sb_info *sbi = UDF_SB(sb);
+ struct udf_sb_info *sbi = udf_sb(sb);
int alloc_count = 0;
uint32_t elen, adsize;
kernel_lb_addr eloc;
@@ -685,7 +685,7 @@ static int udf_table_new_block(struct super_block *sb,
struct inode *table, uint16_t partition,
uint32_t goal, int *err)
{
- struct udf_sb_info *sbi = UDF_SB(sb);
+ struct udf_sb_info *sbi = udf_sb(sb);
uint32_t spread = 0x, nspread = 0x;
uint32_t newblock = 0, adsize;
uint32_t elen, goal_elen = 0;
diff --git a/fs/udf/ialloc.c b/fs/udf/ialloc.c
index 636d8f6..92dc9ae 100644
--- a/fs/udf/ialloc.c
+++ b/fs/udf/ialloc.c
@@ -31,7 +31,7 @@
void udf_free_inode(struct inode *inode)
{
struct super_block *sb = inode->i_sb;
- struct udf_sb_info *sbi = UDF_SB(sb);
+ struct udf_sb_info *sbi = udf_sb(sb);
/*
* Note: we must free any quota before locking the superblock,
@@ -61,7 +61,7 @@ void udf_free_inode(struct inode *inode)
struct inode *udf_new_inode(struct inode *dir, int mode, int *err)
{
struct super_block *sb = dir->i_sb;
- struct udf_sb_info *sbi = UDF_SB(sb);
+ struct udf_sb_info *sbi = udf_sb(sb);
struct inode *inode;
int block;
uint32_t start = UDF_I_LOCATION(dir).logicalBlockNum;
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 1178ae0..5afa19e 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1133,13 +1133,13 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
if (inode->i_uid == -1 ||
UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_UID_IGNORE) ||
UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_UID_SET))
- inode->i_uid = UDF_SB(inode->i_sb)->s_uid;
+ inode->i_uid = udf_sb(inode->i_sb)->s_uid;
inode->i_gid = le32_to_cpu(fe->gid);
if (inode->i_gid == -1 ||
UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_GID_IGNORE) ||
UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_GID_SET))
- inode->i_gid = UDF_SB(inode->i_sb)->s_gid;
+ inode->i_gid = udf_sb(inode->i_sb)->s_gid;
inode->i_nlink = le16_to_cpu(fe->fileLinkCount);
if (!inode->i_nlink)
@@ -1149,7 +1149,7 @@ static void udf_fill_inode(struct inode *inode, struct
buffer_head *bh)
UDF_I_LENEXTENTS(inode) = inode->i_size;
inode->i_mode = udf_convert_permissions(fe);
-
[PATCH 00/24] udf: convert super_block macros to functions
Hi This patchset converts macros related to super_block handling into functions. Besides that it fixes some sparse warnings (23rd and 24th), improves coding style (1st) and fixes error handling (19th). Note that udf files has really long lines and these patches won't validate by checkpatch. I'm going to do more cleanups later. PS: This is the first time I use git-send-email - tell me if I do something wrong. Marcin Slusarz -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Arjan van de Ven wrote: On Sat, 22 Dec 2007 09:20:06 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: Arjan van de Ven wrote: Hi, Linus really wants the extended (4Kb) PCI configuration space (using MCFG acpi table etc) to be opt-in, since there's many issues with it and most drivers don't even use/need it. The idea behind opt-in is that if you don't use it, you don't get to suffer the bugs... Booted on my 64 bit test machine; sadly it has a defunct BIOS that doesn't have a working MCFG. From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: Make MMCONFIG space a driver opt-in There are many issues with using the extended PCI configuration space (CPU, Chipset and most of all BIOS bugs). This while the vast majority of drivers and devices don't even use/need to use the memory mapped access methods since they don't use the config space beyond the traditional 256 bytes. This patch makes accessing the extended config space a driver choice, via the pci_enable_ext_config(pdev) Yuck. And, Linus is just being silly. Wait a year then turn on MMCONFIG :) It took PCI MSI a while to mature, but is finally getting there. Do you hate the name or the concept? I'm certainly open for a better name Many problems: * even if driver not loaded, you might need to access extended capabilities * kernel hacker (me!) might request user to dump PCI config space to see what changes, after various experiments. we need to see that extended space, if it exists, even if driver not loaded. * this "mixed config access" model is new to Linux, after always having config access type be a global system attribute. It introduces new complexity and new inconsistency all over the place. * hardware makers will not test this weird "mixed access" model. You thought mmconfig was poorly tested? Well, why the hell choose something with even less testing behind it (and future likelihood of nil testing). Always-off is better than mixed access. Jeff -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Arjan van de Ven wrote: On Sat, 22 Dec 2007 20:30:58 +0100 Martin Mares <[EMAIL PROTECTED]> wrote: Hello! Just make it so. The name is fine, the concept is unavoidable. The people who complain are whiners that haven't ever had to deal with the fact that there are broken machines around. I complain as well as the maintainer of the pciutils. Breaking all userspace accesses to extended configuration space just because there is a couple of chipsets it's not "just a couple of chipsets", it's actually * a whole lot of bioses * at least one whole CPU generation * .. * .. Do you really want to code all of that into your userspace access code as well? That's silly. He clearly should not have to... just like he should not have to add code to figure out if a device is MMCONFIG-active or not. MMCONFIG should be all or none. System vendors sure as hell will not be testing this crazy mixed-access model. System vendors DO test the "always off" model, obviously, and the "always on" model is entering their testing regime as Vista certification looms and as Linux starts to find bugs. Just Say No to entering "hw vendor never ever tests it this way" land. Jeff -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Linus Torvalds wrote: On Sat, 22 Dec 2007, Arjan van de Ven wrote: On Sat, 22 Dec 2007 09:20:06 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: Yuck. And, Linus is just being silly. Wait a year then turn on MMCONFIG :) It took PCI MSI a while to mature, but is finally getting there. That _really_ doesn't work. Old machines don't go away. We can't just say "wait a year and turn on MMCONFIG", because all the broken machines WILL STILL EXIST. You are reinforcing my point :) The exact same thing can be said for PCI MSI machines that are broken. Outside of Intel machines, early PCI MSI life was yucky and broken. Time passed, we got a handle on the problem set, we quirked that problematic set of systems, and life moved on. And these days, we are benefitting from that -- most new hardware is MSI-capable if not MSIX-capable, and we are turning that on. Some day in the future MSI-only (no INTX) hardware will ship in volume, and we will already be adequately prepared for that day. But here the two items diverge: PCI MSI _can_ be an _option_ for most hardware, hence pci_enable_msi(). But the same cannot be said for MMCONFIG, for reasons outlined below... Do you hate the name or the concept? I'm certainly open for a better name Just make it so. The name is fine, the concept is unavoidable. The people who complain are whiners that haven't ever had to deal with the fact that there are broken machines around. For example, right now Jeff never sees the problem, because when MMCONFIG doesn't work, it's never his problem - nothing in the machine works. But if he has to add a "pci_enable_mmconfig()" to the drivers he maintains, he sees it as a _new_ problem, so he obviously thinks it's stupid: he was never impacted by the issues it fixed! I forcibly turn on mmconfig on all my machines, and monitor lkml, to make sure I'm aware of the extent of the problem -- and the extent of peoples' exaggeration of this problem. So it's natural for Jeff to not like it, but that doesn't make Jeff right in this case. It just means that Jeff never had to worry about it before, because as long as MMCONFIG wasn't per-driver, the problems it caused were never *his* problems. But that doesn't make them less of a problem. Doing it at the driver level fundamentally doesn't work: Regardless of whether a driver is loaded or not, you may NEED to see extended capabilities. The system may NEED to see those capabilities just to parse them for sane operation. And pciutils should be able to see all of config space, not just the Linus-sanitized portion of it. This will make debugging more difficult, for example, because "lspci -vvvxxx" will not be giving me the full "before" and "after" snapshots I need from users, to see if anything changes based on . I know when you look you see all sorts of brokenness. But you and I both know that will pass, with time. If its buggy, turn it off. If not, turn it on. All these hardware makers are paying attention and fixing errata; evidence of forward progress in that regard has already appeared even. Finally, this introduces a new per-device model for PCI config space accesses, something we have NEVER done before. PCI config space should always be all or none. If MMCONFIG is fucked, just turn it off completely. Having to deal with NEW issues brought on by this NEW per-device config space access model is stupid-by-design. Always-off is better than changing the access model from global to per-device. It is even MORE unlikely that hardware makers test the "mmconfig over here, type1 over there" mixed accesses. Linux should not go down that road. Always-off is better than mixed access models. Jeff -- 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: [Cbe-oss-dev] [announce] PS3 Linux Distributor's Starter Kit (v1.5.1) released
On Fri, 2007-12-21 at 13:39 -0800, Geoff Levand wrote: > An updated kboot image is here: > > http://www.kernel.org/pub/linux/kernel/people/geoff/cell/kboot-20071220.bld NFS booting seems to fail. After saying 'Mounting ...' for 30 seconds or so, it then says 'rpcbind: server 0.0.0.0 not responding, timed out'. -- 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: Major regression on hackbench with SLUB (more numbers)
[/me sneaks away from the family] On Sat, 22 Dec 2007, Willy Tarreau wrote: > On Sat, Dec 22, 2007 at 01:00:09PM -0800, Linus Torvalds wrote: > > On Sat, 22 Dec 2007, Theodore Tso wrote: > > > But sometimes when trying to eyeball what is going on, it's a lot > > > nicer just to use "cat /proc/slabinfo". > > > > .. and I call BS on this claim. > > [...] > > I can understand that it has to go away for technical reasons, but Ted > is right, please don't believe that nobody uses it just because you got > no complaint. While people are not likely to perform all computations > in scripts, at least they're used to find some quickly identifiable > patterns there. > I know when I'm looking for memory leaks, I've asked customers to give snapshots of slabinfo at periodic times (once a day even, matters how bad the leak is). This has been helpful in seeing if something did indeed leak. If you have a slab cache that constantly grows, and never shrinks, that's a good indication that something might be leaking. Not always, since there can be legitimate reasons for that, but sometimes it helps. But I still scratch my head when ever I need to touch sysfs. [/me runs back to the family] -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Greg KH wrote: But it is that device, and the driver that controls this device that cares about the extended config space. So it's fair to push this onto the driver if needed, instead of forcing the pci core to just blindly guess for all devices, and getting it wrong... Nothing is being forced to guess. You make sure the broken chipsets never enable mmconfig... just like we do for plenty of other errata. Jeff -- 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] (UPDATED) ecryptfs: check for existing key_tfm at mount time
On Sat, 22 Dec 2007 11:42:37 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > > It would all look a lot more solid if this locking was retained and both > > ecryptfs_tfm_exists() and ecryptfs_add_new_key_tfm() were designed to be > > called under key_tfm_list_mutex. > > Hmm good point, sorry for missing that. How's this look? key_tfm_list_mutex gets used in fs/ecryptfs/main.c but it is static in fs/ecryptfs/crypto.c -- 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 00/20] VM pageout scalability improvements
On Sun, 23 Dec 2007 01:57:32 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > Rik van Riel wrote: > > On large memory systems, the VM can spend way too much time scanning > > through pages that it cannot (or should not) evict from memory. Not > > only does it use up CPU time, but it also provokes lock contention > > and can leave large systems under memory presure in a catatonic state. > > I remember you mentioning that by large memory systems you mean systems > with at-least 128GB, does this definition still hold? It depends on the workload. Certain test cases can wedge the VM with as little as 16GB of RAM. Other workloads cause trouble at 32 or 64GB, with the system sometimes hanging for several minutes, all the CPUs in the pageout code and no actual swap IO. On systems of 128GB and more, we have seen systems hang in the pageout code overnight, without deciding what to swap out. > > This patch series improves VM scalability by: > > > > 1) making the locking a little more scalable > > > > 2) putting filesystem backed, swap backed and non-reclaimable pages > >onto their own LRUs, so the system only scans the pages that it > >can/should evict from memory > > > > 3) switching to SEQ replacement for the anonymous LRUs, so the > >number of pages that need to be scanned when the system > >starts swapping is bound to a reasonable number > > > > The noreclaim patches come verbatim from Lee Schermerhorn and > > Nick Piggin. I have not taken a detailed look at them yet and > > all I have done is fix the rejects against the latest -mm kernel. > > Is there a consolidate patch available, it makes it easier to test. I will make a big patch available with the next version. I have to upgrade my patch set to newer noreclaim patches from Lee and add a few small cleanups elsewhere. > > I am posting this series now because I would like to get more > > feedback, while I am studying and improving the noreclaim patches > > myself. > > What kind of tests show the problem? I'll try and review and test the code. The easiest test possible simply allocates a ton of memory and then touches it all. Enough memory that the system needs to go into swap. Once memory is full, you will see the VM scan like mad, with a big CPU spike (clearing the referenced bits off all pages) before it starts swapping out anything. That big CPU spike should be gone or greatly reduced with my patches. On really huge systems, that big CPU spike can be enough for one CPU to spend so much time in the VM that all the other CPUs join it, and the system goes under in a big lock contention fest. Besides, even single threadedly clearing the referenced bits on 1TB worth of memory can't result in acceptable latencies :) In the real world, users with large JVMs on their servers, which sometimes go a little into swap, can trigger this system. All of the CPUs end up scanning the active list, and all pages have the referenced bit set. Even if the system eventually recovers, it might as well have been dead. Going into swap a little should only take a little bit of time. -- 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: ACPI or radeon: spontaneous reboot regression
On Sunday, 23 of December 2007, Matt Mackall wrote: > With 2.6.24-rc2, plugging and unplugging power results in a sudden > reboot. After the reboot, the machine boots normally until it switches > to graphics mode, at which point the screen is scrambled. It may hang or > repeatedly reboot at this point. Easily repeatable after just a few plug > cycles. > > Switching back to 2.6.23-rc3-mm1, I can do a dozen plug cycles with no > problem. > > Machine is a Thinkpad R51, with R250: > > 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 > [Mobility FireGL 9000] (rev 02) Added to the list of reported regressions as: http://bugzilla.kernel.org/show_bug.cgi?id=9624 Thanks, 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: Linux 2.6.24-rc6
Hi; 21 Ara 2007 Cum tarihinde, Linus Torvalds şunları yazmıştı: > Here's to a merry christmas, doing the whole druidic festival around the > tree thing, With -rc6, dmesg shows following Unknown symbols; [...] [ 26.883635] Bluetooth: Core ver 2.11 [ 26.913123] hci_usb: Unknown symbol hci_suspend_dev [ 26.913155] hci_usb: Unknown symbol hci_free_dev [ 26.913495] hci_usb: Unknown symbol hci_resume_dev [ 26.913566] hci_usb: Unknown symbol hci_alloc_dev [ 26.913696] hci_usb: Unknown symbol hci_unregister_dev [ 26.913775] hci_usb: Unknown symbol hci_recv_fragment [ 26.913841] hci_usb: Unknown symbol hci_register_dev [ 26.914117] hci_usb: Unknown symbol hci_suspend_dev [ 26.914148] hci_usb: Unknown symbol hci_free_dev [ 26.914477] hci_usb: Unknown symbol hci_resume_dev [ 26.914548] hci_usb: Unknown symbol hci_alloc_dev [ 26.914678] hci_usb: Unknown symbol hci_unregister_dev [ 26.914757] hci_usb: Unknown symbol hci_recv_fragment [ 26.914823] hci_usb: Unknown symbol hci_register_dev [ 26.915070] hci_usb: Unknown symbol hci_suspend_dev [ 26.915101] hci_usb: Unknown symbol hci_free_dev [ 26.915429] hci_usb: Unknown symbol hci_resume_dev [ 26.915501] hci_usb: Unknown symbol hci_alloc_dev [ 26.915630] hci_usb: Unknown symbol hci_unregister_dev [ 26.915709] hci_usb: Unknown symbol hci_recv_fragment [ 26.915776] hci_usb: Unknown symbol hci_register_dev [ 26.928322] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 26.937433] ACPI: Thermal Zone [TZS0] (62 C) [ 26.942470] ACPI: Thermal Zone [TZS1] (66 C) [ 26.982668] NET: Registered protocol family 31 [ 26.982671] Bluetooth: HCI device and connection manager initialized [ 26.982675] Bluetooth: HCI socket layer initialized [ 27.043943] Bluetooth: HCI USB driver ver 2.9 [ 27.074386] usbcore: registered new interface driver hci_usb [...] A Google search found [1] and according to that old thread, its either a general module problem [2] or a module-init-tools (I'm using vanilla module-init-tools 3.3_pre11) problem [3]. I'm not sure whether its a user-space problem or these caused by bluetooth module's initialization phase so i decided to report LKML :). Although these shown in kern.log, bluetooth subsystem works without a problem. You can find .config and full dmesg output from [4] and if anything else is needed, please just say it. [1] http://osdir.com/ml/linux.bluez.devel/2004-10/msg00043.html [2] http://osdir.com/ml/linux.bluez.devel/2004-10/msg00047.html [3] http://osdir.com/ml/linux.bluez.devel/2004-10/msg00054.html [4] http://cekirdek.pardus.org.tr/~caglar/kernel/ Cheers -- S.Çağlar Onur <[EMAIL PROTECTED]> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! -- 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/
ACPI or radeon: spontaneous reboot regression
With 2.6.24-rc2, plugging and unplugging power results in a sudden reboot. After the reboot, the machine boots normally until it switches to graphics mode, at which point the screen is scrambled. It may hang or repeatedly reboot at this point. Easily repeatable after just a few plug cycles. Switching back to 2.6.23-rc3-mm1, I can do a dozen plug cycles with no problem. Machine is a Thinkpad R51, with R250: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 [Mobility FireGL 9000] (rev 02) (starting bisection) -- Mathematics is the supreme nostalgia of our time. -- 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: Major regression on hackbench with SLUB (more numbers)
> "IM" == Ingo Molnar <[EMAIL PROTECTED]> writes: IM> Distros will likely pick SLUB if there's no performance worries IM> and if it's the default. Fedora rawhide already uses SLUB. Actually, it seems to me that not only does Fedora rawhide use SLUB, but Fedora 8 and 7 use it as well. They don't have /proc/slabinfo and they all seem to have CONFIG_SLUB=y: > grep -r CONFIG_SLUB=y kernel kernel/devel/config-generic:CONFIG_SLUB=y kernel/F-7/configs/config-generic:CONFIG_SLUB=y kernel/F-8/config-generic:CONFIG_SLUB=y - J< -- 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: Major regression on hackbench with SLUB (more numbers)
On Sat, Dec 22, 2007 at 09:50:09PM +, Al Viro wrote: > On Sat, Dec 22, 2007 at 01:00:09PM -0800, Linus Torvalds wrote: > > > > Another problem with using /sys/slab is that it is downright *ugly*. > > > Why is it for example, that /sys/slab/dentry is a symlink to > > > ../slab/:a-160? > > > > That's the only really ugly thing there. Otherwise, it's pretty nice, but > > having a million files makes for problems when trying to send somebody > > else the full info. > > *raised brows* > > I would say that there's that really ugly thing with embedding kobject > into a struct with the lifetime rules of its own and then having that > struct kfree()d while kobject might still have references, but hey, > maybe it's just me and my lack of appreciation of the glory that is > sysfs. > > Al, too tired of ranting about sysfs being a major architecture > mistake and a recurring source of turds like that one... BTW, the fact that presence of that kobject is conditional makes life even uglier - we have to either kfree() or drop a reference to kobject leaving actual kfree() to its ->release(). While we are at it, when do we remove the symlinks? That got to add even more fun for the lifetime rules... Sigh... How does one set a script that would mail a warning upon git pull that introduces any instances of keyword from given set? I hadn't noticed that slub was using sysfs when it went into the tree back in May ;-/ -- 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: slabtop replacement was Re: Major regression on hackbench with SLUB (more numbers)
On 22/12/2007, Andi Kleen <[EMAIL PROTECTED]> wrote: > A manpage for slabinfo would be useful though. Anybody > volunteering to write one? > > -Andi That would be me. I'm a newbie and never wrote a man page before, so it will take a few days, but I'm bored and out of ideas for any new code for the moment being. Should be fun. Karol Swietlicki -- 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: Mysterious lockdep warning from the SCSI workqueue code
On Sat, 2007-12-22 at 23:56 +0100, Rafael J. Wysocki wrote:
> On Saturday, 22 of December 2007, James Bottomley wrote:
> > I've no idea why this is occurring:
> >
> > WARNING: at kernel/lockdep.c:700 look_up_lock_class()
> > Pid: 2068, comm: scsi_wq_3 Not tainted 2.6.24-rc6 #38
> > [] show_trace_log_lvl+0x1a/0x30
> > [] show_trace+0x12/0x20
> > [] dump_stack+0x6c/0x80
> > [] __lock_acquire+0x46d/0x10b0
> > [] lock_acquire+0x78/0xa0
> > [] run_workqueue+0x128/0x1d0
> > [] worker_thread+0x8c/0xf0
> > [] kthread+0x42/0x70
> > [] kernel_thread_helper+0x7/0x10
> > ===
> >
> > it looks to be happening on the initial workqueue.c:run_workqueue()
> >
> > spin_lock_irq(>lock);
> >
> > It's caused by lockdep.c:look_up_lock_class()
> >
> > WARN_ON_ONCE(class->name != lock->name);
> >
> > but I'm not entirely sure what this actually means, not fully
> > understanding lockdep classes and how we acquire them in scsi.
>
> I guess Ingo and/or Peter should have a look at this.
This makes me think of an invalid use of lockdep_set_class(). The
typical way to trigger this is:
struct lock_class_key my_keys[10];
struct my_obj *create_my_obj1()
{
...
spin_lock_init(_obj.lock);
lockdep_set_class(_obj.lock, my_keys + foo);
...
}
struct my_obj *create_my_obj2()
{
...
spin_lock_init(_obj.lock);
lockdep_set_class(_obj.lock, my_keys + bar);
...
}
This initializes _obj.lock to the same class (provides foo and bar
evaluate to the same), but give it a different name.
#define lockdep_set_class(lock, key) \
lockdep_init_map(&(lock)->dep_map, #key, key, 0)
The name is #key, so: "my_keys + foo" vs "my_keys + bar"
The possible fixes are:
- make key identical by changing the expression
- use lockdep_set_class_and_name() and specify a
consistent name by hand.
--
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: rt2x00 is sapmming my logs
On Saturday, 22 of December 2007, drago01 wrote: > On Dec 23, 2007 12:04 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > >[..] > > > The connection seems top work anyways so i do not think this is critical. > > > Thanks in advance for your time. > > > > I have created a bugzilla entry for this problem at: > > http://bugzilla.kernel.org/show_bug.cgi?id=9622 > > and added it to the list of reported regressions. > > rt2x00 has been merged in 2.6.24 (did not exist in 2.6.23) so its not > a regression. OK, I'll drop it from the regreesion list, but the issue remains. :-) Thanks, 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: rt2x00 is sapmming my logs
El Sun, 23 Dec 2007 00:04:42 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> escribió: > On Saturday, 22 of December 2007, Alejandro Riveira Fernández wrote: > > > I have created a bugzilla entry for this problem at: > http://bugzilla.kernel.org/show_bug.cgi?id=9622 > and added it to the list of reported regressions. Thanks! > > Thanks, > 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/ -- 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: rt2x00 is sapmming my logs
On Dec 23, 2007 12:04 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: >[..] > > The connection seems top work anyways so i do not think this is critical. > > Thanks in advance for your time. > > I have created a bugzilla entry for this problem at: > http://bugzilla.kernel.org/show_bug.cgi?id=9622 > and added it to the list of reported regressions. rt2x00 has been merged in 2.6.24 (did not exist in 2.6.23) so its not a regression. -- 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: rt2x00 is sapmming my logs
On Saturday, 22 of December 2007, Alejandro Riveira Fernández wrote: > > I have a rt2500pci card on an 64 bit system (Ubuntu) AMD X2 processor and i'm > trying latest vanilla kernels i've used a 2.6.24-rc5 kernel without mayor > issues > (except that i have to issue a sudo iwconfig wlan0 rate 54M because it allways > connect at 1Mbit and it is dog slow) but now with v2.6.24-rc6-83-g5b825ed i > have my dmesg spammed with: > > > [ 1122.323489] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > [ 1122.323491] Please file bug report to http://rt2x00.serialmonkey.com. > [ 1122.326139] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > [ 1122.326142] Please file bug report to http://rt2x00.serialmonkey.com. > [ 1122.327508] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > [ 1122.327511] Please file bug report to http://rt2x00.serialmonkey.com. > [ 1122.329405] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > [ 1122.329409] Please file bug report to http://rt2x00.serialmonkey.com. > [ 1122.332519] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > [ 1122.332522] Please file bug report to http://rt2x00.serialmonkey.com. > [ 1122.33] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > [ 1122.334447] Please file bug report to http://rt2x00.serialmonkey.com. > [ 1122.336847] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > [ 1122.336850] Please file bug report to http://rt2x00.serialmonkey.com. > [ 1122.338654] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > [ 1122.338657] Please file bug report to http://rt2x00.serialmonkey.com. > [ 1122.340844] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > [ 1122.340847] Please file bug report to http://rt2x00.serialmonkey.com. > [ 1122.343035] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > [ 1122.343038] Please file bug report to http://rt2x00.serialmonkey.com. > [ 1122.344301] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > [ 1122.344303] Please file bug report to http://rt2x00.serialmonkey.com. > [ 1122.347146] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > [ 1122.347148] Please file bug report to http://rt2x00.serialmonkey.com. > [ 1122.349381] phy0 -> rt2x00pci_write_tx_data: Error - Arrived at non-free > entry in the non-full queue 0. > > The connection seems top work anyways so i do not think this is critical. > Thanks in advance for your time. I have created a bugzilla entry for this problem at: http://bugzilla.kernel.org/show_bug.cgi?id=9622 and added it to the list of reported regressions. Thanks, 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/
[PATCH] fat: Editions to support fat_fallocate()
From: Steven Cavanagh <[EMAIL PROTECTED]>
Added support for fallocate for a msdos fat driver. This allows
preallocation of clusters to an inode before writes to reduce
file fragmentation
Signed-off-by: Steven.Cavanagh <[EMAIL PROTECTED]>
---
fs/fat/file.c | 45 +
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/fs/fat/file.c b/fs/fat/file.c
index 69a83b5..f753c6a 100644
--- a/fs/fat/file.c
+++ b/fs/fat/file.c
@@ -15,6 +15,7 @@ #include
#include
#include
#include
+#include
int fat_generic_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg)
@@ -312,8 +313,52 @@ int fat_getattr(struct vfsmount *mnt, st
}
EXPORT_SYMBOL_GPL(fat_getattr);
+/*
+ * preallocate space for a file. This implements fat fallocate inode
+ * operation, which gets called from sys_fallocate system call. User
+ * space requests len bytes at offset.
+ */
+long fat_fallocate(struct inode *inode, int mode, loff_t offset, loff_t len)
+{
+ int ret = 0;
+ loff_t filesize = inode->i_size;
+
+ /* preallocation to directories is currently not supported */
+ if (S_ISDIR(inode->i_mode)) {
+ printk(KERN_ERR
+ "fat_fallocate(): Directory prealloc not supported\n");
+ return -ENODEV;
+ }
+
+ if ((offset + len) <= MSDOS_I(inode)->mmu_private) {
+ printk(KERN_INFO
+ "fat_fallocate():Blocks already allocated\n");
+ return 0;
+ }
+
+ if ((offset + len) > MSDOS_I(inode)->mmu_private) {
+
+ mutex_lock(>i_mutex);
+ ret = fat_cont_expand(inode, (offset + len));
+ if (ret) {
+ printk(KERN_ERR
+ "fat_fallocate():fat_cont_expand() error\n");
+ mutex_unlock(>i_mutex);
+ return ret;
+ }
+ mutex_unlock(>i_mutex);
+ }
+ if (mode & FALLOC_FL_KEEP_SIZE) {
+ mutex_lock(>i_mutex);
+ i_size_write(inode, filesize);
+ mutex_unlock(>i_mutex);
+ }
+ return ret;
+}
+
const struct inode_operations fat_file_inode_operations = {
.truncate = fat_truncate,
.setattr= fat_notify_change,
.getattr= fat_getattr,
+ .fallocate = fat_fallocate,
};
--
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/3] (Resend part #1) Add the RapidIO support to powerpc architecture with memory mapping support.
Hi,
This is a very large patch. It may be easier to review if it could be
split on some logical way, that is at all possible (I don't know either
way). This is just a quick note about some more trivial things.
On Fri, 21 Dec 2007 17:58:43 +0800 Zhang Wei <[EMAIL PROTECTED]> wrote:
>
> +struct rio_priv {
> + volatile void __iomem *regs_win;
> + volatile struct rio_atmu_regs __iomem *atmu_regs;
> + volatile struct rio_atmu_regs __iomem *maint_atmu_regs;
> + volatile struct rio_atmu_regs __iomem *dbell_atmu_regs;
> + volatile void __iomem *dbell_win;
> + volatile void __iomem *maint_win;
> + volatile struct rio_msg_regs __iomem *msg_regs;
Paulus has said that any pointer marked __iomem does not need to be
volatile ...
> +static int of_cells_get(struct device_node *np, const char *str)
> +{
> + struct device_node *tmp = NULL;
> + const int *var = NULL;
These initializations are unnecessary.
> + var = of_get_property(np, str, NULL);
> + tmp = of_get_parent(np);
> +
> + while (!var && tmp) {
> + var = (int *)of_get_property(tmp, str, NULL);
While I applaud the number of casts remove by this patch, this one is an
unnecessary addition.
> + of_node_put(tmp);
> + tmp = of_get_parent(np);
You should do the above two line in the opposite order. Also do you
really want to keep getting the parent of the same node over and over
(i.e. you never change np)?
> + }
You probably want a final of_node_put(tmp).
> + INFO("Phy type: ");
> + switch (phy_type) {
> + case RIO_PHY_SERIAL:
> + printk("serial\n");
> + break;
> + case RIO_PHY_PARALLEL:
> + printk("parallel");
Missing \n
> + port = kzalloc(sizeof(struct rio_mport), GFP_KERNEL);
> + if (!port) {
> + ERR("Can't alloc memory for 'port'\n");
> + rc = -ENOMEM;
> + goto err;
> + }
> port->id = 0;
> port->index = 0;
These two could go as you just allocated zeroed memory.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpRi7Fgxso5X.pgp
Description: PGP signature
Re: Mysterious lockdep warning from the SCSI workqueue code
On Saturday, 22 of December 2007, James Bottomley wrote: > I've no idea why this is occurring: > > WARNING: at kernel/lockdep.c:700 look_up_lock_class() > Pid: 2068, comm: scsi_wq_3 Not tainted 2.6.24-rc6 #38 > [] show_trace_log_lvl+0x1a/0x30 > [] show_trace+0x12/0x20 > [] dump_stack+0x6c/0x80 > [] __lock_acquire+0x46d/0x10b0 > [] lock_acquire+0x78/0xa0 > [] run_workqueue+0x128/0x1d0 > [] worker_thread+0x8c/0xf0 > [] kthread+0x42/0x70 > [] kernel_thread_helper+0x7/0x10 > === > > it looks to be happening on the initial workqueue.c:run_workqueue() > > spin_lock_irq(>lock); > > It's caused by lockdep.c:look_up_lock_class() > > WARN_ON_ONCE(class->name != lock->name); > > but I'm not entirely sure what this actually means, not fully > understanding lockdep classes and how we acquire them in scsi. I guess Ingo and/or Peter should have a look at this. Thanks, 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: Problems on booting
On Saturday, 22 of December 2007, werner wrote: > There seems to have two regressions between the kernels from yesterday and > before-yesterday > On the kernel -git7 what didnt happened on -git6 > > 1) My hard disk is /dev/hda, but when I have an usb key sticked in /dev/sba, I guess you mean /dev/sda? > and run lilo then, then it dont boot but give L99 99 99 99 ... error. When I > remove the usb stick from /dev/sba , and run then #lilo , then the result > boots. This problem was not present at the -git6 kernel > > 2) The boot stops / hangs on hardware detection of SCSI. I have an Initio > INI-9X00U/UW. The last messages during boot are, that it's verifying i91u > scsi2 , then the boot hangs. When I put the pci=off kernel option, then the > boot process continues (but with this, by other reasons, my computer works > only half, so that this is unpracticable). This problem also didnt > happens with the -git6 kernelThis problem happens only on one of my two > computers, because the other has no SCSI card inside, that computer boots > normally. I have opened a bugzilla entry at http://bugzilla.kernel.org/show_bug.cgi?id=9621 and added it to the list of reported regressions. Thanks, 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: [RFT] Port 0x80 I/O speed
Rene Herman wrote on 12-12-07 00:31: Good day. Would some people on x86 (both 32 and 64) be kind enough to compile and run the attached program? This is about testing how long I/O port access to port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting. Compiled as you wished. And here are the results from 10 iterations...: cycles: out 1965, in 1263 cycles: out 1968, in 1251 cycles: out 1957, in 1257 cycles: out 1992, in 1253 cycles: out 1959, in 1248 cycles: out 1965, in 1264 cycles: out 1957, in 1256 cycles: out 1959, in 1248 cycles: out 1962, in 1298 cycles: out 1962, in 1275 Linux skyscraper 2.6.23.11 #1 SMP Sun Dec 16 11:54:12 CET 2007 i686 GNU/Linux 32bits system processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz stepping: 7 cpu MHz : 2400.182 cache size : 4096 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr s bogomips: 4802.73 clflush size: 64 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz stepping: 7 cpu MHz : 2400.182 cache size : 4096 KB physical id : 0 siblings: 4 core id : 1 cpu cores : 4 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr s bogomips: 10614.49 clflush size: 64 processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz stepping: 7 cpu MHz : 2400.182 cache size : 4096 KB physical id : 0 siblings: 4 core id : 2 cpu cores : 4 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr s bogomips: 4800.17 clflush size: 64 processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz stepping: 7 cpu MHz : 2400.182 cache size : 4096 KB physical id : 0 siblings: 4 core id : 3 cpu cores : 4 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr s bogomips: 4800.17 clflush size: 64 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.24-rc6] pdflush still stuck in D state regression
On Saturday, 22 of December 2007, Tvrtko A. Ursulin wrote: > > Hi, Hi, > As it was in this bug report: http://bugzilla.kernel.org/show_bug.cgi?id=9441 I have reopened http://bugzilla.kernel.org/show_bug.cgi?id=9291 . Please update add the new information in there. > I am still not sure it is a duplicate because it has nothing to do with > reiserfs on > my systems. Here is the latest trace: > > pdflush S 0 139 2 > 0046 eba01fc4 b0155a80 b0155b2c > eb82 >eaab6fc0 b02aa388 b034d9b0 b034d9b0 fffb6e4a fffc > b012f0d2 >b012f090 b0104b6f eb817f44 > > Call Trace: > [] pdflush+0x0/0x210 > [] pdflush+0xac/0x210 > [] schedule+0x168/0x2e0 > [] kthread+0x42/0x70 > [] kthread+0x0/0x70 > [] kernel_thread_helper+0x7/0x18 > === > pdflush D 00140f4c 0 140 2 >b02af660 0046 eba03f10 00140f4c 444d 000f22fd b02aa9a9 > eb5e092c >eba03f74 b03cbfe8 b03cbfe8 00140f4c b0124700 eaab7500 b03cbd80 > b02aa9a4 >6c666470 00687375 008c 0064 b034da20 > b02aa20b > Call Trace: > [] schedule_timeout+0x49/0xc0 > [] process_timeout+0x0/0x10 > [] schedule_timeout+0x44/0xc0 > [] __sched_text_start+0xb/0x20 > [] congestion_wait+0x73/0x90 > [] autoremove_wake_function+0x0/0x50 > [] wb_kupdate+0x95/0xe0 > [] pdflush+0x0/0x210 > [] pdflush+0x10a/0x210 > [] wb_kupdate+0x0/0xe0 > [] kthread+0x42/0x70 > [] kthread+0x0/0x70 > [] kernel_thread_helper+0x7/0x18 > === Thanks, 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] fat: Editions to support fat_fallocate()
Thanks Steve, comments below.
On 12/22/07, Steven Cavanagh <[EMAIL PROTECTED]> wrote:
> From: Steven Cavanagh <[EMAIL PROTECTED]>
>
> Added support for fallocate for a msdos fat driver. This allows
> preallocation of clusters to an inode before writes to reduce
> file fragmentation
Not technically true. This doesn't make any guarantees about
fragmentation (even if in general it works pretty well). To really
reduce fragmentation, then cluster allocation needs to be made smarter
so it goes looking for contiguous clusters when allocating, but that's
a task for a separate patch. Please adjust your description.
Also, please briefly describe the testing that you've performed.
More comments below.
> Signed-off-by: Steven.Cavanagh <[EMAIL PROTECTED]>
> ---
>
> fs/fat/file.c | 45 +
> 1 files changed, 45 insertions(+), 0 deletions(-)
>
> diff --git a/fs/fat/file.c b/fs/fat/file.c
> index 69a83b5..f753c6a 100644
> --- a/fs/fat/file.c
> +++ b/fs/fat/file.c
> @@ -15,6 +15,7 @@ #include
> #include
> #include
> #include
> +#include
>
> int fat_generic_ioctl(struct inode *inode, struct file *filp,
> unsigned int cmd, unsigned long arg)
> @@ -312,8 +313,52 @@ int fat_getattr(struct vfsmount *mnt, st
> }
> EXPORT_SYMBOL_GPL(fat_getattr);
>
> +/*
> + * preallocate space for a file. This implements fat fallocate inode
> + * operation, which gets called from sys_fallocate system call. User
> + * space requests len bytes at offset.
> + */
> +long fat_fallocate(struct inode *inode, int mode, loff_t offset, loff_t len)
> +{
> + int ret = 0;
> + loff_t filesize = inode->i_size;
> +
> + /* preallocation to directories is currently not supported */
> + if (S_ISDIR(inode->i_mode)) {
> + printk(KERN_ERR
> + "fat_fallocate(): Directory prealloc not supported\n");
This printk is probably not needed, or at least make it a pr_debug()
> + return -ENODEV;
> + }
> +
> + if ((offset + len) <= MSDOS_I(inode)->mmu_private) {
> + printk(KERN_INFO
> + "fat_fallocate():Blocks already allocated\n");
Drop the printk() here. It will cause a write to the system log
everytime userspace does an unnecessary fat_fallocate(). That becomes
a performance hit which I don't think we want.
> + return 0;
> + }
> +
> + if ((offset + len) > MSDOS_I(inode)->mmu_private) {
> +
> + mutex_lock(>i_mutex);
> + ret = fat_cont_expand(inode, (offset + len));
> + if (ret) {
> + printk(KERN_ERR
> + "fat_fallocate():fat_cont_expand() error\n");
> + mutex_unlock(>i_mutex);
> + return ret;
> + }
> + mutex_unlock(>i_mutex);
> + }
> + if (mode & FALLOC_FL_KEEP_SIZE) {
> + mutex_lock(>i_mutex);
> + i_size_write(inode, filesize);
> + mutex_unlock(>i_mutex);
> + }
Race condition. The file is increased in size and then returned to
the original size if FALLOC_FL_KEEP_SIZE is set, but the lock is
dropped then reobtained between increasing the size and restoring to
the original. Another file operation can occur between the two
operations. Badness!
However, digging further, when FALLOC_FL_KEEP_SIZE is set, I don't
think fat_cont_expand() has the behaviour that we want to implement.
When that flag is set, I think we simply want to add clusters
associated with the file to the FAT. We don't want to clear them or
map them into the page cache yet (that should be done when the
filesize is increased for real).
I believe a call to fat_allocate_clusters() is all that is needed in
this case. Hirofumi, please correct me if I'm wrong.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
--
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: Major regression on hackbench with SLUB (more numbers)
On Sat, Dec 22, 2007 at 01:00:09PM -0800, Linus Torvalds wrote: > > > On Sat, 22 Dec 2007, Theodore Tso wrote: > > > > I have a general problem with things in /sys/slab, and that's just > > because they are *ugly*. So yes, you can write ugly shell scripts > > like this to get out information: > > [ script deleted ] > > > But sometimes when trying to eyeball what is going on, it's a lot > > nicer just to use "cat /proc/slabinfo". > > .. and I call BS on this claim. > > /proc/slabinfo was (and is) totally pointless for "trying to eyeball > what's going on". The output is totally unreadable, and useless. You end > up with exactly the same script as above, except it reads as > > cat /proc/slabinfo | (read headerline > while read name active num objsize objsperslab pagesperslab rest > do > realsize=$(( nul * objsize )) > size=$(( active * objsize )) > .. exact same rest of loop .. > done | sort -n | .. > > so no, "cat /proc/slabinfo" was almost never practical on its own. > > The *one* advantage it does have is that you can forward it to others. > That's a big advantage. But no, it wasn't ever readable for eyeballing, > because it doesn't even give you a memory usage thing (just "number of > objects and object size" as separate numbers). I don't agree with you Linus. I'm one of those used to quickly take a look at its contents when I don't know where all my memory has gone. I know by experience that if I find 6-digit values in dentry_cache or inode_cache, all I was looking for is there, and that's enough for a quick diag. It doesn't give anything accurate, but it's very useful to quickly diag out some problems on production systems. It was this week that I noticed for the first time that slabinfo did not exist anymore, and did not know what replaced it. Lacking time, I finally gave up and *supposed* that the memory was eaten by the usual suspects. I can understand that it has to go away for technical reasons, but Ted is right, please don't believe that nobody uses it just because you got no complaint. While people are not likely to perform all computations in scripts, at least they're used to find some quickly identifiable patterns there. Willy -- 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: Major regression on hackbench with SLUB (more numbers)
On Sat, Dec 22, 2007 at 01:00:09PM -0800, Linus Torvalds wrote: > > Another problem with using /sys/slab is that it is downright *ugly*. > > Why is it for example, that /sys/slab/dentry is a symlink to > > ../slab/:a-160? > > That's the only really ugly thing there. Otherwise, it's pretty nice, but > having a million files makes for problems when trying to send somebody > else the full info. *raised brows* I would say that there's that really ugly thing with embedding kobject into a struct with the lifetime rules of its own and then having that struct kfree()d while kobject might still have references, but hey, maybe it's just me and my lack of appreciation of the glory that is sysfs. Al, too tired of ranting about sysfs being a major architecture mistake and a recurring source of turds like that 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Sat, Dec 22, 2007 at 08:02:49AM -0800, Arjan van de Ven wrote: > even then.. it's technically not correct; you're not supposed to mix access > types for the same device.. > Just doing opt-in also allows us to do quirks (forbid access) as well. I think what this specification means is that you can't mix both _at the same time_. ie, doing a type 1 cycle, then before it returns, do an mmconfig cycle. We never try to do that because there's a spinlock to prevent more than one config space access at a time. It *has* to work to do them sequentially -- for example, the BIOS may do type1 config accesses, then the OS may do mmconfig. I've occasionally wondered if that spinlock needs to get split up, but for the amount of pain that could ensue, I can't imagine it ever being worthwhile. -- Intel are signing my paycheques ... these opinions are still mine "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: Major regression on hackbench with SLUB (more numbers)
On Sat, 22 Dec 2007, Theodore Tso wrote: > > I have a general problem with things in /sys/slab, and that's just > because they are *ugly*. So yes, you can write ugly shell scripts > like this to get out information: [ script deleted ] > But sometimes when trying to eyeball what is going on, it's a lot > nicer just to use "cat /proc/slabinfo". .. and I call BS on this claim. /proc/slabinfo was (and is) totally pointless for "trying to eyeball what's going on". The output is totally unreadable, and useless. You end up with exactly the same script as above, except it reads as cat /proc/slabinfo | (read headerline while read name active num objsize objsperslab pagesperslab rest do realsize=$(( nul * objsize )) size=$(( active * objsize )) .. exact same rest of loop .. done | sort -n | .. so no, "cat /proc/slabinfo" was almost never practical on its own. The *one* advantage it does have is that you can forward it to others. That's a big advantage. But no, it wasn't ever readable for eyeballing, because it doesn't even give you a memory usage thing (just "number of objects and object size" as separate numbers). But the "everything in one file" indubitably did make it a lot easier for just attaching it to bug-reports. > Another problem with using /sys/slab is that it is downright *ugly*. > Why is it for example, that /sys/slab/dentry is a symlink to > ../slab/:a-160? That's the only really ugly thing there. Otherwise, it's pretty nice, but having a million files makes for problems when trying to send somebody else the full info. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Testing RAM from userspace / question about memmap= arguments
On Sun 2007-12-23 07:06:58, David Newall wrote: > Pavel Machek wrote: >> memtest has following problems: >> >> 0) it is kind of hard to run memtest over ssh >> > > It's kind of hard to run anything over SSH if it has to be run before > userspace is up. But the kernel can collect results from a modified > memtest, after it chains back. memtest can be ran from userspace, that's the point. >> 1) if linux fixes some problem with PCI quirk or microcode >> upload, memtest will not see the fix >> > > What are you saying? Linux is going to fix faulty RAM? Yes, that's what CPU microcode update is for. And I want to test my RAM with up-to-date microcode. >> 2) if memory only fails while something else happens (DMA to >> other piece of memory? Hard disk load glitching powre >> supply?), memtest will not see the problem. > > These are not RAM faults. The very last thing you want is evidence that > you've got a faulty piece of RAM when the fault is actually a hard disk > glitch! No, it may be power supply leading to RAM problems. Yes, I want to detect that. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Testing RAM from userspace / question about memmap= arguments
David Newall wrote: Pavel Machek wrote: On Sat 2007-12-22 13:42:47, Richard D wrote: Cant you, modify bootmem allocator to test with memtest patterns and then use kexec (as Pavel suggested) to test the one where kernel was sitting earlier? I do not think you need to modify anything in kernel. Just use /dev/mem to test areas that kernel doesn't see, then kexec into place you already tested, and test the rest. That's still an insufficient test. One failure mode is writes at one location corrupting cells at another. The idea of wanting to do comprehensive and robust memory testing from within the operating system seems dubious at best, to me. Well if we're trying to be thorough, either way is flawed - you can't possibly test pathologically-misbehaving memory from code running from inside of it, you'd want some kind of non-uniform memory arrangement to do that properly. memtest86's value is that it at least *tries* to work in this environment by dynamically relocating itself, but its memory testing algorithms aren't the hard bit. Also I'm not necessarily interested in *which* section of which DIMM is faulty, just a yes or no is enough so I can send the faulty ones back to the shop. I don't agree that adding a network stack to memtest86's bare kernel is going to be easier than working out how to get Linux to do the same job, with its luxurious programming environment. I can already automate memtest via serial consoles, power cycling, network booting and so on but it's ugly. I will report back in the new year when I've had a chance to play with our collection of dodgy hardware. -- Matthew -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
On Sat, 2007-12-22 at 04:31 -0800, Arjan van de Ven wrote: > Hi, > > Linus really wants the extended (4Kb) PCI configuration space (using MCFG > acpi table etc) to be opt-in, since there's many issues with it and most > drivers don't even use/need it. The idea behind opt-in is that if you don't > use it, you don't get to suffer the bugs... > > Booted on my 64 bit test machine; sadly it has a defunct BIOS that doesn't > have a working MCFG. > > > From: Arjan van de Ven <[EMAIL PROTECTED]> > Subject: Make MMCONFIG space a driver opt-in > > There are many issues with using the extended PCI configuration space > (CPU, Chipset and most of all BIOS bugs). This while the vast majority of > drivers > and devices don't even use/need to use the memory mapped access methods since > they > don't use the config space beyond the traditional 256 bytes. > > This patch makes accessing the extended config space a driver choice, via the > > pci_enable_ext_config(pdev) > > API function; drivers that want/need the extended configuration space should > call this. > (a separate patch will be posted to add this function call to the driver that > uses this) That doesn't look like the right approach to me. The extended config space is generally used by PCI capabilities. So you end up in a situation where part of the capabilities will be invisible until somebody calls your new API, which might affect generic code in some cases beyond simply what a driver is supposed to do. I think best is to have your low level config ops switch between indirect and MM depending on the requested register offset. Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH] adding wistron_btns support for X86_64 systems.
(CC'ing linux-input, as that is the relevant subsystem list for wistron-btns). Rémi Hérilier wrote: > To use my previous patch (wistron_btns support for fujitsu-siemens amilo > pro edition v3505) with my laptop, I need to make the wistron module > compile for x86_64. It is based on Linux 2.4.24-rc4 too. NAK. You cannot make 32 bit BIOS calls in a 64 bit OS. This will (and does) segfault on x86-64 (tested on my Aspire 5020, where call_bios wistron-btns just segfaults on x86-64 with this patch). This is a known issue, and the reason why wistron-btns (and the out-of-tree acerhk) have not been ported to x86-64. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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: Testing RAM from userspace / question about memmap= arguments
Pavel Machek wrote: memtest has following problems: 0) it is kind of hard to run memtest over ssh It's kind of hard to run anything over SSH if it has to be run before userspace is up. But the kernel can collect results from a modified memtest, after it chains back. 1) if linux fixes some problem with PCI quirk or microcode upload, memtest will not see the fix What are you saying? Linux is going to fix faulty RAM? The point with testing RAM is you *want* to see it fail; you don't want Linux to fix it. 2) if memory only fails while something else happens (DMA to other piece of memory? Hard disk load glitching powre supply?), memtest will not see the problem. These are not RAM faults. The very last thing you want is evidence that you've got a faulty piece of RAM when the fault is actually a hard disk glitch! -- 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] Make MMCONFIG space (extended PCI config space) a driver opt-in issue
Hello! > it's not "just a couple of chipsets", it's actually > * a whole lot of bioses > * at least one whole CPU generation > * .. > * .. > > Do you really want to code all of that into your userspace access code as > well? No, I certainly don't. But I expect this to be handled reasonably in the kernel. If I understand the proposed patch correctly, it's only swepping the problem under the carpet -- if you have one of the malfunctioning systems and you happen to load a driver which wants to use the extended config space, it crashes anyway. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth It said, "Insert disk #3," but only two will fit! -- 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] opt the sky2 driver into using extended config space
On Sat, 22 Dec 2007 04:35:59 -0800 Arjan van de Ven <[EMAIL PROTECTED]> wrote: > From: Arjan van de Ven <[EMAIL PROTECTED]> > Subject: opt the sky2 driver into using extended config space > > So far, the sky2 driver is the only one I've identified (with a quick grep) > that actually would be using extended configuration space; the patch below > adds the enablement of this to the driver. > > Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED] Current driver uses the drivers memory map access to PCI config space to avoid all the extra config space access issues. So this patch is not needed. -- 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/
