headers
devzero | 1 May 2006 01:07
Picon

Re: another kconfig target for building monolithic kernel (for security) ?

hello !

thanks for help -  i found that there seems another way for securing /dev/{k}mem (at least in recent kernels)
- the docomentation for the "BSD Secure Levels Linux Security Module" (at  Documentation/seclvl.txt) tells:

Level 1 (Default):
- /dev/mem and /dev/kmem are read-only
- IMMUTABLE and APPEND extended attributes, if set, may not be unset
- Cannot load or unload kernel modules
- Cannot write directly to a mounted block device
- Cannot perform raw I/O operations
- Cannot perform network administrative tasks
- Cannot setuid any file

so - no need for compiling a static/monolithic kernel anymore !?

regards
roland

> -----Ursprüngliche Nachricht-----
> Von: Nix <nix <at> esperi.org.uk>
> Gesendet: 30.04.06 12:57:49
> An: Arjan van de Ven <arjan <at> infradead.org>
> CC: davej <at> redhat.com, linux-kernel <at> vger.kernel.org
> Betreff: Re: another kconfig target for building monolithic kernel (for security) ?

> On 29 Apr 2006, Arjan van de Ven prattled cheerily:
> > On Sat, 2006-04-29 at 12:43 -0400, Dave Jones wrote:
> >> On Sat, Apr 29, 2006 at 03:03:55PM +0200, devzero <at> web.de wrote:
> >>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric W. Biederman | 1 May 2006 01:17
Favicon

Re: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision

"Protasevich, Natalie" <Natalie.Protasevich <at> UNISYS.com> writes:

>> >But I guess using GSI/vector internally only would be fine.
>> 
>> The last time I tried to name a variable "gsi" instead of "irq",
>> Linus launched into a tirade that "GSI" doesn't mean anything to him,
>> or anybody else that googles it.  On the other hand "IRQ" means
>> something
>> to everybody, and if you google it you find all kinds of interesting
>> interrupt-related things.
>> 
>> My point was that "IRQ" means so many "interrupt related" things to
>> different people in different contexts, that it is effectively
>> meaningless.
>> 
>> But Linus was not swayed.
>> 
>
> Oh Len, let's call this thing IRQ why not ;) I kind of agree that this
> is more popular and well-known term, like an old trade mark. I just see
> all those layers of code right now to map those to GSIs, pins, whatever
> it is, that can be replaced with... well, much smaller layers of code :)
> and maybe less "assumpti-ous" too.

The original IRQ (on x86) was simply the enumeration of the input
pins on the pair of i8259 interrupt controllers.

The ACPI global system interrrupts is the enumeration of the input
pins on the ioapics in the system.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Vrabel | 1 May 2006 01:40
Favicon

Re: IP1000 gigabit nic driver

Pekka Enberg wrote:
> On Sat, 2006-04-29 at 14:21 +0200, David Gómez wrote:
>>> I already had it modified, just needed to create the patch... Anyway,
>>> have you submitted it to netdev?
> 
> On Sat, 2006-04-29 at 23:35 +0300, Pekka Enberg wrote:
>> No, I haven't. I don't have the hardware, so I can't test the driver.
>> Furthermore, there's plenty of stuff to fix before it's in any shape for
>> submission. If someone wants to give this patch a spin, I would love to
>> hear the results.

Thanks for doing this Pekka.  I've fixed up some stuff and given it some 
brief testing on a 100BaseT network and it seems to work now.

> Subject: [PATCH] IP1000 Gigabit Ethernet device driver
> 
> This is a cleaned up fork of the IP1000A device driver:
> 
>   <http://www.icplus.com.tw/driver-pp-IP1000A.html>
> 
> Open issues include but are not limited to:
> 
>   - ipg_probe() looks really fishy and doesn't handle all errors
>     (e.g. ioremap failing).
>   - ipg_nic_do_ioctl() is playing games with user-space pointer.
>     We should use ethtool ioctl instead as suggested by Arjan.

Still pending.  Also:

     - something (PHY reset/auto negotiation?) takes 2-3 seconds and
