Re: [PATCH 1/1] MAINTAINERS: Change maintainer for cyttsp driver

[Ferruh Yigit]

On 07/15/2013 12:41 AM, Javier Martinez Canillas wrote:

I haven't had time to work on this driver for a long time and
Ferruh has been doing a great job making it more generic,
adding support for new hardware and providing bug fixes.

Thank you a lot for your work on cyttsp drivers,
we would like to see your support back whenever you have time again.
Your expertise/know-how on issue is valuable.



So, let's make MAINTAINERS reflect reality and add him as the
cyttsp maintainer instead of me.

Also, since Ferruh works for Cypress, we may change the driver
status from Maintained to Supported.

Signed-off-by: Javier Martinez Canillas 
---

Ferruh, please send your ack if you are willing to take over
maintainance of this driver.


Acked-by: Ferruh Yigit 



Also, please confirm that you have been working on behalf of
Cypress instead of doing it on your free time. Otherwise we
should keep the driver status to maintained instead supported.

Right, I am a Cypress employee and working on TrueTouch drivers.


Thanks a lot and best regards,
Javier

  MAINTAINERS |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9d771d9..4ba996c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2458,9 +2458,9 @@ S:Maintained
  F:drivers/media/common/cypress_firmware*
  
  CYTTSP TOUCHSCREEN DRIVER

-M: Javier Martinez Canillas 
+M: Ferruh Yigit 
  L:linux-in...@vger.kernel.org
-S: Maintained
+S: Supported
  F:drivers/input/touchscreen/cyttsp*
  F:include/linux/input/cyttsp.h
  



--

Regards,
ferruh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH BUGFIX] pkt_sched: sch_qfq: remove a source of high packet delay/jitter

[Paolo Valente]

Il 15/07/2013 20:12, Joe Perches ha scritto:

On Mon, 2013-07-15 at 20:01 +0200, Paolo Valente wrote:

QFQ+ inherits from QFQ a design choice that may cause a high packet
delay/jitter and a severe short-term unfairness.

[]

diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c

[]

