headers
Lennert Buytenhek | 1 Jul 2007 01:17

Re: [PATCH] b44: power down PHY when interface down

On Sun, Jul 01, 2007 at 12:24:40AM +0200, Michael Buesch wrote:

> > > Hm, I was going to measure the real power advantage with a
> > > PCI-extender card. But my B44B0 card doesn't seem to work in
> > > that extender card. It works perfectly fine sticked directly into
> > > the motherboard, though, and other cards like a BCM4318 work in
> > > the extender, too.
> > > Not sure what this is.
> > > The extender has an application note about nonworking cards in the
> > > extender and a too big resistor on the board IDSEL pin being the
> > > cause of this.
> > 
> > Does the card show up in lspci at all?
> 
> No it doesn't.

Right, so it sounds like it might be this issue.

> > Does the extender board have a PCI-PCI bridge on it?  (If not,
> > there's not really any reason to resistively couple the IDSEL
> > line to the host, since the host should take care of that.)
> 
> There's no bridge. It just decouples all voltage lines, so you can
> drive it from external supply and/or measure voltages and current.
> On the PCB it looks like the the IDSEL line is rather directly
> routed to the host IDSEL. It just goes through one of the bus
> isolation chips. So I guess (just my guess) that this chip has some
> resistance and if the total resistance of the chip + the IDSEL
> resistor on the mainboard goes above some threshold it doesn't work
> anymore for some cards. In the application note they write
(Continue reading)

Permalink | Reply | 11 comments |
headers
Jesper Juhl | 1 Jul 2007 01:01
Picon

[PATCH][ISDN][resend] fix possible NULL deref on low memory condition in capidrv.c::send_message()

(first send: Monday 25 June 2007, resending due to no response)

If we fail to allocate an skb in 
drivers/isdn/capi/capidrv.c::send_message(), then we'll end up 
dereferencing a NULL pointer.
Since out of memory conditions are not unheard of, I believe it 
is better to print a error message and just return rather than 
bring down the whole kernel. 
Sure, doing this may upset some application, but that's still 
better than crashing the whole system.

(ps. please Cc me on replies from the isdn4linux list since I'm not subscribed 
 there)

Signed-off-by: Jesper Juhl <jesper.juhl <at> gmail.com>
---

 drivers/isdn/capi/capidrv.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/isdn/capi/capidrv.c b/drivers/isdn/capi/capidrv.c
