On Tuesday 19 April 2005 09:46, YOSHIFUJI Hideaki wrote:
> Please keep using __inline__, not inline.
Updated patch follows.
--
vda
diff -urpN 2.6.12-rc2.1.be/include/asm-i386/bitops.h 2.6.12-rc2.2.ror/include/asm-i386/bitops.h
--- 2.6.12-rc2.1.be/include/asm-i386/bitops.h Tue Oct 19 00:54:36 2004
In article <[EMAIL PROTECTED]> (at Tue, 19 Apr 2005 09:18:10 +0300), Denis
Vlasenko <[EMAIL PROTECTED]> says:
> diff -urpN 2.6.12-rc2.1.be/include/linux/bitops.h
> 2.6.12-rc2.2.ror/include/linux/bitops.h
> --- 2.6.12-rc2.1.be/include/linux/bitops.hMon Apr 18 22:55:10 2005
> +++ 2.6.12-rc2.2.
Remove local 64bit rotation function, use generic one.
Patch is untested.
I believe there is no more 64bit rotations in the kernel.
--
vda
diff -urpN 2.6.12-rc2.3.ws/arch/ia64/kernel/ptrace.c 2.6.12-rc2.4.ia64/arch/ia64/kernel/ptrace.c
--- 2.6.12-rc2.3.ws/arch/ia64/kernel/ptrace.c Mon Apr 18 22:5
While we're at it, fix inconsistent tab/space usage.
No code changes.
--
vda
diff -urpN 2.6.12-rc2.2.ror/crypto/sha512.c 2.6.12-rc2.3.ws/crypto/sha512.c
--- 2.6.12-rc2.2.ror/crypto/sha512.c Mon Apr 18 23:37:20 2005
+++ 2.6.12-rc2.3.ws/crypto/sha512.c Mon Apr 18 23:48:18 2005
@@ -35,42 +35,42 @@ st
this results in following code size changes on i386:
# size sha512_org.o sha512_be.o sha512_ror.o
textdata bss dec hex filename
5339 364 057031647 sha512_org.o
5221 364 0558515d1 sha512_be.o
5122 364 05486156e sha512
This + next patch were "modprobe tcrypt" tested.
See next mail.
--
vda
diff -urpN 2.6.12-rc2.0.orig/crypto/sha512.c 2.6.12-rc2.1.be/crypto/sha512.c
--- 2.6.12-rc2.0.orig/crypto/sha512.c Tue Apr 19 00:20:12 2005
+++ 2.6.12-rc2.1.be/crypto/sha512.c Mon Apr 18 23:31:54 2005
@@ -105,7 +105,7 @@ static
This is done because on 32bit arch gcc generates suboptimal code
from C implementation:
old:
40: 83 ea 80sub$0xff80,%edx
43: 89 95 50 ff ff ff mov%edx,0xff50(%ebp)
49: 8b bd 50 ff ff ff mov0xff50(%ebp),%edi
On Mon, 2005-04-18 at 22:54 -0700, Paul Jackson wrote:
> Now, onto the real stuff.
>
> This same issue, in a strange way, comes up on the memory side,
> as well as on the cpu side.
>
> First, let me verify one thing. I understand that the _key_
> purpose of your patch is not so much to isolate
Takashi Ikebe wrote:
(B
(B>Sorry, I may mistake the point,
(B>Chris Wedgwood wrote:
(B>
(B>
(B>>that would also be a problem for live patching too, if you have bad
(B>>state, you have bad state --- live patching doesn't change that
(B>>
(B>>
(B>What I want to say is takeover may mak
Hmmm ... interesting patch. My reaction to the changes in
kernel/cpuset.c are complicated:
* I'm supposed to be on vacation the rest of this month,
so trying (entirely unsuccessfully so far) not to think
about this.
* This is perhaps the first non-trivial cpuset patch to come
in the la
On Tue, Apr 19, 2005 at 02:19:57PM +0900, Takashi Ikebe wrote:
> What I want to say is takeover may makes memory unstable, because
> there are extra operations to reserve current (unstable) status to
> memory.
mmap is coherent between processes
> Live patching never force target process to reser
modprobe tcrypt hangs the box on both kernels.
The last printks are:
testing wp384
NNUnable to handle kernel paging request at virtual address eXXX
Nothing is printed after this and system locks up solid.
No Sysrq-B.
IIRC, 2.6.9 was okay.
Just a heads-up.
--
vda
-
To unsubscribe from thi
Greetings,
For months I have been reading as much as I can about the current
stable/unstable development model, but still have a question.
Has the Linux Kernel reached a point where the majority of developers feel
that (at least for now) no *MAJOR* "rip it out, stomp on it, burn it and
start
Sorry, I may mistake the point,
(BChris Wedgwood wrote:
(B
(B>>For me, is seems very dangerous to estimate the primary copy is not
(B>>broken through status takeover..
(B>>
(B>>
(B>
(B>that would also be a problem for live patching too, if you have bad
(B>state, you have bad state ---
Christoph,
FYI - Emulex is committed to completing the effort for creating a
vendor-agnostic open-source hbaapi library for linux, including the thornier
issues of performing CT passthru and RNID functionality. As soon as the
library exists, an open-source SMI-S provider would become available
Alright, let's try some small i2c and w1 patches...
Could you merge with:
kernel.org/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/
It contains 4 small patches, 2 i2c and 2 w1 bugfixes, diffstat is
below, I'll figure out how to send the individual patches later.
thanks,
greg k-h
drivers
Theodore Ts'o wrote:
>For one, /dev/urandom and /dev/random don't use the same pool
>(anymore). They used to, a long time ago, but certainly as of the
>writing of the paper this was no longer true. This invalidates the
>entire last paragraph of Section 5.3.
Ok, you're right, this is a serious f
On Tue, Apr 19, 2005 at 11:14:27AM +0900, Takashi Ikebe wrote:
> this makes software developer crazy
are you serious? how is live patching of .text easier than some of
the other suggestions which all are more or less sane and things like
gdb, oprofile, etc. will deal with w/o problems?
patc
On Mon, Apr 18, 2005 at 09:40:37PM +, David Wagner wrote:
> Yes, that is a minor glitch, but I believe all their points remain
> valid nonetheless. My advice is to apply the appropriate s/MD5/SHA1/g
> substitution, and re-read the paper to see what you can get out of it.
>
> The problem is no
On Mon, 18 Apr 2005 00:33:57 -0700
Ashmi Bhanushali <[EMAIL PROTECTED]> wrote:
> hi all..
>
> i m a new bee in lunix kernel. and i m trying to implement "FIFO+"
> queuing for packet forwarding in linux kernel by modifying the
> original code for packet forwarding(FIFO).
The more useful way to do
This patch contains the follwing cleanups:
- make needlessly global code static
- remove obsolete Emacs settings
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/pcmcia/ibmtr_cs.c |3 --
drivers/net/tokenring/3c359.c |3 +-
drivers/net/tokenring/3c359_m
This patch contains the following possible cleanups:
- make some needlessly global code static
- remove the unneeded global function DBG_REG
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/mmc/wbsd.c | 30 --
drivers/mmc/wbsd.h |7 ---
2 files ch
This patch contains the following cleanups:
- make a needlessly global function static
- remove the unneeded global function irport_probe
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/irda/irport.c | 15 +--
1 files changed, 1 insertion(+), 14 deletions(-)
--- li
This patch contains the following cleanups:
- mkiss.c: make a needlessly global variable static
- dmascc.c: remove the unused global function dmascc_setup
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/hamradio/dmascc.c | 10 --
drivers/net/hamradio/mkiss.c |2 +-
This patch makes a needlessly global struct static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.12-rc2-mm3-full/drivers/net/arcnet/capmode.c.old 2005-04-19
03:03:23.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/net/arcnet/capmode.c 2005-04-19
03:03:53.0 +0
This patch makes two needlessly global fimware images static const.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/appletalk/cops_ffdrv.h |2 +-
drivers/net/appletalk/cops_ltdrv.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.12-rc2-mm3-full/driv
Rik van Riel wrote:
(B
(B>On Mon, 18 Apr 2005, Takashi Ikebe wrote:
(B>
(B>
(B>
(B>>I believe process status copy consume more time, may be below sequences are
(B>>needed;
(B>>- Stop the service on ACT-process.
(B>>- Copy on memory/on transaction status to shared memory.
(B>>
(B>>
On Tue, Apr 19, 2005 at 04:03:12AM +0200, Adrian Bunk wrote:
> drivers/net/wireless/hostap/hostap.c:#include "hostap_crypt.c"
> Please do not #include .c files.
A tested patch would be appreciated.. ;-)
> A proper separation in a .c file and a header file is the better
> solution.
Agreed and
On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
>...
> All 819 patches:
>...
> bk-netdev.patch
>...
drivers/net/wireless/hostap/hostap.c:#include "hostap_crypt.c"
drivers/net/wireless/hostap/hostap.c:#include "hostap_ap.c"
drivers/net/wireless/hostap/hostap.c:#include "hostap_info.c
On Tue, 2005-04-19 at 11:07 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2005-04-18 at 14:38 -0500, Linas Vepstas wrote:
> >
> > Hi,
> >
> > The patch below appears to fix a problem where a number of dead processes
> > linger on the system. On a highly loaded system, dozens of processes
> > w
On Mon, Apr 18, 2005 at 10:56:57AM -0500, Tom Zanussi wrote:
> Kingsley Cheung writes:
> > On Wed, Mar 23, 2005 at 08:02:54PM +1100, [EMAIL PROTECTED] wrote:
> > > Hi
> > >
> > > I'm using relayfs to relay data from a kernel module to user space on
> > > a SuSE 2.6.5 kernel. I'm not absolut
Hm, I think I got this set up properly, but don't have an automated
script to generate the changelog and diffstat messages yet, so bear with
me...
Could you merge with:
kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/
It should be against your latest git tree. It contains a number
On Mon, 2005-04-18 at 14:38 -0500, Linas Vepstas wrote:
>
> Hi,
>
> The patch below appears to fix a problem where a number of dead processes
> linger on the system. On a highly loaded system, dozens of processes
> were found stuck in do_exit(), calling thier very last schedule(), and
> then be
On Mon, 2005-04-18 at 14:38 -0500, Linas Vepstas wrote:
>
> Hi,
>
> The patch below appears to fix a problem where a number of dead processes
> linger on the system. On a highly loaded system, dozens of processes
> were found stuck in do_exit(), calling thier very last schedule(), and
> then be
On Wed, 2005-04-13 at 19:21 -0700, Venkatesh Pallipadi wrote:
>
> This adds another timer combination of PIT/HPET to go with
> HPET/HPET, HPET/TSC and PIT/TSC!
> This system that has HPET and doesn't have Legacy support, does it support
> routing HPET interrupts through IOAPIC in standard routing
This patch contains the following possible cleanups:
- make two needlessly global structs static
- #if 0 the EXPORT_SYMBOL'ed but unused function tveeprom_dump
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/video/tveeprom.c |6 --
include/media/tveeprom.h |1
This patch makes a needlessly global struct static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/saa7134/saa7134-dvb.c.old
2005-04-19 01:39:58.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/video/saa7134/saa7134-dvb.c
2005-04-
This patch makes a needlessly global function static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.12-rc2-mm3-full/drivers/media/common/saa7146_fops.c.old
2005-04-19 01:21:37.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/common/saa7146_fops.c
2005-04-19 01:
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/md/dm-hw-handler.c|2 +-
drivers/md/dm-path-selector.c |2 +-
drivers/md/dm-table.c |2 +-
drivers/md/dm-zero.c |4 ++--
drivers/md/md.c
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/isdn/hardware/eicon/dadapter.c |2 +-
drivers/isdn/hisax/hfc4s8s_l1.c|4 ++--
drivers/isdn/hysdn/hycapi.c| 20 +++-
drivers/isdn/hysdn/hy
This patch contains the following possible cleanups:
- #if 0 the following unused global functions:
- hpsb_lock
- hpsb_send_gasp
- ieee1394_transactions.h: remove the stale hpsb_lock64 prototype
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/ieee1394/ieee1394_transactions.c |
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global functions:
- dibusb/dvb-dibusb-usb.c: dibusb_set_streaming_mode
- frontends/mt352.c: mt352_read
- ttpci/av7110_hw.c: av7110_reset_arm
- ttpci/av7110_hw.c: av7110_sen
This patch contains the following possible cleanups:
- make needlessly global code static
- remove the following unneeded EXPORT_SYMBOL:
- cx88-core.c: cx88_pci_irqs
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/video/cx88/cx88-core.c |5 ++---
drivers/media/video/cx88
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/video/bttv-driver.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/bttv-driver.c.old
2005-04-19 01:3
This patch contains the following cleanups:
- make the needlessly global function seeq8005_init static
- kill an ancient version variable
- remove some outdated Emacs settings
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 21 Feb 2005
drivers/net/seeq8005.
This patch contains the following cleanups:
- make two needlessly global functions static
- kill an ancient version variable
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/ne3210.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
--- linux-2.6.11-rc3-mm2-full/
On Mon, Apr 18, 2005 at 12:14:06PM -0500, Miller, Mike (OS Dev) wrote:
> > From: Christoph Hellwig [mailto:[EMAIL PROTECTED]
> >
> > This looks like a patch for Linux 2.4. Such major changes for the
> > 2.4 tree don't make sense anymore, especially for
> > functionality not even in Linux 2.6.
>
Hi Andrew,
This patch against kernel 2.6.12-rc2 adds missing button codes for the
Leadtek Winfast remote controls.
Concerning the KEY_* values, I tried to be coherent with the other
remote controls supported by the kernel.
Best regards,
Nicolas
--
Add missing button codes for the Leadtek Winf
Hello.
I've been trying to run Fedora Core 3 on dual P3 machine (Asus P2B-DS board,
Intel BX chipset), but every time I try to boot it, it hangs moments after
mounting local filesystems. It doesn't really matter if I boot SMP or non-SMP
kernel and I've tried several, from 2.6.9 to latest 2.6.11
Dinakar Guniguntala wrote:
Here's an attempt at dynamic sched domains aka isolated cpusets
Very good, I was wondering when someone would try to implement this ;)
It needs some work. A few initial comments on the kernel/sched.c change
- sorry, don't have too much time right now...
--- linux-2.6.12-r
On Sat, Apr 16, 2005 at 11:46:13AM -0700, Paul Ionescu wrote:
>
> Was this setup supposed to work ?
>
Not yet, sorry. This patch was simply decoupling the power state
of the device from its physical presence in the slot. It had
nothing to do about programming p2p bridges and subordinate
devices
James Bottomley wrote:
> On Tue, 2005-04-19 at 07:31 +0900, Tejun Heo wrote:
>
>> The original code also uses timer pending status as a signal that
>>command completed normally in scsi_eh_done() function, and the same
>>race also exists in the original code, no matter what we do, unless we
>>make
On Wed, 2005-04-13 at 12:45 +, Paul Slootman wrote:
> Phil Oester <[EMAIL PROTECTED]> wrote:
> >On Sat, Mar 26, 2005 at 03:10:05PM +, Russell King wrote:
> >> Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages
> >> ago) changes the prescaler setting for this device so w
On Tue, 2005-04-19 at 07:31 +0900, Tejun Heo wrote:
> The original code also uses timer pending status as a signal that
> command completed normally in scsi_eh_done() function, and the same
> race also exists in the original code, no matter what we do, unless we
> make timer expiration and removal
Hello, James.
On Mon, Apr 18, 2005 at 10:33:21AM -0500, James Bottomley wrote:
> On Mon, 2005-04-11 at 03:45 +0900, Tejun Heo wrote:
> > scmd->eh_timeout is used to resolve the race between command
> > completion and timeout. However, during error handling,
> > scsi_send_eh_cmnd uses
On Mon, 18 Apr 2005 11:56:15 +0200, Alexander Nyberg wrote:
>> >This patch fixes the NMI checking problems in -mm x64 for me. It
>>
>> What problems?
>>
>
>Sorry, in -mm on x64 check_nmi_watchdog() has started to be run as a
>late_initcall(). Currently it reports the NMIs as stuck on a few syste
On Sun, Apr 17, 2005 at 10:26:43PM +0200, Daniel Ritz wrote:
> from your dmesg:
> PCI: :00:0b.0 pmc: 7601, current_state, pmcsr: 00040, new:
> ACPI: PCI Interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
> 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> 000
On Mon, 2005-04-18 at 19:00 +0100, Stephen C. Tweedie wrote:
> > > Note that there _is_ some additional complexity here. It's not entirely
> > > free. Specifically, if we have other tasks waiting on our provisional
> > > window, then we need to be very careful about the life expectancy of the
>
This patch lacked a small bit.
Updated patch below.
cu
Adrian
<-- snip -->
This patch makes needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/usb/media/pwc/pwc-ctrl.c | 78 +++
drivers/usb/media/pwc/pwc-if.c |2
hello,
I'm trying to mount root filesystem on cramfs (2.6.11,
compiled with mtd and CRAMFS support), however I get
following well known error message:
VFS: Cannot open root device "mtdblock1" or
unknown-block(31,1)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unabl
On Mon, Apr 18, 2005 at 01:55:06PM +0100, Alan Cox wrote:
> On Llu, 2005-04-18 at 00:47, Adrian Bunk wrote:
> > Are there any external drivers using these exports, and if there are,
> > why aren't they in the kernel?
>
> Its a standard API
>
> > If there aren't and someone will at some time in t
Matt Mackall wrote:
>On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote:
>> http://eprint.iacr.org/2005/029
>
>Unfortunately, this paper's analysis of /dev/random is so shallow that
>they don't even know what hash it's using. Almost all of section 5.3
>is wrong (and was when I read it in
Lorenzo Hernández García-Hierro wrote:
>El lun, 18-04-2005 a las 15:05 -0400, Dave Jones escribió:
>> This is utterly absurd. You can find out anything thats in /proc/cpuinfo
>> by calling cpuid instructions yourself.
>> Please enlighten me as to what security gains we achieve
>> by not allowing
On Mon, 18 Apr 2005 20:07:04 +0200, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?=
=?ISO-8859-1?Q?Garc=EDa-Hierro?= said:
> The limit is only checked when process is created on a fork() call, but
> during execution it's uid can change, thus, the limit for the new uid
> could be exceed.
The only two ways
On 18 Apr 2005, at 19:14, Greg KH wrote:
Care to redo them, add a signed-off-by: line and send them to the
linux-usb-devel mailing list and CC: the hid maintainer?
All done. Sorry for the inconvenience.
--
Andy Armstrong, hexten.net
-
To unsubscribe from this list: send the line "unsubscribe linux-
Hi Derek,
My comments on your code:
> +Changes:
> +v0.1 26 March 2005
> + Initial Release - developed on uClinux with 2.6.9 kernel
> +v0.2 11 April 2005
> + Coding style changes
> +
Changelogs are not welcome in kernel code.
> +#include
> +#include
On Mon, 18 Apr 2005, Jesper Juhl wrote:
> This patch adds a new function valid_signal() that tests if its argument
> is a valid signal number.
>
> The reasons for adding this new function are:
> - some code currently testing _NSIG directly has off-by-one errors. Using
> this function instead
The patch below converts most of the current code that uses _NSIG directly
to instead use the valid_signal() function added by the previous patch.
This avoids gcc -W warnings and off-by-one errors and it's also nice and
readable, no doubt about what the code tests.
Signed-off-by: Jesper Juhl <[E
This patch adds a new function valid_signal() that tests if its argument
is a valid signal number.
The reasons for adding this new function are:
- some code currently testing _NSIG directly has off-by-one errors. Using
this function instead avoids such errors.
- some code currently tests unsi
On Mon, 2005-04-18 at 22:18 +0200, Lorenzo HernÃndez GarcÃa-Hierro
wrote:
> For this purpose I (re)submitted a patch originally made by Serge E.
> Hallyn that adds a hook in order to catch task lookups, thus, providing
> an easy way to handle and determine when a task can lookup'ed.
>
> It's at:
>
Dave Jones writes the following:
>
>On Mon, Apr 18, 2005 at 08:46:52PM +0200, Lorenzo Hernández García-Hierro
>wrote:
> > This patch changes the permissions of the following procfs entries to
> > restrict non-root users from accessing them:
[snip]
> > - /proc/uptime
?!
[snip]
El lun, 18-04-2005 a las 16:01 -0400, Rik van Riel escribió:
> On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote:
>
> > Adding a "trusted user group"-like configuration option could be useful,
> > as it's done within grsecurity, among that the whole thing might be good
> > to depend on a
On Wed, Apr 13, 2005 at 12:45:51PM +, Paul Slootman wrote:
> We have a variety of Dell rackmount systems, also on Cyclades, and see
> this mess everywhere.
>
> I had reported this problem a little while ago, see
> http://marc.theaimsgroup.com/?l=linux-kernel&m=111036598927105&w=2
> but unfortu
Arjan van de Ven wrote:
you just said that you didn't care that it got munlock'd. So you don't
care that it gets freed either. And then reused.
Well, I can live with the app being able to call munlock(), because the apps that our
customers use don't call munlock(). What I can't live with is a bug
El lun, 18-04-2005 a las 15:24 -0400, Rik van Riel escribió:
> This looks like a very bad default to me!
>
> Your patch would force people to run system monitoring
> applications as root, because otherwise they cannot get
> some of the information they can get now. Forcing that
> these applicatio
Here's an attempt at dynamic sched domains aka isolated cpusets
o This functionality is on top of CPUSETs and provides a way to
completely isolate any set of CPUs dynamically.
o There is a new cpu_isolated flag that allows users to convert
an exclusive cpuset to an isolated one
o The iso
On 18 Apr 2005, at 19:14, Greg KH wrote:
Your patches are line-wrapped, and the tabs were stripped out :(
Ah poop - sorry about that. I'm using the Mac mail client which managed
to give me the impression it was going to send them clean.
Care to redo them, add a signed-off-by: line and send them t
On Mon, Apr 18, 2005 at 09:40:40PM +0200, Arjan van de Ven wrote:
>On Mon, 2005-04-18 at 11:25 -0500, Timur Tabi wrote:
>> Arjan van de Ven wrote:
>>
>> > this is a myth; linux is free to move the page about in physical memory
>> > even if it's mlock()ed!!
darn, yes, this is true.
I know people wh
On Mon, Apr 18, 2005 at 05:41:46PM +0100, Andy Armstrong wrote:
> For those who haven't seen it the Cherry CyMotion Linux keyboard is a
> decent quality keyboard with the Windows specific keys replaced with
> Linux keys. It's got a nice little picture of Tux on it too. The
> supplied patches are
On Mon, 2005-04-18 at 15:00 -0500, Timur Tabi wrote:
> Arjan van de Ven wrote:
>
> > you should since that physical page can be reused, say by a root
> > process, and you'd be majorly screwed
>
> I don't understand what you mean by "reused". The whole point behind pinning
> the memory
> is tha
On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote:
> Adding a "trusted user group"-like configuration option could be useful,
> as it's done within grsecurity, among that the whole thing might be good
> to depend on a config. option, but that implies using weird ifdef's and
> the other fo
Arjan van de Ven wrote:
you should since that physical page can be reused, say by a root
process, and you'd be majorly screwed
I don't understand what you mean by "reused". The whole point behind pinning the memory
is that it stays where it is. It doesn't get moved around and it doesn't get swap
On Mon, Apr 18, 2005 at 02:48:41PM +0200, Rao Davide wrote:
> Is LVM working on the alpha port 2.6 kernel series ?
works fine for me.
> If so where do I get libdevmapper so that I can build the userspace LVM
> utils ?
>
> I tryied downloading
> ftp://sources.redhat.com/pub/dm/multipath-toolsmu
El lun, 18-04-2005 a las 12:26 -0700, David S. Miller escribió:
> Stephen Hemminger has already added TCP port randomization on
> connect() to the 2.6.x tree. See
> net/ipv4/tcp_ipv4.c:tcp_v4_hash_connect(), where randomized port
> selection occurs. And unlike your patch, Stephen did add ipv6
> s
El lun, 18-04-2005 a las 15:05 -0400, Dave Jones escribió:
> This is utterly absurd. You can find out anything thats in /proc/cpuinfo
> by calling cpuid instructions yourself.
Right, it doesn't make it worthy enough to represent any risk.
> Please enlighten me as to what security gains we achieve
El lun, 18-04-2005 a las 15:27 -0400, Rik van Riel escribió:
> The same "this forces people to run system monitoring tasks
> as root, potentially opening themselves up to security holes"
> comment applies to this patch.
That's because the patch is split up, those bits are on the proc_misc
one.
I
On Mon, 2005-04-18 at 11:25 -0500, Timur Tabi wrote:
> Arjan van de Ven wrote:
>
> > this is a myth; linux is free to move the page about in physical memory
> > even if it's mlock()ed!!
>
> Then Linux has a very odd definition of the word "locked".
>
> > And even then, the user can munlock the m
On Mon, 2005-04-18 at 20:56 +0200, Terje Malmedal wrote:
> [Arjan van de Ven]
> >> > but also about doing things at the right layer. The syscall layer is
> >> > almost NEVER the right layer.
> >> >
> >> > Can you explain exactly what you are trying to do (it's not a secret I
> >> > assume, kernel
Hi,
The patch below appears to fix a problem where a number of dead processes
linger on the system. On a highly loaded system, dozens of processes
were found stuck in do_exit(), calling thier very last schedule(), and
then being lost forever.
Processes that are PF_DEAD are cleaned up *after
Stephen Hemminger has already added TCP port randomization on
connect() to the 2.6.x tree. See
net/ipv4/tcp_ipv4.c:tcp_v4_hash_connect(), where randomized port
selection occurs. And unlike your patch, Stephen did add ipv6
support (via net/ipv6/tcp_ipv6.c:tcp_v6_hash_connect()) for
port randomiza
On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote:
> - /proc/ioports
> - /proc/iomem
> - /proc/devices
> - /proc/cmdline
> - /proc/version
> - /proc/uptime
> - /proc/cpuinfo
> - /proc/partitions
> - /proc/stat
> - /proc/interrupts
> - /proc/slabinfo
> - /proc/diskstats
> - /proc/modules
>
On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote:
> This patch changes the permissions of the procfs entry config.gz, thus,
> non-root users are restricted from accessing it.
Why?
What is the security benefit of doing this ?
--
"Debugging is twice as hard as writing the code in the
On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote:
> This patch changes the permissions of the /proc/bus/pci directory entry,
> so, non-root users are restricted of accessing it's content.
> It's also available at:
> http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_drivers_pci_
On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote:
> This patch restricts non-root users to view only their own processes.
This looks like a very bad default to me!
Your patch would force people to run system monitoring
applications as root, because otherwise they cannot get
some of the
Terje Malmedal wrote:
Every so often there is bug in the kernel, by patching the
syscall-table I have been able to fix bugs in ioperm and fsync without
rebooting the box.
What do I do the next time I need to do something like this?
Nothing.
You have to understand that the kernel develope
[please reply to all when posting to lkml]
On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote:
> >First, a reminder that the design goal of /dev/random proper is
> >information-theoretic security. That is, it should be secure against
> >an attacker with infinite computational power.
>
Hi,
"When source port is generated on the fly for the TCP protocol (ie. with
connect() ) will
be altered so that the source port is generated at random, instead of a simple
incrementing algorithm."
Ported from grsecurity (http://www.grsecurity.net by Brad Spengler).
Instead of using the PaX & gr
On Mon, Apr 18, 2005 at 04:42:26PM +0100, Christoph Hellwig wrote:
> This looks like a patch for Linux 2.4. Such major changes for the
> 2.4 tree don't make sense anymore, especially for functionality not
> even in Linux 2.6.
Agreed.
-
To unsubscribe from this list: send the line "unsubscribe li
On Mon, Apr 18, 2005 at 08:46:52PM +0200, Lorenzo Hernández García-Hierro wrote:
> This patch changes the permissions of the following procfs entries to
> restrict non-root users from accessing them:
>
> - /proc/devices
> - /proc/cmdline
> - /proc/version
> - /proc/uptime
> - /proc/c
This patch changes the permissions of the procfs entries ioports and
iomem to restrict non-root users from accessing them.
It's also available at
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_kernel_resource.c.patch.
(last patch from the procfs privacy patch-set)
The whole patch is
1 - 100 of 241 matches
Mail list logo
