[patch 2.6.20-1] radeonfb: Add support for Radeon xpress 200m
Added support for radeon xpress 200m(rs480).
Note that the card doesn't like dynclk turned on.
Please CC replies to [EMAIL PROTECTED]
Signed-off-by: Johan Henriksson <[EMAIL PROTECTED]>
---
diff -upr linux-2.6.20.1-vanilla/drivers/video/aty/ati_ids.h
linux-2.6.20.1/drivers/video/aty/ati_ids.h
--- linux-2.6.20.1-vanilla/drivers/video/aty/ati_ids.h Tue Feb 20 07:34:32 2007
+++ linux-2.6.20.1/drivers/video/aty/ati_ids.h Thu Mar 8 19:13:04 2007
@@ -209,4 +209,4 @@
#define PCI_CHIP_R423_5D57 0x5D57
#define PCI_CHIP_RS350_7834 0x7834
#define PCI_CHIP_RS350_7835 0x7835
-
+#define PCI_CHIP_RS480_5955 0x5955
diff -upr linux-2.6.20.1-vanilla/drivers/video/aty/radeon_base.c
linux-2.6.20.1/drivers/video/aty/radeon_base.c
--- linux-2.6.20.1-vanilla/drivers/video/aty/radeon_base.c Tue Feb 20
07:34:32 2007
+++ linux-2.6.20.1/drivers/video/aty/radeon_base.c Thu Mar 8 19:13:04 2007
@@ -100,6 +100,8 @@
{ PCI_VENDOR_ID_ATI, id, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (flags) |
(CHIP_FAMILY_##family) }
static struct pci_device_id radeonfb_pci_table[] = {
+/* Radeon Xpress 200m */
+ CHIP_DEF(PCI_CHIP_RS480_5955, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
/* Mobility M6 */
CHIP_DEF(PCI_CHIP_RADEON_LY,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RADEON_LZ,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
@@ -1990,7 +1992,8 @@ static void radeon_identify_vram(struct
/* framebuffer size */
if ((rinfo->family == CHIP_FAMILY_RS100) ||
(rinfo->family == CHIP_FAMILY_RS200) ||
-(rinfo->family == CHIP_FAMILY_RS300)) {
+(rinfo->family == CHIP_FAMILY_RS300) ||
+ (rinfo->family == CHIP_FAMILY_RS480) ) {
u32 tom = INREG(NB_TOM);
tmp = tom >> 16) - (tom & 0x) + 1) << 6) * 1024);
@@ -2329,7 +2332,7 @@ static int __devinit radeonfb_pci_regist
/* -2 is special: means ON on mobility chips and do not
* change on others
*/
- radeonfb_pm_init(rinfo, rinfo->is_mobility ? 1 : -1,
ignore_devlist, force_sleep);
+ radeonfb_pm_init(rinfo, rinfo->is_mobility && rinfo->family !=
CHIP_FAMILY_RS480 ? 1 : -1, ignore_devlist, force_sleep);
} else
radeonfb_pm_init(rinfo, default_dynclk, ignore_devlist,
force_sleep);
diff -upr linux-2.6.20.1-vanilla/drivers/video/aty/radeonfb.h
linux-2.6.20.1/drivers/video/aty/radeonfb.h
--- linux-2.6.20.1-vanilla/drivers/video/aty/radeonfb.h Tue Feb 20 07:34:32 2007
+++ linux-2.6.20.1/drivers/video/aty/radeonfb.h Thu Mar 8 19:13:04 2007
@@ -48,6 +48,7 @@ enum radeon_family {
CHIP_FAMILY_RV350,
CHIP_FAMILY_RV380,/* RV370/RV380/M22/M24 */
CHIP_FAMILY_R420, /* R420/R423/M18 */
+ CHIP_FAMILY_RS480,
CHIP_FAMILY_LAST,
};
@@ -64,7 +65,8 @@ enum radeon_family {
((rinfo)->family == CHIP_FAMILY_RV350) || \
((rinfo)->family == CHIP_FAMILY_R350) || \
((rinfo)->family == CHIP_FAMILY_RV380) || \
- ((rinfo)->family == CHIP_FAMILY_R420))
+ ((rinfo)->family == CHIP_FAMILY_R420) || \
+ ((rinfo)->family == CHIP_FAMILY_RS480) )
/*
* Chip flags
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
kbuild fixes for section mismatch warnings
The following series of patches gets rid of some false positives
for the section mismatch warnings.
It also enables proper check of section mismatch warnings
when a module is built-in.
So expect a few new warnings to pop up..
The most controversial ones are the patch that ignores
the warning when a function marked __init is exported. Greg KH
says it is OK. And the one allowing the logo references.
Comments are welcome!
kbuild: silence section mismatch warnings for exported functions
kbuild: whitelist logo references from .text to .init.data
kbuild: fix segmentation fault in modpost
kbuild: fix warnings from .pci_fixup section
kbuild: whitelist section mismatch in init/main.c
kbuild: fix section mismatch check for vmlinux
During the last release a great number of section mismatch fixes
has been included and the plan is to make a section mismatch
an error on line with any normal linking errors when all the
non-drivers warnings are fixed.
The diffstat:
b/Makefile |1
b/init/main.c |6 +-
b/scripts/Makefile.modpost |8 +--
b/scripts/mod/modpost.c| 34 +--
scripts/mod/modpost.c | 98 -
5 files changed, 100 insertions(+), 47 deletions(-)
The changes to init/main.c is a simple function rename.
The full list of changes are included below.
The changes are present in kbuild.git at:
git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild.git
I do not plan to push these until next merge window since this
is not critical changes.
PS. I have a backlog of three months of kbuild mails that I
need to walk through. Andrew have applied quite a lot in main
absence period but I have a few remaining patches.
They will be pushed when I get to them.
Sam
>From 5a1ed6a563f5a198d3d7164abf7a5708af20e7ce Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <[EMAIL PROTECTED]>
Date: Mon, 26 Feb 2007 15:33:52 +0100
Subject: kbuild: fix section mismatch check for vmlinux
vmlinux does not contain relocation entries which is
used by the section mismatch checks.
Reported by: Atsushi Nemoto <[EMAIL PROTECTED]>
Use the individual objects as inputs to overcome
this limitation.
In modpost check the .o files and skip non-ELF files.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
Makefile |1 +
scripts/Makefile.modpost |8
scripts/mod/modpost.c| 33 +
3 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/Makefile b/Makefile
index 30b66e2..fa32fde 100644
--- a/Makefile
+++ b/Makefile
@@ -603,6 +603,7 @@ vmlinux-init := $(head-y) $(init-y)
vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
vmlinux-all := $(vmlinux-init) $(vmlinux-main)
vmlinux-lds := arch/$(ARCH)/kernel/vmlinux.lds
+export KBUILD_VMLINUX_OBJS := $(vmlinux-all)
# Rule to link vmlinux - also used during CONFIG_KALLSYMS
# May be overridden by arch/$(ARCH)/Makefile
diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index 65e0a79..d5bbbcc 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -63,16 +63,16 @@ quiet_cmd_modpost = MODPOST $(words $(filter-out vmlinux
FORCE, $^)) modules
$(if $(KBUILD_EXTMOD),-i,-o) $(kernelsymfile) \
$(if $(KBUILD_EXTMOD),-I $(modulesymfile)) \
$(if $(KBUILD_EXTMOD),-o $(modulesymfile)) \
- $(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w) \
- $(wildcard vmlinux) $(filter-out FORCE,$^)
+ $(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w)
PHONY += __modpost
__modpost: $(modules:.ko=.o) FORCE
- $(call cmd,modpost)
+ $(call cmd,modpost) $(wildcard vmlinux) $(filter-out FORCE,$^)
quiet_cmd_kernel-mod = MODPOST $@
- cmd_kernel-mod = $(cmd_modpost)
+ cmd_kernel-mod = $(cmd_modpost) $(KBUILD_VMLINUX_OBJS)
+PHONY += vmlinux
vmlinux: FORCE
$(call cmd,kernel-mod)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index c4b5398..ecf5dff 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -333,10 +333,10 @@ void release_file(void *file, unsigned long size)
munmap(file, size);
}
-static void parse_elf(struct elf_info *info, const char *filename)
+static int parse_elf(struct elf_info *info, const char *filename)
{
unsigned int i;
- Elf_Ehdr *hdr = info->hdr;
+ Elf_Ehdr *hdr;
Elf_Shdr *sechdrs;
Elf_Sym *sym;
@@ -346,9 +346,18 @@ static void parse_elf(struct elf_info *info, const char
*filename)
exit(1);
}
info->hdr = hdr;
- if (info->size < sizeof(*hdr))
- goto truncated;
-
+ if (info->size < sizeof(*hdr)) {
+ /* file too small, assume this is an empty .o file */
+ return 0;
+ }
+ /* Is this a valid ELF file? */
+ if ((hdr->e_ident[EI_MAG0] != ELFMAG0) ||
+ (hdr->e_ident[EI_MAG1] != ELFMAG1) ||
+ (hdr->e_ident[EI_MAG2] != ELFMAG2) ||
+
Re: [patch 2/5] signalfd v2 - signalfd core ...
On Thu, 8 Mar 2007, Linus Torvalds wrote: > > > On Thu, 8 Mar 2007, Davide Libenzi wrote: > > > > The reason for the special function, was not to provide a non-blocking > > behaviour with zero timeout (that just a side effect), but to read the > > siginfo. I was all about using read(2) (and v1 used it), but when you have > > to transfer complex structures over it, it becomes hell. How do you > > cleanly compat over a f_op->read callback for example? > > I agree that it gets a bit "interesting", and one option might be that the > "read()" interface just gets the signal number and the minimal siginfo > information, which is, after all, what 99% of all apps actually care > about. > > But "siginfo_t" is really a *horrible* structure. Nobody sane should ever > use siginfo_t, and the designer of that thing was so high on LSD that it's > not even funny. Re-using fields in a union? Values that depend on other > bits in the thing in random manners? > > In other words, I bet that we could just make it a *lot* better by making > the read structure be: > > - 16 4-byte fields (fixed 64-byte packet), where each field is an >uint32_t (we could even do it in network byte order if we care and if >you want to just pipe the information from one machine to another, but >that sounds a bit excessive ;) > > - Just put the fields people actually use at fixed offsets: si_signo, >si_errno, si_pid, si_uid, si_band, si_fd. > > - that still leaves room for the other cases if anybody ever wants them >(but I doubt it - things like si_addr are really only useful for >synchronous signals that are actually done as *signals*, since you >cannot defer a SIGBUS/SIGSEGV/SIGILL *anyway*). > > So I bet 99% of users actually just want si_signo, while some small subset > might want the SIGCHLD info and some of the special cases (eg we migth > want to add si_addr as a 64-bit thing just because the USB stack sends a > SI_ASYNCIO thing for completed URB's, so a libusb might want it, but > that's probably the only such user). > > And it would be *cleaner* than the mess that is siginfo_t.. > > (I realize that siginfo_t is ugly because it built up over time, using the > same buffer for many different things. I'm just saying that we can > probably do better by *not* using it, and just laying things out in a > cleaner manner to begin with, which also solves any compatibility issues) I can do that, no problem. But isn't it better to recognize that this kind of data just can't be shipped through a non compat-able function? Like, for example, the current trend to say "just use u64 for a pointer, it'll be fine". I remeber, a long time ago when the i386 architecture came out, to say "Wow! 4GB is gonna last *forever*!", let's use u32 for pointers. Well, forever is almost here in my watches. And all the userspace code using APIs assuming to cleanly store a pointer in a u32 will have to be re-factored. So, to cut it short, I can do the pseudo-siginfo read(2), but I don't like it too much (little, actually). The siginfo, as bad as it is, is a standard used in many POSIX APIs (hence even in kernel), and IMO if we want to send that back, a struct siginfo should be. No? - 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: the usage of DEBUG_DRIVER seems ambiguous
On Wed, 7 Mar 2007 19:44:41 -0500 (EST) Robert P. J. Day wrote: > > the usage of the DEBUG_DRIVER preprocessor variable is a big > confusing: > > $ $ grep -rw DEBUG_DRIVER * > drivers/net/sunlance.c:#undef DEBUG_DRIVER > drivers/net/a2065.c:#ifdef DEBUG_DRIVER > drivers/net/a2065.c:#ifdef DEBUG_DRIVER > drivers/net/7990.c:#ifdef DEBUG_DRIVER > drivers/net/7990.c:#ifdef DEBUG_DRIVER > drivers/base/Kconfig:config DEBUG_DRIVER > ... > > it's clearly a configuration variable, but it's also being used by > itself in a few drivers/net/ source files. is that deliberate? The ones in drivers/net/ are just local driver debug controls. They happen to have the same name as a (likely newer) kconfig symbol. Is there a real problem that needs to be fixed? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree
* Daniel Arai ([EMAIL PROTECTED]) wrote: > Chris, would you like to work together on this? I don't know what Xen's > requirements are for the APIC interface. Do you think we could come up > with something that would fit both of our needs, and maybe also be usable > for some of the subarch-specific code? Sure, we just have a pretty small genapic_xen, and then enough (hackery, this should be sorted out) to use that genapic and have an effective override for __send_IPI_shortcut. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: + stupid-hack-to-make-mainline-build.patch added to -mm tree
* Chris Wright <[EMAIL PROTECTED]> wrote: > > Chris, would you like to work together on this? I don't know what > > Xen's requirements are for the APIC interface. Do you think we > > could come up with something that would fit both of our needs, and > > maybe also be usable for some of the subarch-specific code? > > Sure, we just have a pretty small genapic_xen, and then enough > (hackery, this should be sorted out) to use that genapic and have an > effective override for __send_IPI_shortcut. genapic is still too lowlevel: as Thomas mentioned what we want is a virtual interrupt controller used by /all/ hypervisors (and mapped to their respective hypervisor ABIs via the backend). Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] 2.6.21-rc2: known regressions
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > Michael - does your 'date' output advance after resume? If not then > i'd say it's a NO_HZ related problem. [...] in that case please do this on such a 'frozen date' system: echo q > /proc/sysrq-trigger and then send us the hw-timers info. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Loop device - Tracking page writes made to a loop devicethrough mmap
Kandan Venkataraman wrote: > All comments have been taken care of. Your patch still does not do conversions of existing user space visible 'struct loop_info64' which is pretty much cast in stone. Blindly overwriting larger structure over smaller user space buffer of existing userspace binaries is the wrong way to do this. There was a time when folks at least pretended that breaking user space ABI was not tolerable. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: should RTS init in serial core be tied to CRTSCTS
Krzysztof Halasa wrote: > OTOH I wonder what does the device in question require WRT the > serial port and WRT RTS line in particular. > I know there are some half-duplex converters which drive RTS only > while sending and which require CTS to send. As far as I know in the old times this was the *standard* way to use a modem (per CCITT V24), and even nowadays many modems can handle this method for transmit, to stay compatible with the standard. Think of radio modems. Some are inherently half duplex. > They are perhaps a bit broken No, no, they apply an old standard. Probably they are old as well. > > I don't know if one can expect RTS to stay low all the time. Even > a simple /sbin/setserial from /etc/rc.* would drive it high for > a moment. I'm afraid the only way which makes sense may be using > a customized plug. It's a pity that Linux (or Unixes) never handled RTS this way. I feel that the /proc or sysfs solutions are the best to alter this well established default in this driver. It would not break existing installed hardware. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] 2.6.21-rc2: known regressions
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > > 3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of > > windows > >after waiting for some 10 min, I rebooted. no new messages showed > >up in /var/log/messages > > I think this is likely just more of the disk being buggered, but it > could again be related to NO_HZ (people report time not advancing, and > that would make any X timeout taking forever, and you'd see exactly > your behaviour). Michael - does your 'date' output advance after resume? If not then i'd say it's a NO_HZ related problem. If yes then i'd guess it's the SATA problem. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc3-mm1
On Thu, Mar 08, 2007 at 12:56:58PM -0500, [EMAIL PROTECTED] wrote: > On Wed, 07 Mar 2007 20:18:39 PST, Andrew Morton said: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm1/ > > Mostly working for me. > > > - The wireless changes in here need a lot of testers, please. It is major > > rework. > > Working on it - the new MAC80211 stack landed in the -mm tree, but the > matching > iwlwifi driver for the Intel 3945ABG is still out-of-tree and acting wonky > for me. The card comes up, 'iwlist scanning' sees 4 access points, but it > won't associate. Not sure what I borked up. FWIW, I have had best results w/ that driver by manually selecting the freq and ap as well as essid. Hth! John -- John W. Linville [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: /dev/null implementation question
On Thu, 8 Mar 2007 19:01:39 +0100 Michael Nitschinger wrote: > Hello, > > I asked myself how /dev/null is implemented in C, but i didn't find anything > in the documentation or generally on the internet. It would be great if > someone could tell me where i can find the source for this device or how it > is implemented, because it's really hard for me to crawl through the whole > sourcetree. > > thanks in advance, kind regards > Michael Nitschinger > > (p.s.: it would be great if you can Cc me in your answers because i am not > subscribed to the mailinglist! thanks) See linux/drivers/char/mem.c, look for null_fops. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/6] integrity: new hooks
* Casey Schaufler ([EMAIL PROTECTED]) wrote: > > --- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > > It's unfortunate, agreed, but > > > > use of LSM as an integrity framework was also a > > no-go. > > You're going to have to justify this assertion. > I know of at least one work-in-progress for which > LSM works just fine. Not to mention the Integrity > claims of SELinux. Serge is referring to the objections to EVM/IMA as LSM because it was not doing access control, rather integrity measurements. It's all in somewhere the archives. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: passing function pointers through platform devices?
>http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4c20386c8d0719b42503efe65abe47ad3fb3d711 > Your mail seems to be about a gpio userspace interface, which is > something entirely different from an in-kernel API, Sort of, IMHO sysfs classes seems the logical final incarnation for user space access. But to get there it has to migrate down from the machine layer to something that declares it's mapping to the pins on a board. However, just like gpio.txt discusses I am using them to detect MMC insertion, so I needed standard way to declare the pin. This provides that, thank you. NZG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded
At Thu, 08 Mar 2007 12:05:49 -0500, Randy Cushman wrote: > > Takashi Iwai wrote: > > At Thu, 8 Mar 2007 17:52:43 +0100, > > Michal Piotrowski wrote: > > > >> On 08/03/07, Takashi Iwai <[EMAIL PROTECTED]> wrote: > >> > >>> At Thu, 08 Mar 2007 16:42:26 +0100, > >>> Michal Piotrowski wrote: > >>> > > Also, it'd be helpful if you compare > > /proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the > > patch. This reveals which register bits differ actually. > > > a2.txt is form 2.6.21-rc3 witchout > 831466f4ad2b5fe23dff77edbe6a7c244435e973 > > diff -uprN a2.txt /proc/asound/card0/codec97#0/ac97#0-0+regs > --- a2.txt 2007-03-08 16:36:47.0 +0100 > +++ /proc/asound/card0/codec97#0/ac97#0-0+regs 2007-03-08 > 16:36:49.447083597 +0100 > @@ -56,8 +56,8 @@ > 0:6e = > 0:70 = > 0:72 = 0004 > -0:74 = 1001 > -0:76 = 64a4 > +0:74 = 1201 > +0:76 = 7ca4 > 0:78 = 000c > 0:7a = > 0:7c = 4144 > > >>> OK, some wrong bits there. Could you try the patch below? > >>> > >> Problem fixed. Thanks! > >> > >> (speaker-test -c6 -Dplug:surround51 is still broken) > >> > > > > Hm, how about turning off "Spread Front To..." control and run > > speaker-test? > > > > > > Takashi > > > > > > > Michal and Takashi, > > I've been researching your issue this morning. I just noticed that your > exchange had ensued. > > I configured my AD1986-based system as closely as I could to match your > AD1985 mixer settings. In doing so, I experienced results similar to > what I'm assuming you described: Only front channel sound came out of > the surround and c/lfe jacks. > > Here is what I had to change to get the appropriate multichannel sound: > > 1) The command "speaker-test -c6" does not work on my system. I have to > use "speaker-test -Dsurround51 -c6" (Perhaps this is related to running > an old version of speaker-test.) > > 2) I disabled "Spread Front to Surround and Center/LFE" > > The explanation for 2) is this: There can be only one source for each > of the Surround and Center/LFE jacks active at one time. When "Spread > Front to Surround and Center/LFE" is disabled, the surround channels go > to the the jacks; when this control is enabled, ONLY the front channels > go to the surround and c/lfe jacks. > > Considering the register values Michal provided and Takashi's patch: > > The logic of the code is as follows: (Slightly simplifying,) functions > is_shared_linein() and is_shared_micin() return TRUE if the mixer is > configured for shared jacks AND NOT for 6 channel mode. In this case it > is appropriate to > set these bits (LODIS and CLDIS). Yep. So, can you confirm that my fix is OK? Then I'll queue it up to ALSA tree. thanks, Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/6] integrity: new hooks
Quoting Casey Schaufler ([EMAIL PROTECTED]): > > --- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > > It's unfortunate, agreed, but > > > > use of LSM as an integrity framework was also a > > no-go. > > You're going to have to justify this assertion. You misunderstand. I wasn't saying it wouldn't work :) I was saying that it's been said repeatedly that evm should be implemented as an integrity, not security, module. I think it should be done as both. The part which measures the integrity of files should be an integrity subsystem. The part which uses those results to either allow/refuse actions or take some other action (i.e. shut down the system) should be an lsm. > I know of at least one work-in-progress for which > LSM works just fine. Not to mention the Integrity > claims of SELinux. -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: + stupid-hack-to-make-mainline-build.patch added to -mm tree
Chris Wright wrote: * Daniel Arai ([EMAIL PROTECTED]) wrote: There's no good way to override __send_IPI_shortcut. I suppose we could add paravirt ops for __send_IPI_shortcut and every other op that touches the APIC. While that's basically what we did in Xen, it would make more sense to build it into genapic which would give us one common abstraction to base from. We should avoid adding pv_ops when existing infrastructure exists. I agree with this. Chris, would you like to work together on this? I don't know what Xen's requirements are for the APIC interface. Do you think we could come up with something that would fit both of our needs, and maybe also be usable for some of the subarch-specific code? Dan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: passing function pointers through platform devices?
On 3/7/07, NZG <[EMAIL PROTECTED]> wrote: > Once the generic GPIO framework migrates upstream from -mm It already has: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4c20386c8d0719b42503efe65abe47ad3fb3d711 I googled extensively and requested information on any current work here before I began this project and got zip. (see forwarded email paste) Your mail seems to be about a gpio userspace interface, which is something entirely different from an in-kernel API, although I suppose it should be possible to build a userspace interface on top of the generic in-kernel API. If you're looking for a way to do GPIO from a driver, the new generic GPIO API should offer what you need, assuming it has actually been implemented on your platform. Haavard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] aio: fix oops because of extra IO control block freeing.
From Leonid Ananiev
Clean up unused return values in aio_complete() and aio_run_iocb().
Signed-off-by: Leonid Ananiev [EMAIL PROTECTED]
diff -uprN -X dontdiff linux-2.6.20-aio22/fs/aio.c
linux-2.6.20-aio23/fs/aio.c
--- linux-2.6.20-aio22/fs/aio.c2007-03-04 22:55:39.0 +0300
+++ linux-2.6.20-aio23/fs/aio.c2007-03-05 08:46:26.0 +0300
@@ -660,7 +660,7 @@ static inline int __queue_kicked_iocb(st
* simplifies the coding of individual aio operations as
* it avoids various potential races.
*/
-static ssize_t aio_run_iocb(struct kiocb *iocb)
+static void aio_run_iocb(struct kiocb *iocb)
{
struct kioctx*ctx = iocb->ki_ctx;
ssize_t (*retry)(struct kiocb *);
@@ -668,7 +668,7 @@ static ssize_t aio_run_iocb(struct kiocb
if (!(retry = iocb->ki_retry)) {
printk("aio_run_iocb: iocb->ki_retry = NULL\n");
-return 0;
+return;
}
/*
@@ -730,7 +730,6 @@ static ssize_t aio_run_iocb(struct kiocb
}
out:
spin_lock_irq(&ctx->ctx_lock);
-return ret;
}
/*
@@ -897,7 +896,7 @@ EXPORT_SYMBOL(kick_iocb);
*Returns true if this is the last user of the request. The
*only other user of the request can be the cancellation code.
*/
-int fastcall aio_complete(struct kiocb *iocb, long res, long res2)
+void fastcall aio_complete(struct kiocb *iocb, long res, long res2)
{
struct kioctx*ctx = iocb->ki_ctx;
struct aio_ring_info*info;
diff -uprN -X dontdiff linux-2.6.20-aio22/include/linux/aio.h
linux-2.6.20-aio23/include/linux/aio.h
--- linux-2.6.20-aio22/include/linux/aio.h2007-03-04
22:57:50.0 +0300
+++ linux-2.6.20-aio23/include/linux/aio.h2007-03-05
08:46:41.0 +0300
@@ -199,7 +199,7 @@ extern unsigned aio_max_size;
extern ssize_t FASTCALL(wait_on_sync_kiocb(struct kiocb *iocb));
extern int FASTCALL(aio_put_req(struct kiocb *iocb));
extern void FASTCALL(kick_iocb(struct kiocb *iocb));
-extern int FASTCALL(aio_complete(struct kiocb *iocb, long res, long res2));
+extern void FASTCALL(aio_complete(struct kiocb *iocb, long res, long
res2));
extern void FASTCALL(__put_ioctx(struct kioctx *ctx));
struct mm_struct;
extern void FASTCALL(exit_aio(struct mm_struct *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: [PATCH] x86_64 RESTORE_CONTEXT missing '\n'
On Thursday 08 March 2007 18:44, Dave Jiang wrote: > In spite of kgdb, shouldn't it have that \n anyways in case some other code > gets added in the future after the macro? Or are you saying that there should > never be any code ever after that macro? Sure if there is mainline code added after that macro we add the \n. But only if it makes sense to add code there, which it didn't in kgdb. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] aio: fix oops because of extra IO control block freeing.
From Leonid Ananiev
This patch finishes moving from using errno EIOCBRETRY to using flag in
IO control block for aio retrying. After this change the process will be
kicked for direct aio as it was for sync aio.
Signed-off-by: Leonid Ananiev <[EMAIL PROTECTED]>
The patch is applied to 2.6.20 or 2.6.21-rc2
diff -uprN -X linux-2.6.20-aio21/Documentation/dontdiff
linux-2.6.20-aio21/drivers/usb/gadget/inode.c
linux-2.6.20-aio22/drivers/usb/gadget/inode.c
--- linux-2.6.20-aio21/drivers/usb/gadget/inode.c2007-03-04
21:45:52.0 +0300
+++ linux-2.6.20-aio22/drivers/usb/gadget/inode.c2007-03-05
18:19:35.0 +0300
@@ -692,7 +692,10 @@ fail:
kfree(priv);
put_ep(epdata);
} else
-value = (iv ? -EIOCBRETRY : -EIOCBQUEUED);
+if (iv)
+kiocbSetPgBusy(iocb);
+else
+value = -EIOCBQUEUED;
return value;
}
diff -uprN -X linux-2.6.20-aio21/Documentation/dontdiff
linux-2.6.20-aio21/fs/ocfs2/dlmglue.c linux-2.6.20-aio22/fs/ocfs2/dlmglue.c
--- linux-2.6.20-aio21/fs/ocfs2/dlmglue.c2007-03-04
21:45:52.0 +0300
+++ linux-2.6.20-aio22/fs/ocfs2/dlmglue.c2007-03-04
22:57:50.0 +0300
@@ -1639,7 +1639,7 @@ int ocfs2_meta_lock_full(struct inode *i
status = ocfs2_cluster_lock(osb, lockres, level, dlm_flags,
arg_flags);
if (status < 0) {
-if (status != -EAGAIN && status != -EIOCBRETRY)
+if (status != -EAGAIN)
mlog_errno(status);
goto bail;
}
diff -uprN -X linux-2.6.20-aio21/Documentation/dontdiff
linux-2.6.20-aio21/include/linux/aio.h
linux-2.6.20-aio22/include/linux/aio.h
--- linux-2.6.20-aio21/include/linux/aio.h2007-03-04
21:46:45.0 +0300
+++ linux-2.6.20-aio22/include/linux/aio.h2007-03-04
22:57:50.0 +0300
@@ -79,15 +79,6 @@ struct kioctx;
* not ask the method again -- ki_retry must ensure forward progress.
* aio_complete() must be called once and only once in the future,
multiple
* calls may result in undefined behaviour.
- *
- * If ki_retry returns -EIOCBRETRY it has made a promise that kick_iocb()
- * will be called on the kiocb pointer in the future. This may happen
- * through generic helpers that associate kiocb->ki_wait with a wait
- * queue head that ki_retry uses via current->io_wait. It can also happen
- * with custom tracking and manual calls to kick_iocb(), though that is
- * discouraged. In either case, kick_iocb() must be called once and only
- * once. ki_retry must ensure forward progress, the AIO core will wait
- * indefinitely for kick_iocb() to be called.
*/
struct kiocb {
struct list_headki_run_list;
diff -uprN -X linux-2.6.20-aio21/Documentation/dontdiff
linux-2.6.20-aio21/include/linux/errno.h
linux-2.6.20-aio22/include/linux/errno.h
--- linux-2.6.20-aio21/include/linux/errno.h2007-03-04
21:45:51.0 +0300
+++ linux-2.6.20-aio22/include/linux/errno.h2007-03-04
22:57:50.0 +0300
@@ -22,7 +22,6 @@
#define EBADTYPE527/* Type not supported by server */
#define EJUKEBOX528/* Request initiated, but will not complete
before timeout */
#define EIOCBQUEUED529/* iocb queued, will get completion event */
-#define EIOCBRETRY530/* iocb queued, will trigger a retry */
#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: + stupid-hack-to-make-mainline-build.patch added to -mm tree
* Zachary Amsden ([EMAIL PROTECTED]) wrote: > s/do/will (smpboot.c) Well the current Xen mechanism rather dodges all of that (for bits like IPI apicid). thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: hardwired VMI crap
* Zachary Amsden ([EMAIL PROTECTED]) wrote: > Our code is in the tree now, and any attempts to break it using such > justifications as easing maintenance for kernel developers in future > releases are flat out false and improper. That's not quite accurate. This is what Ingo was complaining about earlier with VMI being an inhibitor to change. Core kernel will change and occassionally break VMI. It's entirely reasonable, and in fact normal, to make these changes, esp in the name of easing long term maintenance. There's some mutual responsibility to fix things up in the fallout. But, I really didn't think you disagreed with that, so perhaps I've misunderstood the above. > We are working to correct > flaws that we have and properly conform to the changing interfaces such > as the timer subsystem, and also to interoperate properly with the full > set of available configurations. Right, so let's move on ;-) thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 2/6] integrity: fs hook placement
On Thu, 2007-03-08 at 21:16 +0300, Dmitriy Monakhov wrote:
> Mimi Zohar <[EMAIL PROTECTED]> writes:
>
> > This patch places calls to the new integrity hooks in the appropriate
> > places in the fs directory. It is not meant in any way to be viewed
> > as a complete set, but used as a basis for an initial discussion.
> >
> > Index: linux-2.6.21-rc3-mm2/fs/ext3/xattr_security.c
> > ===
> > --- linux-2.6.21-rc3-mm2.orig/fs/ext3/xattr_security.c
> > +++ linux-2.6.21-rc3-mm2/fs/ext3/xattr_security.c
> > @@ -10,6 +10,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include "xattr.h"
> >
> > static size_t
> > @@ -58,12 +59,19 @@ ext3_init_security(handle_t *handle, str
> >
> > err = security_inode_init_security(inode, dir, &name, &value, &len);
> > if (err) {
> > + /* Even if creation of the security xattr fails, must
> > +* indicate this is a new inode. */
> > + integrity_inode_init_integrity(inode, dir, NULL, NULL, NULL);
> > if (err == -EOPNOTSUPP)
> > return 0;
> > return err;
> > }
> block begin
> > err = ext3_xattr_set_handle(handle, inode, EXT3_XATTR_INDEX_SECURITY,
> > name, value, len, 0);
> > +
> > + integrity_inode_init_integrity(inode, dir, &name, &value, &len);
> > + err = ext3_xattr_set_handle(handle, inode, EXT3_XATTR_INDEX_SECURITY,
> > + name, value, len, 0);
> block end
> May be i've missed something, but i don't get last block.
> Why you call ext3_xattr_set_handle() twise?,
> or you just mistyped and it has to look like this:
> <<
[PATCH] VFS : Delay the dentry name generation on sockets and pipes.
Hi Andrew
I am sorry, my previous patch had a /proc/*/fd/ in a comment, so the */ closed
the comment and fs/dcache.c could not compile.
Could you please put this 'final-final' version in mm for testing ?
Thank's to all contributors, sorry for the noise.
[PATCH] VFS : Delay the dentry name generation on sockets and pipes.
1) Introduces a new method in 'struct dentry_operations'. This method called
d_dname() might be called from d_path() to build a pathname
for special filesystems. It is called without locks.
Future patches (if we succeed in having one common dentry for all
pipes/sockets) may need to change prototype of this method, but we now use :
char *d_dname(struct dentry *dentry, char *buffer, int buflen);
2) Use this new method for sockets : No more sprintf() at socket creation.
This is delayed up to the moment someone does an access to /proc/pid/fd/...
3) Use this new method for pipes : No more sprintf() at pipe creation. This is
delayed up to the moment someone does an access to /proc/pid/fd/...
A benchmark consisting of 1.000.000 calls to pipe()/close()/close() gives a
*nice* speedup on my Pentium(M) 1.6 Ghz :
3.090 s instead of 3.450 s
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
Acked-by: Christoph Hellwig <[EMAIL PROTECTED]>
Acked-by: Linus Torvalds <[EMAIL PROTECTED]>
Documentation/filesystems/Locking | 2 ++
Documentation/filesystems/vfs.txt | 12 +++-
fs/dcache.c | 10 ++
fs/pipe.c | 15 +--
include/linux/dcache.h | 1 +
net/socket.c | 17 ++---
6 files changed, 43 insertions(+), 14 deletions(-)
--- linux-2.6.21-rc3/include/linux/dcache.h 2007-03-07 17:23:55.0
+0100
+++ linux-2.6.21-rc3-ed/include/linux/dcache.h 2007-03-08 11:57:41.0
+0100
@@ -133,6 +133,7 @@ struct dentry_operations {
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
+ char *(*d_dname)(struct dentry *, char *, int);
};
/* the dentry parameter passed to d_hash and d_compare is the parent
--- linux-2.6.21-rc3/Documentation/filesystems/vfs.txt 2007-03-08
10:14:38.0 +0100
+++ linux-2.6.21-rc3-ed/Documentation/filesystems/vfs.txt 2007-03-08
12:08:56.0 +0100
@@ -827,7 +827,7 @@ This describes how a filesystem can over
operations. Dentries and the dcache are the domain of the VFS and the
individual filesystem implementations. Device drivers have no business
here. These methods may be set to NULL, as they are either optional or
-the VFS uses a default. As of kernel 2.6.13, the following members are
+the VFS uses a default. As of kernel 2.6.22, the following members are
defined:
struct dentry_operations {
@@ -837,6 +837,7 @@ struct dentry_operations {
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
+ char *(*d_dname)(struct dentry *, char *, int);
};
d_revalidate: called when the VFS needs to revalidate a dentry. This
@@ -859,6 +860,15 @@ struct dentry_operations {
VFS calls iput(). If you define this method, you must call
iput() yourself
+ d_dname: called when the pathname of a dentry should be generated.
+ Usefull for some pseudo filesystems (sockfs, pipefs, ...) to delay
+ pathname generation. (Instead of doing it when dentry is created,
+ its done only when the path is needed.). Real filesystems probably
+ dont want to use it, because their dentries are present in global
+ dcache hash, so their hash should be an invariant. As no lock is
+ held, d_dname() should not try to modify the dentry itself, unless
+ appropriate SMP safety is used.
+
Each dentry has a pointer to its parent dentry, as well as a hash list
of child dentries. Child dentries are basically like files in a
directory.
--- linux-2.6.21-rc3/Documentation/filesystems/Locking 2007-03-08
10:29:04.0 +0100
+++ linux-2.6.21-rc3-ed/Documentation/filesystems/Locking 2007-03-08
12:08:56.0 +0100
@@ -15,6 +15,7 @@ prototypes:
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
+ char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
locking rules:
none have BKL
@@ -25,6 +26,7 @@ d_compare:no yes no
no
d_delete: yes no yes no
d_release: no no no yes
d_iput:no no no yes
+d_dname: no no no no
--- inode_operations ---
prototypes:
--- linux-2.6.21-rc3/fs/dcache.c2007-03-07 17:
Re: [RFC][Patch 1/6] integrity: new hooks
--- "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > It's unfortunate, agreed, but > > use of LSM as an integrity framework was also a > no-go. You're going to have to justify this assertion. I know of at least one work-in-progress for which LSM works just fine. Not to mention the Integrity claims of SELinux. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/dev/null implementation question
Hello, I asked myself how /dev/null is implemented in C, but i didn't find anything in the documentation or generally on the internet. It would be great if someone could tell me where i can find the source for this device or how it is implemented, because it's really hard for me to crawl through the whole sourcetree. thanks in advance, kind regards Michael Nitschinger (p.s.: it would be great if you can Cc me in your answers because i am not subscribed to the mailinglist! 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: + stupid-hack-to-make-mainline-build.patch added to -mm tree
* Daniel Arai ([EMAIL PROTECTED]) wrote: > There's no good way to override __send_IPI_shortcut. I suppose we could add > paravirt ops for __send_IPI_shortcut and every other op that touches the > APIC. While that's basically what we did in Xen, it would make more sense to build it into genapic which would give us one common abstraction to base from. We should avoid adding pv_ops when existing infrastructure exists. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 2/6] integrity: fs hook placement
On Thu, 2007-03-08 at 09:40 -0800, Chris Wright wrote: > * Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > > Are you objecting only to the duplication at the callsites, so that an > > fsnotify-type of consolidation of security and integrity hooks would be > > ok? Or are you complaining that the security_inode_setxattr and > > integrity_inode_setxattr hooks are too similar anyway, and integrity > > modules should just use some lsm hooks for anything which will be > > authoritative? > > It's duplication of callsites with many identical implementations > that's the problem. > > > (I could see an argument that integirty subsystem should be purely for > > measuring and hence its hooks should never return a value. Only hitch > > there is that if integrity subsystem hits ENOMEM it should be able to > > refuse the action...) > > Right, that's what I was expecting to see, just the measurement > infrastructure. There are a total of 10 Linux Integrity Module(LIM) hooks. Seven of which parallel the LSM hooks, out of the ~150 LSM hooks. 3 of the LIM hooks are for initializing, allocating, and freeing the inode- >i_integrity, used for caching integrity information. As the integrity information is stored as extended attributes, 2 hooks are for catching changes to the extended attributes, one is for updating the extended attributes when the file closes, and d_instantiate is used for initialization. Is this excessive? How else would you design integrity, without using the LSM hooks? Mimi Zohar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 2/6] integrity: fs hook placement
Mimi Zohar <[EMAIL PROTECTED]> writes:
> This patch places calls to the new integrity hooks in the appropriate
> places in the fs directory. It is not meant in any way to be viewed
> as a complete set, but used as a basis for an initial discussion.
>
> Index: linux-2.6.21-rc3-mm2/fs/ext3/xattr_security.c
> ===
> --- linux-2.6.21-rc3-mm2.orig/fs/ext3/xattr_security.c
> +++ linux-2.6.21-rc3-mm2/fs/ext3/xattr_security.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include "xattr.h"
>
> static size_t
> @@ -58,12 +59,19 @@ ext3_init_security(handle_t *handle, str
>
> err = security_inode_init_security(inode, dir, &name, &value, &len);
> if (err) {
> + /* Even if creation of the security xattr fails, must
> + * indicate this is a new inode. */
> + integrity_inode_init_integrity(inode, dir, NULL, NULL, NULL);
> if (err == -EOPNOTSUPP)
> return 0;
> return err;
> }
block begin
> err = ext3_xattr_set_handle(handle, inode, EXT3_XATTR_INDEX_SECURITY,
> name, value, len, 0);
> +
> + integrity_inode_init_integrity(inode, dir, &name, &value, &len);
> + err = ext3_xattr_set_handle(handle, inode, EXT3_XATTR_INDEX_SECURITY,
> + name, value, len, 0);
block end
May be i've missed something, but i don't get last block.
Why you call ext3_xattr_set_handle() twise?,
or you just mistyped and it has to look like this:
<<< kfree(name);
> kfree(value);
> return err;
> Index: linux-2.6.21-rc3-mm2/include/linux/fs.h
> ===
> --- linux-2.6.21-rc3-mm2.orig/include/linux/fs.h
> +++ linux-2.6.21-rc3-mm2/include/linux/fs.h
> @@ -591,6 +591,9 @@ struct inode {
> #ifdef CONFIG_SECURITY
> void*i_security;
> #endif
> +#ifdef CONFIG_INTEGRITY
> + void*i_integrity;
> +#endif
> void*i_private; /* fs or device private pointer */
> };
>
> Index: linux-2.6.21-rc3-mm2/fs/dcache.c
> ===
> --- linux-2.6.21-rc3-mm2.orig/fs/dcache.c
> +++ linux-2.6.21-rc3-mm2/fs/dcache.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -986,6 +987,7 @@ void d_instantiate(struct dentry *entry,
> entry->d_inode = inode;
> fsnotify_d_instantiate(entry, inode);
> spin_unlock(&dcache_lock);
> + integrity_d_instantiate(entry, inode);
> security_d_instantiate(entry, inode);
> }
>
> @@ -1050,6 +1052,7 @@ struct dentry *d_instantiate_unique(stru
> spin_unlock(&dcache_lock);
>
> if (!result) {
> + integrity_d_instantiate(entry, inode);
> security_d_instantiate(entry, inode);
> return NULL;
> }
> @@ -1187,6 +1190,7 @@ struct dentry *d_splice_alias(struct ino
> BUG_ON(!(new->d_flags & DCACHE_DISCONNECTED));
> fsnotify_d_instantiate(new, inode);
> spin_unlock(&dcache_lock);
> + integrity_d_instantiate(new, inode);
> security_d_instantiate(new, inode);
> d_rehash(dentry);
> d_move(new, dentry);
> @@ -1197,6 +1201,7 @@ struct dentry *d_splice_alias(struct ino
> dentry->d_inode = inode;
> fsnotify_d_instantiate(dentry, inode);
> spin_unlock(&dcache_lock);
> + integrity_d_instantiate(dentry, inode);
> security_d_instantiate(dentry, inode);
> d_rehash(dentry);
> }
> @@ -1748,6 +1753,7 @@ found:
> spin_unlock(&dcache_lock);
> out_nolock:
> if (actual == dentry) {
> + integrity_d_instantiate(dentry, inode);
> security_d_instantiate(dentry, inode);
> return NULL;
> }
> Index: linux-2.6.21-rc3-mm2/fs/file_table.c
> ===
> --- linux-2.6.21-rc3-mm2.orig/fs/file_table.c
> +++ linux-2.6.21-rc3-mm2/fs/file_table.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -169,6 +170,7 @@ void fastcall __fput(struct file *file)
> if (file->f_op && file->f_op->release)
> file->f_op->release(inode, file);
> security_file_free(file);
> + integrity_file_free(file);
> if (unlikely(S_ISCHR(inode->i_mode) && inode->i_cdev != NULL))
> cdev_put(inode->i_cdev);
> fops_put(file->f_op);
> @@ -240,6 +242,7 @@ void put_filp(struct file *file)
> {
> if (atomic_dec_and_test(&file->f_count)) {
> security
Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4
On Thu, 8 Mar 2007, Mel Gorman wrote: > > Note that the 16kb page size has a major > > impact on SLUB performance. On IA64 slub will use only 1/4th the locking > > overhead as on 4kb platforms. > It'll be interesting to see the kernbench tests then with debugging > disabled. You can get a similar effect on 4kb platforms by specifying slub_min_order=2 on bootup. This means that we have to rely on your patches to allow higher order allocs to work reliably though. The higher the order of slub the less locking overhead. So the better your patches deal with fragmentation the more we can reduce locking overhead in slub. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] repost I/OAT fixes
I/OAT fixes and missing documentation.
Please pull from,
git://lost.foo-projects.org/~cleech/linux-2.6#master
--
Andrew Morton (1):
I/OAT: warning fix
Chris Leech (6):
ioatdma: Push pending transactions to hardware more frequently
ioatdma: Remove the wrappers around read(bwl)/write(bwl) in ioatdma
ioatdma: Remove the use of writeq from the ioatdma driver
I/OAT: Add documentation for the tcp_dma_copybreak sysctl
I/OAT: Add entries to MAINTAINERS for the DMA memcpy subsystem and ioatdma
I/OAT: Only offload copies for TCP when there will be a context switch
Dan Aloni (1):
I/OAT: fix I/OAT for kexec
Jeff Garzik (1):
drivers/dma: handle sysfs errors
Documentation/networking/ip-sysctl.txt |6 +
MAINTAINERS| 12 +++
drivers/dma/dmaengine.c| 22 +-
drivers/dma/ioatdma.c | 81 --
drivers/dma/ioatdma_io.h | 118 -
net/ipv4/tcp.c | 26 +--
6 files changed, 100 insertions(+), 165 deletions(-)
commit 3ac82a51550c649c67f42f218e5d1ccc4e865685
Author: Dan Aloni <[EMAIL PROTECTED]>
Date: Thu Mar 8 09:57:36 2007 -0800
I/OAT: fix I/OAT for kexec
Under kexec, I/OAT initialization breaks over busy resources because the
previous kernel did not release them.
I'm not sure this fix can be considered a complete one but it works for me.
I guess something similar to the *_remove method should occur there..
Signed-off-by: Dan Aloni <[EMAIL PROTECTED]>
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c
index cbf93ca..1d259e5 100644
--- a/drivers/dma/ioatdma.c
+++ b/drivers/dma/ioatdma.c
@@ -41,6 +41,7 @@
/* internal functions */
static int __devinit ioat_probe(struct pci_dev *pdev, const struct
pci_device_id *ent);
+static void ioat_shutdown(struct pci_dev *pdev);
static void __devexit ioat_remove(struct pci_dev *pdev);
static int enumerate_dma_channels(struct ioat_device *device)
@@ -557,6 +558,7 @@ static struct pci_driver ioat_pci_drv = {
.name = "ioatdma",
.id_table = ioat_pci_tbl,
.probe = ioat_probe,
+ .shutdown = ioat_shutdown,
.remove = __devexit_p(ioat_remove),
};
@@ -781,9 +783,20 @@ err_request_regions:
err_set_dma_mask:
pci_disable_device(pdev);
err_enable_device:
+
+ printk(KERN_ERR "Intel(R) I/OAT DMA Engine initialization failed\n");
+
return err;
}
+static void ioat_shutdown(struct pci_dev *pdev)
+{
+ struct ioat_device *device;
+ device = pci_get_drvdata(pdev);
+
+ dma_async_device_unregister(&device->common);
+}
+
static void __devexit ioat_remove(struct pci_dev *pdev)
{
struct ioat_device *device;
commit 1fa77931067fac6fb2fa01008854da9c77cdcd87
Author: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu Mar 8 09:57:36 2007 -0800
I/OAT: warning fix
net/ipv4/tcp.c: In function 'tcp_recvmsg':
net/ipv4/tcp.c:: warning: unused variable 'available'
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 5ccd5e1..69c525d 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1110,7 +1110,6 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk,
struct msghdr *msg,
long timeo;
struct task_struct *user_recv = NULL;
int copied_early = 0;
- int available = 0;
struct sk_buff *skb;
lock_sock(sk);
@@ -1139,15 +1138,22 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk,
struct msghdr *msg,
tp->ucopy.dma_chan = NULL;
preempt_disable();
skb = skb_peek_tail(&sk->sk_receive_queue);
- if (skb)
- available = TCP_SKB_CB(skb)->seq + skb->len - (*seq);
- if ((available < target) &&
- (len > sysctl_tcp_dma_copybreak) && !(flags & MSG_PEEK) &&
- !sysctl_tcp_low_latency && __get_cpu_var(softnet_data).net_dma) {
- preempt_enable_no_resched();
- tp->ucopy.pinned_list = dma_pin_iovec_pages(msg->msg_iov, len);
- } else
- preempt_enable_no_resched();
+ {
+ int available = 0;
+
+ if (skb)
+ available = TCP_SKB_CB(skb)->seq + skb->len - (*seq);
+ if ((available < target) &&
+ (len > sysctl_tcp_dma_copybreak) && !(flags & MSG_PEEK) &&
+ !sysctl_tcp_low_latency &&
+ __get_cpu_var(softnet_data).net_dma) {
+ preempt_enable_no_resched();
+ tp->ucopy.pinned_list =
+ dma_pin_iovec_pages(msg->msg_iov, len);
+ } else {
+ preempt_enable_no_resched();
Re: Possible "struct pid" leak from tty_io.c
"Catalin Marinas" <[EMAIL PROTECTED]> writes: > Hi Eric, > > I'm trying to track down a kmemleak report (on an ARM platform) which > seems to have appeared with commit > ab521dc0f8e117fd808d3e425216864d60390500. As I'm not familiar with the > TTY layer at all, is it possible that the above commit missed a > put_pid() call on some path? I won't arbitrarily rule a missing put_pid out. I have been know to goof up upon occasion. I just did a quick look to see what kmemleak is. A conservative tracing leak detector sounds interesting. Except for all of the list heads which lead to container_of calls I don't know of anything in the struct pid implementation that would be difficult for it to work with. Well that and there is some rcu access protection which can delay the free by a bit. > The /sbin/init application calls sys_clone() a few times but only one > leak is reported (see below). Looking at the reported pid object (at > 0xc7c14500), count is 2 and nr is 296 but no process with pid 296 > exists any more. It could still be a valid session or a process group id. If you examine the struct pid you can test for this be examining all of the list heads it keeps. If there is something on any of the lists that would account a count of 1. How we have a count of 2 I don't have enough information to guess. Core tty layer handling stops having an remembering pids when the session or process group exits so it is relatively safe from pid wrap around issues without my changes and should make the kind of thing you are reporting very unlikely in a correctly functioning system. In most any other layer we cache pids indefinitely and a situation where we have a pointer to a struct pid with a ref count of 1 long after the process goes away is expected. In this case it is better to hold a reference to a struct pid so we don't do the wrong thing when pid wrap around occurs then to hold a reference to an entire task_struct and lock that in place. I don't understand your situation enough to guess what is going wrong yet. Hopefully I have given you enough information to get started. > unreferenced object 0xc7c14500 (size 36): > comm "init", pid 245, jiffies 4294939289 > backtrace: >[] kmem_cache_alloc >[] alloc_pid >[] do_fork >[] sys_clone >[] ret_fast_syscall I think this is the path that all pid structures come from so unfortunately that doesn't help tracing this problem down. 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: [2/6] 2.6.21-rc2: known regressions
[ Eric, Ingo, can you double-check the timer initialization after resume? We appear to have several reports of date not advancing, and while this could be some SATA issue, it could easily be a timer tick issue too ] On Thu, 8 Mar 2007, Michael S. Tsirkin wrote: > > Here's the status with -rc3: better, but still does not work as well as > 2.6.20. Ok. I think we mostly solved the irq-related stuff, but you might want to check whether you have CONFIG_NOHZ on or off and whether that makes a difference. > 2. First disk access after resume takes a couple of minutes >(seemed instant with 2.6.20) during this time no new messages show on > console Yeah, there is some problem with SATA resume. It would be beautiful if the people who actually see this could narrow it down with bisection. "It works for me" is clearly the case for many people, but not all. But before blaming SATA, check if you have NO_HZ enabled and whether disabling that makes it work ok. If timeouts don't work right (or are *extremely* slow) things that should be instant won't be. > 3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of windows >after waiting for some 10 min, I rebooted. >no new messages showed up in /var/log/messages I think this is likely just more of the disk being buggered, but it could again be related to NO_HZ (people report time not advancing, and that would make any X timeout taking forever, and you'd see exactly your behaviour). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PAGE_SIZE Availability Inconsistency
Anton Blanchard wrote: By the way, it's a massive snafu that the swap area magic number is dependent on PAGE_SIZE. There is absolutely no good reason for that. Agreed, its been a big problem booting between 4kB and 64kB kernels on ppc64. The easiest way to fix this would be to always park the swap magic at the offset of the smallest page size in use, which is 4K. This is analogous how the offset for the ext2/3 superblock got fixed at 1K -- for 1K blocks, it's the second block, but for larger blocks, it's part of the first block. If we fix the offset of the swap magic at 4096 minus the offset that's already there, it will always fall in the first page regardless of page size. -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 2/6] integrity: fs hook placement
Quoting Chris Wright ([EMAIL PROTECTED]): > * Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > > Are you objecting only to the duplication at the callsites, so that an > > fsnotify-type of consolidation of security and integrity hooks would be > > ok? Or are you complaining that the security_inode_setxattr and > > integrity_inode_setxattr hooks are too similar anyway, and integrity > > modules should just use some lsm hooks for anything which will be > > authoritative? > > It's duplication of callsites with many identical implementations > that's the problem. Yes it's ugly... But I guess it gets a point across :) > > (I could see an argument that integirty subsystem should be purely for > > measuring and hence its hooks should never return a value. Only hitch > > there is that if integrity subsystem hits ENOMEM it should be able to > > refuse the action...) > > Right, that's what I was expecting to see, just the measurement > infrastructure. So what you are saying is EVM would stay an LSM, with a cooperating integrity subsystem *just* doing measurements? That's kind of what i was expecting too, however that doesn't fit as well with the idea that an integrity subsystem prevents the need for lsm stacking. I think the idea was that evm would still be able to enforce integrity of selinux xattrs without it stack with selinux. So I can see where this approach came from. -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PAGE_SIZE Availability Inconsistency
> By the way, it's a massive snafu that the swap area magic number is > dependent on PAGE_SIZE. There is absolutely no good reason for that. Agreed, its been a big problem booting between 4kB and 64kB kernels on ppc64. Anton - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc3-mm1
On Wed, 07 Mar 2007 20:18:39 PST, Andrew Morton said: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm1/ Mostly working for me. > - The wireless changes in here need a lot of testers, please. It is major > rework. Working on it - the new MAC80211 stack landed in the -mm tree, but the matching iwlwifi driver for the Intel 3945ABG is still out-of-tree and acting wonky for me. The card comes up, 'iwlist scanning' sees 4 access points, but it won't associate. Not sure what I borked up. pgp5svZo4Kh3r.pgp Description: PGP signature
Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4
On Thu, 8 Mar 2007, Mel Gorman wrote: > Brought up 4 CPUs > Node 0 CPUs: 0-3 > mm/memory.c:111: bad pud c50e4480. Lower bits must be clear right? Looks like the pud was released and then reused for a 64 byte cache or so. This is likely a freelist pointer that slub put there after allocating the page for the 64 byte cache. Then we tried to use the pud. > migration_cost=0,1000 > *** SLUB: Redzone Inactive check fails in [EMAIL PROTECTED] Slab > c0756090 > offset=240 flags=50c7 inuse=3 freelist=c50de0f0 > Bytes b4 c50de0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Object c50de0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Object c50de100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Object c50de110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Object c50de120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >Redzone c50de130: 00 00 00 00 00 00 00 00 > FreePointer c50de138: Data overwritten after free or after slab was allocated. So this may be the same issue. pud was zapped after it was freed destroying the poison of another object in the 64 byte cache. Hmmm.. Maybe I should put the pad checks before the object checks. That way we detect that the whole slab was corrupted and do not flag just a single object. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] containers (V7): Add generic multi-subsystem API to containers
On Mon, Feb 12, 2007 at 12:15:24AM -0800, [EMAIL PROTECTED] wrote:
> +static struct container_group *find_container_group(
> + struct container_group *oldcg, struct container *cont)
> +{
> + struct container_group *res;
> + struct container_subsys *ss;
> + int h = cont->hierarchy;
> + int i;
> +
> + BUG_ON(oldcg->container[h] == cont);
> + /* First see if we already have a container group that matches
> + * the desired set */
> + spin_lock(&container_group_lock);
I think this should be spin_lock_irq().
I have been bitten by lockdep warning in the rcfs patchs. But I think
they should apply here as well.
Essentially, container_task_count() is called from cpuset.c after doing
write_lock_irq(tasklist_lock). This creates the dependency:
tasklist_lock (irqs disabled) -> container_group_lock
However in above function, find_container_group (and several other
functions) we take container_group_lock w/o blocking interrupts. An
interrupt handler now trying to take tasklist_lock will cause a
deadlock.
--
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64 RESTORE_CONTEXT missing '\n'
Andi Kleen wrote: > On Wednesday 07 March 2007 21:45, Dave Jiang wrote: >> The RESTORE_CONTEXT macro is missing the '\n' at the end. It was removed in >> the >> previous patch that touched system.h. It causes compile failure if any >> inline asm is added after the macro. Discovered this when playing with >> kgdb. > > We went through this several times. kgdb has no business to poke > into kernel private macros like this and it shouldn't do that. > So fixing kgdb to not require touching the context switch is the right > change. > > -Andi In spite of kgdb, shouldn't it have that \n anyways in case some other code gets added in the future after the macro? Or are you saying that there should never be any code ever after that macro? -- -- Dave Jiang Software Engineer MontaVista Software, Inc. http://www.mvista.com -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 2/6] integrity: fs hook placement
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > Are you objecting only to the duplication at the callsites, so that an > fsnotify-type of consolidation of security and integrity hooks would be > ok? Or are you complaining that the security_inode_setxattr and > integrity_inode_setxattr hooks are too similar anyway, and integrity > modules should just use some lsm hooks for anything which will be > authoritative? It's duplication of callsites with many identical implementations that's the problem. > (I could see an argument that integirty subsystem should be purely for > measuring and hence its hooks should never return a value. Only hitch > there is that if integrity subsystem hits ENOMEM it should be able to > refuse the action...) Right, that's what I was expecting to see, just the measurement infrastructure. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [SLUB 0/3] SLUB: The unqueued slab allocator V4
On (08/03/07 08:48), Christoph Lameter didst pronounce: > On Thu, 8 Mar 2007, Mel Gorman wrote: > > > On x86_64, it completed successfully and looked reliable. There was a 5% > > performance loss on kernbench and aim9 figures were way down. However, with > > slub_debug enabled, I would expect that so it's not a fair comparison > > performance wise. I'll rerun the tests without debug and see what it looks > > like if you're interested and do not think it's too early to worry about > > performance instead of clarity. This is what I have for bl6-13 (machine > > appears on test.kernel.org so additional details are there). > > No its good to start worrying about performance now. There are still some > performance issues to be ironed out in particular on NUMA. I am not sure > f.e. how the reduction of partial lists affect performance. > Ok, I've sent off a bunch of tests - two of which are on NUMA (numaq and x86_64). It'll take them a long time to complete though as there is a lot of testing going on right now. > > IA64 (machine not visible on TKO) curiously did not exhibit the same > > problems > > on kernbench for Total CPU time which is very unexpected but you can see the > > System CPU times. The AIM9 figures were a bit of an upset but again, I blame > > slub_debug being enabled > > This was a single node box? Yes, memory looks like this; Zone PFN ranges: DMA 1024 -> 262144 Normal 262144 -> 262144 Movable zone start PFN for each node early_node_map[3] active PFN ranges 0: 1024 ->30719 0:32768 ->65413 0:65440 ->65505 On node 0 totalpages: 62405 Node 0 memmap at 0xe1126000 size 3670016 first pfn 0xe1134000 DMA zone: 220 pages used for memmap DMA zone: 0 pages reserved DMA zone: 62185 pages, LIFO batch:7 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap > Note that the 16kb page size has a major > impact on SLUB performance. On IA64 slub will use only 1/4th the locking > overhead as on 4kb platforms. > It'll be interesting to see the kernbench tests then with debugging disabled. > > (as an aside, the succes rates for high-order allocations are lower with > > SLUB. > > Again, I blame slub_debug. I know that enabling SLAB_DEBUG has similar > > effects > > because of red-zoning and the like) > > We have some additional patches here that reduce the max order for some > allocs. I believe the task_struct gets to be an order 2 alloc with V4, > Should make a difference for slab fragmentation > > Now, the bad news. This exploded on ppc64. It started going wrong early in > > the > > boot process and got worse. I haven't looked closely as to why yet as there > > is > > other stuff on my plate but I've included a console log that might be some > > use > > to you. If you think you have a fix for it, feel free to send it on and I'll > > give it a test. > > Hmmm... Looks like something is zapping an object. Try to rerun with > a kernel compiled with CONFIG_SLAB_DEBUG. I would expect similar results. > I've queued up a few tests. One completed as I wrote this and it didn't explode with SLAB_DEBUG set. Maybe the others will be different. I'll kick it around for a bit. It could be a real bug that slab is just not catuching. > > Brought up 4 CPUs > > Node 0 CPUs: 0-3 > > mm/memory.c:111: bad pud c50e4480. > > could not vmalloc 20971520 bytes for cache! > > Hmmm... a bad pud? I need to look at how the puds are managed on power. > > > migration_cost=0,1000 > > *** SLUB: Redzone Inactive check fails in [EMAIL PROTECTED] Slab > > An object was overwritten with zeros after it was freed. > > RTAS daemon started > > RTAS: event: 1, Type: Platform Error, Severity: 2 > > audit: initializing netlink socket (disabled) > > audit(1173335571.256:1): initialized > > Total HugeTLB memory allocated, 0 > > VFS: Disk quotas dquot_6.5.1 > > Dquot-cache hash table entries: 512 (order 0, 4096 bytes) > > JFS: nTxBlock = 8192, nTxLock = 65536 > > SELinux: Registering netfilter hooks > > io scheduler noop registered > > io scheduler anticipatory registered (default) > > io scheduler deadline registered > > io scheduler cfq registered > > pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > > rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 > > rpaphp: Slot [:00:02.2](PCI location=U7879.001.DQD0T7T-P1-C4) registered > > vio_register_driver: driver hvc_console registering > > [ cut here ] > > Badness at mm/slub.c:1701 > > Someone did a kmalloc(0, ...). Zero sized allocation are not flagged > by SLAB but SLUB does. > I'll chase up what's happening here. It will be "reproducable" independent of SLUB by adding a similar check. > > Call Trace: > > [C506B730] [C0011188] .show_stack+0x6c/0x1a0 (unreliable) > > [C506B7D0] [C01EE9F4] .report_bug+0x94/0xe8 > > [C506B860] [C038C85C] .program_check_exception+0x16c/0x5f4 > > [C
EXT3-fs warning (device sdd2): dx_probe: Unrecognised inode hash code 232
Hello, Running 2.6.19.1 on AMD64. While copying some files on an ext3 partition, I got this in the logs: EXT3-fs warning (device sdd2): dx_probe: Unrecognised inode hash code 232 Assertion failure in dx_probe() at fs/ext3/namei.c:384: "dx_get_limit(entries) == dx_root_limit(dir, root->info.info_length)" --- [cut here ] - [please bite here ] - Kernel BUG at fs/ext3/namei.c:384 invalid opcode: [1] PREEMPT SMP CPU 0 Modules linked in: xt_multiport iptable_filter ip_tables x_tables binfmt_misc fuse parport_pc lp parport thermal fan button nls_iso8859_15 ntfs kqemu(P) tcp_diag inet_diag w83627ehf i2c_isa cpufreq_ondemand powernow_k8 freq_table processor snd_hda_intel snd_hda_codec snd_pcm evdev snd_timer psmouse snd pcspkr floppy ehci_hcd soundcore snd_page_alloc usbcore k8temp hwmon ohci1394 ieee1394 forcedeth i2c_nforce2 i2c_core sg sr_mod cdrom Pid: 4018, comm: find Tainted: P 2.6.19.5 #1 RIP: 0010:[] [] dx_probe+0x18b/0x320 RSP: 0018:81006b789d28 EFLAGS: 00010292 RAX: 0081 RBX: 810066f07018 RCX: c100 RDX: 81006b788000 RSI: 81006b5c62c0 RDI: RBP: R08: 81006b788000 R09: 0001 R10: R11: 80212a20 R12: 810066e6f8e8 R13: R14: R15: 810066f06730 FS: 2ae8c9f5c6d0() GS:80586000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 2af535db8086 CR3: 6b7b2000 CR4: 06e0 Process find (pid: 4018, threadinfo 81006b788000, task 81006b5c62c0) Stack: 81006b789dd4 81006b789d88 81007f79d750 810066e6acc0 810066f06730 810066f06730 81007efca580 802f13ab 810066e6ace8 7ff98780 Call Trace: [] ext3_htree_fill_tree+0xab/0x1e0 [] ext3_readdir+0x1a9/0x530 [] vfs_readdir+0x73/0xc0 [] sys_getdents64+0x7f/0xd0 [] system_call+0x7e/0x83 [<2ae8c9dad41a>] Code: 0f 0b 68 f0 0c 48 80 c2 80 01 48 8b 54 24 08 48 89 54 24 10 RIP [] dx_probe+0x18b/0x320 RSP Yeah, I know it's tainted - just wanted to hear if anyone saw this one before. System seems to be fine otherwise, I'll run a fsck on the filesystem lateron. Jan -- Common sense is instinct, and enough of it is genius. -- Josh Billings - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
brand new lists in: radiology, surgery, orthapedics, cardiology, anesthesiology, pediatrics
7 new databases for the medical profession just released! --> All New American Nurses Database: Over 59,000 nurses complete with addresses, phone and fax numbers All data is in Excel format and sortable by 30 specialties. MSA and CMSA fields also included. **Special Price Until March 15 $299** --> All New Radiologist Database :34,763 records for the USA **Price Until March 15 $199** --> All New Database of Surgeons :39,517 records for the USA **Price Until March 15 $199** --> All New Orthapedics Database :24,145 records for the USA **Price Until March 15 $199** --> All New Database of Cardiologists:24,577 records for the USA **Price Until March 15 $199** --> All New Database of Anesthesiologists:38,155 records for the USA **Price Until March 15 $199** --> All New Pediatrics Database : 60,684 records for the USA **Price Until March 15 $249** For more information or to place an order please call 206-600-5313 or for faster service send an email to [EMAIL PROTECTED] Please accept our sincerest apologies if you did not request this email and rest assured that by sending us an email with "unlist" in the subject heading we will never contact you again. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 v2.6.21-rc3
(Dropped LKML, whoops.) On Wednesday 07 March 2007 04:59, you wrote: > We've finally hopefully started to put a dent in the regressions, > especially the suspend/resume problems introduced since 2.6.20. > > So 2.6.21-rc3 is out there now, and there's some hope that it will work > more widely than -rc1 and -rc2 did. Please do give it a good testing, and > update Adrian and the mailing list (and me) about any regressions > (hopefully many more of the "it's fixed now" than other kinds, but all > regressions are interesting). Robert and Jeff already know about these, but I thought I'd send out a reminder. ata2: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 0x500 next cpb count 0x0 next cpb idx 0x0 ata2: CPB 0: ctl_flags 0xd, resp_flags 0x1 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd 35/00:30:b5:c1:8f/00:01:01:00:00/e0 tag 0 cdb 0x0 data 155648 out res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft resetting port ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA They didn't happen (or didn't happen as frequently) in 2.6.20; it's a serious bug. Happened in -rc2 and -rc3. A patch from Robert reverting 721449bf0d51213fe3abf0ac3e3561ef9ea7827a seems to make them go away. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc][patch] futex: restartable futex_wait?
* Nick Piggin <[EMAIL PROTECTED]> wrote: > Hi Ingo, > > I'm seeing an LTP test fail for ltp test sigaction_16_24. Basically, > it tests whether the SA_RESTART flag works for the sem_wait operation. > > I see sem_wait is implemented with futex_wait, so I wonder whether we > can make it restartable? Am I going about it the right way? (Seems to > fix the testcase here). i think that's quite right. I'm wondering why this never came up before? But your fix is not complete i think: > + restart->arg2 = time; > + return -ERESTART_RESTARTBLOCK; > + } 'time' here is relative, so the restarted syscall will do a /full/ wait again. maybe we should rather convert futex timed-waits to hrtimers? Thomas? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: SATA resume slowness, e1000 MSI warning
Jeff Garzik <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> Until I get the best scenario I can come up with is a tg3 hardware bug >> that doesn't renable the pci-X capability after a restore of power state. > > > Speaking of tg3, make sure you are aware that the number of calls to > save-state > functions may not match the number of calls to the restore-state functions. > ISTR seeing some memleak bugs in PCI related to this. Thanks that looks like the problem, multiple calls to save before one call to restore when you have a pci-x capability would easily trigger this problem. I just surveyed a bunch of the pci_save_state and pci_restore_state users and this appears to be a common idiom not just a tg3 thing It looks like when code was added to save/restore the msi capability was added to pci_save/restore_state that an assumption was added that pci_save_state and pci_restore state were only used for suspend and only used in pairs. There is even a partial bug fix that removed the worst of the symptoms of that assumption from the msi code but failed to recognize the core problem. Now that we have code to work with pcie and pcix capabilities as well as msi this problem is much easier to hit. All of pci_save_state and pci_restore_state is going to have to be restructured to fix this, and it is late in the game. Ugh. Oh well, better to fix it now At least I get my answer about if what pci_save_state is doing is reasonable. It is not. pci_save_state no longer supports being used in conjunction with hardware reset and has become a suspend/resume specific function. Now I'm off to wite some patches to fix this. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 5/6] integrity: mtime patch for mmap files
* Mimi Zohar ([EMAIL PROTECTED]) wrote:
> This is a minimal subset of Peter Staubach's July patch, updated to
> apply to the latest kernel. The subset was chosen to demonstrate that
> mmaped files are hashed and hmac properly by EVM after being modified
> when a file's mtime is updated correctly.
Would make sense to Cc Peter on fsdevel on this.
> Index: linux-2.6.21-rc3-mm2/fs/inode.c
> ===
> --- linux-2.6.21-rc3-mm2.orig/fs/inode.c
> +++ linux-2.6.21-rc3-mm2/fs/inode.c
> @@ -1209,8 +1209,8 @@ void touch_atime(struct vfsmount *mnt, s
> EXPORT_SYMBOL(touch_atime);
>
> /**
> - * file_update_time- update mtime and ctime time
> - * @file: file accessed
> + * inode_update_time - update mtime and ctime time
> + * @inode: file accessed
> *
> * Update the mtime and ctime members of an inode and mark the inode
> * for writeback. Note that this function is meant exclusively for
> @@ -1220,9 +1220,8 @@ EXPORT_SYMBOL(touch_atime);
> * timestamps are handled by the server.
> */
>
> -void file_update_time(struct file *file)
> +void inode_update_time(struct inode *inode)
> {
> - struct inode *inode = file->f_path.dentry->d_inode;
> struct timespec now;
> int sync_it = 0;
>
> @@ -1246,7 +1245,7 @@ void file_update_time(struct file *file)
> mark_inode_dirty_sync(inode);
> }
>
> -EXPORT_SYMBOL(file_update_time);
> +EXPORT_SYMBOL(inode_update_time);
>
> int inode_needs_sync(struct inode *inode)
> {
> Index: linux-2.6.21-rc3-mm2/fs/fs-writeback.c
> ===
> --- linux-2.6.21-rc3-mm2.orig/fs/fs-writeback.c
> +++ linux-2.6.21-rc3-mm2/fs/fs-writeback.c
> @@ -167,6 +167,9 @@ __sync_single_inode(struct inode *inode,
>
> spin_unlock(&inode_lock);
>
> + if (test_and_clear_bit(AS_MCTIME, &mapping->flags))
> + inode_update_time(inode);
> +
> ret = do_writepages(mapping, wbc);
>
> /* Don't write the inode if only I_DIRTY_PAGES was set */
> Index: linux-2.6.21-rc3-mm2/fs/buffer.c
> ===
> --- linux-2.6.21-rc3-mm2.orig/fs/buffer.c
> +++ linux-2.6.21-rc3-mm2/fs/buffer.c
> @@ -734,8 +734,11 @@ int __set_page_dirty_buffers(struct page
> }
> spin_unlock(&mapping->private_lock);
>
> - if (TestSetPageDirty(page))
> + if (TestSetPageDirty(page)) {
> + if (page_mapped(page))
> + set_bit(AS_MCTIME, &mapping->flags);
> return 0;
> + }
>
> write_lock_irq(&mapping->tree_lock);
> if (page->mapping) {/* Race with truncate? */
> @@ -749,6 +752,8 @@ int __set_page_dirty_buffers(struct page
> }
> write_unlock_irq(&mapping->tree_lock);
> __mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
> + if (page_mapped(page))
> + set_bit(AS_MCTIME, &mapping->flags);
> return 1;
> }
> EXPORT_SYMBOL(__set_page_dirty_buffers);
> Index: linux-2.6.21-rc3-mm2/include/linux/fs.h
> ===
> --- linux-2.6.21-rc3-mm2.orig/include/linux/fs.h
> +++ linux-2.6.21-rc3-mm2/include/linux/fs.h
> @@ -1944,7 +1944,12 @@ extern int buffer_migrate_page(struct ad
> extern int inode_change_ok(struct inode *, struct iattr *);
> extern int __must_check inode_setattr(struct inode *, struct iattr *);
>
> -extern void file_update_time(struct file *file);
> +extern void inode_update_time(struct inode *);
> +
> +static inline void file_update_time(struct file *file)
> +{
> + inode_update_time(file->f_dentry->d_inode);
s/f_dentry/f_path.dentry/
> +}
>
> static inline ino_t parent_ino(struct dentry *dentry)
> {
> Index: linux-2.6.21-rc3-mm2/include/linux/pagemap.h
> ===
> --- linux-2.6.21-rc3-mm2.orig/include/linux/pagemap.h
> +++ linux-2.6.21-rc3-mm2/include/linux/pagemap.h
> @@ -17,8 +17,9 @@
> * Bits in mapping->flags. The lower __GFP_BITS_SHIFT bits are the page
> * allocation mode flags.
> */
> -#define AS_EIO (__GFP_BITS_SHIFT + 0) /* IO error on async
> write */
> +#define AS_EIO (__GFP_BITS_SHIFT + 0) /* IO error on async
> write */
> #define AS_ENOSPC(__GFP_BITS_SHIFT + 1) /* ENOSPC on async write */
> +#define AS_MCTIME(__GFP_BITS_SHIFT + 2) /* need m/ctime change */
>
> static inline void mapping_set_error(struct address_space *mapping, int
> error)
> {
> Index: linux-2.6.21-rc3-mm2/mm/page-writeback.c
> ===
> --- linux-2.6.21-rc3-mm2.orig/mm/page-writeback.c
> +++ linux-2.6.21-rc3-mm2/mm/page-writeback.c
> @@ -815,8 +815,10 @@ int __set_page_dirty_no_writeback(struct
> */
> int __set_page_dirty_nobuffers(struct page *page)
> {
> + struct address_space *mapping = page_mapping(pag
Re: [patch 2/5] signalfd v2 - signalfd core ...
On Thu, 8 Mar 2007, Michael K. Edwards wrote: > > Make it a netlink socket and fetch your structures using recvmsg(). > siginfo_t belongs in ancillary data. Gaah. That interface is horrible. > The UNIX philosophy is "everything's a file". The Berkeley philosophy > is "everything's a socket, except for files, which are feeble > mini-sockets". I'd go with the Berkeley crowd here. No, the berkeley crowd is totally out to lunch. I might agree with you *if* you could actually do "recvmsg()" on arbitrary file descriptors, but you cannot. We could fix that in Linux, of course, but the fact is, "recvmsg()" is *not* a superset of "read()". In general, it's a *subset*, exactly because very few file descriptors support it. So the normal way to read from a file descriptor (and the *only* way in any generic select loop) is to use "read()". That's the only thing that works for everything. And we shouldn't break that. The sad part is that there really is no reason why the BSD crowd couldn't have done recvmsg() as an "extended read with per-system call flags", which would have made things like O_NONBLOCK etc unnecessary, because you could do it just with MSG_DONTWAIT.. So anybody who would "go with the Berkeley crowd" really shows a lot of bad taste, I'm afraid. The Berkeley crowd really messed up here, and it's so long ago that I don't think there is any point in us trying to fix it any more. (But if somebody makes recvmgs a general VFS interface and makes it just work for everything, I'd probably take the patch as a cleanup. I really think it should have been a "struct file_operations" thing rather than being a socket-only thing.. But since you couldn't portably use it anyway, the thing is pretty moot) 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/
Possible "struct pid" leak from tty_io.c
Hi Eric, I'm trying to track down a kmemleak report (on an ARM platform) which seems to have appeared with commit ab521dc0f8e117fd808d3e425216864d60390500. As I'm not familiar with the TTY layer at all, is it possible that the above commit missed a put_pid() call on some path? The /sbin/init application calls sys_clone() a few times but only one leak is reported (see below). Looking at the reported pid object (at 0xc7c14500), count is 2 and nr is 296 but no process with pid 296 exists any more. unreferenced object 0xc7c14500 (size 36): comm "init", pid 245, jiffies 4294939289 backtrace: [] kmem_cache_alloc [] alloc_pid [] do_fork [] sys_clone [] ret_fast_syscall Thanks. -- Catalin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64 RESTORE_CONTEXT missing '\n'
On Wednesday 07 March 2007 21:45, Dave Jiang wrote: > > The RESTORE_CONTEXT macro is missing the '\n' at the end. It was removed in > the > previous patch that touched system.h. It causes compile failure if any > inline asm is added after the macro. Discovered this when playing with > kgdb. We went through this several times. kgdb has no business to poke into kernel private macros like this and it shouldn't do that. So fixing kgdb to not require touching the context switch is the right change. -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 2/5] signalfd v2 - signalfd core ...
On Thu, 8 Mar 2007, Davide Libenzi wrote: > > The reason for the special function, was not to provide a non-blocking > behaviour with zero timeout (that just a side effect), but to read the > siginfo. I was all about using read(2) (and v1 used it), but when you have > to transfer complex structures over it, it becomes hell. How do you > cleanly compat over a f_op->read callback for example? I agree that it gets a bit "interesting", and one option might be that the "read()" interface just gets the signal number and the minimal siginfo information, which is, after all, what 99% of all apps actually care about. But "siginfo_t" is really a *horrible* structure. Nobody sane should ever use siginfo_t, and the designer of that thing was so high on LSD that it's not even funny. Re-using fields in a union? Values that depend on other bits in the thing in random manners? In other words, I bet that we could just make it a *lot* better by making the read structure be: - 16 4-byte fields (fixed 64-byte packet), where each field is an uint32_t (we could even do it in network byte order if we care and if you want to just pipe the information from one machine to another, but that sounds a bit excessive ;) - Just put the fields people actually use at fixed offsets: si_signo, si_errno, si_pid, si_uid, si_band, si_fd. - that still leaves room for the other cases if anybody ever wants them (but I doubt it - things like si_addr are really only useful for synchronous signals that are actually done as *signals*, since you cannot defer a SIGBUS/SIGSEGV/SIGILL *anyway*). So I bet 99% of users actually just want si_signo, while some small subset might want the SIGCHLD info and some of the special cases (eg we migth want to add si_addr as a 64-bit thing just because the USB stack sends a SI_ASYNCIO thing for completed URB's, so a libusb might want it, but that's probably the only such user). And it would be *cleaner* than the mess that is siginfo_t.. (I realize that siginfo_t is ugly because it built up over time, using the same buffer for many different things. I'm just saying that we can probably do better by *not* using it, and just laying things out in a cleaner manner to begin with, which also solves any compatibility issues) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 1/6] integrity: new hooks
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > It's unfortunate, agreed, but > use of LSM as an integrity framework was also a no-go. > > Options? There's too much dup because stuff like above is just access control not integrity measurement. Need to break off the parts that really are different. But I don't have a great option offhand, I recognize the complication. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 6/6] integrity: TPM internal kernel interface
Other than the nits below, this looks like the right idea.
* Mimi Zohar ([EMAIL PROTECTED]) wrote:
> Index: linux-2.6.21-rc3-mm2/drivers/char/tpm/tpm.c
> ===
> --- linux-2.6.21-rc3-mm2.orig/drivers/char/tpm/tpm.c
> +++ linux-2.6.21-rc3-mm2/drivers/char/tpm/tpm.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (C) 2004 IBM Corporation
> + * Copyright (C) 2004,2007 IBM Corporation
> *
> * Authors:
> * Leendert van Doorn <[EMAIL PROTECTED]>
> @@ -25,6 +25,12 @@
>
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> #include "tpm.h"
>
> enum tpm_const {
> @@ -47,6 +53,8 @@ enum tpm_duration {
> static LIST_HEAD(tpm_chip_list);
> static DEFINE_SPINLOCK(driver_lock);
> static DECLARE_BITMAP(dev_mask, TPM_NUM_DEVICES);
> +#define TPM_CHIP_NUM_MASK 0x
> +#define TPM_CHIP_TYPE_SHIFT 16
>
> /*
> * Array with one entry per ordinal defining the maximum amount
> @@ -363,7 +371,7 @@ EXPORT_SYMBOL_GPL(tpm_calc_ordinal_durat
> /*
> * Internal kernel interface to transmit TPM commands
> */
> -static ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf,
> +ssize_t tpm_transmit(struct tpm_chip *chip, char *buf,
> size_t bufsiz)
> {
> ssize_t rc;
> @@ -422,6 +430,7 @@ out:
> up(&chip->tpm_mutex);
> return rc;
> }
> +EXPORT_SYMBOL_GPL(tpm_transmit);
>
> #define TPM_DIGEST_SIZE 20
> #define TPM_ERROR_SIZE 10
> @@ -665,6 +674,7 @@ ssize_t tpm_show_temp_deactivated(struct
> }
> EXPORT_SYMBOL_GPL(tpm_show_temp_deactivated);
>
> +#define READ_PCR_RESULT_SIZE 30
Is this the same value that's used as a magic number in places
like tpm_gen_interrupt and tpm_show_pcrs? Be nice to convert
that as well to eliminate some magic (my quick review of TPM
specs came up empty, so I could be off the mark).
> static const u8 pcrread[] = {
> 0, 193, /* TPM_TAG_RQU_COMMAND */
> 0, 0, 0, 14,/* length */
> @@ -713,6 +723,93 @@ out:
> }
> EXPORT_SYMBOL_GPL(tpm_show_pcrs);
>
> +static struct tpm_chip* tpm_chip_lookup(int chip_num, int chip_typ)
> +{
> +struct tpm_chip *pos;
> +
> +spin_lock(&driver_lock);
> +list_for_each_entry(pos, &tpm_chip_list, list)
> +if ((chip_num == TPM_ANY_NUM ||
> +pos->dev_num == chip_num ) &&
> +(chip_typ == TPM_ANY_TYPE)){
> +spin_unlock(&driver_lock);
> +return pos;
> +}
> +
> +spin_unlock(&driver_lock);
I guess this is OK, since TPM chips aren't hotpluggable, but
typically this type of interface would refcount the device
it finds before returning it to caller.
> +return NULL;
> +}
> +
> +/*
> + * Return 0 on success. On error pass along error code.
> + * chip_id Upper 2 bytes equal ANY, HW_ONLY or SW_ONLY
> + * Lower 2 bytes equal tpm idx # or AN&
> + * res_buf must fit a TPM_PCR (20 bytes) or NULL if you don't care
> + */
Proper kerneldoc for exported functions please.
> +int tpm_pcr_read( u32 chip_id, int pcr_idx, u8* res_buf, int res_buf_size )
> +{
> +u8 data[READ_PCR_RESULT_SIZE];
> +int rc;
> +__be32 index;
> +int chip_num = chip_id & TPM_CHIP_NUM_MASK;
> +struct tpm_chip* chip;
> +
> +if ( res_buf && res_buf_size < TPM_DIGEST_SIZE )
> +return -ENOSPC;
CodingStyle [extra spaces around '(' and ')'], if (foo)...
Tabs not spaces.
> +
> +if ( (chip = tpm_chip_lookup( chip_num,
> +chip_id >> TPM_CHIP_TYPE_SHIFT ) ) == NULL )
chip = tpm_chip_lookup(chip_num, chip_id >> TPM_CHIP_TYPE_SHIFT);
if (!chip)
> +return -ENODEV;
> +
> +memcpy(data, pcrread, sizeof(pcrread));
> +index = cpu_to_be32(pcr_idx);
> +memcpy(data + 10, &index, 4);
> +if ((rc = tpm_transmit(chip, data, sizeof(data))) > 0 )
> +rc = be32_to_cpu(*((u32*)(data+6)));
> +
Shouldn't this be a helper? (there's other pcr reads going on internally)
And similar CodingStyle comment...
> +if ( rc == 0 && res_buf )
> +memcpy(res_buf, data+10, TPM_DIGEST_SIZE);
> +
> +return rc;
> +
> +}
> +EXPORT_SYMBOL_GPL(tpm_pcr_read);
> +
> +#define EXTEND_PCR_SIZE 34
> +static const u8 pcrextend[] = {
> +0, 193, /* TPM_TAG_RQU_COMMAND */
> +0, 0, 0, 34,/* length */
> +0, 0, 0, 20,/* TPM_ORD_Extend */
> +0, 0, 0, 0 /* PCR index */
> +};
> +
> +/*
> + * Return 0 on success. On error pass along error code.
> + * chip_id Upper 2 bytes equal ANY, HW_ONLY or SW_ONLY
> + * Lower 2 bytes equal tpm idx # or ANY
> + */
> +int tpm_pcr_extend(u32 chip_id, int pcr_idx, const u8* hash)
> +{
> +u8 data[EXTEND_PCR_SIZE];
> +int rc;
> +__be32 in
Re: [PATCH] chaostables
Jan Engelhardt wrote: >>>Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c >>>+/* Equivalent to: >>>+ * -A chaos -m statistic --mode random --probability \ >>>+ * $reject_percentage -j REJECT --reject-with host-unreach; >>>+ * -A chaos -m statistic --mode random --probability \ >>>+ * $delude_percentage -j DELUDE; >>>+ * -A chaos -j DROP; >>>+ */ >> >>What does this do that can't be done by simply adding those individual >>rules? > > > It "wraps it all up", reducing the overall number of rules and user > chains required in the filtering tables to implement the wanted logic. > Reducing the number of filtering rules also reduces the time process a > packet. These two are, in my opinion, a good thing. By that argument we could just codify every ruleset and put it in the kernel. Its three simple rules. There is no chance I'm going to take this part. > Take xt_portscan as an example, which would require a minimum of 23 > filtering rules (which cannot reproduce the module's action in its > fullest). 23 rules means we will be looping a bit in ipt_do_table() for > a single packet, repeatedly checking for "-p tcp", i.e. calling into > xt_tcpudp, checking for port ranges and perhaps other TCP fields that > are never examined in xt_portscan. I'm guessing xt_portscan tries to detect and match on portscans, but its not obvious why it looks at and changes skb->mark and nfct->ctmark, so I suggest you start by explaining what it really does. >>>+++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c >> >>Looks like a copy of the REJECT target. What does it do, >>why can't you use REJECT? > > > Looking only at TCP, > REJECT sends a RST for any packet (if requested), or ICMP otherwise. > DELUDE sends a SYN-ACK on SYN, otherwise RST. > (And TARPIT, for reference, keeps the connection open anytime. Its code > is also quite a replication of REJECT.) > > If you think it is better to merge the respond-with-SYNACK into REJECT > rather than having DELUDE, say so. I'd rather not add hacks to mildly annoy people anywhere. >>We already have the psd match for years, but decided against merging it. > > > On what basis? As far as I flew over psd's code, it uses a heuristic > like "how often did that client recently connect" for match decision. > (P2P clients randomly port knocking, anyone?) I would not think of that > as a reliable way to tell portscans either. However, half-open TCP > connect for example is a more clear action to define a portscan. The question is what we gain by being able to detect portscans. So far my opinion is thats its close to nothing. Besides that, it should be possible to do this by using the recent match. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: irq nobody cared issue on 2.6.2x
On Wednesday 07 March 2007, Linus Torvalds wrote: > > On Wed, 7 Mar 2007, Mws wrote: > > > > if you would be so kind to provide me some infos, > > > > how i would be able to track the problem down _and_ maybe how to fix it. > > The first step is to figure out as exactly as possible _when_ it started > happening. > > > please find two snippets of dmesg after booting 2.6.21-rc3-git > > (2.6.20-1 has got the same results) > > So is 2.6.19 good? 2.6.20-rc1? -rc2? went down to 2.6.17 - earlier is lacking due to correctly booting my machine. > If you're a git user (or even just marginally interested in learning), the > best thing to do is to find some good kernel (the more recent, the better, > but the keyword is *some* kernel that works well), and a bad kernel (the > older the better, just to avoid unnecessary work, but again, you can just > take the most recent too), and then just use "git bisect". > > If you bisect it down to one particular commit, that will help us a lot, > but even if you only bisect it down by booting a handful of kernels (say, > 5-6), it will already have cut things down a lot, and probably more easily > and efficiently than if you just downloaded daily snapshots and tried to > narrow it down that way. > > Linus i started to bring in a load of printk's into v4l dvb repository to find out what exactly is causing the interrupt to appear and why it is not handled. the bug is reproducible by insmod/rmmod dvb_ttpci over and over. yesterday late night i tried a bit too much and my machine freezed as a whole. even kernel sysrq didn't work anymore. i found some point, that after fireware load the interrupt is fired again. will check if there is a solution to create a workaround and try to fix it afterwards. it does NOT appear on a different computer same card. i think it is a problem in combination chipset - card - bios dunno by now, but will find out. thanks for your information, linus. marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PAGE_SIZE Availability Inconsistency
On Thu, Mar 08, 2007 at 09:05:48AM -0800, H. Peter Anvin wrote: > Christoph Hellwig wrote: > >No, no no. We should never export PAGE_SIZE. We might export NBPG > >as deprecated symbol for gdb if it really needs it, but that should > >happen only on a.out systems, and it it should be a true constant, > >not depending on PAGE_SIZE. > > > >I've Cc'ed the gdb list on whether they have any comments on this > >issue. > > By the way, it's a massive snafu that the swap area magic number is > dependent on PAGE_SIZE. There is absolutely no good reason for that. Yeah, now that you mention it I remember having problems with that in the past. We should probably create a new swap format that avoids this problem. I'll put it on my ever growing todo list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add xfrm policy change auditing to pfkey_spdget
On Thu, 8 Mar 2007, Eric Paris wrote: > which didn't have my fix up because i didn't commit it to my local > branch. Is there a better way to get a diff between my miller tree and > 'everything in the branch I have checked out even if it is not > committed'? I'd suggest you commit all your changes in local branches, then export them as emails via git-format-patch for posting. Something like: davem-upstream [1] +- for-davem [2] +- for-davem-prep [3] Do all of your work in [3], so you can manage the queue of patches there before merging/applying them into [2] as a final patch series. So, if one of the commits in [3] needs fixing, you can, for example, export commits up to that with git-format-patch, git-reset --hard to the broken commit, fix, compile, test then reapply the exported commits. Then, once it's all ready, merge into [2] (or export & apply to avoid merge commits). This is just one possible workflow. There are probably several better. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] chaostables
> Also note that the word 'chaostables' does not even appear in the patch,
> though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we
> can safely assume that CHAOS does what it says - make fun of nmap.
"entropy" ?
"randomness"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PAGE_SIZE Availability Inconsistency
Christoph Hellwig wrote: No, no no. We should never export PAGE_SIZE. We might export NBPG as deprecated symbol for gdb if it really needs it, but that should happen only on a.out systems, and it it should be a true constant, not depending on PAGE_SIZE. I've Cc'ed the gdb list on whether they have any comments on this issue. By the way, it's a massive snafu that the swap area magic number is dependent on PAGE_SIZE. There is absolutely no good reason for that. -hp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 2/6] integrity: fs hook placement
Quoting Chris Wright ([EMAIL PROTECTED]):
> * Mimi Zohar ([EMAIL PROTECTED]) wrote:
> > + integrity_d_instantiate(entry, inode);
> > security_d_instantiate(entry, inode);
>
> > + integrity_d_instantiate(entry, inode);
> > security_d_instantiate(entry, inode);
>
> > spin_unlock(&dcache_lock);
> > + integrity_d_instantiate(new, inode);
> > security_d_instantiate(new, inode);
> > d_rehash(dentry);
>
> > d_move(new, dentry);
> > + integrity_d_instantiate(dentry, inode);
> > security_d_instantiate(dentry, inode);
> > d_rehash(dentry);
>
> > if (actual == dentry) {
> > + integrity_d_instantiate(dentry, inode);
> > security_d_instantiate(dentry, inode);
>
>
> > file->f_op->release(inode, file);
> > security_file_free(file);
> > + integrity_file_free(file);
>
>
> > security_file_free(file);
> > + integrity_file_free(file);
>
>
> > if (security_inode_alloc(inode)) {
> ...
> > + if (integrity_inode_alloc(inode)) {
> > + if (inode->i_sb->s_op->destroy_inode)
> > + inode->i_sb->s_op->destroy_inode(inode);
>
> > security_inode_free(inode);
> > + integrity_inode_free(inode);
>
> > error = security_inode_setxattr(dentry, name, value, size, flags);
> > if (error)
> > goto out;
> > +
> > + error = integrity_inode_setxattr(dentry, name, value, size, flags);
>
> > fsnotify_xattr(dentry);
> > + integrity_inode_post_setxattr(dentry, name);
> > security_inode_post_setxattr(dentry, name, value,
>
> I know there's some slightly different goals, but this just doesn't make
> sense. Need to get back to defining and expressing just the differences.
Are you objecting only to the duplication at the callsites, so that an
fsnotify-type of consolidation of security and integrity hooks would be
ok? Or are you complaining that the security_inode_setxattr and
integrity_inode_setxattr hooks are too similar anyway, and integrity
modules should just use some lsm hooks for anything which will be
authoritative?
(I could see an argument that integirty subsystem should be purely for
measuring and hence its hooks should never return a value. Only hitch
there is that if integrity subsystem hits ENOMEM it should be able to
refuse the action...)
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded
Takashi Iwai wrote: At Thu, 8 Mar 2007 17:52:43 +0100, Michal Piotrowski wrote: On 08/03/07, Takashi Iwai <[EMAIL PROTECTED]> wrote: At Thu, 08 Mar 2007 16:42:26 +0100, Michal Piotrowski wrote: Also, it'd be helpful if you compare /proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the patch. This reveals which register bits differ actually. a2.txt is form 2.6.21-rc3 witchout 831466f4ad2b5fe23dff77edbe6a7c244435e973 diff -uprN a2.txt /proc/asound/card0/codec97#0/ac97#0-0+regs --- a2.txt 2007-03-08 16:36:47.0 +0100 +++ /proc/asound/card0/codec97#0/ac97#0-0+regs 2007-03-08 16:36:49.447083597 +0100 @@ -56,8 +56,8 @@ 0:6e = 0:70 = 0:72 = 0004 -0:74 = 1001 -0:76 = 64a4 +0:74 = 1201 +0:76 = 7ca4 0:78 = 000c 0:7a = 0:7c = 4144 OK, some wrong bits there. Could you try the patch below? Problem fixed. Thanks! (speaker-test -c6 -Dplug:surround51 is still broken) Hm, how about turning off "Spread Front To..." control and run speaker-test? Takashi Michal and Takashi, I've been researching your issue this morning. I just noticed that your exchange had ensued. I configured my AD1986-based system as closely as I could to match your AD1985 mixer settings. In doing so, I experienced results similar to what I'm assuming you described: Only front channel sound came out of the surround and c/lfe jacks. Here is what I had to change to get the appropriate multichannel sound: 1) The command "speaker-test -c6" does not work on my system. I have to use "speaker-test -Dsurround51 -c6" (Perhaps this is related to running an old version of speaker-test.) 2) I disabled "Spread Front to Surround and Center/LFE" The explanation for 2) is this: There can be only one source for each of the Surround and Center/LFE jacks active at one time. When "Spread Front to Surround and Center/LFE" is disabled, the surround channels go to the the jacks; when this control is enabled, ONLY the front channels go to the surround and c/lfe jacks. Considering the register values Michal provided and Takashi's patch: The logic of the code is as follows: (Slightly simplifying,) functions is_shared_linein() and is_shared_micin() return TRUE if the mixer is configured for shared jacks AND NOT for 6 channel mode. In this case it is appropriate to set these bits (LODIS and CLDIS). Please double-check your mixer settings. I added a byte to a structure, so the mixer settings can get messed up switching between alsa-kernel versions. I don't understand why the other bit (OMS, 0x74 bit D9) is set. This may have been an oversight on my part. I am modifying alsa-kernel to run as an AD1985 on my system, to try to check these bits. Randy Cushman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded
On 08/03/07, Takashi Iwai <[EMAIL PROTECTED]> wrote: At Thu, 8 Mar 2007 17:52:43 +0100, Michal Piotrowski wrote: > > On 08/03/07, Takashi Iwai <[EMAIL PROTECTED]> wrote: > > At Thu, 08 Mar 2007 16:42:26 +0100, > > Michal Piotrowski wrote: > > > > > > > Also, it'd be helpful if you compare > > > > /proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the > > > > patch. This reveals which register bits differ actually. > > > > > > a2.txt is form 2.6.21-rc3 witchout 831466f4ad2b5fe23dff77edbe6a7c244435e973 > > > > > > diff -uprN a2.txt /proc/asound/card0/codec97#0/ac97#0-0+regs > > > --- a2.txt 2007-03-08 16:36:47.0 +0100 > > > +++ /proc/asound/card0/codec97#0/ac97#0-0+regs 2007-03-08 16:36:49.447083597 +0100 > > > @@ -56,8 +56,8 @@ > > > 0:6e = > > > 0:70 = > > > 0:72 = 0004 > > > -0:74 = 1001 > > > -0:76 = 64a4 > > > +0:74 = 1201 > > > +0:76 = 7ca4 > > > 0:78 = 000c > > > 0:7a = > > > 0:7c = 4144 > > > > OK, some wrong bits there. Could you try the patch below? > > Problem fixed. Thanks! > > (speaker-test -c6 -Dplug:surround51 is still broken) Hm, how about turning off "Spread Front To..." control and run speaker-test? Now I've got: rear left as center rear right as LFE :) Takashi Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/6] integrity: new hooks
Quoting Chris Wright ([EMAIL PROTECTED]):
> * Mimi Zohar ([EMAIL PROTECTED]) wrote:
> > +static int dummy_inode_setxattr(struct dentry *dentry, char *name, void
> > *value,
> > + size_t size, int flags)
> > +{
> > + if (!strncmp(name, XATTR_SECURITY_PREFIX,
> > +sizeof(XATTR_SECURITY_PREFIX) - 1) &&
> > + !capable(CAP_SYS_ADMIN))
> > + return -EPERM;
> > + return 0;
> > +}
>
> Hold on, what is all this? Duplication of all of this code is a no go.
It's unfortunate, agreed, but
use of LSM as an integrity framework was also a no-go.
Options?
thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Request change in behaviour of capability inheritance.
I was reading the capabilities(7) man page. I agree with you about the language. What I am requesting is that for any file without extra attributes, the inheritable and effective set should be full. Ramon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] epoll use a single inode ...
On Thu, 08 Mar 2007 08:24:04 +0100, Eric Dumazet said:
>
> But what is the cost of the conditional branch you added in prefetch(x) ?
>
> if (!x) return;
>
> (correctly predicted or not, but do powerPC have a BTB ?)
>
> About the NULL 'potential problem', maybe we could use a dummy nil (but
> mapped) object, and use its address in lists, ie compare for &nil instead of
> NULL. This would avoid :
>
> - The conditional test in some prefetch() implementations
> - The potential TLB problem with the NULL value.
You avoid those two, but add the very high likelyhood that a statement of the
form 'if (!x) {}' will creep back in and bug out. I doubt that changing
the form of a basic C idiom to save a few cycles is worth it, especially when
the (!x) form can be tested without a memory fetch, but (x != nil) may require
fetching 'nil' (remember - the x86 is a very popular chipset, but register
starved - if the loop is any size at all, 'nil' may require a reload each
time around, costing you the win you thought you had
pgpWRgqXbzEAw.pgp
Description: PGP signature
[PATCH] VFS : Delay the dentry name generation on sockets and pipes.
Hi Andrew
Could you please put this final version in mm for testing ?
Thank's to all contributors.
[PATCH] VFS : Delay the dentry name generation on sockets and pipes.
1) Introduces a new method in 'struct dentry_operations'. This method called
d_dname() might be called from d_path() to build a pathname
for special filesystems. It is called without locks.
Future patches (if we succeed in having one common dentry for all
pipes/sockets) may need to change prototype of this method, but we now use :
char *d_dname(struct dentry *dentry, char *buffer, int buflen);
2) Use this new method for sockets : No more sprintf() at socket creation.
This is delayed up to the moment someone does an access to /proc/pid/fd/...
3) Use this new method for pipes : No more sprintf() at pipe creation. This is
delayed up to the moment someone does an access to /proc/pid/fd/...
A benchmark consisting of 1.000.000 calls to pipe()/close()/close() gives a
*nice* speedup on my Pentium(M) 1.6 Ghz :
3.090 s instead of 3.450 s
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
Acked-by: Christoph Hellwig <[EMAIL PROTECTED]>
Acked-by: Linus Torvalds <[EMAIL PROTECTED]>
Documentation/filesystems/Locking |2 ++
Documentation/filesystems/vfs.txt | 12 +++-
fs/dcache.c | 10 ++
fs/pipe.c | 15 +--
include/linux/dcache.h|1 +
net/socket.c | 17 ++---
6 files changed, 43 insertions(+), 14 deletions(-)
--- linux-2.6.21-rc3/include/linux/dcache.h 2007-03-07 17:23:55.0
+0100
+++ linux-2.6.21-rc3-ed/include/linux/dcache.h 2007-03-08 11:57:41.0
+0100
@@ -133,6 +133,7 @@ struct dentry_operations {
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
+ char *(*d_dname)(struct dentry *, char *, int);
};
/* the dentry parameter passed to d_hash and d_compare is the parent
--- linux-2.6.21-rc3/Documentation/filesystems/vfs.txt 2007-03-08
10:14:38.0 +0100
+++ linux-2.6.21-rc3-ed/Documentation/filesystems/vfs.txt 2007-03-08
12:08:56.0 +0100
@@ -827,7 +827,7 @@ This describes how a filesystem can over
operations. Dentries and the dcache are the domain of the VFS and the
individual filesystem implementations. Device drivers have no business
here. These methods may be set to NULL, as they are either optional or
-the VFS uses a default. As of kernel 2.6.13, the following members are
+the VFS uses a default. As of kernel 2.6.22, the following members are
defined:
struct dentry_operations {
@@ -837,6 +837,7 @@ struct dentry_operations {
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
+ char *(*d_dname)(struct dentry *, char *, int);
};
d_revalidate: called when the VFS needs to revalidate a dentry. This
@@ -859,6 +860,15 @@ struct dentry_operations {
VFS calls iput(). If you define this method, you must call
iput() yourself
+ d_dname: called when the pathname of a dentry should be generated.
+ Usefull for some pseudo filesystems (sockfs, pipefs, ...) to delay
+ pathname generation. (Instead of doing it when dentry is created,
+ its done only when the path is needed.). Real filesystems probably
+ dont want to use it, because their dentries are present in global
+ dcache hash, so their hash should be an invariant. As no lock is
+ held, d_dname() should not try to modify the dentry itself, unless
+ appropriate SMP safety is used.
+
Each dentry has a pointer to its parent dentry, as well as a hash list
of child dentries. Child dentries are basically like files in a
directory.
--- linux-2.6.21-rc3/Documentation/filesystems/Locking 2007-03-08
10:29:04.0 +0100
+++ linux-2.6.21-rc3-ed/Documentation/filesystems/Locking 2007-03-08
12:08:56.0 +0100
@@ -15,6 +15,7 @@ prototypes:
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
+ char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
locking rules:
none have BKL
@@ -25,6 +26,7 @@ d_compare:no yes no
no
d_delete: yes no yes no
d_release: no no no yes
d_iput:no no no yes
+d_dname: no no no no
--- inode_operations ---
prototypes:
--- linux-2.6.21-rc3/fs/dcache.c2007-03-07 17:23:55.0 +0100
+++ linux-2.6.21-rc3-ed/fs/dcache.c 2007-03-08 17:47:04.0 +0100
@@ -1823,6 +1823,16 @@ char * d_path(struct dentry *dentry
Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded
At Thu, 8 Mar 2007 17:52:43 +0100, Michal Piotrowski wrote: > > On 08/03/07, Takashi Iwai <[EMAIL PROTECTED]> wrote: > > At Thu, 08 Mar 2007 16:42:26 +0100, > > Michal Piotrowski wrote: > > > > > > > Also, it'd be helpful if you compare > > > > /proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the > > > > patch. This reveals which register bits differ actually. > > > > > > a2.txt is form 2.6.21-rc3 witchout > > > 831466f4ad2b5fe23dff77edbe6a7c244435e973 > > > > > > diff -uprN a2.txt /proc/asound/card0/codec97#0/ac97#0-0+regs > > > --- a2.txt 2007-03-08 16:36:47.0 +0100 > > > +++ /proc/asound/card0/codec97#0/ac97#0-0+regs 2007-03-08 > > > 16:36:49.447083597 +0100 > > > @@ -56,8 +56,8 @@ > > > 0:6e = > > > 0:70 = > > > 0:72 = 0004 > > > -0:74 = 1001 > > > -0:76 = 64a4 > > > +0:74 = 1201 > > > +0:76 = 7ca4 > > > 0:78 = 000c > > > 0:7a = > > > 0:7c = 4144 > > > > OK, some wrong bits there. Could you try the patch below? > > Problem fixed. Thanks! > > (speaker-test -c6 -Dplug:surround51 is still broken) Hm, how about turning off "Spread Front To..." control and run speaker-test? Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded
On 08/03/07, Takashi Iwai <[EMAIL PROTECTED]> wrote: At Thu, 08 Mar 2007 16:42:26 +0100, Michal Piotrowski wrote: > > > Also, it'd be helpful if you compare > > /proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the > > patch. This reveals which register bits differ actually. > > a2.txt is form 2.6.21-rc3 witchout 831466f4ad2b5fe23dff77edbe6a7c244435e973 > > diff -uprN a2.txt /proc/asound/card0/codec97#0/ac97#0-0+regs > --- a2.txt 2007-03-08 16:36:47.0 +0100 > +++ /proc/asound/card0/codec97#0/ac97#0-0+regs 2007-03-08 16:36:49.447083597 +0100 > @@ -56,8 +56,8 @@ > 0:6e = > 0:70 = > 0:72 = 0004 > -0:74 = 1001 > -0:76 = 64a4 > +0:74 = 1201 > +0:76 = 7ca4 > 0:78 = 000c > 0:7a = > 0:7c = 4144 OK, some wrong bits there. Could you try the patch below? Problem fixed. Thanks! (speaker-test -c6 -Dplug:surround51 is still broken) Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: should RTS init in serial core be tied to CRTSCTS
Carl-Daniel Hailfinger <[EMAIL PROTECTED]> writes: > Unless you want two machines to monitor each other via serial console and > each of them has only one serial port. It's not perfect, but it works well > enough despite all claims to the contrary. Sure, if you don't need "input" (only "console logger" function and not "initial input/output terminal"). It has nothing to do with the RTS "problem", though. BTW: reasonably working, standard-compliant USB-RS232 converters cost $15 or so. Unfortunately not that all machines have USB ports. I agree with Russell - mixing kernel console and application's port is asking for trouble. OTOH I wonder what does the device in question require WRT the serial port and WRT RTS line in particular. I know there are some half-duplex converters which drive RTS only while sending and which require CTS to send. They are perhaps a bit broken and require some CSMA-alike retransmissions etc. I don't know if one can expect RTS to stay low all the time. Even a simple /sbin/setserial from /etc/rc.* would drive it high for a moment. I'm afraid the only way which makes sense may be using a customized plug. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4
On Thu, 8 Mar 2007, Mel Gorman wrote: > On x86_64, it completed successfully and looked reliable. There was a 5% > performance loss on kernbench and aim9 figures were way down. However, with > slub_debug enabled, I would expect that so it's not a fair comparison > performance wise. I'll rerun the tests without debug and see what it looks > like if you're interested and do not think it's too early to worry about > performance instead of clarity. This is what I have for bl6-13 (machine > appears on test.kernel.org so additional details are there). No its good to start worrying about performance now. There are still some performance issues to be ironed out in particular on NUMA. I am not sure f.e. how the reduction of partial lists affect performance. > IA64 (machine not visible on TKO) curiously did not exhibit the same problems > on kernbench for Total CPU time which is very unexpected but you can see the > System CPU times. The AIM9 figures were a bit of an upset but again, I blame > slub_debug being enabled This was a single node box? Note that the 16kb page size has a major impact on SLUB performance. On IA64 slub will use only 1/4th the locking overhead as on 4kb platforms. > (as an aside, the succes rates for high-order allocations are lower with SLUB. > Again, I blame slub_debug. I know that enabling SLAB_DEBUG has similar effects > because of red-zoning and the like) We have some additional patches here that reduce the max order for some allocs. I believe the task_struct gets to be an order 2 alloc with V4, > Now, the bad news. This exploded on ppc64. It started going wrong early in the > boot process and got worse. I haven't looked closely as to why yet as there is > other stuff on my plate but I've included a console log that might be some use > to you. If you think you have a fix for it, feel free to send it on and I'll > give it a test. Hmmm... Looks like something is zapping an object. Try to rerun with a kernel compiled with CONFIG_SLAB_DEBUG. I would expect similar results. > Brought up 4 CPUs > Node 0 CPUs: 0-3 > mm/memory.c:111: bad pud c50e4480. > could not vmalloc 20971520 bytes for cache! Hmmm... a bad pud? I need to look at how the puds are managed on power. > migration_cost=0,1000 > *** SLUB: Redzone Inactive check fails in [EMAIL PROTECTED] Slab An object was overwritten with zeros after it was freed. > RTAS daemon started > RTAS: event: 1, Type: Platform Error, Severity: 2 > audit: initializing netlink socket (disabled) > audit(1173335571.256:1): initialized > Total HugeTLB memory allocated, 0 > VFS: Disk quotas dquot_6.5.1 > Dquot-cache hash table entries: 512 (order 0, 4096 bytes) > JFS: nTxBlock = 8192, nTxLock = 65536 > SELinux: Registering netfilter hooks > io scheduler noop registered > io scheduler anticipatory registered (default) > io scheduler deadline registered > io scheduler cfq registered > pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 > rpaphp: Slot [:00:02.2](PCI location=U7879.001.DQD0T7T-P1-C4) registered > vio_register_driver: driver hvc_console registering > [ cut here ] > Badness at mm/slub.c:1701 Someone did a kmalloc(0, ...). Zero sized allocation are not flagged by SLAB but SLUB does. > Call Trace: > [C506B730] [C0011188] .show_stack+0x6c/0x1a0 (unreliable) > [C506B7D0] [C01EE9F4] .report_bug+0x94/0xe8 > [C506B860] [C038C85C] .program_check_exception+0x16c/0x5f4 > [C506B930] [C00046F4] program_check_common+0xf4/0x100 > --- Exception: 700 at .get_slab+0xbc/0x18c > LR = .__kmalloc+0x28/0x104 > [C506BC20] [C506BCC0] 0xc506bcc0 (unreliable) > [C506BCD0] [C00CE2EC] .__kmalloc+0x28/0x104 > [C506BD60] [C022E724] .tty_register_driver+0x5c/0x23c > [C506BE10] [C0477910] .hvsi_init+0x154/0x1b4 > [C506BEC0] [C0451B7C] .init+0x1c4/0x2f8 > [C506BF90] [C00275D0] .kernel_thread+0x4c/0x68 > mm/memory.c:111: bad pud c5762900. > mm/memory.c:111: bad pud c5762480. > [ cut here ] > kernel BUG at mm/mmap.c:1999! More page table trouble. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PAGE_SIZE Availability Inconsistency
On Thu, Mar 08, 2007 at 04:08:52PM +, Christoph Hellwig wrote: > No, no no. We should never export PAGE_SIZE. We might export NBPG > as deprecated symbol for gdb if it really needs it, but that should > happen only on a.out systems, and it it should be a true constant, > not depending on PAGE_SIZE. > > I've Cc'ed the gdb list on whether they have any comments on this > issue. Sounds reasonable. I do not believe that GDB has any dependence on PAGE_SIZE; bfd (i.e. both gdb and binutils) use NBPG on a large number of systems. Looks like i386, alpha, m68k, s390, vax - but don't quote me on that, I had to guess from the configure script. -- Daniel Jacobowitz CodeSourcery - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
swsusp: platform notifications not properly undone in case of error
Hi! Using IPI No-Shortcut mode swsusp: Resume From Partition /dev/sda1 PM: Checking swsusp image. swsusp: Signature found, resuming PM: Preparing processes for restore. Stopping tasks ... done. PM: Reading swsusp image. Loading image data pages (125285 pages) ... <3>swsusp: Resume mismatch: version Read 501140 kbytes in 0.01 seconds (50114.00 MB/s) swsusp: Error -1 resuming PM: Restore failed, recovering. Restarting tasks ... done. PM: Resume from disk failed. md: Autodetecting RAID arrays. ...and machine boots, but moon icon keeps blinking. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] add for_each_substring() and match_substring()
On Tue, Mar 06, 2007 at 08:19:23PM +0100, Martin Peschke wrote:
> +char *match_to(const char *cs, const char *ct)
> +{
> + char *delim = strpbrk(cs, ct);
> + if (delim)
> + return delim;
> + else if (*cs != '\0')
> + return (char *)(cs + strlen(cs));
This disallows the use of match_to with a real constant char array,
please remove the const from the prototyp.
Bastian
--
"Get back to your stations!"
"We're beaming down to the planet, sir."
-- Kirk and Mr. Leslie, "This Side of Paradise",
stardate 3417.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 2/6] integrity: fs hook placement
* Mimi Zohar ([EMAIL PROTECTED]) wrote:
> + integrity_d_instantiate(entry, inode);
> security_d_instantiate(entry, inode);
> + integrity_d_instantiate(entry, inode);
> security_d_instantiate(entry, inode);
> spin_unlock(&dcache_lock);
> + integrity_d_instantiate(new, inode);
> security_d_instantiate(new, inode);
> d_rehash(dentry);
> d_move(new, dentry);
> + integrity_d_instantiate(dentry, inode);
> security_d_instantiate(dentry, inode);
> d_rehash(dentry);
> if (actual == dentry) {
> + integrity_d_instantiate(dentry, inode);
> security_d_instantiate(dentry, inode);
> file->f_op->release(inode, file);
> security_file_free(file);
> + integrity_file_free(file);
> security_file_free(file);
> + integrity_file_free(file);
> if (security_inode_alloc(inode)) {
...
> + if (integrity_inode_alloc(inode)) {
> + if (inode->i_sb->s_op->destroy_inode)
> + inode->i_sb->s_op->destroy_inode(inode);
> security_inode_free(inode);
> + integrity_inode_free(inode);
> error = security_inode_setxattr(dentry, name, value, size, flags);
> if (error)
> goto out;
> +
> + error = integrity_inode_setxattr(dentry, name, value, size, flags);
> fsnotify_xattr(dentry);
> + integrity_inode_post_setxattr(dentry, name);
> security_inode_post_setxattr(dentry, name, value,
I know there's some slightly different goals, but this just doesn't make
sense. Need to get back to defining and expressing just the differences.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] chaostables
(I suspect a mailserver issue on my side, since I did not receive the
replies from Alan or Patrick. But lkml.org has them, so I will be
replying to both them there.)
On Mar 8 2007 09:55, James Morris wrote:
>On Thu, 8 Mar 2007, Alan Cox wrote:
>
>> Any chance of tweaking the name - it's just there is/was a chaosnet
>> protocol/network system and you don't want people to assume that
>> since its a chaosfilter its for chaosnet ?
>
>That's exactly what I thought it was from the subject line.
Suggest something. (And then convince everyone who already set
chaostables in stone to use the new name, namely search engines,
bloggers, LWN, openwrt.) I don't think anyone seriously uses chaosnet
nowadays. And just because there is a "quicktables" project does not
mean there is a quick protocol filter.
Also note that the word 'chaostables' does not even appear in the patch,
though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we
can safely assume that CHAOS does what it says - make fun of nmap.
>> Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>> ===
>> --- /dev/null
>> +++ linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>> @@ -0,0 +1,184 @@
>> +
>> +static unsigned int xt_chaos_target(struct sk_buff **pskb,
>> +const struct net_device *in, const struct net_device *out,
>> +unsigned int hooknum, const struct xt_target *target, const void
>> *targinfo)
>> +{
>> +/* Equivalent to:
>> + * -A chaos -m statistic --mode random --probability \
>> + * $reject_percentage -j REJECT --reject-with host-unreach;
>> + * -A chaos -m statistic --mode random --probability \
>> + * $delude_percentage -j DELUDE;
>> + * -A chaos -j DROP;
>> + */
>
>What does this do that can't be done by simply adding those individual
>rules?
It "wraps it all up", reducing the overall number of rules and user
chains required in the filtering tables to implement the wanted logic.
Reducing the number of filtering rules also reduces the time process a
packet. These two are, in my opinion, a good thing.
Take xt_portscan as an example, which would require a minimum of 23
filtering rules (which cannot reproduce the module's action in its
fullest). 23 rules means we will be looping a bit in ipt_do_table() for
a single packet, repeatedly checking for "-p tcp", i.e. calling into
xt_tcpudp, checking for port ranges and perhaps other TCP fields that
are never examined in xt_portscan.
>> Index: linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
>> ===
>> --- /dev/null
>> +++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
>
>Looks like a copy of the REJECT target. What does it do,
>why can't you use REJECT?
Looking only at TCP,
REJECT sends a RST for any packet (if requested), or ICMP otherwise.
DELUDE sends a SYN-ACK on SYN, otherwise RST.
(And TARPIT, for reference, keeps the connection open anytime. Its code
is also quite a replication of REJECT.)
If you think it is better to merge the respond-with-SYNACK into REJECT
rather than having DELUDE, say so.
>> Index: linux-2.6.21-rc3/net/netfilter/xt_portscan.c
>> ===
>> --- /dev/null
>> +++ linux-2.6.21-rc3/net/netfilter/xt_portscan.c
>
>We already have the psd match for years, but decided against merging it.
On what basis? As far as I flew over psd's code, it uses a heuristic
like "how often did that client recently connect" for match decision.
(P2P clients randomly port knocking, anyone?) I would not think of that
as a reliable way to tell portscans either. However, half-open TCP
connect for example is a more clear action to define a portscan.
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel threads
Andrew Morton wrote: > > > On Tue, 6 Mar 2007 11:03:48 -0500 "linux-os \(Dick Johnson\)" <[EMAIL > > PROTECTED]> wrote: > > > > In linux-2.6.16.24, there is a problem with kernel threads > > and the aic79xx.c driver. > > > > When nash is executing /initrd/linuxrc in the initial RAM disk > > during boot, it will be installing drivers. One driver, aic79xx.c > > creates some kernel threads that will exit after the initialization > > procedure. Actually the number of tasks depends upon the number > > of disks found as the driver spawns these tasks so initialization > > can occur in the background. The kernel tasks have been 'parented' > > to init. This may be fine for the real init, but nash and other > > shells receive the SIGCHLD signal and think that the fork()/exec() > > they have executed is complete. This makes nash insert drivers > > when the needed previous ones have not yet initialized. Also, when > > booting a shell, the signals from the exiting kernel tasks confuse > > it. > > ug. I've always disliked the kernel's dependence upon init to reap exitted > kernel threads. It Just Seems Wrong. Yes. It is ugly to kick init to reap the kernel thread. I was going to do this change a long ago, but I don't have time to do even a minimal testing now. reparent_to_init() expects that thread_group_empty() == true anyway, we can set ->exit_signal = -1 and make this thread invisible to init. Roland, what do you think? Oleg. --- WQ/kernel/exit.c~rti2007-02-18 22:56:49.0 +0300 +++ WQ/kernel/exit.c2007-03-08 19:26:39.0 +0300 @@ -276,8 +276,8 @@ static void reparent_to_init(void) current->parent = child_reaper(current); add_parent(current); - /* Set the exit signal to SIGCHLD so we signal init on exit */ - current->exit_signal = SIGCHLD; + /* make the task autoreap */ + current->exit_signal = -1; if (!has_rt_policy(current) && (task_nice(current) < 0)) set_user_nice(current, 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/
[QUESTION] outl and writel endianity
Hi. If I use outl everything seems to be OK. Is there any difference in endianity between outl and writel (or iowrite32, which calls writel, I guess). When I do outl(val, p->ibase + 4*off); everyhting is OK, but when I do writel(val, p->iaddr + off); bad value is written unless I use cpu_to_be32(val) (or swap32). this is what p struct contains: u32 __iomem *iaddr; unsigned long ibase; and this, how it is initialized: p->ibase = pci_resource_start(pdev, 2); p->iaddr = pci_iomap(pdev, 2, 0); What's the proper use of this? iowrite32be seems to work too. thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/6] integrity: new hooks
* Mimi Zohar ([EMAIL PROTECTED]) wrote:
> +static int dummy_inode_setxattr(struct dentry *dentry, char *name, void
> *value,
> + size_t size, int flags)
> +{
> + if (!strncmp(name, XATTR_SECURITY_PREFIX,
> + sizeof(XATTR_SECURITY_PREFIX) - 1) &&
> + !capable(CAP_SYS_ADMIN))
> + return -EPERM;
> + return 0;
> +}
Hold on, what is all this? Duplication of all of this code is a no go.
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/5] signalfd v2 - signalfd core ...
On 3/8/07, Davide Libenzi wrote: The reason for the special function, was not to provide a non-blocking behaviour with zero timeout (that just a side effect), but to read the siginfo. I was all about using read(2) (and v1 used it), but when you have to transfer complex structures over it, it becomes hell. How do you cleanly compat over a f_op->read callback for example? Make it a netlink socket and fetch your structures using recvmsg(). siginfo_t belongs in ancillary data. The UNIX philosophy is "everything's a file". The Berkeley philosophy is "everything's a socket, except for files, which are feeble mini-sockets". I'd go with the Berkeley crowd here. Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc3-mm1
On Thu, Mar 08, 2007 at 09:50:43AM -0500, John W. Linville wrote: > On Wed, Mar 07, 2007 at 08:18:39PM -0800, Andrew Morton wrote: > By removing NET_RADIO, these changes pave the way to making wireless > extensions optional when cfg80211 can fully take over for some > drivers > and you don't have any older drivers that still require wext. > > Honestly, I'm tempted to add the pre-802.11 stuff to the features > removal list. I wonder if any of it still actually works... FWIW, I've built these drivers in Fedora for aeons, and never had a single bug filed against them. Either they're perfect, or no-one has that junk any more. I should turn them off for a build and see if anyone complains :) Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Networking Question [ot]
This may be a little off topic but I know there's people here that can give me a quick answer. I'm running Fedora Core 6 and I have two blocks of IP addresses on eth0. 69.50.231.0/28 69.50.231.128/26 Do I need to set some kind of static route so that IPs in one set can talk to the other? If so - how do I do that? Thanks in advance. Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/5] signalfd v2 - signalfd core ...
On Thu, 8 Mar 2007, Linus Torvalds wrote: > You missed David's worry, I think. > > Not only is POLLIN potentially an edge event (depending on the interface > you use to fetch it), but even as a level-triggered one you generally want > to read as much as possible per POLLIN event, and go back to the event > loop only when you get EAGAIN. > > So that's in addition to the read/signal race with other > threads/processes. > > You solved it by having a separate system call, but since it's a regular > file descriptor, why have a new system call at all, and not just make it > be a "read()"? In which case you definitely want O_NONBLOCK support. > > The UNIX philosophy is often quoted as "everything is a file", but that > really means "everything is a stream of bytes". > > In Windows, you have 15 different versions of "read()" with sockets and > files and pipes all having strange special cases and special system calls. > That's not the UNIX way. It should be just a "read()", and then people can > use general libraries and treat all sources the same. > > For example, the main select/poll/epoll loop may be the one doing all the > reading, and then pass off "full buffers only" to the individual per-fd > "action routines". And that kind of model really very fundamentally wants > an fd to be an fd to be an fd - not "some file descriptors need > 'read_from_sigfd()', and some file descriptors need 'read()', and some > file descriptors need 'recvmsg()'" etc. > > So I think you should get rid of signalfd_dequeue(), and just replace it > with a "read()" function. The reason for the special function, was not to provide a non-blocking behaviour with zero timeout (that just a side effect), but to read the siginfo. I was all about using read(2) (and v1 used it), but when you have to transfer complex structures over it, it becomes hell. How do you cleanly compat over a f_op->read callback for example? - 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: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded
At Thu, 8 Mar 2007 17:26:48 +0100, Michal Piotrowski wrote: > > On 08/03/07, Takashi Iwai <[EMAIL PROTECTED]> wrote: > > At Thu, 08 Mar 2007 16:42:26 +0100, > > Michal Piotrowski wrote: > > > > > > Takashi Iwai napisał(a): > > > > Or, does it happen if you play a real 5.1 channel file? > > > > (for example, try speaker-test -c6) > > > > > > It doesn't work for me on both kernels. > > > > Pass -Dplug:surround51 to speaker-test in addition. > > It still doesn't work (at least on clean 2.6.21-rc3). That's expected. But it should work with the fixed kernel. Let me know if it still doesn't work with the patched kernel. thanks, Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Request change in behaviour of capability inheritance.
--- [EMAIL PROTECTED] wrote: > I think that the current behaviour of capability > inheritance across exec() > is not optimal. > > The current behaviour consists in all effective and > permitted capabilities > are cleared across a exec(). This is because it > seems to be intended that > in the future the executable files have a set of > "allowed" and "forced" > capabilities. File based capabilities are the same effective, permitted, and inheritable sets that the process has. Unless the thinking has shifted over the last couple weeks (it happens from time to time) the inheritable set is what you're missing. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PPC: Correct apparently misspelled "XMON" preprocessor directive.
Correct the apparent misspelling of "XMON" to "CONFIG_XMON".
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
i'm only *guessing* that this is a typo, given that the file
"arch/powerpc/Kconfig.debug" defines the XMON config variable.
diff --git a/arch/powerpc/platforms/chrp/setup.c
b/arch/powerpc/platforms/chrp/setup.c
index 117c9a0..1edce72 100644
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -427,7 +427,7 @@ static void __init chrp_find_openpic(void)
of_node_put(np);
}
-#if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(XMON)
+#if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(CONFIG_XMON)
static struct irqaction xmon_irqaction = {
.handler = xmon_irq,
.mask = CPU_MASK_NONE,
@@ -493,7 +493,7 @@ static void __init chrp_find_8259(void)
void __init chrp_init_IRQ(void)
{
-#if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(XMON)
+#if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(CONFIG_XMON)
struct device_node *kbd;
#endif
chrp_find_openpic();
@@ -510,7 +510,7 @@ void __init chrp_init_IRQ(void)
if (_chrp_type == _CHRP_Pegasos)
ppc_md.get_irq= i8259_irq;
-#if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(XMON)
+#if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(CONFIG_XMON)
/* see if there is a keyboard in the device tree
with a parent of type "adb" */
for (kbd = find_devices("keyboard"); kbd; kbd = kbd->next)
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/5] signalfd v2 - signalfd core ...
On Thu, 8 Mar 2007, Davide Libenzi wrote: > > This patch, if you get a POLLIN, you have a signal to read for sure (well, > unless you another thread/task reads it before you - but that's just > somthing you have to take care). There is not explicit check for > O_NONBLOCK now, but a zero timeout would do exactly the same thing. You missed David's worry, I think. Not only is POLLIN potentially an edge event (depending on the interface you use to fetch it), but even as a level-triggered one you generally want to read as much as possible per POLLIN event, and go back to the event loop only when you get EAGAIN. So that's in addition to the read/signal race with other threads/processes. You solved it by having a separate system call, but since it's a regular file descriptor, why have a new system call at all, and not just make it be a "read()"? In which case you definitely want O_NONBLOCK support. The UNIX philosophy is often quoted as "everything is a file", but that really means "everything is a stream of bytes". In Windows, you have 15 different versions of "read()" with sockets and files and pipes all having strange special cases and special system calls. That's not the UNIX way. It should be just a "read()", and then people can use general libraries and treat all sources the same. For example, the main select/poll/epoll loop may be the one doing all the reading, and then pass off "full buffers only" to the individual per-fd "action routines". And that kind of model really very fundamentally wants an fd to be an fd to be an fd - not "some file descriptors need 'read_from_sigfd()', and some file descriptors need 'read()', and some file descriptors need 'recvmsg()'" etc. So I think you should get rid of signalfd_dequeue(), and just replace it with a "read()" function. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded
On 08/03/07, Takashi Iwai <[EMAIL PROTECTED]> wrote: At Thu, 08 Mar 2007 16:42:26 +0100, Michal Piotrowski wrote: > > > Also, it'd be helpful if you compare > > /proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the > > patch. This reveals which register bits differ actually. > > a2.txt is form 2.6.21-rc3 witchout 831466f4ad2b5fe23dff77edbe6a7c244435e973 Just to make sure: it means that a2.txt is a working one and the anoter is non-working, right? Right. Takashi Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with libata-pata, ATAPI DVD reader and a "copy-protected" audio cd
Il giorno gio, 08/03/2007 alle 17.07 +, Alan Cox ha scritto: > > Well, it happened again, with a different cd, and this time I never > > started the player: hal/g-v-m tried to access the CD and now my driver > > is in PIO2 mode and pretty much unusable. Is there a way to fix this > > without rebooting? > > Hard to tell. If it happens again then a "dmesg" after it misbehaves and > an lspci -vxx might provide enough information to begin to debug it. > > Alan I posted these informations in my first message, however: This is the output related to my controllers during the boot: SCSI subsystem initialized libata version 2.00 loaded. sata_nv :00:07.0: version 3.2 sata_nv :00:07.0: Using ADMA mode ata1: SATA max UDMA/133 cmd 0xF0804480 ctl 0xF08044A0 bmdma 0xD400 irq 16 ata2: SATA max UDMA/133 cmd 0xF0804580 ctl 0xF08045A0 bmdma 0xD408 irq 16 scsi0 : sata_nv ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: ATA-7, max UDMA/133, 312581808 sectors: LBA48 NCQ (depth 31/32) ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/133 scsi 0:0:0:0: Direct-Access ATA WDC WD1600JS-22N 10.0 PQ: 0 ANSI: 5 ata1: bounce limit 0x, segment boundary 0x, hw segs 61 SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 > sd 0:0:0:0: Attached scsi disk sda sd 0:0:0:0: Attached scsi generic sg0 type 0 sata_nv :00:08.0: Using ADMA mode ata3: SATA max UDMA/133 cmd 0xF0806480 ctl 0xF08064A0 bmdma 0xC000 irq 17 ata4: SATA max UDMA/133 cmd 0xF0806580 ctl 0xF08065A0 bmdma 0xC008 irq 17 scsi2 : sata_nv ata3: SATA link down (SStatus 0 SControl 300) scsi3 : sata_nv ata4: SATA link down (SStatus 0 SControl 300) pata_amd :00:06.0: version 0.2.7 ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xE800 irq 14 ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xE808 irq 15 scsi4 : pata_amd ata5.00: ATA-6, max UDMA/100, 156301488 sectors: LBA ata5.00: ata5: dev 0 multi count 16 ata5.01: ATA-5, max UDMA/133, 78177792 sectors: LBA ata5.01: ata5: dev 1 multi count 16 ata5.00: configured for UDMA/100 ata5.01: configured for UDMA/133 scsi5 : pata_amd ata6.00: ATAPI, max UDMA/66 ata6.01: ATAPI, max UDMA/33 ata6.00: configured for UDMA/66 ata6.01: configured for UDMA/33 scsi 4:0:0:0: Direct-Access ATA WDC WD800JB-00FM 13.0 PQ: 0 ANSI: 5 SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 > sd 4:0:0:0: Attached scsi disk sdb sd 4:0:0:0: Attached scsi generic sg1 type 0 scsi 4:0:1:0: Direct-Access ATA MAXTOR 6L040J2 A93. PQ: 0 ANSI: 5 SCSI device sdc: 78177792 512-byte hdwr sectors (40027 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 78177792 512-byte hdwr sectors (40027 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sd 4:0:1:0: Attached scsi disk sdc sd 4:0:1:0: Attached scsi generic sg2 type 0 scsi 5:0:0:0: CD-ROMPIONEER DVD-RW DVR-111D 1.23 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 5:0:0:0: Attached scsi CD-ROM sr0 sr 5:0:0:0: Attached scsi generic sg3 type 5 scsi 5:0:1:0: CD-ROMTOSHIBA DVD-ROM SD-M1612 1806 PQ: 0 ANSI: 5 sr1: scsi3-mmc drive: 40x/48x cd/rw xa/form2 cdda tray sr 5:0:1:0: Attached scsi CD-ROM sr1 sr 5:0:1:0: Attached scsi generic sg4 type 5 This is the dmesg output due to the error. This is with the Enhanced CD: ata6.01: qc timeout (cmd 0xa0) ata6.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata6.01: (BMDMA stat 0x65) ata6.01: cmd a0/01:00:00:00:00/00:00:00:00:00/b0 tag 0 cdb 0x28 data 16384 in res 51/51:03:00:00:00/00:00:00:00:00/b0 Emask 0x5 (timeout) ata6: soft resetting port ata6.00: configured for UDMA/66 ata6.01: configured for UDMA/33 ata6: EH complete ata6.01: qc timeout (cmd 0xa0) ata6.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata6.01: (BMDMA stat 0x65) ata6.01: cmd a0/01:00:00:00:00/00:00:00:00:00/b0 tag 0 cdb 0x28 data 16384 in res 51/51:03:00:00:00/00:00:00:00:00/b0 Emask 0x5 (time
Re: [PATCH] Add xfrm policy change auditing to pfkey_spdget
On Wed, 2007-03-07 at 16:07 -0800, David Miller wrote: > From: David Miller <[EMAIL PROTECTED]> > Date: Wed, 07 Mar 2007 15:43:16 -0800 (PST) > > > From: Eric Paris <[EMAIL PROTECTED]> > > Date: Fri, 02 Mar 2007 13:51:24 -0500 > > > > > pfkey_spdget neither had an LSM security hook nor auditing for the > > > removal of xfrm_policy structs. The security hook was added when it was > > > moved into xfrm_policy_byid instead of the callers to that function by > > > my earlier patch and this patch adds the auditing hooks as well. > > > > > > Signed-off-by: Eric Paris <[EMAIL PROTECTED]> > > > > Applied. > > This patch was missing an openning brace on the "if (delete)" line. > Eric you don't post patches without at least compile testing > them now do you? :-) > > I fixed this up, but I will just kick it back to you next time, > and I will likely growl very loudly in your general direction > too. ;) I lose at using git. Sorry. I'll be more careful to check that all of my changes on the current branch are committed before I run my git diff. Or maybe someone will convince me to use git in an all new better way. I created a branch that has your tree and then created a new branch off of that for my changes. I checked out my branch made my patch and commited. I then tried to compile failed and fixed it up. I then compiled, booted, and tested. When I thought it was working I did a git diff miller..my-branch-with-pfkey_spdget which didn't have my fix up because i didn't commit it to my local branch. Is there a better way to get a diff between my miller tree and 'everything in the branch I have checked out even if it is not committed'? Sorry, even if there are no ideas I'll be more careful. -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: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded
At Thu, 08 Mar 2007 16:42:26 +0100,
Michal Piotrowski wrote:
>
> > Also, it'd be helpful if you compare
> > /proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the
> > patch. This reveals which register bits differ actually.
>
> a2.txt is form 2.6.21-rc3 witchout 831466f4ad2b5fe23dff77edbe6a7c244435e973
>
> diff -uprN a2.txt /proc/asound/card0/codec97#0/ac97#0-0+regs
> --- a2.txt 2007-03-08 16:36:47.0 +0100
> +++ /proc/asound/card0/codec97#0/ac97#0-0+regs 2007-03-08 16:36:49.447083597
> +0100
> @@ -56,8 +56,8 @@
> 0:6e =
> 0:70 =
> 0:72 = 0004
> -0:74 = 1001
> -0:76 = 64a4
> +0:74 = 1201
> +0:76 = 7ca4
> 0:78 = 000c
> 0:7a =
> 0:7c = 4144
OK, some wrong bits there. Could you try the patch below?
Takashi
diff -r 6888d4cd251d sound/pci/ac97/ac97_patch.c
--- a/sound/pci/ac97/ac97_patch.c Thu Mar 08 12:53:55 2007 +0100
+++ b/sound/pci/ac97/ac97_patch.c Thu Mar 08 17:10:52 2007 +0100
@@ -1950,9 +1950,9 @@ static void ad1888_update_jacks(struct s
static void ad1888_update_jacks(struct snd_ac97 *ac97)
{
unsigned short val = 0;
- if (! is_shared_linein(ac97))
+ if (is_shared_linein(ac97))
val |= (1 << 12);
- if (! is_shared_micin(ac97))
+ if (is_shared_micin(ac97))
val |= (1 << 11);
/* shared Line-In */
snd_ac97_update_bits(ac97, AC97_AD_MISC, (1 << 11) | (1 << 12), val);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PAGE_SIZE Availability Inconsistency
On Thu, Mar 08, 2007 at 07:53:49AM -0800, Arjan van de Ven wrote: > > > > PAGE_SIZE should not be available at all. Please use getpagesize() > > > > instead. > > > > > > While I agree, NBPG is a bit of a problem, although it's only needed for > > > aout > > > coredumps AFAICT, but still needed to compile e.g. gdb. > > > > So we should export this one with an arbitrary value (on multiple page > > size architectures) and a warning, maybe even an __deprecated attached to > > it. > > if we think the kernel should export this one, we could do > > #ifndef __KERNEL__ > #define PAGE_SIZE getpagesize() > #endif No, no no. We should never export PAGE_SIZE. We might export NBPG as deprecated symbol for gdb if it really needs it, but that should happen only on a.out systems, and it it should be a true constant, not depending on PAGE_SIZE. I've Cc'ed the gdb list on whether they have any comments on this issue. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fastboot] [PATCH 11/20] x86_64: wakeup.S misc cleanups
On Thu, Mar 08, 2007 at 12:43:35PM +0100, Pavel Machek wrote: > > > > + movw$0x0e00 + 'i', %ds:(0xb8012) > > > > + movb$0xa8, %al ; outb %al, $0x80; > > > > + > > > > > > > - movw$0x0e00 + 'i', %ds:(0xb8012) > > > > - movb$0xa8, %al ; outb %al, $0x80; > > > > > > Outbs were my debugging hacks, perhaps you can simply remove them at > > > this point? Not sure how useful "Linux" debug print is, it can > > > probably be removed, too. > > > > > I found these debugging hacks useful while debugging some problem with > > my changes in this code. It helps to find out till what poing code flow > > as reached in this assembly code. So I think its not a bad idea to let > > this piece code be there. > > Ok. (I was not sure how common are displays of port 0x80). They're now typically available in reasonably well stocked stores; I picked one up from CompUSA about a year ago... -- David N. Lombard, Intel, Irvine, CA I do not speak for Intel Corporation; all comments are strictly my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [scsi]: Add offline state checking while dispatch a scsi cmd
On Thu, 2007-03-08 at 17:22 +0800, Joe Jin wrote: > While a scsi device hw error occured, device's status maybe setting > to SDEV_OFFLINE, So at scsi_dispatch_cmd function, we should checking > if device have offline, if yes, do nothing and just return error to > user directly. What's the error you're trying to fix? scsi_dispatch_cmd() is only called from scsi_request_fn() which already has an equivalent of this check in it just prior to calling dispatch. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: refcounting drivers' data structures used in sysfs buffers
On Thu, 8 Mar 2007, Oliver Neukum wrote: > Hi, > > after a lightning bolt from high above I've been looking into refcounting > the data structures drivers use to provide the data used to refill sysfs > buffers. I've come to the following conclusion. > > 1. struct sysfs_buffer must have a struct kref * and probably a destructor > pointer > 2. drivers must be able to pass these pointers through an extended > device_create_file() > 3. Drivers must use refcounting if they want to use attributes > 4. read/write/poll must do refcounting > > I am not sure where to store the pointers. struct sysfs_dirent() looks > like the obvious choice. Comments? Can you explain the reasoning that led to these conclusions? And what exactly was your lightning bolt? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with libata-pata, ATAPI DVD reader and a "copy-protected" audio cd
> Well, it happened again, with a different cd, and this time I never > started the player: hal/g-v-m tried to access the CD and now my driver > is in PIO2 mode and pretty much unusable. Is there a way to fix this > without rebooting? Hard to tell. If it happens again then a "dmesg" after it misbehaves and an lspci -vxx might provide enough information to begin to debug it. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Radeon xpress 200m and radeonfb kinda work
johan henriksson wrote:
> As you can see in the patch I have disabled "Dynamic Clock PM"
> since it makes my card freak out (Don't know why :( ).
> Is there a reason why the "default_dynclk" parameter only is available
> when radeonfb is built as a module or should it be added to radeonfb_setup?
I don't have a clue how that works; I just merged your patch
into a Fedora test kernel and it worked. (And it looks a lot
nicer than vesafb.)
Our X driver guru says the patch is OK and Xpress 200M is
the same as normal Radeon for 2D so framebuffer should be OK.
So we can add this to the patch:
Tested-by: Chuck Ebbert <[EMAIL PROTECTED]>
Please repost it as a reply-to-all and add a decent description
and a signed-off-by per this document:
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
Hi!
I have gotten the radeon xpress 200m (the version without dedicated vmem)
to work with radeonfb.
The attached patch (against linux-2.6.20.1) works for me.
Since I don't have any docs for the card I am unsure if the patch is 100%
correct.
Can someone else with a 200m try it out?
(I have tested it by enabling fbcon and radeonfb in the kernel and
added "video=radeonfb" to lilo. This gave me a nice 1280x800 console :) )
/Johan Henriksson
Please CC, I'm not on the list.
diff -uprN -X linux-2.6.20.1-vanilla/Documentation/dontdiff
linux-2.6.20.1-vanilla/drivers/video/aty/ati_ids.h
linux-2.6.20.1/drivers/video/aty/ati_ids.h
--- linux-2.6.20.1-vanilla/drivers/video/aty/ati_ids.h Tue Feb 20 07:34:32 2007
+++ linux-2.6.20.1/drivers/video/aty/ati_ids.h Tue Mar 6 00:31:16 2007
@@ -209,4 +209,4 @@
#define PCI_CHIP_R423_5D57 0x5D57
#define PCI_CHIP_RS350_7834 0x7834
#define PCI_CHIP_RS350_7835 0x7835
-
+#define PCI_CHIP_RS480_5955 0x5955
diff -uprN -X linux-2.6.20.1-vanilla/Documentation/dontdiff
linux-2.6.20.1-vanilla/drivers/video/aty/radeon_base.c
linux-2.6.20.1/drivers/video/aty/radeon_base.c
--- linux-2.6.20.1-vanilla/drivers/video/aty/radeon_base.c Tue Feb 20
07:34:32 2007
+++ linux-2.6.20.1/drivers/video/aty/radeon_base.c Tue Mar 6 00:31:19 2007
@@ -100,6 +100,8 @@
{ PCI_VENDOR_ID_ATI, id, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (flags) |
(CHIP_FAMILY_##family) }
static struct pci_device_id radeonfb_pci_table[] = {
+/* Radeon Xpress 200m */
+ CHIP_DEF(PCI_CHIP_RS480_5955, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
/* Mobility M6 */
CHIP_DEF(PCI_CHIP_RADEON_LY,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RADEON_LZ,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
@@ -1990,7 +1992,8 @@ static void radeon_identify_vram(struct
/* framebuffer size */
if ((rinfo->family == CHIP_FAMILY_RS100) ||
(rinfo->family == CHIP_FAMILY_RS200) ||
-(rinfo->family == CHIP_FAMILY_RS300)) {
+(rinfo->family == CHIP_FAMILY_RS300) ||
+ (rinfo->family == CHIP_FAMILY_RS480) ) {
u32 tom = INREG(NB_TOM);
tmp = tom >> 16) - (tom & 0x) + 1) << 6) * 1024);
@@ -2329,7 +2332,7 @@ static int __devinit radeonfb_pci_regist
/* -2 is special: means ON on mobility chips and do not
* change on others
*/
- radeonfb_pm_init(rinfo, rinfo->is_mobility ? 1 : -1,
ignore_devlist, force_sleep);
+ radeonfb_pm_init(rinfo, -1,ignore_devlist,
force_sleep);//rinfo->is_mobility ? 1 : -1);
} else
radeonfb_pm_init(rinfo, default_dynclk, ignore_devlist,
force_sleep);
diff -uprN -X linux-2.6.20.1-vanilla/Documentation/dontdiff
linux-2.6.20.1-vanilla/drivers/video/aty/radeonfb.h
linux-2.6.20.1/drivers/video/aty/radeonfb.h
--- linux-2.6.20.1-vanilla/drivers/video/aty/radeonfb.h Tue Feb 20 07:34:32 2007
+++ linux-2.6.20.1/drivers/video/aty/radeonfb.h Tue Mar 6 00:31:16 2007
@@ -48,6 +48,7 @@ enum radeon_family {
CHIP_FAMILY_RV350,
CHIP_FAMILY_RV380,/* RV370/RV380/M22/M24 */
CHIP_FAMILY_R420, /* R420/R423/M18 */
+ CHIP_FAMILY_RS480,
CHIP_FAMILY_LAST,
};
@@ -64,7 +65,8 @@ enum radeon_family {
((rinfo)->family == CHIP_FAMILY_RV350) || \
((rinfo)->family == CHIP_FAMILY_R350) || \
((rinfo)->family == CHIP_FAMILY_RV380) || \
- ((rinfo)->family == CHIP_FAMILY_R420))
+ ((rinfo)->family == CHIP_FAMILY_R420) || \
+ ((rinfo)->family == CHIP_FAMILY_RS480) )
/*
* Chip flags
Re: PAGE_SIZE Availability Inconsistency
On Thu, 2007-03-08 at 09:00 +, Christoph Hellwig wrote: > On Thu, Mar 08, 2007 at 03:18:04AM +0100, Roman Zippel wrote: > > Hi, > > > > On Tuesday 06 March 2007 10:29, Christoph Hellwig wrote: > > > > > PAGE_SIZE should not be available at all. Please use getpagesize() > > > instead. > > > > While I agree, NBPG is a bit of a problem, although it's only needed for > > aout > > coredumps AFAICT, but still needed to compile e.g. gdb. > > So we should export this one with an arbitrary value (on multiple page > size architectures) and a warning, maybe even an __deprecated attached to > it. if we think the kernel should export this one, we could do #ifndef __KERNEL__ #define PAGE_SIZE getpagesize() #endif -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded
At Thu, 08 Mar 2007 16:42:26 +0100,
Michal Piotrowski wrote:
>
> Takashi Iwai napisał(a):
> > At Wed, 07 Mar 2007 23:22:36 +0100,
> > Michal Piotrowski wrote:
> >> Hi Takashi,
> >>
> >> Takashi Iwai napisał(a):
> >>> At Wed, 7 Mar 2007 11:50:24 -0800,
> >>> Andrew Morton wrote:
> On Wed, 7 Mar 2007 20:41:30 +0100 "Michal Piotrowski" <[EMAIL
> PROTECTED]> wrote:
>
> >>> 831466f4ad2b5fe23dff77edbe6a7c244435e973 is first bad commit
> >>> commit 831466f4ad2b5fe23dff77edbe6a7c244435e973
> >>> Author: Randy Cushman <[EMAIL PROTECTED]>
> >>> Date: Tue Dec 19 18:42:16 2006 +0100
> >>>
> >>> [ALSA] ac97 - fix microphone and line_in selection logic
> >>>
> >>> This patch fixes the Microphone and LINE_IN select logic for
> >>> Analog Devices surround codecs with shared jacks. The existing
> >>> code can never utilize the shared jacks for Microphone and LINE_IN
> >>> due to the reversed jack selection logic. The patched code
> >>> correctly selects the shared jack for input if the 'Channel Mode'
> >>> selector does not specify that the jack is to be used for output.
> >>> Specifically, in '2ch' mode the Center/LFE jack is used for
> >>> microphone input and the Surround jack is used for LINE_IN,
> >>> in '4ch' mode the Center/LFE jack is used for microphone input
> >>> and the Surround jack is used for output, and in '6ch' mode
> >>> both jacks are used for output.
> >>>
> >>> Signed-off-by: Randy Cushman <[EMAIL PROTECTED]>
> >>> Signed-off-by: Takashi Iwai <[EMAIL PROTECTED]>
> >>> Signed-off-by: Jaroslav Kysela <[EMAIL PROTECTED]>
> >>>
> >> Is 2.6.21-rc3 similarly broken?
> > Yes.
> >
> OK. Can you please confirm that applying the below fixes 2.6.21-rc3?
>
> If so, I'll queue it up for application in a week or two if there is no
> progress on this.
> >>> [sorry for the late interrupt - I'm just back from a vacation]
> >>>
> >>> Could you postpone reverting for a while?
> >>> I guess this possible regression is limited only to a certain type of
> >>> ac97 codec chip. The patch applied there was a fix for many codec
> >>> chips.
> >>>
> >>> Which codec chip are you using specifically? Please check
> >>> /proc/asound/card0/codec97#0/* file(s).
> >> 0-0/0: Analog Devices AD1985
> >
> > OK, that's good to know.
> >
> >>control.43 {
> >>comment.access 'read write'
> >>comment.type BOOLEAN
> >>comment.count 1
> >>iface MIXER
> >>name 'Spread Front to Surround and Center/LFE'
> >>value true
> >>}
> >
> > So, you're playing two-channel samples and get no output from surround
> > and CLFE?
>
> Yes.
>
> > Or, does it happen if you play a real 5.1 channel file?
> > (for example, try speaker-test -c6)
>
> It doesn't work for me on both kernels.
Pass -Dplug:surround51 to speaker-test in addition.
Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