index 23b6f7b..476012b 100644
--- a/drivers/isdn/capi/capidrv.c
+++ b/drivers/isdn/capi/capidrv.c
 <at>  <at>  -506,9 +506,14  <at>  <at>  static void send_message(capidrv_contr * card, _cmsg * 
cmsg)
 {
 	struct sk_buff *skb;
 	size_t len;
+
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jesper Juhl | 1 Jul 2007 01:05
Picon

[PATCH][Documentation][resend] Add missing files and dirs to 00-INDEX in Documentation/

(originally send: Wed, 6 Jun 2007, resending since it doesn't seem to have 
been picked up anywhere)

This patch adds descriptions for a number of missing files and directories 
to the Documentation/00-INDEX file.
People really should learn to keep this file up-to-date when adding or 
moving documentation...

Signed-off-by: Jesper Juhl <jesper.juhl <at> gmail.com>
---

 Documentation/00-INDEX |  142 
+++++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 133 insertions(+), 9 deletions(-)

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index f08ca95..8b05636 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
 <at>  <at>  -12,6 +12,8  <at>  <at>  Following translations are available on the WWW:

 00-INDEX
 	- this file.
+ABI/
+	- info on kernel <-> userspace ABI and relative interface stability.
 BUG-HUNTING
 	- brute force method of doing binary search of patches to find bug.
 Changes
 <at>  <at>  -25,37 +27,57  <at>  <at>  DMA-mapping.txt
 DocBook/
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jesper Juhl | 1 Jul 2007 01:16
Picon

[PATCH][XFS][resend] fix memory leak in xfs_inactive()

(this is back from May 16 2007, resending since it doesn't look like 
the patch ever made it in anywhere)

The Coverity checker found a memory leak in xfs_inactive().

The offending code is this bit :

1671            tp = xfs_trans_alloc(mp, XFS_TRANS_INACTIVE);

At conditional (1): "truncate != 0" taking true path

1672            if (truncate) {
1673                    /*
1674                     * Do the xfs_itruncate_start() call before
1675                     * reserving any log space because itruncate_start
1676                     * will call into the buffer cache and we can't
1677                     * do that within a transaction.
1678                     */
1679                    xfs_ilock(ip, XFS_IOLOCK_EXCL);
1680
1681                    error = xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE, 0);

At conditional (2): "error != 0" taking true path

1682                    if (error) {
1683                            xfs_iunlock(ip, XFS_IOLOCK_EXCL);

Event leaked_storage: Returned without freeing storage "tp"
Also see events: [alloc_fn][var_assign]
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jesper Juhl | 1 Jul 2007 01:16
Picon

[PATCH][XFS][resend] memory leak; allocated transaction not freed in xfs_inactive_free_eofblocks() in failure case.

(this is back from May 16 2007, resending since it doesn't look like 
the patch ever made it in anywhere)

Fix XFS memory leak; allocated transaction not freed in xfs_inactive_free_eofblocks() in failure case.

the code allocates a transaction, but in the case where 'truncate' is
!=0 and xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE, 0); happens to return
an error, we'll just return from the function without dealing with the
memory allocated byxfs_trans_alloc() and assigned to 'tp', thus it'll be
orphaned/leaked - not good.

Signed-off-by: Jesper Juhl <jesper.juhl <at> gmail.com>
--- 
 fs/xfs/xfs_vnodeops.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/xfs/xfs_vnodeops.c b/fs/xfs/xfs_vnodeops.c
index de17aed..32519cf 100644
--- a/fs/xfs/xfs_vnodeops.c
+++ b/fs/xfs/xfs_vnodeops.c
 <at>  <at>  -1260,6 +1260,7  <at>  <at>  xfs_inactive_free_eofblocks(
 		error = xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE,
 				    ip->i_size);
 		if (error) {
+			xfs_trans_cancel(tp, 0);
 			xfs_iunlock(ip, XFS_IOLOCK_EXCL);
 			return error;
 		}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michal Piotrowski | 1 Jul 2007 01:33
Picon

Re: [possible regression] 2.6.22 reiserfs/libata sporadically hangs on resume from hibernation

Andrey Borzenkov pisze:
> On Sunday 01 July 2007, Rafael J. Wysocki wrote:
>> On Saturday, 30 June 2007 06:59, Andrey Borzenkov wrote:
>>> Since 2.6.18 I do not have suspend to RAM; now I am starting to lose
>>> suspend to disk :)
>>>
>>> Environment - vanilla kernel (2.6.22-rc6 currently + squashfs + single
>>> pata_ali patch to switch off DMA on CD-ROM), single root on reiserfs,
>>> libata with pata_ali driver.
>>>
>>> Until 2.6.22-rc I never had problems with hibernation. With 2.6.22-rc
>>> system hung at least once in every rcX. Up to rc6 those lockups were
>>> absolutely silent (black screen without reaction to any key). In rc6 I
>>> just got something different. After resume I got on screem:
>>>
>>> swsusp: Marking nosave pages: 000000000009f000-0000000000100000
>>> swsusp: Basic memory bitmaps created
>>> swsusp: Basic memory bitmaps freed
>>>
>>> After that it just sits there doing nothing. Ther was brief sound of HDD
>>> but I suspect it was related more to power-on. System was responding to
>>> power-on button press:
>>>
>>> ACPI Error (event-0305): No installed handler for fixed event [00000002
>>> 20070125]
>>>
>>> And SysRq was functioning.
>> That probably means that there's a deadlock somewhere in there.
>>
>>> Unfortunately I do not have serial console so I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jesper Juhl | 1 Jul 2007 01:38
Picon

[PATCH][isapnp] Fix a potential NULL pointer dereference in isapnp_read_tag()

