Thomas Renninger | 1 Aug 02:13 2010
Picon

Re: [PATCH] acpi ec_sys: Be more cautious about ec write access

On Friday 30 July 2010 06:37:17 pm Henrique de Moraes Holschuh wrote:
> On Thu, 29 Jul 2010, Thomas Renninger wrote:
> > - Only allow root to read/write io file (sever bug!)
>
> I'd go further, and only allow CAP_SYS_RAWIO.
I'll have a look and eventually come up with something on-top.

> > +	  The kernel accesses the EC through ACPI parsed code provided by BIOS
> > +	  tables. This option allows to access the EC directly without ACPI
> > +	  code being involved.
>
> This is not really true.  Kernel drivers can, and do access the EC without
> help from the AML firmware (DSDT, SSDT...).
Yes, the native laptop driver hacks which should not exist...
Generally the EC should only be accessed via ACPI interpreted code, is it 
really worth to mention these exceptions at this point?

   Thomas
Thomas Renninger | 1 Aug 02:36 2010
Picon

Re: [PATCH] acpi ec_sys: Export fields of all regions from the EC to debugfs readable

On Saturday 31 July 2010 01:30:53 am Andrew Morton wrote:
> On Fri, 30 Jul 2010 17:47:04 +0200
>
> Thomas Renninger <trenn <at> suse.de> wrote:
> > -static int acpi_ec_open_io(struct inode *i, struct file *f)
> > +static int acpi_ec_open(struct inode *i, struct file *f)
> >  {
> >  	f->private_data = i->i_private;
> > +	if (mutex_trylock(&ec_fs_lock))
> > +		return 0;
> > +	else
> > +		return -EBUSY;
> > +}
>
> Well that sucks - a userspace interface which is _designed_ to randomly
> and rarely fail?

> An application tries to open the thing and gets -EBUSY, what's it
> supposed to do?  Sleep and try again?  Crash and dump core?
This is  a debug interface nobody should rely on or use in real applications.
There should only exist one app which dumps the EC or write modify single
bytes/fields and this one shouldn't be called twice in parallel.
My idea was: if someone accesses this file simultaneously, something is
wrong in userspace and it's even safer...

On the other hand side, the ec.c code should already parallelize register 
accesses  and the whole lock should not be needed at all.
Someone might want to check whether the locks
in ec.c really do what they should and could use this as a stress test if the 
lock is simply removed.
(Continue reading)

Paul E. McKenney | 1 Aug 06:46 2010
Picon

Re: [PATCH] drivers/acpi: call rcu_read_unlock in default case

On Sat, Jul 31, 2010 at 10:35:28PM +0200, Julia Lawall wrote:
> From: Julia Lawall <julia <at> diku.dk>
> 
> Adjust the default case so that it benefits from the call to rcu_read_unlock.
> 
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // <smpl>
>  <at> rcu <at> 
> position p1;
>  <at>  <at> 
> 
> rcu_read_lock <at> p1();
> ...
> rcu_read_unlock();
> 
>  <at>  <at> 
> position rcu.p1;
>  <at>  <at> 
> 
> *rcu_read_lock <at> p1();
> ... when != rcu_read_unlock();
> // </smpl>

I don't claim to understand the SmPL above, but I do like the patch.

Reviewed-by: Paul E. McKenney <paulmck <at> linux.vnet.ibm.com>

> Signed-off-by: Julia Lawall <julia <at> diku.dk>
(Continue reading)

Rafael J. Wysocki | 1 Aug 15:46 2010
Picon

2.6.35-rc6-git6: Reported regressions from 2.6.34

This message contains a list of some regressions from 2.6.34,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 2.6.34, please let us
know either and we'll add them to the list.  Also, please let us know
if any of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.

Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2010-08-01      100       27          23
  2010-07-23       94       33          25
  2010-07-09       79       45          37
  2010-06-21       46       37          26
  2010-06-09       15       13          10

Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16462
Subject		: unable to connect to AP on legal channels 12/13
Submitter	: Daniel J Blueman <daniel.blueman <at> gmail.com>
Date		: 2010-07-25 17:06 (8 days old)