(Continue reading)

Permalink | Reply | 70 comments |
headers
Stefan Richter | 1 May 2006 01:40
Picon

Re: How to replace bus_to_virt()?

Arjan van de Ven wrote:
> On Sun, 2006-04-30 at 16:52 +0200, Stefan Richter wrote:
>>is there a *direct* future-proof replacement for bus_to_virt()?
>>
>>It appears there are already architectures which do not define a 
>>bus_to_virt() funtion or macro. If there isn't a direct replacement, is 
>>there at least a way to detect at compile time whether bus_to_virt() exists?
> 
> 
> I'd go one step further: given a world with iommu's, and multiple pci
> domains etc, how can you know there even IS such a translation possible
> (without first having set it up from the other direction)?

Well, we actually do set it up from the other direction. But in a way 
that does not work with IOMMUs...

AFAIU, the patch "dc395x: dynamically map scatter-gather for PIO" [1] by 
Guennadi Liakhovetski is dealing with the same issue. I am not yet clear 
whether I could adopt this method for sbp2.
[1] http://marc.theaimsgroup.com/?l=linux-scsi&t=114400790300004
--

-- 
Stefan Richter
-=====-=-==- -=-= ----=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 6 comments |
headers
Chris Wedgwood | 1 May 2006 02:01

Re: [BUG] VIA quirk fixup failure after 2.6.17-rc3

On Sun, Apr 30, 2006 at 09:28:20AM -0700, masouds <at> masoud.ir wrote:

> My machine's tulip card stopped working after I updated to 2.6.17-rc3.git3
> which included 75cf7456dd87335f574dcd53c4ae616a2ad71a11 patch of
> yours. Revesing it made the problem go away; Is there a chance that a VIA
> pci_id was missed from the list of quirks in your patch?

it sounds like it

i just grepped the pci_ids.h again and didn't see one missing, could you
also send me the output of "lspci -n" please?
Permalink | Reply | 0 comments |
headers
Nathan Scott | 1 May 2006 02:24
Picon
Favicon

Re: Bad page state in process 'nfsd' with xfs

On Sun, Apr 30, 2006 at 05:19:56PM +0200, Zoltan Boszormenyi wrote:
> ...
> Or not. I had an FC3/x86-64 system until two days ago, now I have FC5/86-64.
> 
> When FC3 was installed I chose to format the partitions to XFS and since 
> then
> I had Oopses regularly with or without VMWare modules.

What was the stack trace for your oops...?

cheers.

--

-- 
Nathan
Permalink | Reply | 3 comments |
headers
Randy.Dunlap | 1 May 2006 02:44

[PATCH] CodingStyle: add typedefs chapter

From: Randy Dunlap <rdunlap <at> xenotime.net>

Add a chapter on typedefs, copied from an email from Linus
to lkml on Feb. 3, 2006.
(Subject: Re: [RFC][PATCH 1/5] Virtualization/containers: startup)

Signed-off-by: Randy Dunlap <rdunlap <at> xenotime.net>
---
 Documentation/CodingStyle |   77 ++++++++++++++++++++++++++++++++++++++--------
 1 files changed, 65 insertions(+), 12 deletions(-)

--- linux-2617-rc3.orig/Documentation/CodingStyle
+++ linux-2617-rc3/Documentation/CodingStyle
 <at>  <at>  -155,7 +155,60  <at>  <at>  problem, which is called the function-gr
 See next chapter.

 
-		Chapter 5: Functions
+		Chapter 5: Typedefs
+
+Please don't use things like "vps_t".
+
+It's a _mistake_ to use typedef for structures and pointers. When you see a
+
+	vps_t a;
+
+in the source, what does it mean?
+
+In contrast, if it says
+
(Continue reading)

Permalink | Reply | 33 comments |
headers
Pavel Roskin | 1 May 2006 02:59
Picon

Re: Removing .tmp_versions considered harmful

Hello, Sam!

