Re: [PATCH 2/2] sysfs: fix race condition around sd->s_dentry, take#2
Tejun Heo wrote: > Tejun Heo wrote: >> Greg KH wrote: >>> On Mon, May 21, 2007 at 10:31:01AM +0530, Maneesh Soni wrote: On Thu, May 17, 2007 at 08:16:10PM +0200, Tejun Heo wrote: > Allowing attribute and symlink dentries to be reclaimed means > sd->s_dentry can change dynamically. However, updates to the field > are unsynchronized leading to race conditions. This patch adds > sysfs_lock and use it to synchronize updates to sd->s_dentry. > > Due to the locking around ->d_iput, the check in sysfs_drop_dentry() > is complex. sysfs_lock only protect sd->s_dentry pointer itself. The > validity of the dentry is protected by dcache_lock, so whether dentry > is alive or not can only be tested while holding both locks. > > This is minimal backport of sysfs_drop_dentry() rewrite in devel > branch. > > DONT APPLY JUST YET Looks ok to me.. I have tested it it but unfortunately I couldn't recreate the race without the patch also. It would be helpful if people actually seeing the race, provide the test results. Greg, please merge this one once we have some test results. >>> Can someone just resend it after those test results are in, with the >>> proper signed-off-by, so I know it's safe to apply? >> I'll resend with S-O-B after someone verifies it fixes the problem. > > Have been trying to reproduce the problem on the latest -rc but haven't > succeeded yet. It seems I lost my magic recipe for these races. Did > anyone succeed? Alright, overnight test finally hit the race condition. It takes me much longer now but the race condition is definitely still there. I'll verify each proposed patch and send it for 2.6.22 inclusion and if they're accepted to -stable. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] pata_it821x: sync with IDE it821x driver
Hello,
Bartlomiej Zolnierkiewicz wrote:
> * (partially) fix DMA in RAID mode
>
> Code intended to check DMA status was checking DMA command register.
> Moreover firmware seems to "forget" to set DMA capable bit for the
> slave device (at least in RAID mode but without ITE RAID volumes) so
> check device ID for DMA capable bit when deciding whether to use DMA
> and remove DMA status check completely.
>
> Thanks to Pavol Šimo for the bugreport and testing the initial fix.
Ah... This is the mysterious mwdma configuration in smart mode, right?
Thanks for fixing this.
> This change unfortunately still doesn't fix DMA in RAID mode (which
> works fine with IDE it821x) but Alan is working on the missing pieces
> (pata_it821x vs libata EH issues).
This is the lbal/nsect SRST problem, right?
> @@ -258,8 +259,14 @@ static void it821x_passthru_set_piomode(
> static const u8 pio_want[]= { ATA_66, ATA_66, ATA_66, ATA_66,
> ATA_ANY };
>
> struct it821x_dev *itdev = ap->private_data;
> + struct ata_device *pair = ata_dev_pair(adev);
> int unit = adev->devno;
> - int mode_wanted = adev->pio_mode - XFER_PIO_0;
> + int mode_wanted = adev->pio_mode;
> +
> + if (pair && adev->pio_mode > pair->pio_mode)
> + mode_wanted = pair->pio_mode;
> +
> + mode_wanted -= XFER_PIO_0;
I think this is better done by mode_filter callback which is guaranteed
to be called before any actual mode configuration is performed and in
device order (master then slave).
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Saturday June 9, [EMAIL PROTECTED] wrote: > Hi, > > As we know the forthcoming GPL V3 will be not compatible with the GPL V2 > and Linux Kernel is GPL V2 only. > So, another point is, which is previously mentioned by Linus and others, > that if it is decided to upgrade the Linux Kernel's License to GPL V3, > it is needed the permission of all the maintainers permission who > contributed to the Linux Kernel and there are a lot of lost or dead > maintainers. Which makes it impossible to get all the maintainers' > permission. You don't need the permission of maintainers. You need the permission of copyright owners. The two groups overlap, but are not the same. Dead people cannot own anything, even copyright. Their estate probably can. I don't think it is theoretically impossible to get everyone's permission, though it may be quite close to practically impossible. > But; if the Linux kernel should Dual-Licensed (GPL V2 and GPL V3), it > will allow us the both worlds' fruits like code exchanging from other > Open Source Projects (OpenSolaris etc.) that is compatible with GPL V3 > and not with GPL V2 and of course the opposite is applicable,too. > > So;at this situation, what is possibility to make the Linux Kernel > Dual-Licensed as I mentioned above and what is your opinions and > suggestions about this idea ? Dual licensing is no easier. It means it is licensed to be used under either license. You already have permission to use it under GPLv2. So to get a dual license, you precisely need to get access under GPLv3 i.e. to convince copyright owners to make that license grant. A thing that we have already agreed is at least "hard". NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]: add parameter "struct bin_attribute *" in .read/.write methods for sysfs binary attributes
From: Zhang Rui <[EMAIL PROTECTED]>
Well, first of all, I don't want to change so many files either.
What I do:
Adding a new parameter "struct bin_attribute *" in the
.read/.write methods for the sysfs binary attributes.
In fact, only the four lines change in fs/sysfs/bin.c and
include/linux/sysfs.h do the real work.
But I have to update all the files that use binary attributes
to make them compatible with the new .read and .write methods.
I'm not sure if I missed any. :(
Why I do this:
For a sysfs attribute, we can get a pointer pointing to the
struct attribute in the .show/.store method,
while we can't do this for the binary attributes.
I don't know why this is different, but this does make it not
so handy to use the binary attributes as the regular ones.
So I think this patch is reasonable. :)
Who benefits from it:
The patch that exposes ACPI tables in sysfs
requires such an improvement.
All the table binary attributes share the same .read method.
Parameter "struct bin_attribute *" is used to get
the table signature and instance number which are used to
distinguish different ACPI table binary attributes.
Without this parameter, we need to offer different .read methods
for different ACPI table binary attributes.
This is impossible as there are various ACPI tables on different
platforms, and we don't know what they are until they are loaded.
Signed-off-by: Zhang Rui <[EMAIL PROTECTED]>
---
Documentation/firmware_class/firmware_sample_firmware_class.c |2
drivers/base/firmware_class.c |4
drivers/firmware/dcdbas.c | 10 +-
drivers/firmware/dell_rbu.c | 25 +++--
drivers/i2c/chips/eeprom.c|3
drivers/i2c/chips/max6875.c |5 -
drivers/pci/hotplug/acpiphp_ibm.c |6 -
drivers/pci/pci-sysfs.c | 18 ++-
drivers/pcmcia/socket_sysfs.c |8 +
drivers/rapidio/rio-sysfs.c |6 -
drivers/rtc/rtc-ds1553.c | 10 +-
drivers/rtc/rtc-ds1742.c | 10 +-
drivers/s390/cio/chp.c| 10 +-
drivers/scsi/arcmsr/arcmsr_attr.c | 15 +--
drivers/scsi/ipr.c| 18 ++-
drivers/scsi/libsas/sas_expander.c| 16 ++-
drivers/scsi/lpfc/lpfc_attr.c | 12 +-
drivers/scsi/qla2xxx/qla_attr.c | 50 ++
drivers/spi/at25.c|6 -
drivers/video/aty/radeon_base.c |8 +
drivers/w1/slaves/w1_ds2433.c | 10 +-
drivers/w1/slaves/w1_therm.c |7 +
drivers/w1/w1.c | 12 +-
drivers/zorro/zorro-sysfs.c |5 -
fs/sysfs/bin.c|4
include/linux/sysfs.h |6 -
net/bridge/br_sysfs_br.c |5 -
27 files changed, 185 insertions(+), 106 deletions(-)
Index:
linux-2.6.22-rc4/Documentation/firmware_class/firmware_sample_firmware_class.c
===
---
linux-2.6.22-rc4.orig/Documentation/firmware_class/firmware_sample_firmware_class.c
2004-01-03 06:33:28.0 +0800
+++
linux-2.6.22-rc4/Documentation/firmware_class/firmware_sample_firmware_class.c
2007-06-08 13:25:33.0 +0800
@@ -78,6 +78,7 @@ static CLASS_DEVICE_ATTR(loading, 0644,
firmware_loading_show, firmware_loading_store);
static ssize_t firmware_data_read(struct kobject *kobj,
+ struct bin_attribute *bin_attr,
char *buffer, loff_t offset, size_t count)
{
struct class_device *class_dev = to_class_dev(kobj);
@@ -88,6 +89,7 @@ static ssize_t firmware_data_read(struct
return count;
}
static ssize_t firmware_data_write(struct kobject *kobj,
+ struct bin_attribute *bin_attr,
char *buffer, loff_t offset, size_t count)
{
struct class_device *class_dev = to_class_dev(kobj);
Index: linux-2.6.22-rc4/drivers/base/firmware_class.c
===
--- linux-2.6.22-rc4.orig/drivers/base/firmware_class.c 2004-01-03
06:33:28.0 +0800
+++ linux-2.6.22-rc4/drivers/base/firmware_class.c 2004-01-03
06:36:47.0 +0800
@@ -175,7 +175,7 @@ static ssize_t firmware_loading_store(st
static DEVICE_ATTR(loading, 0
Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Hi, As we know the forthcoming GPL V3 will be not compatible with the GPL V2 and Linux Kernel is GPL V2 only. So, another point is, which is previously mentioned by Linus and others, that if it is decided to upgrade the Linux Kernel's License to GPL V3, it is needed the permission of all the maintainers permission who contributed to the Linux Kernel and there are a lot of lost or dead maintainers. Which makes it impossible to get all the maintainers' permission. But; if the Linux kernel should Dual-Licensed (GPL V2 and GPL V3), it will allow us the both worlds' fruits like code exchanging from other Open Source Projects (OpenSolaris etc.) that is compatible with GPL V3 and not with GPL V2 and of course the opposite is applicable,too. So;at this situation, what is possibility to make the Linux Kernel Dual-Licensed as I mentioned above and what is your opinions and suggestions about this idea ? Regards, Tarkan Erimer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 8 Jun 2007 22:18:40 -0700 (PDT) [EMAIL PROTECTED] wrote: > the way I would describe the difference betwen AA and SELinux is: > > SELinux is like a default allow IPS system, you have to describe > EVERYTHING to the system so that it knows what to allow and what to stop. > > AA is like a default deny firewall, you describe what you want to happen, > and it blocks everything else without you even having to realize that it's > there. > > now I know that this isn't a perfect analyogy, that SELinux doesn't allow > something to happen unless it's been told to let it, but in terms of > complexity and the amount of work to configure things I think the analogy > is close. It must be drop dead simple to modify SELinux to be default-deny. That seems like it could be done in a small patch instead of requiring a huge new infrastructure. Let's assume that everyone agrees that AA is a good idea. Which parts of it absolutely can't be implemented in terms of SELinux? SELinux isn't fixed in stone, it can be altered if necessary to accommodate AA (as in the example above of becoming default-deny). Sean. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching
On Fri, 8 Jun 2007 22:38:57 -0700 (PDT) [EMAIL PROTECTED] wrote: > so are you suggesting that SELinux would call out to userspace for every > file open to get the label for that file? > No, i'm not. You must already have a kernel function in the current implementation of AA that decides the proper policy for each path. Why not use it to feed labels into SELinux. Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 7/8] fdmap v2 - implement sys_socket2
Davide Libenzi writes: > The only reason we use a floating base, is because Uli preferred to have > non-exactly predictable fd allocations. There no reason of re-doing the > same POSIX mistake all over again: Why must everything that makes things a bit simpler and more predictable for application programmers be called a "mistake"? Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching
On Sat, 9 Jun 2007, Sean wrote: the AA policy is also much easier to understand becouse you can look at it in pieces, understand that piece, and then forget it and move on to the next piece. Nobody is asking you to change the AA policy file. It lives in user space. But i fail to see the problem in translating it into SELinux terms for the user transparently. for example, if you write a policy for apache that limits it's access to it's log files, install directories, and document root. then you write a policy for your log analysis tool to access it's libraries, report directories (under the apache document root) and the apache log files (read only), these two policies are independant, you don't have to think about one while creating the other (which you would have to do if you had to put one label on apache binaries, another on normal web documents, a third on the reports, a fourth on the log files, and a fifth on the binaries for the log analysis tool. and this is ignoring any overlap in libraries!) Again, try to think outside the box a bit. This isn't about using SELinux as it exists today. But imagine an SELinux that would ask you to supply a security label for each file _instead_ of looking up that label itself. Wouldn't that let you implement everything you wanted while still using much of the SELinux infrastructure that is already in the kernel? so are you suggesting that SELinux would call out to userspace for every file open to get the label for that file? just off the top of my head what would all these kernel->userspace->kernel transitions do to performance? would SELinux give userspace the full path to that file? if so wouldn't it have to implement most of what AA adds to do this? if not how would userspace figure out what label to hand back without this info? how would SELinux figure out the permissions for the userspace Daemon? how would you change both the rules for labels in the kernel and the policy for assigning labels in userspace without any race conditions? AA also lets a sysadmin dip their toe in the water and just write a policy for Apache, not for anything else, then write a policy for firefox, then write a policy for their mail client, then for bittorrent, etc. there is no need or push to try and secure everything all at once, and no need to re-label files (and change any policies that used the old labels) when you discover a new interaction. And so it could remain; this is about implementation, not model. yes, you could add all the AA code to SELinux and then say that the result is implemented in SELinux, you may even save a little bit of code in some parts of it (but I would argue that you add more code in others, say for the userpace interface and userspace labeling code), but the result wouldn't be in the spirit of SELinux. it may be possible to write something that resembles AA in SELinux policy (once you solve the problem of how to label newly created files securely), but it's also possible to write a webserver in COBOL to run out of inetd, that doesn't mean that it makes any sort of sense to do either one. on the other hand, it may be a good idea. let's see how people really use AA once they have it available and the SELinux folks can work on duplicating the functionality, if they do then the existing AA interface could be phased out over time, or the internal implementation could change. but arguing that SELinux _may_ be able to do the job of AA _someday_ should not prevent AA from being included today (especially when so many of the SELinux developers are so opposed to the very concept of AA, which doesn't indicate that they are about to rush out and implement the pieces needed to make it work) David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 8 Jun 2007, Greg KH wrote: I still want to see a definition of the AA "model" that we can then use to try to implement using whatever solution works best. As that seems to be missing the current argument of if AA can or can not be implemented using SELinux or something totally different should be stopped. the way I would describe the difference betwen AA and SELinux is: SELinux is like a default allow IPS system, you have to describe EVERYTHING to the system so that it knows what to allow and what to stop. AA is like a default deny firewall, you describe what you want to happen, and it blocks everything else without you even having to realize that it's there. now I know that this isn't a perfect analyogy, that SELinux doesn't allow something to happen unless it's been told to let it, but in terms of complexity and the amount of work to configure things I think the analogy is close. the fact that the SELinux policy _will_ affect the entire systems means one of two things. 1. you have a policy that exactly describes how every part of the system operates or 2. you have a policy that's exessivly permissive in some parts of the system becouse 'that works' and you either don't understand that part of the system well enough, or don't have time to write a more complete policy. I would argue that with the number of files on a system nowdays (483,000 on my 'minimalistic' gentoo server, 442,000 on my slackware laptop, 800,000 on a ubuntu server at work) it's not possible to do #1, so any deployed policy (especially one done by a disto that needs to work for all it's users) is going to follow #2, frequently to the point where it's not really adding much security. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: JIT emulator needs
On 6/8/07, Alan Cox <[EMAIL PROTECTED]> wrote: > There is an SE Linux execmem restriction that enforces W^X. This depends on whatever SELinux rulesets you are running. Its just a good rule to have present that most programs shouldn't be self patching, and then label those that do differently. A marking in the executable would have made more sense. It is really broken having an unprivileged user being able to create whole new executables but unable to lift this restriction on those executables. In any case, the restriction is common and troublesome. > Sometimes it is very helpful to have the read/write mapping > be a fixed offset from the read/exec mapping. A power of 2 > can be especially desirable. mmap MAP_FIXED can do this but you need to know a lot about the memory layout of the system so it gets a bit platform specific. Yes. There are unportable programs, and UNPORTABLE ones. Memory layout can vary between vendor kernels, between normal and 32-on-64 situations, between two different C libraries... > Emulators often need a cheap way to change page permissions. mprotect(, range) rather than a page at a time. The kernel will do merging. Nope. This can happen rapidly and repeatedly to pages that are essentially random. The median length of a range will be a page or two. Merging won't do very much at all. > a. sysctl to set IPC_RMID by default > b. shmget() flag to set IPC_RMID by default Use POSIX shared memory That appears to have the exact same problem. > c. open() flag to unlink a file before returning the fd Is it really that costly to create a blank file, why do you need to do it a lot in a JIT ? This part isn't about cost. It's about not leaving around debris when the JIT crashes. > e. mremap() flag to get a read/write mapping of a read/exec one > f. mremap() flag to get a read/exec mapping of a read/write one > g. mremap() flag to make the 5th arg (new addr) be the upper limit This is all mprotect and munmap. That won't get me a second mapping. Supposing that I had a second mapping, SE Linux would deny the mprotect. I'm looking for a mapping that is born executable or a mapping that is born writable, as needed, so that no transition is needed. > h. 6-bit wide mremap() "flag" to set the upper limit above given base > i. support the prot argument to remap_file_pages > j. a documented way (madvise?) to punch same-VMA zero-page holes mmap (although you get more VMAs from that) so memset() is probably genuinely cheaper if the permissions are not changing. Well cost is the problem here. I sure can find some way to get the operation done, but it isn't cheap. For some usages, the current setup is costly enough that one must consider abandoning the hardware MMU in favor of a software one emitted as part of the JIT. :-( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching
On Fri, 8 Jun 2007 21:56:06 -0700 (PDT) [EMAIL PROTECTED] wrote: > > with AA hardlinks are effectivly different labels on the same file So what? SELinux can be be altered to accept whatever label you generate. Pass it whatever label you want. > one of the big problems with SELinux is what label to put on new files > (including temp files), the AA approach avoids this (frequent) problem > entirely. In exchange AA picks up the (infrequent) problems of bind-mounts > and hard-link creation. People have tried to equate these prolems to show > that AA has just as many problems as SELinux, but you can run systems for > decades without creating hard-links or bind-mounts You are thinking about the way SELinux operates today, not how it might operate to accommodate AA inclusion in the kernel. Instead of SELinux always obtaining labels from file attributes, it could ask AA for them and you could generate them however you like. > also you seriously misunderstand the AA approach > > AA does NOT try to create a security policy for every file on the system. > > Instead AA policies are based on specific programs, and each policy states > what files that program is allowed to access. please read a bit more carefully, I was responding to someone else who made that claim. > if you are useing AA to secure all exposed services on a box you don't > have to try to write a policy to describe what gcc is allowed to access > (unless through policy you give one of your exposed services permission to > run gcc, and even then I'm not sure if gcc would inherit restrictions > from it's parent or just use it's own) > > the resulting policy is much easier to understand (and therefor check) > becouse it is orders of magnatude smaller then any comprehensive SELinux > policy. > > the AA policy is also much easier to understand becouse you can look at it > in pieces, understand that piece, and then forget it and move on to the > next piece. Nobody is asking you to change the AA policy file. It lives in user space. But i fail to see the problem in translating it into SELinux terms for the user transparently. > for example, if you write a policy for apache that limits it's access to > it's log files, install directories, and document root. then you write a > policy for your log analysis tool to access it's libraries, report > directories (under the apache document root) and the apache log files > (read only), these two policies are independant, you don't have to think > about one while creating the other (which you would have to do if you had > to put one label on apache binaries, another on normal web documents, a > third on the reports, a fourth on the log files, and a fifth on the > binaries for the log analysis tool. and this is ignoring any overlap in > libraries!) Again, try to think outside the box a bit. This isn't about using SELinux as it exists today. But imagine an SELinux that would ask you to supply a security label for each file _instead_ of looking up that label itself. Wouldn't that let you implement everything you wanted while still using much of the SELinux infrastructure that is already in the kernel? > AA also lets a sysadmin dip their toe in the water and just write a policy > for Apache, not for anything else, then write a policy for firefox, then > write a policy for their mail client, then for bittorrent, etc. there is > no need or push to try and secure everything all at once, and no need to > re-label files (and change any policies that used the old labels) when > you discover a new interaction. And so it could remain; this is about implementation, not model. Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching
On Fri, 8 Jun 2007, Sean wrote: On Sat, 9 Jun 2007 11:01:41 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote: From the discussion so far, it seems that the different "model" that AA is trying to implement, is to do in one step what SELinux does in two steps; that is trying to combine labelling and enforcement into a single step. If this is so, then why can't it just feed its automatic labelling into SELinux enforcement code? I tried to give each file it's own label, but I couldn't do it. http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf That paper seems entirely focused on the automatic generation of policy, and doesn't seem to help the discussion along. For instance, there may be a way to implement AA on top of SELinux _without_ giving each and every file its own label. There are many elements that forms too strong barrier between pathname and labels, such as bind-mounts, hard links, newly created files, renamed files, temporary files and so on. So I gave up giving each file a label that can be used as an identifier, and took an approach to forbid unneeded mount operations, unneeded link operations, unneeded renaming operations to keep the pathname represent it's own identifier as much as possible. AA must have a function that decides the security rights for any given path in order to make its enforcement decisions. It must surely be able to deal with all those things you listed above (bind-mounts,hard links etc). So why can't those decisions be turned into labels that are fed into SELinux enforcement code? with AA hardlinks are effectivly different labels on the same file one of the big problems with SELinux is what label to put on new files (including temp files), the AA approach avoids this (frequent) problem entirely. In exchange AA picks up the (infrequent) problems of bind-mounts and hard-link creation. People have tried to equate these prolems to show that AA has just as many problems as SELinux, but you can run systems for decades without creating hard-links or bind-mounts also you seriously misunderstand the AA approach AA does NOT try to create a security policy for every file on the system. Instead AA policies are based on specific programs, and each policy states what files that program is allowed to access. if you are useing AA to secure all exposed services on a box you don't have to try to write a policy to describe what gcc is allowed to access (unless through policy you give one of your exposed services permission to run gcc, and even then I'm not sure if gcc would inherit restrictions from it's parent or just use it's own) the resulting policy is much easier to understand (and therefor check) becouse it is orders of magnatude smaller then any comprehensive SELinux policy. the AA policy is also much easier to understand becouse you can look at it in pieces, understand that piece, and then forget it and move on to the next piece. for example, if you write a policy for apache that limits it's access to it's log files, install directories, and document root. then you write a policy for your log analysis tool to access it's libraries, report directories (under the apache document root) and the apache log files (read only), these two policies are independant, you don't have to think about one while creating the other (which you would have to do if you had to put one label on apache binaries, another on normal web documents, a third on the reports, a fourth on the log files, and a fifth on the binaries for the log analysis tool. and this is ignoring any overlap in libraries!) AA also lets a sysadmin dip their toe in the water and just write a policy for Apache, not for anything else, then write a policy for firefox, then write a policy for their mail client, then for bittorrent, etc. there is no need or push to try and secure everything all at once, and no need to re-label files (and change any policies that used the old labels) when you discover a new interaction. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] shm: Fix the filename of hugetlb sysv shared memory
Andrew Morton wrote: On Fri, 08 Jun 2007 17:43:34 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote: Some user space tools need to identify SYSV shared memory when examining /proc//maps. To do so they look for a block device with major zero, a dentry named SYSV, and having the minor of the internal sysv shared memory kernel mount. To help these tools and to make it easier for people just browsing /proc//maps this patch modifies hugetlb sysv shared memory to use the SYSV dentry naming convention. User space tools will still have to be aware that hugetlb sysv shared memory lives on a different internal kernel mount and so has a different block device minor number from the rest of sysv shared memory. I assume this fix is preferred over Badari's? If so, why? No. You still need my patch to fix the current breakage. This patch makes hugetlbfs also use same naming convention as regular shmem for its name. This is not absolutely needed, its a nice to have. Currently, user space tools can't depend on the filename alone, since its not unique (based on kry). Thanks, Badari - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: JIT emulator needs
On 6/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Albert Cahalan a écrit :
> Additions to better support JIT emulators:
>
> a. sysctl to set IPC_RMID by default
Not very good, this will break some apps.
As a sysctl, the admin gets to choose between
compatibility and sanity.
I can see such a sysctl also being really helpful for a
shared computer used for an Operating Systems or
System Programming course.
> b. shmget() flag to set IPC_RMID by default
This is better :)
Both are good. This one requires that all apps using
SysV shared memory be modified to use the flag.
The other requires that a very few apps be modified
to tolerate a behavior change.
> c. open() flag to unlink a file before returning the fd
Well, I assume you would like fd = open("/path/somefile", O_RDWR | O_CREAT |
O_UNLINK, 0644)
(ie allocate a file handle but no name ?)
Yes.
Quite difficult to implement this atomically with current vfs, maybe a new
syscall would be better. (Linus will kill me for that :) )
(We dont need to insert "somefile" in one directory, then unlink it, we only
need to allocate an unnamed inode to get some backing store)
I suspect that SMB/CIFS has a native call for this. There is
some sort of tmpfile flag defined over in that world.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Make i386 kernel show the unhandled signals
Hello,
This patch makes the i386 behave the same way that x86_64 does when a
segfault happens. A line gets printed to the kernel log so that tools
that need to check for failures can behave more uniformly between
different kernels. Like x86_64, it can be disabled by setting
debug.show_unhandled_signals sysctl variable to 0 (or by doing
echo 0 > /proc/sys/debug/show_unhandled_signals)
Also, all of the lines being printed are now using printk_ratelimit()
to deny the ability of DoS from a local user with a program like the
following:
main()
{
while (1)
if (!fork()) *(int *)0 = 0;
}
cheers,
Masoud
Signed-off-by: Masoud Sharbiani <[EMAIL PROTECTED]>
arch/i386/kernel/signal.c |5 +
arch/i386/kernel/traps.c|7 +++
arch/i386/mm/fault.c| 11 +++
arch/x86_64/kernel/signal.c |2 +-
arch/x86_64/kernel/traps.c |6 --
arch/x86_64/mm/fault.c | 15 +++
arch/x86_64/mm/init.c | 35 ---
include/asm-x86_64/proto.h |2 --
include/linux/signal.h |3 +++
include/linux/sysctl.h |3 +++
kernel/signal.c | 10 ++
kernel/sysctl.c | 10 ++
12 files changed, 57 insertions(+), 52 deletions(-)
diff --git a/arch/i386/kernel/signal.c b/arch/i386/kernel/signal.c
index d574e38..828dcb0 100644
--- a/arch/i386/kernel/signal.c
+++ b/arch/i386/kernel/signal.c
@@ -199,6 +199,11 @@ asmlinkage int sys_sigreturn(unsigned long __unused)
return eax;
badframe:
+ if (show_unhandled_signals && printk_ratelimit())
+ printk("%s[%d] bad frame in sigreturn frame:%p eip:%lx esp:%lx
oeax:%lx\n",
+ current->comm, current->pid, frame, regs->eip, regs->esp,
+ regs->orig_eax);
+
force_sig(SIGSEGV, current);
return 0;
}
diff --git a/arch/i386/kernel/traps.c b/arch/i386/kernel/traps.c
index 90da057..bccc5b4 100644
--- a/arch/i386/kernel/traps.c
+++ b/arch/i386/kernel/traps.c
@@ -610,6 +610,13 @@ fastcall void __kprobes do_general_protection(struct
pt_regs * regs,
current->thread.error_code = error_code;
current->thread.trap_no = 13;
+ if (show_unhandled_signals && unhandled_signal(current, SIGSEGV) &&
+ printk_ratelimit())
+ printk(KERN_INFO
+ "%s[%d] general protection eip:%lx esp:%lx error:%lx\n",
+ current->comm, current->pid,
+ regs->eip, regs->esp, error_code);
+
force_sig(SIGSEGV, current);
return;
diff --git a/arch/i386/mm/fault.c b/arch/i386/mm/fault.c
index 29d7d61..2aa4206 100644
--- a/arch/i386/mm/fault.c
+++ b/arch/i386/mm/fault.c
@@ -283,6 +283,8 @@ static inline int vmalloc_fault(unsigned long address)
return 0;
}
+int show_unhandled_signals = 1;
+
/*
* This routine handles page faults. It determines the address,
* and the problem, and then passes it off to one of the appropriate
@@ -465,6 +467,15 @@ bad_area_nosemaphore:
if (is_prefetch(regs, address, error_code))
return;
+ if (show_unhandled_signals && unhandled_signal(tsk, SIGSEGV) &&
+ printk_ratelimit()) {
+ printk(
+ "%s%s[%d]: segfault at %08lx eip %08lx esp %08lx error
%lx\n",
+ tsk->pid > 1 ? KERN_INFO : KERN_EMERG,
+ tsk->comm, tsk->pid, address, regs->eip,
+ regs->esp, error_code);
+ }
+
tsk->thread.cr2 = address;
/* Kernel addresses are always protection faults */
tsk->thread.error_code = error_code | (address >= TASK_SIZE);
diff --git a/arch/i386/mm/init.c b/arch/i386/mm/init.c
diff --git a/arch/x86_64/kernel/signal.c b/arch/x86_64/kernel/signal.c
index 290f5d8..f9506f6 100644
--- a/arch/x86_64/kernel/signal.c
+++ b/arch/x86_64/kernel/signal.c
@@ -480,7 +480,7 @@ do_notify_resume(struct pt_regs *regs, void *unused, __u32
thread_info_flags)
void signal_fault(struct pt_regs *regs, void __user *frame, char *where)
{
struct task_struct *me = current;
- if (exception_trace)
+ if (show_unhandled_signals && printk_ratelimit())
printk("%s[%d] bad frame in %s frame:%p rip:%lx rsp:%lx
orax:%lx\n",
me->comm,me->pid,where,frame,regs->rip,regs->rsp,regs->orig_rax);
diff --git a/arch/x86_64/kernel/traps.c b/arch/x86_64/kernel/traps.c
index cb29fb9..4f46b4d 100644
--- a/arch/x86_64/kernel/traps.c
+++ b/arch/x86_64/kernel/traps.c
@@ -577,7 +577,8 @@ static void __kprobes do_trap(int trapnr, int signr, char
*str,
tsk->thread.error_code = error_code;
tsk->thread.trap_no = trapnr;
- if (exception_trace && unhandled_signal(tsk, signr))
+ if (show_unhandled
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching
On Sat, 9 Jun 2007 11:01:41 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote: >From the discussion so far, it seems that the different "model" that AA is trying to implement, is to do in one step what SELinux does in two steps; that is trying to combine labelling and enforcement into a single step. If this is so, then why can't it just feed its automatic labelling into SELinux enforcement code? > I tried to give each file it's own label, but I couldn't do it. > http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf That paper seems entirely focused on the automatic generation of policy, and doesn't seem to help the discussion along. For instance, there may be a way to implement AA on top of SELinux _without_ giving each and every file its own label. > There are many elements that forms too strong barrier between pathname and > labels, > such as bind-mounts, hard links, newly created files, renamed files, > temporary files and so on. > So I gave up giving each file a label that can be used as an identifier, > and took an approach to forbid unneeded mount operations, unneeded link > operations, > unneeded renaming operations to keep the pathname represent it's own > identifier as much as possible. AA must have a function that decides the security rights for any given path in order to make its enforcement decisions. It must surely be able to deal with all those things you listed above (bind-mounts,hard links etc). So why can't those decisions be turned into labels that are fed into SELinux enforcement code? Sean. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [RFC] wrong cpus started
I have noticed that recent kernels, 2.6.16 through at least 2.6.19,
hyperthreading
can no longer be effectively disabled by using maxcpus. This means that anyone
that
was using maxcpus to disable hyperthreading when running Linux will no longer be
using all of their physical cpus.
The following patch restores the earlier behavior, but I am fairly sure that
some
CPU hotplug environments would not want this change. I can imagine making the
two
lines moved in the patch below to instead be conditional on CONFIG_HOTPLUG_CPU
and
!CONFIG_HOTPLUG_CPU respectively. Can someone more familiar with hotplug CPU
come
up with a better fix?
--- a/arch/i386/kernel/mpparse.c2006-11-29 15:57:37.0 -0600
+++ b/arch/i386/kernel/mpparse.c2007-06-06 16:41:06.635814335 -0500
@@ -180,9 +180,6 @@ static void __devinit MP_processor_info
}
apic_version[m->mpc_apicid] = ver;
- phys_cpu = apicid_to_cpu_present(apicid);
- physids_or(phys_cpu_present_map, phys_cpu_present_map, phys_cpu);
-
if (num_processors >= NR_CPUS) {
printk(KERN_WARNING "WARNING: NR_CPUS limit of %i reached."
" Processor ignored.\n", NR_CPUS);
@@ -195,6 +192,9 @@ static void __devinit MP_processor_info
return;
}
+ phys_cpu = apicid_to_cpu_present(apicid);
+ physids_or(phys_cpu_present_map, phys_cpu_present_map, phys_cpu);
+
cpu_set(num_processors, cpu_possible_map);
num_processors++;
--
Mark Rustad, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ext3fs: umount+sync not enough to guarantee metadata-on-disk
Andrew Morton wrote: On Thu, 07 Jun 2007 12:11:58 -0400 Chuck Ebbert <[EMAIL PROTECTED]> wrote: On 06/07/2007 11:41 AM, Andrew Morton wrote: mount /var/lib/mythtv -oremount,ro sync umount /var/lib/mythtv Did this succeed? If the application is still truncating that file, the umount should have failed. Shouldn't sync should wait for truncate to finish? I can't think of anything in there at present which would cause that to happen, and it's not immediately obvious how we _could_ make it happen - we have an inode which potentially has no dirty pages and which is itself clean. The truncate can span multiple journal commits, so forcing a journal commit in sync() won't necessarily block behind the truncate. I guess we could ask sync to speculatively take and release every inode's i_mutex or something. But even that would involve quite some hoop-jumping due to those infuriating spinlock-protected list_heads on the superblock. hmm. Okay, I added more instrumentation and retested today. Good and Bad. The umount does indeed fail while the massive unlink is happening, so I can just loop on that a few times before giving up. But.. the earlier "remount,ro".. well.. I don't know what it does. I did get it to lock up solid, though.. hung on the "remount,ro" when issued during an unlink of a 15GB file. The disk I/O eventually completes, and drives go idle, but the system remains hung inside the remount,ro call. Alt-sysrq-T was functioning, so I have some screen shots (.jpg) here: http://rtr.ca/remount_ro/ That's definitely a bug. For now, I'll just not attempt the remount,ro on this system, and have it loop for a minute attempting umount instead. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [0/1] [patch -mm] Add containerstats (v3)
Andrew Morton wrote: > On Fri, 08 Jun 2007 23:43:46 +0530 > Balbir Singh <[EMAIL PROTECTED]> wrote: > >> This patch implements per container statistics infrastructure and re-uses >> code from the taskstats interface. > > boggle. > > Symbol: CONTAINERS [=y] > Selected by: CONTAINER_DEBUG || CPUSETS && SMP || CONTAINER_CPUACCT > > Paul, that's just bizarre. How come it was done this way? > > > > OK, so taskstats.c still compiles, but I'm surprised. Shouldn't all that > newly-added container stuff in taskstats.c be inside CONFIG_CONTAINERS? Hi, Andrew, I've added a definition of containerstats_build() even when CONFIG_CONTAINERS is turned off, it simply returns -EINVAL. That's why taskstats.c compiles, I could add an #ifdef and move the containers commands under CONFIG_CONTAINERS, but I felt taskstats.c could be clean without any #ifdef's hanging around (as much as possible). In the next iteration, I could move out all the code to containerstats.c and make containerstats.c depend on CONFIG_CONTAINERS -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] i386: Fix the K7 NMI watchdog checkbit
On 2007.06.09 04:27:10 +0200, Björn Steinbrink wrote: > On 2007.06.08 22:43:25 +0200, Ingo Molnar wrote: > > > > * Björn Steinbrink <[EMAIL PROTECTED]> wrote: > > > > > Anyway, both are bugs and should be fixed. Maybe we're even lucky and > > > it fixes your hang. *fingers crossed* > > > > just to make it clear: the NMI watchdog was working perfectly fine on > > that box (in v2.6.21 and in dozens of kernel releases before that, for > > multiple years) before Andi's cleanup patch. So lets find that bug first > > or revert the cleanups. > > Might have been pure luck. ;-) The culprit seems to be commit > b7471c6da94d30d3deadc55986cc38d1ff57f9ca (from Sep 2006), which > introduced the check bit to figure out if a NMI was generated by the > watchdog timer. While the performance counter register on K7 is 64 bits > wide, the upper 16 bits are reserved and thus using bit 63 as the check > bit is wrong. A quick check using /dev/cpu/0/msr shows that > here, the upper 16 bits are zero all the time, chances are that this is > not deterministic and you got a 1 in bit 63 due to some random change. Hrmpf... Should've read the AMD docs first, not some random website. The upper bits are "read as zero", so while that was another bug fix, it's unlikely to help in your case. :-( Björn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i386: Fix the K7 NMI watchdog checkbit
On 2007.06.08 22:43:25 +0200, Ingo Molnar wrote:
>
> * Björn Steinbrink <[EMAIL PROTECTED]> wrote:
>
> > Anyway, both are bugs and should be fixed. Maybe we're even lucky and
> > it fixes your hang. *fingers crossed*
>
> just to make it clear: the NMI watchdog was working perfectly fine on
> that box (in v2.6.21 and in dozens of kernel releases before that, for
> multiple years) before Andi's cleanup patch. So lets find that bug first
> or revert the cleanups.
Might have been pure luck. ;-) The culprit seems to be commit
b7471c6da94d30d3deadc55986cc38d1ff57f9ca (from Sep 2006), which
introduced the check bit to figure out if a NMI was generated by the
watchdog timer. While the performance counter register on K7 is 64 bits
wide, the upper 16 bits are reserved and thus using bit 63 as the check
bit is wrong. A quick check using /dev/cpu/0/msr shows that
here, the upper 16 bits are zero all the time, chances are that this is
not deterministic and you got a 1 in bit 63 due to some random change.
Björn
The performance counters on K7 are only 48 bits wide, so using bit 63 to
check if the counter overflowed is wrong. Let's use bit 47 instead.
Signed-off-by: Björn Steinbrink <[EMAIL PROTECTED]>
Cc: Don Zickus <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
---
diff --git a/arch/i386/kernel/cpu/perfctr-watchdog.c
b/arch/i386/kernel/cpu/perfctr-watchdog.c
index 2b04c8f..82c6967 100644
--- a/arch/i386/kernel/cpu/perfctr-watchdog.c
+++ b/arch/i386/kernel/cpu/perfctr-watchdog.c
@@ -294,7 +294,7 @@ static struct wd_ops k7_wd_ops = {
.stop = single_msr_stop_watchdog,
.perfctr = MSR_K7_PERFCTR0,
.evntsel = MSR_K7_EVNTSEL0,
- .checkbit = 1ULL<<63,
+ .checkbit = 1ULL<<47,
};
/* Intel Model 6 (PPro+,P2,P3,P-M,Core1) */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 7/8] fdmap v2 - implement sys_socket2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Al Viro wrote:
> Any real-world examples of exploitable holes based on that?
Return to libc exploit, calling dup2, where some privileged data is
redirected from the normal file descriptor to one of the attackers
choosing. The latter could be an outgoing socket connection which would
result in leaking the data to the outside.
normal code intruder
so = socket()
fd = open ("local-file")
dup2(so, fd);
write (fd, privileged data)
It's just a little function call. If the arguments of dup2() are known
this is not a big issue to construct.
>> You're confusing the problems.
>
> No, I'm not. The entire argument for having a separate set of descriptors
> is based on programs behaving in similar fashion, working correctly now but
> limiting what libraries can do with opening files for internal needs.
It's completely different.
The reason why runtime libraries cannot keep descriptors open unless it
is explicitly part of the API (e.g., opendir) is that POSIX and Unix
forever guarantee that descriptors are allocated sequentially. Linus
already showed a code sequence:
close(0);
.. something else ..
if (open("myfile", O_RDONLY) < 0)
exit(1);
This occurs in the real world and it is guaranteed to work.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGagv72ijCOnn/RHQRAqxTAJwLhjuFT22SegEVXrbevpsnOkDxLQCgwgza
7ZOScxEm2lgMJNjG9UDAdfo=
=fenl
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: networking busted in current -git ???
From: Trond Myklebust <[EMAIL PROTECTED]> Date: Fri, 08 Jun 2007 17:43:27 -0400 > It is not dhcp. I'm seeing the same bug with bog-standard ifup with a > static address on an FC-6 machine. > > It appears to be something in the latest dump from davem to Linus, but I > haven't yet had time to identify what. Linus's current tree should have this fixed. Let us know if this is not the case. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching
Hello. David Lang wrote: > as I understand it SELinux puts one label on each file, so if you have > three files accessed by two programs such that > program A accesses files X Y > program B accesses files Y Z > > then files X Y and Z all need separate labels with the policy stateing > that program A need to access labels X, Y and program B needs to access > files Y Z > > extended out this can come close to giving each file it's own label. AA > essentially does this and calls the label the path and computes it at > runtime instead of storing it somewhere. I tried to give each file it's own label, but I couldn't do it. http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf There are many elements that forms too strong barrier between pathname and labels, such as bind-mounts, hard links, newly created files, renamed files, temporary files and so on. So I gave up giving each file a label that can be used as an identifier, and took an approach to forbid unneeded mount operations, unneeded link operations, unneeded renaming operations to keep the pathname represent it's own identifier as much as possible. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.6.21.3] kbuild: fix build for cygwin
Sam Ravnborg wrote: On Fri, Jun 08, 2007 at 11:32:29AM -0700, Tom wrote: From: Tom Enderes <[EMAIL PROTECTED]> The kernel build failed on cygwin hosts, because cygwin has slightly different typedefs compared to linux: scripts/mod/file2alias.c:518: error: dereferencing pointer to incomplete type Two files, scripts/mod/file2alias.c and scripts/mod/modpost.h, were modified as follows: Whever __CYGWIN__ is defined, __uint32 is defined as __uint32_t (instead of uint_32_t) and the missing ElfxxSection definitions are added. These changes have been tested both on cygwin 1.5.24, hostcc=gcc 3.4.4 and on FC5, hostcc=gcc 4.1.1-1. Any tests on cygwin, with and without this change, were executed with the following set for make: HOST_LOADLIBES="-lcurses -lintl". Signed-off-by: Tom Enderes <[EMAIL PROTECTED]> diff -Naur -r o21.1/scripts/mod/file2alias.c 2.6.21.1/scripts/mod/file2alias.c --- o21.1/scripts/mod/file2alias.c2007-04-27 14:49:26.0 -0700 +++ 2.6.21.1/scripts/mod/file2alias.c2007-05-29 20:35:01.209115300 -0700 @@ -29,7 +29,11 @@ #include +#ifdef __CYGWIN__ +typedef __uint32_t __u32; +#else typedef uint32_t__u32; +#endif typedef uint16_t__u16; typedef unsigned char__u8; This change is wrong. Somehow __uint32_t_defined gets defined and cygwin fails to define uint32_t. So we have hit a bug in cygwin here. Browsing the code I think that including inttypes.h much sooner will fix it. In file2alias.c I moved include of inttypes.h up. diff -Naur -r o21.1/scripts/mod/modpost.h 2.6.21.1/scripts/mod/modpost.h --- o21.1/scripts/mod/modpost.h2007-04-27 14:49:26.0 -0700 +++ 2.6.21.1/scripts/mod/modpost.h2007-05-29 20:35:01.599732800 -0700 @@ -9,6 +9,11 @@ #include #include +#ifdef __CYGWIN__ +typedef uint16_t Elf32_Section; +typedef uint16_t Elf64_Section; +#endif I did this in an alternative way. Replacing use of Elf32_section with Elf32_Half did the trick. Same for the 64 bit type. Let me know if this works on Cygwin. This is what I got on cygwin: In file included from scripts/mod/../../include/linux/input.h:19, from scripts/mod/file2alias.c:41: /usr/include/asm/types.h:21: error: conflicting types for '__u32' scripts/mod/file2alias.c:33: error: previous declaration of '__u32' was here scripts/mod/file2alias.c: In function `do_ieee1394_entry': scripts/mod/file2alias.c:193: warning: unsigned int format, __u32 arg (arg 3) scripts/mod/file2alias.c:195: warning: unsigned int format, __u32 arg (arg 3) scripts/mod/file2alias.c:197: warning: unsigned int format, __u32 arg (arg 3) scripts/mod/file2alias.c:199: warning: unsigned int format, __u32 arg (arg 3) scripts/mod/file2alias.c: In function `do_pci_entry': scripts/mod/file2alias.c:221: warning: unsigned int format, __u32 arg (arg 3) scripts/mod/file2alias.c:222: warning: unsigned int format, __u32 arg (arg 3) scripts/mod/file2alias.c:223: warning: unsigned int format, __u32 arg (arg 3) scripts/mod/file2alias.c:224: warning: unsigned int format, __u32 arg (arg 3) scripts/mod/file2alias.c: In function `do_pcmcia_entry': scripts/mod/file2alias.c:346: warning: unsigned int format, long unsigned int ar g (arg 3) scripts/mod/file2alias.c:347: warning: unsigned int format, long unsigned int ar g (arg 3) scripts/mod/file2alias.c:348: warning: unsigned int format, long unsigned int ar g (arg 3) scripts/mod/file2alias.c:349: warning: unsigned int format, long unsigned int ar g (arg 3) scripts/mod/file2alias.c: In function `do_parisc_entry': scripts/mod/file2alias.c:469: warning: unsigned int format, __u32 arg (arg 3) make[2]: *** [scripts/mod/file2alias.o] Error 1 make[1]: *** [scripts/mod] Error 2 make: *** [scripts] Error 2 I have tested with a few architectures on Linux with success. (Needs to look into the lib part next). Thanks for keeping attention on this. Sam diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c index f646381..5e017a9 100644 --- a/scripts/mod/file2alias.c +++ b/scripts/mod/file2alias.c @@ -10,6 +10,14 @@ * of the GNU General Public License, incorporated herein by reference. */ +#ifdef __sun__ +#include +#else +#include +#endif + +#include + #include "modpost.h" /* We use the ELF typedefs for kernel_ulong_t but bite the bullet and @@ -21,13 +29,6 @@ typedef Elf32_Addr kernel_ulong_t; typedef Elf64_Addr kernel_ulong_t; #define BITS_PER_LONG 64 #endif -#ifdef __sun__ -#include -#else -#include -#endif - -#include typedef uint32_t __u32; typedef uint16_t __u16; diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h index 4156dd3..0ffed17 100644 --- a/scripts/mod/modpost.h +++ b/scripts/mod/modpost.h @@ -17,7 +17,7 @@ #define Elf_ShdrElf32_Shdr #define Elf_Sym Elf32_Sym #define Elf_AddrElf32_Addr -#define Elf_Section Elf32_Section +#define Elf_Section Elf32_Half #define ELF_ST_BIND ELF32_ST_BIND #define ELF_ST_TYPE ELF32_ST_TYPE @@ -31,7 +31,7 @@ #define E
Re: [patch 7/8] fdmap v2 - implement sys_socket2
On Fri, Jun 08, 2007 at 06:19:28PM -0700, Ulrich Drepper wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Al Viro wrote: > > Exactly. Put it another way, randomizer is a stress-tester. > > ... and a security mechanism. And as such it is only useful if it is > used. Probably it should be policy-controlled whether you can turn it off. Any real-world examples of exploitable holes based on that? Real blue-sky world, not grsec-advocacy "undiscovered null ptr derefs on every corner and all of the variety fixable by our magic goo" one, please. > > Note that > > #define NR_FILES > > > > for (i = 0; i < NR_FILES; i++) > > close(i); > > You're confusing the problems. No, I'm not. The entire argument for having a separate set of descriptors is based on programs behaving in similar fashion, working correctly now but limiting what libraries can do with opening files for internal needs. So here's the question: how widespread it really is, considering that "working correctly" is not a trivial constraint. Again, I'd love to see real data; if I need handwaving, I know where to find it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] cpuset: zero malloc - fix for new containers
From: Paul Jackson <[EMAIL PROTECTED]>
Third of three -- This applies after the container patches,
fixing a problem that earlier patches also fixed in the older
cpuset code.
The container code to present a list of tasks using a container
to user space could write to an array that it had kmalloc'd,
after a kmalloc request of zero size.
The problem was that the code didn't check for writes past the
allocated end of the array until -after- the first write.
This is a race condition that is likely rare -- it would only show
up if a container went from being empty to having a task in it,
during the brief time between the allocation and the first write.
Prior to roughly 2.6.22 kernels, this was also a benign problem,
because a zero kmalloc returned a few usable bytes anyway,
and no harm was done with the bogus write.
With the 2.6.22 kernel changes to make issue a warning if
code tries to write to the location returned from a zero size
allocation, this problem is no longer benign. This container code
would occassionally trigger that warning.
The fix is trivial -- check before storing into the array,
not after, whether the array is big enough to hold the store.
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: "Serge E. Hallyn" <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Dave Hansen <[EMAIL PROTECTED]>
Cc: Herbert Poetzl <[EMAIL PROTECTED]>
Cc: Kirill Korotaev <[EMAIL PROTECTED]>
Cc: Paul Menage <[EMAIL PROTECTED]>
Cc: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
---
Andrew - this is the third of three similar patches. This one
redoes the fix for the container code.
Please apply somewhere after:
containersv10-share-css_group-arrays-between-tasks-with-same-container-memberships.patch
kernel/container.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.22-rc4-mm2.orig/kernel/container.c 2007-06-08 15:36:14.997835546
-0700
+++ 2.6.22-rc4-mm2/kernel/container.c 2007-06-08 15:37:09.606655972 -0700
@@ -1451,9 +1451,9 @@ static int pid_array_load(pid_t *pidarra
struct task_struct *tsk;
container_iter_start(cont, &it);
while ((tsk = container_iter_next(cont, &it))) {
- pidarray[n++] = pid_nr(task_pid(tsk));
if (unlikely(n == npids))
break;
+ pidarray[n++] = pid_nr(task_pid(tsk));
}
container_iter_end(cont, &it);
return n;
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] cpuset: zero malloc - fix for old cpusets
From: Paul Jackson <[EMAIL PROTECTED]>
First of three -- this one goes before the container patches,
and should be sent to Linus for 2.6.22.
The cpuset code to present a list of tasks using a cpuset to
user space could write to an array that it had kmalloc'd,
after a kmalloc request of zero size.
The problem was that the code didn't check for writes past
the allocated end of the array until -after- the first write.
This is a race condition that is likely rare -- it would only
show up if a cpuset went from being empty to having a task
in it, during the brief time between the allocation and the
first write.
Prior to roughly 2.6.22 kernels, this was also a benign
problem, because a zero kmalloc returned a few usable bytes
anyway, and no harm was done with the bogus write.
With the 2.6.22 kernel changes to make issue a warning if
code tries to write to the location returned from a zero
size allocation, this problem is no longer benign. This
cpuset code would occassionally trigger that warning.
The fix is trivial -- check before storing into the array,
not after, whether the array is big enough to hold the store.
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: "Serge E. Hallyn" <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Dave Hansen <[EMAIL PROTECTED]>
Cc: Herbert Poetzl <[EMAIL PROTECTED]>
Cc: Kirill Korotaev <[EMAIL PROTECTED]>
Cc: Paul Menage <[EMAIL PROTECTED]>
Cc: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
---
Andrew - this fix collides with the container changes, and now
that you have sent Christoph's patch to Linus to warn on writes
to zero-sized allocations, this fix should go to Linus too.
So it comes in three parts: fix the old, undo that, fix the new.
This patch should be applied first, before the container patches,
and sent to Linus for 2.6.22.
kernel/cpuset.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.22-rc4-mm2.orig/kernel/cpuset.c 2007-06-08 14:44:58.899036450 -0700
+++ 2.6.22-rc4-mm2/kernel/cpuset.c 2007-06-08 14:47:00.996907442 -0700
@@ -1620,9 +1620,9 @@ static int pid_array_load(pid_t *pidarra
do_each_thread(g, p) {
if (p->cpuset == cs) {
- pidarray[n++] = p->pid;
if (unlikely(n == npids))
goto array_full;
+ pidarray[n++] = p->pid;
}
} while_each_thread(g, p);
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] cpuset: zero malloc - revert the old cpuset fix
From: Paul Jackson <[EMAIL PROTECTED]>
Second of three -- This one undoes the first one. Apply before
the container patch that changes cpusets to use containers,
in order to avoid a patch conflict.
The cpuset code to present a list of tasks using a cpuset to
user space could write to an array that it had kmalloc'd,
after a kmalloc request of zero size.
The problem was that the code didn't check for writes past
the allocated end of the array until -after- the first write.
This is a race condition that is likely rare -- it would only
show up if a cpuset went from being empty to having a task
in it, during the brief time between the allocation and the
first write.
Prior to roughly 2.6.22 kernels, this was also a benign
problem, because a zero kmalloc returned a few usable bytes
anyway, and no harm was done with the bogus write.
With the 2.6.22 kernel changes to make issue a warning if
code tries to write to the location returned from a zero
size allocation, this problem is no longer benign. This
cpuset code would occassionally trigger that warning.
The fix is trivial -- check before storing into the array,
not after, whether the array is big enough to hold the store.
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: "Serge E. Hallyn" <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Dave Hansen <[EMAIL PROTECTED]>
Cc: Herbert Poetzl <[EMAIL PROTECTED]>
Cc: Kirill Korotaev <[EMAIL PROTECTED]>
Cc: Paul Menage <[EMAIL PROTECTED]>
Cc: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>
---
Andrew,
This is the second of three in the set - it reverses the
first one, to avoid colliding with the container patches.
Apply somewhere before, or entirely merge into:
containersv10-share-css_group-arrays-between-tasks-with-same-container-memberships.patch
kernel/cpuset.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.22-rc4-mm2.orig/kernel/cpuset.c 2007-06-08 14:57:59.091074320 -0700
+++ 2.6.22-rc4-mm2/kernel/cpuset.c 2007-06-08 15:34:24.336172342 -0700
@@ -1620,9 +1620,9 @@ static int pid_array_load(pid_t *pidarra
do_each_thread(g, p) {
if (p->cpuset == cs) {
+ pidarray[n++] = p->pid;
if (unlikely(n == npids))
goto array_full;
- pidarray[n++] = p->pid;
}
} while_each_thread(g, p);
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] RFC: have tcp_recvmsg() check kthread_should_stop() and treat it as if it were signalled
Please cc networking patches to [EMAIL PROTECTED]
Jeff Layton <[EMAIL PROTECTED]> wrote:
>
> The following patch is a first stab at removing this need. It makes it
> so that in tcp_recvmsg() we also check kthread_should_stop() at any
> point where we currently check to see if the task was signalled. If
> that returns true, then it acts as if it were signalled and returns to
> the calling function.
This just doesn't seem to fit. Why should networking care about kthreads?
Perhaps you can get kthread_stop to send a signal instead?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 23/32] IPV4: Correct rp_filter help text.
On Sat, Jun 09, 2007 at 11:20:43AM +1000, Herbert Xu wrote:
> Chris Wright <[EMAIL PROTECTED]> wrote:
> >
> > --- linux-2.6.20.13.orig/net/ipv4/Kconfig
> > +++ linux-2.6.20.13/net/ipv4/Kconfig
> > @@ -43,11 +43,11 @@ config IP_ADVANCED_ROUTER
> > asymmetric routing (packets from you to a host take a different
> > path
> > than packets from that host to you) or if you operate a non-routing
> > host which has several IP addresses on different interfaces. To
> > turn
> > - rp_filter off use:
> > + rp_filter on use:
> >
> > - echo 0 > /proc/sys/net/ipv4/conf//rp_filter
> > + echo 1 > /proc/sys/net/ipv4/conf//rp_filter
> > or
> > - echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
> > + echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
>
> BTW, this documentation is actually wrong. You can't enable rp_filter
So to fix the documentation, we should change the word "or" to "and".
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 7/8] fdmap v2 - implement sys_socket2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Al Viro wrote: > Exactly. Put it another way, randomizer is a stress-tester. ... and a security mechanism. And as such it is only useful if it is used. Probably it should be policy-controlled whether you can turn it off. > Note that > #define NR_FILES > > for (i = 0; i < NR_FILES; i++) > close(i); You're confusing the problems. This is not the argument for having a separate file descriptor set. It is the argument to have hidden file descriptors. Randomization has nothing whatsoever to do with this example. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGagAg2ijCOnn/RHQRAhV+AJ9qT2epTxDWWS++74f+vrV3NucVHACdGkxm MULoyE+0NY7dSHcB2epKe7w= =o3+1 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 23/32] IPV4: Correct rp_filter help text.
Chris Wright <[EMAIL PROTECTED]> wrote:
>
> --- linux-2.6.20.13.orig/net/ipv4/Kconfig
> +++ linux-2.6.20.13/net/ipv4/Kconfig
> @@ -43,11 +43,11 @@ config IP_ADVANCED_ROUTER
> asymmetric routing (packets from you to a host take a different path
> than packets from that host to you) or if you operate a non-routing
> host which has several IP addresses on different interfaces. To turn
> - rp_filter off use:
> + rp_filter on use:
>
> - echo 0 > /proc/sys/net/ipv4/conf//rp_filter
> + echo 1 > /proc/sys/net/ipv4/conf//rp_filter
> or
> - echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
> + echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
BTW, this documentation is actually wrong. You can't enable rp_filter
on all interfaces with
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
You must do that in conjunction with
echo 1 > /proc/sys/net/ipv4/conf//rp_filter
for it to work for .
This is really counter-intuitive but it's apparently how it's always
worked.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: networking busted in current -git ???
Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> It appears to be something in the latest dump from davem to Linus, but I
> haven't yet had time to identify what.
You want this patch which should hit the tree soon.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
[IPV4]: Do not remove idev when addresses are cleared
Now that we create idev before addresses are added, it no longer makes
sense to remove them when addresses are all deleted.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 354e800..0cf813f 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -327,12 +327,8 @@ static void __inet_del_ifa(struct in_device *in_dev,
struct in_ifaddr **ifap,
}
}
- if (destroy) {
+ if (destroy)
inet_free_ifa(ifa1);
-
- if (!in_dev->ifa_list)
- inetdev_destroy(in_dev);
- }
}
static void inet_del_ifa(struct in_device *in_dev, struct in_ifaddr **ifap,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Fri, 8 Jun 2007, Greg KH wrote: On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote: AppArmor is meant to be relatively easy to understand, manage, and customize, and introducing a labels layer wouldn't help these goals. Woah, that describes the userspace side of AA just fine, it means nothing when it comes to the in-kernel implementation. There is no reason that you can't implement the same functionality using some totally different in-kernel solution if possible. SELinux is applicable in areas where AppArmor is not (e.g., MLS), but this comes at a cost. For me the question is not SELinux or AppArmor, but if AppArmor's security model is a good solution in common scenarios. In my opinion, AppArmor is a better answer than SELinux in a number of scenarios. This gives it value, nonwithstanding the fact that SELinux can be taken further. I am still not completely certian that we can not properly implement AA functionality using a SELinux backend solution. Yes, the current tools that try to implement this are still lacking, and maybe the kernel needs to change, but that is possible. I still want to see a definition of the AA "model" that we can then use to try to implement using whatever solution works best. As that seems to be missing the current argument of if AA can or can not be implemented using SELinux or something totally different should be stopped. So, AA developers, do you have such a document anywhere? I know there are some old research papers, do they properly describe the current model you are trying to implement here? Greg, to implement the AA approach useing SELinux you need to have a way that files that are renamed or created get tagged with the right label automaticaly with no possible race condition. If this can be done then it _may_ be possible to do the job that AA is aimed at with SELinux, but the work nessasary to figure out what lables are needed on what file would still make it a non-trivial task. as I understand it SELinux puts one label on each file, so if you have three files accessed by two programs such that program A accesses files X Y program B accesses files Y Z then files X Y and Z all need seperate labels with the policy stateing that program A need to access labels X, Y and program B needs to access files Y Z extended out this can come close to giving each file it's own label. AA essentially does this and calls the label the path and computes it at runtime instead of storing it somewhere. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: why does the macro "ZERO_PAGE" take an argument?
Robert P. J. Day wrote: > > and once again, an initially innocuous question quickly leaves me > behind. no, no, i'm getting used to it. :-P > This is what happens when you stir the muck on the bottom. This is probably a good thing. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Re: 4Gb ram not showing up
Andrew Lyon wrote: > > I have run memtest86+ for days at a time on both systems with no errors > at all. > > broken hardware i guess, i am not surprised about the abit board, ive > had nothing but trouble with abit motherboards and do not use them any > more, but the supermicro is a xeon server board and i was using > kingston ram, i wouldnt expect that to have issues. > > latest bios on both. > And have you verified that it's specced for the memory load you're putting on it? Not all platforms can use every slot with certain kinds of DIMMs, depending on chip and rank count. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 7/8] fdmap v2 - implement sys_socket2
On Fri, Jun 08, 2007 at 05:03:57PM -0700, Linus Torvalds wrote: > > > On Fri, 8 Jun 2007, Davide Libenzi wrote: > > > > On Fri, 8 Jun 2007, Linus Torvalds wrote: > > > > > > You need things to be *repeatable* for debugging. No ifs, buts, or maybes > > > about it. > > > > It all depends on how you use the file descriptor. > > Read what I wrote. "for debugging". > > If your code is bug-free, and does what you intend it to do, everything is > fine. But you wouldn't be doing debugging then, would you? > > For debugging, it does _not_ depend on "how you use the file descriptor". > The whole _point_ is that something does something wrong. Maybe you > _intended_ to use the file descriptor some way, and the bug was that you > didn't. Exactly. Put it another way, randomizer is a stress-tester. Which is a damn useful debugging tool in its own right. *However*, the main thing about debugging tools is that you need to be able to turn them on and off individually; then you get a useful information narrowing the diagnosis down. If you can't do that, you lose. Folks, the real question is whether we consider the loops blindly shooting down the file descriptors as a supportable thing. Correction: whether the code written in that style *and* *correct* *with* *current* *semantics* is sufficiently numerous and hard to notice that we need that sort of kludges. Because what Uli's suggesting is certainly that - a kludge sufficient for glibc internal needs. Note that #define NR_FILES for (i = 0; i < NR_FILES; i++) close(i); is simply broken. No ifs, no buts, it's broken on the current kernel. So that kind of stuff needs fixing anyway; do we have enough left to make it worth preserving? I don't know the answer; some data would be much appreciated. If the broken stuff like above outnumbers the valid uses, we probably need think of some way to catch that kind of crap anyway... Randomizer for open() et.al. switchable on per-process basis would be a nice tool to catch some of those, along with instrumenting the kernel to notice massive close() on files that hadn't been opened, etc. As long as all we have is a handwaving about widespread and unspecified code doing this, this and that, but not that... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] update checkpatch.pl to version 0.04
Andy Whitcroft wrote: > This version brings a some new tests, and a host of changes to fix > false positives, of particular note: > > - check for and report #if 0 > - extend checking of line lengths and spacing for .pl, .sh etc > - extends the pointer type checks to multiple levels > - updates printk handling to track newlines > - adds a wrapped patch detector > - drops the leading component of the filenames > - extends switch indent handling to switch statmentes rooted in > the context > - adds foo * bar single pointer checks I just wanted to say Thank You for putting checkpatch.pl together. I've only used v0.1 here (its what showed up in wireless-dev) but it made pruning through the iwlwifi sources to clean things up a very manageable task. Great job so far. Thanks, James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/9] USB: set default y for CONFIG_USB_DEVICE_CLASS
From: Kay Sievers <[EMAIL PROTECTED]>
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
Cc: bert hubert <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/core/Kconfig | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index f493fb1..346fc03 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -40,21 +40,25 @@ config USB_DEVICEFS
config USB_DEVICE_CLASS
bool "USB device class-devices (DEPRECATED)"
depends on USB
- default n
+ default y
---help---
Userspace access to USB devices is granted by device-nodes exported
directly from the usbdev in sysfs. Old versions of the driver
core and udev needed additional class devices to export device nodes.
These additional devices are difficult to handle in userspace, if
- information about USB interfaces must be available. One device
contains
- the device node, the other device contains the interface data. Both
- devices are at the same level in sysfs (siblings) and one can't access
- the other. The device node created directly by the usbdev is the
parent
- device of the interface and therefore easily accessible from the
interface
- event.
-
- This option provides backward compatibility if needed.
+ information about USB interfaces must be available. One device
+ contains the device node, the other device contains the interface
+ data. Both devices are at the same level in sysfs (siblings) and one
+ can't access the other. The device node created directly by the
+ usb device is the parent device of the interface and therefore
+ easily accessible from the interface event.
+
+ This option provides backward compatibility for libusb device
+ nodes (lsusb) when usbfs is not used, and the following udev rule
+ doesn't exist:
+ SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", \
+ NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"
config USB_DYNAMIC_MINORS
bool "Dynamic USB minor allocation (EXPERIMENTAL)"
--
1.5.2.1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote: > AppArmor is meant to be relatively easy to understand, manage, and customize, > and introducing a labels layer wouldn't help these goals. Woah, that describes the userspace side of AA just fine, it means nothing when it comes to the in-kernel implementation. There is no reason that you can't implement the same functionality using some totally different in-kernel solution if possible. > SELinux is applicable in areas where AppArmor is not (e.g., MLS), but > this comes at a cost. For me the question is not SELinux or AppArmor, > but if AppArmor's security model is a good solution in common > scenarios. In my opinion, AppArmor is a better answer than SELinux in > a number of scenarios. This gives it value, nonwithstanding the fact > that SELinux can be taken further. I am still not completely certian that we can not properly implement AA functionality using a SELinux backend solution. Yes, the current tools that try to implement this are still lacking, and maybe the kernel needs to change, but that is possible. I still want to see a definition of the AA "model" that we can then use to try to implement using whatever solution works best. As that seems to be missing the current argument of if AA can or can not be implemented using SELinux or something totally different should be stopped. So, AA developers, do you have such a document anywhere? I know there are some old research papers, do they properly describe the current model you are trying to implement here? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 7/8] fdmap v2 - implement sys_socket2
On Fri, 8 Jun 2007, Linus Torvalds wrote: > On Fri, 8 Jun 2007, Davide Libenzi wrote: > > > > On Fri, 8 Jun 2007, Linus Torvalds wrote: > > > > > > You need things to be *repeatable* for debugging. No ifs, buts, or maybes > > > about it. > > > > It all depends on how you use the file descriptor. > > Read what I wrote. "for debugging". > > If your code is bug-free, and does what you intend it to do, everything is > fine. But you wouldn't be doing debugging then, would you? > > For debugging, it does _not_ depend on "how you use the file descriptor". > The whole _point_ is that something does something wrong. Maybe you > _intended_ to use the file descriptor some way, and the bug was that you > didn't. Ok, so what's your idea? Have another POSIX-like allocator somewhere up there in the fd space, with a fixed and include-defined base? Or just drop all this altogether? - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] pata_it821x: sync with IDE it821x driver
* fix PIO setup for devices with different PIO speeds in passthru mode
IT821x allows one PIO setting per port se we have to limit maximum
PIO mode to the one of the slowest device on the port.
* (partially) fix DMA in RAID mode
Code intended to check DMA status was checking DMA command register.
Moreover firmware seems to "forget" to set DMA capable bit for the
slave device (at least in RAID mode but without ITE RAID volumes) so
check device ID for DMA capable bit when deciding whether to use DMA
and remove DMA status check completely.
Thanks to Pavol Šimo for the bugreport and testing the initial fix.
This change unfortunately still doesn't fix DMA in RAID mode (which
works fine with IDE it821x) but Alan is working on the missing pieces
(pata_it821x vs libata EH issues).
Cc: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ata/pata_it821x.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
Index: b/drivers/ata/pata_it821x.c
===
--- a/drivers/ata/pata_it821x.c
+++ b/drivers/ata/pata_it821x.c
@@ -2,6 +2,7 @@
* pata_it821x.c - IT821x PATA for new ATA layer
* (C) 2005 Red Hat Inc
* Alan Cox <[EMAIL PROTECTED]>
+ * (C) 2007 Bartlomiej Zolnierkiewicz
*
* based upon
*
@@ -79,7 +80,7 @@
#define DRV_NAME "pata_it821x"
-#define DRV_VERSION "0.3.6"
+#define DRV_VERSION "0.3.7"
struct it821x_dev
{
@@ -258,8 +259,14 @@ static void it821x_passthru_set_piomode(
static const u8 pio_want[]= { ATA_66, ATA_66, ATA_66, ATA_66,
ATA_ANY };
struct it821x_dev *itdev = ap->private_data;
+ struct ata_device *pair = ata_dev_pair(adev);
int unit = adev->devno;
- int mode_wanted = adev->pio_mode - XFER_PIO_0;
+ int mode_wanted = adev->pio_mode;
+
+ if (pair && adev->pio_mode > pair->pio_mode)
+ mode_wanted = pair->pio_mode;
+
+ mode_wanted -= XFER_PIO_0;
/* We prefer 66Mhz clock for PIO 0-3, don't care for PIO4 */
itdev->want[unit][1] = pio_want[mode_wanted];
@@ -460,14 +467,8 @@ static unsigned int it821x_passthru_qc_i
static int it821x_smart_set_mode(struct ata_port *ap, struct ata_device
**unused)
{
- int dma_enabled = 0;
int i;
- /* Bits 5 and 6 indicate if DMA is active on master/slave */
- /* It is possible that BMDMA isn't allocated */
- if (ap->ioaddr.bmdma_addr)
- dma_enabled = ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
-
for (i = 0; i < ATA_MAX_DEVICES; i++) {
struct ata_device *dev = &ap->device[i];
if (ata_dev_enabled(dev)) {
@@ -476,7 +477,7 @@ static int it821x_smart_set_mode(struct
dev->dma_mode = XFER_MW_DMA_0;
/* We do need the right mode information for DMA or PIO
and this comes from the current configuration flags
*/
- if (dma_enabled & (1 << (5 + i))) {
+ if (ata_id_has_dma(dev->id)) {
ata_dev_printk(dev, KERN_INFO, "configured for
DMA\n");
dev->xfer_mode = XFER_MW_DMA_0;
dev->xfer_shift = ATA_SHIFT_MWDMA;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/6] include linux pci_id-h add amd northbridge defines
On Fri, Jun 08, 2007 at 10:45:10AM -0600, [EMAIL PROTECTED] wrote: > From: Douglas Thompson <[EMAIL PROTECTED]> > > pci_ids.h needs two of the AMD NB device-ids namely, > Addressmap and the Memory Controller devices Does any kernel driver need this? We're trying to only include things in the pci_ids.h file that are needed in more than one file to cut down on the churn here for unnecessary ids. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 7/8] fdmap v2 - implement sys_socket2
On Fri, 8 Jun 2007, Davide Libenzi wrote: > > On Fri, 8 Jun 2007, Linus Torvalds wrote: > > > > You need things to be *repeatable* for debugging. No ifs, buts, or maybes > > about it. > > It all depends on how you use the file descriptor. Read what I wrote. "for debugging". If your code is bug-free, and does what you intend it to do, everything is fine. But you wouldn't be doing debugging then, would you? For debugging, it does _not_ depend on "how you use the file descriptor". The whole _point_ is that something does something wrong. Maybe you _intended_ to use the file descriptor some way, and the bug was that you didn't. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/9] USB: Fix up bogus bInterval values in endpoint descriptors
From: Alan Stern <[EMAIL PROTECTED]>
This patch (as904) adds code to check for endpoint descriptor bInterval
values outside the legal limits. Illegal values are set to 32 ms, which
seems like a reasonable default.
This fixes Bugzilla #8432.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/core/config.c | 42 +-
1 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 2d4fd53..dd34823 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -1,4 +1,5 @@
#include
+#include
#include
#include
#include
@@ -49,7 +50,7 @@ static int usb_parse_endpoint(struct device *ddev, int cfgno,
int inum,
unsigned char *buffer0 = buffer;
struct usb_endpoint_descriptor *d;
struct usb_host_endpoint *endpoint;
- int n, i;
+ int n, i, j;
d = (struct usb_endpoint_descriptor *) buffer;
buffer += d->bLength;
@@ -84,6 +85,45 @@ static int usb_parse_endpoint(struct device *ddev, int
cfgno, int inum,
memcpy(&endpoint->desc, d, n);
INIT_LIST_HEAD(&endpoint->urb_list);
+ /* If the bInterval value is outside the legal range,
+* set it to a default value: 32 ms */
+ i = 0; /* i = min, j = max, n = default */
+ j = 255;
+ if (usb_endpoint_xfer_int(d)) {
+ i = 1;
+ switch (to_usb_device(ddev)->speed) {
+ case USB_SPEED_HIGH:
+ n = 9; /* 32 ms = 2^(9-1) uframes */
+ j = 16;
+ break;
+ default:/* USB_SPEED_FULL or _LOW */
+ /* For low-speed, 10 ms is the official minimum.
+* But some "overclocked" devices might want faster
+* polling so we'll allow it. */
+ n = 32;
+ break;
+ }
+ } else if (usb_endpoint_xfer_isoc(d)) {
+ i = 1;
+ j = 16;
+ switch (to_usb_device(ddev)->speed) {
+ case USB_SPEED_HIGH:
+ n = 9; /* 32 ms = 2^(9-1) uframes */
+ break;
+ default:/* USB_SPEED_FULL */
+ n = 6; /* 32 ms = 2^(6-1) frames */
+ break;
+ }
+ }
+ if (d->bInterval < i || d->bInterval > j) {
+ dev_warn(ddev, "config %d interface %d altsetting %d "
+ "endpoint 0x%X has an invalid bInterval %d, "
+ "changing to %d\n",
+ cfgno, inum, asnum,
+ d->bEndpointAddress, d->bInterval, n);
+ endpoint->desc.bInterval = n;
+ }
+
/* Skip over any Class Specific or Vendor Specific descriptors;
* find the next endpoint or interface descriptor */
endpoint->extra = buffer;
--
1.5.2.1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 9/9] OHCI: Fix machine check in ohci_hub_status_data
From: Alan Stern <[EMAIL PROTECTED]> This patch (as901) fixes an oversight in ohci-hcd. The hub_status_data routine must not try to access the controller's memory-mapped registers if the controller is in a low-power state; such attempts will cause a crash on some architectures (such as PPC). Signed-off-by: Alan Stern <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/usb/host/ohci-hub.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c index 216c9c9..bb9cc59 100644 --- a/drivers/usb/host/ohci-hub.c +++ b/drivers/usb/host/ohci-hub.c @@ -417,6 +417,8 @@ ohci_hub_status_data (struct usb_hcd *hcd, char *buf) unsigned long flags; spin_lock_irqsave (&ohci->lock, flags); + if (!test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags)) + goto done; /* undocumented erratum seen on at least rev D */ if ((ohci->flags & OHCI_QUIRK_AMD756) -- 1.5.2.1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 7/9] USB: cxacru: ignore error trying to start ADSL in atm_start
From: Simon Arlott <[EMAIL PROTECTED]>
The sysfs adsl_status attribute ignores (aside from returning -EIO to the
user) any error sending a START/STOP command to the device and there is at
least one firmware which never sends a response but appears to work
regardless. Therefore atm_start should also continue if an error is received
so that such firmware is usable.
The official Conexant driver doesn't expect a reply either but this is for
another device (E2 router) and a commonly used firmware does respond.
Also, there is no point in changing -ECONNRESET to -ETIMEDOUT since nothing
ever checks for either of these values.
Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
Cc: Duncan Sands <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/atm/cxacru.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
index 68cf582..8bcf7fe 100644
--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
@@ -476,8 +476,6 @@ static int cxacru_start_wait_urb(struct urb *urb, struct
completion *done,
add_timer(&timer);
wait_for_completion(done);
status = urb->status;
- if (status == -ECONNRESET)
- status = -ETIMEDOUT;
del_timer_sync(&timer);
if (actual_length)
@@ -671,11 +669,8 @@ static int cxacru_atm_start(struct usbatm_data
*usbatm_instance,
/* start ADSL */
mutex_lock(&instance->adsl_state_serialize);
ret = cxacru_cm(instance, CM_REQUEST_CHIP_ADSL_LINE_START, NULL, 0,
NULL, 0);
- if (ret < 0) {
+ if (ret < 0)
atm_err(usbatm_instance, "cxacru_atm_start:
CHIP_ADSL_LINE_START returned %d\n", ret);
- mutex_unlock(&instance->adsl_state_serialize);
- return ret;
- }
/* Start status polling */
mutex_lock(&instance->poll_state_serialize);
--
1.5.2.1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] USB: cxacru: create sysfs attributes in atm_start instead of bind
From: Simon Arlott <[EMAIL PROTECTED]>
Since usbatm doesn't set the usb_interface driver data until after calling
bind and heavy_init, it would be NULL when the sysfs attributes are read.
Reading the MAC address from atm_dev before atm_dev exists would have been
be possible too.
Calling create_device_file in atm_start will avoid this problem, and the
data is useless until the first status poll runs. However, it must be
ready before a status poll does a printk on line status change otherwise
userspace could react before the files exist.
For completeness I've moved remove_device_file to atm_stop so it's not
called in unbind when it's not needed. There's no point starting ADSL if
atm_start could still fail either.
Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
Cc: Duncan Sands <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/atm/cxacru.c | 45 +
1 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
index 30b7bfb..68cf582 100644
--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
@@ -629,10 +629,22 @@ static int cxacru_card_status(struct cxacru_data
*instance)
return 0;
}
+static void cxacru_remove_device_files(struct usbatm_data *usbatm_instance,
+ struct atm_dev *atm_dev)
+{
+ struct usb_interface *intf = usbatm_instance->usb_intf;
+
+ #define CXACRU_DEVICE_REMOVE_FILE(_name) \
+ device_remove_file(&intf->dev, &dev_attr_##_name);
+ CXACRU_ALL_FILES(REMOVE);
+ #undef CXACRU_DEVICE_REMOVE_FILE
+}
+
static int cxacru_atm_start(struct usbatm_data *usbatm_instance,
struct atm_dev *atm_dev)
{
struct cxacru_data *instance = usbatm_instance->driver_data;
+ struct usb_interface *intf = usbatm_instance->usb_intf;
/*
struct atm_dev *atm_dev = usbatm_instance->atm_dev;
*/
@@ -649,6 +661,13 @@ static int cxacru_atm_start(struct usbatm_data
*usbatm_instance,
return ret;
}
+ #define CXACRU_DEVICE_CREATE_FILE(_name) \
+ ret = device_create_file(&intf->dev, &dev_attr_##_name); \
+ if (unlikely(ret)) \
+ goto fail_sysfs;
+ CXACRU_ALL_FILES(CREATE);
+ #undef CXACRU_DEVICE_CREATE_FILE
+
/* start ADSL */
mutex_lock(&instance->adsl_state_serialize);
ret = cxacru_cm(instance, CM_REQUEST_CHIP_ADSL_LINE_START, NULL, 0,
NULL, 0);
@@ -680,6 +699,11 @@ static int cxacru_atm_start(struct usbatm_data
*usbatm_instance,
if (start_polling)
cxacru_poll_status(&instance->poll_work.work);
return 0;
+
+fail_sysfs:
+ usb_err(usbatm_instance, "cxacru_atm_start: device_create_file failed
(%d)\n", ret);
+ cxacru_remove_device_files(usbatm_instance, atm_dev);
+ return ret;
}
static void cxacru_poll_status(struct work_struct *work)
@@ -1065,13 +1089,6 @@ static int cxacru_bind(struct usbatm_data
*usbatm_instance,
goto fail;
}
- #define CXACRU_DEVICE_CREATE_FILE(_name) \
- ret = device_create_file(&intf->dev, &dev_attr_##_name); \
- if (unlikely(ret)) \
- goto fail_sysfs;
- CXACRU_ALL_FILES(CREATE);
- #undef CXACRU_DEVICE_CREATE_FILE
-
usb_fill_int_urb(instance->rcv_urb,
usb_dev, usb_rcvintpipe(usb_dev, CXACRU_EP_CMD),
instance->rcv_buf, PAGE_SIZE,
@@ -1092,14 +1109,6 @@ static int cxacru_bind(struct usbatm_data
*usbatm_instance,
return 0;
- fail_sysfs:
- dbg("cxacru_bind: device_create_file failed (%d)\n", ret);
-
- #define CXACRU_DEVICE_REMOVE_FILE(_name) \
- device_remove_file(&intf->dev, &dev_attr_##_name);
- CXACRU_ALL_FILES(REMOVE);
- #undef CXACRU_DEVICE_REVOVE_FILE
-
fail:
free_page((unsigned long) instance->snd_buf);
free_page((unsigned long) instance->rcv_buf);
@@ -1146,11 +1155,6 @@ static void cxacru_unbind(struct usbatm_data
*usbatm_instance,
free_page((unsigned long) instance->snd_buf);
free_page((unsigned long) instance->rcv_buf);
- #define CXACRU_DEVICE_REMOVE_FILE(_name) \
- device_remove_file(&intf->dev, &dev_attr_##_name);
- CXACRU_ALL_FILES(REMOVE);
- #undef CXACRU_DEVICE_REVOVE_FILE
-
kfree(instance);
usbatm_instance->driver_data = NULL;
@@ -1231,6 +1235,7 @@ static struct usbatm_driver cxacru_driver = {
.heavy_init = cxacru_heavy_init,
.unbind = cxacru_unbind,
.atm_start = cxacru_atm_start,
+ .atm_stop = cxacru_remove_device_files,
.bulk_in= CXACRU_EP_DATA,
.bulk_out = CXACRU_EP_DATA,
.rx_padding = 3,
--
1.5.2.1
-
To unsubscribe from this list: sen
[PATCH 4/9] USB: UNUSUAL_DEV: Sync up some reported devices from Ubuntu
From: Ben Collins <[EMAIL PROTECTED]> UNUSUAL_DEV: Sync up some reported devices from Ubuntu Various unusual dev entries accumulated from Ubuntu bug reports. Signed-off-by: Ben Collins <[EMAIL PROTECTED]> Cc: Alan Stern <[EMAIL PROTECTED]> Signed-off-by: Phil Dibowitz <[EMAIL PROTECTED]> --- drivers/usb/storage/unusual_devs.h | 21 +++-- 1 files changed, 19 insertions(+), 2 deletions(-) diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index d230ee7..54979c2 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -1179,8 +1179,8 @@ UNUSUAL_DEV( 0x0a17, 0x006, 0x, 0x, US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_FIX_INQUIRY ), -/* These are virtual windows driver CDs, which the zd1211rw driver automatically - * converts into a WLAN devices. */ +/* These are virtual windows driver CDs, which the zd1211rw driver + * automatically converts into WLAN devices. */ UNUSUAL_DEV( 0x0ace, 0x2011, 0x0101, 0x0101, "ZyXEL", "G-220F USB-WLAN Install", @@ -1193,6 +1193,14 @@ UNUSUAL_DEV( 0x0ace, 0x20ff, 0x0101, 0x0101, US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_DEVICE ), +/* SanDisk that has a second LUN for a driver ISO, reported by + * Ben Collins <[EMAIL PROTECTED]> */ +UNUSUAL_DEV( 0x0781, 0x5406, 0x, 0x, + "SanDisk", + "U3 Cruzer Micro driver ISO", + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_SINGLE_LUN ), + #ifdef CONFIG_USB_STORAGE_ISD200 UNUSUAL_DEV( 0x0bf6, 0xa001, 0x0100, 0x0110, "ATI", @@ -1271,6 +1279,15 @@ UNUSUAL_DEV( 0x0dd8, 0x1060, 0x, 0x, US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_FIX_INQUIRY ), +/* Reported by Edward Chapman (taken from linux-usb mailing list) + Netac OnlyDisk Mini U2CV2 512MB USB 2.0 Flash Drive */ +UNUSUAL_DEV( 0x0dd8, 0xd202, 0x, 0x, + "Netac", + "USB Flash Disk", + US_SC_DEVICE, US_PR_DEVICE, NULL, + US_FL_IGNORE_RESIDUE ), + + /* Patch by Stephan Walter <[EMAIL PROTECTED]> * I don't know why, but it works... */ UNUSUAL_DEV( 0x0dda, 0x0001, 0x0012, 0x0012, -- 1.5.2.1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] USB: cxacru: add Documentation file
From: Simon Arlott <[EMAIL PROTECTED]> The sysfs attributes for exposing cxacru statistics/status information with possible values is now explained in Documentation/networking/cxacru.txt including information on the writable adsl_state attribute's commands and a sample of the kernel log format. Signed-off-by: Simon Arlott <[EMAIL PROTECTED]> Cc: Duncan Sands <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- Documentation/networking/00-INDEX |2 + Documentation/networking/cxacru.txt | 84 +++ 2 files changed, 86 insertions(+), 0 deletions(-) create mode 100644 Documentation/networking/cxacru.txt diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index e06b6e3..153d84d 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -32,6 +32,8 @@ cops.txt - info on the COPS LocalTalk Linux driver cs89x0.txt - the Crystal LAN (CS8900/20-based) Ethernet ISA adapter driver +cxacru.txt + - Conexant AccessRunner USB ADSL Modem de4x5.txt - the Digital EtherWORKS DE4?? and DE5?? PCI Ethernet driver decnet.txt diff --git a/Documentation/networking/cxacru.txt b/Documentation/networking/cxacru.txt new file mode 100644 index 000..b074681 --- /dev/null +++ b/Documentation/networking/cxacru.txt @@ -0,0 +1,84 @@ +Firmware is required for this device: http://accessrunner.sourceforge.net/ + +While it is capable of managing/maintaining the ADSL connection without the +module loaded, the device will sometimes stop responding after unloading the +driver and it is necessary to unplug/remove power to the device to fix this. + +Detected devices will appear as ATM devices named "cxacru". In /sys/class/atm/ +these are directories named cxacruN where N is the device number. A symlink +named device points to the USB interface device's directory which contains +several sysfs attribute files for retrieving device statistics: + +* adsl_controller_version + +* adsl_headend +* adsl_headend_environment + Information about the remote headend. + +* downstream_attenuation (dB) +* downstream_bits_per_frame +* downstream_rate (kbps) +* downstream_snr_margin (dB) + Downstream stats. + +* upstream_attenuation (dB) +* upstream_bits_per_frame +* upstream_rate (kbps) +* upstream_snr_margin (dB) +* transmitter_power (dBm/Hz) + Upstream stats. + +* downstream_crc_errors +* downstream_fec_errors +* downstream_hec_errors +* upstream_crc_errors +* upstream_fec_errors +* upstream_hec_errors + Error counts. + +* line_startable + Indicates that ADSL support on the device + is/can be enabled, see adsl_start. + +* line_status + "initialising" + "down" + "attempting to activate" + "training" + "channel analysis" + "exchange" + "waiting" + "up" + + Changes between "down" and "attempting to activate" + if there is no signal. + +* link_status + "not connected" + "connected" + "lost" + +* mac_address + +* modulation + "ANSI T1.413" + "ITU-T G.992.1 (G.DMT)" + "ITU-T G.992.2 (G.LITE)" + +* startup_attempts + Count of total attempts to initialise ADSL. + +To enable/disable ADSL, the following can be written to the adsl_state file: + "start" + "stop + "restart" (stops, waits 1.5s, then starts) + "poll" (used to resume status polling if it was disabled due to failure) + +Changes in adsl/line state are reported via kernel log messages: + [4942145.150704] ATM dev 0: ADSL state: running + [4942243.663766] ATM dev 0: ADSL line: down + [4942249.665075] ATM dev 0: ADSL line: attempting to activate + [4942253.654954] ATM dev 0: ADSL line: training + [4942255.666387] ATM dev 0: ADSL line: channel analysis + [4942259.656262] ATM dev 0: ADSL line: exchange + [2635357.696901] ATM dev 0: ADSL line: up (8128 kb/s down | 832 kb/s up) -- 1.5.2.1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/9] usblp: Don't let suspend to kill ->used
From: Pete Zaitcev <[EMAIL PROTECTED]>
Suspend destroys refcounting for open/release.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/class/usblp.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index 7b1edfe..6778f9a 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -347,10 +347,8 @@ static int handle_bidir (struct usblp *usblp)
if (usblp->bidir && usblp->used && !usblp->sleeping) {
usblp->readcount = 0;
usblp->readurb->dev = usblp->dev;
- if (usb_submit_urb(usblp->readurb, GFP_KERNEL) < 0) {
- usblp->used = 0;
+ if (usb_submit_urb(usblp->readurb, GFP_KERNEL) < 0)
return -EIO;
- }
}
return 0;
@@ -412,6 +410,7 @@ static int usblp_open(struct inode *inode, struct file
*file)
usblp->readurb->status = 0;
if (handle_bidir(usblp) < 0) {
+ usblp->used = 0;
file->private_data = NULL;
retval = -EIO;
}
--
1.5.2.1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] USB: usb gadgets avoid le{16,32}_to_cpup()
From: David Brownell <[EMAIL PROTECTED]>
It turns out that le16_to_cpup() and le32_to_cpup() aren't always safe
to call with pointers into packed structures, since those are inlined
functions and GCC may lose the "packed" attribute. So those references
can become unaligned kernel accesses, which are evil on some hardware.
This patch updates uses of those routines in the gadget stack. The
references into packed structures can just use leXX_to_cpu(*x), which
in most cases is more natural. Some other uses in RNDIS, mostly in
debug code, were wrong in the first place; those use get_unaligned().
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/gadget/epautoconf.c |2 +-
drivers/usb/gadget/inode.c |8
drivers/usb/gadget/net2280.c|6 +++---
drivers/usb/gadget/omap_udc.c |6 +++---
drivers/usb/gadget/rndis.c | 35 ++-
5 files changed, 33 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index f28af06..6042364 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -132,7 +132,7 @@ ep_matches (
* where it's an output parameter representing the full speed limit.
* the usb spec fixes high speed bulk maxpacket at 512 bytes.
*/
- max = 0x7ff & le16_to_cpup (&desc->wMaxPacketSize);
+ max = 0x7ff & le16_to_cpu(desc->wMaxPacketSize);
switch (type) {
case USB_ENDPOINT_XFER_INT:
/* INT: limit 64 bytes full speed, 1024 high speed */
diff --git a/drivers/usb/gadget/inode.c b/drivers/usb/gadget/inode.c
index 188c74a..46d0e52 100644
--- a/drivers/usb/gadget/inode.c
+++ b/drivers/usb/gadget/inode.c
@@ -1369,12 +1369,12 @@ config_buf (struct dev_data *dev, u8 type, unsigned
index)
hs = !hs;
if (hs) {
dev->req->buf = dev->hs_config;
- len = le16_to_cpup (&dev->hs_config->wTotalLength);
+ len = le16_to_cpu(dev->hs_config->wTotalLength);
} else
#endif
{
dev->req->buf = dev->config;
- len = le16_to_cpup (&dev->config->wTotalLength);
+ len = le16_to_cpu(dev->config->wTotalLength);
}
((u8 *)dev->req->buf) [1] = type;
return len;
@@ -1885,7 +1885,7 @@ dev_config (struct file *fd, const char __user *buf,
size_t len, loff_t *ptr)
/* full or low speed config */
dev->config = (void *) kbuf;
- total = le16_to_cpup (&dev->config->wTotalLength);
+ total = le16_to_cpu(dev->config->wTotalLength);
if (!is_valid_config (dev->config) || total >= length)
goto fail;
kbuf += total;
@@ -1894,7 +1894,7 @@ dev_config (struct file *fd, const char __user *buf,
size_t len, loff_t *ptr)
/* optional high speed config */
if (kbuf [1] == USB_DT_CONFIG) {
dev->hs_config = (void *) kbuf;
- total = le16_to_cpup (&dev->hs_config->wTotalLength);
+ total = le16_to_cpu(dev->hs_config->wTotalLength);
if (!is_valid_config (dev->hs_config) || total >= length)
goto fail;
kbuf += total;
diff --git a/drivers/usb/gadget/net2280.c b/drivers/usb/gadget/net2280.c
index 52779c5..d975ecf 100644
--- a/drivers/usb/gadget/net2280.c
+++ b/drivers/usb/gadget/net2280.c
@@ -2440,9 +2440,9 @@ static void handle_stat0_irqs (struct net2280 *dev, u32
stat)
tmp = 0;
-#definew_value le16_to_cpup (&u.r.wValue)
-#definew_index le16_to_cpup (&u.r.wIndex)
-#definew_lengthle16_to_cpup (&u.r.wLength)
+#definew_value le16_to_cpu(u.r.wValue)
+#definew_index le16_to_cpu(u.r.wIndex)
+#definew_lengthle16_to_cpu(u.r.wLength)
/* ack the irq */
writel (1 << SETUP_PACKET_INTERRUPT, &dev->regs->irqstat0);
diff --git a/drivers/usb/gadget/omap_udc.c b/drivers/usb/gadget/omap_udc.c
index b394e63..c4975a6 100644
--- a/drivers/usb/gadget/omap_udc.c
+++ b/drivers/usb/gadget/omap_udc.c
@@ -1651,9 +1651,9 @@ static void ep0_irq(struct omap_udc *udc, u16 irq_src)
UDC_EP_NUM_REG = 0;
} while (UDC_IRQ_SRC_REG & UDC_SETUP);
-#definew_value le16_to_cpup (&u.r.wValue)
-#definew_index le16_to_cpup (&u.r.wIndex)
-#definew_lengthle16_to_cpup (&u.r.wLength)
+#definew_value le16_to_cpu(u.r.wValue)
+#definew_index le16_to_cpu(u.r.wIndex)
+#definew_lengthle16_to_cpu(u.r.wLength)
/* Delegate almost all control requests to the gadget driver,
* except for a handful of ch9 status/feature requests that
diff --git a/drivers/usb/gadget/rndis.c b/drivers/usb/gadget/rndis.c
index 6e
[GIT PATCH] USB fixes for 2.6.22-rc4
Here are some USB fixes against your 2.6.22-rc4 tree.
They fix a number of minor things and update some documentation and add
some usb-storage quirks, and make the config option a default that has
been tripping up some usbfs users with older udev configurations.
All of these have been in the -mm releases for a while.
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-devel mailing list, if
anyone wants to see them.
thanks,
greg k-h
Documentation/networking/00-INDEX |2 +
Documentation/networking/cxacru.txt | 84 +++
drivers/usb/atm/cxacru.c| 52 +++---
drivers/usb/class/usblp.c |5 +-
drivers/usb/core/Kconfig| 22 +
drivers/usb/core/config.c | 42 +-
drivers/usb/gadget/epautoconf.c |2 +-
drivers/usb/gadget/inode.c |8 ++--
drivers/usb/gadget/net2280.c|6 +-
drivers/usb/gadget/omap_udc.c |6 +-
drivers/usb/gadget/rndis.c | 35 +-
drivers/usb/host/ohci-hub.c |2 +
drivers/usb/storage/unusual_devs.h | 21 -
13 files changed, 222 insertions(+), 65 deletions(-)
create mode 100644 Documentation/networking/cxacru.txt
---
Alan Stern (2):
USB: Fix up bogus bInterval values in endpoint descriptors
OHCI: Fix machine check in ohci_hub_status_data
Ben Collins (1):
USB: UNUSUAL_DEV: Sync up some reported devices from Ubuntu
David Brownell (1):
USB: usb gadgets avoid le{16,32}_to_cpup()
Kay Sievers (1):
USB: set default y for CONFIG_USB_DEVICE_CLASS
Pete Zaitcev (1):
usblp: Don't let suspend to kill ->used
Simon Arlott (3):
USB: cxacru: add Documentation file
USB: cxacru: create sysfs attributes in atm_start instead of bind
USB: cxacru: ignore error trying to start ADSL in atm_start
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] shm: Fix the filename of hugetlb sysv shared memory
On Fri, 08 Jun 2007 17:43:34 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > Some user space tools need to identify SYSV shared memory when > examining /proc//maps. To do so they look for a block device > with major zero, a dentry named SYSV, and having the minor of > the internal sysv shared memory kernel mount. > > To help these tools and to make it easier for people just browsing > /proc//maps this patch modifies hugetlb sysv shared memory to > use the SYSV dentry naming convention. > > User space tools will still have to be aware that hugetlb sysv > shared memory lives on a different internal kernel mount and so > has a different block device minor number from the rest of sysv > shared memory. I assume this fix is preferred over Badari's? If so, why? From: Badari Pulavarty <[EMAIL PROTECTED]> shmid used to be stored as inode# for shared memory segments. Some of the proc-ps tools use this from /proc/pid/maps. Recent cleanups to newseg() changed it. This patch sets inode number back to shared memory id to fix breakage. Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]> Cc: "Albert Cahalan" <[EMAIL PROTECTED]> Cc: "Eric W. Biederman" <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- ipc/shm.c |5 + 1 files changed, 5 insertions(+) diff -puN ipc/shm.c~restore-shmid-as-inode-to-fix-proc-pid-maps-abi-breakage ipc/shm.c --- a/ipc/shm.c~restore-shmid-as-inode-to-fix-proc-pid-maps-abi-breakage +++ a/ipc/shm.c @@ -397,6 +397,11 @@ static int newseg (struct ipc_namespace shp->shm_nattch = 0; shp->id = shm_buildid(ns, id, shp->shm_perm.seq); shp->shm_file = file; + /* +* shmid gets reported as "inode#" in /proc/pid/maps. +* proc-ps tools use this. Changing this will break them. +*/ + file->f_dentry->d_inode->i_ino = shp->id; ns->shm_tot += numpages; shm_unlock(shp); _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Move led attributes out of device name and into sysfs attributes, was Re: LED devices
On Sat, Jun 09, 2007 at 12:02:28AM +0100, Richard Purdie wrote: > On Fri, 2007-06-08 at 11:57 -0700, Greg KH wrote: > > On Fri, Jun 01, 2007 at 05:23:24PM +0100, Richard Purdie wrote: > > > I still question whether either colour or function properties are > > > actually particularly useful to userspace other than for naming purposes > > > which is why they were part of the device name. > > > > > > Anyhow, I'm trying not to say too much more as it will just go in > > > circles. I'll await a reply from Greg. > > > > Hm, I thought I made my opinion pretty clear in the beginning. > > > > Why not just do a simple: > > led01 > > led02 > > led03 > > ... > > > > and so on? > > If we do this, my point is we're exporting something to userspace which > is totally devoid of information. Just like all other subsystems? No, the only information the device name is that it shows a UNIQUE name at that point in time in the kernel. Heck, we could just use random numbers that are unique like some other people have suggested, it would mean the exact same thing. > sysfs is for userspace and "led01" means absolutely nothing to it. Wrong, the attributes in that directory mean everything. The name means nothing. > The most you can summarise from it is it happens to have registered > first and its an LED. Exactly. > Since its in class/leds/ we can summarise the latter without help from > the prefix. I'd hate to think userspace cares about the former. Ok, then use a random number please. Start with 01 and just increment from there, or use the idr subsystem. I was trying to be nice and at least give you a prefix that looked kind of sane to people, but if you want to be difficult... :) > > > And use the 'name' field to put the name of your device (disk, > > bluetooth, etc.) This is the way all other busses and devices work, and > > I don't think that LEDs are anything more "special" than anything else > > in the kernel, right? > > Since the "busid" field means absolutely nothing, why not give it a > sensible id and save the overhead of a separate name? Because that is not how things work, sorry. > If kernel policy is that we should have useless data in sysfs, so be it, > I just make sure that is on record and then break the defined LED class > API. Again, the bus id needs to be unique, for that specific class/bus that's it. The attributes in the directory let you figure out what specifics are for the device. Look at the PCI and USB devices. There is some information you can glean from those names, but they are primary a unique identifier, you need to look at the attributes to get the real information about your device. LED devices are no different. > > Ok, so I make the point above with a sledge hammer. There are more > subtle issues here too. People are asking for a ton of extra attributes > for the LED class. We can have a name, a colour, an LED "function", a > location on the device and probably 101 other things. Great, the more the merrier. Seriously, I have no problem with that. > As I understand it, sysfs was put there to pass information *the kernel > knows* to userspace. The kernel doesn't actually care about the location > of an LED or its colour. All the kernel cares is we have an LED and it > has a certain brightness. If you know the color and location already, why not export that information? Unless you can determine it from userspace some other way already? > Yes, we can teach the kernel all this extra info but it is simply to > pass to userspace. Why should my kernel be bloated with all that extra > information which it doesn't need itself? If there's no other way for userspace to determine it, then put it in the kernel. Otherwise leave it for userspace to handle. > My conclusion is that there should be something in userspace > supplementing this information from the kernel. Going back the the > problem at hand, HAL is already equipped to do this, all it needs is > some kind of unique ID so it can identify the LED. This would be the > busid. Well, if that is possible. Just put it in an attribute. > So I do stand by what the LED class does as being sane. Yes, the class > defined a way of writing its busids which isn't like any other but there > is a good reason for it. We could make it machine readable to provide > hints to userspace and I never saw any reason why we shouldn't have > done. It was discussed on LKML and no objections were raised (it was in > fact requested). The choice of field separator is unfortunate since its > developed other meanings after it was used in the LED class, such is > life. Sorry, I missed it with the other stuff on lkml, but now I'm trying to get this fixed. Just use an attribute like the whole rest of the kernel and a number for a bus id. > So there are various options: > > 1. We keep 'useful' busids and the LED class continues as is. We accept > classes can provide a busid naming policy if it makes sense. Nope. >
[PATCH] shm: Fix the filename of hugetlb sysv shared memory
Some user space tools need to identify SYSV shared memory when
examining /proc//maps. To do so they look for a block device
with major zero, a dentry named SYSV, and having the minor of
the internal sysv shared memory kernel mount.
To help these tools and to make it easier for people just browsing
/proc//maps this patch modifies hugetlb sysv shared memory to
use the SYSV dentry naming convention.
User space tools will still have to be aware that hugetlb sysv
shared memory lives on a different internal kernel mount and so
has a different block device minor number from the rest of sysv
shared memory.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
fs/hugetlbfs/inode.c|7 ++-
include/linux/hugetlb.h |4 ++--
ipc/shm.c |6 +++---
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index aa083dd..e6b46b3 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -736,15 +736,13 @@ static int can_do_hugetlb_shm(void)
can_do_mlock());
}
-struct file *hugetlb_zero_setup(size_t size)
+struct file *hugetlb_file_setup(const char *name, size_t size)
{
int error = -ENOMEM;
struct file *file;
struct inode *inode;
struct dentry *dentry, *root;
struct qstr quick_string;
- char buf[16];
- static atomic_t counter;
if (!hugetlbfs_vfsmount)
return ERR_PTR(-ENOENT);
@@ -756,8 +754,7 @@ struct file *hugetlb_zero_setup(size_t size)
return ERR_PTR(-ENOMEM);
root = hugetlbfs_vfsmount->mnt_root;
- snprintf(buf, 16, "%u", atomic_inc_return(&counter));
- quick_string.name = buf;
+ quick_string.name = name;
quick_string.len = strlen(quick_string.name);
quick_string.hash = 0;
dentry = d_alloc(root, &quick_string);
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index b4570b6..2c13715 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -163,7 +163,7 @@ static inline struct hugetlbfs_sb_info *HUGETLBFS_SB(struct
super_block *sb)
extern const struct file_operations hugetlbfs_file_operations;
extern struct vm_operations_struct hugetlb_vm_ops;
-struct file *hugetlb_zero_setup(size_t);
+struct file *hugetlb_file_setup(const char *name, size_t);
int hugetlb_get_quota(struct address_space *mapping);
void hugetlb_put_quota(struct address_space *mapping);
@@ -185,7 +185,7 @@ static inline void set_file_hugepages(struct file *file)
#define is_file_hugepages(file)0
#define set_file_hugepages(file) BUG()
-#define hugetlb_zero_setup(size) ERR_PTR(-ENOSYS)
+#define hugetlb_file_setup(name,size) ERR_PTR(-ENOSYS)
#endif /* !CONFIG_HUGETLBFS */
diff --git a/ipc/shm.c b/ipc/shm.c
index 4fefbad..c31f743 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -364,9 +364,10 @@ static int newseg (struct ipc_namespace *ns, key_t key,
int shmflg, size_t size)
return error;
}
+ sprintf (name, "SYSV%08x", key);
if (shmflg & SHM_HUGETLB) {
- /* hugetlb_zero_setup takes care of mlock user accounting */
- file = hugetlb_zero_setup(size);
+ /* hugetlb_file_setup takes care of mlock user accounting */
+ file = hugetlb_file_setup(name, size);
shp->mlock_user = current->user;
} else {
int acctflag = VM_ACCOUNT;
@@ -377,7 +378,6 @@ static int newseg (struct ipc_namespace *ns, key_t key, int
shmflg, size_t size)
if ((shmflg & SHM_NORESERVE) &&
sysctl_overcommit_memory != OVERCOMMIT_NEVER)
acctflag = 0;
- sprintf (name, "SYSV%08x", key);
file = shmem_file_setup(name, size, acctflag);
}
error = PTR_ERR(file);
--
1.5.1.1.181.g2de0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] trim memory not covered by WB MTRRs
Jesse Barnes <[EMAIL PROTECTED]> writes: >> - Overlapping MTRRs. > > Overlapping should be ok, since that's usually intentional (e.g. one big > wb range with a portion of uc space due to another mtrr). I'm not say overlapping was a bug. I was saying that you don't handle overlapping mtrrs in figuring the last cached addresses. Therefore when a UC range overlaps a WB range we might thing the last page in the WB range is cached when it is not. >> - What happens if we have uncached memory lower down? > > Holes definitely aren't dealt with, but then we haven't seen any yet... > >> Except for performance problems I guess that case is relatively >> harmless. - Is it possible and worth it to amend the e820 map, so it >> shows the problem area as Reserved or otherwise not usable RAM? > > That would be useful, but only if we moved the check to a little > earlier, prior to the addition of the active ranges from the e820. > Might be a little nicer than adjusting end_pfn, but will ultimately > achieve the same thing... Yes, with perhaps a little more consistency. 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 2.6.21] cramfs: add cramfs Linear XIP
The downside: We need mem_map[] struct page entries behind all memory segments. Nowerdays we can easily create those via vmem_map/sparsemem. Opinions? Frankly this is going to be mostly relevant on ARM architectures at least at first. Maybe I'm missing something but I don't see that sparemem is supported on ARM... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Move led attributes out of device name and into sysfs attributes, was Re: LED devices
On Fri, 2007-06-08 at 11:57 -0700, Greg KH wrote: > On Fri, Jun 01, 2007 at 05:23:24PM +0100, Richard Purdie wrote: > > I still question whether either colour or function properties are > > actually particularly useful to userspace other than for naming purposes > > which is why they were part of the device name. > > > > Anyhow, I'm trying not to say too much more as it will just go in > > circles. I'll await a reply from Greg. > > Hm, I thought I made my opinion pretty clear in the beginning. > > Why not just do a simple: > led01 > led02 > led03 > ... > > and so on? If we do this, my point is we're exporting something to userspace which is totally devoid of information. sysfs is for userspace and "led01" means absolutely nothing to it. The most you can summarise from it is it happens to have registered first and its an LED. Since its in class/leds/ we can summarise the latter without help from the prefix. I'd hate to think userspace cares about the former. > And use the 'name' field to put the name of your device (disk, > bluetooth, etc.) This is the way all other busses and devices work, and > I don't think that LEDs are anything more "special" than anything else > in the kernel, right? Since the "busid" field means absolutely nothing, why not give it a sensible id and save the overhead of a separate name? If kernel policy is that we should have useless data in sysfs, so be it, I just make sure that is on record and then break the defined LED class API. Ok, so I make the point above with a sledge hammer. There are more subtle issues here too. People are asking for a ton of extra attributes for the LED class. We can have a name, a colour, an LED "function", a location on the device and probably 101 other things. As I understand it, sysfs was put there to pass information *the kernel knows* to userspace. The kernel doesn't actually care about the location of an LED or its colour. All the kernel cares is we have an LED and it has a certain brightness. Yes, we can teach the kernel all this extra info but it is simply to pass to userspace. Why should my kernel be bloated with all that extra information which it doesn't need itself? My conclusion is that there should be something in userspace supplementing this information from the kernel. Going back the the problem at hand, HAL is already equipped to do this, all it needs is some kind of unique ID so it can identify the LED. This would be the busid. So I do stand by what the LED class does as being sane. Yes, the class defined a way of writing its busids which isn't like any other but there is a good reason for it. We could make it machine readable to provide hints to userspace and I never saw any reason why we shouldn't have done. It was discussed on LKML and no objections were raised (it was in fact requested). The choice of field separator is unfortunate since its developed other meanings after it was used in the LED class, such is life. So there are various options: 1. We keep 'useful' busids and the LED class continues as is. We accept classes can provide a busid naming policy if it makes sense. 2. We adopt free form busids and export a ton of attributes just useful to userspace (bloating the kernel IMO). 3. As 2. but use 'useless' busids that mean nothing. 4. We adopt free form busids but let userspace fill in its own information based on the busid (no policy on naming). 5. Other combinations thereof. I'm very aware I'm isolated here and ultimately this is probably Greg's decision which I will end up abiding by. If anyone else does have a view, speak now ;-). I think there are some important issues here and they do need clarification, one way or another. Cheers, Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
On Sat, 9 Jun 2007, Andi Kleen wrote: > > Why was it not allowed? Because interrupts are disabled? > > Allocating memory during page out under low memory could > lead to deadlocks. That is because Linux used to make no attempt > to limit dirty pages for anonymous mappings and then you could > end up with most of your memory dirty and not enough > memory cleanable for page out and then when page out > needs more memory you could be dead. > > [yes that implies that mmap over NFS was always broken] Right. We got that fixed in 2.6.19. > Now there is a anon dirty limit since a few releases, but I'm not > fully convinced it solves the problem completely. A gut feeling or is there more? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
On Saturday 09 June 2007 00:36, Christoph Lameter wrote: > On Fri, 8 Jun 2007, Andreas Kleen wrote: > > > That's what kmem_cache_alloc() is for?!?! > > > > Tradtionally that was not allowed in block layer path. Not sure > > it is fully obsolete with the recent dirty tracking work, probably not. > > Why was it not allowed? Because interrupts are disabled? Allocating memory during page out under low memory could lead to deadlocks. That is because Linux used to make no attempt to limit dirty pages for anonymous mappings and then you could end up with most of your memory dirty and not enough memory cleanable for page out and then when page out needs more memory you could be dead. [yes that implies that mmap over NFS was always broken] Now there is a anon dirty limit since a few releases, but I'm not fully convinced it solves the problem completely. > > Besides it would need to be GFP_ATOMIC and the default > > atomic pools are not that big. > > Those could be increased. I think Mel has them already increased in mm. That would be lots of wasted memory. I already got >100 MB free on my workstation under steady caching state. Already far too much imho. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
On Fri, 8 Jun 2007, Keshavamurthy, Anil S wrote: > > What functionality are you missing in the page allocator? It seems that is > > does what you want? > Humm..I basically want to allocate memory during interrupt context and > expect not to fail. I know this is a hard requirement :) The page allocator can do that for you. The reserves are configurable. Not failing is a thing unseen in the computer world. > I want to be able to reserve certain amount of memory specifically for > IOMMU purpose. That is of course a problem unless you allocate memory beforehand. Mempool? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
On Fri, Jun 08, 2007 at 03:33:39PM -0700, Christoph Lameter wrote: > On Fri, 8 Jun 2007, Keshavamurthy, Anil S wrote: > > > > You _seem_ to be saying that the resource pools are there purely for > > > alloc/free performance reasons. If so, I'd be skeptical: slab is pretty > > > darned fast. > > We need several objects of size say( 4 * sizeof(u64)) and reuse > > them in dma map/unmap api calls for managing io virtual allocation address > > that > > this driver has dished out. Hence having pool of objects where we put > > the element in the linked list and and get it from the linked list is pretty > > fast compared to slab. > > SLUB also manages objects using a linked list. Is there a real performance > difference? Sorry, I have not tried using SLUB, I will surely check this out. -Anil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
On Fri, Jun 08, 2007 at 03:32:08PM -0700, Christoph Lameter wrote: > On Fri, 8 Jun 2007, Keshavamurthy, Anil S wrote: > > > In the IOMMU case, we need exactly opposite of what mempool provides, > > i.e we always want to look for the element in the pool and if the pool > > has no element then go to OS as a worst case. This resource pool > > library routines do the same. Again, this resource pools > > grows and shrinks automatically to maintain the minimum pool > > elements in the background. I am not sure whether this totally > > opposite functionality of mempools and resource pools can be > > merged. > > What functionality are you missing in the page allocator? It seems that is > does what you want? Humm..I basically want to allocate memory during interrupt context and expect not to fail. I know this is a hard requirement :) I want to be able to reserve certain amount of memory specifically for IOMMU purpose. -Anil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] [PATCH i386] during VM oom condition, kill all threads in process group
Will Schmidt <[EMAIL PROTECTED]> writes: > On Fri, 2007-06-08 at 12:32 -0700, Andrew Morton wrote: >> On Fri, 08 Jun 2007 14:19:18 -0500 >> Will Schmidt <[EMAIL PROTECTED]> wrote: >> >> > > > > zap_other_threads() requires tasklist_lock. >> > > >> In fact, it's probably the case that rcu_read_lock() is now sufficient >> locking coverage for zap_other_threads() (cc's people). >> >> It had better be, because do_group_exit() forgot to take tasklist_lock. It >> is perhaps relying upon spin_lock()'s hidden rcu_read_lock() properties >> without so much as a code comment, which would be somewhat nasty of it. > >> You could perhaps just call do_group_exit() from within the fault >> handler, >> btw. > > Yup, so looks like I can actually replace the existing do_exit() call > with do_group_exit(). I'll sit on this for a bit to give other folks a > chance to comment on which lock call is sufficient, read_lock() or > rcu_read_lock(), etc; and do_group_exit()'s issue with taking > tasklist_lock. No. The rcu_read_lock is not sufficient. Yes. sighand->siglock is enough, and we explicitly take it in do_group_exit before calling zap_other_threads. Unless I have completely miss-understood this thread. 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/
[PATCH 1/2] [RFC] PCI: read revision ID by default
Currently there are 97 occurrences where drivers need the pci
revision ID. We can do this once for all devices. Even the pci
subsystem needs the revision several times for quirks. The extra
u8 member pads out nicely in the pci_dev struct.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/pci/probe.c |3 +++
include/linux/pci.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e48fcf0..0fdb71d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -918,6 +918,9 @@ pci_scan_device(struct pci_bus *bus, int devfn)
dev->cfg_size = pci_cfg_space_size(dev);
dev->error_state = pci_channel_io_normal;
+ /* read the PCI revision: 1 byte */
+ pci_read_config_byte(dev, PCI_REVISION_ID, &dev->revision);
+
/* Assume 32-bit PCI; let 64-bit PCI cards (which are far rarer)
set this higher, assuming the system even supports it. */
dev->dma_mask = 0x;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index fbf3766..9847936 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -138,6 +138,7 @@ struct pci_dev {
unsigned short subsystem_vendor;
unsigned short subsystem_device;
unsigned intclass; /* 3 bytes: (base,sub,prog-if) */
+ u8 revision; /* PCI revision, low byte of class word
*/
u8 hdr_type; /* PCI header type (`multi' flag masked
out) */
u8 rom_base_reg; /* which config register controls the
ROM */
u8 pin;/* which interrupt pin this device uses
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] Replace DPRINTK with pr_debug in autofs
Jack Stone wrote: > Signed-off-by: Jack Stone <[EMAIL PROTECTED]> Acked-By: H. Peter Anvin <[EMAIL PROTECTED]> As far as I can tell, autofs 3 has fallen into disuse, and autofs 4/5 has matured to the point where I don't think there is any major reason to use autofs 3 anymore. It probably should be put on the chopping block. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 7/8] fdmap v2 - implement sys_socket2
On Fri, 8 Jun 2007, Alan Cox wrote: > > > > It does not work. What if the main application, library A and library B > > > > wants to implement their own allocation strategy? > > > > > > Its called "discipline". I would suggest that libc contains a default > > > allocator. You might also want to assign library and application ranges > > > for clarity. > > > > That is really nice solution. Each library has to have each own allocator. > > Are you being deliberately stupid ? > > I suggested *libc* contains a default allocator "You might also want to assign library and application ranges for clarity." So let's see. We have the legacy one (1st fdtable), the non-legacy app one (2nd fdtable) and one for the library (3rd fdtable). And which library? Each one his own (4th, 5th ... fdtable)? ... > > replicated all around the code that access directly the fdtables. I did > > the fdmap consolidation patch, and I can tell you there are quite a few > > places that access fdtables directly. > > This is true, but if you are worried about complexity we get back to the > original posix allocator which packs them in tight and produces a most > excellent spread in the general case (whacko apps like bash aside) ... complexity does not come from the allocator, but from the fact that direct access to the fdtable is done all over the kernel. Code that assumes there's only *one* fdtable. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
On Fri, 8 Jun 2007, Andreas Kleen wrote: > > That's what kmem_cache_alloc() is for?!?! > > Tradtionally that was not allowed in block layer path. Not sure > it is fully obsolete with the recent dirty tracking work, probably not. Why was it not allowed? Because interrupts are disabled? > Besides it would need to be GFP_ATOMIC and the default > atomic pools are not that big. Those could be increased. I think Mel has them already increased in mm. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
On Fri, 8 Jun 2007, Siddha, Suresh B wrote: > > If for some reason you really can't do that (and a requirement for > > allocation-in-interrupt is the only valid reason, really) and if you indeed > > can demonstrate memory allocation failures with certain workloads then > > let's take a look at that. As I said, attaching a reserve pool to your > > slab cache might be a suitable approach. But none of these things are > > I agree. We are better off with enhancing slab infrastructure for this, if > needed. The slab allocators already use the page allocators atomic reserves if called with GFP_ATOMIC. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] Replace DPRINTK with pr_debug in autofs
Signed-off-by: Jack Stone <[EMAIL PROTECTED]>
---
-#ifdef DEBUG
-#define DPRINTK(D) (printk D)
-#else
-#define DPRINTK(D) ((void)0)
-#endif
-
/*
* If the daemon returns a negative response (AUTOFS_IOC_FAIL) then the
* kernel will keep the negative response cached for up to the time given
Index: linux/fs/autofs/dirhash.c
===
--- linux.orig/fs/autofs/dirhash.c
+++ linux/fs/autofs/dirhash.c
@@ -77,7 +77,7 @@ struct autofs_dir_ent *autofs_expire(str
/* Make sure entry is mounted and unused; note that dentry will
point to the mounted-on-top root. */
if (!S_ISDIR(dentry->d_inode->i_mode)||!d_mountpoint(dentry)) {
- DPRINTK(("autofs: not expirable (not a mounted
directory): %s\n",
ent->name));
+ pr_debug("autofs: not expirable (not a mounted
directory): %s\n",
ent->name);
continue;
}
mntget(mnt);
@@ -85,7 +85,7 @@ struct autofs_dir_ent *autofs_expire(str
if (!follow_down(&mnt, &dentry)) {
dput(dentry);
mntput(mnt);
- DPRINTK(("autofs: not expirable (not a mounted
directory): %s\n",
ent->name));
+ pr_debug("autofs: not expirable (not a mounted
directory): %s\n",
ent->name);
continue;
}
while (d_mountpoint(dentry) && follow_down(&mnt, &dentry))
@@ -94,10 +94,10 @@ struct autofs_dir_ent *autofs_expire(str
if ( may_umount(mnt) ) {
mntput(mnt);
- DPRINTK(("autofs: signaling expire on %s\n",
ent->name));
+ pr_debug("autofs: signaling expire on %s\n", ent->name);
return ent; /* Expirable! */
}
- DPRINTK(("autofs: didn't expire due to may_umount: %s\n",
ent->name));
+ pr_debug("autofs: didn't expire due to may_umount: %s\n",
ent->name);
mntput(mnt);
}
return NULL;/* No expirable entries */
@@ -112,7 +112,7 @@ struct autofs_dir_ent *autofs_hash_looku
{
struct autofs_dir_ent *dhn;
- DPRINTK(("autofs_hash_lookup: hash = 0x%08x, name = ", name->hash));
+ pr_debug("autofs_hash_lookup: hash = 0x%08x, name = ", name->hash);
autofs_say(name->name,name->len);
for ( dhn = dh->h[(unsigned) name->hash % AUTOFS_HASH_SIZE] ; dhn ;
dhn = dhn->next ) {
@@ -129,7 +129,7 @@ void autofs_hash_insert(struct autofs_di
{
struct autofs_dir_ent **dhnp;
- DPRINTK(("autofs_hash_insert: hash = 0x%08x, name = ", ent->hash));
+ pr_debug("autofs_hash_insert: hash = 0x%08x, name = ", ent->hash);
autofs_say(ent->name,ent->len);
autofs_init_usage(dh,ent);
@@ -179,7 +179,7 @@ struct autofs_dir_ent *autofs_hash_enum(
bucket = ecount = 0;
}
- DPRINTK(("autofs_hash_enum: bucket %d, entry %d\n", bucket, ecount));
+ pr_debug("autofs_hash_enum: bucket %d, entry %d\n", bucket, ecount);
ent = last ? last->next : NULL;
Index: linux/fs/autofs/inode.c
===
--- linux.orig/fs/autofs/inode.c
+++ linux/fs/autofs/inode.c
@@ -48,7 +48,7 @@ void autofs_kill_sb(struct super_block *
kfree(sb->s_fs_info);
out_kill_sb:
- DPRINTK(("autofs: shutting down\n"));
+ pr_debug("autofs: shutting down\n");
kill_anon_super(sb);
}
@@ -146,7 +146,7 @@ int autofs_fill_super(struct super_block
sbi = kzalloc(sizeof(*sbi), GFP_KERNEL);
if (!sbi)
goto fail_unlock;
- DPRINTK(("autofs: starting up, sbi = %p\n",sbi));
+ pr_debug("autofs: starting up, sbi = %p\n",sbi);
s->s_fs_info = sbi;
sbi->magic = AUTOFS_SBI_MAGIC;
@@ -186,7 +186,7 @@ int autofs_fill_super(struct super_block
goto fail_dput;
}
- DPRINTK(("autofs: pipe fd = %d, pgrp = %u\n", pipefd, pgid));
+ pr_debug("autofs: pipe fd = %d, pgrp = %u\n", pipefd, pgid);
sbi->oz_pgrp = find_get_pid(pgid);
if (!sbi->oz_pgrp) {
Index: linux/fs/autofs/root.c
===
--- linux.orig/fs/autofs/root.c
+++ linux/fs/autofs/root.c
@@ -201,7 +201,7 @@ static struct dentry *autofs_root_lookup
struct autofs_sb_info *sbi;
int oz_mode;
- DPRINTK(("autofs_root_lookup: name = "));
+ pr_debug("autofs_root_lookup: name = ");
lock_kernel();
autofs_say(dentry->d_name.name,dentry->d_name.len);
@@ -213,10 +213,10 @@ static struct dentry *autofs_root_lookup
sbi = autofs_sbi(dir->i_sb);
oz_mode = autofs_oz_mode(sbi);
- DPRINTK(("autofs_lookup: pid = %u, pgrp = %u, catatonic = %d, "
+ pr_debug("autofs_lookup: pid = %u, pgrp = %u, catato
Re: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
On Fri, 8 Jun 2007, Keshavamurthy, Anil S wrote: > > You _seem_ to be saying that the resource pools are there purely for > > alloc/free performance reasons. If so, I'd be skeptical: slab is pretty > > darned fast. > We need several objects of size say( 4 * sizeof(u64)) and reuse > them in dma map/unmap api calls for managing io virtual allocation address > that > this driver has dished out. Hence having pool of objects where we put > the element in the linked list and and get it from the linked list is pretty > fast compared to slab. SLUB also manages objects using a linked list. Is there a real performance difference? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/7] Replace DPRINTK with pr_debug in alternative.c
Signed-off-by: Jack Stone <[EMAIL PROTECTED]>
---
-#define DPRINTK(fmt, args...) if (debug_alternative) \
- printk(KERN_DEBUG fmt, args)
-
#ifdef GENERIC_NOP1
/* Use inline assembly to define this because the nops are defined
as inline assembly strings in the include files and we cannot
@@ -165,7 +163,7 @@
u8 *instr;
int diff;
- DPRINTK("%s: alt table %p -> %p\n", __FUNCTION__, start, end);
+ pr_debug("%s: alt table %p -> %p\n", __FUNCTION__, start, end);
for (a = start; a < end; a++) {
BUG_ON(a->replacementlen > a->instrlen);
if (!boot_cpu_has(a->cpuid))
@@ -175,7 +173,7 @@
/* vsyscall code is not mapped yet. resolve it manually. */
if (instr >= (u8 *)VSYSCALL_START && instr < (u8*)VSYSCALL_END)
{
instr = __va(instr - (u8*)VSYSCALL_START +
(u8*)__pa_symbol(&__vsyscall_0));
- DPRINTK("%s: vsyscall fixup: %p => %p\n",
+ pr_debug("%s: vsyscall fixup: %p => %p\n",
__FUNCTION__, a->instr, instr);
}
#endif
@@ -261,7 +259,7 @@
smp->locks_end = locks_end;
smp->text = text;
smp->text_end = text_end;
- DPRINTK("%s: locks %p -> %p, text %p -> %p, name %s\n",
+ pr_debug("%s: locks %p -> %p, text %p -> %p, name %s\n",
__FUNCTION__, smp->locks, smp->locks_end,
smp->text, smp->text_end, smp->name);
@@ -287,7 +285,7 @@
continue;
list_del(&item->next);
spin_unlock_irqrestore(&smp_alt, flags);
- DPRINTK("%s: %s\n", __FUNCTION__, item->name);
+ pr_debug("%s: %s\n", __FUNCTION__, item->name);
kfree(item);
return;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
On Fri, 8 Jun 2007, Keshavamurthy, Anil S wrote: > In the IOMMU case, we need exactly opposite of what mempool provides, > i.e we always want to look for the element in the pool and if the pool > has no element then go to OS as a worst case. This resource pool > library routines do the same. Again, this resource pools > grows and shrinks automatically to maintain the minimum pool > elements in the background. I am not sure whether this totally > opposite functionality of mempools and resource pools can be > merged. What functionality are you missing in the page allocator? It seems that is does what you want? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] Update DPRINTK macro to use pr_debug in autofs4
Signed-off-by: Jack Stone <[EMAIL PROTECTED]>
---
#ifdef DEBUG
-#define DPRINTK(fmt,args...) do { printk(KERN_DEBUG "pid %d: %s: " fmt
"\n" , current->pid , __FUNCTION__ , ##args); } while(0)
+#define DPRINTK(fmt,args...) do { pr_debug("pid %d: %s: " fmt "\n" ,
current->pid , __FUNCTION__ , ##args); } while(0)
#else
#define DPRINTK(fmt,args...) do {} while(0)
#endif
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ide: ide-generic, add another device exception
On Sat, 9 Jun 2007 00:42:50 +0200 Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > On Friday 08 June 2007, Alan Cox wrote: > > On Fri, 8 Jun 2007 14:18:55 +0200 > > Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > > > > > On Monday 04 June 2007, Jiri Slaby wrote: > > > > ide-generic, add another device exception > > > > > > ide-generic is a generic ISA IDE driver, this one is > > > drivers/ide/pci/generic > > > (a generic IDE PCI driver) - fixed patch description to avoid confusion. > > > > Nope ide-generic is a generic I/O based ST506 interface. It covers a bit > > more than just ISA bus. > > If so then can we finally get rid of hd.c? Ok ST-506 register set. ST-506 MFM command set is a bit different and does need hd.c (SFF only deals with PCI controllers) > > > [ Yes, both drivers need a rename - patches are welcomed. ] > > > > Good way to break everyones module settings > > MODULE_ALIAS() should cover this up nicely. No problem with that. Just need to be sure it gets done. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
On Friday 08 June 2007 22:55, Andrew Morton wrote: > On Fri, 8 Jun 2007 22:43:10 +0200 (CEST) > > Andreas Kleen <[EMAIL PROTECTED]> wrote: > > > That's what kmem_cache_alloc() is for?!?! > > > > Tradtionally that was not allowed in block layer path. Not sure > > it is fully obsolete with the recent dirty tracking work, probably not. > > > > Besides it would need to be GFP_ATOMIC and the default > > atomic pools are not that big. > > That in itself is a problem. What do we have to do to be able > to make these allocations use the *much* stronger GFP_NOIO? That still sleeps. Allow networking and block drivers (and other device drivers) to map SGs without holding spinlocks. Would be major work. I've been asking for it for years because it would also avoid other nasty problem, like the panic-on-overflow issues with swiotlb/AMD GART iommu -- it could just block for free space instead. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-IOMMU 06/10] Intel IOMMU driver
On Thu, 7 Jun 2007, Andrew Morton wrote:
> > +void *iommu_rpool_alloc(unsigned int size, gfp_t flag)
> > +{
> > + if (size == PAGE_SIZE_4K)
> > + return(void *)get_zeroed_page(flag);
> > + else
> > + return kzalloc(size, flag);
> > +}
>
> kmalloc(4k) is pretty efficient and (I think) is guaranteed to return a
> page-aligned address.
Page allocations should be done through the page allocator. 4k
allocations benefit from the per cpu caches of the page allocator which
makes the use of the page allocator fastest and best for 4k allocs.
kmalloc allocations are not guaranteed to be aligned to 4k boundaries.
They usually are but ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Restore shmid as inode# to fix /proc/pid/maps ABI breakage
Andrew, Can you include this in -mm ? Thanks, Badari shmid used to be stored as inode# for shared memory segments. Some of the proc-ps tools use this from /proc/pid/maps. Recent cleanups to newseg() changed it. This patch sets inode number back to shared memory id to fix breakage. Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]> Index: linux-2.6.22-rc4/ipc/shm.c === --- linux-2.6.22-rc4.orig/ipc/shm.c 2007-06-08 15:17:20.0 -0700 +++ linux-2.6.22-rc4/ipc/shm.c 2007-06-08 15:19:38.0 -0700 @@ -397,6 +397,11 @@ static int newseg (struct ipc_namespace shp->shm_nattch = 0; shp->id = shm_buildid(ns, id, shp->shm_perm.seq); shp->shm_file = file; + /* +* shmid gets reported as "inode#" in /proc/pid/maps. +* proc-ps tools use this. Changing this will break them. +*/ + file->f_dentry->d_inode->i_ino = shp->id; ns->shm_tot += numpages; shm_unlock(shp); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] i386: Fix two more NMI watchdog bugs
> None of the patches posted by Björn fix the kernel BUG at > arch/i386/kernel/cpu/perfctr-watchdog.c:126! that occurs when doing > echo 0 > /proc/sys/kernel/nmi_watchdog > > Call Trace: > [] single_msr_unreserve+0xd/0x1a > [] disable_lapic_nmi_watchdog+0x27/0x35 > [] proc_nmi_enabled+0xa0/0xbd > [] proc_sys_write+0x6f/0x8c > [] proc_sys_write+0x0/0x8c > [] vfs_write+0x8a/0x10c > [] sys_write+0x41/0x67 > [] syscall_call+0x7/0xb > > Andi, did you have a patch for that? ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/disable-watchdog -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ide: ide-generic, add another device exception
On Friday 08 June 2007, Alan Cox wrote: > On Fri, 8 Jun 2007 14:18:55 +0200 > Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > > > On Monday 04 June 2007, Jiri Slaby wrote: > > > ide-generic, add another device exception > > > > ide-generic is a generic ISA IDE driver, this one is drivers/ide/pci/generic > > (a generic IDE PCI driver) - fixed patch description to avoid confusion. > > Nope ide-generic is a generic I/O based ST506 interface. It covers a bit > more than just ISA bus. If so then can we finally get rid of hd.c? > > [ Yes, both drivers need a rename - patches are welcomed. ] > > Good way to break everyones module settings MODULE_ALIAS() should cover this up nicely. Thanks, Bart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/3] [CRYPTO] Add optimized SHA-1 implementation for i486+
Add x86-optimized implementation of the SHA-1 hash function, taken from Nettle under the LGPL. This code will be enabled on kernels compiled for 486es or better; kernels which support 386es will use the generic implementation (since we need BSWAP). We disable building lib/sha1.o when an optimized implementation is available, as the library link order for x86 (and x86_64) would otherwise ignore the optimized version. The existing optimized implementation for ARM does not do this; the library link order for that architecture appears to favor the arch/arm/ version automatically. I've left this situation alone since I'm not familiar with the ARM code, but a !ARM condition could be added to CONFIG_SHA1_GENERIC if it makes sense. The code has been tested with tcrypt and the NIST test vectors. Signed-off-by: Benjamin Gilbert <[EMAIL PROTECTED]> --- arch/i386/kernel/i386_ksyms.c |5 + arch/i386/lib/Makefile|1 arch/i386/lib/sha1.S | 299 + include/linux/cryptohash.h|9 + lib/Kconfig | 13 ++ lib/Makefile |3 6 files changed, 328 insertions(+), 2 deletions(-) diff --git a/arch/i386/kernel/i386_ksyms.c b/arch/i386/kernel/i386_ksyms.c index e3d4b73..812bc4e 100644 --- a/arch/i386/kernel/i386_ksyms.c +++ b/arch/i386/kernel/i386_ksyms.c @@ -1,4 +1,5 @@ #include +#include #include #include @@ -28,3 +29,7 @@ EXPORT_SYMBOL(__read_lock_failed); #endif EXPORT_SYMBOL(csum_partial); + +#ifdef CONFIG_SHA1_X86 +EXPORT_SYMBOL(sha_transform); +#endif diff --git a/arch/i386/lib/Makefile b/arch/i386/lib/Makefile index 22d8ac5..69f4845 100644 --- a/arch/i386/lib/Makefile +++ b/arch/i386/lib/Makefile @@ -6,6 +6,7 @@ lib-y = checksum.o delay.o usercopy.o getuser.o putuser.o memcpy.o strstr.o \ bitops.o semaphore.o +lib-$(CONFIG_SHA1_X86) += sha1.o lib-$(CONFIG_X86_USE_3DNOW) += mmx.o obj-$(CONFIG_SMP) += msr-on-cpu.o diff --git a/arch/i386/lib/sha1.S b/arch/i386/lib/sha1.S new file mode 100644 index 000..28aa4b7 --- /dev/null +++ b/arch/i386/lib/sha1.S @@ -0,0 +1,299 @@ +/* + * x86-optimized SHA1 hash algorithm (i486 and above) + * + * Originally from Nettle + * Ported from M4 to cpp by Benjamin Gilbert <[EMAIL PROTECTED]> + * + * Copyright (C) 2004, Niels M�ller + * Copyright (C) 2006-2007 Carnegie Mellon University + * + * This library is free software; you can redistribute it and/or modify it + * under the terms of version 2.1 of the GNU Lesser General Public License as + * published by the Free Software Foundation. A copy of the GNU Lesser General + * Public License should have been distributed along with this library in the + * file LICENSE.LGPL. + * + * This library is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License + * for more details. + */ + +#include +#include + +/* Register usage */ +#define SA %eax +#define SB %ebx +#define SC %ecx +#define SD %edx +#define SE %ebp +#define DATA %esp +#define TMP%edi +#define TMP2 %esi/* Used by SWAP and F3 */ +#define TMP3 64(%esp) + +/* Constants */ +#define K1VALUE$0x5A827999 /* Rounds 0-19 */ +#define K2VALUE$0x6ED9EBA1 /* Rounds 20-39 */ +#define K3VALUE$0x8F1BBCDC /* Rounds 40-59 */ +#define K4VALUE$0xCA62C1D6 /* Rounds 60-79 */ + +/* Convert stack offsets in words to offsets in bytes */ +#define OFFSET(i) 4*(i) + +/* Reads the input via TMP2 into register, byteswaps it, and stores it in + the DATA array. */ +#define SWAP(index, register) \ + movlOFFSET(index)(TMP2), register; \ + bswap register; \ + movlregister, OFFSET(index)(DATA) + +/* Sets the workspace word at the given index to TMP. */ +#define CLEAR(index) \ + movlTMP, OFFSET(index)(DATA) + +/* pushl/popl wrappers that update the DWARF unwind table */ +#define PUSH(regname) \ + pushl %regname; \ + CFI_ADJUST_CFA_OFFSET 4; \ + CFI_REL_OFFSET regname, 0 + +#define POP(regname) \ + popl%regname; \ + CFI_ADJUST_CFA_OFFSET -4; \ + CFI_RESTORE regname + +/* + * expand(i) is the expansion function + * + * W[i] = (W[i - 16] ^ W[i - 14] ^ W[i - 8] ^ W[i - 3]) <<< 1 + * + * where W[i] is stored in DATA[i mod 16]. + * + * Result is stored back in W[i], and also left in TMP, the only + * register that is used. + */ +#define EXPAND(i)
[PATCH 3/3] [CRYPTO] Add optimized SHA-1 implementation for x86_64
Add optimized implementation of the SHA-1 hash function for x86_64, ported from the x86 implementation in Nettle (which is LGPLed). The code has been tested with tcrypt and the NIST test vectors. Signed-off-by: Benjamin Gilbert <[EMAIL PROTECTED]> --- arch/x86_64/kernel/x8664_ksyms.c |3 arch/x86_64/lib/Makefile |2 arch/x86_64/lib/sha1.S | 281 ++ include/linux/cryptohash.h |2 lib/Kconfig |7 + 5 files changed, 293 insertions(+), 2 deletions(-) diff --git a/arch/x86_64/kernel/x8664_ksyms.c b/arch/x86_64/kernel/x8664_ksyms.c index 77c25b3..bc641ab 100644 --- a/arch/x86_64/kernel/x8664_ksyms.c +++ b/arch/x86_64/kernel/x8664_ksyms.c @@ -3,6 +3,7 @@ #include #include +#include #include #include @@ -60,3 +61,5 @@ EXPORT_SYMBOL(init_level4_pgt); EXPORT_SYMBOL(load_gs_index); EXPORT_SYMBOL(_proxy_pda); + +EXPORT_SYMBOL(sha_transform); diff --git a/arch/x86_64/lib/Makefile b/arch/x86_64/lib/Makefile index c943271..6c8110b 100644 --- a/arch/x86_64/lib/Makefile +++ b/arch/x86_64/lib/Makefile @@ -9,5 +9,5 @@ obj-$(CONFIG_SMP) += msr-on-cpu.o lib-y := csum-partial.o csum-copy.o csum-wrappers.o delay.o \ usercopy.o getuser.o putuser.o \ - thunk.o clear_page.o copy_page.o bitstr.o bitops.o + thunk.o clear_page.o copy_page.o bitstr.o bitops.o sha1.o lib-y += memcpy.o memmove.o memset.o copy_user.o rwlock.o copy_user_nocache.o diff --git a/arch/x86_64/lib/sha1.S b/arch/x86_64/lib/sha1.S new file mode 100644 index 000..48f4fde --- /dev/null +++ b/arch/x86_64/lib/sha1.S @@ -0,0 +1,281 @@ +/* + * sha1-x86_64 - x86_64-optimized SHA1 hash algorithm + * + * Originally from Nettle + * Ported from M4 to cpp by Benjamin Gilbert <[EMAIL PROTECTED]> + * Ported from x86 to x86_64 by Benjamin Gilbert + * + * Copyright (C) 2004, Niels M�ller + * Copyright (C) 2006-2007 Carnegie Mellon University + * + * This library is free software; you can redistribute it and/or modify it + * under the terms of version 2.1 of the GNU Lesser General Public License as + * published by the Free Software Foundation. A copy of the GNU Lesser General + * Public License should have been distributed along with this library in the + * file LICENSE.LGPL. + * + * This library is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License + * for more details. + */ + +#include +#include + +/* Register usage. r12-15 must be saved if they will be used. Accessing + r8-r15 takes an extra instruction byte. */ +#define P_STATE%rdi/* Pointer parameter */ +#define P_DATA %rsi/* Pointer parameter */ +#define DATA %rdx/* Pointer parameter */ +#define SA %edi/* Reuses P_STATE */ +#define SB %esi/* Reuses P_DATA */ +#define SC %eax +#define SD %ebx/* Callee-saved */ +#define SE %ebp/* Callee-saved */ +#define TMP%ecx +#define TMP2 %r8d/* Used by F3 */ +#define CONST %r9d +#define STATE %r10 + +/* Constants */ +#define K1VALUE$0x5A827999 /* Rounds 0-19 */ +#define K2VALUE$0x6ED9EBA1 /* Rounds 20-39 */ +#define K3VALUE$0x8F1BBCDC /* Rounds 40-59 */ +#define K4VALUE$0xCA62C1D6 /* Rounds 60-79 */ + +/* Convert stack offsets in 32-bit words to offsets in bytes */ +#define OFFSET(i) 4*(i) + +/* Reads the input via P_DATA into register, byteswaps it, and stores it in + the DATA array. */ +#define SWAP(index, register) \ + movlOFFSET(index)(P_DATA), register;\ + bswap register; \ + movlregister, OFFSET(index)(DATA) + +/* push/pop wrappers that update the DWARF unwind table */ +#define PUSH(regname) \ + push%regname; \ + CFI_ADJUST_CFA_OFFSET 8; \ + CFI_REL_OFFSET regname, 0 + +#define POP(regname) \ + pop %regname; \ + CFI_ADJUST_CFA_OFFSET -8; \ + CFI_RESTORE regname + +/* + * expand(i) is the expansion function + * + * W[i] = (W[i - 16] ^ W[i - 14] ^ W[i - 8] ^ W[i - 3]) <<< 1 + * + * where W[i] is stored in DATA[i mod 16]. + * + * Result is stored back in W[i], and also left in TMP, the only + * register that is used. + */ +#define EXPAND(i) \ + movlOFFSET(i % 16)(DATA), TMP; \ + xorlOFFSET((i + 2) % 16)(DATA
[PATCH 1/7] Add a new debug function to kernel.h
Signed-off-by: Jack Stone <[EMAIL PROTECTED]>
---
Index: linux/include/linux/kernel.h
===
--- linux.orig/include/linux/kernel.h
+++ linux/include/linux/kernel.h
@@ -228,11 +228,18 @@ extern void print_hex_dump(const char *l
/* If you are writing a driver, please use dev_dbg instead */
#define pr_debug(fmt,arg...) \
printk(KERN_DEBUG fmt,##arg)
+#define pr_err(fmt,arg...) \
+ printk(KERN_ERR fmt,##arg)
#else
static inline int __attribute__ ((format (printf, 1, 2)))
pr_debug(const char * fmt, ...)
{
return 0;
}
+
+static inline int __attribute__ ((format (printf, 1, 2))) pr_err(const
char * fmt, ...)
+{
+ return 0;
+}
#endif
#define pr_info(fmt,arg...) \
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] Cleanup code to replace DPRINTK with pr_debug
This patch series replaces DPRINTK with pr_debug in alternative.c, autofs, autofs4 and ncpfs. A new function called pr_err is also added to keep functionality in ncpfs. The last 2 patches add support for pr_debug_pid and apply it to autofs4 to keep the output the same as the current DPRINTK statements. All patches have been compile tested but not boot tested -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Add optimized SHA-1 implementations for x86 and x86_64
The following 3-part series adds assembly implementations of the SHA-1 transform for x86 and x86_64. For x86_64 the optimized code is always selected; on x86 it is selected if the kernel is compiled for i486 or above (since the code needs BSWAP). These changes primarily improve the performance of the CryptoAPI SHA-1 module and of /dev/urandom. I've included some performance data from my test boxes below. This version incorporates feedback from Herbert Xu. Andrew, I'm sending this to you because of the (admittedly tiny) intersection with arm and s390 in part 1. - tcrypt performance tests: === Pentium IV in 32-bit mode, average of 5 trials === Test# Bytes/ Bytes/ Cyc/B Cyc/B Change block update(C) (asm) 0 16 16229114 50% 1 64 16142 76 46% 2 64 64 79 35 56% 3 256 16 59 34 42% 4 256 64 44 24 45% 5 256 256 43 17 60% 61024 16 51 36 29% 71024 256 30 13 57% 810241024 28 12 57% 92048 16 66 30 55% 102048 256 31 12 61% 1120481024 27 13 52% 1220482048 26 13 50% 134096 16 49 30 39% 144096 256 28 12 57% 1540961024 28 11 61% 1640964096 26 13 50% 178192 16 49 29 41% 188192 256 27 11 59% 1981921024 26 11 58% 2081924096 25 10 60% 2181928192 25 10 60% === Intel Core 2 in 64-bit mode, average of 5 trials === Test# Bytes/ Bytes/ Cyc/B Cyc/B Change block update(C) (asm) 0 16 16112 81 28% 1 64 16 55 39 29% 2 64 64 42 27 36% 3 256 16 35 25 29% 4 256 64 24 14 42% 5 256 256 22 12 45% 61024 16 31 22 29% 71024 256 17 9 47% 810241024 16 9 44% 92048 16 30 22 27% 102048 256 16 8 50% 1120481024 16 8 50% 1220482048 16 8 50% 134096 16 29 21 28% 144096 256 16 8 50% 1540961024 15 8 47% 1640964096 15 7 53% 178192 16 29 22 24% 188192 256 16 8 50% 1981921024 15 7 53% 2081924096 15 7 53% 2181928192 15 7 53% I've also done informal tests on other boxes, and the performance improvement has been in the same ballpark. On the aforementioned Pentium IV, /dev/urandom throughput goes from 3.7 MB/s to 5.6 MB/s with the patches; on the Core 2, it increases from 5.5 MB/s to 8.1 MB/s. Signed-off-by: Benjamin Gilbert <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] Replace DPRINTK with pr_debug_pid in autofs4
Signed-off-by: Jack Stone <[EMAIL PROTECTED]>
---
-/* #define DEBUG */
-
-#ifdef DEBUG
-#define DPRINTK(fmt,args...) do { pr_debug("pid %d: %s: " fmt "\n" ,
current->pid , __FUNCTION__ , ##args); } while(0)
-#else
-#define DPRINTK(fmt,args...) do {} while(0)
-#endif
-
/* Unified info structure. This is pointed to by both the dentry and
inode structures. Each file in the filesystem has an instance of this
structure. It holds a reference to the dentry, so dentries are never
Index: linux/fs/autofs4/expire.c
===
--- linux.orig/fs/autofs4/expire.c
+++ linux/fs/autofs4/expire.c
@@ -50,7 +50,7 @@ static int autofs4_mount_busy(struct vfs
struct dentry *top = dentry;
int status = 1;
- DPRINTK("dentry %p %.*s",
+ pr_debug_pid("dentry %p %.*s",
dentry, (int)dentry->d_name.len, dentry->d_name.name);
mntget(mnt);
@@ -72,7 +72,7 @@ static int autofs4_mount_busy(struct vfs
status = 0;
done:
- DPRINTK("returning = %d", status);
+ pr_debug_pid("returning = %d", status);
mntput(mnt);
dput(dentry);
return status;
@@ -110,7 +110,7 @@ static int autofs4_direct_busy(struct vf
unsigned long timeout,
int do_now)
{
- DPRINTK("top %p %.*s",
+ pr_debug_pid("top %p %.*s",
top, (int) top->d_name.len, top->d_name.name);
/* If it's busy update the expiry counters */
@@ -139,7 +139,7 @@ static int autofs4_tree_busy(struct vfsm
struct autofs_info *top_ino = autofs4_dentry_ino(top);
struct dentry *p;
- DPRINTK("top %p %.*s",
+ pr_debug_pid("top %p %.*s",
top, (int)top->d_name.len, top->d_name.name);
/* Negative dentry - give up */
@@ -152,7 +152,7 @@ static int autofs4_tree_busy(struct vfsm
if (!simple_positive(p))
continue;
- DPRINTK("dentry %p %.*s",
+ pr_debug_pid("dentry %p %.*s",
p, (int) p->d_name.len, p->d_name.name);
p = dget(p);
@@ -211,7 +211,7 @@ static struct dentry *autofs4_check_leav
{
struct dentry *p;
- DPRINTK("parent %p %.*s",
+ pr_debug_pid("parent %p %.*s",
parent, (int)parent->d_name.len, parent->d_name.name);
spin_lock(&dcache_lock);
@@ -220,7 +220,7 @@ static struct dentry *autofs4_check_leav
if (!simple_positive(p))
continue;
- DPRINTK("dentry %p %.*s",
+ pr_debug_pid("dentry %p %.*s",
p, (int) p->d_name.len, p->d_name.name);
p = dget(p);
@@ -323,7 +323,7 @@ static struct dentry *autofs4_expire_ind
* offset (autofs-5.0+).
*/
if (d_mountpoint(dentry)) {
- DPRINTK("checking mountpoint %p %.*s",
+ pr_debug_pid("checking mountpoint %p %.*s",
dentry, (int)dentry->d_name.len,
dentry->d_name.name);
/* Can we umount this guy */
@@ -373,7 +373,7 @@ next:
}
if (expired) {
- DPRINTK("returning %p %.*s",
+ pr_debug_pid("returning %p %.*s",
expired, (int)expired->d_name.len,
expired->d_name.name);
spin_lock(&dcache_lock);
list_move(&expired->d_parent->d_subdirs, &expired->d_u.d_child);
Index: linux/fs/autofs4/inode.c
===
--- linux.orig/fs/autofs4/inode.c
+++ linux/fs/autofs4/inode.c
@@ -124,7 +124,7 @@ resume:
next = next->next;
spin_unlock(&dcache_lock);
- DPRINTK("dentry %p %.*s",
+ pr_debug_pid("dentry %p %.*s",
dentry, (int)dentry->d_name.len, dentry->d_name.name);
dput(dentry);
@@ -137,7 +137,7 @@ resume:
next = this_parent->d_u.d_child.next;
this_parent = this_parent->d_parent;
spin_unlock(&dcache_lock);
- DPRINTK("parent dentry %p %.*s",
+ pr_debug_pid("parent dentry %p %.*s",
dentry, (int)dentry->d_name.len, dentry->d_name.name);
dput(dentry);
spin_lock(&dcache_lock);
@@ -169,7 +169,7 @@ void autofs4_kill_sb(struct super_block
kfree(sbi);
out_kill_sb:
- DPRINTK("shutting down");
+ pr_debug_pid("shutting down");
kill_anon_super(sb);
}
@@ -315,7 +315,7 @@ int autofs4_fill_super(struct super_bloc
sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
if (!sbi)
goto fail_unlock;
- DPRINTK("starting up, sbi = %p",sbi);
+ pr_debug_pid("starting up, sbi = %p",sbi);
memset(sbi, 0, sizeof(*sbi));
@@ -391,7 +391,7 @@ int au
[PATCH 6/7] Add pr_debug_pid to kernel.h
Signed-off-by: Jack Stone <[EMAIL PROTECTED]>
---
+static inline int __attribute__ ((format (printf, 1, 2)))
pr_debug_pid(const char * fmt, ...)
+{
+ return 0;
+}
+
static inline int __attribute__ ((format (printf, 1, 2))) pr_err(const
char * fmt, ...)
{
return 0;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] Replace DPRINTK with pr_debug in ncpfs
Signed-off-by: Jack Stone <[EMAIL PROTECTED]>
---
- DDPRINTK("ncp_lookup_validate: %s/%s not valid, age=%ld, server
lookup\n",
+ pr_debug("ncp_lookup_validate: %s/%s not valid, age=%ld, server
lookup\n",
dentry->d_parent->d_name.name, dentry->d_name.name,
NCP_GET_AGE(dentry));
@@ -313,7 +313,7 @@ __ncp_lookup_validate(struct dentry * de
res = ncp_obtain_info(server, dir, __name, &(finfo.i));
}
finfo.volume = finfo.i.volNumber;
- DDPRINTK("ncp_lookup_validate: looked for %s/%s, res=%d\n",
+ pr_debug("ncp_lookup_validate: looked for %s/%s, res=%d\n",
dentry->d_parent->d_name.name, __name, res);
/*
* If we didn't find it, or if it has a different dirEntNum to
@@ -324,13 +324,13 @@ __ncp_lookup_validate(struct dentry * de
ncp_new_dentry(dentry);
val=1;
} else
- DDPRINTK("ncp_lookup_validate: found, but dirEntNum
changed\n");
+ pr_debug("ncp_lookup_validate: found, but dirEntNum
changed\n");
ncp_update_inode2(dentry->d_inode, &finfo);
}
finished:
- DDPRINTK("ncp_lookup_validate: result=%d\n", val);
+ pr_debug("ncp_lookup_validate: result=%d\n", val);
dput(parent);
return val;
}
@@ -416,7 +416,7 @@ static int ncp_readdir(struct file *filp
ctl.page = NULL;
ctl.cache = NULL;
- DDPRINTK("ncp_readdir: reading %s/%s, pos=%d\n",
+ pr_debug("ncp_readdir: reading %s/%s, pos=%d\n",
dentry->d_parent->d_name.name, dentry->d_name.name,
(int) filp->f_pos);
@@ -656,7 +656,7 @@ ncp_read_volume_list(struct file *filp,
struct ncp_entry_info entry;
int i;
- DPRINTK("ncp_read_volume_list: pos=%ld\n",
+ pr_debug("ncp_read_volume_list: pos=%ld\n",
(unsigned long) filp->f_pos);
for (i = 0; i < NCP_NUMBER_OF_VOLUMES; i++) {
@@ -666,12 +666,12 @@ ncp_read_volume_list(struct file *filp,
if (!strlen(info.volume_name))
continue;
- DPRINTK("ncp_read_volume_list: found vol: %s\n",
+ pr_debug("ncp_read_volume_list: found vol: %s\n",
info.volume_name);
if (ncp_lookup_volume(server, info.volume_name,
&entry.i)) {
- DPRINTK("ncpfs: could not lookup vol %s\n",
+ pr_debug("ncpfs: could not lookup vol %s\n",
info.volume_name);
continue;
}
@@ -695,7 +695,7 @@ ncp_do_readdir(struct file *filp, void *
int more;
size_t bufsize;
- DPRINTK("ncp_do_readdir: %s/%s, fpos=%ld\n",
+ pr_debug("ncp_do_readdir: %s/%s, fpos=%ld\n",
dentry->d_parent->d_name.name, dentry->d_name.name,
(unsigned long) filp->f_pos);
PPRINTK("ncp_do_readdir: init %s, volnum=%d, dirent=%u\n",
@@ -704,7 +704,7 @@ ncp_do_readdir(struct file *filp, void *
err = ncp_initialize_search(server, dir, &seq);
if (err) {
- DPRINTK("ncp_do_readdir: init failed, err=%d\n", err);
+ pr_debug("ncp_do_readdir: init failed, err=%d\n", err);
return;
}
/* We MUST NOT use server->buffer_size handshaked with server if we are
@@ -779,10 +779,10 @@ int ncp_conn_logged_in(struct super_bloc
NCP_FINFO(ino)->dirEntNum = dirEntNum;
NCP_FINFO(ino)->DosDirNum = DosDirNum;
} else {
- DPRINTK("ncpfs: sb->s_root->d_inode ==
NULL!\n");
+ pr_debug("ncpfs: sb->s_root->d_inode ==
NULL!\n");
}
} else {
- DPRINTK("ncpfs: sb->s_root == NULL!\n");
+ pr_debug("ncpfs: sb->s_root == NULL!\n");
}
}
result = 0;
@@ -917,7 +917,7 @@ int ncp_create_new(struct inode *dir, st
if (result) {
if (result == 0x87)
error = -ENAMETOOLONG;
- DPRINTK("ncp_create: %s/%s failed\n",
+ pr_debug("ncp_create: %s/%s failed\n",
dentry->d_parent->d_name.name,
dentry->d_name.name);
goto out;
}
@@ -952,7 +952,7 @@ static int ncp_mkdir(struct inode *dir,
int error, len;
__u8 __name[NCP_MAXPATHLEN + 1];
- DPRINTK("ncp_mkdir: making %s/%s\n",
+ pr_debug("ncp_mkdir: making %s/%s\n",
dentry->d_parent->d_name.name, dentry->d_name.name);
error = -EIO;
@@ -995,7 +995,7 @@ static int ncp_rmdir(struct inode *dir,
int error, result, len;
Re: [patch 7/8] fdmap v2 - implement sys_socket2
> > Unproven and dubious at best as a claim. > > I really don't mean to be rude and pointing you to read the archives, but > the proof and the reason why claims are valid is inside there. I've read the archive. I'm totally unconvinced by any of the fd allocation policy stuff. There are some good arguments about O_CLOEXEC and threading but not about fd allocation. > > > It does not work. What if the main application, library A and library B > > > wants to implement their own allocation strategy? > > > > Its called "discipline". I would suggest that libc contains a default > > allocator. You might also want to assign library and application ranges > > for clarity. > > That is really nice solution. Each library has to have each own allocator. Are you being deliberately stupid ? I suggested *libc* contains a default allocator > Then we'll have what, a committee that assigns fd ranges? Currently the fd ranges are assigned by a committee called POSIX based on Unix practice. > replicated all around the code that access directly the fdtables. I did > the fdmap consolidation patch, and I can tell you there are quite a few > places that access fdtables directly. This is true, but if you are worried about complexity we get back to the original posix allocator which packs them in tight and produces a most excellent spread in the general case (whacko apps like bash aside) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
On Fri, Jun 08, 2007 at 02:42:07PM -0700, Andrew Morton wrote: > I'd say just remove the whole thing and use kmem_cache_alloc(). We will try that. > Put much effort into removing the GFP_ATOMIC and using GFP_NOIO instead: > there's your problem right there. As these are called from interrupt handlers, we can't use GFP_NOIO. > If for some reason you really can't do that (and a requirement for > allocation-in-interrupt is the only valid reason, really) and if you indeed > can demonstrate memory allocation failures with certain workloads then > let's take a look at that. As I said, attaching a reserve pool to your > slab cache might be a suitable approach. But none of these things are I agree. We are better off with enhancing slab infrastructure for this, if needed. > magic: if memory allcoation failures or deadlocks or livelocks are > demonstrable with the reserves absent, then they'll also be possible with > the reserves present. > > Unless you use mempools, and can sleep. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-usb-devel] ThinkPad T41 - Strange USB 2.0 behaviour
Alan Stern wrote: Robert, it would help somewhat if you could build a kernel with CONFIG_USB_DEBUG turned on and post the dmesg log showing what happens when you plug in one of those non-working devices. Sorry, yes I should have done that before... Yes, in principle Linux can be made to switch over to full speed when high speed fails. But there are limitations: The switchover would work only for devices plugged directly into the computer, not for devices plugged into a high-speed hub. And some Linux systems (not regular PCs) have EHCI implementations that don't allow such a switch -- or if they do, I'm not aware of how to accomplish it. Interesting, I have a USB 2.0 hub, but have not tried it, mainly because I need to find a power supply for it first. But regardless if the hub works as USB 2.0 or 1.1, it could be that another hub behaves differently, just like I have one USB 2.0 memory key that still works as such. BTW, depending on the kind of failure the system does not keep retrying indefinitely. It gives up after four attempts. Alan Stern ***USB related boot messages with CONFIG_USB_DEBUG enabled Jun 8 23:33:30 localhost kernel: USB Universal Host Controller Interface driver v3.0 Jun 8 23:33:30 localhost kernel: ACPI: PCI Interrupt :00:1d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 Jun 8 23:33:30 localhost kernel: uhci_hcd :00:1d.0: UHCI Host Controller Jun 8 23:33:30 localhost kernel: uhci_hcd :00:1d.0: new USB bus registered, assigned bus number 1 Jun 8 23:33:30 localhost kernel: uhci_hcd :00:1d.0: detected 2 ports Jun 8 23:33:30 localhost kernel: uhci_hcd :00:1d.0: irq 11, io base 0x1800 Jun 8 23:33:30 localhost kernel: usb usb1: Product: UHCI Host Controller Jun 8 23:33:30 localhost kernel: usb usb1: Manufacturer: Linux 2.6.22-rc4 uhci_hcd Jun 8 23:33:30 localhost kernel: usb usb1: SerialNumber: :00:1d.0 Jun 8 23:33:30 localhost kernel: usb usb1: configuration #1 chosen from 1 choice Jun 8 23:33:30 localhost kernel: hub 1-0:1.0: USB hub found Jun 8 23:33:30 localhost kernel: hub 1-0:1.0: 2 ports detected Jun 8 23:33:30 localhost kernel: ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 Jun 8 23:33:30 localhost kernel: ACPI: PCI Interrupt :00:1d.1[B] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 Jun 8 23:33:30 localhost kernel: uhci_hcd :00:1d.1: UHCI Host Controller Jun 8 23:33:30 localhost kernel: uhci_hcd :00:1d.1: new USB bus registered, assigned bus number 2 Jun 8 23:33:30 localhost kernel: uhci_hcd :00:1d.1: detected 2 ports Jun 8 23:33:30 localhost kernel: uhci_hcd :00:1d.1: irq 11, io base 0x1820 Jun 8 23:33:30 localhost kernel: usb usb2: Product: UHCI Host Controller Jun 8 23:33:30 localhost kernel: usb usb2: Manufacturer: Linux 2.6.22-rc4 uhci_hcd Jun 8 23:33:30 localhost kernel: usb usb2: SerialNumber: :00:1d.1 Jun 8 23:33:31 localhost kernel: usb usb2: configuration #1 chosen from 1 choice Jun 8 23:33:31 localhost rpcbind: cannot create socket for udp6 Jun 8 23:33:31 localhost kernel: hub 2-0:1.0: USB hub found Jun 8 23:33:31 localhost kernel: hub 2-0:1.0: 2 ports detected Jun 8 23:33:31 localhost rpcbind: cannot create socket for tcp6 Jun 8 23:33:31 localhost kernel: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 Jun 8 23:33:31 localhost kernel: ACPI: PCI Interrupt :00:1d.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 Jun 8 23:33:31 localhost kernel: uhci_hcd :00:1d.2: UHCI Host Controller Jun 8 23:33:31 localhost kernel: uhci_hcd :00:1d.2: new USB bus registered, assigned bus number 3 Jun 8 23:33:31 localhost kernel: uhci_hcd :00:1d.2: detected 2 ports Jun 8 23:33:31 localhost kernel: uhci_hcd :00:1d.2: irq 11, io base 0x1840 Jun 8 23:33:31 localhost kernel: usb usb3: Product: UHCI Host Controller Jun 8 23:33:31 localhost kernel: usb usb3: Manufacturer: Linux 2.6.22-rc4 uhci_hcd Jun 8 23:33:31 localhost kernel: usb usb3: SerialNumber: :00:1d.2 Jun 8 23:33:31 localhost kernel: usb usb3: configuration #1 chosen from 1 choice Jun 8 23:33:31 localhost kernel: hub 3-0:1.0: USB hub found Jun 8 23:33:31 localhost kernel: hub 3-0:1.0: 2 ports detected Jun 8 23:33:31 localhost kernel: ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11 Jun 8 23:33:31 localhost kernel: ACPI: PCI Interrupt :00:1d.7[D] -> Link [LNKH] -> GSI 11 (level, low) -> IRQ 11 Jun 8 23:33:31 localhost kernel: ehci_hcd :00:1d.7: EHCI Host Controller Jun 8 23:33:31 localhost kernel: ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 4 Jun 8 23:33:31 localhost kernel: ehci_hcd :00:1d.7: debug port 1 Jun 8 23:33:31 localhost kernel: ehci_hcd :00:1d.7: irq 11, io mem 0xc000 Jun 8 23:33:31 localhost kernel: ehci_hcd :00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 Jun 8 23:33:31 localhost kernel: usb usb4: Product: EHCI Host Controller Jun 8 23:33:31 localhost kernel: usb
Re: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling
Andrew Morton wrote: Put much effort into removing the GFP_ATOMIC and using GFP_NOIO instead: there's your problem right there. If for some reason you really can't do that (and a requirement for allocation-in-interrupt is the only valid reason, really) and that's the case here; IO gets submitted from IRQ handlers (both network and block)... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
-ck patch | Feedback
Hello, I'm using -ck since... along time ago (I start using it with the kernel 2.6.16) . I started using it with Ubuntu and the response of the system was better. Since that I always compile my kernels with -ck. Actually I use 2.6.20-ck1 and I have no problems, even with things that needs kernel-sources like gspca for my webcam. Thanks a lot for the patches. PS: when will this go into the official kernel? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: libata and legacy ide pcmcia failure
Robert de Rooy wrote: Mark Lord wrote: I still don't see much evidence that interrupts are actually functioning here. It would be good to see /proc/interrupts before/after libata tries to talk to it. Let's assume for the moment that interrupts are b0rken. The legacy IDE driver can talk to such devices completely without interrupts, if the IDE polling patch (below) is applied. So, Robert: could you try again with the old IDE driver, except apply this patch to it first? This will give valuable info. I tried the patch, but a get a kernel panic on boot with it. I can try to get a screenshot of it tomorrow. Oh crap. I did test it a couple of months ago, but my boot/root drive is libata not IDE -- so no panic on boot with it. After booting, it worked just fine talking to PC-CARD CF devices using the polling. =ml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] [CRYPTO] Move sha_init() into cryptohash.h
Make sha_init() a static inline in cryptohash.h rather than an (unexported)
function in lib/sha1.c, in preparation for making sha1.c optional. This
also allows some cleanups:
- Modular code can now use sha_init() rather than reimplementing it
- The optimized implementation of SHA-1 for ARM no longer needs to
reimplement sha_init() in assembly
Signed-off-by: Benjamin Gilbert <[EMAIL PROTECTED]>
---
arch/arm/lib/sha1.S | 16
arch/s390/crypto/sha1_s390.c |6 +-
drivers/crypto/padlock-sha.c |8 ++--
include/linux/cryptohash.h | 14 +-
lib/sha1.c | 14 --
5 files changed, 16 insertions(+), 42 deletions(-)
diff --git a/arch/arm/lib/sha1.S b/arch/arm/lib/sha1.S
index ff6ece4..5be800c 100644
--- a/arch/arm/lib/sha1.S
+++ b/arch/arm/lib/sha1.S
@@ -188,19 +188,3 @@ ENTRY(sha_transform)
.L_sha_K:
.word 0x5a827999, 0x6ed9eba1, 0x8f1bbcdc, 0xca62c1d6
-
-/*
- * void sha_init(__u32 *buf)
- */
-
-.L_sha_initial_digest:
- .word 0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476, 0xc3d2e1f0
-
-ENTRY(sha_init)
-
- str lr, [sp, #-4]!
- adr r1, .L_sha_initial_digest
- ldmia r1, {r1, r2, r3, ip, lr}
- stmia r0, {r1, r2, r3, ip, lr}
- ldr pc, [sp], #4
-
diff --git a/arch/s390/crypto/sha1_s390.c b/arch/s390/crypto/sha1_s390.c
index af4460e..fed9a2e 100644
--- a/arch/s390/crypto/sha1_s390.c
+++ b/arch/s390/crypto/sha1_s390.c
@@ -42,11 +42,7 @@ static void sha1_init(struct crypto_tfm *tfm)
{
struct s390_sha1_ctx *sctx = crypto_tfm_ctx(tfm);
- sctx->state[0] = 0x67452301;
- sctx->state[1] = 0xEFCDAB89;
- sctx->state[2] = 0x98BADCFE;
- sctx->state[3] = 0x10325476;
- sctx->state[4] = 0xC3D2E1F0;
+ sha_init(sctx->state);
sctx->count = 0;
}
diff --git a/drivers/crypto/padlock-sha.c b/drivers/crypto/padlock-sha.c
index a781fd2..b47d708 100644
--- a/drivers/crypto/padlock-sha.c
+++ b/drivers/crypto/padlock-sha.c
@@ -107,12 +107,8 @@ static void padlock_do_sha1(const char *in, char *out, int
count)
char buf[128+16];
char *result = NEAREST_ALIGNED(buf);
- ((uint32_t *)result)[0] = 0x67452301;
- ((uint32_t *)result)[1] = 0xEFCDAB89;
- ((uint32_t *)result)[2] = 0x98BADCFE;
- ((uint32_t *)result)[3] = 0x10325476;
- ((uint32_t *)result)[4] = 0xC3D2E1F0;
-
+ sha_init((uint32_t *)result);
+
asm volatile (".byte 0xf3,0x0f,0xa6,0xc8" /* rep xsha1 */
: "+S"(in), "+D"(result)
: "c"(count), "a"(0));
diff --git a/include/linux/cryptohash.h b/include/linux/cryptohash.h
index c118b2a..a172401 100644
--- a/include/linux/cryptohash.h
+++ b/include/linux/cryptohash.h
@@ -4,7 +4,19 @@
#define SHA_DIGEST_WORDS 5
#define SHA_WORKSPACE_WORDS 80
-void sha_init(__u32 *buf);
+/**
+ * sha_init - initialize the vectors for a SHA1 digest
+ * @buf: vector to initialize
+ */
+static inline void sha_init(__u32 *buf)
+{
+ buf[0] = 0x67452301;
+ buf[1] = 0xefcdab89;
+ buf[2] = 0x98badcfe;
+ buf[3] = 0x10325476;
+ buf[4] = 0xc3d2e1f0;
+}
+
void sha_transform(__u32 *digest, const char *data, __u32 *W);
__u32 half_md4_transform(__u32 buf[4], __u32 const in[8]);
diff --git a/lib/sha1.c b/lib/sha1.c
index 4c45fd5..815816f 100644
--- a/lib/sha1.c
+++ b/lib/sha1.c
@@ -79,17 +79,3 @@ void sha_transform(__u32 *digest, const char *in, __u32 *W)
digest[4] += e;
}
EXPORT_SYMBOL(sha_transform);
-
-/**
- * sha_init - initialize the vectors for a SHA1 digest
- * @buf: vector to initialize
- */
-void sha_init(__u32 *buf)
-{
- buf[0] = 0x67452301;
- buf[1] = 0xefcdab89;
- buf[2] = 0x98badcfe;
- buf[3] = 0x10325476;
- buf[4] = 0xc3d2e1f0;
-}
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: RE : Building kernel 2.6.21.3 for arm on cygwin
Hi Matthieu. Can you please try to tell what your patch actually does. As for the part added in the MAkefile you pass -lintl for Cygwin - but I fail to see _why_ -lintl is needed. The patch to check-lxdialog.sh is outdated. Could I ask you to redo it againt latest version and again explains the _why_ part. The how part is obvious from the diff... Do not get me worg. I would love to have Cygwin supported but I want it in the cleanest possible way. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata and legacy ide pcmcia failure
Mark Lord wrote: I still don't see much evidence that interrupts are actually functioning here. It would be good to see /proc/interrupts before/after libata tries to talk to it. Let's assume for the moment that interrupts are b0rken. The legacy IDE driver can talk to such devices completely without interrupts, if the IDE polling patch (below) is applied. So, Robert: could you try again with the old IDE driver, except apply this patch to it first? This will give valuable info. I tried the patch, but a get a kernel panic on boot with it. I can try to get a screenshot of it tomorrow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