(Continue reading)

Picon

Re: [PATCH] acpi ec_sys: Be more cautious about ec write access

On Sun, 01 Aug 2010, Thomas Renninger wrote:
> On Friday 30 July 2010 06:37:17 pm Henrique de Moraes Holschuh wrote:
> > On Thu, 29 Jul 2010, Thomas Renninger wrote:
> > > - Only allow root to read/write io file (sever bug!)
> >
> > I'd go further, and only allow CAP_SYS_RAWIO.
> I'll have a look and eventually come up with something on-top.
> 
> > > +	  The kernel accesses the EC through ACPI parsed code provided by BIOS
> > > +	  tables. This option allows to access the EC directly without ACPI
> > > +	  code being involved.
> >
> > This is not really true.  Kernel drivers can, and do access the EC without
> > help from the AML firmware (DSDT, SSDT...).
> Yes, the native laptop driver hacks which should not exist...

But which DO exist.  Let's not go there.

> Generally the EC should only be accessed via ACPI interpreted code, is it 
> really worth to mention these exceptions at this point?

Why state incorrect information?  No kernel driver needs this new Kconfig
option to work, it is required only for *userspace* access to the EC
register space.  IMHO, it would better to say this:

"This option allows userspace direct access to the EC registers, for
debugging and kernel driver development purposes".

Which is entirely correct and gets the proper idea of its intended usage
across (it is not intended to be used for userspace drivers, AFAIK).
(Continue reading)

Rafael J. Wysocki | 1 Aug 16:27 2010
Picon

2.6.35-rc6-git6: Reported regressions 2.6.33 -> 2.6.34

[NOTE: This is the last summary report of regressions introduced between
 2.6.33 and 2.6.34.  Thanks for helping us with tracking these bugs!]

This message contains a list of some post-2.6.33 regressions introduced before
2.6.34, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.

If you know of any other unresolved post-2.6.33 regressions, please let us know
either and we'll add them to the list.  Also, please let us know if any
of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.

Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2010-08-01      129       17          16
  2010-07-23      128       27          25
  2010-07-10      122       25          24
  2010-06-21      114       36          28
  2010-06-13      111       40          34
  2010-05-09       80       27          24
  2010-05-04       76       26          22
  2010-04-20       64       35          34
  2010-04-07       48       35          33
  2010-03-21       15       13          10

(Continue reading)

Linus Torvalds | 1 Aug 20:01 2010

Re: 2.6.35-rc6-git6: Reported regressions from 2.6.34

On Sun, Aug 1, 2010 at 6:46 AM, Rafael J. Wysocki <rjw@...> wrote:
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16400
> Subject         : 2.6.35-rc5 inconsistent lock state
> Submitter       : Martin Pirker <lkml.collector@...>
> Date            : 2010-07-14 20:33 (19 days old)
> Message-ID      : <AANLkTikDF0TL6OyPVCzPlUTwxFehcrETn3ysgSSeTq92 <at> mail.gmail.com>
> References      : http://marc.info/?l=linux-kernel&m=127913961025267&w=2

This has a proposed patch. I don't know what the status of it is, though. Jens?

   http://marc.info/?l=linux-kernel&m=127950018204029&w=2

> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16393
> Subject         : kernel BUG at fs/block_dev.c:765!
> Submitter       : Markus Trippelsdorf <markus@...>
> Date            : 2010-07-14 13:52 (19 days old)
> Message-ID      : <20100714135217.GA1797@...>
> References      : http://marc.info/?l=linux-kernel&m=127911564213748&w=2

This one is interesting. And I think I perhaps see where it's coming from.

bd_start_claiming() (through bd_prepare_to_claim()) has two separate
success cases: either there was no holder (bd_claiming is NULL) or the
new holder was already claiming it (bd_claiming == holder).