On Sun, 2006-04-30 at 23:47 +0200, Sam Ravnborg wrote:
> On Mon, Apr 24, 2006 at 03:55:27PM -0400, Pavel Roskin wrote:
> > Remove *.mod files but not .tmp_versions for external builds
> > 
> > From: Pavel Roskin <proski <at> gnu.org>
> > 
> > When "make install" is run as root, .tmp_versions is re-created and
> > becomes owned by root.  Subsequent "make" run by user fails because
> > .tmp_versions cannot be removed.
> 
> What architecture?
> For i386 and x86_64 make install no longer try to compile the kernel.

That's x86_64.  It turns out the dependency of "install" on "all" in the
project Makefile was causing .tmp_versions to be re-created.  Removing
the dependency on "all" fixes the problem.  This is the original rule:

install: all
        $(MAKE) $(KBUILD_FLAGS) modules_install \
                INSTALL_MOD_DIR=kernel/drivers/net/wireless
        $(DEPMOD) -ae

However, I'd rather keep the dependency of "install" on "all".  It's
better to compile a few files as root than to install out-of-date
modules.  I'm glad that your patch gives me a choice how to write the
project's Makefile.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nigel Cunningham | 1 May 2006 03:49

Re: [RFC][PATCH] swsusp: support creating bigger images

Hi.

Sorry for the slow response - I only have internet access at work now. This is 
going to be a pattern for the next few weeks - I'm off work next week and.the 
week after I'll also be off apart from Monday and Tuesday (those are my last 
two days working for Cyclades - I then get my sweetheart and little one back, 
and we drive down to Victoria over the rest of the week).

On Sunday 30 April 2006 22:27, Rafael J. Wysocki wrote:
> Hi,
>
> On Wednesday 26 April 2006 02:49, Nigel Cunningham wrote:
> > On Wednesday 26 April 2006 08:43, Rafael J. Wysocki wrote:
> > > On Wednesday 26 April 2006 00:25, Pavel Machek wrote:
> > > > > > It does apply to all of the LRU pages. This is what I've been
> > > > > > doing for years now. The only corner case I've come across is
> > > > > > XFS. It still wants to write data even when there's nothing to do
> > > > > > and it's threads are frozen (IIRC - haven't looked at it for a
> > > > > > while). I got around that by freezing bdevs when freezing
> > > > > > processes.
> > > > >
> > > > > This means if we freeze bdevs, we'll be able to save all of the LRU
> > > > > pages, except for the pages mapped by the current task, without
> > > > > copying.  I think we can try to do this, but we'll need a patch to
> > > > > freeze bdevs for this purpose. ;-)
> > > >
> > > > ...adding more dependencies to how vm/blockdevs work. I'd say current
> > > > code is complex enough...
> > >
> > > Well, why don't we see the patch?  If it's too complex, we can just
(Continue reading)

Permalink | Reply | 2 comments |
headers
Oleg Nesterov | 1 May 2006 08:59
Picon

splice(SPLICE_F_MOVE) problems

I noticed sys_splice() and friends were added. Cool!
But I can't understand how SPLICE_F_MOVE is supposed to
work.

	pipe_to_file:

		if (sd->flags & SPLICE_F_MOVE) {

			if (buf->ops->steal(info, buf))
				goto find_page;

Let's suppose that buf->ops == page_cache_pipe_buf_ops.
page_cache_pipe_buf_steal() returns PG_locked page, why?

			page = buf->page;
			if (add_to_page_cache(page, mapping, index, gfp_mask))

This adds entire page to page cache. What about partial pages?
This can corrupt sd->file if offset != 0 || this_len != PAGE_SIZE.

				goto find_page;

Ok, add_to_page_cache() failed. 'page' is still locked.
It will be released later, this should trigger bad_page().

Also, we don't clear PIPE_BUF_FLAG_STOLEN, so we will miss
the data copying and page_cache_release(page) below:

		if (!(buf->flags & PIPE_BUF_FLAG_STOLEN)) {
			char *dst = kmap_atomic(page, KM_USER0);
(Continue reading)

Permalink | Reply | 9 comments |

Gmane