On Fri, 04 Feb 2005 11:03:47 +0100, Ingo Molnar said:
>
> i have released the -V0.7.38-01 Real-Time Preemption patch, which can be
> downloaded from the usual place:
Hey Ingo.. Sorry to keep breaking stuff on you, but.. ;)
Summary: Looks like CONFIG_NET_PKTGEN=y gives -V0.7.38-03 indigestion.
Mark F. Haigh wrote:
Apologies. Patch now -p1-able.
[Apologies yet again, now includes description]
I'd submitted a patch earlier for this file, fixing a warning. When I
looked at it further, I noticed it can output an incorrect warning
message under certain circumstances. I've confirmed that
The description in kernel 2.6.11-rc3-mm1 make for the skge driver states
the following:
"*New SysKonnect GigaEthernet support (EXPERIMENTAL) (SKGE)
This driver support the Marvell Yukon or SysKonnect SK-98xx/SK-95xx
and related Gigabit Ethernet adapters. It is a new smaller driver
driver with
The description in kernel 2.6.11-rc3-mm1 make for the skge driver states
the following:
"*New SysKonnect GigaEthernet support (EXPERIMENTAL) (SKGE)
This driver support the Marvell Yukon or SysKonnect SK-98xx/SK-95xx
and related Gigabit Ethernet adapters. It is a new smaller driver
driver with
Mark F. Haigh wrote:
Apologies. Patch now -p1-able.
[Apolgies yet again, description included now]
Noticed that in drivers/scsi/sym53c8xx.c:
sym53c8xx.c:13185: warning: integer constant is too large for "long" type
Since we're not dealing with C99 (yet), this 64 bit integer constant
needs to be
Greg KH wrote:
Oops, this time you forgot the whole description of the patch :(
Third time's the charm...
The following has been reported in the wild for kernel 2.6.8-24:
PCI: Enabling device :00:05.0 ( -> 0002)
PCI: No IRQ known for interrupt pin @ of device :00:05.0. Probably
buggy
Mark F. Haigh wrote:
--- arch/i386/kernel/pci-irq.c.orig 2005-02-07 19:55:23.852531544 -0800
+++ arch/i386/kernel/pci-irq.c 2005-02-07 20:13:38.835068896 -0800
Apologies. Patch now -p1-able.
Mark F. Haigh
[EMAIL PROTECTED]
Signed-off-by: Mark F. Haigh <[EMAIL PROTECTED]>
---
Mark F. Haigh wrote:
--- drivers/scsi/sym53c8xx.c.orig 2005-02-07 19:53:05.741527608 -0800
+++ drivers/scsi/sym53c8xx.c2005-02-07 19:53:36.782808616 -0800
Apologies. Patch now -p1-able.
Mark F. Haigh
[EMAIL PROTECTED]
Signed-off-by: Mark F. Haigh <[EMAIL PROTECTED]>
---
On Mon, Feb 07, 2005 at 09:42:02PM -0800, Mark F. Haigh wrote:
> Greg KH wrote:
> >On Mon, Feb 07, 2005 at 09:06:18PM -0800, Mark F. Haigh wrote:
>
> > > --- arch/i386/pci/irq.c.orig 2005-02-07 20:40:58.140856536 -0800
> > > +++ arch/i386/pci/irq.c 2005-02-07 20:46:06.713946296 -0800
> >
>
Greg KH wrote:
On Mon, Feb 07, 2005 at 09:06:18PM -0800, Mark F. Haigh wrote:
> --- arch/i386/pci/irq.c.orig 2005-02-07 20:40:58.140856536 -0800
> +++ arch/i386/pci/irq.c 2005-02-07 20:46:06.713946296 -0800
Can you resend this so it can be applied with -p1 to patch, and a
Signed-off-by:
On Mon, Feb 07, 2005 at 09:06:18PM -0800, Mark F. Haigh wrote:
>
> (Same basic problem I just reported in a seperate thread against 2.4.29-bk8)
>
> The following has been reported in the wild for kernel 2.6.8-24:
>
> PCI: Enabling device :00:05.0 ( -> 0002)
> PCI: No IRQ known for
(Same basic problem I just reported in a seperate thread against 2.4.29-bk8)
The following has been reported in the wild for kernel 2.6.8-24:
PCI: Enabling device :00:05.0 ( -> 0002)
PCI: No IRQ known for interrupt pin @ of device :00:05.0. Probably
buggy MP table.
It should read "No
Same patch, now against 2.4.29-bk8:
Noticed that in drivers/scsi/sym53c8xx.c:
sym53c8xx.c:13185: warning: integer constant is too large for "long" type
Since we're not dealing with C99 (yet), this 64 bit integer constant
needs to be suffixed with ULL. Patch included.
Mark F. Haigh
[EMAIL
I'd submitted a patch earlier for this file, fixing a warning. When I
looked at it further, I noticed it can output an incorrect warning
message under certain circumstances. I've confirmed that this can and
does happen in the wild:
PCI: Enabling device :00:0a.0 ( -> 0001)
PCI: No IRQ
Kernel panic'ed while booting (on HP rx5670 - 2 CPU) the kernel
2.6.11-rc3, configured
and compiled with zx1_defconfig target.
I want follow the below given steps to understand and debug the problem. Please
correct me if they are not the correct way of attacking problems of this kind.
1.
In a somewhat beta.
We're working on our ease-of-use.
Release 3.0.19 of STP, available at Sourceforge
(http://sourceforge.net/projects/stp )
and via BK
( bk://developer.osdl.org tag: release_3.0.19 )
adds an email gateway, so you can submit test requests without
the Web.
I am looking for a
Hi Seto !
I was reading the list archives for the discussion back in September
about PCI error reporting. Has there been any further progress on this
since then ?
I'm looking into adapting something for the need of ppc64 as well
(which, btw, has 1 slot = 1 bridge on most cases, but not all of
Grzegorz Kulewski <[EMAIL PROTECTED]> wrote:
>
> On Mon, 7 Feb 2005, Andrew Morton wrote:
>
> > Daniel Drake <[EMAIL PROTECTED]> wrote:
> >>
> >>> # fs/binfmt_elf.c
> >>> # 2005/01/17 13:37:56-08:00 [EMAIL PROTECTED] +43 -19
> >>> # [SPARC64]: Missing user access return value checks in
Appended is a patch which stops using the zone->zone_mem_map to
calculate the buddy and combined page pointers. It uses the fact
that the mem_map array is guaranteed to be contigious for the
surrounding (1 << MAX_ORDER) pages. The relative positions of
the pages in the physical address space to
There are some corrections for my message... Sorry.
At Tue, 08 Feb 2005 12:53:29 +0900,
SATOH Fumiyasu wrote:
> Host3:
> --
> OS: Debian GNU/Linux testing version (sarge)
> Kernel: kernel-image-2.6.10-1-686-smp
> (compiled by gcc version 3.3.5 (Debian 1:3.3.5-6))
> Filesystem: /
At Mon, 07 Feb 2005 09:38:28 -0600,
Jeffrey E. Hundstad wrote:
> I'm sorry for this truncated report... but it's all I've got. If you
> need .config or system configuration, etc. let me know and I'll send'em
> ASAP. I don't believe this is hardware related; ide-smart shows all fine.
>
> From
Hi,
I am trying to beat the I/O bottleneck so as to speed up bulk data transfers
in high speed network. It seems that the system call sendfile() can help to
reduce CPU utilization and speedup data transfers. But I have one question
about the system call,
First, Linux sendfile requires that
On Mon, 07 Feb 2005 18:20:36 PST, Chris Wright said:
> * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > open("/tmp/sh-thd-1107848098", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|O_LARGEFILE,
0600) = 3
>
> O_EXCL
>
> > Wow - if my /tmp was on the same partition, and I'd hard-linked that
> > file to
David Holland pointed out that Make has a lot of implicit suffix rules
built in and you can disable them by setting ".SUFFIXES:". As an
example, checking the debugging information shows we no longer try to
compile anything from a '.f' suffix. This turns out to be good for a 15%
speedup on a
On Mon, Feb 07, 2005 at 07:38:12AM -0800, Linus Torvalds wrote:
>
> Whee. You've got 5 _million_ bio's "active". Which account for about 750MB
> of your 860MB of slab usage.
Same situation here, at different rates on two different platforms,
both running same kernel build. Both show steadily
-BEGIN PGP SIGNED MESSAGE-
(BHash: SHA1
(B
(BOn 02/08/2005 09:23 AM, Horst von Brand wrote:
(B> Clemens Schwaighofer <[EMAIL PROTECTED]> said:
(B>
(B> [...]
(B>>but to be honest, most times I need vfat, and I actually haven't
(B>>encountered a time when I need msdos.
(B>
(B>
Clemens Schwaighofer <[EMAIL PROTECTED]> said:
[...]
> but to be honest, most times I need vfat, and I actually haven't
> encountered a time when I need msdos.
But writing MSDOS on a VFAT filesystem is a sure way to screw it up, and
AFAIU vice-versa.
--
Dr. Horst H. von Brand
"Randy.Dunlap" <[EMAIL PROTECTED]> said:
> Chris Friesen wrote:
[...]
> > If you look at the big chip manufacturers (TI, Maxim, Analog Devices,
> > etc.) they publish specs on everything. It would be nice if others did
> > the same.
> One of the arguments that I have heard is fairly old and
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> open("/tmp/sh-thd-1107848098", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|O_LARGEFILE,
> 0600) = 3
O_EXCL
> Wow - if my /tmp was on the same partition, and I'd hard-linked that
> file to /etc/passwd, it would be toast now if root had run it.
So, in fact,
On Tue, 08 Feb 2005 01:48:40 GMT, David Wagner said:
> How would /etc/passwd get clobbered? Are you thinking that a tmp
> cleaner run by cron might delete /tmp/whatever (i.e., delete the hardlink
> you created above)? But deleting /tmp/whatever is safe; it doesn't affect
> /etc/passwd. I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wright wrote:
> * John Richard Moser ([EMAIL PROTECTED]) wrote:
>
>>Yes, mkdtemp() and mkstemp().
>>
>>Of course we can't always rely on programmers to get it right, so the
>>idea here is to make sure we ask broken code to behave nicely, and
Hi,
On Mon, 2005-02-07 at 16:51 -0800, [EMAIL PROTECTED] wrote:
[...]
> On a K6-2 box the 2.6.9 kernel starts to load : "Loading" then the PC
> resets.
> The kernel compiled and everything installed OK. Lilo is OK. I've tried four
> times different configs with the same result. Box
>For those systems that have everything on one big partition, you can often
>do stuff like:
>
>ln /etc/passwd /tmp/
>
>and wait for /etc/passwd to get clobbered by a cron job run by root...
How would /etc/passwd get clobbered? Are you thinking that a tmp
cleaner run by cron might delete
Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> On Mon, 7 Feb 2005, Andrew Morton wrote:
>
> > > Look at the early posts. I plan to put that up on the web. I have some
> > > stats attached to the end of this message from an earlier post.
> >
> > But that's a patch-specific microbenchmark, isn't
On Tue, Feb 08, 2005 at 12:29:29PM +1100, herbert wrote:
>
> This one moves the dst->child processing from dst_ifdown into
> xfrm_dst_ifdown.
This patch adds a net_device argument to ifdown. After all,
it's a bit silly to notify someone of an ifdown event without
telling them what which device
Here is the resend of the patch to support compatible URB ioctl
on 64 bit systems. This version already incorporate some feed back
I get from the list and I have not get any new input yet.
Change Log:
- Let usbdevfs directly handle 32 bit URB ioctl. More specifically:
USBDEVFS_SUBMITURB32,
On Sun, Feb 06, 2005 at 05:51:17PM +1100, herbert wrote:
>
> The idea is to move the check into dst->ops->ifdown. By definition
> ipv6_dst_ifdown will only see rt6_info entries. So dst_dev_event
> will become
Here are the patches to do this. Do they look sane?
This one moves the dst->child
On Mon, 7 Feb 2005, Andrew Morton wrote:
> > Look at the early posts. I plan to put that up on the web. I have some
> > stats attached to the end of this message from an earlier post.
>
> But that's a patch-specific microbenchmark, isn't it? Has this work been
> benchmarked against real-world
On Mon, 7 Feb 2005, Ingo Molnar wrote:
>
> boots fine and shrinks the image size quite noticeably:
>
> [Nr] Name TypeAddr OffSize
> [ 1] .textPROGBITSc010 001000 2771a9 [vmlinux-orig]
> [ 1] .textPROGBITSc010 001000 2742dd [vmlinux-patched]
Eric Piel wrote:
Note that this is a re-send of a previous patch now that the patch of
Peter (which had to be applied before this one) has been intregrated
in the vanilla kernel. It's Peter's version modified to apply cleanly
against 2.6.11-rc3 plus a fix in the comment.
I was actually just
Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > What were the benchmarking results for this work? I think you had some,
> > but this is pretty vital info, so it should be retained in the changelogs.
>
> Look at the early posts. I plan to put that up on the web. I have some
> stats attached to
On Mon, 7 Feb 2005, Andrew Morton wrote:
Daniel Drake <[EMAIL PROTECTED]> wrote:
# fs/binfmt_elf.c
# 2005/01/17 13:37:56-08:00 [EMAIL PROTECTED] +43 -19
# [SPARC64]: Missing user access return value checks in fs/binfmt_elf.c and
fs/compat.c
#
I think so. For a short period we applied this
Hi all,
On a K6-2 box the 2.6.9 kernel starts to load : "Loading" then the PC
resets.
The kernel compiled and everything installed OK. Lilo is OK. I've tried four
times different configs with the same result. Box resets. My 2.4.28 kernel
works OK.
I've tried rm'ing and re-unpacking
On Mon, 7 Feb 2005, Andrew Morton wrote:
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
> >
> > Adds management of ZEROED and NOT_ZEROED pages and a background daemon
> > called scrubd.
>
> What were the benchmarking results for this work? I think you had some,
> but this is pretty vital info,
On Thu, Feb 03, 2005 at 12:08:05PM -0700, Bjorn Helgaas wrote:
> Convert pci_raw_ops to use unsigned segment (aka domain),
> bus, and devfn. With the previous code, various ia64 config
> accesses fail due to segment sign-extension problems.
>
> ia64:
> - With a signed seg >= 0x8, unwanted
On Fri, Feb 04, 2005 at 12:28:36PM +0900, MUNEDA Takahiro wrote:
> Hi,
>
> The legacy_io which is the member of pci_bus struct might be
> NULL. It should be checked.
>
> This patch checks 'b->legacy_io', NULL or not.
>
> Signed-off-by: MUNEDA Takahiro <[EMAIL PROTECTED]>
Applied, thanks.
greg
Andrew wrote:
> OK, I'll add cpusets to the 2.6.12 queue.
I'd like that ;).
Thank-you, Matthew, for the work you put into making sense of this.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL
The /proc/driver/rtc interface didn't have any module owner hook.
The simplest fix is to just convert this to the single version of seq_file.
Also, fix initialization of rtc_dev to use C99 form.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
diff -Nru a/drivers/char/rtc.c
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Enrico Bartky
>Sent: Monday, February 07, 2005 7:12 AM
>To: linux-kernel@vger.kernel.org
>Subject: BIOS Bug
>
>Hello,
>
>on my notebook, when I plugged in my USB keyboard the kernel
>doesnt boot
Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> Adds management of ZEROED and NOT_ZEROED pages and a background daemon
> called scrubd.
What were the benchmarking results for this work? I think you had some,
but this is pretty vital info, so it should be retained in the changelogs.
Having one
> Er, use the result of the get_children_props() call only if it _failed_?
> I suspect that wasn't your intention. This makes my G5 boot again:
Here's an alternate fix for the ppc64 crash during boot. This corrects
the offending function to use more conventional error codes. I'll
follow up with
Hi Pavel.
I'm keen to see if we can merge Suspend2's freezer implementation after
2.6.11. Does that conflict with any of your intended changes? If it
doesn't, I'll submit a patch for review/merge as quickly as I can.
The main change involves the introduction of a new SYNCTHREAD flag. We
use this
Matthew Dobson <[EMAIL PROTECTED]> wrote:
>
> Sorry to reply a long quiet thread,
Is appreciated, thanks.
> but I've been trading emails with Paul
> Jackson on this subject recently, and I've been unable to convince either him
> or myself that merging CPUSETs and CKRM is as easy as I once
Daniel Drake <[EMAIL PROTECTED]> wrote:
>
> > # fs/binfmt_elf.c
> > # 2005/01/17 13:37:56-08:00 [EMAIL PROTECTED] +43 -19
> > # [SPARC64]: Missing user access return value checks in fs/binfmt_elf.c
> > and fs/compat.c
> > #
>
> I think so. For a short period we applied this patch to the
Matthew Dobson wrote:
On Sun, 2004-10-03 at 16:53, Martin J. Bligh wrote:
Martin wrote:
Matt had proposed having a separate sched_domain tree for each cpuset, which
made a lot of sense, but seemed harder to do in practice because "exclusive"
in cpusets doesn't really mean exclusive at all.
See my
Andrew Morton wrote:
I wonder if reverting the patch will restore the old behaviour?
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/01/21 13:42:18-08:00 [EMAIL PROTECTED]
# Merge nuts.davemloft.net:/disk1/BK/sparcwork-2.6
# into
On Feb 7, 2005, at 4:35 PM, Benjamin Herrenschmidt wrote:
Interesting... more than no swap, you must also make sure you have no
r/w mmap'ed file (which are technically equivalent to swap).
Yeah, I kinda had a similar thought. Just because you aren't
swapping doesn't mean the VM subsystem isn't
El lun, 07-02-2005 a las 16:50 -0600, Serge E. Hallyn escribió:
> Hi,
>
> If I understood you correct earlier, the only policy you needed to
> enforce was to prevent double-chrooting. If that is the case, why is it
> not sufficient to keep a "process-has-used-chroot" flag in
> current->security
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
>This module sends a signal to one or several processes (in user
> space) when a fork occurs in the kernel. It relays information about
> forks (parent and child pid) to a user space application.
>
> ...
>This patch is used
Well, I keep trying a little bit more. In the mean while you can get some
of the stuff I needed to change to at least get it to compile:
One of the problems was use of direct architecture specific semaphores
(which doesn't work under PREEMPT_REALTIME) and in places where a quick
(maybe too quick)
Benjamin Herrenschmidt wrote:
Interesting... more than no swap, you must also make sure you have no
r/w mmap'ed file (which are technically equivalent to swap).
Ah...thanks for the warning.
We want to eventually make it work with swap as well, but that's
substantially more complicated.
I'm not
Martin Mares wrote:
Hello!
Which is a good thing, right? "driver_data" is usually a pointer to
somewhere. Having userspace specify it would not be a good thing.
That depends on the driver usage, and the patch allows it to be
configurable and defaults to not being used.
Maybe we could just
On Fri, Sep 24, 2004 at 01:18:19AM -0400, Ali Bayazit wrote:
>
> On Thu, 2004-09-23 at 17:16 +0100, Alan Cox wrote:
> > On Iau, 2004-09-23 at 00:04, Judith und Mirko Kloppstech wrote:
> > > Why not write a file system on top of ISO9660 which uses the rest of the
> > > CD to write error
Jay Lan <[EMAIL PROTECTED]> wrote:
>
> I have tested Christoph's patch before the leave. It did work for CSA
> and showed performance improvement on certain configuration.
OK, thanks.
> Should i propose to include the CSA module in
> the kernel then, Andrew? :)
Sure, if such an action is
Hi,
If I understood you correct earlier, the only policy you needed to
enforce was to prevent double-chrooting. If that is the case, why is it
not sufficient to keep a "process-has-used-chroot" flag in
current->security which is set on the first call to
capable(CAP_SYS_CHROOT) and inherited by
må den 07.02.2005 Klokka 23:16 (+0100) skreiv Olivier Galibert:
> I'm starting to install some fedora core 3 systems in an environment
> where 64bits SGIs are still serving the home directories. They have
> the bug/feature that required the 2.4 patch to hack the 64bits
> cookies[1]. The 2.6
* John Richard Moser ([EMAIL PROTECTED]) wrote:
> Yes, mkdtemp() and mkstemp().
>
> Of course we can't always rely on programmers to get it right, so the
> idea here is to make sure we ask broken code to behave nicely, and stab
> it in the face if it doesn't. Please try to examine this in that
Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> I have some obscure Kylix application here... It started gets
> misteriously killed in 2.6.11-rc3 and -rc3-mm1...
>
> [EMAIL PROTECTED]:~/slovnik/bin$ strace ./Slovnik
> execve("./Slovnik", ["./Slovnik"], [/* 32 vars */]) = 0
> +++ killed by SIGKILL +++
On Mon, 07 Feb 2005 14:26:03 PST, Chris Wright said:
> * Michael Halcrow ([EMAIL PROTECTED]) wrote:
> > This is the third in a series of eight patches to the BSD Secure
> > Levels LSM. It moves the claim on the block device from the inode
> > struct to the file struct in order to address a
David Brownell wrote:
> On Sunday 06 February 2005 7:59 am, Giuseppe Bilotta wrote:
> >
> > I have a MAGNEX/ViPower USB/FirWire external HD enclosure. I
> > found that it works pretty fine (albeit slowly) when connected
> > to the USB 1.1 ports built in my Dell Inspiron 8200, but trying
> > to
On Mon, 07 Feb 2005 14:26:03 PST, Chris Wright said:
> Hard links still point to same inode, what's the issue that this
> addresses?
For those systems that have everything on one big partition, you can often
do stuff like:
ln /etc/passwd /tmp/
and wait for /etc/passwd to get clobbered by a
Hello!
> >Which is a good thing, right? "driver_data" is usually a pointer to
> >somewhere. Having userspace specify it would not be a good thing.
>
> That depends on the driver usage, and the patch allows it to be
> configurable and defaults to not being used.
Maybe we could just define the
btw., do you consider PaX as a 100% sure solution against 'code
injection' attacks (meaning that the attacker wants to execute an
arbitrary piece of code, and assuming the attacked application has a
stack overflow)? I.e. does PaX avoid all such attacks in a guaranteed
way?
Ingo
-
To
* Lorenzo Hernández García-Hierro ([EMAIL PROTECTED]) wrote:
> Attached you can find a patch which adds a new hook for the sys_chroot()
> syscall, and makes us able to add additional enforcing and security
> checks by using the Linux Security Modules framework (ie. chdir
> enforcing, etc).
If you
Greg KH wrote:
On Mon, Feb 07, 2005 at 04:00:27PM -0600, [EMAIL PROTECTED] wrote:
Currently, code exists in the pci layer to allow userspace to specify
driver data when adding a pci dynamic id from sysfs. However, this data
is never used and there exists no way in the existing code to use it.
[I am not subscribed, please CC: any replies]
When you build the 2.6 kernel outside of its source directory, using the
O= option like so:
make -C linux-2.6.10 O=../builddir
this conveniently produces a top-level Makefile in "builddir" which can
be used to update/clean/rebuild the tree
Hi!
I have some obscure Kylix application here... It started gets
misteriously killed in 2.6.11-rc3 and -rc3-mm1...
[EMAIL PROTECTED]:~/slovnik/bin$ strace ./Slovnik
execve("./Slovnik", ["./Slovnik"], [/* 32 vars */]) = 0
+++ killed by SIGKILL +++
[EMAIL PROTECTED]:~/slovnik/bin$ ldd ./Slovnik
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wright wrote:
> * John Richard Moser ([EMAIL PROTECTED]) wrote:
>
>>I've yet to see this break anything on Ubuntu or Gentoo; Brad Spengler
>>claims this breaks nothing on Debian. On the other hand, this could
>>potentially squash the second
* Michael Halcrow ([EMAIL PROTECTED]) wrote:
> This is the third in a series of eight patches to the BSD Secure
> Levels LSM. It moves the claim on the block device from the inode
> struct to the file struct in order to address a potential
> circumvention of the control via hard links to block
The February release of LTP is now available.
LTP-20050207
- runltp now exports $TMPDIR as a copy of $TMP, certain exceptions caused
these to be different.
- extra functions for LTP libs are to make these tests fail with a more
informative message when attempts to create swap on tmpfs
On Mon, Feb 07, 2005 at 04:00:27PM -0600, [EMAIL PROTECTED] wrote:
>
> Currently, code exists in the pci layer to allow userspace to specify
> driver data when adding a pci dynamic id from sysfs. However, this data
> is never used and there exists no way in the existing code to use it.
Which is
Hi,
Attached you can find a patch which adds a new hook for the sys_chroot()
syscall, and makes us able to add additional enforcing and security
checks by using the Linux Security Modules framework (ie. chdir
enforcing, etc).
Current user of the hook is the forthcoming 0.2 revision of vSecurity.
I'm starting to install some fedora core 3 systems in an environment
where 64bits SGIs are still serving the home directories. They have
the bug/feature that required the 2.4 patch to hack the 64bits
cookies[1]. The 2.6 kernel I just found still can't compensate by
itself for the issue.
Is
On Mon, 07 Feb 2005 23:00:33 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?=
=?ISO-8859-1?Q?Garc=EDa-Hierro?= said:
> A sysctl can be a good option, creating a CTL_SECURITY and then
> registering stuff under it, but this requires to have the kernel hackers
> agree with implementing a new security
Pavel Machek wrote:
Hi!
I do have CONFIG_X86_PM_TIMER enabled, but it seems by board does not
have such piece of hardware:
[EMAIL PROTECTED]:/usr/src/linux-mm$ dmesg | grep -i "time\|tick\|apic"
PCI: Setting latency timer of device :00:11.5 to 64
[EMAIL PROTECTED]:/usr/src/linux-mm$
If you
El lun, 07-02-2005 a las 16:45 -0500, [EMAIL PROTECTED] escribió:
> On Mon, 07 Feb 2005 20:34:33 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?=
> =?ISO-8859-1?Q?Garc=EDa-Hierro?= said:
>
> > But It's better to give users a "secure-by-default" status, at least on
> > those parts that don't affect
Currently, code exists in the pci layer to allow userspace to specify
driver data when adding a pci dynamic id from sysfs. However, this data
is never used and there exists no way in the existing code to use it.
This patch allows device drivers to indicate that they want driver data
passed to
Michelle Konzack schrieb:
> Am 2005-02-07 09:47:09, schrieb Pozsár Balázs:
> > See? I _have_ that patch applied, that's why it tried vfat and not msdos
> > first.
>
> With this, you will nerver mount a Filesystem "msdos".
>
> Because "vfat" IS "msdos" + "lfn".
>
> You can attach to ALL "msdos"
On Mon, 07 Feb 2005 20:34:33 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?=
=?ISO-8859-1?Q?Garc=EDa-Hierro?= said:
> But It's better to give users a "secure-by-default" status, at least on
> those parts that don't affect negatively the stability or the
> performance itself.
It's still policy, and
him wrote:
> I have run into a problem I am having a hard time figuring out.
>
> I have an MPC7400 SBC (PCI bus based) that has a device X residing
> at the following locations in memory:
>
> 0x1860 - 0x186f device control register space
> 0xb000 - 0xbfff device
On Mon, 2005-02-07 at 08:44 -0600, Chris Friesen wrote:
> Benjamin Herrenschmidt wrote:
> >>It turns out that to call ptep_clear_flush_dirty() on ppc64 from a
> >>module I needed to export the following symbols:
> >>
> >>__flush_tlb_pending
> >>ppc64_tlb_batch
> >>hpte_update
> >
> >
> > Any
On Thu, 3 Feb 2005, IWAMOTO Toshihiro wrote:
> The current implementation of memory hotremoval relies on that pages
> can be unmapped from process spaces. After successful unmapping,
> subsequent accesses to the pages are blocked and don't interfere
> the hotremoval operation.
>
> However, this
Now that we're only invalidating the pages that intersected a direct IO write
we might as well only unmap the intersecting bytes as well. This passed a
light fsx load with page cache, direct, and mmap IO.
Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
---
filemap.c | 12
1
On Sun, Feb 06, 2005 at 03:26:15PM +0100, Jean Delvare wrote:
> Hi Enrico,
>
> Sorry for the delay.
>
> > I have a board with the ALI M7101 chip, but I can't activate it in
> > BIOS. I tried to compile the prog/hotplug/m7101.c but I seen that
> > this is only for 2.4 Kernels. Is there a module
This adds filemap_write_and_wait_range(mapping, lstart, lend) which starts
writeback and waits on a range of pages. We call this from __blkdev_direct_IO
with just the range that is going to be read by the direct_IO read. It was
lightly tested with fsx and ext3 and passed.
Signed-off-by: Zach
>> But this won't happen if next
>>started as 0 and we didn't update it. I don't know if retrying is the
>>intended behaviour or if we care that the start == 0 case doesn't do it.
>
>
> Good point. Let's make it explicit?
Looks great. I briefly had visions of some bitfield to pack the three
Jan Kasprzak wrote:
: I think I have been running 2.6.10-rc3 before. I've copied
: the fs/bio.c from 2.6.10-rc3 to my 2.6.11-rc2 sources and booted the
: resulting kernel. I hope it will not eat my filesystems :-) I will send
: my /proc/slabinfo in a few days.
Hmm, after 3h35min of
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > still wrong. What you get this way is a nice, complicated NOP.
>
> not only a nop but also a likely crash given that i didn't adjust
> the declaration of some_function appropriately ;-). let's cater
> for less complexity too with the following
On Mon, 2005-02-07 at 12:30 -0500, Robert Love wrote:
> Well, I don't share the hatred for ioctl, at least compared to another
> type unsafe interface like write().
>
> But John and I are open to doing whatever is the consensus. If there is
> an agreed alternative, and that is the requirement
Hi!
> > > > We already try to do that, but it hangs on 70% of machines. See
> > > > Documentation/power/video.txt.
> > >
> > > We know that all of these ROMs are run at power on so they have to
> > > work. This implies that there must be something wrong with the
> > > environment the ROM are
1 - 100 of 554 matches
Mail list logo