The Coverity checker spotted (as bug #809) that we dereference 'type' 
long before we actually test it against NULL in 
drivers/pnp/isapnp/core.c::isapnp_read_tag() - both branches of the 
'if (tag & 0x80)' dereference type, and since this 'if' is before the test 
against NULL and the return of -1, this will blow up is ever type is NULL.
This is easy to fix by simply moving the NULL test to the beginning of 
the function.

Signed-off-by: Jesper Juhl <jesper.juhl <at> gmail.com>
---

 drivers/pnp/isapnp/core.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
diff --git a/drivers/pnp/isapnp/core.c b/drivers/pnp/isapnp/core.c
index a0b1587..5696924 100644
--- a/drivers/pnp/isapnp/core.c
+++ b/drivers/pnp/isapnp/core.c
 <at>  <at>  -356,6 +356,8  <at>  <at>  static int __init isapnp_read_tag(unsigned char *type, unsigned short *size)
 {
 	unsigned char tag, tmp[2];

+	if (!type)	/* wrong type */
+		return -1;
 	isapnp_peek(&tag, 1);
 	if (tag == 0)				/* invalid tag */
 		return -1;
 <at>  <at>  -370,8 +372,6  <at>  <at>  static int __init isapnp_read_tag(unsigned char *type, unsigned short *size)
 #if 0
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michal Piotrowski | 1 Jul 2007 01:42
Picon

Re: [1/2] 2.6.22-rc6: known regressions with patches

Hi Ingo,

Ingo Molnar pisze:
> * Michal Piotrowski <michal.k.k.piotrowski <at> gmail.com> wrote:
> 
>> Subject    : fix nmi_watchdog=2 bootup hang
>> References : http://lkml.org/lkml/2007/6/25/51
>> Submitter  : Ingo Molnar <mingo <at> elte.hu>
>> Caused-By  : Jeremy Fitzhardinge <jeremy <at> xensource.com>
>>             Andi Kleen <ak <at> suse.de>
>>             commit f8822f42019eceed19cc6c0f985a489e17796ed8
>> Status     : patch available
> 
> fixed by:
> 
>  commit b9e3614f444f6546204f4538afcaa3ebe36d49f2
>  Author: Bj<C3><B6>rn Steinbrink <B.Steinbrink <at> gmx.de>
>  Date:   Mon Jun 25 23:04:37 2007 +0200
> 
>      fix nmi_watchdog=2 bootup hang
> 
> 	Ingo
> 

It's already removed

364  	2007-06-27 00:19:54  	8494  	 	mkkp  	"fix nmi_watchdog=2 bootup hang" fixed

Regards,
Michal
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kyle Moffett | 1 Jul 2007 01:46
Picon

Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness

On Jun 30, 2007, at 15:03:07, Davide Libenzi wrote:
> Hmm, why would you need MAP_REUSABLE? If a page is visible at any  
> time for a given UID, and you have a login under such UID, you can  
> fetch the content of the page at any time (ie, ptrace_attach,  
> gdb, ...).

Not under SELinux or other LSMs.  I suppose those could live without  
a 15% performance improvement in some workloads, but it would be nice  
if we could avoid it.  Essentially, UID is a really poor way to  
define process-security-equivalence classes in some systems.  If you  
really want to define such classes then you need to add LSM hooks to  
manage the equivalence classes.

> I think the focus should be to find a case where under the  
> currently implemented policy for MAP_NOZERO, MAP_NOZERO represent a  
> loss of security WRT no MAP_NOZERO.

Very simple case:
SELinux is turned on, an s9 (IE: TOP_SECRET) process calls free(),  
and an s3 (IE: UNCLASSIFIED) process calls malloc(), getting the data  
from the TOP_SECRET process.

>> The real trick is how to define the "key".  The default, without  
>> LSMs, should be something like the UID.  SELinux, on the other  
>> hand, would probably want to use some kind of hash of the label as  
>> the "key", (and store the label in each pool, as well).  That way  
>> SELinux could have a simple access-vector check for  
>> process:reusepage, as well as an access-vector check and type  
>> transition for "freereusablepage".  Then a policy could allow most  
>> user processes to unconditionally reuse pages (which would end up
(Continue reading)

Permalink | Reply | 11 comments |
headers
Davide Libenzi | 1 Jul 2007 01:57

Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness

On Sat, 30 Jun 2007, Kyle Moffett wrote:

> On Jun 30, 2007, at 15:03:07, Davide Libenzi wrote:
> > Hmm, why would you need MAP_REUSABLE? If a page is visible at any time for a
> > given UID, and you have a login under such UID, you can fetch the content of
> > the page at any time (ie, ptrace_attach, gdb, ...).
> 
> Not under SELinux or other LSMs.  I suppose those could live without a 15%
> performance improvement in some workloads, but it would be nice if we could
> avoid it.  Essentially, UID is a really poor way to define
> process-security-equivalence classes in some systems.  If you really want to
> define such classes then you need to add LSM hooks to manage the equivalence
> classes.
> 
> > I think the focus should be to find a case where under the currently
> > implemented policy for MAP_NOZERO, MAP_NOZERO represent a loss of security
> > WRT no MAP_NOZERO.
> 
> Very simple case:
> SELinux is turned on, an s9 (IE: TOP_SECRET) process calls free(), and an s3
> (IE: UNCLASSIFIED) process calls malloc(), getting the data from the
> TOP_SECRET process.

Note that you use *s3* and *s9*. Those will be two different context cookies. 
SeLinux will have its own way to set the cookie in the mm_struct, to *s3* 
in one case, and to *s9* in the other case. This will make things so that 
they'll never see each other pages.

> > It is very easy, assuming a simple unsigned long cookie is enough for
> > SeLinux, to fit in the current MAP_NOZERO.   Well, we have to change
(Continue reading)

Permalink | Reply | 10 comments |

Gmane