@@ -189,6 +188,7 @@ struct qfq_sched {
struct qfq_aggregate*in_serv_agg;   /* Aggregate being served. */
u32 num_active_agg; /* Num. of active aggregates */
u32 wsum;   /* weight sum */
+   unsigned long   iwsum;  /* inverse weight sum*/


This is a different size for 32/64 bit compiles
and may be better as u32.



Sending a new version with u32, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 3.10 regression: hang on suspend

[Stanislaw Gruszka]

Hi

On Mon, Jul 15, 2013 at 09:40:13PM +0200, Ortwin Glück wrote:
> My Samsung ultrabook hangs when suspending to RAM since this commit
> (bisected). Disabling wifi before suspend works around the issue.
> All works fine with 3.9.y.
> 
> 12e7f517029dad819c45eca9ca01fdb9ba57616b
> 
> Author: Stanislaw Gruszka 
> 
> Date:   Thu Feb 28 10:55:26 2013 +0100
> 
> mac80211: cleanup generic suspend/resume procedures
> 
> Since now we disconnect before suspend, various code which save
> connection state can now be removed from suspend and resume
> procedure. Cleanup on resume side is smaller as ieee80211_reconfig()
> is also used for H/W restart.
> 
> Signed-off-by: Stanislaw Gruszka 
> Signed-off-by: Johannes Berg 

Apparently this commit changed suspend procedure on mac80211, but it's
not obvious for me why it hangs :-(

What is your user space configuration (are you using NM or other
software or maybe just wpa_supplicant)? Are you using wowlan?
If you do add no_console_suspend boot parameter does it print some
diagnostic messages during suspend before the hang ?

Thanks
Stanislaw

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH BUGFIX] pkt_sched: sch_qfq: remove a source of high packet delay/jitter

[Paolo Valente]

QFQ+ inherits from QFQ a design choice that may cause a high packet
delay/jitter and a severe short-term unfairness. As QFQ, QFQ+ uses a
special quantity, the system virtual time, to track the service
provided by the ideal system it approximates. When a packet is
dequeued, this quantity must be incremented by the size of the packet,
divided by the sum of the weights of the aggregates waiting to be
served. Tracking this sum correctly is a non-trivial task, because, to
preserve tight service guarantees, the decrement of this sum must be
delayed in a special way [1]: this sum can be decremented only after
that its value would decrease also in the ideal system approximated by
QFQ+. For efficiency, QFQ+ keeps track only of the 'instantaneous'
weight sum, increased and decreased immediately as the weight of an
aggregate changes, and as an aggregate is created or destroyed (which,
in its turn, happens as a consequence of some class being
created/destroyed/changed). However, to avoid the problems caused to
service guarantees by these immediate decreases, QFQ+ increments the
system virtual time using the maximum value allowed for the weight
sum, 2^10, in place of the dynamic, instantaneous value. The
instantaneous value of the weight sum is used only to check whether a
request of weight increase or a class creation can be satisfied.

Unfortunately, the problems caused by this choice are worse than the
temporary degradation of the service guarantees that may occur, when a
class is changed or destroyed, if the instantaneous value of the
weight sum was used to update the system virtual time. In fact, the
fraction of the link bandwidth guaranteed by QFQ+ to each aggregate is
equal to the ratio between the weight of the aggregate and the sum of
the weights of the competing aggregates. The packet delay guaranteed
to the aggregate is instead inversely proportional to the guaranteed
bandwidth. By using the maximum possible value, and not the actual
value of the weight sum, QFQ+ provides each aggregate with the worst
possible service guarantees, and not with service guarantees related
to the actual set of competing aggregates. To see the consequences of
this fact, consider the following simple example.

Suppose that only the following aggregates are backlogged, i.e., that
only the classes in the following aggregates have packets to transmit:
one aggregate with weight 10, say A, and ten aggregates with weight 1,
say B1, B2, ..., B10. In particular, suppose that these aggregates are
always backlogged. Given the weight distribution, the smoothest and
fairest service order would be:
A B1 A B2 A B3 A B4 A B5 A B6 A B7 A B8 A B9 A B10 A B1 A B2 ...

QFQ+ would provide exactly this optimal service if it used the actual
value for the weight sum instead of the maximum possible value, i.e.,
11 instead of 2^10. In contrast, since QFQ+ uses the latter value, it
serves aggregates as follows (easy to prove and to reproduce
experimentally):
A B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 A A A A A A A A A A B1 B2 ... B10 A A ...

By replacing 10 with N in the above example, and by increasing N, one
can increase at will the maximum packet delay and the jitter
experienced by the classes in aggregate A.

This patch addresses this issue by just using the above
'instantaneous' value of the weight sum, instead of the maximum
possible value, when updating the system virtual time.  After the
instantaneous weight sum is decreased, QFQ+ may deviate from the ideal
service for a time interval in the order of the time to serve one
maximum-size packet for each backlogged class. The worst-case extent
of the deviation exhibited by QFQ+ during this time interval [1] is
basically the same as of the deviation described above (but, without
this patch, QFQ+ suffers from such a deviation all the time). Finally,
this patch modifies the comment to the function qfq_slot_insert, to
make it coherent with the fact that the weight sum used by QFQ+ can
now be lower than the maximum possible value.

[1] P. Valente, "Extending WF2Q+ to support a dynamic traffic mix",
Proceedings of AAA-IDEA'05, June 2005.

Signed-off-by: Paolo Valente 
---
 net/sched/sch_qfq.c | 85 +++--
 1 file changed, 56 insertions(+), 29 deletions(-)

diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index a7ab323..8056fb4 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -113,7 +113,6 @@
 
 #define FRAC_BITS  30  /* fixed point arithmetic */
 #define ONE_FP (1UL << FRAC_BITS)
-#define IWSUM  (ONE_FP/QFQ_MAX_WSUM)
 
 #define QFQ_MTU_SHIFT  16  /* to support TSO/GSO */
 #define QFQ_MIN_LMAX   512 /* see qfq_slot_insert */
@@ -189,6 +188,7 @@ struct qfq_sched {
struct qfq_aggregate*in_serv_agg;   /* Aggregate being served. */
u32 num_active_agg; /* Num. of active aggregates */
u32 wsum;   /* weight sum */
+

Re: splice vs execve lockdep trace.

[Dave Chinner]

On Tue, Jul 16, 2013 at 07:16:02AM +0100, Al Viro wrote:
> On Tue, Jul 16, 2013 at 04:03:51PM +1000, Dave Chinner wrote:
> 
> > I posted patches to fix this i_mutex/i_iolock inversion a couple of
> > years ago (july 2011):
> > 
> > https://lkml.org/lkml/2011/7/18/4
> > 
> > And V2 was posted here and reviewed (aug 2011):
> > 
> > http://xfs.9218.n7.nabble.com/PATCH-0-2-splice-i-mutex-vs-splice-write-deadlock-V2-tt4072.html#none
> 
> Unless I'm misreading the patch, you end up doing file_remove_suid()
> without holding i_mutex at all...

+   xfs_rw_ilock(ip, XFS_IOLOCK_EXCL);
+   ret = file_remove_suid(out);

Actaully, xfs_rw_ilock() takes the i_mutex due to teh exclusive locking ebing
done, so that's all fine.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] ASoC: kirkwood-i2s: fix a compilation warning

[Jean-Francois Moine]

In the function kirkwood_set_rate, when the rate cannot be satisfied
by the internal nor by an external clock, the clock source in undefined:

 warning: ‘clks_ctrl’ may be used uninitialized in this function

The ALSA subsystem should never gives such a rate because:
- the rates with the internal clock are limited to 44.1, 48 and 96 kHz
  as specified by the kirkwood_i2s_dai structure,
- the other rates are proposed in the structure kirkwood_i2s_dai_extclk
  only when the external clock is present.

In case of programming error (bad rate for internal clock and no
external clock), the function will simply cause a backtrace.

Signed-off-by: Jean-Francois Moine 
---
v2
- add more explanations
---
 sound/soc/kirkwood/kirkwood-i2s.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/sound/soc/kirkwood/kirkwood-i2s.c 
b/sound/soc/kirkwood/kirkwood-i2s.c
index 4c9dad3..c9daf3b 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -105,14 +105,16 @@ static void kirkwood_set_rate(struct snd_soc_dai *dai,
uint32_t clks_ctrl;
 
if (rate == 44100 || rate == 48000 || rate == 96000) {
-   /* use internal dco for supported rates */
+   /* use internal dco for the supported rates
+* defined in kirkwood_i2s_dai */
dev_dbg(dai->dev, "%s: dco set rate = %lu\n",
__func__, rate);
kirkwood_set_dco(priv->io, rate);
 
clks_ctrl = KIRKWOOD_MCLK_SOURCE_DCO;
-   } else if (!IS_ERR(priv->extclk)) {
-   /* use optional external clk for other rates */
+   } else {
+   /* use the external clock for the other rates
+* defined in kirkwood_i2s_dai_extclk */
dev_dbg(dai->dev, "%s: extclk set rate = %lu -> %lu\n",
__func__, rate, 256 * rate);
clk_set_rate(priv->extclk, 256 * rate);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 3.10.[01] modprobe snd-... hangs

[Lucas De Marchi]

On Tue, Jul 16, 2013 at 2:41 AM, Rusty Russell  wrote:
> Philipp Matthias Hahn  writes:
>> Hello,
>>
>> My x86_64 systems has some trouble loading some ALSA snd-* modules since
>> the upgrade to 3.10.[01]: Several automatic modprobe calls hang, but
>> loading snd-intel-hda and snd-audio-usb by hand still works.
>
> Not a known problem to me, at least.  Perhaps it's a dep loop somehow.

First thing to check is the /etc/modprobe.d/*.conf file that contains
these install commands. Did they change besides the kernel upgrade?

[
   Not really related to this, but... people/distros should stop using
install commands for things like this. By using softdeps kmod is smart
enough to detect and (possibly) break loops. With  install commands it
can't because it has no idea what the install command will do.
]

>
>> ...
>>  1071 ?S  0:00 sh -c /sbin/modprobe --ignore-install snd && { 
>> /sbin/modprobe --quiet snd
>>  1080 ?D  0:00  \_ /sbin/modprobe --quiet snd-seq
>
> This was first, and it's waiting.  Which means it must be doing
> something weird, because snd_seq_oss is loading now:
>
>> snd_seq_oss 33717 1 - Loading 0xa041b000

Searching kmod's log, I guess Debian still has:

 install snd_seq modprobe --ignore-install snd-seq $CMDLINE_OPTS && {
modprobe --quiet snd-seq-midi ; modprobe --quiet snd-seq-oss ; : ; }

>
> Perhaps in the tangle of modprobe install commands somewhere this gets
> invoked?
>
>> # ps axf
>>   460 ?S  0:00  \_ [kworker/u8:3]
>>  1087 ?S  0:00  |   \_ [kworker/u8:3]
>>  1092 ?S  0:00  |   \_ /sbin/modprobe -q -- snd-seq-client-14

Weird... this is coming from a request_module(). Greping... this
should only be coming from

git grep request_module | grep snd-seq-client
sound/core/seq/seq_clientmgr.c: request_module("snd-seq-client-%i",

Philipp, which kernel are you upgrading from?  I don't see anything to
blame in the changes for the past releases. Any chance a bad entry in
your .conf was added too? You may want to paste the output of modprobe
-c, at least until "# End of configuration files. Dumping indexes
now:"

>
> On my systems, that's snd-seq-dummy, which depends on snd_seq.  Which,
> in fact, is already loaded.
>
> Lucas, any clues?

I don't think I could help, but we need more data, like the ones above.


Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] [BUG] 3.10.[01] modprobe snd-... hangs

[Takashi Iwai]

At Tue, 16 Jul 2013 15:11:51 +0930,
Rusty Russell wrote:
> 
> Philipp Matthias Hahn  writes:
> > Hello,
> >
> > My x86_64 systems has some trouble loading some ALSA snd-* modules since
> > the upgrade to 3.10.[01]: Several automatic modprobe calls hang, but
> > loading snd-intel-hda and snd-audio-usb by hand still works.
> 
> Not a known problem to me, at least.  Perhaps it's a dep loop somehow.

I remember that someone reported it being Debian specific snd-seq-oss
loading stuff.

> > ...
> >  1071 ?S  0:00 sh -c /sbin/modprobe --ignore-install snd && { 
> > /sbin/modprobe --quiet snd
> >  1080 ?D  0:00  \_ /sbin/modprobe --quiet snd-seq
> 
> This was first, and it's waiting.  Which means it must be doing
> something weird, because snd_seq_oss is loading now:
> 
> > snd_seq_oss 33717 1 - Loading 0xa041b000
> 
> Perhaps in the tangle of modprobe install commands somewhere this gets
> invoked?

Likely, but I wonder what triggered a bug suddenly on 3.10.
There is absolutely no change in sound/core/seq/*, and through a quick
look, I couldn't find any suspicious change in kernel/module.c that
may lead to this problem between 3.9 and 3.10.

Philipp, can you get a sysrq-T trace while the stall?


thanks,

Takashi

> > # ps axf
> >   460 ?S  0:00  \_ [kworker/u8:3]
> >  1087 ?S  0:00  |   \_ [kworker/u8:3]
> >  1092 ?S  0:00  |   \_ /sbin/modprobe -q -- 
> > snd-seq-client-14
> 
> On my systems, that's snd-seq-dummy, which depends on snd_seq.  Which,
> in fact, is already loaded.
> 
> Lucas, any clues?
> 
> Full quote below.
> 
> Cheers,
> Rusty.
> 
> Philipp Matthias Hahn  writes:
> > Hello,
> >
> > My x86_64 systems has some trouble loading some ALSA snd-* modules since
> > the upgrade to 3.10.[01]: Several automatic modprobe calls hang, but
> > loading snd-intel-hda and snd-audio-usb by hand still works.
> >
> > # ps axf
> >   460 ?S  0:00  \_ [kworker/u8:3]
> >  1087 ?S  0:00  |   \_ [kworker/u8:3]
> >  1092 ?S  0:00  |   \_ /sbin/modprobe -q -- 
> > snd-seq-client-14
> > ...
> >  1071 ?S  0:00 sh -c /sbin/modprobe --ignore-install snd && { 
> > /sbin/modprobe --quiet snd
> >  1080 ?D  0:00  \_ /sbin/modprobe --quiet snd-seq
> >  1115 ?S  0:00 sh -c /sbin/modprobe --ignore-install 
> > snd-rawmidi && { /sbin/modprobe --q
> >  1154 ?S  0:00  \_ /sbin/modprobe --quiet snd-seq-midi
> >  1119 ?S  0:00 sh -c /sbin/modprobe --ignore-install 
> > snd-rawmidi && { /sbin/modprobe --q
> >  1148 ?S  0:00  \_ /sbin/modprobe --quiet snd-seq-midi
> >
> > In /var/log/daemon.log I find the following messages:
> > Jul 15 19:58:44 scout udevd[912]: timeout: killing '/sbin/modprobe -b 
> > usb:vFC08p0101d0250dc00dsc00dp00ic01isc01ip00in00' [1044]
> > Jul 15 19:58:56 scout udevd[912]: '/sbin/modprobe -b 
> > usb:vFC08p0101d0250dc00dsc00dp00ic01isc01ip00in00' [1044] terminated by 
> > signal 9 (Killed)
> > Jul 15 19:58:56 scout udevd[919]: timeout: killing '/sbin/modprobe -b 
> > pci:v10DEd026Csv1462sd7350bc04sc03i00' [1051]
> > Jul 15 19:58:56 scout udevd[914]: timeout: killing '/sbin/modprobe -b 
> > usb:vFC08p0101d0250dc00dsc00dp00ic01isc03ip00in01' [1045]
> > Jul 15 19:58:56 scout udevd[919]: '/sbin/modprobe -b 
> > pci:v10DEd026Csv1462sd7350bc04sc03i00' [1051] terminated by 
> > signal 9 (Killed)
> > Jul 15 19:58:56 scout udevd[914]: '/sbin/modprobe -b 
> > usb:vFC08p0101d0250dc00dsc00dp00ic01isc03ip00in01' [1045] terminated by 
> > signal 9 (Killed)
> >
> >
> > This is a Debian sid system
> > # modprobe -V
> > kmod version 9
> >
> > # echo t >/proc/sysrq-trigger
> > produces too much output to include the modprobe processes. I already
> > stopped most processes, but that is not enough.
> >
> >
> > # cat /proc/1092/syscall
> > 175 0x7effcad92000 0xafe8 0x7effca9c2f88 0x7effca6ea3aa 0x0 0x0 
> > 0x7fff3e3de648 0x7effca6eef8a
> >
> > # cat /proc/1080/syscall
> > 175 0x7fe01b25e000 0xafe8 0x7fe01ae8ef88 0x7fe01abb63aa 0x3 0x0 
> > 0x7fffba8cc748 0x7fe01abbaf8a
> >
> > # cat /proc/1154/syscall
> > 175 0x7fc157a7b000 0xafe8 0x7fc1576abf88 0x7fc1573d33aa 0x3 0x0 
> > 0x7fff05809e58 0x7fc1573d7f8a
> >
> > # cat /proc/1148/syscall
> > 175 0x7fc7159d5000 0xafe8 0x7fc715605f88 0x7fc71532d3aa 0x3 0x0 
> > 0x7fff47a1f3c8 0x7fc715331f8a
> >
> > Is this a know bug or has someone seen similar problems?
> >
> > # cat /proc/modules
> > ip6table_filter 1575 0 - Live 0xa0893000
> > ip6_tables 13784 1 ip6table_filter, Live 0xa088b000
> > ebtable_nat 1887 0 - Live 0xa0887000
> > ebtables 19917 1 ebtable_nat, Live 0xa087e000
> > snd_usb_audio 124196 0 - Live 0xa0851000
> > snd_usbmidi_lib 16982 1 snd_usb_audio, Live 0xa0848000
> > rfcomm 28731 10 - Live 0xa083a000
> > bnep 9786 2 - Live 0xa0833000
> > snd_hda_codec_realtek 37669 1 - Live 0xa0823000
> > snd_hda_inte

Re: [PATCH V5 09/12] perf: make events stream always parsable

[Adrian Hunter]

On 15/07/13 09:14, Adrian Hunter wrote:
> On 12/07/13 17:55, Peter Zijlstra wrote:
>> On Fri, Jul 12, 2013 at 03:56:01PM +0300, Adrian Hunter wrote:
 There's events where this isn't a possible location; take PERF_RECORD_MMAP 
 for
 instance; the tail is the complete filename.
>>>
>>> PERF_RECORD_MMAP falls in the category I have called non-sample events.
>>> Those events are appended with an ID sample.  perf tools parses the ID
>>> sample backwards from header.size.  So the ID is at the last position
>>> relative to header.size
>>
>> But why? Why make it different per PERF_RECORD type? 
> 
> There have always been two formats:
> 
>   1. PERF_RECORD_SAMPLE as defined by perf_output_sample()
> 
>   2. everything else as defined by __perf_event__output_id_sample()
> 
> The two formats are not the same, and there is no reason for them to be.
> 
> PERF_RECORD_SAMPLE is parsed forwards, so the ID is at the first position.
> 
> ID samples are parsed backwards, so the ID is at the last position (i.e. the
> first position parsed).

If you want the ID at the first position in the ID sample, it is do-able.
It means perf tools will have to be changed to calculate the variable start
position of the ID sample, and then parse the ID sample forwards from there.
Please advise.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: splice vs execve lockdep trace.

[Dave Chinner]

On Tue, Jul 16, 2013 at 07:16:02AM +0100, Al Viro wrote:
> On Tue, Jul 16, 2013 at 04:03:51PM +1000, Dave Chinner wrote:
> 
> > I posted patches to fix this i_mutex/i_iolock inversion a couple of
> > years ago (july 2011):
> > 
> > https://lkml.org/lkml/2011/7/18/4
> > 
> > And V2 was posted here and reviewed (aug 2011):
> > 
> > http://xfs.9218.n7.nabble.com/PATCH-0-2-splice-i-mutex-vs-splice-write-deadlock-V2-tt4072.html#none
> 
> Unless I'm misreading the patch, you end up doing file_remove_suid()
> without holding i_mutex at all...

We've been calling file_remove_suid() since at least 2010 without
i_mutex held through the direct IO write path

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 03/12] perf tools: add pid to struct thread

[Adrian Hunter]

Record pid on struct thread.  The member is named 'pid_'
to avoid confusion with the 'tid' member which was previously
named 'pid'.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/machine.c | 16 +++-
 tools/perf/util/thread.c  |  3 ++-
 tools/perf/util/thread.h  |  3 ++-
 3 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index f9f9d63..67ba572 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -233,7 +233,8 @@ void machines__set_id_hdr_size(struct machines *machines, 
u16 id_hdr_size)
return;
 }
 
-static struct thread *__machine__findnew_thread(struct machine *machine, pid_t 
tid,
+static struct thread *__machine__findnew_thread(struct machine *machine,
+   pid_t pid, pid_t tid,
bool create)
 {
struct rb_node **p = &machine->threads.rb_node;
@@ -245,8 +246,11 @@ static struct thread *__machine__findnew_thread(struct 
machine *machine, pid_t t
 * so most of the time we dont have to look up
 * the full rbtree:
 */
-   if (machine->last_match && machine->last_match->tid == tid)
+   if (machine->last_match && machine->last_match->tid == tid) {
+   if (pid && pid != machine->last_match->pid_)
+   machine->last_match->pid_ = pid;
return machine->last_match;
+   }
 
while (*p != NULL) {
parent = *p;
@@ -254,6 +258,8 @@ static struct thread *__machine__findnew_thread(struct 
machine *machine, pid_t t
 
if (th->tid == tid) {
machine->last_match = th;
+   if (pid && pid != th->pid_)
+   th->pid_ = pid;
return th;
}
 
@@ -266,7 +272,7 @@ static struct thread *__machine__findnew_thread(struct 
machine *machine, pid_t t
if (!create)
return NULL;
 
-   th = thread__new(tid);
+   th = thread__new(pid, tid);
if (th != NULL) {
rb_link_node(&th->rb_node, parent, p);
rb_insert_color(&th->rb_node, &machine->threads);
@@ -278,12 +284,12 @@ static struct thread *__machine__findnew_thread(struct 
machine *machine, pid_t t
 
 struct thread *machine__findnew_thread(struct machine *machine, pid_t tid)
 {
-   return __machine__findnew_thread(machine, tid, true);
+   return __machine__findnew_thread(machine, 0, tid, true);
 }
 
 struct thread *machine__find_thread(struct machine *machine, pid_t tid)
 {
-   return __machine__findnew_thread(machine, tid, false);
+   return __machine__findnew_thread(machine, 0, tid, false);
 }
 
 int machine__process_comm_event(struct machine *machine, union perf_event 
*event)
diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index 6feeb88..e3d4a55 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -7,12 +7,13 @@
 #include "util.h"
 #include "debug.h"
 
-struct thread *thread__new(pid_t tid)
+struct thread *thread__new(pid_t pid, pid_t tid)
 {
struct thread *self = zalloc(sizeof(*self));
 
if (self != NULL) {
map_groups__init(&self->mg);
+   self->pid_ = pid;
self->tid = tid;
self->ppid = -1;
self->comm = malloc(32);
diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h
index 0fe1f9c..fc464bc 100644
--- a/tools/perf/util/thread.h
+++ b/tools/perf/util/thread.h
@@ -12,6 +12,7 @@ struct thread {
struct list_head node;
};
struct map_groups   mg;
+   pid_t   pid_; /* Not all tools update this */
pid_t   tid;
pid_t   ppid;
charshortname[3];
@@ -24,7 +25,7 @@ struct thread {
 
 struct machine;
 
-struct thread *thread__new(pid_t tid);
+struct thread *thread__new(pid_t pid, pid_t tid);
 void thread__delete(struct thread *self);
 
 int thread__set_comm(struct thread *self, const char *comm);
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 00/12] perf tools: some fixes and tweaks

[Adrian Hunter]

Hi

Here are some fixes and tweaks to perf tools (version 6).

Changes in V6:
Some checkpatch fixes

perf: make events stream always parsable
Add sample format comments

Changes in V5:
Re-based to Arnaldo's tree and dropped already applied patches:
perf tools: remove unused parameter
perf tools: fix missing tool parameter
perf tools: fix missing 'finished_round'
perf tools: fix parse_events_terms() segfault on error path
perf tools: fix new_term() missing free on error path
perf tools: add const specifier to perf_pmu__find name parameter
perf tools: tidy duplicated munmap code
perf tools: validate perf event header size

perf tools: add debug prints
Changed to perf_event_attr__fprintf()
perf tools: add pid to struct thread
Always set the pid, even if a pid is already set
perf tools: change machine__findnew_thread() to set thread pid
Replaces: perf tools: change "machine" functions to set thread 
pid
perf tools: add support for PERF_SAMPLE_IDENTFIER
Only use PERF_SAMPLE_IDENTFIER if sample types are different
perf tools: expand perf_event__synthesize_sample()
New patch in preparation of a sample parsing test
perf tools: add a sample parsing test
New patch

Changes in V4:
I added kernel support for matching sample types via
PERF_SAMPLE_IDENTIFIER.  perf tools support for that required
first fixing some other things.

perf tools: fix parse_events_terms() freeing local variable on error 
path
Dropped - covered by David Ahern
perf tools: struct thread has a tid not a pid
Added ack by David Ahern
perf tools: add pid to struct thread
Remove unused function
perf tools: fix missing increment in sample parsing
New patch
perf tools: tidy up sample parsing overflow checking
New patch
perf tools: remove unnecessary callchain validation
New patch
perf tools: remove references to struct ip_event
New patch
perf tools: move struct ip_event
New patch
perf: make events stream always parsable
New patch
perf tools: add support for PERF_SAMPLE_IDENTFIER
New patch

Changes in V3:
perf tools: add pid to struct thread
Split into 2 patches
perf tools: fix ppid in thread__fork()
Dropped for now

Changes in V2:
perf tools: fix missing tool parameter
Fixed one extra occurrence
perf tools: fix parse_events_terms() freeing local variable on error 
path
Made "freeing" code into a new function
perf tools: validate perf event header size
Corrected byte-swapping
perf tools: allow non-matching sample types
Added comments
Fixed id_pos calculation
id_pos/is_pos updated whenever sample_type changes
Removed perf_evlist__sample_type()
Added __perf_evlist__combined_sample_type()
Added perf_evlist__combined_sample_type()
Added perf_evlist__make_sample_types_compatible()
Added ack's to patches acked by Jiri Olsa


Adrian Hunter (12):
  perf tools: add debug prints
  perf tools: allow non-matching sample types
  perf tools: add pid to struct thread
  perf tools: change machine__findnew_thread() to set thread pid
  perf tools: tidy up sample parsing overflow checking
  perf tools: remove unnecessary callchain validation
  perf tools: remove references to struct ip_event
  perf tools: move struct ip_event
  perf: make events stream always parsable
  perf tools: add support for PERF_SAMPLE_IDENTFIER
  perf tools: expand perf_event__synthesize_sample()
  perf tools: add a sample parsing test

 include/uapi/linux/perf_event.h   |  33 +++-
 kernel/events/core.c  |  11 +-
 tools/perf/Makefile   |   1 +
 tools/perf/builtin-inject.c   |   7 +-
 tools/perf/builtin-kmem.c |   3 +-
 tools/perf/builtin-kvm.c  |   3 +-
 tools/perf/builtin-lock.c |   3 +-
 tools/perf/builtin-mem.c  |   2 +-
 tools/perf/builtin-report.c   |   2 +-
 tools/perf/builtin-sched.c|  17 +-
 tools/perf/builtin-script.c   |   3 +-
 tools/perf/builtin-top.c  |  11 +-
 tools/perf/builtin-trace.c|  12 +-
 tools/perf/tests/builtin-test.c   |   4 +
 tools/perf/tests/hists_link.c |  30 +++-
 tools/perf/tests/mmap-basic.c |   2 +-
 tools/perf/tests/sample-parsing.c | 240 +++
 tools/perf/tests/tests.h  |   1 +
 too

[PATCH V6 08/12] perf tools: move struct ip_event

[Adrian Hunter]

struct ip_event assumes fixed positions for ip, pid
and tid.  That is no longer true with the addition of
PERF_SAMPLE_IDENTIFIER.

struct ip_event is no longer used except by hists_link.c.
Move it there.

Signed-off-by: Adrian Hunter 
---
 tools/perf/tests/hists_link.c | 23 +++
 tools/perf/util/event.h   | 11 ---
 2 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/tools/perf/tests/hists_link.c b/tools/perf/tests/hists_link.c
index 7e0ca15..cfdbfd9 100644
--- a/tools/perf/tests/hists_link.c
+++ b/tools/perf/tests/hists_link.c
@@ -195,6 +195,19 @@ static struct sample fake_samples[][5] = {
},
 };
 
+/* PERF_SAMPLE_IP | PERF_SAMPLE_TID | * but not PERF_SAMPLE_IDENTIFIER */
+struct ip_event {
+   struct perf_event_header header;
+   u64 ip;
+   u32 pid, tid;
+   unsigned char __more_data[];
+};
+
+union perf_ip_event {
+   struct ip_event ip;
+   union perf_event event;
+};
+
 static int add_hist_entries(struct perf_evlist *evlist, struct machine 
*machine)
 {
struct perf_evsel *evsel;
@@ -210,7 +223,7 @@ static int add_hist_entries(struct perf_evlist *evlist, 
struct machine *machine)
 */
list_for_each_entry(evsel, &evlist->entries, node) {
for (k = 0; k < ARRAY_SIZE(fake_common_samples); k++) {
-   const union perf_event event = {
+   const union perf_ip_event ip_event = {
.ip = {
.header = {
.misc = PERF_RECORD_MISC_USER,
@@ -219,10 +232,11 @@ static int add_hist_entries(struct perf_evlist *evlist, 
struct machine *machine)
.ip  = fake_common_samples[k].ip,
},
};
+   const union perf_event *event = &ip_event.event;
 
sample.pid = ip_event.ip.pid;
sample.ip = ip_event.ip.ip;
-   if (perf_event__preprocess_sample(&event, machine, &al,
+   if (perf_event__preprocess_sample(event, machine, &al,
  &sample, 0) < 0)
goto out;
 
@@ -236,7 +250,7 @@ static int add_hist_entries(struct perf_evlist *evlist, 
struct machine *machine)
}
 
for (k = 0; k < ARRAY_SIZE(fake_samples[i]); k++) {
-   const union perf_event event = {
+   const union perf_ip_event ip_event = {
.ip = {
.header = {
.misc = PERF_RECORD_MISC_USER,
@@ -245,10 +259,11 @@ static int add_hist_entries(struct perf_evlist *evlist, 
struct machine *machine)
.ip  = fake_samples[i][k].ip,
},
};
+   const union perf_event *event = &ip_event.event;
 
sample.pid = ip_event.ip.pid;
sample.ip = ip_event.ip.ip;
-   if (perf_event__preprocess_sample(&event, machine, &al,
+   if (perf_event__preprocess_sample(event, machine, &al,
  &sample, 0) < 0)
goto out;
 
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index e60585e..94f4503 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -8,16 +8,6 @@
 #include "map.h"
 #include "build-id.h"
 
-/*
- * PERF_SAMPLE_IP | PERF_SAMPLE_TID | *
- */
-struct ip_event {
-   struct perf_event_header header;
-   u64 ip;
-   u32 pid, tid;
-   unsigned char __more_data[];
-};
-
 struct mmap_event {
struct perf_event_header header;
u32 pid, tid;
@@ -162,7 +152,6 @@ struct tracing_data_event {
 
 union perf_event {
struct perf_event_headerheader;
-   struct ip_event ip;
struct mmap_event   mmap;
struct comm_event   comm;
struct fork_event   fork;
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 10/12] perf tools: add support for PERF_SAMPLE_IDENTFIER

[Adrian Hunter]

Enable parsing of samples with sample format bit
PERF_SAMPLE_IDENTFIER.  In addition, if the kernel supports
it, prefer it to selecting PERF_SAMPLE_ID thereby avoiding
the need to force compatible sample types.

Signed-off-by: Adrian Hunter 
---
 tools/perf/tests/mmap-basic.c |  2 +-
 tools/perf/util/event.h   |  9 +++--
 tools/perf/util/evlist.c  | 94 +--
 tools/perf/util/evlist.h  |  1 +
 tools/perf/util/evsel.c   | 41 +++
 tools/perf/util/evsel.h   |  3 +-
 6 files changed, 134 insertions(+), 16 deletions(-)

diff --git a/tools/perf/tests/mmap-basic.c b/tools/perf/tests/mmap-basic.c
index 5b1b5ab..c4185b9 100644
--- a/tools/perf/tests/mmap-basic.c
+++ b/tools/perf/tests/mmap-basic.c
@@ -72,7 +72,7 @@ int test__basic_mmap(void)
}
 
evsels[i]->attr.wakeup_events = 1;
-   perf_evsel__set_sample_id(evsels[i]);
+   perf_evsel__set_sample_id(evsels[i], false);
 
perf_evlist__add(evlist, evsels[i]);
 
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 94f4503..82bad0d 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -53,7 +53,8 @@ struct read_event {
(PERF_SAMPLE_IP | PERF_SAMPLE_TID | \
 PERF_SAMPLE_TIME | PERF_SAMPLE_ADDR |  \
PERF_SAMPLE_ID | PERF_SAMPLE_STREAM_ID |\
-PERF_SAMPLE_CPU | PERF_SAMPLE_PERIOD)
+PERF_SAMPLE_CPU | PERF_SAMPLE_PERIOD | \
+PERF_SAMPLE_IDENTIFIER)
 
 /*
  * Events have compatible sample types if the following bits all have the same
@@ -61,13 +62,15 @@ struct read_event {
  * events the order is: PERF_SAMPLE_IP, PERF_SAMPLE_TID, PERF_SAMPLE_TIME,
  * PERF_SAMPLE_ADDR, PERF_SAMPLE_ID.  For non-sample events the sample members
  * are accessed in reverse order.  The order is: PERF_SAMPLE_ID,
- * PERF_SAMPLE_STREAM_ID, PERF_SAMPLE_CPU.
+ * PERF_SAMPLE_STREAM_ID, PERF_SAMPLE_CPU.  PERF_SAMPLE_IDENTIFIER is added for
+ * completeness but it should not be used with PERF_SAMPLE_ID.  Sample types
+ * that include PERF_SAMPLE_IDENTIFIER are always compatible.
  */
 #define PERF_COMPAT_MASK   \
(PERF_SAMPLE_IP   | PERF_SAMPLE_TID   | \
 PERF_SAMPLE_TIME | PERF_SAMPLE_ADDR  | \
 PERF_SAMPLE_ID   | PERF_SAMPLE_STREAM_ID | \
-PERF_SAMPLE_CPU)
+PERF_SAMPLE_CPU  | PERF_SAMPLE_IDENTIFIER)
 
 struct sample_event {
struct perf_event_headerheader;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index b8a5a75..3c53ef0 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -89,10 +89,81 @@ void perf_evlist__make_sample_types_compatible(struct 
perf_evlist *evlist)
perf_evlist__set_id_pos(evlist);
 }
 
+typedef void (*setup_probe_fn_t)(struct perf_evsel *evsel);
+
+static int perf_do_probe_api(setup_probe_fn_t fn, int cpu, const char *str)
+{
+   struct perf_evlist *evlist;
+   struct perf_evsel *evsel;
+   int err = -EAGAIN, fd;
+
+   evlist = perf_evlist__new();
+   if (!evlist)
+   return -ENOMEM;
+
+   if (parse_events(evlist, str))
+   goto out_delete;
+
+   evsel = perf_evlist__first(evlist);
+
+   fd = sys_perf_event_open(&evsel->attr, -1, cpu, -1, 0);
+   if (fd < 0)
+   goto out_delete;
+   close(fd);
+
+   fn(evsel);
+
+   fd = sys_perf_event_open(&evsel->attr, -1, cpu, -1, 0);
+   if (fd < 0) {
+   if (errno == EINVAL)
+   err = -EINVAL;
+   goto out_delete;
+   }
+   close(fd);
+   err = 0;
+
+out_delete:
+   perf_evlist__delete(evlist);
+   return err;
+}
+
+static bool perf_probe_api(setup_probe_fn_t fn)
+{
+   const char *try[] = {"cycles:u", "instructions:u", "cpu-clock", NULL};
+   struct cpu_map *cpus;
+   int cpu, ret, i = 0;
+
+   cpus = cpu_map__new(NULL);
+   if (!cpus)
+   return false;
+   cpu = cpus->map[0];
+   cpu_map__delete(cpus);
+
+   do {
+   ret = perf_do_probe_api(fn, cpu, try[i++]);
+   if (!ret)
+   return true;
+   } while (ret == -EAGAIN && try[i]);
+
+   return false;
+}
+
+static void perf_probe_sample_identifier(struct perf_evsel *evsel)
+{
+   evsel->attr.sample_type |= PERF_SAMPLE_IDENTIFIER;
+}
+
+bool perf_can_sample_identifier(void)
+{
+   return perf_probe_api(perf_probe_sample_identifier);
+}
+
 void perf_evlist__config(struct perf_evlist *evlist,
struct perf_record_opts *opts)
 {
struct perf_evsel *evsel;
+   bool use_sample_identifier = false;
+
/*
 * Set the evsel leader links before we configure attributes,
 * since some might depend on this info.
@@ -103,14 +174,26 @@ void perf_evlist__config(struct perf_evlist *evlist,
if (evl

Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume

[Daniel Vetter]

On Sun, Jul 14, 2013 at 08:30:09PM +0400, Konstantin Khlebnikov wrote:
> This patch fixes regression in power consumtion of sandy bridge gpu, which
> exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
> it's extremely busy. After that it never reaches rc6 state.
> 
> Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
> ("drm/i915: load boot context at driver init time"). Without documentation
> it's not clear what is happening here, probably this breaks internal state of
> hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake
> during whole initialization sequence in gen6_init_clock_gating() fixes this 
> bug.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
> Signed-off-by: Konstantin Khlebnikov 

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=58971
Tested-by: Alexander Kaltsas 
Tested-by: rocko 

> ---
>  drivers/gpu/drm/i915/intel_pm.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index aa01128..839a43f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3640,6 +3640,8 @@ static void gen6_init_clock_gating(struct drm_device 
> *dev)
>   int pipe;
>   uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE;
>  
> + gen6_gt_force_wake_get(dev_priv);
> +
>   I915_WRITE(ILK_DSPCLK_GATE_D, dspclk_gate);
>  
>   I915_WRITE(ILK_DISPLAY_CHICKEN2,
> @@ -3728,6 +3730,8 @@ static void gen6_init_clock_gating(struct drm_device 
> *dev)
>   cpt_init_clock_gating(dev);
>  
>   gen6_check_mch_setup(dev);
> +
> + gen6_gt_force_wake_put(dev_priv);
>  }
>  
>  static void gen7_setup_fixed_func_scheduler(struct drm_i915_private 
> *dev_priv)
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 09/12] perf: make events stream always parsable

[Adrian Hunter]

The event stream is not always parsable because the format of a sample
is dependent on the sample_type of the selected event.  When there
is more than one selected event and the sample_types are not the
same then parsing becomes problematic.  A sample can be matched to its
selected event using the ID that is allocated when the event is opened.
Unfortunately, to get the ID from the sample means first parsing it.

This patch adds a new sample format bit PERF_SAMPLE_IDENTIFER that puts
the ID at a fixed position so that the ID can be retrieved without
parsing the sample.  For sample events, that is the first position
immediately after the header.  For non-sample events, that is the last
position.

Signed-off-by: Adrian Hunter 
---
 include/uapi/linux/perf_event.h | 33 ++---
 kernel/events/core.c| 11 ++-
 2 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 0b1df41..627bbcf 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -134,8 +134,9 @@ enum perf_event_sample_format {
PERF_SAMPLE_STACK_USER  = 1U << 13,
PERF_SAMPLE_WEIGHT  = 1U << 14,
PERF_SAMPLE_DATA_SRC= 1U << 15,
+   PERF_SAMPLE_IDENTIFIER  = 1U << 16,
 
-   PERF_SAMPLE_MAX = 1U << 16, /* non-ABI */
+   PERF_SAMPLE_MAX = 1U << 17, /* non-ABI */
 };
 
 /*
@@ -471,12 +472,23 @@ enum perf_event_type {
/*
 * If perf_event_attr.sample_id_all is set then all event types will
 * have the sample_type selected fields related to where/when
-* (identity) an event took place (TID, TIME, ID, CPU, STREAM_ID)
-* described in PERF_RECORD_SAMPLE below, it will be stashed just after
-* the perf_event_header and the fields already present for the existing
-* fields, i.e. at the end of the payload. That way a newer perf.data
-* file will be supported by older perf tools, with these new optional
-* fields being ignored.
+* (identity) an event took place (TID, TIME, ID, STREAM_ID, CPU,
+* IDENTIFIER) described in PERF_RECORD_SAMPLE below, it will be stashed
+* just after the perf_event_header and the fields already present for
+* the existing fields, i.e. at the end of the payload. That way a newer
+* perf.data file will be supported by older perf tools, with these new
+* optional fields being ignored.  The format is:
+*
+*  { u32   pid, tid; } && PERF_SAMPLE_TID
+*  { u64   time; } && PERF_SAMPLE_TIME
+*  { u64   id;   } && PERF_SAMPLE_ID
+*  { u64   stream_id;} && PERF_SAMPLE_STREAM_ID
+*  { u32   cpu, res; } && PERF_SAMPLE_CPU
+*  { u64   id;   } && PERF_SAMPLE_IDENTIFIER
+*
+* Note that PERF_SAMPLE_IDENTIFIER duplicates PERF_SAMPLE_ID.  The
+* advantage of PERF_SAMPLE_IDENTIFIER is that its position is fixed
+* relative to header.size.
 *
 * The MMAP events record the PROT_EXEC mappings so that we can
 * correlate userspace IPs to code. They have the following structure:
@@ -557,6 +569,13 @@ enum perf_event_type {
 * struct {
 *  struct perf_event_headerheader;
 *
+*  #
+*  # Note that PERF_SAMPLE_IDENTIFIER duplicates PERF_SAMPLE_ID.
+*  # The advantage of PERF_SAMPLE_IDENTIFIER is that its position
+*  # is fixed relative to header.
+*  #
+*
+*  { u64   id;   } && PERF_SAMPLE_IDENTIFIER
 *  { u64   ip;   } && PERF_SAMPLE_IP
 *  { u32   pid, tid; } && PERF_SAMPLE_TID
 *  { u64   time; } && PERF_SAMPLE_TIME
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 708ab70..866516b 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1216,6 +1216,9 @@ static void perf_event__id_header_size(struct perf_event 
*event)
if (sample_type & PERF_SAMPLE_TIME)
size += sizeof(data->time);
 
+   if (sample_type & PERF_SAMPLE_IDENTIFIER)
+   size += sizeof(data->id);
+
if (sample_type & PERF_SAMPLE_ID)
size += sizeof(data->id);
 
@@ -4251,7 +4254,7 @@ static void __perf_event_header__init_id(struct 
perf_event_header *header,
if (sample_type & PERF_SAMPLE_TIME)
data->time = perf_clock();
 
-   if (sample_type & PERF_SAMPLE_ID)
+   if (sample_type & (PERF_SAMPLE_ID | PERF_SAMPLE_IDENTIFIER))
data->id = primary_event_id(event);
 
if (sample_type & PERF_SAMPLE_STREAM_ID)
@@ -4290

[PATCH V6 11/12] perf tools: expand perf_event__synthesize_sample()

[Adrian Hunter]

Expand perf_event__synthesize_sample() to handle all
sample format bits.

Signed-off-by: Adrian Hunter 
---
 tools/perf/builtin-inject.c |  3 +-
 tools/perf/util/event.h |  1 +
 tools/perf/util/evsel.c | 70 -
 3 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index ffacd46..eb33da6 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -301,7 +301,8 @@ found:
sample_sw.period = sample->period;
sample_sw.time   = sample->time;
perf_event__synthesize_sample(event_sw, evsel->attr.sample_type,
- &sample_sw, false);
+ evsel->attr.sample_regs_user, &sample_sw,
+ false);
build_id__mark_dso_hit(tool, event_sw, &sample_sw, evsel, machine);
return perf_event__repipe(tool, event_sw, &sample_sw, machine);
 }
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 82bad0d..7f5c36b 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -228,6 +228,7 @@ int perf_event__preprocess_sample(const union perf_event 
*self,
 const char *perf_event__name(unsigned int id);
 
 int perf_event__synthesize_sample(union perf_event *event, u64 type,
+ u64 sample_regs_user,
  const struct perf_sample *sample,
  bool swapped);
 
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 41cfb21..5efa3ce 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1357,11 +1357,12 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel, 
union perf_event *event,
 }
 
 int perf_event__synthesize_sample(union perf_event *event, u64 type,
+ u64 sample_regs_user,
  const struct perf_sample *sample,
  bool swapped)
 {
u64 *array;
-
+   size_t sz;
/*
 * used for cross-endian analysis. See git commit 65014ab3
 * for why this goofiness is needed.
@@ -1434,6 +1435,73 @@ int perf_event__synthesize_sample(union perf_event 
*event, u64 type,
array++;
}
 
+   if (type & PERF_SAMPLE_READ) {
+   fprintf(stderr, "PERF_SAMPLE_READ is unsupported for now\n");
+   return -1;
+   }
+
+   if (type & PERF_SAMPLE_CALLCHAIN) {
+   sz = (sample->callchain->nr + 1) * sizeof(u64);
+   memcpy(array, sample->callchain, sz);
+   array = (void *)array + sz;
+   }
+
+   if (type & PERF_SAMPLE_RAW) {
+   u.val32[0] = sample->raw_size;
+   if (WARN_ONCE(swapped,
+ "Endianness of raw data not corrected!\n")) {
+   /*
+* Inverse of what is done in perf_evsel__parse_sample
+*/
+   u.val32[0] = bswap_32(u.val32[0]);
+   u.val32[1] = bswap_32(u.val32[1]);
+   u.val64 = bswap_64(u.val64);
+   }
+   *array = u.val64;
+   array = (void *)array + sizeof(u32);
+
+   memcpy(array, sample->raw_data, sample->raw_size);
+   array = (void *)array + sample->raw_size;
+   }
+
+   if (type & PERF_SAMPLE_BRANCH_STACK) {
+   sz = sample->branch_stack->nr * sizeof(struct branch_entry);
+   sz += sizeof(u64);
+   memcpy(array, sample->branch_stack, sz);
+   array = (void *)array + sz;
+   }
+
+   if (type & PERF_SAMPLE_REGS_USER) {
+   if (sample->user_regs.regs && sample_regs_user) {
+   *array++ = sample_regs_user;
+   sz = hweight_long(sample_regs_user) * sizeof(u64);
+   memcpy(array, sample->user_regs.regs, sz);
+   array = (void *)array + sz;
+   } else {
+   *array++ = 0;
+   }
+   }
+
+   if (type & PERF_SAMPLE_STACK_USER) {
+   sz = sample->user_stack.size;
+   *array++ = sz;
+   if (sz) {
+   memcpy(array, sample->user_stack.data, sz);
+   array = (void *)array + sz;
+   *array++ = sz;
+   }
+   }
+
+   if (type & PERF_SAMPLE_WEIGHT) {
+   *array = sample->weight;
+   array++;
+   }
+
+   if (type & PERF_SAMPLE_DATA_SRC) {
+   *array = sample->data_src;
+   array++;
+   }
+
return 0;
 }
 
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please

Re: v3.11-rc1 USB regressions

[Daniel Mack]

Hi Aaro,

On 16.07.2013 00:56, Aaro Koskinen wrote:
> Hi,
> 
> I think USB tree introduced regressions in v3.11-rc1, at least for some
> OMAP devices using legacy boot.

Thanks for checking the tree so early.

> I have only bisected these; I have no
> idea what the real fixes are but the following reverts make Nokia OMAP2+
> boards again usable for kernel development work (they need working USB
> connection for interacting with the device):
> 
> 1) USB peripheral mode (g_ether) is broken on Nokia N900, N950 and N9
>(USB_MUSB_OMAP2PLUS). To make it it work, I need to revert three
>commits:
> 
>   09fc7d22b024692b2fe8a943b246de1af307132b
>   usb: musb: fix incorrect usage of resource pointer
>   (Reverting this fixes the g_ether probe failure "couldn't find
>an available UDC")

Can't say much about this one, but I'd like you to only keep this one
reverted and sort out the regressions in the musb core first.

>   fe4cb0912f8e737f8e4b8b38b9e692f8062f5423
>   usb: musb: gadget: remove hcd initialization
>   (Reverting this fixes error "cdc_ether: probe of 4-1:1.0 failed
>with error -110" seen on the host side.)

Which role does your musb-based hardware have in this case, and which
MUSB_* config symbols do you set? You should have USB_MUSB_GADGET.

>   8b125df5b24cfb0ec7fa1971e343cc0badc1827d
>   usb: musb: eliminate musb_to_hcd
>   (Reverting this fixes compilation error cause by the previous
>revert.)
>
> 2) USB peripheral mode (g_ether) is broken also on Nokia N800 and N810
>(USB_MUSB_TUSB6010). In addition to the above, I need to also revert
>the following:
> 
>   b7e2e75a8c6062afe1dd88b0b299938e5d36dff8
>   usb: gadget: drop unused USB_GADGET_MUSB_HDRC
> 
>(This commit is clearly incorrect - code checking for this still
>remain in the tree (see e.g. N8x0 board file), so it's not "unused".)

Good catch, I didn't expect board files to depend on config symbols that
have no effect on the driver itself.

Please check the attached patch and let me know if it helps.


Thanks,
Daniel


>From 5f33d42f2dffb82d22b83a030f14fe2331a935b7 Mon Sep 17 00:00:00 2001
From: Daniel Mack 
Date: Tue, 16 Jul 2013 08:19:49 +0200
Subject: [PATCH] ARM: omap2: fix musb usage for n8x0

Commit b7e2e75a8c ("usb: gadget: drop unused USB_GADGET_MUSB_HDRC")
dropped a config symbol that was unused by the musb core, but it turns
out that board support code still had references to it.

As the core now handles both dual role and host-only modes, we can just
pass MUSB_OTG as mode from board files.

Signed-off-by: Daniel Mack 
---
 arch/arm/mach-omap2/board-n8x0.c | 4 
 arch/arm/mach-omap2/usb-musb.c   | 5 +
 2 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index f6eeb87..827d150 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -122,11 +122,7 @@ static struct musb_hdrc_config musb_config = {
 };
 
 static struct musb_hdrc_platform_data tusb_data = {
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
 	.mode		= MUSB_OTG,
-#else
-	.mode		= MUSB_HOST,
-#endif
 	.set_power	= tusb_set_power,
 	.min_power	= 25,	/* x2 = 50 mA drawn from VBUS as peripheral */
 	.power		= 100,	/* Max 100 mA VBUS for host mode */
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 8c4de27..bc89723 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -38,11 +38,8 @@ static struct musb_hdrc_config musb_config = {
 };
 
 static struct musb_hdrc_platform_data musb_plat = {
-#ifdef CONFIG_USB_GADGET_MUSB_HDRC
 	.mode		= MUSB_OTG,
-#else
-	.mode		= MUSB_HOST,
-#endif
+
 	/* .clock is set dynamically */
 	.config		= &musb_config,
 
-- 
1.8.1.4

Re: [RFC PATCH 00/11] ARM: DT: update cpu device of_node

[Viresh Kumar]

On 15 July 2013 15:52,   wrote:
> Sudeep KarkadaNagesha (11):
>   cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes
>   cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
>   cpufreq: highbank-cpufreq: remove device tree parsing for cpu nodes
>   cpufreq: spear-cpufreq: remove device tree parsing for cpu nodes
>   cpufreq: kirkwood-cpufreq: remove device tree parsing for cpu nodes
>   cpufreq: arm_big_little: remove device tree parsing for cpu nodes

For cpufreq part:

Acked-by: Viresh Kumar 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 01/12] perf tools: add debug prints

[Adrian Hunter]

It is useful to see the arguments to perf_event_open
and whether the perf events ring buffer was mmapped
per-cpu or per-thread.  That information will now be
displayed when verbose is 2 i.e option -vv

Signed-off-by: Adrian Hunter 
Acked-by: Jiri Olsa 
---
 tools/perf/util/evlist.c |  3 +++
 tools/perf/util/evsel.c  | 58 
 2 files changed, 61 insertions(+)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 42ea4e9..2b77b33 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -14,6 +14,7 @@
 #include "target.h"
 #include "evlist.h"
 #include "evsel.h"
+#include "debug.h"
 #include 
 
 #include "parse-events.h"
@@ -454,6 +455,7 @@ static int perf_evlist__mmap_per_cpu(struct perf_evlist 
*evlist, int prot, int m
int nr_cpus = cpu_map__nr(evlist->cpus);
int nr_threads = thread_map__nr(evlist->threads);
 
+   pr_debug2("perf event ring buffer mmapped per cpu\n");
for (cpu = 0; cpu < nr_cpus; cpu++) {
int output = -1;
 
@@ -492,6 +494,7 @@ static int perf_evlist__mmap_per_thread(struct perf_evlist 
*evlist, int prot, in
int thread;
int nr_threads = thread_map__nr(evlist->threads);
 
+   pr_debug2("perf event ring buffer mmapped per thread\n");
for (thread = 0; thread < nr_threads; thread++) {
int output = -1;
 
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index a635461..0b9c4fd 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -21,6 +21,7 @@
 #include "thread_map.h"
 #include "target.h"
 #include "perf_regs.h"
+#include "debug.h"
 
 static struct {
bool sample_id_all;
@@ -817,6 +818,58 @@ static int get_group_fd(struct perf_evsel *evsel, int cpu, 
int thread)
return fd;
 }
 
+static size_t perf_event_attr__fprintf(struct perf_event_attr *attr, FILE *fp)
+{
+   size_t ret;
+
+   ret = fprintf(fp, 
"\n");
+   ret += fprintf(fp, "perf_event_attr:\n");
+   ret += fprintf(fp, "  type%u\n", attr->type);
+   ret += fprintf(fp, "  size%u\n", attr->size);
+   ret += fprintf(fp, "  config  %#"PRIx64"\n", 
(uint64_t)attr->config);
+   ret += fprintf(fp, "  sample_period   %"PRIu64"\n", 
(uint64_t)attr->sample_period);
+   ret += fprintf(fp, "  sample_freq %"PRIu64"\n", 
(uint64_t)attr->sample_freq);
+   ret += fprintf(fp, "  sample_type %#"PRIx64"\n", 
(uint64_t)attr->sample_type);
+   ret += fprintf(fp, "  read_format %#"PRIx64"\n", 
(uint64_t)attr->read_format);
+
+   ret += fprintf(fp, "  disabled%u", attr->disabled);
+   ret += fprintf(fp, "inherit %u\n", attr->inherit);
+   ret += fprintf(fp, "  pinned  %u", attr->pinned);
+   ret += fprintf(fp, "exclusive   %u\n", attr->exclusive);
+   ret += fprintf(fp, "  exclude_user%u", attr->exclude_user);
+   ret += fprintf(fp, "exclude_kernel  %u\n", attr->exclude_kernel);
+   ret += fprintf(fp, "  exclude_hv  %u", attr->exclude_hv);
+   ret += fprintf(fp, "exclude_idle%u\n", attr->exclude_idle);
+   ret += fprintf(fp, "  mmap%u", attr->mmap);
+   ret += fprintf(fp, "comm%u\n", attr->comm);
+   ret += fprintf(fp, "  freq%u", attr->freq);
+   ret += fprintf(fp, "inherit_stat%u\n", attr->inherit_stat);
+   ret += fprintf(fp, "  enable_on_exec  %u", 
attr->enable_on_exec);
+   ret += fprintf(fp, "task%u\n", attr->task);
+   ret += fprintf(fp, "  watermark   %u", attr->watermark);
+   ret += fprintf(fp, "precise_ip  %u\n", attr->precise_ip);
+   ret += fprintf(fp, "  mmap_data   %u", attr->mmap_data);
+   ret += fprintf(fp, "sample_id_all   %u\n", attr->sample_id_all);
+   ret += fprintf(fp, "  exclude_host%u", attr->exclude_host);
+   ret += fprintf(fp, "exclude_guest   %u\n", attr->exclude_guest);
+   ret += fprintf(fp, "  excl.callchain.kern %u", 
attr->exclude_callchain_kernel);
+   ret += fprintf(fp, "excl.callchain.user %u\n", 
attr->exclude_callchain_user);
+
+   ret += fprintf(fp, "  wakeup_events   %u\n", attr->wakeup_events);
+   ret += fprintf(fp, "  wakeup_watermark%u\n", 
attr->wakeup_watermark);
+   ret += fprintf(fp, "  bp_type %#x\n", attr->bp_type);
+   ret += fprintf(fp, "  bp_addr %#"PRIx64"\n", 
(uint64_t)attr->bp_addr);
+   ret += fprintf(fp, "  config1 %#"PRIx64"\n", 
(uint64_t)attr->config1);
+   ret += fprintf(fp, "  bp_len  %"PRIu64"\n", 
(uint64_t)attr->bp_len);
+   ret += fprintf(fp, "  config2 %#"PRIx64"\n", 
(uint64_t)attr->config2);
+   ret += f

[PATCH V6 02/12] perf tools: allow non-matching sample types

[Adrian Hunter]

Sample types need not be identical to determine
the sample id from the event.  Only the position
of the sample id needs to be the same.

Compatible sample types are ones in which the bits
defined by PERF_COMPAT_MASK are the same.
'perf_evlist__config()' forces sample types to be
compatible on that basis.

Signed-off-by: Adrian Hunter 
---
 tools/perf/builtin-report.c |   2 +-
 tools/perf/util/event.h |  14 +
 tools/perf/util/evlist.c| 136 ++--
 tools/perf/util/evlist.h|   8 ++-
 tools/perf/util/evsel.c |  64 -
 tools/perf/util/evsel.h |  10 
 tools/perf/util/session.c   |   8 ++-
 7 files changed, 231 insertions(+), 11 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index a34c587..7b6a2bb 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -367,7 +367,7 @@ static int process_read_event(struct perf_tool *tool,
 static int perf_report__setup_sample_type(struct perf_report *rep)
 {
struct perf_session *self = rep->session;
-   u64 sample_type = perf_evlist__sample_type(self->evlist);
+   u64 sample_type = perf_evlist__combined_sample_type(self->evlist);
 
if (!self->fd_pipe && !(sample_type & PERF_SAMPLE_CALLCHAIN)) {
if (sort__has_parent) {
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 1ebb8fb..e60585e 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -65,6 +65,20 @@ struct read_event {
PERF_SAMPLE_ID | PERF_SAMPLE_STREAM_ID |\
 PERF_SAMPLE_CPU | PERF_SAMPLE_PERIOD)
 
+/*
+ * Events have compatible sample types if the following bits all have the same
+ * value.  This is because the order of sample members is fixed.  For sample
+ * events the order is: PERF_SAMPLE_IP, PERF_SAMPLE_TID, PERF_SAMPLE_TIME,
+ * PERF_SAMPLE_ADDR, PERF_SAMPLE_ID.  For non-sample events the sample members
+ * are accessed in reverse order.  The order is: PERF_SAMPLE_ID,
+ * PERF_SAMPLE_STREAM_ID, PERF_SAMPLE_CPU.
+ */
+#define PERF_COMPAT_MASK   \
+   (PERF_SAMPLE_IP   | PERF_SAMPLE_TID   | \
+PERF_SAMPLE_TIME | PERF_SAMPLE_ADDR  | \
+PERF_SAMPLE_ID   | PERF_SAMPLE_STREAM_ID | \
+PERF_SAMPLE_CPU)
+
 struct sample_event {
struct perf_event_headerheader;
u64 array[];
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 2b77b33..b8a5a75 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -49,6 +49,46 @@ struct perf_evlist *perf_evlist__new(void)
return evlist;
 }
 
+/**
+ * perf_evlist__set_id_pos - set the positions of event ids.
+ * @evlist: selected event list
+ *
+ * Events with compatible sample types all have the same id_pos
+ * and is_pos.  For convenience, put a copy on evlist.
+ */
+static void perf_evlist__set_id_pos(struct perf_evlist *evlist)
+{
+   struct perf_evsel *first = perf_evlist__first(evlist);
+
+   evlist->id_pos = first->id_pos;
+   evlist->is_pos = first->is_pos;
+}
+
+/**
+ * perf_evlist__make_sample_types_compatible - make sample types compatible.
+ * @evlist: selected event list
+ *
+ * Events with compatible sample types all have the same id_pos and is_pos.
+ * This can be achieved by matching the bits of PERF_COMPAT_MASK.
+ */
+void perf_evlist__make_sample_types_compatible(struct perf_evlist *evlist)
+{
+   struct perf_evsel *evsel;
+   u64 compat = 0;
+
+   list_for_each_entry(evsel, &evlist->entries, node)
+   compat |= evsel->attr.sample_type & PERF_COMPAT_MASK;
+
+   list_for_each_entry(evsel, &evlist->entries, node) {
+   evsel->attr.sample_type |= compat;
+   evsel->sample_size =
+   __perf_evsel__sample_size(evsel->attr.sample_type);
+   perf_evsel__calc_id_pos(evsel);
+   }
+
+   perf_evlist__set_id_pos(evlist);
+}
+
 void perf_evlist__config(struct perf_evlist *evlist,
struct perf_record_opts *opts)
 {
@@ -69,6 +109,8 @@ void perf_evlist__config(struct perf_evlist *evlist,
if (evlist->nr_entries > 1)
perf_evsel__set_sample_id(evsel);
}
+
+   perf_evlist__make_sample_types_compatible(evlist);
 }
 
 static void perf_evlist__purge(struct perf_evlist *evlist)
@@ -102,6 +144,7 @@ void perf_evlist__add(struct perf_evlist *evlist, struct 
perf_evsel *entry)
 {
list_add_tail(&entry->node, &evlist->entries);
++evlist->nr_entries;
+   perf_evlist__set_id_pos(evlist);
 }
 
 void perf_evlist__splice_list_tail(struct perf_evlist *evlist,
@@ -110,6 +153,7 @@ void perf_evlist__splice_list_tail(struct perf_evlist 
*evlist,
 {
list_splice_tail(list, &evlist->entries);
evlist->nr_entries += nr_entries;
+   perf_evlist__set_id_pos(evlist);
 }
 
 void __perf_evlist__set_leader(struct list_head *list)
@@ -

[PATCH V6 07/12] perf tools: remove references to struct ip_event

[Adrian Hunter]

struct ip_event assumes fixeed positions for ip, pid
and tid.  That is no longer true with the addition of
PERF_SAMPLE_IDENTIFIER.  The information is anyway in
struct sample, so use that instead.

Signed-off-by: Adrian Hunter 
---
 tools/perf/builtin-inject.c   |  4 ++--
 tools/perf/builtin-kmem.c |  4 ++--
 tools/perf/builtin-mem.c  |  2 +-
 tools/perf/builtin-script.c   |  4 ++--
 tools/perf/builtin-top.c  | 11 ++-
 tools/perf/tests/hists_link.c |  4 
 tools/perf/util/build-id.c|  8 
 tools/perf/util/event.c   |  6 +++---
 tools/perf/util/evsel.c   |  4 ++--
 tools/perf/util/session.c |  8 +---
 10 files changed, 31 insertions(+), 24 deletions(-)

diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 0d4ae1d..ffacd46 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -198,7 +198,7 @@ static int perf_event__inject_buildid(struct perf_tool 
*tool,
 
cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
 
-   thread = machine__findnew_thread(machine, event->ip.pid, event->ip.pid);
+   thread = machine__findnew_thread(machine, sample->pid, sample->pid);
if (thread == NULL) {
pr_err("problem processing %d event, skipping it.\n",
   event->header.type);
@@ -206,7 +206,7 @@ static int perf_event__inject_buildid(struct perf_tool 
*tool,
}
 
thread__find_addr_map(thread, machine, cpumode, MAP__FUNCTION,
- event->ip.ip, &al);
+ sample->ip, &al);
 
if (al.map != NULL) {
if (!al.map->dso->hit) {
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index c324778..c2dff9c 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -305,8 +305,8 @@ static int process_sample_event(struct perf_tool *tool 
__maybe_unused,
struct perf_evsel *evsel,
struct machine *machine)
 {
-   struct thread *thread = machine__findnew_thread(machine, event->ip.pid,
-   event->ip.pid);
+   struct thread *thread = machine__findnew_thread(machine, sample->pid,
+   sample->pid);
 
if (thread == NULL) {
pr_debug("problem processing %d event, skipping it.\n",
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index a8ff6d2..4274680 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -96,7 +96,7 @@ dump_raw_samples(struct perf_tool *tool,
symbol_conf.field_sep,
sample->tid,
symbol_conf.field_sep,
-   event->ip.ip,
+   sample->ip,
symbol_conf.field_sep,
sample->addr,
symbol_conf.field_sep,
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index b094b33..05e1db2 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -480,8 +480,8 @@ static int process_sample_event(struct perf_tool *tool 
__maybe_unused,
struct machine *machine)
 {
struct addr_location al;
-   struct thread *thread = machine__findnew_thread(machine, event->ip.pid,
-   event->ip.tid);
+   struct thread *thread = machine__findnew_thread(machine, sample->pid,
+   sample->tid);
 
if (thread == NULL) {
pr_debug("problem processing %d event, skipping it.\n",
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index bbf4635..0ecec5f 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -690,7 +690,7 @@ static void perf_event__process_sample(struct perf_tool 
*tool,
 {
struct perf_top *top = container_of(tool, struct perf_top, tool);
struct symbol *parent = NULL;
-   u64 ip = event->ip.ip;
+   u64 ip = sample->ip;
struct addr_location al;
int err;
 
@@ -700,10 +700,10 @@ static void perf_event__process_sample(struct perf_tool 
*tool,
if (!seen)
seen = intlist__new(NULL);
 
-   if (!intlist__has_entry(seen, event->ip.pid)) {
+   if (!intlist__has_entry(seen, sample->pid)) {
pr_err("Can't find guest [%d]'s kernel information\n",
-   event->ip.pid);
-   intlist__add(seen, event->ip.pid);
+   sample->pid);
+   intlist__add(seen, sample->pid);
}
return;
}
@@ -838,7 +838,8 @@ static void perf_top__mmap_read_idx(struct perf_top *top, 
int idx)
break;
case PERF_RECORD_MISC_GUEST_KERNEL:
++top

[PATCH V6 06/12] perf tools: remove unnecessary callchain validation

[Adrian Hunter]

Now that the sample parsing correctly checks data sizes
there is no reason for it to be done again for callchains.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/callchain.c |  8 
 tools/perf/util/callchain.h |  5 -
 tools/perf/util/session.c   | 20 
 3 files changed, 33 deletions(-)

diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 42b6a63..024162a 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -20,14 +20,6 @@
 
 __thread struct callchain_cursor callchain_cursor;
 
-bool ip_callchain__valid(struct ip_callchain *chain,
-const union perf_event *event)
-{
-   unsigned int chain_size = event->header.size;
-   chain_size -= (unsigned long)&event->ip.__more_data - (unsigned 
long)event;
-   return chain->nr * sizeof(u64) <= chain_size;
-}
-
 #define chain_for_each_child(child, parent)\
list_for_each_entry(child, &parent->children, siblings)
 
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index 3ee9f67..988c1aa 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -103,11 +103,6 @@ int callchain_append(struct callchain_root *root,
 int callchain_merge(struct callchain_cursor *cursor,
struct callchain_root *dst, struct callchain_root *src);
 
-struct ip_callchain;
-union perf_event;
-
-bool ip_callchain__valid(struct ip_callchain *chain,
-const union perf_event *event);
 /*
  * Initialize a cursor before adding entries inside, but keep
  * the previously allocated entries as a cache.
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 708c72b..1b07d7a 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -889,22 +889,6 @@ static int perf_session_deliver_event(struct perf_session 
*session,
}
 }
 
-static int perf_session__preprocess_sample(struct perf_session *session,
-  union perf_event *event, struct 
perf_sample *sample)
-{
-   if (event->header.type != PERF_RECORD_SAMPLE ||
-   !sample->callchain)
-   return 0;
-
-   if (!ip_callchain__valid(sample->callchain, event)) {
-   pr_debug("call-chain problem with event, skipping it.\n");
-   ++session->stats.nr_invalid_chains;
-   session->stats.total_invalid_chains += sample->period;
-   return -EINVAL;
-   }
-   return 0;
-}
-
 static int perf_session__process_user_event(struct perf_session *session, 
union perf_event *event,
struct perf_tool *tool, u64 
file_offset)
 {
@@ -967,10 +951,6 @@ static int perf_session__process_event(struct perf_session 
*session,
if (ret)
return ret;
 
-   /* Preprocess sample records - precheck callchains */
-   if (perf_session__preprocess_sample(session, event, &sample))
-   return 0;
-
if (tool->ordered_samples) {
ret = perf_session_queue_event(session, event, &sample,
   file_offset);
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V6 04/12] perf tools: change machine__findnew_thread() to set thread pid

[Adrian Hunter]

Add a new parameter for 'pid' to machine__findnew_thread().
Change callers to pass 'pid' when it is known.

Signed-off-by: Adrian Hunter 
---
 tools/perf/builtin-inject.c   |  2 +-
 tools/perf/builtin-kmem.c |  3 ++-
 tools/perf/builtin-kvm.c  |  3 ++-
 tools/perf/builtin-lock.c |  3 ++-
 tools/perf/builtin-sched.c| 17 +
 tools/perf/builtin-script.c   |  3 ++-
 tools/perf/builtin-trace.c| 12 +---
 tools/perf/tests/hists_link.c |  3 ++-
 tools/perf/util/build-id.c|  7 +--
 tools/perf/util/event.c   |  3 ++-
 tools/perf/util/machine.c | 23 ---
 tools/perf/util/machine.h |  3 ++-
 tools/perf/util/session.c |  2 +-
 13 files changed, 55 insertions(+), 29 deletions(-)

diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 1d8de2e..0d4ae1d 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -198,7 +198,7 @@ static int perf_event__inject_buildid(struct perf_tool 
*tool,
 
cpumode = event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
 
-   thread = machine__findnew_thread(machine, event->ip.pid);
+   thread = machine__findnew_thread(machine, event->ip.pid, event->ip.pid);
if (thread == NULL) {
pr_err("problem processing %d event, skipping it.\n",
   event->header.type);
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index b49f5c5..c324778 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -305,7 +305,8 @@ static int process_sample_event(struct perf_tool *tool 
__maybe_unused,
struct perf_evsel *evsel,
struct machine *machine)
 {
-   struct thread *thread = machine__findnew_thread(machine, event->ip.pid);
+   struct thread *thread = machine__findnew_thread(machine, event->ip.pid,
+   event->ip.pid);
 
if (thread == NULL) {
pr_debug("problem processing %d event, skipping it.\n",
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 24b78ae..ecbbec8 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -691,7 +691,8 @@ static int process_sample_event(struct perf_tool *tool,
struct perf_evsel *evsel,
struct machine *machine)
 {
-   struct thread *thread = machine__findnew_thread(machine, sample->tid);
+   struct thread *thread = machine__findnew_thread(machine, sample->pid,
+   sample->tid);
struct perf_kvm_stat *kvm = container_of(tool, struct perf_kvm_stat,
 tool);
 
diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index 76543a4..ee33ba2 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -805,7 +805,8 @@ static int process_sample_event(struct perf_tool *tool 
__maybe_unused,
struct perf_evsel *evsel,
struct machine *machine)
 {
-   struct thread *thread = machine__findnew_thread(machine, sample->tid);
+   struct thread *thread = machine__findnew_thread(machine, sample->pid,
+   sample->tid);
 
if (thread == NULL) {
pr_debug("problem processing %d event, skipping it.\n",
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 948183a..49593a0 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -934,8 +934,8 @@ static int latency_switch_event(struct perf_sched *sched,
return -1;
}
 
-   sched_out = machine__findnew_thread(machine, prev_pid);
-   sched_in = machine__findnew_thread(machine, next_pid);
+   sched_out = machine__findnew_thread(machine, 0, prev_pid);
+   sched_in = machine__findnew_thread(machine, 0, next_pid);
 
out_events = thread_atoms_search(&sched->atom_root, sched_out, 
&sched->cmp_pid);
if (!out_events) {
@@ -978,7 +978,7 @@ static int latency_runtime_event(struct perf_sched *sched,
 {
const u32 pid  = perf_evsel__intval(evsel, sample, "pid");
const u64 runtime  = perf_evsel__intval(evsel, sample, "runtime");
-   struct thread *thread = machine__findnew_thread(machine, pid);
+   struct thread *thread = machine__findnew_thread(machine, 0, pid);
struct work_atoms *atoms = thread_atoms_search(&sched->atom_root, 
thread, &sched->cmp_pid);
u64 timestamp = sample->time;
int cpu = sample->cpu;
@@ -1016,7 +1016,7 @@ static int latency_wakeup_event(struct perf_sched *sched,
if (!success)
return 0;
 
-   wakee = machine__findnew_thread(machine, pid);
+   wakee = machine__findnew_thread(machine, 0, pid);
atoms = thread_atoms_search(&sched->atom_ro

[PATCH V6 12/12] perf tools: add a sample parsing test

[Adrian Hunter]

Add a test that checks that sample parsing is correctly
implemented.

Signed-off-by: Adrian Hunter 
---
 tools/perf/Makefile   |   1 +
 tools/perf/tests/builtin-test.c   |   4 +
 tools/perf/tests/sample-parsing.c | 240 ++
 tools/perf/tests/tests.h  |   1 +
 4 files changed, 246 insertions(+)
 create mode 100644 tools/perf/tests/sample-parsing.c

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 5b7c6db..fe20130 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -389,6 +389,7 @@ LIB_OBJS += $(OUTPUT)tests/bp_signal.o
 LIB_OBJS += $(OUTPUT)tests/bp_signal_overflow.o
 LIB_OBJS += $(OUTPUT)tests/task-exit.o
 LIB_OBJS += $(OUTPUT)tests/sw-clock.o
+LIB_OBJS += $(OUTPUT)tests/sample-parsing.o
 
 BUILTIN_OBJS += $(OUTPUT)builtin-annotate.o
 BUILTIN_OBJS += $(OUTPUT)builtin-bench.o
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 35b45f1466..5ee3933 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -94,6 +94,10 @@ static struct test {
.func = test__sw_clock_freq,
},
{
+   .desc = "Test sample parsing",
+   .func = test__sample_parsing,
+   },
+   {
.func = NULL,
},
 };
diff --git a/tools/perf/tests/sample-parsing.c 
b/tools/perf/tests/sample-parsing.c
new file mode 100644
index 000..c6e6813
--- /dev/null
+++ b/tools/perf/tests/sample-parsing.c
@@ -0,0 +1,240 @@
+#include 
+#include 
+
+#include "event.h"
+#include "evsel.h"
+
+#include "tests.h"
+
+#define COMP(m) {  \
+   while (s1->m != s2->m) {\
+   pr_debug("Samples differ at '"#m"'\n"); \
+   return false;   \
+   }   \
+}
+
+#define MCOMP(m) { \
+   while (memcmp(&s1->m, &s2->m, sizeof(s1->m))) { \
+   pr_debug("Samples differ at '"#m"'\n"); \
+   return false;   \
+   }   \
+}
+
+static bool samples_same(const struct perf_sample *s1,
+const struct perf_sample *s2, u64 type, u64 regs_user)
+{
+   size_t i;
+
+   if (type & PERF_SAMPLE_IDENTIFIER)
+   COMP(id);
+
+   if (type & PERF_SAMPLE_IP)
+   COMP(ip);
+
+   if (type & PERF_SAMPLE_TID) {
+   COMP(pid);
+   COMP(tid);
+   }
+
+   if (type & PERF_SAMPLE_TIME)
+   COMP(time);
+
+   if (type & PERF_SAMPLE_ADDR)
+   COMP(addr);
+
+   if (type & PERF_SAMPLE_ID)
+   COMP(id);
+
+   if (type & PERF_SAMPLE_STREAM_ID)
+   COMP(stream_id);
+
+   if (type & PERF_SAMPLE_CPU)
+   COMP(cpu);
+
+   if (type & PERF_SAMPLE_PERIOD)
+   COMP(period);
+
+   if (type & PERF_SAMPLE_CALLCHAIN) {
+   COMP(callchain->nr);
+   for (i = 0; i < s1->callchain->nr; i++)
+   COMP(callchain->ips[i]);
+   }
+
+   if (type & PERF_SAMPLE_RAW) {
+   COMP(raw_size);
+   if (memcmp(s1->raw_data, s2->raw_data, s1->raw_size)) {
+   pr_debug("Samples differ at 'raw_data'\n");
+   return false;
+   }
+   }
+
+   if (type & PERF_SAMPLE_BRANCH_STACK) {
+   COMP(branch_stack->nr);
+   for (i = 0; i < s1->branch_stack->nr; i++)
+   MCOMP(branch_stack->entries[i]);
+   }
+
+   if (type & PERF_SAMPLE_REGS_USER) {
+   size_t sz = hweight_long(regs_user) * sizeof(u64);
+
+   if ((sz && (!s1->user_regs.regs || !s2->user_regs.regs)) ||
+   memcmp(s1->user_regs.regs, s2->user_regs.regs, sz)) {
+   pr_debug("Samples differ at 'user_regs'\n");
+   return false;
+   }
+   }
+
+   if (type & PERF_SAMPLE_STACK_USER) {
+   COMP(user_stack.size);
+   if (memcmp(s1->user_stack.data, s1->user_stack.data,
+  s1->user_stack.size)) {
+   pr_debug("Samples differ at 'user_stack'\n");
+   return false;
+   }
+   }
+
+   if (type & PERF_SAMPLE_WEIGHT)
+   COMP(weight);
+
+   if (type & PERF_SAMPLE_DATA_SRC)
+   COMP(data_src);
+
+   return true;
+}
+
+static int do_test(u64 sample_type, u64 sample_regs_user)
+{
+   struct perf_evsel evsel = {
+   .needs_swap = false,
+   .attr = {
+   .sample_type = sample_type,
+   .sample_regs_user = sample_regs_user,
+   },
+   };
+   union perf_event event = {
+   .header = {
+   .t

[PATCH V6 05/12] perf tools: tidy up sample parsing overflow checking

[Adrian Hunter]

The size of data retrieved from a sample event must be
validated to ensure it does not go past the end of the
event.  That was being done sporadically and without
considering integer overflows.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/evsel.c | 102 ++--
 1 file changed, 64 insertions(+), 38 deletions(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 724b75a..20e2ed9 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1114,24 +1114,38 @@ static int perf_evsel__parse_id_sample(const struct 
perf_evsel *evsel,
return 0;
 }
 
-static bool sample_overlap(const union perf_event *event,
-  const void *offset, u64 size)
+static inline bool overflow_one(const void *endp, const void *offset)
 {
-   const void *base = event;
-
-   if (offset + size > base + event->header.size)
-   return true;
+   return offset + sizeof(u64) > endp;
+}
 
-   return false;
+static inline bool overflow(const void *endp, u16 max_size, const void *offset,
+   u64 size)
+{
+   return size > max_size || offset + size > endp;
 }
 
+#define OVERFLOW_CHECK_ONE(offset) \
+   do {\
+   if (overflow_one(endp, (offset)))   \
+   return -EFAULT; \
+   } while (0)
+
+#define OVERFLOW_CHECK(offset, size)   \
+   do {\
+   if (overflow(endp, max_size, (offset), (size))) \
+   return -EFAULT; \
+   } while (0)
+
 int perf_evsel__parse_sample(struct perf_evsel *evsel, union perf_event *event,
 struct perf_sample *data)
 {
u64 type = evsel->attr.sample_type;
-   u64 regs_user = evsel->attr.sample_regs_user;
bool swapped = evsel->needs_swap;
const u64 *array;
+   u16 max_size = event->header.size;
+   const void *endp = (void *)event + max_size;
+   u64 sz;
 
/*
 * used for cross-endian analysis. See git commit 65014ab3
@@ -1153,6 +1167,11 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel, 
union perf_event *event,
 
array = event->sample.array;
 
+   /*
+* sample_size is based on PERF_SAMPLE_MASK which includes up to
+* PERF_SAMPLE_PERIOD.  After that overflow_one() or overflow() must be
+* used to check the format does not go past the end of the event.
+*/
if (evsel->sample_size + sizeof(event->header) > event->header.size)
return -EFAULT;
 
@@ -1221,20 +1240,19 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel, 
union perf_event *event,
}
 
if (type & PERF_SAMPLE_CALLCHAIN) {
-   if (sample_overlap(event, array, sizeof(data->callchain->nr)))
-   return -EFAULT;
-
-   data->callchain = (struct ip_callchain *)array;
+   const u64 max_callchain_nr = UINT64_MAX / sizeof(u64);
 
-   if (sample_overlap(event, array, data->callchain->nr))
+   OVERFLOW_CHECK_ONE(array);
+   data->callchain = (struct ip_callchain *)array++;
+   if (data->callchain->nr > max_callchain_nr)
return -EFAULT;
-
-   array += 1 + data->callchain->nr;
+   sz = data->callchain->nr * sizeof(u64);
+   OVERFLOW_CHECK(array, sz);
+   array = (void *)array + sz;
}
 
if (type & PERF_SAMPLE_RAW) {
-   const u64 *pdata;
-
+   OVERFLOW_CHECK_ONE(array);
u.val64 = *array;
if (WARN_ONCE(swapped,
  "Endianness of raw data not corrected!\n")) {
@@ -1243,65 +1261,73 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel, 
union perf_event *event,
u.val32[0] = bswap_32(u.val32[0]);
u.val32[1] = bswap_32(u.val32[1]);
}
-
-   if (sample_overlap(event, array, sizeof(u32)))
-   return -EFAULT;
-
data->raw_size = u.val32[0];
-   pdata = (void *) array + sizeof(u32);
+   array = (void *)array + sizeof(u32);
 
-   if (sample_overlap(event, pdata, data->raw_size))
-   return -EFAULT;
-
-   data->raw_data = (void *) pdata;
-
-   array = (void *)array + data->raw_size + sizeof(u32);
+   OVERFLOW_CHECK(array, data->raw_size);
+   data->raw_data = (void *)array;
+   array = (void *)array + data->raw_size;
}
 
if (type & PERF_SAMPLE_BRANCH_STACK) {
-   u64 sz;
+   const u64 max_branch_nr = UINT64_MAX /
+ 

Re: [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume

[Daniel Vetter]

On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khlebnikov wrote:
> Daniel Vetter wrote:
> >On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
> >  wrote:
> >>This patch fixes regression in power consumtion of sandy bridge gpu, which
> >>exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking 
> >>that
> >>it's extremely busy. After that it never reaches rc6 state.
> >>
> >>Bug was introduce by commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
> >>("drm/i915: load boot context at driver init time"). Without documentation
> >>it's not clear what is happening here, probably this breaks internal state 
> >>of
> >>hardware ring buffers and confuses RPS engine. Fortunately keeping forcewake
> >>during whole initialization sequence in gen6_init_clock_gating() fixes this 
> >>bug.
> >>
> >>References: https://bugs.freedesktop.org/show_bug.cgi?id=54089
> >>Signed-off-by: Konstantin Khlebnikov
> >
> >We already hold an forcewake reference while setting up the rps stuff,
> >should we maybe hold the forcewake for the entire duration, i.e. grab
> >it here in clock_gating and release it only in gen6/vlv_enable_rps?
> >Can you please test that version, too?
> 
> This will be racy because rps stuff is done in separate work which might be 
> canceled
> if intel_disable_gt_powersave() happens before its completion.

Can be fixed with a flush_delayed_work. And since that has the same
requirements wrt locking to prevent deadlocks as cancel_work_sync it would
be a drop-in replacement. Can I volunteer you to look into testing that
out a bit? Otherwise I could volunteer someone from our team.

In any case I think we should apply this trick to all platforms where
we've added the MBCTL write (i.e. snb, ivb, hsw & vlv) since rps/rc6 works
_very_ similar on all of those.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 02/11] ARM: DT/kernel: define ARM specific arch_of_get_cpu_node

[Viresh Kumar]

On 16 July 2013 00:40, Rob Herring  wrote:
> The powermac cpufreq driver could probably also be converted
> (arch/powerpc/platforms/powermac/cpufreq_64.c).

Its called: drivers/cpufreq/pmac64-cpufreq.c now.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

[Greg KH]

On Tue, Jul 16, 2013 at 10:10:31AM +0400, James Bottomley wrote:
> On Mon, 2013-07-15 at 17:06 -0700, Greg KH wrote:
> > On Mon, Jul 15, 2013 at 06:01:39PM -0400, Steven Rostedt wrote:
> > > On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote:
> > > 
> > > > I don't like this at all, just for the simple reason that it will push
> > > > the majority of the work of stable kernel development on to the
> > > > subsystem maintainers, who have enough work to do as it is.
> > > > 
> > > > Stable tree stuff should cause almost _no_ extra burden on the kernel
> > > > developers, because it is something that I, and a few other people, have
> > > > agreed to do with our time.  It has taken me 8 _years_ to finally get
> > > > maintainers to agree to mark stuff for the stable tree, and fine-tune a
> > > > development process that makes it easy for us to do this backport work.
> > > 
> > > Although, since those 8 years, the stable tree has proven its
> > > importance.
> > > 
> > > Is a extra "ack" also too much to ask?
> > 
> > Maintainers are our most limited resource, I'm getting their "ack" when
> > they themselves tag the patch to be backported with the Cc: line.
> > 
> > I then cc: them when the patch goes into the patch queue.
> > 
> > I then cc: them again when the patch is in the -rc1 phase.
> > 
> > How many times do I need to do this to give people a chance to say
> > "nak"?
> 
> Just to pick up on this, the problem from my perspective is that this
> cc: goes into my personal inbox.  From a list perspective this just
> doesn't work.  The entirety of my workflow is set up to operate from the
> mailing lists.  My inbox is for my day job.  It gets about 100 emails or
> more a day and anything that goes in there and doesn't get looked at for
> a day gets lost.  I sometimes feel guilty about seeing stable reviews
> whiz by, but not necessarily guilty enough to go back and try to find
> them.  I have thought of using filtering to manually place these into a
> deferred mailbox for later use.  However, the problem is that my work
> inbox is exchange, and the only tags I could filter on seem to be in the
> body (exchange does body filtering about as elegantly as a penguin
> flies).
> 
> That's where the suggestion to drop cc: stable@ came from.  I realise
> the workflow just isn't working for me.
> 
> I say we have the discussion at KS then I'll investigate a different
> workflow for SCSI.

KS is in November, feel free to not tag patches Cc: stable for scsi if
you don't want to use the existing workflow, and try something else now.

All I need, at the least, is a list of git ids to apply to the stable
tree(s), send them to sta...@vger.kernel.org and I can take it from
there with my tools.

If you want to test things separately, send me a tree to pull, or a mbox
to apply, that works as well.  You can do all of these without having to
wait until November.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 01/11] driver/core: cpu: initialize of_node in cpu's device struture

[Viresh Kumar]

On 15 July 2013 15:52,   wrote:
> From: Sudeep KarkadaNagesha 
>
> CPUs are also registered as devices but the of_node in these cpu
> devices are not initialized. Currently different drivers requiring
> to access cpu device node are parsing the nodes themselves and
> initialising the of_node in cpu device.
>
> The of_node in all the cpu devices properly needs to be initialized

s/properly /

> properly and at one place. The best place to update this is CPU
> subsystem driver when registering the cpu devices.
>
> This patch introduces a new function arch_of_get_cpu_node and uses it
> to assign of_node. The definition of this function can be overridden
> by architecture specific implementation.
>
> Signed-off-by: Sudeep KarkadaNagesha 
> ---
>  drivers/base/cpu.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index a16d20e..4b3047a 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -28,6 +28,24 @@ static int cpu_subsys_match(struct device *dev, struct 
> device_driver *drv)
> return 0;
>  }
>
> +/**
> + * arch_of_get_cpu_node - Get device node associated with the given logical 
> CPU
> + * @cpu: CPU number(logical index) for which device node is required
> + *
> + * The only purpose of this function is to retrieve the device node for the
> + * given logical CPU index. It should be used to intialise the of_node in
> + * cpu device. Once of_node in cpu device is populated, all the further
> + * references can use that instead.
> + *
> + * CPU logical to physical index mapping is architecure specific and is built
> + * before booting secondary cores. Hence this function is marked __weak and
> + * can be overridden by architecture specific implementation.
> + */
> +struct device_node * __weak arch_of_get_cpu_node(int cpu)
> +{
> +   return NULL;
> +}
> +
>  #ifdef CONFIG_HOTPLUG_CPU
>  static void change_cpu_under_node(struct cpu *cpu,
> unsigned int from_nid, unsigned int to_nid)
> @@ -289,6 +307,7 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
> cpu->dev.release = cpu_device_release;
> cpu->dev.offline_disabled = !cpu->hotpluggable;
> cpu->dev.offline = !cpu_online(num);
> +   cpu->dev.of_node = arch_of_get_cpu_node(num);
>  #ifdef CONFIG_ARCH_HAS_CPU_AUTOPROBE
> cpu->dev.bus->uevent = arch_cpu_uevent;
>  #endif
> --
> 1.8.1.2
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ALSA: hda - Add new GPU codec ID to snd-hda

[Takashi Iwai]

At Fri, 12 Jul 2013 11:01:37 -0700,
Aaron Plattner wrote:
> 
> Vendor ID 0x10de0060 is used by a yet-to-be-named GPU chip.
> 
> Reviewed-by: Andy Ritger 
> Signed-off-by: Aaron Plattner 

Forgot to mention that the patch was applied.

Thanks.


Takashi

> ---
>  sound/pci/hda/patch_hdmi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index e12f7a0..486def7 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -2536,6 +2536,7 @@ static const struct hda_codec_preset 
> snd_hda_preset_hdmi[] = {
>  { .id = 0x10de0043, .name = "GPU 43 HDMI/DP",.patch = 
> patch_generic_hdmi },
>  { .id = 0x10de0044, .name = "GPU 44 HDMI/DP",.patch = 
> patch_generic_hdmi },
>  { .id = 0x10de0051, .name = "GPU 51 HDMI/DP",.patch = 
> patch_generic_hdmi },
> +{ .id = 0x10de0060, .name = "GPU 60 HDMI/DP",.patch = 
> patch_generic_hdmi },
>  { .id = 0x10de0067, .name = "MCP67 HDMI",.patch = patch_nvhdmi_2ch },
>  { .id = 0x10de8001, .name = "MCP73 HDMI",.patch = patch_nvhdmi_2ch },
>  { .id = 0x11069f80, .name = "VX900 HDMI/DP", .patch = patch_via_hdmi },
> @@ -2588,6 +2589,7 @@ MODULE_ALIAS("snd-hda-codec-id:10de0042");
>  MODULE_ALIAS("snd-hda-codec-id:10de0043");
>  MODULE_ALIAS("snd-hda-codec-id:10de0044");
>  MODULE_ALIAS("snd-hda-codec-id:10de0051");
> +MODULE_ALIAS("snd-hda-codec-id:10de0060");
>  MODULE_ALIAS("snd-hda-codec-id:10de0067");
>  MODULE_ALIAS("snd-hda-codec-id:10de8001");
>  MODULE_ALIAS("snd-hda-codec-id:11069f80");
> -- 
> 1.7.12
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

[Greg KH]

On Tue, Jul 16, 2013 at 03:30:01AM +0100, Ben Hutchings wrote:
> Anything that's being reviewed on the stable list is public.  I know
> this is an old argument, but if you point out a fix you *know* has a
> security impact then you'll help general distribution maintainers and
> users a lot more than you help the black-hats who are quite capable of
> recognising such a fix (if they haven't already spotted and exploited
> the bug).

I'm sorry, but you know I will not do that, so asking about it isn't
going to change this behavior.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

[Greg KH]

On Tue, Jul 16, 2013 at 01:27:42PM +1000, Dave Airlie wrote:
> On Tue, Jul 16, 2013 at 12:41 PM, Ben Hutchings  wrote:
> > On Mon, 2013-07-15 at 22:09 -0400, Steven Rostedt wrote:
> > [...]
> >> > > How important is the stable releases? Are maintainers willing to do a
> >> > > little more work now to make sure their subsystems work fine in older
> >> > > kernels? This isn't the same stable as it was 8 years ago.
> >> >
> >> > And that annoys the hell out of some Linux companies who feel that the
> >> > stable kernels compete with them.  So people working for those companies
> >> > might not get as much help with doing any additional work for stable
> >> > kernel releases (this is not just idle gossip, I've heard it directly
> >> > from management's mouths.)
> >>
> >> Hmm, this is new to me. Really, I thought the whole point of the stable
> >> releases was to help Linux companies.
> > [...]
> >
> > I also heard some managers decided their kernel source packages should
> > have all the patches squashed together to make them harder to cherry-
> > pick... could it have been the same company?
> 
> Greg loves to tell stories about RH management, but really if he can
> find any engineer who works for RH that says he can't work on stable
> due to being told by management, I'd be surprised. Maybe when stable
> first surfaced there was a hope of it being close to RHEL, but at this
> point stable has little to no usefulness from a RHEL point of view,
> and since nearly all the RH employed maintainers all do stable work, I
> can't see why Greg would think this matters.
> 
> In fact Greg how much of stable queue does come from Red Hatters?

I always separate RH managers from engineers in their doings because I
know that one does not feel the same as the other.

My point is, if I start asking developers to do more work for the stable
trees, that has the potential to make people not like the stable trees
more for resource issues, and I don't want to do that at all.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

[David Lang]

On Mon, 15 Jul 2013, Greg KH wrote:


I don't like this at all, just for the simple reason that it will push
the majority of the work of stable kernel development on to the
subsystem maintainers, who have enough work to do as it is.

Stable tree stuff should cause almost _no_ extra burden on the kernel
developers, because it is something that I, and a few other people, have
agreed to do with our time.  It has taken me 8 _years_ to finally get
maintainers to agree to mark stuff for the stable tree, and fine-tune a
development process that makes it easy for us to do this backport work.


It's important to remember that the subsystem maintainers have essentially no 
input on how many stable trees there are or how long they are maintained.


That is entirely up to the people maintaining the stable trees.

Just because some crazy person ;-) decides to maintain 2.4 for many years 
doesn't mean that every subsystem maintainer needs to worry about backporting 
patches from 3.11 all the way back to 2.4. The fact that they are as willing as 
they are to review the results of the backports for problems in amazing.


David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

[Greg KH]

On Tue, Jul 16, 2013 at 09:17:32AM +0400, James Bottomley wrote:
> On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote:
> > On Mon, Jul 15, 2013 at 11:27:56PM +0400, James Bottomley wrote:
> > > Before the "3.10.1-stable review" thread degenerated into a disagreement
> > > about habits of politeness, there were some solid points being made
> > > which, I think, bear consideration and which may now be lost.
> > > 
> > > The problem, as Ji Kosina put is succinctly is that the distributions
> > > are finding stable less useful because it contains to much stuff they'd
> > > classify as not stable material.

And I'm going to be working on that.

But I need, from the distros, specific examples of what they object to.
So far all I've gotten is one security patch (that was needed), and one
patch for sysfs that I backported too far in the version numbers (my
fault.)

Given the huge number of stable patches over the past few years, only
having 2 patches be an issue sounds like things are working well for
people here.

If I don't get pushback, with specifics, from the distros, I will not
know what to change, so if people can provide me that, it will help out
a lot.

> > I don't like this at all, just for the simple reason that it will push
> > the majority of the work of stable kernel development on to the
> > subsystem maintainers, who have enough work to do as it is.
> 
> Well, I think of this as a feature not a bug because it enables scaling,
> but we can certainly debate the topic; it's probably one of the more
> important things that should be discussed.

How does this scale?  It makes the maintainers do more work, which does
not scale at all.

> > Stable tree stuff should cause almost _no_ extra burden on the kernel
> > developers, because it is something that I, and a few other people, have
> > agreed to do with our time.  It has taken me 8 _years_ to finally get
> > maintainers to agree to mark stuff for the stable tree, and fine-tune a
> > development process that makes it easy for us to do this backport work.
> > 
> > I _want_ the exact same commit that is in Linus's tree for the backport
> > because if I have to rely on a maintainer to do the backport and resend
> > it, I _know_ it will usually be a changed patch, and the git commit id
> > will be lost.
> 
> This is fixable with process and tools, surely.

That's crazy, and it implies that there is a problem today with the Cc:
tag.

Is there?  What is the problem that you are seeing that you wish to help
resolve?

I don't think it's the same problem that I am seeing, as adding more
tools and processes sure isn't going to fix that.

> > Have I missed anything else that the distros are objecting to?  The
> > "smaller" distros (i.e. ones without lots of kernel developers) have
> > been giving me nothing but _thanks_ and appreciation with the way that
> > I've been sucking in all of the different fixes.  Do we want to mess
> > with a process that is really working out well for them, and only causes
> > annoyance at times by the larger ones?
> 
> I still think the scaling problem remains plus, if you push back more,
> it's going to increase friction: you aren't necessarily in the best
> position to know what should be a stable fix for a given subsystem, and
> if you push back incorrectly it's going to annoy the maintainer.

Making a subsystem maintainer answer "why is this needed" is really
going to annoy people?  Seriously?

Let's try it out, and see what happens.

I think the real stable issue that _everyone_ keeps ignoring, is my
original complaint, in that people are using the -rc1 merge window to
get fixes in they should have sent to Linus for .0.

I don't see anything you have written so far that will help resolve that
issue, which is not good, as that needs to be taken care of.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] perf: add two new features

[Adrian Hunter]

On 28/06/13 22:22, Adrian Hunter wrote:
> On 28/06/2013 6:27 p.m., Peter Zijlstra wrote:
>> On Fri, Jun 28, 2013 at 04:22:16PM +0300, Adrian Hunter wrote:
>>> Hi
>>>
>>> Please consider these two new perf features:
>>>x86: add ability to calculate TSC from perf sample timestamps
>>>perf: add 'keep tracking' flag to PERF_EVENT_IOC_DISABLE
>>
>> Please explain to us why you'd like to do this..
> 
> I will see what information I can dig up.  The short answer is that I need
> to disable and re-enable a perf event but still be able to map IPs to their
> DSOs and symbols - which means not losing mmap events.

Any other comments?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 7/8] cpufreq: Preserve policy structure across suspend/resume

[Viresh Kumar]

On 15 July 2013 15:35, Srivatsa S. Bhat
 wrote:
> Actually even I was wondering about this while writing the patch and
> I even tested shutdown after multiple suspend/resume cycles, to verify that
> the refcount is messed up. But surprisingly, things worked just fine.
>
> Logically there should've been a refcount mismatch and things should have
> failed, but everything worked fine during my tests. Apart from suspend/resume
> and shutdown tests, I even tried mixing a few regular CPU hotplug operations
> (echo 0/1 to sysfs online files), but nothing stood out.
>
> Sorry, I forgot to document this in the patch. Either the patch is wrong
> or something else is silently fixing this up. Not sure what is the exact
> situation.

To understand it I actually applied your patches to get better view of the code.
(Haven't tested it though).. And found that your code is doing the right thing
and we shouldn't get a mismatch.. This is the sequence of events I can draw:

- __cpu_add_dev() for first cpu. sets the refcount to 'x', where x are
the no. of
cpus in its clock domain.
- _cpu_add_dev() for other cpus: doesn't change anything in refcount

- Suspend:
 - cpu_remove_dev() for all cpus, due to frozen flag we don't touch the value
of count
- Resume:
 - cpu_add_dev() for all cpus, due to frozen flag we don't touch the
value of count.

And so things work as expected. That's why your code isn't breaking anything I
believe.

But can no. of cpus change inbetween suspend/resume? Then count would be
tricky as we are using the same policy structure.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: splice vs execve lockdep trace.

[Al Viro]

On Tue, Jul 16, 2013 at 04:03:51PM +1000, Dave Chinner wrote:

> I posted patches to fix this i_mutex/i_iolock inversion a couple of
> years ago (july 2011):
> 
> https://lkml.org/lkml/2011/7/18/4
> 
> And V2 was posted here and reviewed (aug 2011):
> 
> http://xfs.9218.n7.nabble.com/PATCH-0-2-splice-i-mutex-vs-splice-write-deadlock-V2-tt4072.html#none

Unless I'm misreading the patch, you end up doing file_remove_suid()
without holding i_mutex at all...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 00/19] 3.10.1-stable review

[Willy Tarreau]

Hi Neil,

On Tue, Jul 16, 2013 at 08:40:36AM +1000, NeilBrown wrote:
> On Mon, 15 Jul 2013 21:17:27 +0200 Willy Tarreau  wrote:
> 
> > Communication works two ways.
> 
> I understand that to mean (at least) that for communication, every message
> must be both sent and received.  So when constructing a message, it is
> important to think about how others will understand it.

Yes, and I'd say that "others" here is "most of the readers". I've been
using that in some large companies, sometimes people do wrong things and
defend themselves of stupid choices by putting tens of people in copy to
try to cover their ass.

This is where I please myself. I only assemble nice words that everyone
understands to build sentences that several readers will interprete with
a varying degree of aggressivity. The aggressivity is at its top for the
target, but non-existent for the most external readers. You end up with
a person justifying him/herself in public about something apparently not
existing, till the point where someone high asks "what are you talking
about, care to elaborate?". You get impressive results this way, wrong
projects being aborted, budgets to fix others. Not a single bad word,
yet it is an extermely unpleasant experience for the target who feels
naked in public and hates me. Quite frankly these persons would prefer
a single hard e-mail from Linus than a week long of chess game like this.
So yes, everyone's understanding is important.

> On a public email list there are an awful lot of "others", and it is very
> likely that any possible misunderstanding will be experienced by someone.
> I think it best to minimise opportunities for misunderstanding.

Yes exactly, especially for non-native readers who don't always
understand some cultural jokes. There were a number of non-important
jokes I didn't catch in this thread and that are not important. However
generally when Linus gives someone his "appreciation" for a given work,
there is very little room for misinterpretation, which is fine. He once
severely scolded me on the sec list for insisting on proposing a fix for
an issue I misunderstood. I had all the colorful details to understand
the issue and to realize that I was lacking some skills in the specific
area subject of the issue.

> > Sure it can be hard for newcomers but I don't remember having read him
> > scold a newcomer. 
> 
> I think that is not relevant.  He is scolding people senior developers in
> front of newcomers.  That is not likely to encourage people to want to become
> senior developers.

I'm not that sure, because instead newcomers think "this guy is a bastard, I
don't want to work with him, I'll work with maintainers instead". And that's
what is expected. They start by focusing on a given subsystem, and as years
pass, they realize that the guy with the big mouth is not that naughty,
especially when he helps them design or fix their work.

> Anecdote:  My son (in highschool) is doing a psych assignment where he is
> asking people to complete a survey which, among other things, asks about
> people fear/anxiety response to various situations (it is a fairly standard
> instrument I think[1]).  Last few times he checked, the situation with the
> highest average score was "One person bullying another".  Really, it isn't
> nice to watch.

That's an interesting study which very likely matches reality, but here
it's a bit different. The group of people is not just two guys having
words together, imagine a room with hundreds or thousands of people and
two in the middle fighting. They'll just get ignored by newcomers who
will preferably sit down close to people who discuss calmly.

I have another anecdote. A few years ago, one very discrete and respectful
developer used to help me with backports of some security fixes. At some
point I asked him "wouldn't you prefer to be on the sec list, it would be
easier", and he replied "Linus will never accept, he once scolded me in
public", and I replied "quite the opposite then, that's good for you".
And when I asked, Linus said "yes of course I want him on the list, he
can certainly help us". So as you see, if some people are impressed first,
they can still be brought in front of the one they fear and realize that
they were thinking wrong.

It can seem counter-producting first (as Sarah thinks) but I think that
the competent people find their way in this simply because they're backed
up by other ones. That's how I think we get that number of skilled people
at the top of each subsystem.

And last, from some feedback I got, I would suspect that some top developers
prefer one e-mail from Linus once in a while to countless e-mails from end
users who repeatedly criticize their work when something does not work like
they expect for whatever reasons (including PEBKAC).

Best regards,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/maj

Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

[James Bottomley]

On Mon, 2013-07-15 at 17:06 -0700, Greg KH wrote:
> On Mon, Jul 15, 2013 at 06:01:39PM -0400, Steven Rostedt wrote:
> > On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote:
> > 
> > > I don't like this at all, just for the simple reason that it will push
> > > the majority of the work of stable kernel development on to the
> > > subsystem maintainers, who have enough work to do as it is.
> > > 
> > > Stable tree stuff should cause almost _no_ extra burden on the kernel
> > > developers, because it is something that I, and a few other people, have
> > > agreed to do with our time.  It has taken me 8 _years_ to finally get
> > > maintainers to agree to mark stuff for the stable tree, and fine-tune a
> > > development process that makes it easy for us to do this backport work.
> > 
> > Although, since those 8 years, the stable tree has proven its
> > importance.
> > 
> > Is a extra "ack" also too much to ask?
> 
> Maintainers are our most limited resource, I'm getting their "ack" when
> they themselves tag the patch to be backported with the Cc: line.
> 
> I then cc: them when the patch goes into the patch queue.
> 
> I then cc: them again when the patch is in the -rc1 phase.
> 
> How many times do I need to do this to give people a chance to say
> "nak"?

Just to pick up on this, the problem from my perspective is that this
cc: goes into my personal inbox.  From a list perspective this just
doesn't work.  The entirety of my workflow is set up to operate from the
mailing lists.  My inbox is for my day job.  It gets about 100 emails or
more a day and anything that goes in there and doesn't get looked at for
a day gets lost.  I sometimes feel guilty about seeing stable reviews
whiz by, but not necessarily guilty enough to go back and try to find
them.  I have thought of using filtering to manually place these into a
deferred mailbox for later use.  However, the problem is that my work
inbox is exchange, and the only tags I could filter on seem to be in the
body (exchange does body filtering about as elegantly as a penguin
flies).

That's where the suggestion to drop cc: stable@ came from.  I realise
the workflow just isn't working for me.

I say we have the discussion at KS then I'll investigate a different
workflow for SCSI.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: splice vs execve lockdep trace.

[Dave Chinner]

On Mon, Jul 15, 2013 at 08:25:14PM -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 7:38 PM, Dave Jones  wrote:
> >
> >   The recent trinity changes shouldn't have really made
> > any notable difference here.
> 
> Hmm. I'm not aware pf anything that has changed in this area since
> 3.10 - neither in execve, xfs or in splice. Not even since 3.9.

It's been there for years.

> The "pipe -> cred_guard_mutex" lock chain is pretty direct, and can be
> clearly attributed to splicing into /proc. Now, whether that is a
> *good* idea or not is clearly debatable, and I do think that maybe we
> should just not splice to/from proc files, but that doesn't seem to be
> new, and I don't think it's necessarily *broken* per se, it's just
> that splicing into /proc seems somewhat unnecessary, and various proc
> files do end up taking locks that can be "interesting".

But this is a new way of triggering the inversion, however

> At the other end of the spectrum, the "cred_guard_mutex -> FS locks"
> thing from execve() is also pretty clear, and probably not fixable or
> necessarily something we'd even want to fix.
> 
> But the "FS locks -> pipe" part is a bit questionable. Honestly, I'd
> be much happier if XFS used generic_file_splice_read/write().
>
> And looking more at that, I'm actually starting to think this is an
> XFS locking problem. XFS really should not call back to splice while
> holding the inode lock.
> 
> But that XFS code doesn't seem new either. Is XFS a new thing for you
> to test with?

I posted patches to fix this i_mutex/i_iolock inversion a couple of
years ago (july 2011):

https://lkml.org/lkml/2011/7/18/4

And V2 was posted here and reviewed (aug 2011):

http://xfs.9218.n7.nabble.com/PATCH-0-2-splice-i-mutex-vs-splice-write-deadlock-V2-tt4072.html#none

It didn't get picked up by with a VFS tree, so sat moldering until
somebody else reported it (Nov 2012) and it reposted it again, only
to have it ignored again:

http://oss.sgi.com/archives/xfs/2012-11/msg00671.html

And I recently discussed it again with Al w.r.t. filesystem freeze
problems he was looking at, and I was waiting for that to settle
down before I posted the fixes again

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC V10 15/18] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

[Gleb Natapov]

On Tue, Jul 16, 2013 at 09:07:53AM +0530, Raghavendra K T wrote:
> On 07/15/2013 04:06 PM, Gleb Natapov wrote:
> >On Mon, Jul 15, 2013 at 03:20:06PM +0530, Raghavendra K T wrote:
> >>On 07/14/2013 06:42 PM, Gleb Natapov wrote:
> >>>On Mon, Jun 24, 2013 at 06:13:42PM +0530, Raghavendra K T wrote:
> kvm : Paravirtual ticketlocks support for linux guests running on KVM 
> hypervisor
> 
> From: Srivatsa Vaddagiri 
> 
> >>trimming
> >>[...]
> +
> +static void kvm_lock_spinning(struct arch_spinlock *lock, __ticket_t 
> want)
> +{
> + struct kvm_lock_waiting *w;
> + int cpu;
> + u64 start;
> + unsigned long flags;
> +
> + w = &__get_cpu_var(lock_waiting);
> + cpu = smp_processor_id();
> + start = spin_time_start();
> +
> + /*
> +  * Make sure an interrupt handler can't upset things in a
> +  * partially setup state.
> +  */
> + local_irq_save(flags);
> +
> + /*
> +  * The ordering protocol on this is that the "lock" pointer
> +  * may only be set non-NULL if the "want" ticket is correct.
> +  * If we're updating "want", we must first clear "lock".
> +  */
> + w->lock = NULL;
> + smp_wmb();
> + w->want = want;
> + smp_wmb();
> + w->lock = lock;
> +
> + add_stats(TAKEN_SLOW, 1);
> +
> + /*
> +  * This uses set_bit, which is atomic but we should not rely on its
> +  * reordering gurantees. So barrier is needed after this call.
> +  */
> + cpumask_set_cpu(cpu, &waiting_cpus);
> +
> + barrier();
> +
> + /*
> +  * Mark entry to slowpath before doing the pickup test to make
> +  * sure we don't deadlock with an unlocker.
> +  */
> + __ticket_enter_slowpath(lock);
> +
> + /*
> +  * check again make sure it didn't become free while
> +  * we weren't looking.
> +  */
> + if (ACCESS_ONCE(lock->tickets.head) == want) {
> + add_stats(TAKEN_SLOW_PICKUP, 1);
> + goto out;
> + }
> +
> + /* Allow interrupts while blocked */
> + local_irq_restore(flags);
> +
> >>>So what happens if an interrupt comes here and an interrupt handler
> >>>takes another spinlock that goes into the slow path? As far as I see
> >>>lock_waiting will become overwritten and cpu will be cleared from
> >>>waiting_cpus bitmap by nested kvm_lock_spinning(), so when halt is
> >>>called here after returning from the interrupt handler nobody is going
> >>>to wake this lock holder. Next random interrupt will "fix" it, but it
> >>>may be several milliseconds away, or never. We should probably check
> >>>if interrupt were enabled and call native_safe_halt() here.
> >>>
> >>
> >>Okay you mean something like below should be done.
> >>if irq_enabled()
> >>   native_safe_halt()
> >>else
> >>   halt()
> >>
> >>It is been a complex stuff for analysis for me.
> >>
> >>So in our discussion stack would looking like this.
> >>
> >>spinlock()
> >>   kvm_lock_spinning()
> >>   <-- interrupt here
> >>   halt()
> >>
> >>
> >> From the halt if we trace
> >>
> >It is to early to trace the halt since it was not executed yet. Guest
> >stack trace will look something like this:
> >
> >spinlock(a)
> >   kvm_lock_spinning(a)
> >lock_waiting = a
> >set bit in waiting_cpus
> > <-- interrupt here
> > spinlock(b)
> >   kvm_lock_spinning(b)
> > lock_waiting = b
> > set bit in waiting_cpus
> > halt()
> > unset bit in waiting_cpus
> > lock_waiting = NULL
> >  --> ret from interrupt
> >halt()
> >
> >Now at the time of the last halt above lock_waiting == NULL and
> >waiting_cpus is empty and not interrupt it pending, so who will unhalt
> >the waiter?
> >
> 
> Yes. if an interrupt occurs between
> local_irq_restore() and halt(), this is possible. and since this is
> rarest of rare (possiility of irq entering slowpath and then no
> random irq to do spurious wakeup), we had never hit this problem in
> the past.
I do not think it is very rare to get interrupt between
local_irq_restore() and halt() under load since any interrupt that
occurs between local_irq_save() and local_irq_restore() will be delivered
immediately after local_irq_restore(). Of course the chance of no other
random interrupt waking lock waiter is very low, but waiter can sleep
for much longer then needed and this will be noticeable in performance.

BTW can NMI handler take spinlocks? If it can what happens if NMI is
delivered in a section protected by local_irq_save()/local_irq_restore()?

> 
> So I am,
> 1. trying to artificially reproduce this.
> 
> 2. I replaced the halt with below code,
>if (arch_irqs_disabled())
> halt();
> 
> and ran benchmarks.
> But this results in degradation because, it means we again go back
> and spin in irq enabled c

linux-next: Tree for Jul 16

[Stephen Rothwell]

Hi all,

Changes since 20130712:

New tree: ptr-ret

Removed tree: cpuidle (at maintainers request)

The drm-intel tree gained a conflict against the drm-intel-fixes tree.

The sound-asoc tree gained a build failure so I used the version from
next-20130715.

The akpm tree gained conflicts against the ext4 tree.

The cpuinit tree gained a conflict against the hwmon-staging tree and
lost a patch that turned up elsewhere.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 230 trees (counting Linus' and 33 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (47188d3 Merge tag 'ext4_for_linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4)
Merging fixes/master (8177a9d lseek(fd, n, SEEK_END) does *not* go to eof - n)
Merging kbuild-current/rc-fixes (42a0940 Merge branch 'yem-kconfig-rc-fixes' of 
git://gitorious.org/linux-kconfig/linux-kconfig into kbuild/rc-fixes)
Merging arc-current/for-curr (6d128e1 Revert "Makefile: Fix install error with 
make -j option")
Merging arm-current/fixes (cbbe6f8 ARM: 7778/1: smp_twd: twd_update_frequency 
need be run on all online CPUs)
Merging m68k-current/for-linus (ad81f05 Linux 3.11-rc1)
Merging metag-fixes/fixes (d903bca metag: checksum.h: fix carry in 
csum_tcpudp_nofold)
Merging powerpc-merge/merge (ea461ab powerpc/eeh: Fix fetching bus for 
single-dev-PE)
Merging sparc/master (6d128e1 Revert "Makefile: Fix install error with make -j 
option")
Merging net/master (63345b4 Merge branch 'for_linus' of 
git://cavan.codon.org.uk/platform-drivers-x86)
Merging ipsec/master (01cb71d net_sched: restore "overhead xxx" handling)
Merging sound-current/for-linus (86f0b5b staging: line6: Fix unlocked 
snd_pcm_stop() call)
Merging pci-current/for-linus (65694c5 x86/PCI: Map PCI setup data with 
ioremap() so it can be in highmem)
Merging wireless/master (53e5946 ath9k_htc: fix data race between 
request_firmware_nowait() callback and suspend())
Merging driver-core.current/driver-core-linus (ad81f05 Linux 3.11-rc1)
Merging tty.current/tty-linus (ad81f05 Linux 3.11-rc1)
Merging usb.current/usb-linus (ad81f05 Linux 3.11-rc1)
Merging staging.current/staging-linus (ad81f05 Linux 3.11-rc1)
Merging char-misc.current/char-misc-linus (ad81f05 Linux 3.11-rc1)
Merging input-current/for-linus (88ce3c3 Merge branch 'next' into for-linus)
Merging md-current/for-linus (1376512 md/raid10: fix bug which causes all 
RAID10 reshapes to move no data.)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (9c23b7d crypto: caam - Fixed the memory out of 
bound overwrite issue)
Merging ide/master (6d128e1 Revert "Makefile: Fix install error with make -j 
option")
Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (d94ea3f irqchip: Return -EPERM for 
reserved IRQs)
Merging devicetree-current/devicetree/merge (706b78f dtc: ensure #line 
directives don't consume d

Re: Linux 3.9.10

[ianp]

Greg KH  linuxfoundation.org> writes:

> Please move to the 3.10-stable series at this point in time.  If that
> isn't working for you, please let us know NOW!
> 

Hi Greg,

Unfortunate hardware owners of Intel Atom's Cedar Trail platforms (like Atom 
N2600/N2800) like myself have been relying on the excellent work of thomas001 
on the cedarview-drm kernel driver, https://github.com/thomas001/cedarview-
drm, to enable the use of the cedarview_gfx module and its proprietary, 
accelerated userspace xorg driver pvr, with later kernel releases.

Unfortunately, the 3.10 kernel release brought about some major changes in  
include/linux/proc_fs.h that prevent the successful compilation of the 
cedarview_gfx kernel module, as reported here 
https://github.com/thomas001/cedarview-drm/issues/1 .

Can you suggest how one proceeds from here? Intel cannot be relied upon to 
update the driver package, even at least the open-source cedarview-drm source 
package, for this hardware.

-ianp

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Commence Industrial Crm Profiled By simply Manufacturing Correspondent Thomas R. Cutler

[lkml]

Reported by Thomas UR. Cutler, Manufacturing Journalist in the recent issue of 
Alternative Focus, "The foundation of any quality revenue organization starts 
with all the implementation in addition to management of an sales 
process.Thomas sabo rea These is also the steps required by the sales 
representative to move the prospect from the initial introduction stage to the 
closing step.

Few industrial CRM models provide manufacturers which has a structured 
established sales method or technique for considering and handling each stage 
of the sales bike. A pro-active way of managing the sales procedure allows this 
sales manager to monitor and supply guidance through cycle, in addition to help 
gross sales representatives consentrate on the most effective opportunities. " 
This article can be read in its entirety  thomas sabo sverige.

Caretsky, noted within the feature posting that "CEOs worth mentioning 
companies usually share exactly how their innovative enterprise resource 
planning (ERP) program provides them whatever they want, but are not able to 
recognize that ERP programs provide information following a sale, not ahead of 
or in the sales process. Thomas sabo smycken ERP programs provide absolutely no 
value with regard to improving this efficiency of how to sell in addition to 
service buyers. This will be one cause that outlook reports tend to be always 
incorrect. "

Commence presents industrial organizations complete "Freedom Connected with 
Choice" purchase the solutions and program that ideal meets this company 
requirements regarding manufacturers in addition to distributors. The 
comprehensive CRM Alternative application suite can be purchased for work with 
on game play or on- demand as being a hosted service. Thomas sabo berlocker 
Industrial leaders often construct departmental CRM solutions while using award 
successful Commence Commercial CRM Platform. These alternatives are why so many 
industrial organizations choose Commence as the solution pertaining to managing 
shopper relationships. Almost all Commence Alternative solutions support mobile 
and also wireless connectivity in addition to integration for you to 
back-office accounting in addition to ERP models.

Datacraft Alternatives specializes in providing their particular clients 
considering the tools they need to rapidly replace outdated guide systems 
together with technology which speeds method flow and improves precision. 
Thomas Sabo Halsband Datacraft's highest regarded product, Signum continues to 
be developed throughout the Kanban notion of replenishment, and provides a 
pivotal tool pertaining to manufacturing organizations to watch process stream, 
lower administrative transaction expenditures, and improve decision-making 
power.

---
posted at http://www.serverphorums.com
http://www.serverphorums.com/read.php?12,743669,743669#msg-743669
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] usb: musb: fix USB enumeration issue in OMAP3 platform

[Kishon Vijay Abraham I]

Tony,

On Monday 08 July 2013 04:44 PM, Kishon Vijay Abraham I wrote:
> This series fixes the USB enumeration issue caused because of the controller
> not able to get a reference to the PHY because of incorrect binding in the
> board file.
> 
> In the case of non-dt boot, the platform specific initialization file
> (board file) will do usb_bind_phy that binds the usb controller with the
> PHY using device names. After the device names are created using 
> PLATFORM_DEVID_AUTO, our original method of binding by device names doesn't
> work reliably (since the device name changes). Hence the usb controller
> is made to use labels for getting the PHY.
> 
> Here the PHY name is added in the plat data of USB controller device which
> should be used by the controller driver to get the PHY.
> Two new APIs usb_get_phy_by_name and devm_usb_get_phy_by_name are added to
> be used by the controller to get the PHY by name.

You haven't picked this patch series?

-Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Selling Creative With Nike

[lkml]

Time that we have the ad and even slogan suitable dull detect, just 
"advertised", so whereby consumers can not be tempted, in all probability to 
crash. At length of time, advertising creative instead of a typical literary 
plus artistic growth, it might only screen advertising themes or templates or 
themes, advertising procedures by marketplace environment and also the 
constraints, the pursuit is a most economical nike schuhe bestellen in 
improvement to concise approach, promote the store's corporate vendor and item 
personality, to take full advantage of communication in addition to affect 
shoppers.

This image isn't just beautiful, appeals into the imagination, in addition to 
meaningful, especially to view them association up additional. Image facts 
behind the exact group marked the fresh face of Nike: Nike brand has already 
been not only for youth but additionally for seniors, not just for men but 
additionally for young ladies, not simply for the the planet's leading 
champions with the unknown road movement. Nike passed another kind of image 
connected with any voice. nike schuhe deutschland did definitely not directly 
claim "revolution" although announced every "revolution", and these can be a 
popular but not limited to the service for a few brands.

In the new field hockey game, you will discover 40 debut with Nike weather max 
2009 basketball shoes and boots and " booties ", which contains nike air max 
bestellen. The clean game initiated seeing participants obtain basketball shoes 
will be wide and also varied, the ball player doesn't need 80 points or maybe 
more, or catch greater than 22 rebounds to becoming a pair regarding footwear 
trapeze, the important is will depend on your participate in time. Select the 
sneakers following the golfer who could possibly get precise tips, such seeing 
that its meaning, history, and Jordan following the initial evaluation to 
discover the shoes etc.

Nike Jordan following introduced any generation for you to sign should the red 
along with black sneakers or boots, NBA objectives are yet wearing the majority 
the fairly old-fashioned ebony and Nike Air Max sale deutschland. Jordan to 
understand the shoes which could not wear, but still place on the early morning 
after long run. The NBA is not allowed, each carrying around a Jordan Jordan is 
certain to get a great result, Nike Jordan paid out all fines, Nike ambiance 
max 24-7, along with become well-known.

Right now, the Nike Air Max Damen scientific suggestions embodied in the 
creative and also advertising activities of every session. Scientific in 
addition to artistic resourcefulness in advertising may be a contradiction from 
the unity, discussed penetration, together play a role. Make innovative 
scientific a lot more rational, additional artistic sense is therefore 
creative. That wonderful ingenuity, science in addition to art need to be 
perfect unity on the crystal.

---
posted at http://www.serverphorums.com
http://www.serverphorums.com/read.php?12,743667,743667#msg-743667
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Nike Jordan compensated all fines

[lkml]

Should the ad or even slogan in to a dull note, just "advertised", so in which 
consumers cannot be tempted, likely to don't succeed. At the same time frame, 
advertising creative rather than a normal literary and artistic design, it 
might only demonstrate advertising subjects, advertising methods by current 
market environment and the constraints, the pursuit could be the most 
economical  nike schuhe bestellen 90 and concise means, promote your corporate 
manufacturer and merchandise personality, to maximise communication and also 
affect people.

This image is not only beautiful, appeals towards imagination, and also 
meaningful, especially to see them website link up all the more. Image info 
behind the particular group marked the modern face connected with Nike: Nike 
brand is now not only for youth but in addition for older people, not only for 
men but also for adult females, not only for the globe's leading champions with 
the unknown roadway movement. Nike passed some other image on the voice. nike 
schuhe deutschland did possibly not directly say "revolution" yet announced any 
"revolution", which may be a popular although not limited towards the service 
just the summer brands.

Within the new field hockey game, there are actually 40 debut with Nike air max 
2010 basketball footwear, which contains nike air max bestellen. The new game 
how players acquire basketball shoes fluctuate, the player would not need to 
get 80 points or maybe more, or catch in excess of 22 rebounds to obtain a pair 
associated with shoes trapeze, the key is depends on your have fun with time. 
Mouse click on the shoes following your player who will get detailed 
information, which include its importance, history, and Jordan following your 
first evaluation to see the shoes and so on.

Nike Jordan subsequently introduced some sort of generation in order to sign 
should the red along with black " booties ", NBA participants are even now 
wearing a lot of the relatively old-fashioned charcoal and Nike Air Max sale 
deutschland. Jordan to discover the shoes that could not have on, but still 
apply to the day time after tomorrow. The NBA will not be allowed, each 
sporting a Michael Jordan are certain to get a very good result, Nike Jordan 
compensated all fines, Nike air flow max 24-7, who has become renowned.

Today, the Nike Air Max Damen scientific principles embodied within the 
creative and advertising activities of every session. Scientific as well as 
artistic creativity in advertising may be a contradiction on the unity, mutual 
penetration, together are likely involved. Make inspiring scientific plus much 
more rational, much more artistic feeling is consequently creative. The 
excellent creativity, science as well as art must be perfect unity on the 
crystal.

---
posted at http://www.serverphorums.com
http://www.serverphorums.com/read.php?12,743668,743668#msg-743668
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Question:Bsearch replace the search_extable implementations

[anish singh]

On Tue, Jul 16, 2013 at 10:29 AM, Rusty Russell  wrote:
> anish singh  writes:
>> Hello Rusty,
>>
>> Right now I see so many places in the kernel
>> where we open code binary search implementations
>> such as search_extable implementations.
>>
>> http://lxr.free-electrons.com/ident?a=powerpc;i=search_extable
>>
>> Would it be ok to replace this with bsearch lib code?
>>
>> I am not trying to fix any problem nor I see
>> any problem in current implementations but
>> if we can replace the large amount of code
>> would it not be a good reason to send a patch
>> for this?
>
> It should be fine, yes.
great.Will be sending patch for this soon.
>
> Thanks!
> Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 7/9] mm, hugetlb: add VM_NORESERVE check in vma_has_reserves()

[Aneesh Kumar K.V]

Joonsoo Kim  writes:

> On Mon, Jul 15, 2013 at 08:41:12PM +0530, Aneesh Kumar K.V wrote:
>> Joonsoo Kim  writes:
>> 
>> > If we map the region with MAP_NORESERVE and MAP_SHARED,
>> > we can skip to check reserve counting and eventually we cannot be ensured
>> > to allocate a huge page in fault time.
>> > With following example code, you can easily find this situation.
>> >
>> > Assume 2MB, nr_hugepages = 100
>> >
>> > fd = hugetlbfs_unlinked_fd();
>> > if (fd < 0)
>> > return 1;
>> >
>> > size = 200 * MB;
>> > flag = MAP_SHARED;
>> > p = mmap(NULL, size, PROT_READ|PROT_WRITE, flag, fd, 0);
>> > if (p == MAP_FAILED) {
>> > fprintf(stderr, "mmap() failed: %s\n", strerror(errno));
>> > return -1;
>> > }
>> >
>> > size = 2 * MB;
>> > flag = MAP_ANONYMOUS | MAP_SHARED | MAP_HUGETLB | MAP_NORESERVE;
>> > p = mmap(NULL, size, PROT_READ|PROT_WRITE, flag, -1, 0);
>> > if (p == MAP_FAILED) {
>> > fprintf(stderr, "mmap() failed: %s\n", strerror(errno));
>> > }
>> > p[0] = '0';
>> > sleep(10);
>> >
>> > During executing sleep(10), run 'cat /proc/meminfo' on another process.
>> > You'll find a mentioned problem.
>> >
>> > Solution is simple. We should check VM_NORESERVE in vma_has_reserves().
>> > This prevent to use a pre-allocated huge page if free count is under
>> > the reserve count.
>> 
>> You have a problem with this patch, which i guess you are fixing in
>> patch 9. Consider two process
>> 
>> a) MAP_SHARED  on fd
>> b) MAP_SHARED | MAP_NORESERVE on fd
>> 
>> We should allow the (b) to access the page even if VM_NORESERVE is set
>> and we are out of reserve space .
>
> I can't get your point.
> Please elaborate more on this.


One process mmap with MAP_SHARED and another one with MAP_SHARED | MAP_NORESERVE
Now the first process will result in reserving the pages from the hugtlb
pool. Now if the second process try to dequeue huge page and we don't
have free space we will fail because

vma_has_reservers will now return zero because VM_NORESERVE is set 
and we can have (h->free_huge_pages - h->resv_huge_pages) == 0;

The below hunk in your patch 9 handles that

 +  if (vma->vm_flags & VM_NORESERVE) {
 +  /*
 +   * This address is already reserved by other process(chg == 0),
 +   * so, we should decreament reserved count. Without
 +   * decreamenting, reserve count is remained after releasing
 +   * inode, because this allocated page will go into page cache
 +   * and is regarded as coming from reserved pool in releasing
 +   * step. Currently, we don't have any other solution to deal
 +   * with this situation properly, so add work-around here.
 +   */
 +  if (vma->vm_flags & VM_MAYSHARE && chg == 0)
 +  return 1;
 +  else
 +  return 0;
 +  }

so may be both of these should be folded ?

-aneesh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net 1/2] macvtap: fix the missing ret value of TUNSETQUEUE

[Jason Wang]

Commit 441ac0fcaadc76ad09771812382345001dd2b813
(macvtap: Convert to using rtnl lock) forget to return what
macvtap_ioctl_set_queue() returns to its caller. This may break multiqueue API
by always falling through to TUNGETFEATURES.

Cc: Vlad Yasevich 
Signed-off-by: Jason Wang 
---
 drivers/net/macvtap.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index f2c4a3b..8270b5e 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -1103,6 +1103,7 @@ static long macvtap_ioctl(struct file *file, unsigned int 
cmd,
rtnl_lock();
ret = macvtap_ioctl_set_queue(file, u);
rtnl_unlock();
+   return ret;
 
case TUNGETFEATURES:
if (put_user(IFF_TAP | IFF_NO_PI | IFF_VNET_HDR |
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net 2/2] macvtap: do not assume 802.1Q when send vlan packets

[Jason Wang]

The hard-coded 8021.q proto will break 802.1ad traffic. So switch to use
vlan->proto.

Cc: Basil Gor 
Signed-off-by: Jason Wang 
---
 drivers/net/macvtap.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 8270b5e..638b64c 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -869,7 +869,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
__be16 h_vlan_proto;
__be16 h_vlan_TCI;
} veth;
-   veth.h_vlan_proto = htons(ETH_P_8021Q);
+   veth.h_vlan_proto = skb->vlan_proto;
veth.h_vlan_TCI = htons(vlan_tx_tag_get(skb));
 
vlan_offset = offsetof(struct vlan_ethhdr, h_vlan_proto);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 3.10.[01] modprobe snd-... hangs

[Rusty Russell]

Philipp Matthias Hahn  writes:
> Hello,
>
> My x86_64 systems has some trouble loading some ALSA snd-* modules since
> the upgrade to 3.10.[01]: Several automatic modprobe calls hang, but
> loading snd-intel-hda and snd-audio-usb by hand still works.

Not a known problem to me, at least.  Perhaps it's a dep loop somehow.

> ...
>  1071 ?S  0:00 sh -c /sbin/modprobe --ignore-install snd && { 
> /sbin/modprobe --quiet snd
>  1080 ?D  0:00  \_ /sbin/modprobe --quiet snd-seq

This was first, and it's waiting.  Which means it must be doing
something weird, because snd_seq_oss is loading now:

> snd_seq_oss 33717 1 - Loading 0xa041b000

Perhaps in the tangle of modprobe install commands somewhere this gets
invoked?

> # ps axf
>   460 ?S  0:00  \_ [kworker/u8:3]
>  1087 ?S  0:00  |   \_ [kworker/u8:3]
>  1092 ?S  0:00  |   \_ /sbin/modprobe -q -- snd-seq-client-14

On my systems, that's snd-seq-dummy, which depends on snd_seq.  Which,
in fact, is already loaded.

Lucas, any clues?

Full quote below.

Cheers,
Rusty.

Philipp Matthias Hahn  writes:
> Hello,
>
> My x86_64 systems has some trouble loading some ALSA snd-* modules since
> the upgrade to 3.10.[01]: Several automatic modprobe calls hang, but
> loading snd-intel-hda and snd-audio-usb by hand still works.
>
> # ps axf
>   460 ?S  0:00  \_ [kworker/u8:3]
>  1087 ?S  0:00  |   \_ [kworker/u8:3]
>  1092 ?S  0:00  |   \_ /sbin/modprobe -q -- snd-seq-client-14
> ...
>  1071 ?S  0:00 sh -c /sbin/modprobe --ignore-install snd && { 
> /sbin/modprobe --quiet snd
>  1080 ?D  0:00  \_ /sbin/modprobe --quiet snd-seq
>  1115 ?S  0:00 sh -c /sbin/modprobe --ignore-install snd-rawmidi 
> && { /sbin/modprobe --q
>  1154 ?S  0:00  \_ /sbin/modprobe --quiet snd-seq-midi
>  1119 ?S  0:00 sh -c /sbin/modprobe --ignore-install snd-rawmidi 
> && { /sbin/modprobe --q
>  1148 ?S  0:00  \_ /sbin/modprobe --quiet snd-seq-midi
>
> In /var/log/daemon.log I find the following messages:
> Jul 15 19:58:44 scout udevd[912]: timeout: killing '/sbin/modprobe -b 
> usb:vFC08p0101d0250dc00dsc00dp00ic01isc01ip00in00' [1044]
> Jul 15 19:58:56 scout udevd[912]: '/sbin/modprobe -b 
> usb:vFC08p0101d0250dc00dsc00dp00ic01isc01ip00in00' [1044] terminated by 
> signal 9 (Killed)
> Jul 15 19:58:56 scout udevd[919]: timeout: killing '/sbin/modprobe -b 
> pci:v10DEd026Csv1462sd7350bc04sc03i00' [1051]
> Jul 15 19:58:56 scout udevd[914]: timeout: killing '/sbin/modprobe -b 
> usb:vFC08p0101d0250dc00dsc00dp00ic01isc03ip00in01' [1045]
> Jul 15 19:58:56 scout udevd[919]: '/sbin/modprobe -b 
> pci:v10DEd026Csv1462sd7350bc04sc03i00' [1051] terminated by 
> signal 9 (Killed)
> Jul 15 19:58:56 scout udevd[914]: '/sbin/modprobe -b 
> usb:vFC08p0101d0250dc00dsc00dp00ic01isc03ip00in01' [1045] terminated by 
> signal 9 (Killed)
>
>
> This is a Debian sid system
> # modprobe -V
> kmod version 9
>
> # echo t >/proc/sysrq-trigger
> produces too much output to include the modprobe processes. I already
> stopped most processes, but that is not enough.
>
>
> # cat /proc/1092/syscall
> 175 0x7effcad92000 0xafe8 0x7effca9c2f88 0x7effca6ea3aa 0x0 0x0 
> 0x7fff3e3de648 0x7effca6eef8a
>
> # cat /proc/1080/syscall
> 175 0x7fe01b25e000 0xafe8 0x7fe01ae8ef88 0x7fe01abb63aa 0x3 0x0 
> 0x7fffba8cc748 0x7fe01abbaf8a
>
> # cat /proc/1154/syscall
> 175 0x7fc157a7b000 0xafe8 0x7fc1576abf88 0x7fc1573d33aa 0x3 0x0 
> 0x7fff05809e58 0x7fc1573d7f8a
>
> # cat /proc/1148/syscall
> 175 0x7fc7159d5000 0xafe8 0x7fc715605f88 0x7fc71532d3aa 0x3 0x0 
> 0x7fff47a1f3c8 0x7fc715331f8a
>
> Is this a know bug or has someone seen similar problems?
>
> # cat /proc/modules
> ip6table_filter 1575 0 - Live 0xa0893000
> ip6_tables 13784 1 ip6table_filter, Live 0xa088b000
> ebtable_nat 1887 0 - Live 0xa0887000
> ebtables 19917 1 ebtable_nat, Live 0xa087e000
> snd_usb_audio 124196 0 - Live 0xa0851000
> snd_usbmidi_lib 16982 1 snd_usb_audio, Live 0xa0848000
> rfcomm 28731 10 - Live 0xa083a000
> bnep 9786 2 - Live 0xa0833000
> snd_hda_codec_realtek 37669 1 - Live 0xa0823000
> snd_hda_intel 31432 0 - Live 0xa0814000
> snd_hda_codec 140669 2 snd_hda_codec_realtek,snd_hda_intel, Live 
> 0xa07e2000
> snd_hwdep 5627 2 snd_usb_audio,snd_hda_codec, Live 0xa07dd000
> iptable_filter 1618 1 - Live 0xa07d9000
> xt_owner 1326 1 - Live 0xa07d5000
> ip_tables 13390 1 iptable_filter, Live 0xa07cd000
> x_tables 18433 6 
> ip6table_filter,ip6_tables,ebtables,iptable_filter,xt_owner,ip_tables, Live 
> 0xa07c3000
> cpufreq_conservative 7015 0 - Live 0xa07bd000
> cpufreq_ondemand 8945 0 - Live 0xa07b6000
> cpufreq_powersave 1010 0 - Live 0xa07b2000
> cpufreq_userspace 2136 0 - Live 0xa07ae000
> binfmt_misc 6479

Re: Question:Bsearch replace the search_extable implementations

[Rusty Russell]

anish singh  writes:
> Hello Rusty,
>
> Right now I see so many places in the kernel
> where we open code binary search implementations
> such as search_extable implementations.
>
> http://lxr.free-electrons.com/ident?a=powerpc;i=search_extable
>
> Would it be ok to replace this with bsearch lib code?
>
> I am not trying to fix any problem nor I see
> any problem in current implementations but
> if we can replace the large amount of code
> would it not be a good reason to send a patch
> for this?

It should be fine, yes.

Thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 00/19] 3.10.1-stable review

[Rusty Russell]

Linus Torvalds  writes:
> On Mon, Jul 15, 2013 at 12:17 PM, Willy Tarreau  wrote:
>>
>> BTW, I was amazed that you managed to get him have a much softer tone inr
>> his last e-mail, you probably found a weakness here in his management
>> process :-)
>
> Hey, I _like_ arguing, and "cursing" and "arguing" are actually not at
> all the same thing.
>
> And I really don't tend to curse unless people are doing something
> stupid and annoying. If people have concerns and questions that I feel
> are valid, I'm more than happy to talk about it.
>
> I curse when there isn't any argument. The cursing happens for the
> "you're so f*cking wrong that it's not even worth trying to make
> logical arguments about it, because you have no possible excuse" case.
>
> .. and sometimes people surprise me and come back with a valid excuse
> after all. "My whole family died in a tragic freak accident and my
> pony got cancer, and I was distracted".
>
> And then I might even tell them I'm sorry.
>
> No. Not really.

You have to be harsh with code: People mistake politeness for
uncertainty.  Whenever I said 'I prefer if you XYZ' some proportion
didn't realize I meant 'Don't argue unless you have new facts: do XYZ or
go away.'  This wastes my time, so I started being explicit.

But be gentle with people.  You've already called their baby ugly.

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm/hugetlb: per-vma instantiation mutexes

[Joonsoo Kim]

On Mon, Jul 15, 2013 at 09:51:21PM -0400, Rik van Riel wrote:
> On 07/15/2013 03:24 AM, David Gibson wrote:
> >On Sun, Jul 14, 2013 at 08:16:44PM -0700, Davidlohr Bueso wrote:
> 
> >>>Reading the existing comment, this change looks very suspicious to me.
> >>>A per-vma mutex is just not going to provide the necessary exclusion, is
> >>>it?  (But I recall next to nothing about these regions and
> >>>reservations.)
> >
> >A per-VMA lock is definitely wrong.  I think it handles one form of
> >the race, between threads sharing a VM on a MAP_PRIVATE mapping.
> >However another form of the race can and does occur between different
> >MAP_SHARED VMAs in the same or different processes.  I think there may
> >be edge cases involving mremap() and MAP_PRIVATE that will also be
> >missed by a per-VMA lock.
> >
> >Note that the libhugetlbfs testsuite contains tests for both PRIVATE
> >and SHARED variants of the race.
> 
> Can we get away with simply using a mutex in the file?
> Say vma->vm_file->mapping->i_mmap_mutex?

I totally agree with this approach :)

> 
> That might help with multiple processes initializing
> multiple shared memory segments at the same time, and
> should not hurt the case of a process mapping its own
> hugetlbfs area.
> 
> It might have the potential to hurt when getting private
> copies on a MAP_PRIVATE area, though.  I have no idea
> how common it is for multiple processes to MAP_PRIVATE
> the same hugetlbfs file, though...

Currently, getting private copies on a MAP_PRIVATE area is also
serialized by hugetlb_instantiation_mutex.
How do we get worse with your approach?

BTW, we have one race problem related to hugetlb_instantiation_mutex.
It is not right protection for region structure handling. We map the
area without holding a hugetlb_instantiation_mutex, so there is
race condition between mapping a new area and faulting the other area.
Am I missing?

Thanks.

> 
> -- 
> All rights reversed
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: splice vs execve lockdep trace.

[Al Viro]

On Mon, Jul 15, 2013 at 08:25:14PM -0700, Linus Torvalds wrote:

> The "pipe -> cred_guard_mutex" lock chain is pretty direct, and can be
> clearly attributed to splicing into /proc. Now, whether that is a
> *good* idea or not is clearly debatable, and I do think that maybe we
> should just not splice to/from proc files, but that doesn't seem to be
> new, and I don't think it's necessarily *broken* per se, it's just
> that splicing into /proc seems somewhat unnecessary, and various proc
> files do end up taking locks that can be "interesting".

FWIW, we might attack that one - after all, we could have ->splice_write()
for that guy that would grab cred_guard_mutex, then call splice_from_pipe()
with actor that would map/do security_setprocattr/unmap...  Said that,
considering what it does on write, it really does *not* want to deal with
partial writes, so...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the cpuinit tree with the hwmon-staging tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the cpuinit tree got a conflict in
drivers/hwmon/coretemp.c between commit cc58db361386 ("hwmon: (coretemp)
Atom CPUs don't support TjMax; no warning needed") from the hwmon-staging
tree and commit "hwmon: delete __cpuinit usage from all hwmon files" from
the cpuinit tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/hwmon/coretemp.c
index be58da1,2e5e2dc..000
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@@ -317,20 -316,7 +316,19 @@@ static int adjust_tjmax(struct cpuinfo_
return tjmax;
  }
  
 +static bool cpu_has_tjmax(struct cpuinfo_x86 *c)
 +{
 +  u8 model = c->x86_model;
 +
 +  return model > 0xe &&
 + model != 0x1c &&
 + model != 0x26 &&
 + model != 0x27 &&
 + model != 0x35 &&
 + model != 0x36;
 +}
 +
- static int __cpuinit get_tjmax(struct cpuinfo_x86 *c, u32 id,
-  struct device *dev)
+ static int get_tjmax(struct cpuinfo_x86 *c, u32 id, struct device *dev)
  {
int err;
u32 eax, edx;


pgpgk7SK7gqep.pgp
Description: PGP signature

[PATCH] smp: blackfin: fix check error, using atomic_ops to handle atomic_t type

[Steven Miao]

From: Steven Miao 

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Steven Miao 
---
 arch/blackfin/mach-common/smp.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/blackfin/mach-common/smp.c b/arch/blackfin/mach-common/smp.c
index 961d839..b5f9ed7 100644
--- a/arch/blackfin/mach-common/smp.c
+++ b/arch/blackfin/mach-common/smp.c
@@ -147,7 +147,7 @@ static irqreturn_t ipi_handler_int1(int irq, void 
*dev_instance)
platform_clear_ipi(cpu, IRQ_SUPPLE_1);
 
bfin_ipi_data = &__get_cpu_var(bfin_ipi);
-   while ((pending = xchg(&bfin_ipi_data->bits, 0)) != 0) {
+   while ((pending = atomic_xchg(&bfin_ipi_data->bits, 0)) != 0) {
msg = 0;
do {
msg = find_next_bit(&pending, BITS_PER_LONG, msg + 1);
@@ -182,8 +182,8 @@ static void bfin_ipi_init(void)
struct ipi_data *bfin_ipi_data;
for_each_possible_cpu(cpu) {
bfin_ipi_data = &per_cpu(bfin_ipi, cpu);
-   bfin_ipi_data->bits = 0;
-   bfin_ipi_data->count = 0;
+   atomic_set(&bfin_ipi_data->bits, 0);
+   atomic_set(&bfin_ipi_data->count, 0);
}
 }
 
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] AHCI: fix Null pointer dereference in achi_host_active()

[Xiaotian Feng]

commit b29900e6 introuded a regression, which resulted Null pointer
dereference for achi host with dummy ports. For ahci ports, when the
port is dummy port, its private_data will be NULL, as ata_dummy_port_ops
doesn't support ->port_start.

Reported-and-tested-by: Alex Williamson 
Signed-off-by: Xiaotian Feng 
Cc: Alexander Gordeev 
Cc: Tejun Heo 
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/ata/ahci.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5064f3e..f1de689 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1147,10 +1147,16 @@ int ahci_host_activate(struct ata_host *host, int irq, 
unsigned int n_msis)
 
for (i = 0; i < host->n_ports; i++) {
struct ahci_port_priv *pp = host->ports[i]->private_data;
+   const char *desc;
 
+   if (ata_port_is_dummy(host->ports[i]))
+   desc = dev_driver_string(host->dev);
+   else
+   desc = pp->irq_desc;
+ 
rc = devm_request_threaded_irq(host->dev,
irq + i, ahci_hw_interrupt, ahci_thread_fn, IRQF_SHARED,
-   pp->irq_desc, host->ports[i]);
+   desc, host->ports[i]);
if (rc)
goto out_free_irqs;
}
-- 
1.7.9.6 (Apple Git-31.1)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the akpm tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/ext4/extents_status.c: In function 'ext4_es_shrink':
fs/ext4/extents_status.c:990:50: error: 'ret' undeclared (first use in this 
function)
  trace_ext4_es_shrink_exit(sbi->s_sb, nr_shrunk, ret);
  ^
fs/ext4/extents_status.c: In function 'ext4_es_register_shrinker':
fs/ext4/extents_status.c:999:36: error: 'ext4_es_scan' undeclared (first use in 
this function)
  sbi->s_es_shrinker.scan_objects = ext4_es_scan;
^

A product of my conflict resolutions :-(

I applied the following fix patch:

From: Stephen Rothwell 
Date: Tue, 16 Jul 2013 15:12:34 +1000
Subject: [PATCH] fixup for ext4 and shrinker changes

Signe-off-by: Stephen Rothwell 
---
 fs/ext4/extents_status.c|  6 +++---
 include/trace/events/ext4.h | 12 +---
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c
index db080c4..87fd719 100644
--- a/fs/ext4/extents_status.c
+++ b/fs/ext4/extents_status.c
@@ -977,8 +977,8 @@ static unsigned long __ext4_es_shrink(struct ext4_sb_info 
*sbi, int nr_to_scan,
return nr_shrunk;
 }
 
-static unsigned long ext4_es_shrink(struct shrinker *shrink,
-   struct shrink_control *sc)
+static unsigned long ext4_es_scan(struct shrinker *shrink,
+ struct shrink_control *sc)
 {
struct ext4_sb_info *sbi = container_of(shrink,
struct ext4_sb_info, s_es_shrinker);
@@ -987,7 +987,7 @@ static unsigned long ext4_es_shrink(struct shrinker *shrink,
 
nr_shrunk = __ext4_es_shrink(sbi, nr_to_scan, NULL);
 
-   trace_ext4_es_shrink_exit(sbi->s_sb, nr_shrunk, ret);
+   trace_ext4_es_shrink_exit(sbi->s_sb, nr_shrunk);
return nr_shrunk;
 }
 
diff --git a/include/trace/events/ext4.h b/include/trace/events/ext4.h
index 2068db2..e62c0d3 100644
--- a/include/trace/events/ext4.h
+++ b/include/trace/events/ext4.h
@@ -2378,25 +2378,23 @@ TRACE_EVENT(ext4_es_shrink_enter,
 );
 
 TRACE_EVENT(ext4_es_shrink_exit,
-   TP_PROTO(struct super_block *sb, int shrunk_nr, int cache_cnt),
+   TP_PROTO(struct super_block *sb, unsigned long shrunk_nr),
 
-   TP_ARGS(sb, shrunk_nr, cache_cnt),
+   TP_ARGS(sb, shrunk_nr),
 
TP_STRUCT__entry(
__field(dev_t,  dev )
-   __field(int,shrunk_nr   )
-   __field(int,cache_cnt   )
+   __field(unsigned long,  shrunk_nr   )
),
 
TP_fast_assign(
__entry->dev= sb->s_dev;
__entry->shrunk_nr  = shrunk_nr;
-   __entry->cache_cnt  = cache_cnt;
),
 
-   TP_printk("dev %d,%d shrunk_nr %d cache_cnt %d",
+   TP_printk("dev %d,%d shrunk_nr %lu",
  MAJOR(__entry->dev), MINOR(__entry->dev),
- __entry->shrunk_nr, __entry->cache_cnt)
+ __entry->shrunk_nr)
 );
 
 #endif /* _TRACE_EXT4_H */
-- 
1.8.3.2

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpf8B3oXo7IF.pgp
Description: PGP signature

Re: KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

[James Bottomley]

On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote:
> On Mon, Jul 15, 2013 at 11:27:56PM +0400, James Bottomley wrote:
> > Before the "3.10.1-stable review" thread degenerated into a disagreement
> > about habits of politeness, there were some solid points being made
> > which, I think, bear consideration and which may now be lost.
> > 
> > The problem, as Ji Kosina put is succinctly is that the distributions
> > are finding stable less useful because it contains to much stuff they'd
> > classify as not stable material.
> > 
> > The question that arises from this is who is stable aiming at ...
> > because if it's the distributions (and that's what people seem to be
> > using it for) then we need to take this feedback seriously.
> > 
> > The next question is how should we, the maintainers, be policing commits
> > to stable.  As I think has been demonstrated in the discussion the
> > "stable rules" are more sort of guidelines (apologies for the pirates
> > reference).  In many ways, this is as it should be, because people
> > should have enough taste to know what constitutes a stable fix.  The
> > real root cause of the problem is that the cc: stable tag can't be
> > stripped once it's in the tree, so maintainers only get to police things
> > they put in the tree.  Stuff they pull from others is already tagged and
> > that tag can't be changed.  This effectively pushes the problem out to
> > the lowest (and possibly more inexperienced) leaves of the Maintainer
> > tree.  In theory we have a review stage for stable, but the review
> > patches don't automatically get routed to the right mailing list and the
> > first round usually comes out in the merge window when Maintainers'
> > attention is elsewhere.
> > 
> > The solution, to me, looks simple:  Let's co-opt a process we already
> > know how to do: mailing list review and tree handling.  So the proposal
> > is simple:
> > 
> >  1. Drop the cc: stable@ tag: it makes it way too easy to add an ill
> > reviewed patch to stable
> >  2. All patches to stable should follow current review rules: They
> > should go to the mailing list the original patch was sent to
> > once the original is upstream as a request for stable.
> >  3. Following debate on the list, the original maintainer would be
> > responsible for collecting the patches (including the upstream
> > commit) adjudicating on them and passing them on to stable after
> > list review (either by git tree pull or email to stable@).
> > 
> > I contend this raises the bar for adding patches to stable much higher,
> > which seems to be needed, and adds a review stage which involves all the
> > original reviewers.
> 
> I don't like this at all, just for the simple reason that it will push
> the majority of the work of stable kernel development on to the
> subsystem maintainers, who have enough work to do as it is.

Well, I think of this as a feature not a bug because it enables scaling,
but we can certainly debate the topic; it's probably one of the more
important things that should be discussed.

> Stable tree stuff should cause almost _no_ extra burden on the kernel
> developers, because it is something that I, and a few other people, have
> agreed to do with our time.  It has taken me 8 _years_ to finally get
> maintainers to agree to mark stuff for the stable tree, and fine-tune a
> development process that makes it easy for us to do this backport work.
> 
> I _want_ the exact same commit that is in Linus's tree for the backport
> because if I have to rely on a maintainer to do the backport and resend
> it, I _know_ it will usually be a changed patch, and the git commit id
> will be lost.

This is fixable with process and tools, surely.

It's always surprised me that the number one stable_kernel_rules.txt
rule wasn't you have tobe upstream and label in the the first line with
Upstream-Commit: commitid.  (I know it's in the procedure, but that's
not rules).  But if it were, a script can reject with a response all
non-conforming emails.  Now you have the commitid, interdiff can tell
you if it's the same patch as went into the kernel, so you can put this
into the automatic apply queue.  Everything else goes into a different
queue.

> I know this because it happens today.  I get patches from maintainers
> that are radically changed from what is in Linus's tree without any
> justification for why that is.  That's not ok.

So you could even script this.  An automatic request for justification
of patches that interdiff flags as being different (or a request to
resubmit with the identical diff so they pass the interdiff test).

> Let me work with the distros on the issues they have raised.  So far I
> have the following issues they have complained about:
>   - patches that shouldn't be there because they don't really do
> anything.
>   - patches that aren't obvious why they are there.
> 
> The first one I am going to be pushing back on, and have alread

Re: [uclinux-dist-devel] [GIT PULL] Blackfin updates for 3.11

[Steven Miao]

On Tue, Jul 16, 2013 at 1:49 AM, Linus Torvalds
 wrote:
> On Mon, Jul 15, 2013 at 10:28 AM, Geert Uytterhoeven
>  wrote:
>>
>> but the first one is non-trivial: using xchg() on atomic_t is a bit gross...
>
> It's also broken. There's no guarantee that an "atomic_t" is just a
> value. Now, the old sparc32 stuff (which hid lock bits in atomic_t)
> may be gone, but it's still the case that atomic_t may not actually
> work with xchg.
>
> (In *practice* it works on normal architectures, so I'm not saying
> that we don't have it, but it's a bug if we do).
>
> There are "atomic_xchg()" and "atomic_xchg64()" functions that are supported.
I'll send a patch to fix it.
>
>  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [uclinux-dist-devel] [GIT PULL] Blackfin updates for 3.11

[Steven Miao]

Hi Geert,

On Tue, Jul 16, 2013 at 1:28 AM, Geert Uytterhoeven
 wrote:
> Hi Steven,
>
> On Tue, Jul 9, 2013 at 11:15 AM, Steven Miao  wrote:
>> Steven Miao (2):
>>   smp: refine bf561 smpboot code
>
> Unfortunately this landed too late in -next to notice:
>
> arch/blackfin/mach-common/smp.c:150:2: error: conversion to non-scalar
> type requested
> arch/blackfin/mach-common/smp.c:185:23: error: incompatible types when
> assigning to type 'atomic_t' from type 'int'
> arch/blackfin/mach-common/smp.c:186:24: error: incompatible types when
> assigning to type 'atomic_t' from type 'int'
> make[2]: *** [arch/blackfin/mach-common/smp.o] Error 1
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/9115952/
>
> It's a bit embarrassing to break your own core code (with a patch that was
> submitted for public review in August 2012?).
>
> The last two can be trivially-fixed with the following
> (whitespace-damaged gmail)
> patch:
>
> --- a/arch/blackfin/mach-common/smp.c
> +++ b/arch/blackfin/mach-common/smp.c
> @@ -182,8 +182,8 @@ static void bfin_ipi_init(void)
>   struct ipi_data *bfin_ipi_data;
>   for_each_possible_cpu(cpu) {
>   bfin_ipi_data = &per_cpu(bfin_ipi, cpu);
> - bfin_ipi_data->bits = 0;
> - bfin_ipi_data->count = 0;
> + atomic_set(&bfin_ipi_data->bits, 0);
> + atomic_set(&bfin_ipi_data->count, 0);
>   }
>  }

Sorry, I should use atomic_ops to hanle atomic_t type.
>
> but the first one is non-trivial: using xchg() on atomic_t is a bit gross...
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Willy Tarreau]

On Mon, Jul 15, 2013 at 08:17:30PM -0400, Steven Rostedt wrote:
> On Mon, 2013-07-15 at 16:15 -0700, Guenter Roeck wrote:
> >  
> > One thing you should keep in mind in your discussion is what can happen
> > if people get too polite with each other.
> > 
> > I have seen this happen at two large companies I worked for. Early on, 
> > flames
> > are acceptable and expected as response to someone publishing bad code which
> > breaks everything for everyone. Then, at some point, it is not acceptable
> > anymore to flame, and one is expected to be polite and friendly at all 
> > times.
> > "Your code breaks the build for every platform. Would you please kindly
> > consider fixing it ?"
> > Result is that code quality suffers, to the point where images don't even
> > build anymore.
> > 
> > I hope the Linux kernel never gets into that stage. To avoid that,
> > I am willing to be cursed at by Linus if I am the responsible party.
> 
> Didn't Jim Zemlin show some research where there were two groups:
> 
>  One that did a bunch of brain storming where no idea was a bad idea
> 
>  The other required you to defend your idea while the others bashed it.
> 
> The results always showed that the second group not only did a better
> job, but also faster and more efficient.
> 
> I'm afraid if we worry too much about politeness, we will fall into that
> first group.

Linus already said you don't need to feer this change from him :-)

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] regmap: Provide __acquires/__releases annotations

[Fabio Estevam]

From: Fabio Estevam 

Fix the following sparse warnings:

drivers/base/regmap/regmap.c:305:13: warning: context imbalance in 
'regmap_lock_spinlock' - wrong count at exit
drivers/base/regmap/regmap.c:314:13: warning: context imbalance in 
'regmap_unlock_spinlock' - unexpected unlock

Signed-off-by: Fabio Estevam 
---
 drivers/base/regmap/regmap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index e0d0c7d..d7144cf 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -303,6 +303,7 @@ static void regmap_unlock_mutex(void *__map)
 }
 
 static void regmap_lock_spinlock(void *__map)
+__acquires(&map->spinlock)
 {
struct regmap *map = __map;
unsigned long flags;
@@ -312,6 +313,7 @@ static void regmap_lock_spinlock(void *__map)
 }
 
 static void regmap_unlock_spinlock(void *__map)
+__releases(&map->spinlock)
 {
struct regmap *map = __map;
spin_unlock_irqrestore(&map->spinlock, map->spinlock_flags);
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/9] mm, hugetlb: move up the code which check availability of free huge page

[Joonsoo Kim]

On Tue, Jul 16, 2013 at 09:06:04AM +0530, Aneesh Kumar K.V wrote:
> Joonsoo Kim  writes:
> 
> > On Mon, Jul 15, 2013 at 07:31:33PM +0530, Aneesh Kumar K.V wrote:
> >> Joonsoo Kim  writes:
> >> 
> >> > We don't need to proceede the processing if we don't have any usable
> >> > free huge page. So move this code up.
> >> 
> >> I guess you can also mention that since we are holding hugetlb_lock
> >> hstate values can't change.
> >
> > Okay. I will mention this for v2.
> >
> >> 
> >> 
> >> Also.
> >> 
> >> >
> >> > Signed-off-by: Joonsoo Kim 
> >> >
> >> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> >> > index e2bfbf7..d87f70b 100644
> >> > --- a/mm/hugetlb.c
> >> > +++ b/mm/hugetlb.c
> >> > @@ -539,10 +539,6 @@ static struct page *dequeue_huge_page_vma(struct 
> >> > hstate *h,
> >> >  struct zoneref *z;
> >> >  unsigned int cpuset_mems_cookie;
> >> >
> >> > -retry_cpuset:
> >> > -cpuset_mems_cookie = get_mems_allowed();
> >> > -zonelist = huge_zonelist(vma, address,
> >> > -htlb_alloc_mask, &mpol, 
> >> > &nodemask);
> >> >  /*
> >> >   * A child process with MAP_PRIVATE mappings created by their 
> >> > parent
> >> >   * have no page reserves. This check ensures that reservations 
> >> > are
> >> > @@ -550,11 +546,16 @@ retry_cpuset:
> >> >   */
> >> >  if (!vma_has_reserves(vma) &&
> >> >  h->free_huge_pages - h->resv_huge_pages == 0)
> >> > -goto err;
> >> > +return NULL;
> >> >
> >> 
> >> If you don't do the above change, the patch will be much simpler. 
> >
> > The patch will be, but output code will not.
> > With this change, we can remove one goto label('err:') and
> > this makes code more readable.
> >
> 
> If you feel stronly about the cleanup, you can do another path for the
> cleanups. Don't mix things in a single patch. That makes review difficult.

Okay! I will make an another patch for clean-up.

Thanks.

> 
> -aneesh
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the akpm tree with the ext4 tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
fs/ext4/extents_status.c between commit decae3aab047 ("ext4: make the
extent_status code more robust against ENOMEM failures") from the ext4
tree and commit "fs-convert-fs-shrinkers-to-new-scan-count-api-fix" from
the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc fs/ext4/extents_status.c
index 95d5bde,8a45b86..000
--- a/fs/ext4/extents_status.c
+++ b/fs/ext4/extents_status.c
@@@ -148,8 -148,6 +148,8 @@@ static int __es_remove_extent(struct in
  ext4_lblk_t end);
  static int __es_try_to_reclaim_extents(struct ext4_inode_info *ei,
   int nr_to_scan);
- static int __ext4_es_shrink(struct ext4_sb_info *sbi, int nr_to_scan,
-   struct ext4_inode_info *locked_ei);
++static unsigned long __ext4_es_shrink(struct ext4_sb_info *sbi, int 
nr_to_scan,
++struct ext4_inode_info *locked_ei);
  
  int __init ext4_init_es(void)
  {
@@@ -914,13 -903,17 +915,14 @@@ static unsigned long ext4_es_count(stru
return nr;
  }
  
- static int __ext4_es_shrink(struct ext4_sb_info *sbi, int nr_to_scan,
 -static unsigned long ext4_es_scan(struct shrinker *shrink,
 -struct shrink_control *sc)
++static unsigned long __ext4_es_shrink(struct ext4_sb_info *sbi, int 
nr_to_scan,
 +  struct ext4_inode_info *locked_ei)
  {
 -  struct ext4_sb_info *sbi = container_of(shrink,
 -  struct ext4_sb_info, s_es_shrinker);
struct ext4_inode_info *ei;
struct list_head *cur, *tmp;
LIST_HEAD(skiped);
-   int ret, nr_shrunk = 0;
 -  int nr_to_scan = sc->nr_to_scan;
 -  int ret = 0;
++  int ret;
+   unsigned long nr_shrunk = 0;
  
spin_lock(&sbi->s_es_lru_lock);
  
@@@ -969,21 -962,6 +971,22 @@@
list_splice_tail(&skiped, &sbi->s_es_lru);
spin_unlock(&sbi->s_es_lru_lock);
  
 +  if (locked_ei && nr_shrunk == 0)
 +  nr_shrunk = __es_try_to_reclaim_extents(ei, nr_to_scan);
 +
 +  return nr_shrunk;
 +}
 +
- static long ext4_es_shrink(struct shrinker *shrink, struct shrink_control *sc)
++static unsigned long ext4_es_shrink(struct shrinker *shrink,
++  struct shrink_control *sc)
 +{
 +  struct ext4_sb_info *sbi = container_of(shrink,
 +  struct ext4_sb_info, s_es_shrinker);
 +  int nr_to_scan = sc->nr_to_scan;
-   int nr_shrunk;
++  unsigned long nr_shrunk;
 +
 +  nr_shrunk = __ext4_es_shrink(sbi, nr_to_scan, NULL);
 +
trace_ext4_es_shrink_exit(sbi->s_sb, nr_shrunk, ret);
return nr_shrunk;
  }


pgpZFSwjmX2N3.pgp
Description: PGP signature

linux-next: manual merge of the akpm tree with the ext4 tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
fs/ext4/extents_status.c between commit decae3aab047 ("ext4: make the
extent_status code more robust against ENOMEM failures") from the ext4
tree and commit  "fs: convert fs shrinkers to new scan/count API" from
the akpm tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc fs/ext4/extents_status.c
index 91cb110,fb3b95e..000
--- a/fs/ext4/extents_status.c
+++ b/fs/ext4/extents_status.c
@@@ -903,9 -891,21 +903,20 @@@ static int ext4_inode_touch_time_cmp(vo
return -1;
  }
  
+ static long ext4_es_count(struct shrinker *shrink, struct shrink_control *sc)
+ {
+   long nr;
+   struct ext4_sb_info *sbi = container_of(shrink,
+   struct ext4_sb_info, s_es_shrinker);
+ 
+   nr = percpu_counter_read_positive(&sbi->s_extent_cache_cnt);
+   trace_ext4_es_shrink_enter(sbi->s_sb, sc->nr_to_scan, nr);
+   return nr;
+ }
+ 
 -static long ext4_es_scan(struct shrinker *shrink, struct shrink_control *sc)
 +static int __ext4_es_shrink(struct ext4_sb_info *sbi, int nr_to_scan,
 +  struct ext4_inode_info *locked_ei)
  {
 -  struct ext4_sb_info *sbi = container_of(shrink,
 -  struct ext4_sb_info, s_es_shrinker);
struct ext4_inode_info *ei;
struct list_head *cur, *tmp;
LIST_HEAD(skiped);
@@@ -958,30 -959,8 +969,23 @@@
list_splice_tail(&skiped, &sbi->s_es_lru);
spin_unlock(&sbi->s_es_lru_lock);
  
 +  if (locked_ei && nr_shrunk == 0)
 +  nr_shrunk = __es_try_to_reclaim_extents(ei, nr_to_scan);
 +
 +  return nr_shrunk;
 +}
 +
- static int ext4_es_shrink(struct shrinker *shrink, struct shrink_control *sc)
++static long ext4_es_shrink(struct shrinker *shrink, struct shrink_control *sc)
 +{
 +  struct ext4_sb_info *sbi = container_of(shrink,
 +  struct ext4_sb_info, s_es_shrinker);
 +  int nr_to_scan = sc->nr_to_scan;
-   int ret, nr_shrunk;
- 
-   ret = percpu_counter_read_positive(&sbi->s_extent_cache_cnt);
-   trace_ext4_es_shrink_enter(sbi->s_sb, nr_to_scan, ret);
- 
-   if (!nr_to_scan)
-   return ret;
++  int nr_shrunk;
 +
 +  nr_shrunk = __ext4_es_shrink(sbi, nr_to_scan, NULL);
 +
-   ret = percpu_counter_read_positive(&sbi->s_extent_cache_cnt);
trace_ext4_es_shrink_exit(sbi->s_sb, nr_shrunk, ret);
-   return ret;
+   return nr_shrunk;
  }
  
  void ext4_es_register_shrinker(struct ext4_sb_info *sbi)


pgpCzGDVgiwuh.pgp
Description: PGP signature

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Paul Gortmaker]

[Re: [PATCH] Documentation: update references to v2.6.x in development-process] 
On 16/07/2013 (Tue 13:50) Stephen Rothwell wrote:

> Hi Paul,
> 
> On Mon, 15 Jul 2013 22:13:50 -0400 Paul Gortmaker 
>  wrote:
> >
> > On a similar note, I was thinking about the recent thread on linux-next
> > where we were indicating that people shouldn't rebase linux-next content
> > on a whim, and that new devel (vs. bugfix) content shouldn't appear in
> > the linux-next content during the merge window.  There is no question
> > that the linux-next process is integral to the main flow of patches to
> > mainline, so I think Documentation/development-process/2.Process (the
> > same file) should also capture those points in the linux-next section.
> > Do you have some pre-canned text we can insert there, or should I draft
> > something up for you to review?
> 
> The latter would be certainly easier for me :-)  If that is not easy, let
> me know and I will write something (even without swearing ;-)).

I'll do something for the latter, but I can't promise to refrain from
swearing...  ;-)

Thanks,
Paul.
--

> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/scsi/fnic: updated fileoperations structure to use simple_open

[Dragos Foianu]

The function has the same implementation as simple_open. I removed it and 
replaced the reference in the fileoperations struct with simple_open.

Found using Coccinelle.

Signed-off-by: Dragos Foianu 
---
 drivers/scsi/fnic/fnic_debugfs.c |   19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/scsi/fnic/fnic_debugfs.c b/drivers/scsi/fnic/fnic_debugfs.c
index cbcb012..ddc7e94 100644
--- a/drivers/scsi/fnic/fnic_debugfs.c
+++ b/drivers/scsi/fnic/fnic_debugfs.c
@@ -25,23 +25,6 @@ static struct dentry *fnic_trace_debugfs_file;
 static struct dentry *fnic_trace_enable;
 
 /*
- * fnic_trace_ctrl_open - Open the trace_enable file
- * @inode: The inode pointer.
- * @file: The file pointer to attach the trace enable/disable flag.
- *
- * Description:
- * This routine opens a debugsfs file trace_enable.
- *
- * Returns:
- * This function returns zero if successful.
- */
-static int fnic_trace_ctrl_open(struct inode *inode, struct file *filp)
-{
-   filp->private_data = inode->i_private;
-   return 0;
-}
-
-/*
  * fnic_trace_ctrl_read - Read a trace_enable debugfs file
  * @filp: The file pointer to read from.
  * @ubuf: The buffer to copy the data to.
@@ -222,7 +205,7 @@ static int fnic_trace_debugfs_release(struct inode *inode,
 
 static const struct file_operations fnic_trace_ctrl_fops = {
.owner = THIS_MODULE,
-   .open = fnic_trace_ctrl_open,
+   .open = simple_open,
.read = fnic_trace_ctrl_read,
.write = fnic_trace_ctrl_write,
 };
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] nohz: fix compile warning in tick_nohz_init()

[Li Zhong]

cpu is not used after commit 5b8621a68fdcd2baf1d3b413726f913a5254d46a

Signed-off-by: Li Zhong 
---
 kernel/time/tick-sched.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index e80183f..8145860 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -343,8 +343,6 @@ static int tick_nohz_init_all(void)
 
 void __init tick_nohz_init(void)
 {
-   int cpu;
-
if (!have_nohz_full_mask) {
if (tick_nohz_init_all() < 0)
return;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Ben Hutchings]

On Mon, 2013-07-15 at 19:34 -0400, Paul Gortmaker wrote:
[...] 
>  Some kernels are designated "long term" kernels; they will receive support
>  for a longer period.  As of this writing, the current long term kernels
>  and their maintainers are:
>  
> - 2.6.27  Willy Tarreau   (Deep-frozen stable kernel)
> - 2.6.32  Greg Kroah-Hartman
> - 2.6.35  Andi Kleen  (Embedded flag kernel)
> + 2.6.32  Willy Tarreau
> + 3.0 Greg Kroah-Hartman
> + 3.2 Ben Hutchings
> + 3.4 Greg Kroah-Hartman
[...]

You could also link to  here.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


signature.asc
Description: This is a digitally signed message part

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Darren Hart]

On Mon, 2013-07-15 at 23:37 -0400, Steven Rostedt wrote:
> On Mon, 2013-07-15 at 23:34 -0400, Steven Rostedt wrote:
> > On Tue, 2013-07-16 at 13:14 +1000, NeilBrown wrote:
> > 
> > > Surely there is an enormous difference between being required to defend 
> > > your
> > > position against rational and forceful argument, and being required to 
> > > defend
> > > it against irrelevant name calling.
> > 
> > Sure, but I don't think there's really much name calling in the kernel
> > community.
> > 
> > I just scanned a large number of LKML emails, and they all seemed rather
> > technical, and no personal attacks at all. And that included several
> > emails from Linus as well. Probably the strongest email came from Thomas
> > Gleixner, but even that didn't contain any personal name calling. Mostly
> > he called stuff "crap" but that was about the code and claims that the
> > code did, but not about the person.
> > 
> > There are a few times that Linus gets a bit colorful with his
> > criticisms, but that's really the minority of the email and not the
> > overall tone. I think Linus picks his battles. Sometimes he goes
> > overboard, but he's human. But I still think he's running this ship
> > well.
> > 
> 
> I just found this gem: https://lkml.org/lkml/2013/7/10/600
> 
> But it's just Linus ranting about having "make install" modify the
> source tree (which I totally agree with him, as I've stumbled over crap
> like this in other projects). But he's bitching about the code, not the
> person who asked him to pull it.

Excellent example Steve. This is the core of what I was trying to get
at. Linus vehemently and colorfully expressed his distate for *problem*
and told the developer what they needed to do differently. No personal
attack there.

Would I like to be on the receiving end of that email... No, I would
not. However, I can also understand being fed up with lots of little
things like this and not having the patience or the desire to treat each
one as a mentoring opportunity. The difference tends to be I rant to my
close friends and Linus does so in public he's the more honest of
the two of us I think :-)

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

[Ben Hutchings]

On Tue, 2013-07-16 at 13:27 +1000, Dave Airlie wrote:
> On Tue, Jul 16, 2013 at 12:41 PM, Ben Hutchings  wrote:
> > On Mon, 2013-07-15 at 22:09 -0400, Steven Rostedt wrote:
> > [...]
> >> > > How important is the stable releases? Are maintainers willing to do a
> >> > > little more work now to make sure their subsystems work fine in older
> >> > > kernels? This isn't the same stable as it was 8 years ago.
> >> >
> >> > And that annoys the hell out of some Linux companies who feel that the
> >> > stable kernels compete with them.  So people working for those companies
> >> > might not get as much help with doing any additional work for stable
> >> > kernel releases (this is not just idle gossip, I've heard it directly
> >> > from management's mouths.)
> >>
> >> Hmm, this is new to me. Really, I thought the whole point of the stable
> >> releases was to help Linux companies.
> > [...]
> >
> > I also heard some managers decided their kernel source packages should
> > have all the patches squashed together to make them harder to cherry-
> > pick... could it have been the same company?
> 
> Greg loves to tell stories about RH management, but really if he can
> find any engineer who works for RH that says he can't work on stable
> due to being told by management, I'd be surprised.

To be clear, I very much appreciate the level of contribution to stable
from RH developers.  And it's a little too high to believe these are
just a few rogues flouting policy. :-)

> Maybe when stable
> first surfaced there was a hope of it being close to RHEL,

The lack of non-trivial driver backports means it's not really
competitive with any commercial distribution.  (But it looks a little
better if you add in compat-drivers.)

> but at this
> point stable has little to no usefulness from a RHEL point of view,
> and since nearly all the RH employed maintainers all do stable work, I
> can't see why Greg would think this matters.
> 
> In fact Greg how much of stable queue does come from Red Hatters?

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


signature.asc
Description: This is a digitally signed message part

Re: [RESEND] The initmpfs patches.

[Rob Landley]

On 07/15/2013 04:01:35 PM, Andrew Morton wrote:
On Tue, 09 Jul 2013 21:06:39 -0500 Rob Landley   
wrote:


> Attached, so you don't have to fish them out of:
>
>http://lkml.indiana.edu/hypermail/linux/kernel/1306.3/04204.html

Too hard.  Especially when I want to reply to a patch.  Please resend
as a patch series in the time-honoured fashion?


Ok.

(Balsa is such an incompetent email client I wrote a python script to  
do this via raw smtp, and I'm always convinced it's going to screw up  
the send. But I think I've got it debugged now...)



> --- a/fs/ramfs/inode.c
> +++ b/fs/ramfs/inode.c
> @@ -247,7 +247,14 @@ struct dentry *ramfs_mount(struct  
file_system_type *fs_type,
>  static struct dentry *rootfs_mount(struct file_system_type  
*fs_type,

>int flags, const char *dev_name, void *data)
>  {
> -	return mount_nodev(fs_type, flags|MS_NOUSER, data,  
ramfs_fill_super);

> +  static int once;
> +
> +  if (once)
> +  return ERR_PTR(-ENODEV);
> +  else
> +  once++;
> +
> +  return mount_nodev(fs_type, flags, data, ramfs_fill_super);
>  }

The patches do this in a couple of places.  The treatment of `once' is
obviously racy.  Probably it is unlikely to matter in these contexts,
but it does set a poor example.  And it's so trivially fixed with, for
example, test_and_set_bit() that I do think it's worth that change.


Fixing in new series. Retesting will probably delay the resend until  
morning.


Thanks,

Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ATTEND] How to act on LKML

[David Ahern]

On 7/15/13 4:50 PM, Sarah Sharp wrote:

Sarah will bring the brownies.


Peace pot brownies!  I love it!


Too bad the KS is not going to be held here in Colorado. You could 
follow through with that ...


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Documentation: update references to v2.6.x in development-process

[Stephen Rothwell]

Hi Paul,

On Mon, 15 Jul 2013 22:13:50 -0400 Paul Gortmaker 
 wrote:
>
> On a similar note, I was thinking about the recent thread on linux-next
> where we were indicating that people shouldn't rebase linux-next content
> on a whim, and that new devel (vs. bugfix) content shouldn't appear in
> the linux-next content during the merge window.  There is no question
> that the linux-next process is integral to the main flow of patches to
> mainline, so I think Documentation/development-process/2.Process (the
> same file) should also capture those points in the linux-next section.
> Do you have some pre-canned text we can insert there, or should I draft
> something up for you to review?

The latter would be certainly easier for me :-)  If that is not easy, let
me know and I will write something (even without swearing ;-)).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpNaByfj4AmS.pgp
Description: PGP signature

Re: [PATCH] usb: udc: add gadget state kobject uevent

[Rong Wang]

Hi Greg,

The USB on our platform can change roles between HOST and GADGET, but
it is not capable of OTG.
When the USB changes between roles the udev will run some scripts
automatically according to the udev rules.
The default role is GADGET, and we bind the g_mass_storage to the USB
GADGET role.

We should secure the back end file storage between the device and the
host PC connecting to our device.
We need to know when the GADGET is really connect to a host PC, then
we can umount the file on the device
and export it to the g_mass_storage.

The question is since we default GADGET, so the g_mass_storage.ko is
installed early but connecting to a host PC
is randomly, But the udev has no idea when a host PC connects our device.

So we consider it's reasonable to let the udev know the GADGET device state.
Is there any alternative to our question?

Thanks!

On Tue, Jul 16, 2013 at 12:52 AM, Greg KH  wrote:
> On Mon, Jul 15, 2013 at 11:57:24AM +0800, Rong Wang wrote:
>> usb: udc: add gadget state kobject uevent
>>
>> Add USB_UDC_STATE environment variable in udc uevent
>> callback and trigger kobject_uevent in usb_gadget_set_state
>> to inform the user-space the state of the gadget.
>
> Why?
>
> And what's with the indentation?
>
>> Signed-off-by: Rong Wang 
>>
>> diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
>> index ffd8fa5..05715d1 100644
>> --- a/drivers/usb/gadget/udc-core.c
>> +++ b/drivers/usb/gadget/udc-core.c
>> @@ -101,11 +101,32 @@ EXPORT_SYMBOL_GPL(usb_gadget_unmap_request);
>>
>>  /* 
>> - */
>>
>> +/**
>> + * usb_gadget_set_state - set usb gadget state
>> + * @gadget: gadget device
>> + * @state: state defined in USB specification ch9
>> + * Context: !in_interrupt()
>> + */
>>  void usb_gadget_set_state(struct usb_gadget *gadget,
>> enum usb_device_state state)
>>  {
>> +   struct usb_udc  *udc = NULL;
>> +
>> gadget->state = state;
>> sysfs_notify(&gadget->dev.kobj, NULL, "status");
>> +
>> +   mutex_lock(&udc_lock);
>> +   list_for_each_entry(udc, &udc_list, list)
>> +   if (udc->gadget == gadget)
>> +   goto found;
>> +
>> +   dev_err(gadget->dev.parent, "gadget not registered.\n");
>> +   mutex_unlock(&udc_lock);
>> +   return;
>> +
>> +found:
>> +   mutex_unlock(&udc_lock);
>> +   kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
>
> I really don't like adding kobject change events, as they usually never
> get listened to, and there are other ways to get this information from
> userspace, right?
>
> Why do you need/want this?  What is it going to be used for?  What tools
> will use it?  How will they use it?
>
> And why can't the existing notification events for gadget devices work
> for you?
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ATTEND] How to act on LKML

[Steven Rostedt]

On Tue, 2013-07-16 at 11:27 +0800, Li Zefan wrote:

> Oh, I can name some kernel developers who I see are most friendly to other
> developers, and you are one of them. ;)

That's because I've been blessed to only have to deal with good
developers ;-)

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

[Steven Rostedt]

On Tue, 2013-07-16 at 13:27 +1000, Dave Airlie wrote:

> > I also heard some managers decided their kernel source packages should
> > have all the patches squashed together to make them harder to cherry-
> > pick... could it have been the same company?
> 
> Greg loves to tell stories about RH management, but really if he can
> find any engineer who works for RH that says he can't work on stable
> due to being told by management, I'd be surprised. Maybe when stable
> first surfaced there was a hope of it being close to RHEL, but at this
> point stable has little to no usefulness from a RHEL point of view,
> and since nearly all the RH employed maintainers all do stable work, I
> can't see why Greg would think this matters.

And to stress that point. I myself work for Red Hat, and I'm very big
into the stable tree. Heck, I maintain a 3.6 stable (not as well as
"Greg" does, but I'm just a mere mortal).

I don't know what managers Greg talked to, but I've been encouraged by
management to mark bug fixes with the stable tag.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] ARM: dts: imx23-evk: enable USB PHY and controller

[Fabio Estevam]

On Mon, Jul 15, 2013 at 11:22 AM, Otavio Salvador
 wrote:
> The i.MX23EVK board provides a USB port so the USB PHY and controller
> need to be enabled for it to be usable.

Has this been tested? I don't see in this patch any code to enable USB power.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Steven Rostedt]

On Mon, 2013-07-15 at 23:34 -0400, Steven Rostedt wrote:
> On Tue, 2013-07-16 at 13:14 +1000, NeilBrown wrote:
> 
> > Surely there is an enormous difference between being required to defend your
> > position against rational and forceful argument, and being required to 
> > defend
> > it against irrelevant name calling.
> 
> Sure, but I don't think there's really much name calling in the kernel
> community.
> 
> I just scanned a large number of LKML emails, and they all seemed rather
> technical, and no personal attacks at all. And that included several
> emails from Linus as well. Probably the strongest email came from Thomas
> Gleixner, but even that didn't contain any personal name calling. Mostly
> he called stuff "crap" but that was about the code and claims that the
> code did, but not about the person.
> 
> There are a few times that Linus gets a bit colorful with his
> criticisms, but that's really the minority of the email and not the
> overall tone. I think Linus picks his battles. Sometimes he goes
> overboard, but he's human. But I still think he's running this ship
> well.
> 

I just found this gem: https://lkml.org/lkml/2013/7/10/600

But it's just Linus ranting about having "make install" modify the
source tree (which I totally agree with him, as I've stumbled over crap
like this in other projects). But he's bitching about the code, not the
person who asked him to pull it.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ATTEND] How to act on LKML

[H. Peter Anvin]

On 07/15/2013 08:06 PM, Steven Rostedt wrote:
> 
> Linus's point is that he wants to be honest, and cursing is his way of
> giving you the most direct way to understand how he honestly feels.
> 

What I don't get about anything of this is that I have always found
Linus' being hyper-obviously over the top sarcastic when he goes on a
rant.  There is usually plenty of context to derive that from, too, even
if you haven't seen him in person enough to virtually hear the smirk in
his voice.  This is a form of humor more than anything else, and at
least I find it utterly impossible to be offended by it.  As the main
target of the rant this weekend, I (a) chuckled, and (b) said "I think I
need to do some damage control".

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/9] mm, hugetlb: move up the code which check availability of free huge page

[Aneesh Kumar K.V]

Joonsoo Kim  writes:

> On Mon, Jul 15, 2013 at 07:31:33PM +0530, Aneesh Kumar K.V wrote:
>> Joonsoo Kim  writes:
>> 
>> > We don't need to proceede the processing if we don't have any usable
>> > free huge page. So move this code up.
>> 
>> I guess you can also mention that since we are holding hugetlb_lock
>> hstate values can't change.
>
> Okay. I will mention this for v2.
>
>> 
>> 
>> Also.
>> 
>> >
>> > Signed-off-by: Joonsoo Kim 
>> >
>> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> > index e2bfbf7..d87f70b 100644
>> > --- a/mm/hugetlb.c
>> > +++ b/mm/hugetlb.c
>> > @@ -539,10 +539,6 @@ static struct page *dequeue_huge_page_vma(struct 
>> > hstate *h,
>> >struct zoneref *z;
>> >unsigned int cpuset_mems_cookie;
>> >
>> > -retry_cpuset:
>> > -  cpuset_mems_cookie = get_mems_allowed();
>> > -  zonelist = huge_zonelist(vma, address,
>> > -  htlb_alloc_mask, &mpol, &nodemask);
>> >/*
>> > * A child process with MAP_PRIVATE mappings created by their parent
>> > * have no page reserves. This check ensures that reservations are
>> > @@ -550,11 +546,16 @@ retry_cpuset:
>> > */
>> >if (!vma_has_reserves(vma) &&
>> >h->free_huge_pages - h->resv_huge_pages == 0)
>> > -  goto err;
>> > +  return NULL;
>> >
>> 
>> If you don't do the above change, the patch will be much simpler. 
>
> The patch will be, but output code will not.
> With this change, we can remove one goto label('err:') and
> this makes code more readable.
>

If you feel stronly about the cleanup, you can do another path for the
cleanups. Don't mix things in a single patch. That makes review difficult.

-aneesh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[Steven Rostedt]

On Tue, 2013-07-16 at 13:14 +1000, NeilBrown wrote:

> Surely there is an enormous difference between being required to defend your
> position against rational and forceful argument, and being required to defend
> it against irrelevant name calling.

Sure, but I don't think there's really much name calling in the kernel
community.

I just scanned a large number of LKML emails, and they all seemed rather
technical, and no personal attacks at all. And that included several
emails from Linus as well. Probably the strongest email came from Thomas
Gleixner, but even that didn't contain any personal name calling. Mostly
he called stuff "crap" but that was about the code and claims that the
code did, but not about the person.

There are a few times that Linus gets a bit colorful with his
criticisms, but that's really the minority of the email and not the
overall tone. I think Linus picks his battles. Sometimes he goes
overboard, but he's human. But I still think he's running this ship
well.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC V10 15/18] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

[Raghavendra K T]

On 07/15/2013 04:06 PM, Gleb Natapov wrote:

On Mon, Jul 15, 2013 at 03:20:06PM +0530, Raghavendra K T wrote:

On 07/14/2013 06:42 PM, Gleb Natapov wrote:

On Mon, Jun 24, 2013 at 06:13:42PM +0530, Raghavendra K T wrote:

kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor

From: Srivatsa Vaddagiri 


trimming
[...]

+
+static void kvm_lock_spinning(struct arch_spinlock *lock, __ticket_t want)
+{
+   struct kvm_lock_waiting *w;
+   int cpu;
+   u64 start;
+   unsigned long flags;
+
+   w = &__get_cpu_var(lock_waiting);
+   cpu = smp_processor_id();
+   start = spin_time_start();
+
+   /*
+* Make sure an interrupt handler can't upset things in a
+* partially setup state.
+*/
+   local_irq_save(flags);
+
+   /*
+* The ordering protocol on this is that the "lock" pointer
+* may only be set non-NULL if the "want" ticket is correct.
+* If we're updating "want", we must first clear "lock".
+*/
+   w->lock = NULL;
+   smp_wmb();
+   w->want = want;
+   smp_wmb();
+   w->lock = lock;
+
+   add_stats(TAKEN_SLOW, 1);
+
+   /*
+* This uses set_bit, which is atomic but we should not rely on its
+* reordering gurantees. So barrier is needed after this call.
+*/
+   cpumask_set_cpu(cpu, &waiting_cpus);
+
+   barrier();
+
+   /*
+* Mark entry to slowpath before doing the pickup test to make
+* sure we don't deadlock with an unlocker.
+*/
+   __ticket_enter_slowpath(lock);
+
+   /*
+* check again make sure it didn't become free while
+* we weren't looking.
+*/
+   if (ACCESS_ONCE(lock->tickets.head) == want) {
+   add_stats(TAKEN_SLOW_PICKUP, 1);
+   goto out;
+   }
+
+   /* Allow interrupts while blocked */
+   local_irq_restore(flags);
+

So what happens if an interrupt comes here and an interrupt handler
takes another spinlock that goes into the slow path? As far as I see
lock_waiting will become overwritten and cpu will be cleared from
waiting_cpus bitmap by nested kvm_lock_spinning(), so when halt is
called here after returning from the interrupt handler nobody is going
to wake this lock holder. Next random interrupt will "fix" it, but it
may be several milliseconds away, or never. We should probably check
if interrupt were enabled and call native_safe_halt() here.



Okay you mean something like below should be done.
if irq_enabled()
   native_safe_halt()
else
   halt()

It is been a complex stuff for analysis for me.

So in our discussion stack would looking like this.

spinlock()
   kvm_lock_spinning()
   <-- interrupt here
   halt()


 From the halt if we trace


It is to early to trace the halt since it was not executed yet. Guest
stack trace will look something like this:

spinlock(a)
   kvm_lock_spinning(a)
lock_waiting = a
set bit in waiting_cpus
 <-- interrupt here
 spinlock(b)
   kvm_lock_spinning(b)
 lock_waiting = b
 set bit in waiting_cpus
 halt()
 unset bit in waiting_cpus
 lock_waiting = NULL
  --> ret from interrupt
halt()

Now at the time of the last halt above lock_waiting == NULL and
waiting_cpus is empty and not interrupt it pending, so who will unhalt
the waiter?



Yes. if an interrupt occurs between
local_irq_restore() and halt(), this is possible. and since this is 
rarest of rare (possiility of irq entering slowpath and then no random 
irq to do spurious wakeup), we had never hit this problem in the past.


So I am,
1. trying to artificially reproduce this.

2. I replaced the halt with below code,
   if (arch_irqs_disabled())
halt();

and ran benchmarks.
But this results in degradation because, it means we again go back and 
spin in irq enabled case.


3. Now I am analyzing the performance overhead of safe_halt in irq 
enabled case.

  if (arch_irqs_disabled())
   halt();
  else
   safe_halt();

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] video: hx8357: Make IM pins optional

[Mike Galbraith]

On Tue, 2013-07-16 at 09:49 +0900, Jingoo Han wrote: 
> On Tuesday, July 16, 2013 12:27 AM, Maxime Ripard wrote:

> > +
> > +   ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> > +   GPIOF_OUT_INIT_LOW, 
> > "im_pins");
> 
> This makes a checkpatch warning such as 'WARNING: line over 80 characters'.
> How about the following?
> 
>   ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
>   GPIOF_OUT_INIT_LOW, "im_pins");

IIRC, some maintainers gripe (davem?) when they see such alignment,
preferring the original arg below arg alignment vs strict 80 column.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: splice vs execve lockdep trace.

[Dave Jones]

On Mon, Jul 15, 2013 at 08:25:14PM -0700, Linus Torvalds wrote:
 
 
 > And looking more at that, I'm actually starting to think this is an
 > XFS locking problem. XFS really should not call back to splice while
 > holding the inode lock.
 > 
 > But that XFS code doesn't seem new either. Is XFS a new thing for you
 > to test with?

I started pounding on it fairly recently and have shook out a number
of bugs (now fixed) since I started, so relatively new, but on the order of 
'months' now.

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ATTEND] How to act on LKML

[Li Zefan]

On 2013/7/16 6:08, Steven Rostedt wrote:
> On Mon, 2013-07-15 at 14:50 -0700, Linus Torvalds wrote:
>> On Mon, Jul 15, 2013 at 1:41 PM, Sarah Sharp
>>  wrote:
>>>
>>> Oh, FFS, I just called out on private email for "playing the victim
>>> card".  I will repeat: this is not just about me, or other minorities.
>>> I should not have to ask for professional behavior on the mailing lists.
>>> Professional behavior should be the default.
>>
>> Bullshit.
>>
> 
> Can we please make this into a Kernel Summit discussion. I highly doubt
> we would solve anything, but it certainly would be a fun segment to
> watch :-)
> 

Oh, I can name some kernel developers who I see are most friendly to other
developers, and you are one of them. ;)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] i2c-designware: Manually set RESTART bit between messages

[Chew, Chiau Ee]

On Wed, Jul 03, 2013 at 10:15:11PM +0200, Wolfram Sang wrote:
> 
> CCing Mika and Christian.
> 
> On Fri, Jun 21, 2013 at 03:05:28PM +0800, Chew Chiau Ee wrote:
> > From: Chew, Chiau Ee 
> > 
> > If both IC_EMPTYFIFO_HOLD_MASTER_EN and IC_RESTART_EN are set to 1, 
> > the Designware I2C controller doesn't generate RESTART unless user 
> > specifically requests it by setting RESTART bit in IC_DATA_CMD register.
> > 
> > Since IC_EMPTYFIFO_HOLD_MASTER_EN setting can't be detected from 
> > hardware register, we must always manually set the restart bit between 
> > messages.
> > 
> > Signed-off-by: Chew, Chiau Ee 
> 
> How come restart has worked before? Or did it not?

> It works fine. However IC_EMPTYFIFO_HOLD_MASTER_EN=1 makes a difference. We 
> had similar thing with the STOP that was fixed previously.

>If I understand the dw i2c databook right, RESTART is only issued if the 
>transfer direction changes. So if you have two or more consecutive transfers 
>that have the same direction (not sure how common that is) there is no RESTART 
>between them unless >DW_IC_CON_RESTART_EN is set.

>Chiau Ee, does this fix a real problem?

Yes, it fixed a problem in one of our use case. we have a use case whereby the 
control path of the audio codec is using I2C bus. During our validation based 
on that use case,  we observed there is issue with back-to-back message 
transfer if this fix is not being added.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] KS Topic request: Handling the Stable kernel, let's dump the cc: stable tag

[Dave Airlie]

On Tue, Jul 16, 2013 at 12:41 PM, Ben Hutchings  wrote:
> On Mon, 2013-07-15 at 22:09 -0400, Steven Rostedt wrote:
> [...]
>> > > How important is the stable releases? Are maintainers willing to do a
>> > > little more work now to make sure their subsystems work fine in older
>> > > kernels? This isn't the same stable as it was 8 years ago.
>> >
>> > And that annoys the hell out of some Linux companies who feel that the
>> > stable kernels compete with them.  So people working for those companies
>> > might not get as much help with doing any additional work for stable
>> > kernel releases (this is not just idle gossip, I've heard it directly
>> > from management's mouths.)
>>
>> Hmm, this is new to me. Really, I thought the whole point of the stable
>> releases was to help Linux companies.
> [...]
>
> I also heard some managers decided their kernel source packages should
> have all the patches squashed together to make them harder to cherry-
> pick... could it have been the same company?

Greg loves to tell stories about RH management, but really if he can
find any engineer who works for RH that says he can't work on stable
due to being told by management, I'd be surprised. Maybe when stable
first surfaced there was a hope of it being close to RHEL, but at this
point stable has little to no usefulness from a RHEL point of view,
and since nearly all the RH employed maintainers all do stable work, I
can't see why Greg would think this matters.

In fact Greg how much of stable queue does come from Red Hatters?

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: splice vs execve lockdep trace.

[Linus Torvalds]

On Mon, Jul 15, 2013 at 7:38 PM, Dave Jones  wrote:
>
>   The recent trinity changes shouldn't have really made
> any notable difference here.

Hmm. I'm not aware pf anything that has changed in this area since
3.10 - neither in execve, xfs or in splice. Not even since 3.9.

But I may certainly have missed something.

> Interestingly, the 'soft lockups' I was
> seeing all the time on that box seem to have gone into hiding.

Honestly, I'm somewhat inclined to blame the whole perf situation, and
saying that we hopefully got that fixed. In between the silly do_div()
buglets and all the indications that the time was spent in nmi
handlers, I'd be willing to just ignore them as false positives
brought on by the whole switch to the perf irq..

>  > Or is the XFS i_iolock required for this thing to happen at all?
>  > Adding Ben Myers to the cc just for luck/completeness.
>
> It is only happening (so far) on the XFS test box, but I don't have
> enough data to say that's definite yet.

.. so there's been a number of xfs changes, and I don't know the code,
but none of them seem at all relevant to this.

The "pipe -> cred_guard_mutex" lock chain is pretty direct, and can be
clearly attributed to splicing into /proc. Now, whether that is a
*good* idea or not is clearly debatable, and I do think that maybe we
should just not splice to/from proc files, but that doesn't seem to be
new, and I don't think it's necessarily *broken* per se, it's just
that splicing into /proc seems somewhat unnecessary, and various proc
files do end up taking locks that can be "interesting".

At the other end of the spectrum, the "cred_guard_mutex -> FS locks"
thing from execve() is also pretty clear, and probably not fixable or
necessarily something we'd even want to fix.

But the "FS locks -> pipe" part is a bit questionable. Honestly, I'd
be much happier if XFS used generic_file_splice_read/write().

And looking more at that, I'm actually starting to think this is an
XFS locking problem. XFS really should not call back to splice while
holding the inode lock.

But that XFS code doesn't seem new either. Is XFS a new thing for you
to test with?

Ben? Comments? I added the xfs list too now that I'm starting to
possibly blame XFS more actively..

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

[Aaron Lu]

On 07/15/2013 07:42 PM, Rafael J. Wysocki wrote:
> On Monday, July 15, 2013 10:36:15 AM Aaron Lu wrote:
>> On 07/13/2013 08:46 AM, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki 
>>>
>>> According to Matthew Garrett, "Windows 8 leaves backlight control up
>>> to individual graphics drivers rather than making ACPI calls itself.
>>> There's plenty of evidence to suggest that the Intel driver for
>>> Windows [8] doesn't use the ACPI interface, including the fact that
>>> it's broken on a bunch of machines when the OS claims to support
>>> Windows 8.  The simplest thing to do appears to be to disable the
>>> ACPI backlight interface on these systems".
>>>
>>> There's a problem with that approach, however, because simply
>>> avoiding to register the ACPI backlight interface if the firmware
>>> calls _OSI for Windows 8 may not work in the following situations:
>>>  (1) The ACPI backlight interface actually works on the given system
>>>  and the i915 driver is not loaded (e.g. another graphics driver
>>>  is used).
>>>  (2) The ACPI backlight interface doesn't work on the given system,
>>>  but there is a vendor platform driver that will register its
>>>  own, equally broken, backlight interface if not prevented from
>>>  doing so by the ACPI subsystem.
>>> Therefore we need to allow the ACPI backlight interface to be
>>> registered until the i915 driver is loaded which then will unregister
>>> it if the firmware has called _OSI for Windows 8 (or will register
>>> the ACPI video driver without backlight support if not already
>>> present).
>>>
>>> For this reason, introduce an alternative function for registering
>>> ACPI video, acpi_video_register_with_quirks(), that will check
>>> whether or not the ACPI video driver has already been registered
>>> and whether or not the backlight Windows 8 quirk has to be applied.
>>> If the quirk has to be applied, it will block the ACPI backlight
>>> support and either unregister the backlight interface if the ACPI
>>> video driver has already been registered, or register the ACPI
>>> video driver without the backlight interface otherwise.  Make
>>> the i915 driver use acpi_video_register_with_quirks() instead of
>>> acpi_video_register() in i915_driver_load().
>>>
>>> This change is based on earlier patches from Matthew Garrett,
>>> Chun-Yi Lee and Seth Forshee and Aaron Lu's comments.
>>>
>>> Signed-off-by: Rafael J. Wysocki 
>>
>> Reviewed-by: Aaron Lu 
>>
>> BTW, I also tested on a Toshiba laptop Z830 where its AML code
>> claims support of win8, the result is as expected: ACPI video
>> interface is removed, i915 Xorg driver picks intel_backlight.
>>
>> Thanks for the fix.
> 
> Cool, thanks for testing this!
> 
> Can you please also ask bug reporters in the BZ entires related to this to 
> test
> it too?

Sure.

To be clear, I actually tested the patch in your linux-next branch,
which turned out to be a little different in that you have fixed the
problem Igor raised here.

I'll ask reporters to test on a stable tree with the following two
patches on top:
https://patchwork.kernel.org/patch/2812951/ (expose OSI version)
https://patchwork.kernel.org/patch/2827793/ (your updated patch)
or your linux-next branch, whichever they like.

-Aaron

> 
> Rafael
> 
> 
>>> ---
>>>  drivers/acpi/internal.h |   11 ++
>>>  drivers/acpi/video.c|   65 
>>> 
>>>  drivers/acpi/video_detect.c |   21 
>>>  drivers/gpu/drm/i915/i915_dma.c |2 -
>>>  include/acpi/video.h|   11 ++
>>>  include/linux/acpi.h|1 
>>>  6 files changed, 103 insertions(+), 8 deletions(-)
>>>
>>> Index: linux-pm/drivers/acpi/video.c
>>> ===
>>> --- linux-pm.orig/drivers/acpi/video.c
>>> +++ linux-pm/drivers/acpi/video.c
>>> @@ -44,6 +44,8 @@
>>>  #include 
>>>  #include 
>>>  
>>> +#include "internal.h"
>>> +
>>>  #define PREFIX "ACPI: "
>>>  
>>>  #define ACPI_VIDEO_BUS_NAME"Video Bus"
>>> @@ -898,7 +900,7 @@ static void acpi_video_device_find_cap(s
>>> device->cap._DDC = 1;
>>> }
>>>  
>>> -   if (acpi_video_backlight_support()) {
>>> +   if (acpi_video_verify_backlight_support()) {
>>> struct backlight_properties props;
>>> struct pci_dev *pdev;
>>> acpi_handle acpi_parent;
>>> @@ -1854,6 +1856,46 @@ static int acpi_video_bus_remove(struct
>>> return 0;
>>>  }
>>>  
>>> +static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
>>> + void *context, void **rv)
>>> +{
>>> +   struct acpi_device *acpi_dev;
>>> +   struct acpi_video_bus *video;
>>> +   struct acpi_video_device *dev, *next;
>>> +
>>> +   if (acpi_bus_get_device(handle, &acpi_dev))
>>> +   return AE_OK;
>>> +
>>> +   if (acpi_match_device_ids(acpi_dev, video_device_ids))
>>> +   return AE_OK;
>>> +
>>> +   video =

linux-next: build failure after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

sound/soc/tegra/tegra_alc5632.c:16:28: fatal error: asm/mach-types.h: No such 
file or directory
 #include 
^

Caused by commit df7e4082f47d ("ASoC: tegra: Enable COMPILE_TEST
builds").  If you are going to do that, please test via (at least) an
x86_64 allmodconf build.  Including asm/mach-types.h is an architecture
dependency.

sound/soc/omap/omap-pcm.c: In function 'omap_pcm_preallocate_dma_buffer':
sound/soc/omap/omap-pcm.c:171:2: error: implicit declaration of function 
'dma_alloc_writecombine' [-Werror=implicit-function-declaration]
  buf->area = dma_alloc_writecombine(pcm->card->dev, size,
  ^
sound/soc/omap/omap-pcm.c:171:12: warning: assignment makes pointer from 
integer without a cast [enabled by default]
  buf->area = dma_alloc_writecombine(pcm->card->dev, size,
^
sound/soc/omap/omap-pcm.c: In function 'omap_pcm_free_dma_buffers':
sound/soc/omap/omap-pcm.c:195:3: error: implicit declaration of function 
'dma_free_writecombine' [-Werror=implicit-function-declaration]
   dma_free_writecombine(pcm->card->dev, buf->bytes,
   ^

Caused by commit 6109b2fca632 ("ASoC: omap: Enable COMPILE_TEST build for
DT platforms").  In this case, a missing include.

I have used the version of the sound-asoc tree from next-20130715 for
today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpaaLrK1Iqm2.pgp
Description: PGP signature

Re: [ATTEND] How to act on LKML (was: [ 00/19] 3.10.1-stable review)

[NeilBrown]

On Mon, 15 Jul 2013 20:17:30 -0400 Steven Rostedt  wrote:

> On Mon, 2013-07-15 at 16:15 -0700, Guenter Roeck wrote:
> >  
> > One thing you should keep in mind in your discussion is what can happen
> > if people get too polite with each other.
> > 
> > I have seen this happen at two large companies I worked for. Early on, 
> > flames
> > are acceptable and expected as response to someone publishing bad code which
> > breaks everything for everyone. Then, at some point, it is not acceptable
> > anymore to flame, and one is expected to be polite and friendly at all 
> > times.
> > "Your code breaks the build for every platform. Would you please kindly
> > consider fixing it ?"
> > Result is that code quality suffers, to the point where images don't even
> > build anymore.
> > 
> > I hope the Linux kernel never gets into that stage. To avoid that,
> > I am willing to be cursed at by Linus if I am the responsible party.
> 
> Didn't Jim Zemlin show some research where there were two groups:
> 
>  One that did a bunch of brain storming where no idea was a bad idea
> 
>  The other required you to defend your idea while the others bashed it.
> 
> The results always showed that the second group not only did a better
> job, but also faster and more efficient.
> 
> I'm afraid if we worry too much about politeness, we will fall into that
> first group.
> 

Surely there is an enormous difference between being required to defend your
position against rational and forceful argument, and being required to defend
it against irrelevant name calling.

NeilBrown


signature.asc
Description: PGP signature

Re: [ATTEND] How to act on LKML

[Steven Rostedt]

On Tue, 2013-07-16 at 03:43 +0100, Chris Ball wrote:
> Hi,

> I'd like other developers to treat me this way too, but perhaps a good
> way to get started is to first come up with a statement of how we'd
> like to treat others, and then start collecting signatories to it.
> Does that sound like a good idea?

"collecting signatories"? Like getting signatures from kids that say
they will remain virgins till they marry? In the end, they all end up
getting screwed.

No, we don't need any pact to sign. I'm not sure this is really that
much of an issue. Yes, Linus likes to rant, but that's basically his
trademark. There's a few other grumpy kernel developers that can be a
bit heavy handed too. But really, if you don't want to be cursed at,
here's some pretty easy instructions to follow.


1) Read what a maintainer tells you twice. If you are pointed to a
document, read that twice.

2) If you don't understand what the maintainer says, ask what he/she
meant.

3) Be honest! Don't try to pull that you know something that you really
don't.

4) If you change existing infrastructure. Prove that your change is
better. And not just on your box, on many other boxes. Post RFCs asking
others to test, and give feedback. Don't claim its better till the
numbers are in.

5) Don't be afraid to admit you don't know something. I find people that
tell you what they don't know have much more integrity than people that
keep telling you what they do know.

I don't see any kernel developer cursing at someone because they just
feel like cursing at someone. It's usually caused by someone not being
honest with themselves or the developers they are dealing with. Or
simply not listening to what they are being told.

Linus's point is that he wants to be honest, and cursing is his way of
giving you the most direct way to understand how he honestly feels.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 00/19] 3.10.1-stable review

[Li Zefan]

>> Sarah, first off, I don't have that many tools at hand. Secondly, I
>> simply don't believe in being polite or politically correct.
> 
> Bullshit.  I've seen you be polite, and explain to clueless maintainers
> why there's no way you can revert their merge that caused regressions,
> and ask them to fit it without resorting to tearing them down
> emotionally:
> 

As an asian, who are considered as much shyer than Western developers,
I don't see any attitute problem in Linus. But whenever I need to send
a patch to him, I tend to be more careful not to make mistakes.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH-v3 00/17] staging/lustre: fix various build issues

[Peng Tao]

On Tue, Jul 16, 2013 at 10:32 AM, Andrew Morton
 wrote:
> erk, I forgot about that.
>
> Please send Greg a full patchset against current Linus mainline.  Then,
> ideally, send me the patches which adapt that patchset to the new
> shrinker API.
>
> Or don't worry about the second part and I'll fix things up at my end.

The v3 patchset applies cleanly against current Linus mainline. Greg
please merge them if they are OK to you.

Andrew please just drop the fifth patch of the five. It is included in
the patchset sent to Greg. The other four are shrinker API patches and
can be applied cleanly. There is no conflict between the two patchsets
except for the fifth one ([patch 5/5] staging/lustre: replace
num_physpages with totalram_pages) that appears in both.

Thanks,
Tao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ATTEND] How to act on LKML

[Chris Ball]

Hi,

On Tue, Jul 16 2013, Darren Hart wrote:
> On Mon, 2013-07-15 at 15:36 -0700, Sarah Sharp wrote:
>> The people who want to work together in a civil manner should get
>> together and create a "Kernel maintainer's code of conduct" that
>> outlines what they expect from fellow kernel developers.  The people who
>> want to continue acting "unprofessionally" should document what
>> behaviors set off their cursing streaks, so that others can avoid that
>> behavior.  Somewhere in the middle is the community behavior all
>> developers can thrive in.
>> 
>> Some people won't agree with everything in that document.  The point is,
>> they don't have to agree.  They can read the document, figure out what
>> the community expects, and figure out whether they can modify their
>> behavior to match.  If they are unwilling to change, they simply don't
>> have to work with the developers who have signed it.
>> 
>> Perhaps a trusted third party could take a stab at a first draft of this
>> document?  Greg KH?  Steve Rostedt?  Darren Hart?
>
> [..]
> I do believe that someone from the intended audience of a document
> should be the one to write the first draft (or they should be among the
> reviewers if the authority drafts the document). For instance, I
> believe I would be able to document how to work with -tip or -stable as
> an individual contributor. I would not be a good candidate for writing
> the "how to be a lieutenant to Linus" because I am neither Linus nor
> one of his lieutenants.

Here's a simple statement that I hope many kernel developers would
sign up for -- I'd be happy to make it for the subsystem I maintain:

* If there's something wrong with your patch, I will critique the
  code respectfully, without personal attacks or public humiliation.

I'd like other developers to treat me this way too, but perhaps a good
way to get started is to first come up with a statement of how we'd
like to treat others, and then start collecting signatories to it.
Does that sound like a good idea?

Thanks,

- Chris.
-- 
Chris Ball  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/