Note in particular the case of the holder _already_ holding it. What happens is:

 - bd_start_claiming() succeeds because we had _already_ claimed it
with the same holder
(Continue reading)

Larry Finger | 1 Aug 21:39 2010
Picon

Re: 2.6.35-rc6-git6: Reported regressions from 2.6.34

On 08/01/2010 08:46 AM, Rafael J. Wysocki wrote:
> This message contains a list of some regressions from 2.6.34,
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
> 
> If you know of any other unresolved regressions from 2.6.34, please let us
> know either and we'll add them to the list.  Also, please let us know
> if any of the entries below are invalid.
> 
> Each entry from the list will be sent additionally in an automatic reply
> to this message with CCs to the people involved in reporting and handling
> the issue.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16312
> Subject		: WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
> Submitter	: Zdenek Kabelac <zdenek.kabelac@...>
> Date		: 2010-06-28 9:40 (35 days old)
> Message-ID	: <AANLkTin24fr5O4_q5Xbo9Y_NKkEmtcp6Hgmr9_4qXaFz@...>
> References	: http://marc.info/?l=linux-kernel&m=127771804806465&w=2
> Handled-By	: Jan Kara <jack@...>
> Patch		: https://bugzilla.kernel.org/attachment.cgi?id=27272

I am beginning to think that Bug 16312 is not the same as Bug 16122. Even with
the patches from 16312, I still get warnings as below:

[   11.728776] ------------[ cut here ]------------
[   11.728787] WARNING: at fs/fs-writeback.c:964 __mark_inode_dirty+0x10f/0x1a0()
[   11.728790] Hardware name: HP Pavilion dv2700 Notebook PC
[   11.728792] Modules linked in: loop(+) dm_mod ide_cd_mod cdrom
snd_hda_codec_conexant ide_pci_generic arc4 ecb b43 rng_core mac80211
(Continue reading)

Rafael J. Wysocki | 1 Aug 23:37 2010
Picon

Re: 2.6.35-rc6-git6: Reported regressions from 2.6.34

On Sunday, August 01, 2010, Linus Torvalds wrote:
> On Sun, Aug 1, 2010 at 6:46 AM, Rafael J. Wysocki <rjw@...> wrote:
...
> 
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16369
> > Subject         : Yet another 2.6.35 regression (AGP)?
> > Submitter       : Woody Suwalski <terraluna977@...>
> > Date            : 2010-07-09 14:21 (24 days old)
> > Message-ID      : <4C373084.8000503@...>
> > References      : http://marc.info/?l=linux-kernel&m=127868797119254&w=2
> 
> Should hopefully be fixed by commit e7b96f28c58c ("agp/intel: Use the
> correct mask to detect i830 aperture size.")

Closed.

> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16365
> > Subject         : kernel BUG at fs/btrfs/extent-tree.c:1353
> > Submitter       : Johannes Hirte <johannes.hirte@...>
> > Date            : 2010-07-08 14:27 (25 days old)
> > Message-ID      : <201007081627.24654.johannes.hirte@...>
> > References      : http://marc.info/?l=linux-kernel&m=127859960725931&w=2
> 
> This one is reportedly fixed by commit 83ba7b071f30 ("writeback:
> simplify the write back thread queue")

Closed.

> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16215
> > Subject         : sysfs: cannot create duplicate filename '/class/net/bnep0'
(Continue reading)

Huang Ying | 2 Aug 09:48 2010
Picon

[PATCH 0/4] ACPI, APEI, Some fixes and ERST debug support for 2.6.36

[PATCH 1/4] ACPI, APEI, Fix a typo of error path of apei_resources_request
[PATCH 2/4] ACPI, APEI, Rename CPER and GHES severity constants
[PATCH 3/4] ACPI, APEI, Manage GHES as platform devices
[PATCH 4/4] ACPI, APEI, ERST debug support
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane