[git pull] m68k updates for 3.12

[Geert Uytterhoeven]

Hi Linus,

The following changes since commit b36f4be3de1b123d8601de062e7dbfc904f305fb:

  Linux 3.11-rc6 (2013-08-18 14:36:53 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus

for you to fetch changes up to 55490050df0f5d82ce070be11351c65f7696101c:

  m68k/atari: ARAnyM - Always use physical addresses in NatFeat calls 
(2013-08-23 12:49:01 +0200)


Geert Uytterhoeven (2):
  m68k: Ignore disabled HSYNC interrupt on Atari for irqs_disabled()
  m68k/atari: ARAnyM - Always use physical addresses in NatFeat calls

Summary:
  - Kill harmless warning messages when running a multi-platform kernel on
Atari,
  - Correct virt/phys mixups that didn't actually hurt due to identity
mappings.

Thanks for pulling!

 arch/m68k/emu/natfeat.c  |   14 +++---
 arch/m68k/emu/nfblock.c  |4 ++--
 arch/m68k/emu/nfcon.c|8 +---
 arch/m68k/emu/nfeth.c|7 ---
 arch/m68k/include/asm/irqflags.h |4 
 5 files changed, 22 insertions(+), 15 deletions(-)

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: [PATCH] input: allow SERIO=m even without EXPERT=y

[Tom Gundersen]

On Mon, Sep 2, 2013 at 11:30 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
 On Mon, Sep 2, 2013 at 11:01 PM, richard -rw- weinberger
 richard.weinber...@gmail.com wrote:
 On Mon, Sep 2, 2013 at 8:47 PM, Tom Gundersen t...@jklm.no wrote:
 There is plenty of consumer hardware (e.g., mac books) that does not use
 AT keyboards or PS/2 mice. It therefore makes sense for distro kernels
 to build the related drivers as modules to avoid loading them on hardware
 that does not need them. As such, these options should no longer be 
 protected
 by EXPERT.

 Moreover, building these drivers as modules gets rid of the following ugly
 error during boot:

 [2.337745] i8042: PNP: No PS/2 controller found. Probing ports directly.
 [3.439537] i8042: No controller found

 Signed-off-by: Tom Gundersen t...@jklm.no
 Cc: Dmitry Torokhov dmitry.torok...@gmail.com
 ---
  drivers/input/keyboard/Kconfig | 4 ++--
  drivers/input/serio/Kconfig| 6 +++---
  2 files changed, 5 insertions(+), 5 deletions(-)

 diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
 index 269d4c3..2d31cec 100644
 --- a/drivers/input/keyboard/Kconfig
 +++ b/drivers/input/keyboard/Kconfig
 @@ -2,7 +2,7 @@
  # Input core configuration
  #
  menuconfig INPUT_KEYBOARD
 -   bool Keyboards if EXPERT || !X86
 +   bool Keyboards

 Maybe this a stupid question, but why are you dropping the !X86 too?

 Because the if EXPERT only mattered for X86.

 Apply De Morgan and it read like do not ask the question if !EXPERT  X86.

Precisely.

-t
--
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] checkpatch: Add warning about submitting patches using --file

[Joe Perches]

On Mon, 2013-09-02 at 23:37 +0300, Dan Carpenter wrote:
 On Mon, Sep 02, 2013 at 12:40:47PM -0700, Joe Perches wrote:
  +WARNING: When using --file mode, do not send patches that just make
  +whitespace or formatting changes unless more significant changes are
  +also made for other reasons in another patch.
  +
 
 This is a run on sentence.

Suggest alternatives.
I suppose are also made could be shortened.

 Also I don't agree with it.  Clean up
 patches are good on their own.

Try getting one past James stasis Bottomley.

 There are parts of the kernel which are
 not just in staging where I refuse to look at because it is so bad.

Me too.

 The problem is that people send clean up patches which don't clean up
 the code or which make the code worse than the original.

Maybe the only way to learn coding taste is to have
patches rejected.

 All they care
 about is pleasing checkpatch.pl instead of actually thinking about what
 they are doing.  The message should just say something like, Take a
 step back and think about if this actually improves things for human
 readers.

Maybe.  Suggest better text.


--
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] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Josh Triplett]

On Mon, Sep 02, 2013 at 09:50:23PM +0100, David Howells wrote:
 Josh Triplett j...@joshtriplett.org wrote:
 
   There are many checkpatch rules (like semicolons) that
   are not in CodingStyle.
  
  It's a rule of thumb, not a mandate.  In *general*, checkpatch.pl should
  not be enforcing style rules that aren't documented in CodingStyle.
 
 Except that it becomes a mandate when someone runs it automatically against
 every one of your patches and then sends you an email for each patch it finds
 a checkpatch niggle against...

I think we're talking about two different things.  I wasn't talking
about checkpatch.pl itself; I was talking about the idea that every
style rule in checkpatch.pl should corresponding documentation in
CodingStyle.  That's what I was calling a rule of thumb rather than a
mandate.

- Josh triplett
--
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] checkpatch: Report missing spaces around trigraphs with --strict

[Joe Perches]

Spaces around trigraphs are specified by CodingStyle
but checkpatch is currently silent about them because
there are many current instances without them.

Make missing spaces around trigraphs a --strict message.

Signed-off-by: Joe Perches j...@perches.com
---
 Oddly enough, the opposite is true as well. 3.1, spaces around binary
 and ternary operators, is for example not enforced, presumably because
 it would generate too many positives. Since I like that rule, I have
 my private version of checkpatch.pl which does check for it. After all,
 it _is_ a CodingStyle rule.

 scripts/checkpatch.pl | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9bb056c..bb34c11 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2817,7 +2817,7 @@ sub process {
\+=|-=|\*=|\/=|%=|\^=|\|=|=|
=|-|=|!|~|
|\|\||,|\^|\+\+|--||\||\+|-|\*|\/|%|
-   \?|:
+   \?:|\?|:
}x;
my @elements = split(/($ops|;)/, $opline);
 
@@ -3040,15 +3040,13 @@ sub process {
$ok = 1;
}
 
-   # Ignore ?:
-   if (($opv eq ':O'  $ca =~ /\?$/) ||
-   ($op eq '?'  $cc =~ /^:/)) {
-   $ok = 1;
-   }
-
+   # messages are ERROR, but ?: are CHK
if ($ok == 0) {
-   if (ERROR(SPACING,
- spaces required 
around that '$op' $at\n . $hereptr)) {
+   my $msg_type = \ERROR;
+   $msg_type = \CHK if (($op eq 
'?:' || $op eq '?' || $op eq ':')  $ctx =~ /VxV/);
+
+   if ({$msg_type}(SPACING,
+spaces 
required around that '$op' $at\n . $hereptr)) {
$good = 
rtrim($fix_elements[$n]) .   . trim($fix_elements[$n + 1]) .  ;
if (defined 
$fix_elements[$n + 2]) {

$fix_elements[$n + 2] =~ s/^\s+//;


--
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 1/1] staging/speakup/kobjects.c: Code improvement.

[Raphael S.Carvalho]

Well, there is no need to use strcmp since we can make a test of similar 
semantic by using the var_id field of param.
I moved the test into the VAR_NUM:VAR_TIME case since VAR_STRING will never be 
voice.

spk_xlate isn't used anymore (in line 628), then there is no difference between 
using cp and buf in VAR_STRING case.
Besides, buf is a const char and those changes remove one uneeded line.

I created the function spk_reset_default_value because it clarifies the code 
and allows code reusing.

Signed-off-by: Raphael S.Carvalho raphael.sc...@gmail.com
---
 drivers/staging/speakup/kobjects.c |   71 
 1 files changed, 39 insertions(+), 32 deletions(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index 51bdea3..5c6e77a 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -586,6 +586,25 @@ ssize_t spk_var_show(struct kobject *kobj, struct 
kobj_attribute *attr,
 EXPORT_SYMBOL_GPL(spk_var_show);
 
 /*
+ * Used to reset either default_pitch or default_vol.
+ */
+static inline void spk_reset_default_value(char *header_name,
+   int *synth_default_value, int idx)
+{
+   struct st_var_header *param;
+
+   if (synth  synth_default_value) {
+   param = spk_var_header_by_name(header_name);
+   if (param)  {
+   spk_set_num_var(synth_default_value[idx],
+   param, E_NEW_DEFAULT);
+   spk_set_num_var(0, param, E_DEFAULT);
+   pr_info(%s reset to default value\n, param-name);
+   }
+   }
+}
+
+/*
  * This function is called when a user echos a value to one of the
  * variable parameters.
  */
@@ -624,56 +643,44 @@ ssize_t spk_var_store(struct kobject *kobj, struct 
kobj_attribute *attr,
if (ret == -ERANGE) {
var_data = param-data;
pr_warn(value for %s out of range, expect %d to %d\n,
-   attr-attr.name,
+   param-name,
var_data-u.n.low, var_data-u.n.high);
}
+
+  /*
+   * If voice was just changed, we might need to reset our default
+   * pitch and volume.
+   */
+   if (param-var_id == VOICE) {
+   spk_reset_default_value(pitch, synth-default_pitch,
+   value);
+   spk_reset_default_value(vol, synth-default_vol,
+   value);
+   }
break;
case VAR_STRING:
-   len = strlen(buf);
-   if ((len = 1)  (buf[len - 1] == '\n'))
+   len = strlen(cp);
+   if ((len = 1)  (cp[len - 1] == '\n'))
--len;
-   if ((len = 2)  (buf[0] == '')  (buf[len - 1] == '')) {
-   ++buf;
+   if ((len = 2)  (cp[0] == '')  (cp[len - 1] == '')) {
+   ++cp;
len -= 2;
}
-   cp = (char *) buf;
cp[len] = '\0';
-   ret = spk_set_string_var(buf, param, len);
+   ret = spk_set_string_var(cp, param, len);
if (ret == -E2BIG)
pr_warn(value too long for %s\n,
-   attr-attr.name);
+   param-name);
break;
default:
pr_warn(%s unknown type %d\n,
param-name, (int)param-var_type);
break;
-   }
-   /*
-* If voice was just changed, we might need to reset our default
-* pitch and volume.
-*/
-   if (strcmp(attr-attr.name, voice) == 0) {
-   if (synth  synth-default_pitch) {
-   param = spk_var_header_by_name(pitch);
-   if (param)  {
-   spk_set_num_var(synth-default_pitch[value],
-   param, E_NEW_DEFAULT);
-   spk_set_num_var(0, param, E_DEFAULT);
-   }
-   }
-   if (synth  synth-default_vol) {
-   param = spk_var_header_by_name(vol);
-   if (param)  {
-   spk_set_num_var(synth-default_vol[value],
-   param, E_NEW_DEFAULT);
-   spk_set_num_var(0, param, E_DEFAULT);
-   }
-   }
-   }
+   }
spin_unlock_irqrestore(speakup_info.spinlock, flags);
 
if (ret == -ERESTART)
-   pr_info(%s reset to default value\n, attr-attr.name);
+   pr_info(%s reset to default value\n, param-name);

Re: Linux 3.11

[Nicholas A. Bellinger]

On Mon, 2013-09-02 at 14:10 -0700, Linus Torvalds wrote:
 As some people noticed, I got distracted (Ooh, look, a squirrel..)
 and never wrote an announcement for -rc7. My bad. But it wasn't
 actually all that interesting a release apart from the date, and it
 had a silly compile error in ohci-pci if you hadn't enabled
 CONFIG_PM_RUNTIME, so we'll just forget -rc7 ever happened, ok?
 Instead, go and get the real 3.11 release, which is out there, all
 shiny and ready to be compiled and loved.
 
 Since rc7 (ok, I lied, it happened) there's been just small fixes.
 Most of them came in from the networking tree, but there's some all
 over: some random filesystem fixes, a couple of sound fixes, a
 /proc/timer_list fix, things like that. Nothing really stands out
 (unless you happened to use the new soft-dirty code, that had a buglet
 that could really hurt), but let's hope we don't have some silly
 configuration that doesn't even compile this time around.
 
 Shortlog appended.
 

Hi Linus,

Unfortunately, this doesn't include the remaining target fixes for
v3.11:

Re: [GIT PULL -v2] target fixes for v3.11
http://marc.info/?l=linux-kernelm=137799048226191w=2

Is there a reason why these did not get PULLed..?

Thanks,

--nab

--
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/2] spi: delete premature free_irq

[Mark Brown]

On Mon, Sep 02, 2013 at 11:54:20AM +0200, Julia Lawall wrote:
 From: Julia Lawall julia.law...@lip6.fr
 
 Free_irq is not needed if there has been no request_irq.  Free_irq is
 removed from both the probe and remove functions.  The correct request_irq
 and free_irq appear to be in the add_host and remove_host functions in
 spi-dw.c.

Applied, thanks.


signature.asc
Description: Digital signature

RESEND: Generating interrupts from a USB device driver?

[Daniel Santos]

Hello guys.  I didn't get a response the last time so hopefully with 
3.11 out I'll get one this time.


I need to be able to generate interrupts from a USB device driver while 
servicing the complete() function of an interrupt URB. While I realize 
that this may seem strange, the purpose is for a USB to SPI/GPIO bridge 
chip (the MCP2210). When something happens on the remote device where a 
chip is expecting it's interrupt out pin to trigger an interrupt on some 
local (to the board) microcontroller, the MCP2210 instead receives that 
signal and communicates it to the host the next time it's queried. This 
is the interrupt that I need to, in effect propagate locally. Since my 
spi_master and gpio_chip are all functioning now, this is the last step 
to get one of my spi protocol drivers working correctly.


I've been reading up on Documentation/IRQ-domain.txt, but IRQ 
controllers are all new to me and there's a lot for me to learn, so I 
just want to make sure I'm going down the correct path. Is the correct 
method to create an IRQ domain with irq_domain_add_linear() or some 
such? I can figure it out eventually, but if somebody can point me in 
the right direction, it can save me a WHOLE lot of time.


Thanks in advance
Daniel

--
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: Linux 3.11

[Linus Torvalds]

On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:

 Unfortunately, this doesn't include the remaining target fixes for
 v3.11:

 Re: [GIT PULL -v2] target fixes for v3.11
 http://marc.info/?l=linux-kernelm=137799048226191w=2

 Is there a reason why these did not get PULLed..?

Very simple: I have no such email in my mailbox. I see the target
updates for v3.11-rc1 email (and I pulled that), and there is nothing
since.

I don't even have that mail in my lkml archives, much less as a private email.

I see neither youe -v2 PULL request nor the One more late v3.11
specific regression one. In fact, I see no emails from you at all
from Aug 31.

It may be that gmail hates you for some reason...

[ time passes ]

Yup. It's in my spam-box, with gmail helpfully telling me:

   Why is this message in Spam? We've found that lots of messages from
linux-iscsi.org are spam.  Learn more

so something is rotten in the state of linux-iscsi.org.

Recent messages from you were similarly tagged:

 [GIT PULL -v2] target fixes for 3.11
 Re: LIO FC Target
 Re: [GIT PULL] target fixes for v3.11-rc7

there might have been more. You might want to try to figure out why
gmail thinks that linux-iscsi.org is spammy.

Linus


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: RESEND: Generating interrupts from a USB device driver?

[Greg KH]

On Mon, Sep 02, 2013 at 05:46:58PM -0500, Daniel Santos wrote:
 Hello guys.  I didn't get a response the last time so hopefully with 
 3.11 out I'll get one this time.
 
 I need to be able to generate interrupts from a USB device driver while 
 servicing the complete() function of an interrupt URB.

No you don't :)

 While I realize that this may seem strange, the purpose is for a USB
 to SPI/GPIO bridge chip (the MCP2210). When something happens on the
 remote device where a chip is expecting it's interrupt out pin to
 trigger an interrupt on some local (to the board) microcontroller, the
 MCP2210 instead receives that signal and communicates it to the host
 the next time it's queried. This is the interrupt that I need to, in
 effect propagate locally. Since my spi_master and gpio_chip are all
 functioning now, this is the last step to get one of my spi protocol
 drivers working correctly.

Just pass the data up the spi stack in your interrupt endpoint handler.
No need to try to create a real interrupt.  There are other USB SPI
drivers that should give you the idea of how to do it.

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: [PATCH] checkpatch: Report missing spaces around trigraphs with --strict

[Josh Triplett]

On Mon, Sep 02, 2013 at 03:14:46PM -0700, Joe Perches wrote:
 Spaces around trigraphs are specified by CodingStyle
 but checkpatch is currently silent about them because
 there are many current instances without them.
 
 Make missing spaces around trigraphs a --strict message.
 
 Signed-off-by: Joe Perches j...@perches.com

Reviewed-by: Josh Triplett j...@joshtriplett.org

 --- a/scripts/checkpatch.pl
 +++ b/scripts/checkpatch.pl
 @@ -2817,7 +2817,7 @@ sub process {
   \+=|-=|\*=|\/=|%=|\^=|\|=|=|
   =|-|=|!|~|
   |\|\||,|\^|\+\+|--||\||\+|-|\*|\/|%|
 - \?|:
 + \?:|\?|:
   }x;

While you're poking at this bit of code, would you mind looking at why
it gives a false positive for spaces around '*' on my recent patch at
http://mid.gmane.org/20130901234251.GB25057@leaf ?  It appears to
mistake the '*' of a pointer for a multiply.

Thanks,
Josh Triplett
--
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/

[GIT PULL] hwmon updates for 3.12

[Guenter Roeck]

Hi Linus,

Please pull hwmon updates for Linux 3.12 from signed tag:

git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hwmon-for-linus

Thanks,
Guenter

--

The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8:

  Linux 3.11-rc5 (2013-08-11 18:04:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
tags/hwmon-for-linus

for you to fetch changes up to f060c658b820141f18abd7b71586d628464a03ea:

  hwmon: (htu21) Add Measurement Specialties HTU21D support (2013-08-29 
09:09:12 -0700)


New driver for HTU21D (humidity sensor)
Add support for Fam16h (Kabini) to k10temp
Add support for NCT6102D/6106D and NCT6791D to nct6775 driver
Add support for ADS1115 to ads1015 driver
Add support for hibernate to w83627ehf and nct6775 drivers
Some minor cleanups


Dan Carpenter (2):
  hwmon: (nct6775) Fix size of data-temp array
  hwmon: (adt7462) ADT7462_REG_VOLT_MAX() should return 0

Darrick J. Wong (1):
  hwmon: Change my email address.

David Bartley (1):
  hwmon: (nct6775) Add support for NCT6791D

Evgeniy Dushistov (1):
  hwmon: (ads1015) Add support for ADS1115

Guenter Roeck (7):
  hwmon: (coretemp) Atom CPUs don't support TjMax; no warning needed
  hwmon: (nct6775) Allocate attributes dynamically from templates
  hwmon: (nct6775) Support two SuperIO chips in the same system
  hwmon: (nct6775) Add support for NCT6102D/6106D
  hwmon: (nct6775) Add support for critical low/high temperature limits on 
NCT6106
  hwmon: (nct6775) Add support for beep attributes
  hwmon: (nct6775) Avoid using device platform data outside probe function

Harald Judt (2):
  hwmon: (nct6775) Add support for hibernate
  hwmon: (w83627ehf) Add support for hibernate

Jingoo Han (1):
  hwmon: use dev_get_platdata()

Wei Hu (1):
  hwmon: (k10temp) Add support for Fam16h (Kabini)

William Markezana (1):
  hwmon: (htu21) Add Measurement Specialties HTU21D support

 Documentation/hwmon/ads1015  |8 +-
 Documentation/hwmon/htu21|   46 +
 Documentation/hwmon/k10temp  |1 +
 drivers/hwmon/Kconfig|   18 +-
 drivers/hwmon/Makefile   |1 +
 drivers/hwmon/acpi_power_meter.c |4 +-
 drivers/hwmon/ads1015.c  |   27 +-
 drivers/hwmon/ads7828.c  |2 +-
 drivers/hwmon/adt7462.c  |8 +-
 drivers/hwmon/adt7470.c  |4 +-
 drivers/hwmon/coretemp.c |   14 +-
 drivers/hwmon/ds620.c|2 +-
 drivers/hwmon/f71805f.c  |2 +-
 drivers/hwmon/f71882fg.c |2 +-
 drivers/hwmon/f75375s.c  |3 +-
 drivers/hwmon/g762.c |2 +-
 drivers/hwmon/gpio-fan.c |2 +-
 drivers/hwmon/htu21.c|  199 +++
 drivers/hwmon/i5k_amb.c  |4 +-
 drivers/hwmon/ibmaem.c   |4 +-
 drivers/hwmon/ibmpex.c   |4 +-
 drivers/hwmon/ina2xx.c   |4 +-
 drivers/hwmon/it87.c |6 +-
 drivers/hwmon/k10temp.c  |3 +-
 drivers/hwmon/lm87.c |4 +-
 drivers/hwmon/max197.c   |2 +-
 drivers/hwmon/max6639.c  |2 +-
 drivers/hwmon/mcp3021.c  |7 +-
 drivers/hwmon/nct6775.c  | 2531 +++---
 drivers/hwmon/ntc_thermistor.c   |2 +-
 drivers/hwmon/pc87427.c  |4 +-
 drivers/hwmon/pmbus/pmbus_core.c |2 +-
 drivers/hwmon/s3c-hwmon.c|6 +-
 drivers/hwmon/sht15.c|4 +-
 drivers/hwmon/smsc47m1.c |4 +-
 drivers/hwmon/w83627ehf.c|   22 +-
 drivers/hwmon/w83627hf.c |6 +-
 drivers/misc/ics932s401.c|4 +-
 38 files changed, 1618 insertions(+), 1352 deletions(-)
 create mode 100644 Documentation/hwmon/htu21
 create mode 100644 drivers/hwmon/htu21.c


signature.asc
Description: Digital signature

[PATCH v2 3/4] mm/hwpoison: fix false report 2nd try page recovery

[Wanpeng Li]

If the page is poisoned by software inject w/ MF_COUNT_INCREASED flag, there
is a false report 2nd try page recovery which is not truth, this patch fix it
by report first try free buddy page recovery if MF_COUNT_INCREASED is set.

Before patch:

[  346.332041] Injecting memory failure at pfn 200010
[  346.332189] MCE 0x200010: free buddy, 2nd try page recovery: Delayed

After patch:

[  297.742600] Injecting memory failure at pfn 200010
[  297.742941] MCE 0x200010: free buddy page recovery: Delayed

Reviewed-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
 mm/memory-failure.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index b114570..6293164 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1114,8 +1114,10 @@ int memory_failure(unsigned long pfn, int trapno, int 
flags)
 * shake_page could have turned it free.
 */
if (is_free_buddy_page(p)) {
-   action_result(pfn, free buddy, 2nd try,
-   DELAYED);
+   if (flags  MF_COUNT_INCREASED)
+   action_result(pfn, free buddy, 
DELAYED);
+   else
+   action_result(pfn, free buddy, 2nd 
try, DELAYED);
return 0;
}
action_result(pfn, non LRU, IGNORED);
-- 
1.7.5.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 v2 4/4] mm/hwpoison: fix the lack of one reference count against poisoned page

[Wanpeng Li]

The lack of one reference count against poisoned page for hwpoison_inject w/o 
hwpoison_filter enabled result in hwpoison detect -1 users still referenced 
the page, however, the number should be 0 except the poison handler held one 
after successfully unmap. This patch fix it by hold one referenced count 
against 
poisoned page for hwpoison_inject w/ and w/o hwpoison_filter enabled.

Before patch:

[   71.902112] Injecting memory failure at pfn 224706
[   71.902137] MCE 0x224706: dirty LRU page recovery: Failed
[   71.902138] MCE 0x224706: dirty LRU page still referenced by -1 users

After patch:

[   94.710860] Injecting memory failure at pfn 215b68
[   94.710885] MCE 0x215b68: dirty LRU page recovery: Recovered

Reviewed-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
 mm/hwpoison-inject.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/hwpoison-inject.c b/mm/hwpoison-inject.c
index afc2daa..4c84678 100644
--- a/mm/hwpoison-inject.c
+++ b/mm/hwpoison-inject.c
@@ -20,8 +20,6 @@ static int hwpoison_inject(void *data, u64 val)
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
 
-   if (!hwpoison_filter_enable)
-   goto inject;
if (!pfn_valid(pfn))
return -ENXIO;
 
@@ -33,6 +31,9 @@ static int hwpoison_inject(void *data, u64 val)
if (!get_page_unless_zero(hpage))
return 0;
 
+   if (!hwpoison_filter_enable)
+   goto inject;
+
if (!PageLRU(p)  !PageHuge(p))
shake_page(p, 0);
/*
-- 
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/

[PATCH v2 1/4] mm/hwpoison: fix traverse hugetlbfs page to avoid printk flood

[Wanpeng Li]

madvise_hwpoison won't check if the page is small page or huge page and 
traverse 
in small page granularity against the range unconditional, which result in a 
printk 
flood MCE xxx: already hardware poisoned if the page is huge page. This patch 
fix 
it by increase compound_order(compound_head(page)) for huge page iterator.

Testcase:

#define _GNU_SOURCE
#include stdlib.h
#include stdio.h
#include sys/mman.h
#include unistd.h
#include fcntl.h
#include sys/types.h
#include errno.h

#define PAGES_TO_TEST 3
#define PAGE_SIZE   4096 * 512

int main(void)
{
char *mem;
int i;

mem = mmap(NULL, PAGES_TO_TEST * PAGE_SIZE,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | 
MAP_HUGETLB, 0, 0);

if (madvise(mem, PAGES_TO_TEST * PAGE_SIZE, MADV_HWPOISON) == -1)
return -1;

munmap(mem, PAGES_TO_TEST * PAGE_SIZE);

return 0;
}

Reviewed-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
 mm/madvise.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index 6975bc8..539eeb9 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -343,10 +343,11 @@ static long madvise_remove(struct vm_area_struct *vma,
  */
 static int madvise_hwpoison(int bhv, unsigned long start, unsigned long end)
 {
+   struct page *p;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
-   for (; start  end; start += PAGE_SIZE) {
-   struct page *p;
+   for (; start  end; start += PAGE_SIZE 
+   compound_order(compound_head(p))) {
int ret;
 
ret = get_user_pages_fast(start, 1, 0, p);
-- 
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/

[PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page

[Wanpeng Li]

Changelog:
 *v1 - v2: reverse PageTransHuge(page)  !PageHuge(page) check 

PageTransHuge() can't guarantee the page is transparent huge page since it 
return true for both transparent huge and hugetlbfs pages. This patch fix 
it by check the page is also !hugetlbfs page.

Before patch:

[  121.571128] Injecting memory failure at pfn 23a200
[  121.571141] MCE 0x23a200: huge page recovery: Delayed
[  140.355100] MCE: Memory failure is now running on 0x23a200

After patch:

[   94.290793] Injecting memory failure at pfn 23a000
[   94.290800] MCE 0x23a000: huge page recovery: Delayed
[  105.722303] MCE: Software-unpoisoned page 0x23a000

Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
 mm/memory-failure.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
 * worked by memory_failure() and the page lock is not held yet.
 * In such case, we yield to memory_failure() and make unpoison fail.
 */
-   if (PageTransHuge(page)) {
+   if (!PageHuge(page)  PageTransHuge(page)) {
pr_info(MCE: Memory failure is now running on %#lx\n, pfn);
return 0;
}
-- 
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: Linux 3.11

[Guenter Roeck]

On 09/02/2013 03:50 PM, Linus Torvalds wrote:

On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:


Unfortunately, this doesn't include the remaining target fixes for
v3.11:

Re: [GIT PULL -v2] target fixes for v3.11
http://marc.info/?l=linux-kernelm=137799048226191w=2

Is there a reason why these did not get PULLed..?


Very simple: I have no such email in my mailbox. I see the target
updates for v3.11-rc1 email (and I pulled that), and there is nothing
since.

I don't even have that mail in my lkml archives, much less as a private email.

I see neither youe -v2 PULL request nor the One more late v3.11
specific regression one. In fact, I see no emails from you at all
from Aug 31.

It may be that gmail hates you for some reason...

[ time passes ]

Yup. It's in my spam-box, with gmail helpfully telling me:

Why is this message in Spam? We've found that lots of messages from
linux-iscsi.org are spam.  Learn more

so something is rotten in the state of linux-iscsi.org.

Recent messages from you were similarly tagged:

  [GIT PULL -v2] target fixes for 3.11
  Re: LIO FC Target
  Re: [GIT PULL] target fixes for v3.11-rc7

there might have been more. You might want to try to figure out why
gmail thinks that linux-iscsi.org is spammy.



I don't think it has anything to do with linux-iscsi.org.
Possibly Nicholas' e-mail provider is not hosted in the US, meaning e-mail
sent through it can not be logged and examined by a certain US government 
agency.

I had the same experience; Google blocks all e-mail from my private provider
(located in Singapore). When asked by the provider, they claimed to know
nothing about it. No, my provider doesn't forward more spam than other 
providers,
and definitely less than, say, Yahoo.

I can only recommend for everyone to send pull requests through a gmail account.
If you set it up correctly, you can keep using your non-gmail source address
but still send it through a Google server. Just don't use it for anything else
unless you don't mind Big Brother listening in.

Guenter

--
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] checkpatch: Report missing spaces around trigraphs with --strict

[Joe Perches]

 would you mind looking at why
 it gives a false positive for spaces around '*' on my recent patch at
 http://mid.gmane.org/20130901234251.GB25057@leaf ?  It appears to
 mistake the '*' of a pointer for a multiply.

Looks like checkpatch thinks this should be a multiplication.

Try this:
---
 scripts/checkpatch.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9bb056c..e421b5e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3005,7 +3005,7 @@ sub process {
 $op eq '*' or $op eq '/' or
 $op eq '%')
{
-   if ($ctx =~ /Wx[^WCE]|[^WCE]xW/) {
+   if ($ctx =~ /Wx[^WCEB]|[^WCE]xW/) {
if (ERROR(SPACING,
  need consistent 
spacing around '$op' $at\n . $hereptr)) {
$good = 
rtrim($fix_elements[$n]) .   . trim($fix_elements[$n + 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/

[GIT PATCH] USB patches for 3.12-rc1

[Greg KH]

The following changes since commit b36f4be3de1b123d8601de062e7dbfc904f305fb:

  Linux 3.11-rc6 (2013-08-18 14:36:53 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-3.12-rc1

for you to fetch changes up to b9a1048137f4ae43ee90f61a3f34f0efe863cfeb:

  usbcore: fix incorrect type in assignment in descriptors_changed() 
(2013-08-30 18:50:43 -0700)


USB patches for 3.12-rc1

Here's the big USB driver pull request for 3.12-rc1

Lots of USB driver fixes and updates.  Nothing major, just the normal
xhci, gadget, and other driver changes.  Full details in the shortlog.

Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org


Al Cooper (1):
  usb: Add Device Tree support to XHCI Platform driver

Alan Stern (9):
  USB: remove redundant #if
  USB: simplify the interface of usb_get_status()
  USB: refactor code for enabling/disabling remote wakeup
  USB: handle LPM errors during device suspend correctly
  USB: EHCI: keep better track of resuming ports
  USB: EHCI: don't depend on hardware for tracking port resets and resumes
  USB: handle LPM errors during device suspend correctly
  USB: OHCI: Allow runtime PM without system sleep
  USB: fix build error when CONFIG_PM_SLEEP isn't enabled

Alexey Khoroshilov (1):
  usb: gadget: amd5536udc: unconditionally use GFP_ATOMIC in udc_queue()

Anatolij Gustschin (1):
  usb: phy: fix build breakage

Andrzej Pietrasiewicz (1):
  usb: gadget: configfs: keep a function if it is not successfully added

Andy Shevchenko (4):
  usbtmc: remove trailing spaces
  usbtmc: call pr_err instead of plain printk
  usbtmc: remove redundant braces
  usbtmc: convert to devm_kzalloc

Boris BREZILLON (4):
  usb: gadget: atmel_usba: prepare clk before calling enable
  USB: ohci-at91: add usb_clk for transition to common clk framework
  usb: gadget: at91_udc: add missing clk_put on fclk and iclk
  usb: gadget: at91_udc: add usb_clk for transition to common clk framework

Chen Wang (1):
  USB: usb-skeleton.c: add retry for nonblocking read

Dan Carpenter (6):
  USB: mos7720: use GFP_ATOMIC under spinlock
  usb: gadget: gadgetfs: use after free in dev_release()
  usb: gadget: gadgetfs: potential use after free in unbind()
  usb: phy: signedness bugs in suspend/resume functions
  usb: gadget: double unlocks on error in atmel_usba_start()
  dma: cppi41: off by one in desc_to_chan()

Daniel Mack (1):
  usb: ehci-mxc: check for pdata before dereferencing

David Daney (1):
  usb: Move definition of USB_EHCI_BIG_ENDIAN_MMIO et al. out side of the 
ifs.

Dmitry Kasatkin (2):
  xhci:prevent callbacks suppressed when debug is not enabled
  dev-core: fix build break when DEBUG is enabled

Fabio Estevam (4):
  usb: phy: phy-mxs-usb: Check the return value from stmp_reset_block()
  usb: chipidea: ci_hdrc_imx: remove unused variable 'res'
  usb: chipidea: move hw_phymode_configure() into probe
  usb: chipidea: remove previous MODULE_ALIAS

Felipe Balbi (32):
  usb: class: cdc-acm: be careful with bInterval
  usb: atm: speedtch: be careful with bInterval
  usb: clamp bInterval to allowed range
  usb: dwc3: make glue layers selectable
  usb: gadget: remove imx_udc
  usb: dwc3: gadget: don't request IRQs in atomic
  usb: dwc3: switch to GPL v2 only
  usb: phy: protect against NULL phy pointers
  usb: common: introduce of_usb_get_maximum_speed()
  usb: dwc3: let non-DT platforms pass tx-fifo-resize flag;
  usb: dwc3: make maximum-speed a per-instance attribute
  usb: dwc3: core: switch to snps,dwc3
  usb: dwc3: gadget: drop dwc3 manual phy control
  usb: dwc3: omap: switch over to devm_ioremap_resource()
  usb: dwc3: core: switch over to devm_ioremap_resource()
  usb: dwc3: gadget: move debugging print around
  usb: dwc3: gadget: move direction setting up
  usb: dwc3: gadget: add a debugging print when initializing endpoints
  usb: dwc3: core: don't redefine DWC3_DCFG_LPM_CAP
  usb: dwc3: gadget: don't enable LPM early
  usb: dwc3: core: introduce and use macros for Event Size register
  usb: dwc3: gadget: get rid of IRQF_ONESHOT
  usb: dwc3: gadget: rename dwc3_process_event_buf
  usb: dwc3: gadget: introduce dwc3_process_event_buf
  usb: gadget: udc-core: move sysfs_notify() to a workqueue
  usb: dwc3: ep0: only change to ADDRESS if set_config() succeeds
  usb: dwc3: ep0: don't change to configured state too early
  usb: of: fix build breakage caused by recent patches
  usb: dwc3: use dev_get_platdata()
  Merge branch 'nop-phy-rename' into next
  usb: musb: dsps: make it depend on OF_IRQ
  usb: dwc3: core: cope with NULL pdata

Feng-Hsin 

[GIT PATCH] char/misc patches for 3.12-rc1

[Greg KH]

The following changes since commit b36f4be3de1b123d8601de062e7dbfc904f305fb:

  Linux 3.11-rc6 (2013-08-18 14:36:53 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
tags/char-misc-3.12-rc1

for you to fetch changes up to 3cc1f95283a125cf54ccf1e25065321d4385133b:

  drivers: uio: Kconfig: add MMU dependancy for UIO (2013-08-30 14:19:46 -0700)


Char/Misc patches for 3.12-rc1

Here is the big char/misc driver pull request for 3.12-rc1

Lots of driver updates all over the char/misc tree, full details in the
shortlog below.

Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org


Alessandro Rubini (1):
  FMC: fix locking in sample chardev driver

Alexandru Juncu (1):
  pcmcia: synclink_cs: replace sum of bitmasks with OR operation.

Andy King (2):
  VMCI: Remove non-blocking/pinned queuepair support
  VMCI: Add support for virtual IOMMU

Chen Gang (2):
  drivers: parport: Kconfig: exclude h8300 for PARPORT_PC
  drivers: uio: Kconfig: add MMU dependancy for UIO

Greg Kroah-Hartman (5):
  misc: c2port: use dev_bin_attrs instead of hand-coding it
  Revert misc: c2port: use dev_bin_attrs instead of hand-coding it
  Merge 3.11-rc3 into char-misc-next.
  Merge tag 'extcon-next-for-3.12' of 
git://git.kernel.org/.../chanwoo/extcon into char-misc-next
  Merge 3.11-rc6 into char-misc-next

Heiko Stübner (1):
  misc: sram: fix error path in sram_probe

Jan-Simon Möller (1):
  misc: vmw_balloon: Remove braces to fix build for clang.

Jingoo Han (9):
  FMC: Staticize local symbols
  vme: vme_tsi148.c: add missing __iomem annotation
  vme: vme_ca91cx42.c: add missing __iomem annotation
  vme: vme_vmivme7805.c: add missing __iomem annotation
  parport: amiga: remove unnecessary platform_set_drvdata()
  uio: uio_pruss: remove unnecessary platform_set_drvdata()
  drivers: uio_dmem_genirq: use dev_get_platdata()
  drivers: uio_pruss: use dev_get_platdata()
  drivers: uio_pdrv_genirq: use dev_get_platdata()

K. Y. Srinivasan (4):
  Drivers: hv: util: Fix a bug in version negotiation code for util services
  Drivers: hv: balloon: Initialize the transaction ID just before sending 
the packet
  Drivers: hv: vmbus: Fix a bug in the handling of channel offers
  Drivers: hv: vmbus: Do not attempt to negoatiate a new version prematurely

Kees Cook (4):
  lkdtm: fix stack protector trigger
  lkdtm: add WARNING trigger
  lkdtm: add SPINLOCKUP trigger
  lkdtm: add EXEC_* triggers

Kishon Vijay Abraham I (3):
  extcon: Add an API to get extcon device from dt node
  usb: dwc3: use extcon fwrk to receive connect/disconnect
  extcon: palmas: remove assigning edev.name to palmas

Laxman Dewangan (6):
  extcon: palmas: rename device tree binding matching with file name
  extcon: palmas: devicetree: remove non-require property details
  extcon: palmas: remove unused member from palams_usb structure
  extcon: palmas: enable ID_GND and ID_FLOAT detection always
  extcon: palams: add support for suspend/resume
  extcon: palmas: Option to disable ID/VBUS detection based on platform

Mark Brown (3):
  extcon: arizona: Use power efficient workqueue
  extcon: gpio: Use power efficient workqueue for debounce
  extcon: adc-jack: Use power efficient workqueue

Mark Rusk (1):
  drivers/misc/hpilo: Correct panic when an AUX iLO is detected

Michal Simek (1):
  uio: Remove uio_pdrv and use uio_pdrv_genirq instead

Olaf Hering (7):
  Drivers: hv: remove HV_DRV_VERSION
  Tools: hv: fix send/recv buffer allocation
  Tools: hv: check return value of daemon to fix compiler warning.
  Tools: hv: in kvp_set_ip_info free mac_addr right after usage
  Tools: hv: check return value of system in hv_kvp_daemon
  Tools: hv: correct payload size in netlink_send
  Tools: hv: use full nlmsghdr in netlink_send

Oleksandr Kozaruk (1):
  drivers: misc: ti-st: fix potential race if st_kim_start fails

Rostislav Lisovy (1):
  drivers: uio: Add driver for Humusoft MF624 DAQ PCI card

Tomas Hozza (3):
  tools: hv: Improve error logging in VSS daemon.
  tools: hv: Check return value of poll call
  tools: hv: Check return value of setsockopt call

Tomas Winkler (4):
  mei: wake also writers on reset
  mei: bus: do not overflow the device name buffer
  mei: don't get stuck in select during reset
  mei: me: fix hardware reset flow

Uwe Kleine-König (3):
  mm: make generic_access_phys available for modules
  uio: provide vm access to UIO_MEM_PHYS maps
  uio: drop unused vma_count member in uio_device struct

Wei Yongjun (1):
  vme: vme_ca91cx42.c: fix to pass correct device identity to free_irq()

Wolfram Sang (1):
  

[GIT PATCH] Driver core patches for 3.12-rc1

[Greg KH]

The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095:

  Linux 3.11-rc3 (2013-07-28 20:53:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ 
tags/driver-core-3.12-rc1

for you to fetch changes up to 1f153c02f5856ec109fa532eb5f31c39f85c:

  firmware loader: fix pending_fw_head list corruption (2013-08-30 12:04:27 
-0700)


Driver core patches for 3.12-rc1

Here's the big driver core pull request for 3.12-rc1.

Lots of tiny changes here fixing up the way sysfs attributes are
created, to try to make drivers simpler, and fix a whole class race
conditions with creations of device attributes after the device was
announced to userspace.

All the various pieces are acked by the different subsystem maintainers.

Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org


David Graham White (1):
  drivers:base:core: Moved sym export macros to respective functions

Geert Uytterhoeven (1):
  Kconfig: Remove hotplug enable hints in CONFIG_KEXEC help texts

Greg KH (2):
  ACPI: bgrt: take advantage of binary sysfs groups
  firmware: dcdbas: use binary attribute groups

Greg Kroah-Hartman (92):
  misc: c2port: use dev_bin_attrs instead of hand-coding it
  bsr: convert bsr_class to use dev_groups
  tile: srom: convert srom_class to use dev_groups
  c2port: convert class code to use dev_groups
  enclosure: convert class code to use dev_groups
  UIO: convert class code to use dev_groups
  staging: comedi: convert class code to use dev_groups
  c2port: convert class code to use bin_attrs in groups
  char: tile-srom: fix build error
  dma: convert dma_devclass to use dev_groups
  extcon: convert extcon_class to use dev_groups
  SCSI: OSD: convert class code to use dev_groups
  video: backlight: convert class code to use dev_groups
  video: backlight: lcd: convert class code to use dev_groups
  net: wireless: convert class code to use dev_groups
  net: rfkill: convert class code to use dev_groups
  ISDN: convert class code to use dev_groups
  leds: convert class code to use dev_groups
  PTP: convert class code to use dev_groups
  cuse: convert class code to use dev_groups
  net: core: convert class code to use dev_groups
  net: ieee802154: convert class code to use dev_groups
  Merge 3.11-rc3 into driver-core-next
  rtc: convert class code to use dev_groups
  driver core: bus_type: add dev_groups
  driver core: bus_type: add drv_groups
  driver core: bus_type: add bus_groups
  mips: convert vpe_class to use dev_groups
  devfreq: convert devfreq_class to use dev_groups
  HID: roccat: convert class code to use dev_groups
  v4l2: convert class code to use dev_groups
  x86: wmi: convert class code to use dev_groups
  PPS: convert class code to use dev_groups
  backing-dev: convert class code to use dev_groups
  hid: roccat-arvo: convert class code to use bin_attrs in groups
  hid: roccat-isku: convert class code to use bin_attrs in groups
  hid: roccat-kone: convert class code to use bin_attrs in groups
  hid: roccat-savu: convert class code to use bin_attrs in groups
  hid: roccat-koneplus: convert class code to use bin_attrs in groups
  hid: roccat-konepure: convert class code to use bin_attrs in groups
  hid: roccat-kovaplus: convert class code to use bin_attrs in groups
  hid: roccat-kone: fix off-by-one bug in attributes
  sysfs.h: fix __BIN_ATTR_RW()
  hid: roccat-pyra: convert class code to use bin_attrs in groups
  sysfs: add sysfs_create/remove_groups()
  sysfs: group.c: move EXPORT_SYMBOL_GPL() to the proper location
  sysfs: group.c: fix trailing whitespace
  sysfs: group.c: fix up some * coding style issues
  sysfs: group.c: fix up broken string coding style
  sysfs: group.c: add kerneldoc for sysfs_remove_group
  sysfs: group: update copyright to add myself and the LF
  sysfs: fix placement of EXPORT_SYMBOL()
  sysfs: remove trailing whitespace
  sysfs: fix up space coding style issues
  sysfs: fix up 80 column coding style issues
  sysfs: fix up uaccess.h coding style warnings
  sysfs: dir.c: fix up odd do/while indentation
  sysfs: file.c: fix up broken string warnings
  sysfs: sysfs.h: fix coding style issues
  sysfs: fix up minor coding style issues in sysfs.h
  acpi: bgrt: fix build error due to attribute change
  sysfs: group.c: fix up kerneldoc
  sysfs.h: remove attr_name() macro
  w1: remove race with sysfs file creation
  w1: use default attribute groups for w1 slave devices
  w1: add attribute groups to struct w1_family_ops
  w1: slaves: w1_therm: convert to use w1_family_ops.groups
  w1: slaves: 

[GIT PATCH] TTY/Serial patches for 3.12-rc1

[Greg KH]

The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:

  Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ 
tags/tty-3.12-rc1

for you to fetch changes up to 2d1d3f3ae985ec5676fb56ff2c7acad2e1c4e6eb:

  hvc_xen: Remove unnecessary __GFP_ZERO from kzalloc (2013-08-30 14:11:28 
-0700)


TTY/Serial driver patches for 3.12-rc1

Here's the big tty/serial driver pull request for 3.12-rc1.

Lots of n_tty reworks to resolve some very long-standing issues, removing the
3-4 different locks that were taken for every character.  This code has been
beaten on for a long time in linux-next with no reported regressions.

Other than that, a range of serial and tty driver updates and revisions.  Full
details in the shortlog.

Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org


Aldo Iljazi (1):
  Drivers: tty: n_gsm.c: fixed 7 errors  6 warnings that checkpatch 
complained

Alexander Shiyan (8):
  serial: max310x: Driver rework
  serial: max310x: Add MAX3109 support
  serial: max310x: Add MAX14830 support
  serial: max310x: Fix dev_pm_ops
  serial: sccnxp: Disable regulator on error
  serial: sccnxp: Using CLK API for getting UART clock
  serial: sccnxp: Using structure for each supported IC instead of switch 
in probe
  serial: sccnxp: Add DT support

Alexandru Juncu (1):
  TTY: synclink: replace bitmasks add operation with OR operation.

Andreas Bießmann (1):
  register_console: prevent adding the same console twice

Andreas Platschek (1):
  tty: Remove dead code

Axel Lin (2):
  serial: fsl_lpuart: Return proper error on lpuart_serial_init error path
  serial: bfin_uart: Remove redundant testing for ifdef 
CONFIG_SERIAL_BFIN_MODULE

Barry Song (2):
  serial: sirf: add support for Marco chip
  serial: sirf: drop redundant pinctrl_get_select_default as pinctrl core 
does it

Christophe Leroy (1):
  tty: serial: cpm_uart: Adding proper request of GPIO used by cpm_uart 
driver

Clemens Ladisch (1):
  vt: make the default color configurable

Dan Carpenter (1):
  serial: icom: move array overflow checks earlier

Daniel Mack (1):
  tty: serial: pxa: remove old cruft

Darren Hart (3):
  pch_uart: Use DMI interface for board detection
  serial: pch_uart: Remove __initdata annotation from dmi_table
  serial: pch_uart: Fix signed-ness and casting of uartclk related fields

Dmitry Fink (1):
  OMAP: UART: Keep the TX fifo full when possible

Elen Song (8):
  serial: at91: correct definition from DMA to PDC
  serial: at91: use function pointer to choose pdc or pio
  serial: at91: add tx dma support
  serial: at91: add rx dma support
  serial: at91: support run time switch transfer mode
  serial: at91: distinguish usart and uart
  serial: at91: make UART support dma and pdc transfers
  serial: at91: add dma support in usart binding descriptions

Fabio Estevam (1):
  serial: amba-pl011: Use __releases/__acquires annotations

Gabor Juhos (6):
  tty: ar933x_uart: convert to use devm_* functions
  tty: ar933x_uart: use the clk API to get the uart clock
  tty: ar933x_uart: remove superfluous assignment of ar933x_uart_driver.nr
  tty: ar933x_uart: use config_enabled() macro to clean up ifdefs
  tty: ar933x_uart: allow to build the driver as a module
  tty: ar933x_uart: add device tree support and binding documentation

Govindraj.R (1):
  OMAP2+: UART: enable tx wakeup bit for wer reg

Greg Kroah-Hartman (5):
  Merge 3.11-rc3 into tty-next
  Revert serial: sccnxp: Add DT support
  Merge 3.11-rc4 into tty-next
  Revert serial: omap: Fix IRQ handling return value
  Revert OMAP: UART: Keep the TX fifo full when possible

Grygorii Strashko (1):
  serial: omap: enable PM runtime only when its fully configured

Hendrik Brueckner (2):
  tty/hvc_console: Add DTR/RTS callback to handle HUPCL control
  tty/hvc_iucv: Disconnect IUCV connection when lowering DTR

Huang Shijie (7):
  serial: imx: remove the uart_console() check
  serial: imx: distinguish the imx6q uart from the others
  serial: imx: add DMA support for imx6q
  serial: mxs: enable the DMA only when the RTS/CTS is valid
  serial: mxs: remove the MXS_AUART_DMA_CONFIG
  ARM: dts: imx28-evk: add the RTS/CTS property for auart0
  serial: imx: initialize the local variable

Hubert Feurstein (1):
  serial/imx: fix custom-baudrate handling

Ian Abbott (4):
  pci_ids.h: move PCI_VENDOR_ID_AMCC here
  serial: 8250_pci: replace PCI_VENDOR_ID_ADDIDATA_OLD
  serial: 8250_pci: use local device ID for ADDI-DATA APCI-7800
  pci_ids.h: remove PCI_VENDOR_ID_ADDIDATA_OLD and 
PCI_DEVICE_ID_ADDIDATA_APCI7800

Jingoo 

[PATCH v4 1/1 resend] i2c: rcar: modify I2C driver

[Nguyen Viet Dung]

This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2.

Signed-off-by: Nguyen Viet Dung nv-d...@jinso.co.jp
---
 drivers/i2c/busses/i2c-rcar.c |   35 +--
 1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 0fc5858..32ec693 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -101,6 +101,11 @@ enum {
 #define ID_ARBLOST (1  3)
 #define ID_NACK(1  4)
 
+enum rcar_i2c_type {
+   I2C_RCAR_H1,
+   I2C_RCAR_H2,
+};
+
 struct rcar_i2c_priv {
void __iomem *io;
struct i2c_adapter adap;
@@ -113,6 +118,7 @@ struct rcar_i2c_priv {
int irq;
u32 icccr;
u32 flags;
+   enum rcar_i2c_type  devtype;
 };
 
 #define rcar_i2c_priv_to_dev(p)((p)-adap.dev.parent)
@@ -224,12 +230,25 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv 
*priv,
u32 scgd, cdf;
u32 round, ick;
u32 scl;
+   u32 cdf_width;
 
if (!clkp) {
dev_err(dev, there is no peripheral_clk\n);
return -EIO;
}
 
+   switch (priv-devtype) {
+   case I2C_RCAR_H1:
+   cdf_width = 2;
+   break;
+   case I2C_RCAR_H2:
+   cdf_width = 3;
+   break;
+   default:
+   dev_err(dev, device type error\n);
+   return -EIO;
+   }
+
/*
 * calculate SCL clock
 * see
@@ -245,7 +264,7 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv 
*priv,
 * clkp : peripheral_clk
 * F[]  : integer up-valuation
 */
-   for (cdf = 0; cdf  4; cdf++) {
+   for (cdf = 0; cdf  (1  cdf_width); cdf++) {
ick = clk_get_rate(clkp) / (1 + cdf);
if (ick  2000)
goto ick_find;
@@ -287,7 +306,7 @@ scgd_find:
/*
 * keep icccr value
 */
-   priv-icccr = (scgd  2 | cdf);
+   priv-icccr = (scgd  (cdf_width) | cdf);
 
return 0;
 }
@@ -632,6 +651,9 @@ static int rcar_i2c_probe(struct platform_device *pdev)
bus_speed = 10; /* default 100 kHz */
if (pdata  pdata-bus_speed)
bus_speed = pdata-bus_speed;
+
+   priv-devtype = platform_get_device_id(pdev)-driver_data;
+
ret = rcar_i2c_clock_calculate(priv, bus_speed, dev);
if (ret  0)
return ret;
@@ -686,6 +708,14 @@ static int rcar_i2c_remove(struct platform_device *pdev)
return 0;
 }
 
+static struct platform_device_id rcar_i2c_id_table[] = {
+   { i2c-rcar,   I2C_RCAR_H1 },
+   { i2c-rcar_h1,I2C_RCAR_H1 },
+   { i2c-rcar_h2,I2C_RCAR_H2 },
+   {},
+};
+MODULE_DEVICE_TABLE(platform, rcar_i2c_id_table);
+
 static struct platform_driver rcar_i2c_driver = {
.driver = {
.name   = i2c-rcar,
@@ -693,6 +723,7 @@ static struct platform_driver rcar_i2c_driver = {
},
.probe  = rcar_i2c_probe,
.remove = rcar_i2c_remove,
+   .id_table   = rcar_i2c_id_table,
 };
 
 module_platform_driver(rcar_i2c_driver);
-- 
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 v4 0/1 resend] ARM: shmobile: r8a7790: add I2C support

[Nguyen Viet Dung]

Hi Wolfram
CC Morimoto

Please consider the following patch for the r8a7790 Soc.
This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2.
It was developed base on the renesas-devel-20130722 branch and
have tested on the Lager board.

Thanks,
Nguyen viet Dung

Nguyen Viet Dung (1):
  i2c: rcar: modify I2C driver

 drivers/i2c/busses/i2c-rcar.c |   35 +--
 1 file changed, 33 insertions(+), 2 deletions(-)

-- 
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/

Re: [PATCH] [BUGFIX] crash/ioapic: Prevent crash_kexec() from deadlocking of ioapic_lock

[Eric W. Biederman]

Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com writes:

 Hi Eric and Don,

 Sorry for the late reply.

 (2013/08/31 9:58), Eric W. Biederman wrote:
 Don Zickus dzic...@redhat.com writes:
 
 On Tue, Aug 27, 2013 at 12:41:51PM +0900, Yoshihiro YUNOMAE wrote:
 Hi Don,

 Sorry for the late reply.

 (2013/08/22 22:11), Don Zickus wrote:
 On Thu, Aug 22, 2013 at 05:38:07PM +0900, Yoshihiro YUNOMAE wrote:
 So, I agree with Eric, let's remove the disable_IO_APIC() stuff and keep
 the code simpler.

 Thank you for commenting about my patch.
 I didn't know you already have submitted the patches for this deadlock
 problem.

 I can't answer definitively right now that no problems are induced by
 removing disable_IO_APIC(). However, my patch should be work well (and
 has already been merged to -tip tree). So how about taking my patch at
 first, and then discussing the removal of disabled_IO_APIC()?

 It doesn't matter to me.  My orignal patch last year was similar to yours
 until it was suggested that we were working around a problem which was we
 shouldn't touch the IO_APIC code on panic.  Then I wrote the removal of
 disable_IO_APIC patch and did lots of testing on it.  I don't think I have
 seen any issues with it (just the removal of disabling the lapic stuff).

 Yes, you really did a lot of testing about this problem according to
 your patch(https://lkml.org/lkml/2012/1/31/391). Although you
 said jiffies calibration code does not need the PIT in
 http://lists.infradead.org/pipermail/kexec/2012-February/006017.html,
 I don't understand yet why we can remove disable_IO_APIC.
 Would you please explain about the calibration codes?

 I forgot a lot of this, Eric B. might remember more (as he was the one that
 pointed this out initially).  I believe initially the io_apic had to be in
 a pre-configured state in order to do some early calibration of the timing
 code.  Later on, it was my understanding, that the calibration of various
 time keeping stuff did not need the io_apic in a correct state.  The code
 might have switched to tsc instead of PIT, I forget.
 
 Yes.  Alan Coxe's initial SMP port had a few cases where it still
 exepected the system to be in PIT mode during boot and it took us a
 decade or so before those assumptions were finally expunged.

 Would you please tell me the commit ID or the hint like files,
 functions, or when?

The short version is last time we tilted at this windmill the only
problem we could find was nmi's caused by the nmi watchdog.

So as a bug work-around all we need to retain is disabling the nmi
watchdog in crash-kexec.

 Then again looking at the output of the latest dmesg, it seems the IO APIC
 is initialized way before the tsc is calibrated.  So I am not sure what
 needed to get done or what interrupts are needed before the IO APIC gets
 initialized.
 
 The practical issue is that jiffies was calibrated off of the PIT timer
 if I recall.  But that is all old news.

 Are the jiffies calibration codes calibrate_delay()?
 It seems that the jiffies calibration have not used PIT in 2005
 according to 8a9e1b0.

Exactly.  That was the original reason why we put in the code to
disable the IOAPIC and the local apic.  There might have been other
reasons but that was the primary.

 By the way, can we remove disable_IO_APIC even if an old dump capture
 kernel is used?

 Good question.  I did a bunch of testing with RHEL-6 too, which is 2.6.32
 based.  But I think we added some IRR fixes (commit 1e75b31d638), which
 may or may not have helped in this case.  So I don't know when a kernel
 started worked correctly during init (with the right changes).  I believe
 2.6.32 had everything.
 
 A sufficient old and buggy dump capture kernel will fail because of bugs
 in it's startup path, but I don't think anyone cares.

 OK, if the jiffies calibration problem has been fixed in the old days,
 we don't need to care for the old kernel.

Exactly.  There may have been one or two other silly assumptions and to
the best of our knowledge all of those have been purged except the
assumption that an NMI watchdog won't happen between kernels and while
booting the kernel.

 The kernel startup path has been fixed for years, and disable_IO_APIC in
 crash_kexec has always been a bug work-around for deficiencies in the
 kernel's start up path (not part of the guaranteed interface).
 Furthermore every real system configuration I have encountered used the
 same kernel version for the crashdump kernel and the production kernel.
 So we should be good.

 We also will be use the kdump(crashdump) kernel as the production
 kernel. Should I only care for the current kernel?

For this particular issue yes.

In general it is important for there to be a stable interface between
the two kernels just so you are not required to use the same kernel
version, and so there is the possibility of using something besides a
linux kernel.

At the same time it has always been the targets kernel's responsibility
to sort out the hardware 

Re: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page

[Naoya Horiguchi]

On Tue, Sep 03, 2013 at 07:36:44AM +0800, Wanpeng Li wrote:
 Changelog:
  *v1 - v2: reverse PageTransHuge(page)  !PageHuge(page) check 
 
 PageTransHuge() can't guarantee the page is transparent huge page since it 
 return true for both transparent huge and hugetlbfs pages. This patch fix 
 it by check the page is also !hugetlbfs page.
 
 Before patch:
 
 [  121.571128] Injecting memory failure at pfn 23a200
 [  121.571141] MCE 0x23a200: huge page recovery: Delayed
 [  140.355100] MCE: Memory failure is now running on 0x23a200
 
 After patch:
 
 [   94.290793] Injecting memory failure at pfn 23a000
 [   94.290800] MCE 0x23a000: huge page recovery: Delayed
 [  105.722303] MCE: Software-unpoisoned page 0x23a000
 
 Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com

Thanks!

Reviewed-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com

 ---
  mm/memory-failure.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/mm/memory-failure.c b/mm/memory-failure.c
 index e28ee77..b114570 100644
 --- a/mm/memory-failure.c
 +++ b/mm/memory-failure.c
 @@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
 - if (PageTransHuge(page)) {
 + if (!PageHuge(page)  PageTransHuge(page)) {
   pr_info(MCE: Memory failure is now running on %#lx\n, pfn);
   return 0;
   }
 -- 
 1.8.1.2
 
 --
 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: a href=mailto:d...@kvack.org; em...@kvack.org /a

--
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] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Shilong Wang]

2013/9/3 Joe Perches j...@perches.com:
 On Mon, 2013-09-02 at 21:50 +0100, David Howells wrote:
 Josh Triplett j...@joshtriplett.org wrote:

   There are many checkpatch rules (like semicolons) that
   are not in CodingStyle.
 
  It's a rule of thumb, not a mandate.  In *general*, checkpatch.pl should
  not be enforcing style rules that aren't documented in CodingStyle.

 Except that it becomes a mandate when someone runs it automatically against
 every one of your patches and then sends you an email for each patch it finds
 a checkpatch niggle against...

Agree with this..
But using checkpatch.pl, i found there are *so many* patches that have
warnings or errors.

As far as i know, patches with checkpatch.pl's errors should be
avoided  at least unless
there is a *bug* in checkpatch.pl!


 I think that any robot sending such checkpatch-only
 emails should be disabled.

 I know of 2 email robots.

 Fengguang Wu's very useful build robot
 sends out emails on build failures.
 I think that's great.

 Wang Shilong wangshilong1...@gmail.com
 sent me an automated checkpatch email I
 thought was not useful.

I am sorry if i give you any trouble, i have disabled it(in fact, it
only has run for a day!)

Thanks,
wang

 Does anyone know of other checkpatch robots?


--
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: linux 3.11

[Juan Barry Manuel Canham]

I noticed that linux-iscsi.org isn't doing much to protect itself from being 
used as a spam source. If you setup the following you should be less likely to 
be marked as spam:

* SPF record (setup both spf and a txt spf record for compatibility) 
* DMARC record to enforce SPF and allow servers to contact you when linux-
iscsi.org is used as a spam source
* DKIM - more work and probably not needed, but I suspect having valid dkim 
signatures will help with some mail servers spam rankings 

Apologies as this isn't really Linux kernel related stuff but it might help 
other developers avoid being spammed by gmail too.
--
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] checkpatch: Report missing spaces around trigraphs with --strict

[Josh Triplett]

On Mon, Sep 02, 2013 at 04:54:25PM -0700, Joe Perches wrote:
  would you mind looking at why
  it gives a false positive for spaces around '*' on my recent patch at
  http://mid.gmane.org/20130901234251.GB25057@leaf ?  It appears to
  mistake the '*' of a pointer for a multiply.
 
 Looks like checkpatch thinks this should be a multiplication.
 
 Try this:
 ---
  scripts/checkpatch.pl | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
 index 9bb056c..e421b5e 100755
 --- a/scripts/checkpatch.pl
 +++ b/scripts/checkpatch.pl
 @@ -3005,7 +3005,7 @@ sub process {
$op eq '*' or $op eq '/' or
$op eq '%')
   {
 - if ($ctx =~ /Wx[^WCE]|[^WCE]xW/) {
 + if ($ctx =~ /Wx[^WCEB]|[^WCE]xW/) {
   if (ERROR(SPACING,
 need consistent 
 spacing around '$op' $at\n . $hereptr)) {
   $good = 
 rtrim($fix_elements[$n]) .   . trim($fix_elements[$n + 1]) .  ;
 
 

That patch does indeed fix the problem, thanks!

Tested-by: Josh Triplett j...@joshtriplett.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: [Ksummit-2013-discuss] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Josh Triplett]

On Tue, Sep 03, 2013 at 08:26:21AM +0800, Shilong Wang wrote:
 2013/9/3 Joe Perches j...@perches.com:
  Wang Shilong wangshilong1...@gmail.com
  sent me an automated checkpatch email I
  thought was not useful.
 
 I am sorry if i give you any trouble, i have disabled it(in fact, it
 only has run for a day!)

I would suggest that you leave it running, but rather than sending mails
directly, have it prep the mails for you to send after manual review.
Do some careful scrutiny for false positives and cases where the change
would not improve the code, and use checkpatch's options to turn off
the more contentious warnings (like the 80-column warning).  Over time,
you'll develop a set of options that produce warnings people mostly
*want* to get notified about.

- Josh Triplett
--
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] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Fengguang Wu]

On Mon, Sep 02, 2013 at 02:11:36PM -0700, Joe Perches wrote:
 On Mon, 2013-09-02 at 21:50 +0100, David Howells wrote:
  Josh Triplett j...@joshtriplett.org wrote:
  
There are many checkpatch rules (like semicolons) that
are not in CodingStyle.
   
   It's a rule of thumb, not a mandate.  In *general*, checkpatch.pl should
   not be enforcing style rules that aren't documented in CodingStyle.
  
  Except that it becomes a mandate when someone runs it automatically against
  every one of your patches and then sends you an email for each patch it 
  finds
  a checkpatch niggle against...
 
 I think that any robot sending such checkpatch-only
 emails should be disabled.
 
 I know of 2 email robots.
 
 Fengguang Wu's very useful build robot
 sends out emails on build failures.
 I think that's great.

Thanks! Yes I'm now running checkpatch these days because some people
suggested to me that some of the checkpatch warnings do help catch
real bugs.

However I do try to avoid upsetting people with maybe-subjective
warnings. A checkpatch report will only be sent when a small fraction
of error types are detected. Comments are very welcome on how to
improve this list:

MEMSET
IN_ATOMIC
UAPI_INCLUDE
MALFORMED_INCLUDE   
SIZEOF_ADDRESS  
KREALLOC_ARG_REUSE  
EXECUTE_PERMISSIONS 
ERROR:BAD_SIGN_OFF  
LO_MACRO
HI_MACRO
CSYNC
SSYNC
HOTPLUG_SECTION
INDENTED_LABEL
INLINE_LOCATION
STORAGE_CLASS
USLEEP_RANGE
UNNECESSARY_CASTS
ALLOC_SIZEOF_STRUCT
KREALLOC_ARG_REUSE
USE_FUNC
LOCKDEP
EXPORTED_WORLD_WRITABLE
WHITESPACE_AFTER_LINE_CONTINUATION
MISSING_VMLINUX_SYMBOL
NEEDLESS_IF
PRINTF_L

Once the decision is made to send a checkpatch error/warning, the
report email will use the triggering error (the one that matters) as
the email subject, with the complete output of checkpatch.pl included
in email body.

Thanks,
Fengguang
--
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: Linux 3.11

[Nicholas A. Bellinger]

On Mon, 2013-09-02 at 15:50 -0700, Linus Torvalds wrote:
 On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
 n...@linux-iscsi.org wrote:
 
  Unfortunately, this doesn't include the remaining target fixes for
  v3.11:
 
  Re: [GIT PULL -v2] target fixes for v3.11
  http://marc.info/?l=linux-kernelm=137799048226191w=2
 
  Is there a reason why these did not get PULLed..?
 
 Very simple: I have no such email in my mailbox. I see the target
 updates for v3.11-rc1 email (and I pulled that), and there is nothing
 since.
 
 I don't even have that mail in my lkml archives, much less as a private email.
 
 I see neither youe -v2 PULL request nor the One more late v3.11
 specific regression one. In fact, I see no emails from you at all
 from Aug 31.
 
 It may be that gmail hates you for some reason...
 
 [ time passes ]
 
 Yup. It's in my spam-box, with gmail helpfully telling me:
 
Why is this message in Spam? We've found that lots of messages from
 linux-iscsi.org are spam.  Learn more
 
 so something is rotten in the state of linux-iscsi.org.
 
 Recent messages from you were similarly tagged:
 
  [GIT PULL -v2] target fixes for 3.11
  Re: LIO FC Target
  Re: [GIT PULL] target fixes for v3.11-rc7
 
 there might have been more. You might want to try to figure out why
 gmail thinks that linux-iscsi.org is spammy.

Mmmm, that is what I was afraid of, looking into that now..

So if you would, please go ahead and pull target-pending/master ASAP for
the fixes, and I'll send the parts that need to goto Greg-KH separately.

Thanks,

--nab

--
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] f2fs: optimize gc for better performance

[Jaegeuk Kim]

Hi Jin,

 [...]
 
  It seems that we can obtain the performance gain just by setting the
  MAX_VICTIM_SEARCH to 4096, for example.
  So, how about just adding an ending criteria like below?
 
 
 I agree that we could get the performance improvement by simply
 enlarging the MAX_VICTIM_SEARCH to 4096, but I am concerning the
 scalability a little bit. Because it might always searching the whole
 bitmap in some cases, for example, when dirty segments is 4000 and
 total segments is 409600.
  [snip]
 [...]
 
  if (p-max_search  MAX_VICTIM_SEARCH)
  p-max_search = MAX_VICTIM_SEARCH;
 
 
 The optimization does not apply to SSR mode. There has a reason.
 As noticed in the test, when SSR selected the segments that have most
 garbage blocks, then when gc is needed, all the dirty segments might
 have very less garbage blocks, thus the gc overhead is high. This might
 lead to performance degradation. So the patch does not change the
 victim selection policy for SSR.

I think it doesn't care.
GC is only triggered during the direct node block allocation.
What it means that we need to consider the number of GC triggers where
the GC triggers more frequently during the normal data allocation than
the node block allocation.
So, I think it would not degrade performance significatly.

BTW, could you show some numbers for this?
Or could you test what I suggested?

Thanks,

 
 What do you think now?
 
  #define MAX_VICTIM_SEARCH 4096 /* covers 8GB */
 
 p-offset = sbi-last_victim[p-gc_mode];
  @@ -243,6 +245,8 @@ static int get_victim_by_default(struct f2fs_sb_info 
  *sbi,
 struct victim_sel_policy p;
 unsigned int secno, max_cost;
 int nsearched = 0;
  +  unsigned int max_search = MAX_VICTIM_SEARCH;
  +  unsigned int nr_dirty;
 
 p.alloc_mode = alloc_mode;
 select_policy(sbi, gc_type, type, p);
  @@ -258,6 +262,27 @@ static int get_victim_by_default(struct f2fs_sb_info 
  *sbi,
 goto got_it;
 }
 
  +  nr_dirty = dirty_i-nr_dirty[p.dirty_type];
  +  if (p.gc_mode == GC_GREEDY  p.alloc_mode != SSR) {
  +  if (TOTAL_SEGS(sbi) = FULL_VICTIM_SEARCH_THRESH)
  +  max_search = nr_dirty; /* search all the dirty segs */
  +  else {
  +  /*
  +   * With more dirty segments, garbage blocks are likely
  +   * more scattered, thus search harder for better
  +   * victim.
  +   */
  +  max_search = div_u64 ((nr_dirty *
  +  FULL_VICTIM_SEARCH_THRESH), TOTAL_SEGS(sbi));
  +  if (max_search  MIN_VICTIM_SEARCH_GREEDY)
  +  max_search = MIN_VICTIM_SEARCH_GREEDY;
  +  }
  +  }
  +
  +  /* no more than the total dirty segments */
  +  if (max_search  nr_dirty)
  +  max_search = nr_dirty;
  +
 while (1) {
 unsigned long cost;
 unsigned int segno;
  @@ -290,7 +315,7 @@ static int get_victim_by_default(struct f2fs_sb_info 
  *sbi,
 if (cost == max_cost)
 continue;
 
  -  if (nsearched++ = MAX_VICTIM_SEARCH) {
  +  if (nsearched++ = max_search) {
 
  if (nsearched++ = p.max_search) {
 
 sbi-last_victim[p.gc_mode] = segno;
 break;
 }
  diff --git a/fs/f2fs/gc.h b/fs/f2fs/gc.h
  index 2c6a6bd..2f525aa 100644
  --- a/fs/f2fs/gc.h
  +++ b/fs/f2fs/gc.h
  @@ -20,7 +20,9 @@
#define LIMIT_FREE_BLOCK 40 /* percentage over invalid + free space */
 
/* Search max. number of dirty segments to select a victim segment */
  -#define MAX_VICTIM_SEARCH 20
  +#define MAX_VICTIM_SEARCH 20
  +#define MIN_VICTIM_SEARCH_GREEDY  20
  +#define FULL_VICTIM_SEARCH_THRESH 4096
 
struct f2fs_gc_kthread {
 struct task_struct *f2fs_gc_task;
  diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
  index 062424a..cd33f96 100644
  --- a/fs/f2fs/segment.h
  +++ b/fs/f2fs/segment.h
  @@ -142,6 +142,7 @@ struct victim_sel_policy {
 int alloc_mode; /* LFS or SSR */
 int gc_mode;/* GC_CB or GC_GREEDY */
 unsigned long *dirty_segmap;/* dirty segment bitmap */
  +  int dirty_type;
 
  int max_search; /* maximum # of segments to search */
 
 unsigned int offset;/* last scanned bitmap offset */
 unsigned int ofs_unit;  /* bitmap search unit */
 unsigned int min_cost;  /* minimum cost */
 
 

-- 
Jaegeuk Kim
Samsung

--
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] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Joe Perches]

On Tue, 2013-09-03 at 08:39 +0800, Fengguang Wu wrote:
 On Mon, Sep 02, 2013 at 02:11:36PM -0700, Joe Perches wrote:
[]
  Fengguang Wu's very useful build robot
  sends out emails on build failures.
  I think that's great.
 
 Thanks! Yes I'm now running checkpatch these days because some people
 suggested to me that some of the checkpatch warnings do help catch
 real bugs.

Hi Fengguang.

I see, I don't recall receiving one of these so
it must be working just fine.

 However I do try to avoid upsetting people with maybe-subjective
 warnings. A checkpatch report will only be sent when a small fraction
 of error types are detected. Comments are very welcome on how to
 improve this list:

Your list seems reasonable.

I might add:

DOS_LINE_ENDINGS
MODIFIED_INCLUDE_ASM
JIFFIES_COMPARISON
ONE_SEMICOLON


--
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 RESEND 2/3] x86, mm: Update min_pfn_mapped in add_pfn_range_mapped().

[Tang Chen]

Hi Yinghai,

On 09/03/2013 02:41 AM, Yinghai Lu wrote:
..


Nak, you can not move that.

min_pfn_mapped should not be updated before init_range_memory_mapping
is returned. as it need to refer old min_pfn_mapped.
and init_range_memory_mapping still init mapping from low to high locally.
min_pfn_mapped can not be updated too early.


The current code is like this:

init_mem_mapping()
{
while (from high to low) {
init_range_memory_mapping()
{
/* Here is from low to high */
for (from low to high) {
init_memory_mapping()
{
for () {
/* Need to refer min_pfn_mapped 
here */
kernel_physical_mapping_init();
}
/* So if updating min_pfn_mapped here, 
it is too low */
add_pfn_range_mapped();
}
}
}   
}
}

How about change the for (from low to high) in 
init_range_memory_mapping() to

for_rev(from high to low) ?
Then we can update min_pfn_mapped in add_pfn_range_mapped().

And also, the outer loop is from high to low, we can change the inner 
loop to be from high

to low too.

I think updating min_pfn_mapped in init_mem_mapping() is less readable. 
And min_pfn_mapped

and max_pfn_mapped should be updated together.

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: [Ksummit-2013-discuss] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Fengguang Wu]

On Mon, Sep 02, 2013 at 05:36:03PM -0700, Josh Triplett wrote:
 On Tue, Sep 03, 2013 at 08:26:21AM +0800, Shilong Wang wrote:
  2013/9/3 Joe Perches j...@perches.com:
   Wang Shilong wangshilong1...@gmail.com
   sent me an automated checkpatch email I
   thought was not useful.
  
  I am sorry if i give you any trouble, i have disabled it(in fact, it
  only has run for a day!)
 
 I would suggest that you leave it running, but rather than sending mails
 directly, have it prep the mails for you to send after manual review.
 Do some careful scrutiny for false positives and cases where the change
 would not improve the code, and use checkpatch's options to turn off
 the more contentious warnings (like the 80-column warning).  Over time,
 you'll develop a set of options that produce warnings people mostly
 *want* to get notified about.
 
Good suggestions! That's exactly what I'm trying to do. And Joe kindly
showed me the initial list of checkpatch error types suitable for auto
notification.

Coverage is good: the checkpatch robot iterates over every new commit
in the 300+ git trees I collected over time. Some maintainer trees are
skipped because they should already run the check.

Here is the list of reports sent in the last two weeks. They are private
emails directly sent to the commit author and committer.  So far I've not
received complaints on these unsolicited checkpatch reports.

 Aug 23  [netdev-next:master 200/301] WARNING: usb_free_urb(NULL) is safe this 
check is probably n
 Aug 23  [netdev-next:master 202/301] WARNING: usb_free_urb(NULL) is safe this 
check is probably n
 Aug 23  [linuxtv-media:master 321/499] ERROR: Unrecognized email address: 
'Kyungmin Park kyungmi
 Aug 23  [linuxtv-media:master 322/499] ERROR: Unrecognized email address: 
'Kyungmin Park kyungmi
 Aug 24  [xlnx:master-next 32/53] WARNING: unnecessary cast may hide bugs, see 
http://c-faq.com/ma
 Aug 28  [mmotm:master 473/483] WARNING: __func__ should be used instead of gcc 
specific __FUNCTIO
 Aug 28  [kvm:queue 13/14] ERROR: Unrecognized email address: 'Gleb Natapov 
@g...@redhat.com'
 Aug 29  [dhowells-fs:keys-devel 9/12] WARNING: labels should not be indented
 Aug 29  [jolsa-perf:perf/plugins2 14/20] WARNING: storage class should be at 
the beginning of the
 Aug 30  [nfs:testing 47/61] ERROR: Unrecognized email address: 'Trond 
Myklebust Trond.Myklebust@
 Aug 31  [josef-btrfs:master 74/135] WARNING: kfree(NULL) is safe this check is 
probably not requi
 Aug 31  [jolsa-perf:perf/toggle6 6/8] WARNING: kfree(NULL) is safe this check 
is probably not req
 Sep 01  [jolsa-perf:perf/core_plugins 14/24] WARNING: storage class should be 
at the beginning of

Thanks,
Fengguang

--
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] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Josh Triplett]

On Tue, Sep 03, 2013 at 08:39:58AM +0800, Fengguang Wu wrote:
 On Mon, Sep 02, 2013 at 02:11:36PM -0700, Joe Perches wrote:
  On Mon, 2013-09-02 at 21:50 +0100, David Howells wrote:
   Josh Triplett j...@joshtriplett.org wrote:
   
 There are many checkpatch rules (like semicolons) that
 are not in CodingStyle.

It's a rule of thumb, not a mandate.  In *general*, checkpatch.pl should
not be enforcing style rules that aren't documented in CodingStyle.
   
   Except that it becomes a mandate when someone runs it automatically 
   against
   every one of your patches and then sends you an email for each patch it 
   finds
   a checkpatch niggle against...
  
  I think that any robot sending such checkpatch-only
  emails should be disabled.
  
  I know of 2 email robots.
  
  Fengguang Wu's very useful build robot
  sends out emails on build failures.
  I think that's great.
 
 Thanks! Yes I'm now running checkpatch these days because some people
 suggested to me that some of the checkpatch warnings do help catch
 real bugs.
 
 However I do try to avoid upsetting people with maybe-subjective
 warnings. A checkpatch report will only be sent when a small fraction
 of error types are detected. Comments are very welcome on how to
 improve this list:
 
 MEMSET
 IN_ATOMIC
 UAPI_INCLUDE
 MALFORMED_INCLUDE   
 SIZEOF_ADDRESS  
 KREALLOC_ARG_REUSE  
 EXECUTE_PERMISSIONS 
 ERROR:BAD_SIGN_OFF  
 LO_MACRO
 HI_MACRO
 CSYNC
 SSYNC
 HOTPLUG_SECTION
 INDENTED_LABEL
 INLINE_LOCATION
 STORAGE_CLASS
 USLEEP_RANGE
 UNNECESSARY_CASTS
 ALLOC_SIZEOF_STRUCT
 KREALLOC_ARG_REUSE
 USE_FUNC
 LOCKDEP
 EXPORTED_WORLD_WRITABLE
 WHITESPACE_AFTER_LINE_CONTINUATION
 MISSING_VMLINUX_SYMBOL
 NEEDLESS_IF
 PRINTF_L

Looks like you have KREALLOC_ARG_REUSE in that list twice.

Other than that, those look sensible.  I'd suggest a couple more, which
*should* always make sense, and to the best of my knowledge don't tend
to generate false positives:

C99_COMMENTS
CONFIG_EXPERIMENTAL
CVS_KEYWORD
ELSE_AFTER_BRACE
GLOBAL_INITIALIZERS
INITIALISED_STATIC
INVALID_UTF8
LINUX_VERSION_CODE
MISSING_EOF_NEWLINE
PREFER_SEQ_PUTS
PRINTK_WITHOUT_KERN_LEVEL
REDUNDANT_CODE
RETURN_PARENTHESES
SIZEOF_PARENTHESIS
SPACE_BEFORE_TAB
TRAILING_SEMICOLON
TRAILING_WHITESPACE
USE_DEVICE_INITCALL
USE_RELATIVE_PATH

These *ought* to make sense, but I don't know their false positive rates:

HEXADECIMAL_BOOLEAN_TEST
ALLOC_ARRAY_ARGS
CONSIDER_KSTRTO
CONST_STRUCT
SPLIT_STRING

The following almost always make sense, but only on patches not
yet applied to a tree:

PATCH_PREFIX
MODIFIED_INCLUDE_ASM
CORRUPTED_PATCH
NOT_UNIFIED_DIFF
MISSING_SIGN_OFF

- Josh Triplett
--
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] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Fengguang Wu]

On Mon, Sep 02, 2013 at 05:47:54PM -0700, Joe Perches wrote:
 On Tue, 2013-09-03 at 08:39 +0800, Fengguang Wu wrote:
  On Mon, Sep 02, 2013 at 02:11:36PM -0700, Joe Perches wrote:
 []
   Fengguang Wu's very useful build robot
   sends out emails on build failures.
   I think that's great.
  
  Thanks! Yes I'm now running checkpatch these days because some people
  suggested to me that some of the checkpatch warnings do help catch
  real bugs.
 
 Hi Fengguang.
 
 I see, I don't recall receiving one of these so
 it must be working just fine.

Hi Joe!

Log shows that one of your patch being checked earlier today:

[4 days ago, Joe Perches] perf: Convert kmalloc_node(...GFP_ZERO...) to 
kzalloc_node()

If you have more patches in some git tree that missed the check,
please let me know.

  However I do try to avoid upsetting people with maybe-subjective
  warnings. A checkpatch report will only be sent when a small fraction
  of error types are detected. Comments are very welcome on how to
  improve this list:
 
 Your list seems reasonable.
 
 I might add:
 
 DOS_LINE_ENDINGS
 MODIFIED_INCLUDE_ASM
 JIFFIES_COMPARISON
 ONE_SEMICOLON

Yeah they all look good to have. Thanks for the suggestions again!

Thanks,
Fengguang
--
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: RESEND: Generating interrupts from a USB device driver?

[Daniel Santos]

On 09/02/2013 06:07 PM, Greg KH wrote:

On Mon, Sep 02, 2013 at 05:46:58PM -0500, Daniel Santos wrote:

Hello guys.  I didn't get a response the last time so hopefully with
3.11 out I'll get one this time.

I need to be able to generate interrupts from a USB device driver while
servicing the complete() function of an interrupt URB.

No you don't :)


While I realize that this may seem strange, the purpose is for a USB
to SPI/GPIO bridge chip (the MCP2210). When something happens on the
remote device where a chip is expecting it's interrupt out pin to
trigger an interrupt on some local (to the board) microcontroller, the
MCP2210 instead receives that signal and communicates it to the host
the next time it's queried. This is the interrupt that I need to, in
effect propagate locally. Since my spi_master and gpio_chip are all
functioning now, this is the last step to get one of my spi protocol
drivers working correctly.

Just pass the data up the spi stack in your interrupt endpoint handler.
No need to try to create a real interrupt.  There are other USB SPI
drivers that should give you the idea of how to do it.
Thanks for your response! I haven't been able to find these drivers, can 
you please point me to one? I guess I don't know the spi stack well 
enough to know how to propagate that notification up to the driver for 
the spi device (let alone that it was called a stack :)


Thanks!!
Daniel
--
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] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Joe Perches]

On Mon, 2013-09-02 at 18:34 -0700, Josh Triplett wrote:
 I'd suggest a couple more, which
 *should* always make sense, and to the best of my knowledge don't tend
 to generate false positives:
 
 C99_COMMENTS

I don't have a problem with c99 comments.
As far as I know, Linus doesn't either.

https://lkml.org/lkml/2012/4/16/473

 CONFIG_EXPERIMENTAL
 CVS_KEYWORD

OK, but shrug

 ELSE_AFTER_BRACE

I wouldn't do this one.  I think
there are some false positives here.

 GLOBAL_INITIALIZERS
 INITIALISED_STATIC

Nor these.

 INVALID_UTF8
 LINUX_VERSION_CODE
 MISSING_EOF_NEWLINE

OK I suppose.

 PREFER_SEQ_PUTS
 PRINTK_WITHOUT_KERN_LEVEL

There are a lot of these.
I suggest no here.

 RETURN_PARENTHESES
 SIZEOF_PARENTHESIS

It's in coding style, but some newish patches
do avoid them.  It's a question about how noisy
you want your robot to be.

 SPACE_BEFORE_TAB
 TRAILING_SEMICOLON
 TRAILING_WHITESPACE
 USE_DEVICE_INITCALL

 USE_RELATIVE_PATH

Having checkpatch tell people how to write changelogs
I think not a great idea.

 These *ought* to make sense, but I don't know their false positive rates:
 
 HEXADECIMAL_BOOLEAN_TEST

That's a good one.  0 false positives.

 ALLOC_ARRAY_ARGS

Yes, this would be reasonable too.

 CONSIDER_KSTRTO

I think orobably not.  This would be a cleanup thing.

 CONST_STRUCT

OK

 SPLIT_STRING

I suggest no but shrug

--
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] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Josh Triplett]

On Mon, Sep 02, 2013 at 06:52:45PM -0700, Joe Perches wrote:
 On Mon, 2013-09-02 at 18:34 -0700, Josh Triplett wrote:
  I'd suggest a couple more, which
  *should* always make sense, and to the best of my knowledge don't tend
  to generate false positives:
  
  C99_COMMENTS
 
 I don't have a problem with c99 comments.
 As far as I know, Linus doesn't either.
 
 https://lkml.org/lkml/2012/4/16/473

That doesn't look like an endorsement so much as a statement that C99
comments are less awful than the net/ special-case comment style.

Documentation/CodingStyle chapter 8 says:
 Linux style for comments is the C89 /* ... */ style.
 Don't use C99-style // ... comments.

If that no longer holds true, we should remove it from CodingStyle.  As
far as I know, though, it still holds.  In any case, it rarely comes up;
most kernel code doesn't use such comments.

  CONFIG_EXPERIMENTAL
  CVS_KEYWORD
 
 OK, but shrug

Sure, I don't expect them to come up often.

  ELSE_AFTER_BRACE
 
 I wouldn't do this one.  I think
 there are some false positives here.

Oh?  What kinds of false positives have you seen?

In any case, fair enough.

  GLOBAL_INITIALIZERS
  INITIALISED_STATIC
 
 Nor these.

I don't see an obvious way for those to have false positives.  What have
you seen?

  INVALID_UTF8
  LINUX_VERSION_CODE
  MISSING_EOF_NEWLINE
 
 OK I suppose.

Not particularly critical, but uncontroversial and no false positives.

  PREFER_SEQ_PUTS
  PRINTK_WITHOUT_KERN_LEVEL
 
 There are a lot of these.
 I suggest no here.

I assume the bot only applies this to new patches, not to existing code,
in which case these seem completely reasonable.  New code should follow
these, even if we don't mass-fix existing code.

  RETURN_PARENTHESES
  SIZEOF_PARENTHESIS
 
 It's in coding style, but some newish patches
 do avoid them.  It's a question about how noisy
 you want your robot to be.

These two seem reasonable to enforce on new code.  I agree that they
shouldn't trigger mass cleanups of existing code.

  SPACE_BEFORE_TAB
  TRAILING_SEMICOLON
  TRAILING_WHITESPACE
  USE_DEVICE_INITCALL

I didn't see any comment from you on these four.  Thoughts?

  USE_RELATIVE_PATH
 
 Having checkpatch tell people how to write changelogs
 I think not a great idea.

In general, sure, but that particular one seems OK.  In any case, not
particularly critical.

  These *ought* to make sense, but I don't know their false positive rates:
  
  HEXADECIMAL_BOOLEAN_TEST
 
 That's a good one.  0 false positives.

Ah, good.

  ALLOC_ARRAY_ARGS
 
 Yes, this would be reasonable too.

Excellent.

  CONSIDER_KSTRTO
 
 I think orobably not.  This would be a cleanup thing.

Even if applied to new code only?  New code should use the right
functions to start with.

  CONST_STRUCT
 
 OK

Good to know; glad to hear it doesn't have false positives.

  SPLIT_STRING
 
 I suggest no but shrug

I can easily believe that it has too many false positives.  Let's leave
that one alone for now.

- Josh Triplett
--
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: Linux 3.11

[Theodore Ts'o]

On Mon, Sep 02, 2013 at 04:46:18PM -0700, Guenter Roeck wrote:
 I don't think it has anything to do with linux-iscsi.org.
 Possibly Nicholas' e-mail provider is not hosted in the US, meaning e-mail
 sent through it can not be logged and examined by a certain US government 
 agency.

Hardly.  mail.linux-iscsi.org is hosted by Rackspace, which is most
certainly in the US.  There may be spammers using some of Rackspace
subnets, which is much more likely to have something to be the issue.

I had a similar issue with thunk.org, which is hosted by Linode.  In
my case, part of the problem was that I was that I moved my host to a
different Linode datacenter (from Dallas to Atlanta), and I forgot to
update my SPF record, so e-mails with an SMTP envelope address of
ty...@thunk.org were getting a soft-fail.  (And e-mails with an SMTP
return address of ty...@mit.edu but sent from imap.thunk.org were
always getting a soft-fail, which would tend to increase the
likelihood that if the e-mail tripped other hueristics, would cause it
to be considered spam.)

Fixing my SPF record, and enabling DKIM (with a DKIM key published for
thunk.org in DNS, and making sure that I always used an SMTP envelope
return address of ty...@thunk.org, even if the RFC 822 from address
stated ty...@mit.edu) fixed the spam false positive issues for me.

(Hint: installing and configuring OpenDKIM really isn't all that hard.
I did it in less than an hour.)

 I had the same experience; Google blocks all e-mail from my private provider
 (located in Singapore). When asked by the provider, they claimed to know
 nothing about it. No, my provider doesn't forward more spam than other 
 providers,
 and definitely less than, say, Yahoo.

One of the things that might be happening is that your private
provider may be hosting mailing lists used by companies to send
marketing newsletters.  Unfortunately, sometimes it's a pain to
subscribe from such newsletters, and some users will just simply hit
the it's spam button to make such newsletters go away.  For a small
provider, it's easier for a percentage of e-mails being emitted from a
mailer to be considered spam to exceed some magic threshold, thus
increasing the spam score for e-mails originating from that
provider.

I'll also note that Yahoo uses DKIM (heck, it invented DKIM) and using
DKIM is useful because if someone tries to fake spam using your
domain, if your e-mails are getting signed using DKIM, and the spam is
getting sent without being DKIM signed, many of the anti-spam
filtering services defintiely do take this into account.  Some may
even automatically decrease your spam score slightly just because you
are using DKIM, just because spammers tend not to do this, and using
DKIM to sign your e-mail headers makes it easier for spam filtering
systems to hold senders accountable for spam that they send.

  - Ted

P.S.  Although I work for Google, I don't know anything about the
low-level details of how Google's anti-SPAM systems work.  However,
for almost a decade, I was a member of MIT Network Operations, and was
one of the postmasters for mit.edu, back when aol.com was in its prime
(and we had a larger number of SMTP deliveries per day than AOL did).
So I know a thing or two about e-mail and I'd be really surprised
if anyone, particular a major mail provider such as Google, Yahoo,
Hotmail, etc, was filtering e-mail just because it came from a non-US
mail server.

The reality is that e-mail is international, and it's only the admins
of smaller mail services (perhaps desperate to filter out vast
quantities of Russian or Chinese Spam, and figuring that they weren't
expecting any valid e-mails from those countries), that would do
something as silly has filtering based on geographic source locations.
--
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] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Joe Perches]

On Mon, 2013-09-02 at 19:12 -0700, Josh Triplett wrote:
 On Mon, Sep 02, 2013 at 06:52:45PM -0700, Joe Perches wrote:
  On Mon, 2013-09-02 at 18:34 -0700, Josh Triplett wrote:
   I'd suggest a couple more, which
   *should* always make sense, and to the best of my knowledge don't tend
   to generate false positives:

Hey Josh.

I don't want to enable too many types of messages
because the barrier to entry to submit patches
shouldn't be so high that it discourages people.

I feel mostly that many types of checkpatch messages
are OK to emit, but aren't necessary to fix and
people should feel that checkpatch isn't a necessary
thing to silence before patches are accepted.

cheers, Joe

--
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] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Fengguang Wu]

On Mon, Sep 02, 2013 at 06:52:45PM -0700, Joe Perches wrote:
 On Mon, 2013-09-02 at 18:34 -0700, Josh Triplett wrote:
  I'd suggest a couple more, which
  *should* always make sense, and to the best of my knowledge don't tend
  to generate false positives:
  
  C99_COMMENTS
 
 I don't have a problem with c99 comments.
 As far as I know, Linus doesn't either.
 
 https://lkml.org/lkml/2012/4/16/473
 
  CONFIG_EXPERIMENTAL
  CVS_KEYWORD
 
 OK, but shrug
 
  ELSE_AFTER_BRACE
 
 I wouldn't do this one.  I think
 there are some false positives here.
 
  GLOBAL_INITIALIZERS
  INITIALISED_STATIC
 
 Nor these.
 
  INVALID_UTF8
  LINUX_VERSION_CODE
  MISSING_EOF_NEWLINE
 
 OK I suppose.
 
  PREFER_SEQ_PUTS
  PRINTK_WITHOUT_KERN_LEVEL
 
 There are a lot of these.
 I suggest no here.
 
  RETURN_PARENTHESES
  SIZEOF_PARENTHESIS
 
 It's in coding style, but some newish patches
 do avoid them.  It's a question about how noisy
 you want your robot to be.

I'd prefer the robot to show up only when necessary. The coding style
warnings are good for the developers who actively run checkpatch.pl to
make their patch better. However most are probably not suitable for a
robot to send people unsolicited warnings.

  SPACE_BEFORE_TAB
  TRAILING_SEMICOLON
  TRAILING_WHITESPACE
  USE_DEVICE_INITCALL
 
  USE_RELATIVE_PATH
 
 Having checkpatch tell people how to write changelogs
 I think not a great idea.
 
  These *ought* to make sense, but I don't know their false positive rates:
  
  HEXADECIMAL_BOOLEAN_TEST
 
 That's a good one.  0 false positives.
 
  ALLOC_ARRAY_ARGS
 
 Yes, this would be reasonable too.
 
  CONSIDER_KSTRTO
 
 I think orobably not.  This would be a cleanup thing.

Perhaps we can run it for a while, so that people at least come to
aware there is a kstrto() for use. :)

  CONST_STRUCT
 
 OK
 
  SPLIT_STRING
 
 I suggest no but shrug

Thanks for both of your suggestions! I'll add the commonly agreed ones:

+INVALID_UTF8
+LINUX_VERSION_CODE
+MISSING_EOF_NEWLINE
+HEXADECIMAL_BOOLEAN_TEST
+ALLOC_ARRAY_ARGS
+CONST_STRUCT
+CONSIDER_KSTRTO

And remove the duplicate one (good catch, Josh!)

-KREALLOC_ARG_REUSE

Thanks,
Fengguang
--
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: Linux 3.11

[Nicholas A. Bellinger]

Hi Ted,

On Mon, 2013-09-02 at 22:17 -0400, Theodore Ts'o wrote:
 On Mon, Sep 02, 2013 at 04:46:18PM -0700, Guenter Roeck wrote:
  I don't think it has anything to do with linux-iscsi.org.
  Possibly Nicholas' e-mail provider is not hosted in the US, meaning e-mail
  sent through it can not be logged and examined by a certain US government 
  agency.
 
 Hardly.  mail.linux-iscsi.org is hosted by Rackspace, which is most
 certainly in the US.  There may be spammers using some of Rackspace
 subnets, which is much more likely to have something to be the issue.
 
 I had a similar issue with thunk.org, which is hosted by Linode.  In
 my case, part of the problem was that I was that I moved my host to a
 different Linode datacenter (from Dallas to Atlanta), and I forgot to
 update my SPF record, so e-mails with an SMTP envelope address of
 ty...@thunk.org were getting a soft-fail.  (And e-mails with an SMTP
 return address of ty...@mit.edu but sent from imap.thunk.org were
 always getting a soft-fail, which would tend to increase the
 likelihood that if the e-mail tripped other hueristics, would cause it
 to be considered spam.)
 
 Fixing my SPF record, and enabling DKIM (with a DKIM key published for
 thunk.org in DNS, and making sure that I always used an SMTP envelope
 return address of ty...@thunk.org, even if the RFC 822 from address
 stated ty...@mit.edu) fixed the spam false positive issues for me.
 
 (Hint: installing and configuring OpenDKIM really isn't all that hard.
 I did it in less than an hour.)

nod, thanks for the additional information.

Enabling DKIM now, and just waiting for the TXT records to update to
verify.

--nab

--
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 RESEND 2/3] x86, mm: Update min_pfn_mapped in add_pfn_range_mapped().

[Yinghai Lu]

On Mon, Sep 2, 2013 at 6:06 PM, Tang Chen tangc...@cn.fujitsu.com wrote:
 Hi Yinghai,

 On 09/03/2013 02:41 AM, Yinghai Lu wrote:

 How about change the for (from low to high) in init_range_memory_mapping()
 to
 for_rev(from high to low) ?
 Then we can update min_pfn_mapped in add_pfn_range_mapped().

 And also, the outer loop is from high to low, we can change the inner loop
 to be from high
 to low too.

No. there is other reason for doing local from low to high.

kernel_physical_mapping_init() could clear some mapping near the end
of PUG/PMD entries but not the head.


 I think updating min_pfn_mapped in init_mem_mapping() is less readable. And
 min_pfn_mapped
 and max_pfn_mapped should be updated together.

min_pfn_mapped is early local variable to control allocation in alloc_low_pages.
put it in init_mem_mapping is more readable.

Yinghai
--
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/8] Drop support for Renesas H8/300 architecture

[Chen Gang F T]

Hello Guenter Roeck:


I don't care about whether I am in cc mailing list, but at least,
please help confirm 2 things:

  Is what I had done for h8300 just making wastes and noisy in kernel and 
related sub-system mailing list ?

  and is the disccusion about h8300 between us also wastes and noisy in kernel 
mailing list ?


And also I have to make an apologize to kernel and other related sub
system mailing list:

  some of patches about h8300 which I have sent in 2013-09-02 are really wastes 
(and I wasted my time resource for it, too).

  the excuse (not reason) is I do not know about Guenter Roeck has sent this 
patch (I am not in this cc list, so I find it one day delay).


BTW: I also add some another related members in cc mailing list to let
them know about some of suspending thread about h8300 (which waiting
for allmodconfig finish) can be canceled.


Thanks.

On 08/31/2013 07:51 AM, Guenter Roeck wrote:
 H8/300 has been dead for several years, the kernel for it has
 not compiled for ages, and recent versions of gcc for it are broken.
 It is time to drop support for it.
 
 Yes, I understand it is not that simple to drop an architecture,
 and it may need some discussion, but someone has to put a stake
 into the ground. Keeping a virtually dead architecture on life support
 takes resources which are better spent elsewhere.
 
 v2:
 - s/Renesys/Renesas/g
 - Found and removed more architecture specific code in fs/minix
   and in smc9194 driver
 - Added explicit Cc: for h8300 maintainer
 - Added subsystem maintainer Acks
 
 
 Guenter Roeck (8):
   Drop support for Renesas H8/300 (h8300) architecture
   ide: Drop H8/300 driver
   net/ethernet: smsc9194: Drop conditional code for H8/300
   net/ethernet: Drop H8/300 Ethernet driver
   watchdog: Drop references to H8300 architecture
   Drop MAINTAINERS entry for H8/300
   Drop remaining references to H8/300 architecture
   fs/minix: Drop dependency on H8300
 
  Documentation/scheduler/sched-arch.txt   |5 -
  MAINTAINERS  |8 -
  arch/h8300/Kconfig   |  109 
  arch/h8300/Kconfig.cpu   |  171 --
  arch/h8300/Kconfig.debug |   68 ---
  arch/h8300/Kconfig.ide   |   44 --
  arch/h8300/Makefile  |   71 ---
  arch/h8300/README|   38 --
  arch/h8300/boot/Makefile |   22 -
  arch/h8300/boot/compressed/Makefile  |   37 --
  arch/h8300/boot/compressed/head.S|   47 --
  arch/h8300/boot/compressed/misc.c|  180 --
  arch/h8300/boot/compressed/vmlinux.lds   |   32 -
  arch/h8300/boot/compressed/vmlinux.scr   |9 -
  arch/h8300/defconfig |   42 --
  arch/h8300/include/asm/Kbuild|8 -
  arch/h8300/include/asm/asm-offsets.h |1 -
  arch/h8300/include/asm/atomic.h  |  146 -
  arch/h8300/include/asm/barrier.h |   29 -
  arch/h8300/include/asm/bitops.h  |  211 ---
  arch/h8300/include/asm/bootinfo.h|2 -
  arch/h8300/include/asm/bug.h |   12 -
  arch/h8300/include/asm/bugs.h|   16 -
  arch/h8300/include/asm/cache.h   |   13 -
  arch/h8300/include/asm/cachectl.h|   14 -
  arch/h8300/include/asm/cacheflush.h  |   40 --
  arch/h8300/include/asm/checksum.h|  102 
  arch/h8300/include/asm/cmpxchg.h |   60 --
  arch/h8300/include/asm/cputime.h |6 -
  arch/h8300/include/asm/current.h |   25 -
  arch/h8300/include/asm/dbg.h |2 -
  arch/h8300/include/asm/delay.h   |   38 --
  arch/h8300/include/asm/device.h  |7 -
  arch/h8300/include/asm/div64.h   |1 -
  arch/h8300/include/asm/dma.h |   15 -
  arch/h8300/include/asm/elf.h |  101 
  arch/h8300/include/asm/emergency-restart.h   |6 -
  arch/h8300/include/asm/fb.h  |   12 -
  arch/h8300/include/asm/flat.h|   26 -
  arch/h8300/include/asm/fpu.h |1 -
  arch/h8300/include/asm/ftrace.h  |1 -
  arch/h8300/include/asm/futex.h   |6 -
  arch/h8300/include/asm/gpio-internal.h   |   52 --
  arch/h8300/include/asm/hardirq.h |   19 -
  arch/h8300/include/asm/hw_irq.h  |1 -
  arch/h8300/include/asm/io.h  |  358 ---
  arch/h8300/include/asm/irq.h |   49 --
  arch/h8300/include/asm/irq_regs.h|1 -
  

Re: [PATCH] xtensa: Fix broken allmodconfig build

[Guenter Roeck]

On 08/27/2013 09:06 PM, Guenter Roeck wrote:

xtansa allmodbuild fails with:

arch/xtensa/kernel/xtensa_ksyms.c:129:1: error: '_mcount' undeclared here (not 
in a function)
make[2]: *** [arch/xtensa/kernel/xtensa_ksyms.o] Error 1
make[1]: *** [arch/xtensa/kernel] Error 2

The breakage is due to commit 478ba61af (xtensa: add static function tracer
support) which exports _mcount without declaring it.

Cc: Max Filippov jcmvb...@gmail.com
Signed-off-by: Guenter Roeck li...@roeck-us.net
---


Ping ... 3.11 now ships with xtensa allmodconfig broken, which is completely 
unnecessary.

Guenter


  arch/xtensa/kernel/xtensa_ksyms.c |1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/xtensa/kernel/xtensa_ksyms.c 
b/arch/xtensa/kernel/xtensa_ksyms.c
index d8507f8..74a60c7 100644
--- a/arch/xtensa/kernel/xtensa_ksyms.c
+++ b/arch/xtensa/kernel/xtensa_ksyms.c
@@ -25,6 +25,7 @@
  #include asm/io.h
  #include asm/page.h
  #include asm/pgalloc.h
+#include asm/ftrace.h
  #ifdef CONFIG_BLK_DEV_FD
  #include asm/floppy.h
  #endif



--
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 2/3] mm/vmalloc: don't warning vmalloc allocation failure twice

[Wanpeng Li]

Don't warning twice in __vmalloc_area_node and __vmalloc_node_range if
__vmalloc_area_node allocation failure.

Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
 mm/vmalloc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index d78d117..e3ec8b4 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1635,7 +1635,7 @@ void *__vmalloc_node_range(unsigned long size, unsigned 
long align,
 
addr = __vmalloc_area_node(area, gfp_mask, prot, node, caller);
if (!addr)
-   goto fail;
+   return NULL;
 
/*
 * In this function, newly allocated vm_struct has VM_UNINITIALIZED
-- 
1.7.5.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 v2 1/3] mm/vmalloc: don't set area-caller twice

[Wanpeng Li]

Changelog:
 * rebase against mmotm tree

The caller address has already been set in set_vmalloc_vm(), there's no need
to set it again in __vmalloc_area_node.

Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
 mm/vmalloc.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 1074543..d78d117 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1566,7 +1566,6 @@ static void *__vmalloc_area_node(struct vm_struct *area, 
gfp_t gfp_mask,
pages = kmalloc_node(array_size, nested_gfp, node);
}
area-pages = pages;
-   area-caller = caller;
if (!area-pages) {
remove_vm_area(area-addr);
kfree(area);
-- 
1.7.5.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 v2 3/3] mm/vmalloc: move VM_UNINITIALIZED just before show_numa_info

[Wanpeng Li]

The VM_UNINITIALIZED/VM_UNLIST flag introduced by commit f5252e00(mm: avoid
null pointer access in vm_struct via /proc/vmallocinfo) is used to avoid
accessing the pages field with unallocated page when show_numa_info() is
called. This patch move the check just before show_numa_info in order that
some messages still can be dumped via /proc/vmallocinfo.

Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
 mm/vmalloc.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index e3ec8b4..c4720cd 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2590,11 +2590,6 @@ static int s_show(struct seq_file *m, void *p)
 
v = va-vm;
 
-   /* Pair with smp_wmb() in clear_vm_uninitialized_flag() */
-   smp_rmb();
-   if (v-flags  VM_UNINITIALIZED)
-   return 0;
-
seq_printf(m, 0x%pK-0x%pK %7ld,
v-addr, v-addr + v-size, v-size);
 
@@ -2622,6 +2617,11 @@ static int s_show(struct seq_file *m, void *p)
if (v-flags  VM_VPAGES)
seq_printf(m,  vpages);
 
+   /* Pair with smp_wmb() in clear_vm_uninitialized_flag() */
+   smp_rmb();
+   if (v-flags  VM_UNINITIALIZED)
+   return 0;
+
show_numa_info(m, v);
seq_putc(m, '\n');
return 0;
-- 
1.7.5.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/

Re: [PATCH] iommu: WARN_ON when removing a device with no iommu_group associated

[Wei Yang]

Any more comments? Or this one is not proper?

On Thu, Aug 22, 2013 at 09:33:27PM -0600, Alex Williamson wrote:
[+cc iommu]

On Fri, 2013-08-23 at 09:55 +0800, Wei Yang wrote:
 When removing a device from the system, iommu_group driver will try to
 disconnect it from its group. While in some cases, one device may not
 associated with any iommu_group. For example, not enough DMA address space.
 
 In the generic bus notification, it will check dev-iommu_group before 
 calling
 iommu_group_remove_device(). While in some cases, developers may call
 iommu_group_remove_device() in a different code path and without check. For
 those devices with dev-iommu_group set to NULL, kernel will crash.
 
 This patch gives a warning and return when trying to remove a device from an
 iommu_group with dev-iommu_group set to NULL. This helps to indicate some 
 bad
 behavior and also guard the kernel.
 
 Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com

Acked-by: Alex Williamson alex.william...@redhat.com

 ---
  drivers/iommu/iommu.c |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
 index fbe9ca7..43396f0 100644
 --- a/drivers/iommu/iommu.c
 +++ b/drivers/iommu/iommu.c
 @@ -379,6 +379,9 @@ void iommu_group_remove_device(struct device *dev)
  struct iommu_group *group = dev-iommu_group;
  struct iommu_device *tmp_device, *device = NULL;
  
 +if (WARN_ON(!group))
 +return;
 +
  /* Pre-notify listeners that a device is being removed. */
  blocking_notifier_call_chain(group-notifier,
   IOMMU_GROUP_NOTIFY_DEL_DEVICE, dev);



-- 
Richard Yang
Help you, Help me

--
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] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Josh Triplett]

On Tue, Sep 03, 2013 at 10:46:40AM +0800, Fengguang Wu wrote:
 On Mon, Sep 02, 2013 at 06:52:45PM -0700, Joe Perches wrote:
  On Mon, 2013-09-02 at 18:34 -0700, Josh Triplett wrote:
   CONFIG_EXPERIMENTAL
   CVS_KEYWORD
  
  OK, but shrug
[...]
 Thanks for both of your suggestions! I'll add the commonly agreed ones:
 
 +INVALID_UTF8
 +LINUX_VERSION_CODE
 +MISSING_EOF_NEWLINE
 +HEXADECIMAL_BOOLEAN_TEST
 +ALLOC_ARRAY_ARGS
 +CONST_STRUCT
 +CONSIDER_KSTRTO
 
 And remove the duplicate one (good catch, Josh!)
 
 -KREALLOC_ARG_REUSE

You missed CONFIG_EXPERIMENTAL and CVS_KEYWORD; see above.

- Josh Triplett
--
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: OCFS2: ocfs2_read_blocks:285 ERROR: block 532737 had the JBD bit set while I was in lock_buffer!

[Jeff Liu]

Hello,

It seems like Sunil has fixed a similar issue against ocfs2-1.4
several years ago:
https://oss.oracle.com/git/?p=ocfs2-1.4.git;a=commitdiff_plain;h=2fd250839d0f5073af8d42e97f1db74beb621674;hp=e882faf84930431524f84598caea7d4e9a9529c5
https://oss.oracle.com/git/?p=ocfs2-1.4.git;a=commitdiff_plain;h=eccff85213d4c2762f787d9e7cb1503042ba75b9;hp=edc147473ffd9c03790dc4502b893823f44a9ec4

The old bug ticket for the discussion:
https://oss.oracle.com/bugzilla/show_bug.cgi?id=1235

This fix is specifically for ocfs2-1.4, but Mark once mentioned that
the BUG() there can be removed if we have a good explanation for this
sort of behavior, is it time to have it in mainline?

Thanks,
-Jeff
On 09/03/2013 04:32 AM, richard -rw- weinberger wrote:

 Hi!
 
 Today one of my computers crashed with the following panic.
 The machine is heavily using reflinks.
 Looks like it managed to hit a CATCH_BH_JBD_RACES error check.
 
 3[37628.934461] (reflink,512,0):ocfs2_reflink_ioctl:4459 ERROR: status = -17
 3[37628.943160] (kworker/u:2,809,1):ocfs2_read_blocks:285 ERROR:
 block 532737 had the JBD bit set while I was in lock_buffer!
 4[37628.943169] [ cut here ]
 2[37628.944464] kernel BUG at
 /home/rw/work/ssworkstation/maker/_source/kernel/fs/ocfs2/buffer_head_io.c:286!
 4[37628.945134] invalid opcode:  [#1] PREEMPT SMP
 4[37628.945809] CPU 1
 4[37628.945817] Pid: 809, comm: kworker/u:2 Not tainted 3.8.4+ #46
/
 4[37628.947167] RIP: 0010:[8125afa0]  [8125afa0]
 ocfs2_read_blocks+0x410/0x610
 4[37628.947880] RSP: 0018:880234631908  EFLAGS: 00010292
 4[37628.948593] RAX: 006d RBX: 0001 RCX:
 0067
 4[37628.949317] RDX: 0048 RSI: 0046 RDI:
 8214c0dc
 Oops#1 Part3
 4[37628.950037] RBP: 880234631988 R08: 000a R09:
 d490
 4[37628.950758] R10:  R11: 0004 R12:
 00082101
 4[37628.951477] R13: 880233147980 R14:  R15:
 880216ca2208
 4[37628.952201] FS:  ()
 GS:88023e28() knlGS:
 4[37628.952936] CS:  0010 DS:  ES:  CR0: 80050033
 4[37628.953669] CR2: 7fe7ea29fc62 CR3: 06c0b000 CR4:
 000407e0
 4[37628.954421] DR0:  DR1:  DR2:
 
 4[37628.955176] DR3:  DR6: 0ff0 DR7:
 0400
 4[37628.955925] Process kworker/u:2 (pid: 809, threadinfo
 88023463, task 880234ba86e0)
 4[37628.956689] Stack:
 4[37628.957461]  00082101 ea0008900880 880234631948
 1000
 4[37628.958250]  00082102 00082102 81295eb0
 
 Oops#1 Part2
 4[37628.959044]  88023428c000 0001 
 8802346319f0
 4[37628.959844] Call Trace:
 4[37628.960639]  [81295eb0] ? ocfs2_read_refcount_block+0x50/0x50
 4[37628.961453]  [81295e8b] ocfs2_read_refcount_block+0x2b/0x50
 4[37628.962249]  [81297417] ocfs2_get_refcount_tree+0xa7/0x350
 4[37628.963042]  [8115c6d1] ? __find_get_block+0xa1/0x1e0
 4[37628.963835]  [8129c5e8] ocfs2_lock_refcount_tree+0x48/0x4f0
 4[37628.964645]  [8124fccb] ocfs2_remove_btree_range+0xab/0xb30
 4[37628.965452]  [81253a99] ocfs2_commit_truncate+0x139/0x550
 4[37628.966247]  [812844c0] ? ocfs2_extend_trans+0x1c0/0x1c0
 4[37628.967049]  [8127e36e] ocfs2_evict_inode+0x89e/0x2530
 4[37628.967851]  [81154a78] ? __inode_wait_for_writeback+0x68/0xc0
 4[37628.968645]  [8114878f] evict+0xaf/0x1b0
 4[37628.969432]  [81149495] iput+0x105/0x1a0
 Oops#1 Part1
 4[37628.970213]  [8125b557] 
 __ocfs2_drop_dl_inodes.isra.14+0x47/0x80
 4[37628.971002]  [8125bd65] ocfs2_drop_dl_inodes+0x25/0xa0
 4[37628.971788]  [81087dc7] process_one_work+0x147/0x470
 4[37628.972580]  [810884bd] worker_thread+0x14d/0x3f0
 4[37628.973381]  [81088370] ? rescuer_thread+0x240/0x240
 4[37628.974175]  [8108db5b] kthread+0xbb/0xc0
 4[37628.974960]  [8108daa0] ? __kthread_parkme+0x80/0x80
 4[37628.975747]  [817dd9ec] ret_from_fork+0x7c/0xb0
 4[37628.976529]  [8108daa0] ? __kthread_parkme+0x80/0x80
 4[37628.977307] Code: 0f 0b 4c 89 ff e8 11 0b f0 ff e9 f2 fc ff ff
 48 b8 00 00 00 00 00 00 00 10 48 85 05 2b 58 9d 00 74 09 48 85 05 c2
 79 f4 00 74 02 0f 0b 65 48 8b 14 25 70 b8 00 00 48 8d 82 28 e0 ff ff
 4d 8b 67
 1[37628.979053] RIP  [8125afa0] ocfs2_read_blocks+0x410/0x610
 4[37628.979893]  RSP 880234631908
 4[37628.983420] ---[ end trace c03a48f44cf30d5e ]---
 


--
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] [PATCH] checkpatch: Add comment about updating Documentation/CodingStyle

[Fengguang Wu]

On Mon, Sep 02, 2013 at 08:16:45PM -0700, Josh Triplett wrote:
 On Tue, Sep 03, 2013 at 10:46:40AM +0800, Fengguang Wu wrote:
  On Mon, Sep 02, 2013 at 06:52:45PM -0700, Joe Perches wrote:
   On Mon, 2013-09-02 at 18:34 -0700, Josh Triplett wrote:
CONFIG_EXPERIMENTAL
CVS_KEYWORD
   
   OK, but shrug
 [...]
  Thanks for both of your suggestions! I'll add the commonly agreed ones:
  
  +INVALID_UTF8
  +LINUX_VERSION_CODE
  +MISSING_EOF_NEWLINE
  +HEXADECIMAL_BOOLEAN_TEST
  +ALLOC_ARRAY_ARGS
  +CONST_STRUCT
  +CONSIDER_KSTRTO
  
  And remove the duplicate one (good catch, Josh!)
  
  -KREALLOC_ARG_REUSE
 
 You missed CONFIG_EXPERIMENTAL and CVS_KEYWORD; see above.

OK, added, thanks!

Cheers,
Fengguang
--
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/8] Drop support for Renesas H8/300 architecture

[Guenter Roeck]

On 09/02/2013 07:53 PM, Chen Gang F T wrote:
 Hello Guenter Roeck:
 
 
 I don't care about whether I am in cc mailing list, but at least,
 please help confirm 2 things:
 
Is what I had done for h8300 just making wastes and noisy in kernel and 
 related sub-system mailing list ?
 
and is the disccusion about h8300 between us also wastes and noisy in 
 kernel mailing list ?
 

It raised my awareness of the status of h8300 maintenance,
so I would not see it as noise or waste. I might have suggested
a different target for your efforts, but that is your choice to make,
not mine.

On the code review side, I had suggested that you should not add new
ifdefs into code, much less unnecessary ones. Your counter-argument
was that you wanted to follow the existing coding style in the file
in question. To me, that argument is along the line of the coding
style in this file is bad, let's do more of it.
That doesn't make much sense to me, so I did not bother to respond.
Setting that aside, it is not up to me to approve or reject your patches.
Whoever does that would be the one you have to convince.

Guenter

--
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: [guv v2 04/31] net: Replace __get_cpu_var uses

[David Miller]

From: David Howells dhowe...@redhat.com
Date: Mon, 02 Sep 2013 22:35:06 +0100

 Would it be possible to use __thread annotations for per-CPU
 variables, I wonder?

Paul Mackerras tried it on powerpc and you can't do it.

The problem is that there is no way to tell the compiler that sched()
and similar (potentially) change the thread pointer base.

It really will cache pre-computed __thread pointer calculations across
sched().
--
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 2/4] mm/hwpoison: fix miss catch transparent huge page

[Chen Gong]

On Tue, Sep 03, 2013 at 07:36:44AM +0800, Wanpeng Li wrote:
 Date: Tue,  3 Sep 2013 07:36:44 +0800
 From: Wanpeng Li liw...@linux.vnet.ibm.com
 To: Andrew Morton a...@linux-foundation.org
 Cc: Andi Kleen a...@firstfloor.org, Fengguang Wu
  fengguang...@intel.com, Naoya Horiguchi n-horigu...@ah.jp.nec.com,
  Tony Luck tony.l...@intel.com, gong.c...@linux.intel.com,
  linux...@kvack.org, linux-kernel@vger.kernel.org, Wanpeng Li
  liw...@linux.vnet.ibm.com
 Subject: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page 
 X-Mailer: git-send-email 1.7.5.4
 
 Changelog:
  *v1 - v2: reverse PageTransHuge(page)  !PageHuge(page) check 
 
 PageTransHuge() can't guarantee the page is transparent huge page since it 
 return true for both transparent huge and hugetlbfs pages. This patch fix 
 it by check the page is also !hugetlbfs page.
 
 Before patch:
 
 [  121.571128] Injecting memory failure at pfn 23a200
 [  121.571141] MCE 0x23a200: huge page recovery: Delayed
 [  140.355100] MCE: Memory failure is now running on 0x23a200
 
 After patch:
 
 [   94.290793] Injecting memory failure at pfn 23a000
 [   94.290800] MCE 0x23a000: huge page recovery: Delayed
 [  105.722303] MCE: Software-unpoisoned page 0x23a000
 
 Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
 ---
  mm/memory-failure.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/mm/memory-failure.c b/mm/memory-failure.c
 index e28ee77..b114570 100644
 --- a/mm/memory-failure.c
 +++ b/mm/memory-failure.c
 @@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
 - if (PageTransHuge(page)) {
 + if (!PageHuge(page)  PageTransHuge(page)) {
   pr_info(MCE: Memory failure is now running on %#lx\n, pfn);
   return 0;
   }

Not sure which git tree should be used to apply this patch series? I assume
this patch series follows this link: https://lkml.org/lkml/2013/8/26/76.

In unpoison_memory we already have
if (PageHuge(page)) {
...
return 0;
}
so it looks like this patch is redundant.


signature.asc
Description: Digital signature

Re: [PATCH v4:No Change] xHCI:Fixing xhci_readl definition and function call

[Kumar Gaurav]

I tried applying this patch on linux-next and it applies well.
i used
git apply --apply



On Saturday 31 August 2013 11:02 PM, Kumar Gaurav wrote:

This patch redefine function xhci_readl. xhci_readl function doesn't use 
xhci_hcd argument.
Hence there is no need of keeping it in the function arguments.

Redefining this function breaks other functions which calls this function.
This phatch also correct those calls in xhci driver.

Signed-off-by: Kumar Gaurav kumargauravgup...@gmail.com
---
  drivers/usb/host/xhci-dbg.c  |   36 -
  drivers/usb/host/xhci-hub.c  |   72 -
  drivers/usb/host/xhci-mem.c  |   20 -
  drivers/usb/host/xhci-ring.c |   12 +++---
  drivers/usb/host/xhci.c  |   92 +-
  drivers/usb/host/xhci.h  |3 +-
  6 files changed, 117 insertions(+), 118 deletions(-)

diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 73503a8..229e312 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -32,7 +32,7 @@ void xhci_dbg_regs(struct xhci_hcd *xhci)
  
  	xhci_dbg(xhci, // xHCI capability registers at %p:\n,

xhci-cap_regs);
-   temp = xhci_readl(xhci, xhci-cap_regs-hc_capbase);
+   temp = xhci_readl(xhci-cap_regs-hc_capbase);
xhci_dbg(xhci, // @%p = 0x%x (CAPLENGTH AND HCIVERSION)\n,
xhci-cap_regs-hc_capbase, temp);
xhci_dbg(xhci, //   CAPLENGTH: 0x%x\n,
@@ -44,13 +44,13 @@ void xhci_dbg_regs(struct xhci_hcd *xhci)
  
  	xhci_dbg(xhci, // xHCI operational registers at %p:\n, xhci-op_regs);
  
-	temp = xhci_readl(xhci, xhci-cap_regs-run_regs_off);

+   temp = xhci_readl(xhci-cap_regs-run_regs_off);
xhci_dbg(xhci, // @%p = 0x%x RTSOFF\n,
xhci-cap_regs-run_regs_off,
(unsigned int) temp  RTSOFF_MASK);
xhci_dbg(xhci, // xHCI runtime registers at %p:\n, xhci-run_regs);
  
-	temp = xhci_readl(xhci, xhci-cap_regs-db_off);

+   temp = xhci_readl(xhci-cap_regs-db_off);
xhci_dbg(xhci, // @%p = 0x%x DBOFF\n, xhci-cap_regs-db_off, temp);
xhci_dbg(xhci, // Doorbell array at %p:\n, xhci-dba);
  }
@@ -61,7 +61,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
  
  	xhci_dbg(xhci, xHCI capability registers at %p:\n, xhci-cap_regs);
  
-	temp = xhci_readl(xhci, xhci-cap_regs-hc_capbase);

+   temp = xhci_readl(xhci-cap_regs-hc_capbase);
xhci_dbg(xhci, CAPLENGTH AND HCIVERSION 0x%x:\n,
(unsigned int) temp);
xhci_dbg(xhci, CAPLENGTH: 0x%x\n,
@@ -69,7 +69,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci, HCIVERSION: 0x%x\n,
(unsigned int) HC_VERSION(temp));
  
-	temp = xhci_readl(xhci, xhci-cap_regs-hcs_params1);

+   temp = xhci_readl(xhci-cap_regs-hcs_params1);
xhci_dbg(xhci, HCSPARAMS 1: 0x%x\n,
(unsigned int) temp);
xhci_dbg(xhci,   Max device slots: %u\n,
@@ -79,7 +79,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci,   Max ports: %u\n,
(unsigned int) HCS_MAX_PORTS(temp));
  
-	temp = xhci_readl(xhci, xhci-cap_regs-hcs_params2);

+   temp = xhci_readl(xhci-cap_regs-hcs_params2);
xhci_dbg(xhci, HCSPARAMS 2: 0x%x\n,
(unsigned int) temp);
xhci_dbg(xhci,   Isoc scheduling threshold: %u\n,
@@ -87,7 +87,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci,   Maximum allowed segments in event ring: %u\n,
(unsigned int) HCS_ERST_MAX(temp));
  
-	temp = xhci_readl(xhci, xhci-cap_regs-hcs_params3);

+   temp = xhci_readl(xhci-cap_regs-hcs_params3);
xhci_dbg(xhci, HCSPARAMS 3 0x%x:\n,
(unsigned int) temp);
xhci_dbg(xhci,   Worst case U1 device exit latency: %u\n,
@@ -95,14 +95,14 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci,   Worst case U2 device exit latency: %u\n,
(unsigned int) HCS_U2_LATENCY(temp));
  
-	temp = xhci_readl(xhci, xhci-cap_regs-hcc_params);

+   temp = xhci_readl(xhci-cap_regs-hcc_params);
xhci_dbg(xhci, HCC PARAMS 0x%x:\n, (unsigned int) temp);
xhci_dbg(xhci,   HC generates %s bit addresses\n,
HCC_64BIT_ADDR(temp) ? 64 : 32);
/* FIXME */
xhci_dbg(xhci,   FIXME: more HCCPARAMS debugging\n);
  
-	temp = xhci_readl(xhci, xhci-cap_regs-run_regs_off);

+   temp = xhci_readl(xhci-cap_regs-run_regs_off);
xhci_dbg(xhci, RTSOFF 0x%x:\n, temp  RTSOFF_MASK);
  }
  
@@ -110,7 +110,7 @@ static void xhci_print_command_reg(struct xhci_hcd *xhci)

  {
u32 temp;
  
-	temp = xhci_readl(xhci, xhci-op_regs-command);

+   temp = xhci_readl(xhci-op_regs-command);
xhci_dbg(xhci, USBCMD 0x%x:\n, temp);

[PATCH 0/2] audit: fix soft lockups and udevd errors when audit is overrun

[Chuck Anderson]

The two patches that follow in separate emails resolve soft lockups and
udevd reported errors that prevented a large memory 3.8 system from booting.

The patches are based on 3.11-rc7.

I believe it is the same issue recently posted as:

  [RFC] audit: avoid soft lockup in audit_log_start()
  https://lkml.org/lkml/2013/8/28/626

The first patch:

  audit: fix soft lockups due to loop in audit_log_start() when 
audit_backlog_limit exceeded


fixes a bug in kernel/audit that caused many soft lockups during boot:

  BUG: soft lockup - CPU#66 stuck for 22s! [udevd:9559]
  RIP: 0010:[810d1d06]  [810d1d06] 
audit_log_start+0xe6/0x350

  Call Trace:
   [8108ea30] ? try_to_wake_up+0x2d0/0x2d0
   [810d8d6f] audit_log_exit+0x3f/0x590
   [810d975d] __audit_syscall_exit+0x28d/0x2c0
   [815e0440] sysret_audit+0x17/0x21

The second patch:

  audit: Two efficiency fixes for audit mechanism

prevents these and similar error messages repeated often during boot:

  udevd[876]: worker [887] unexpectedly returned with status 0x0100
  udevd[876]: worker [887] failed while handling 
'/devices/pci:00/:00:03.0/:40:00.0'

  udevd[876]: worker [880] unexpectedly returned with status 0x0100
  udevd[876]: worker [880] failed while handling 
'/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/event1'


  udevadm settle - timeout of 180 seconds reached, the event queue 
contains:

/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/event1 (3995)
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT3F0D:00 (4034)

  audit: audit_backlog=258  audit_backlog_limit=256
  audit: audit_lost=1 audit_rate_limit=0 audit_backlog_limit=256
--
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 1/2] audit: fix soft lockups due to loop in audit_log_start() wh,en audit_backlog_limit exceeded

[Chuck Anderson]

audit: fix softlockups due to loop in audit_log_start() when 
audit_backlog_limit exceeded


author: Dan Duval dan.du...@oracle.com

This patch fixes a bug in kernel/audit that can cause many soft lockups
and prevent the boot of a large memory 3.8 system:

  BUG: soft lockup - CPU#66 stuck for 22s! [udevd:9559]
  RIP: 0010:[810d1d06]  [810d1d06] 
audit_log_start+0xe6/0x350

  Call Trace:
   [8108ea30] ? try_to_wake_up+0x2d0/0x2d0
   [810d8d6f] audit_log_exit+0x3f/0x590
   [810d975d] __audit_syscall_exit+0x28d/0x2c0
   [815e0440] sysret_audit+0x17/0x21

audit_log_start() will call wait_for_auditd() to delay returning an
audit_buffer if there are too many SKBs on audit_skb_queue.
wait_for_auditd() puts itself on the audit_backlog_wait queue and
sleeps for sleep_time jiffies or until it is (normally) woken when
kauditd takes an SKB off of audit_skb_queue.  wait_for_auditd() returns
to audit_log_start() which checks to see if audit_skb_queue still has
too many SKBs.  If there are still too many, audit_log_start() will
continue to call wait_for_auditd() in a loop until
audit_backlog_wait_time has passed.  audit_log_start() will then
complain (backlog limit exceeded); set audit_backlog_wait_time
to NULL so other waiters will fall out of the loop when woken up; wake
up any waiters in wait_for_auditd(); return NULL which tells the caller
that an audit_buffer could not be allocated.

A bug in audit_log_start() prevents it from breaking out of the
wait_for_auditd() loop when audit_backlog_wait_time has passed.
Instead, it will loop in the audit_skb_queue-is-too-long while-loop
eventually causing a soft lockup.  There can (and most likely will)
be multiple threads looping.  The fix is to continue in the while-loop
only if sleep_time was greater than 0 (audit_backlog_wait_time has not
passed).

Another bug in audit_log_start() prevents audit_backlog_wait_time from
working as expected.  audit_backlog_wait_time is normally the time
period that audit_log_start() will wait for the number of SKBs on
audit_skb_queue to fall below the too-many threshold.  If
audit_backlog_wait_time passes, audit_log_start() will set it to
audit_backlog_wait_overflow, which is zero, and wake up any waiters in
wait_for_auditd().  audit_backlog_wait_time is now zero so the waiters
will fall out of the loop when they return to audit_log_start().  That
is expected behavior.  But audit_backlog_wait_time is not reset to its
initial value when audit_skb_queue's length is no longer too long.
Subsequent calls to audit_log_start() when audit_skb_queue is too long
will not wait in wait_for_auditd(), instead returning NULL.  The fix
is to set audit_backlog_wait_time to its initial value when
audit_skb_queue passes the size test, potentially resetting it.

A third issue is to have both audit_log_start() and wait_for_auditd()
use the same limit value for the length of audit_skb_queue.  It isn't
necessary today but (1) assumptions may change in the future and (2)
is one less oddity for a reader to have to verify.

Signed-off-by: Dan Duval dan.du...@oracle.com
Signed-off-by: Chuck Anderson chuck.ander...@oracle.com
---
 kernel/audit.c |   28 
 1 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 91e53d0..9a78dde 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -103,9 +103,11 @@ static int audit_rate_limit;

 /* Number of outstanding audit_buffers allowed. */
 static int audit_backlog_limit = 64;
-static int audit_backlog_wait_time = 60 * HZ;
 static int audit_backlog_wait_overflow = 0;

+#define AUDIT_BACKLOG_WAIT_TIME (60 * HZ)
+static int audit_backlog_wait_time = AUDIT_BACKLOG_WAIT_TIME;
+
 /* The identity of the user shutting down the audit system. */
 kuid_t audit_sig_uid = INVALID_UID;
 pid_t  audit_sig_pid = -1;
@@ -1053,14 +1055,14 @@ static inline void audit_get_stamp(struct 
audit_context

*ctx,
 /*
  * Wait for auditd to drain the queue a little
  */
-static void wait_for_auditd(unsigned long sleep_time)
+static void wait_for_auditd(unsigned long sleep_time, int limit)
 {
DECLARE_WAITQUEUE(wait, current);
set_current_state(TASK_UNINTERRUPTIBLE);
add_wait_queue(audit_backlog_wait, wait);

if (audit_backlog_limit 
-   skb_queue_len(audit_skb_queue)  audit_backlog_limit)
+   skb_queue_len(audit_skb_queue)  limit)
schedule_timeout(sleep_time);

__set_current_state(TASK_RUNNING);
@@ -1095,8 +1097,8 @@ struct audit_buffer *audit_log_start(struct 
audit_context

*ctx, gfp_t gfp_mask,
struct audit_buffer *ab = NULL;
struct timespec t;
unsigned intuninitialized_var(serial);
-   int reserve;
unsigned long timeout_start = jiffies;
+   int limit;

if (audit_initialized != AUDIT_INITIALIZED)
return NULL;
@@ -1104,22 +1106,22 @@ struct 

[PATCH v8 02/10] tracing: Add basic event trigger framework

[Tom Zanussi]

Add a 'trigger' file for each trace event, enabling 'trace event
triggers' to be set for trace events.

'trace event triggers' are patterned after the existing 'ftrace
function triggers' implementation except that triggers are written to
per-event 'trigger' files instead of to a single file such as the
'set_ftrace_filter' used for ftrace function triggers.

The implementation is meant to be entirely separate from ftrace
function triggers, in order to keep the respective implementations
relatively simple and to allow them to diverge.

The event trigger functionality is built on top of SOFT_DISABLE
functionality.  It adds a TRIGGER_MODE bit to the ftrace_event_file
flags which is checked when any trace event fires.  Triggers set for a
particular event need to be checked regardless of whether that event
is actually enabled or not - getting an event to fire even if it's not
enabled is what's already implemented by SOFT_DISABLE mode, so trigger
mode directly reuses that.  Event trigger essentially inherit the soft
disable logic in __ftrace_event_enable_disable() while adding a bit of
logic and trigger reference counting via tm_ref on top of that in a
new trace_event_trigger_enable_disable() function.  Because the base
__ftrace_event_enable_disable() code now needs to be invoked from
outside trace_events.c, a wrapper is also added for those usages.

The triggers for an event are actually invoked via a new function,
event_triggers_call(), and code is also added to invoke them for
ftrace_raw_event calls as well as syscall events.

The main part of the patch creates a new trace_events_trigger.c file
to contain the trace event triggers implementation.

The standard open, read, and release file operations are implemented
here.

The open() implementation sets up for the various open modes of the
'trigger' file.  It creates and attaches the trigger iterator and sets
up the command parser.  If opened for reading set up the trigger
seq_ops.

The read() implementation parses the event trigger written to the
'trigger' file, looks up the trigger command, and passes it along to
that event_command's func() implementation for command-specific
processing.

The release() implementation does whatever cleanup is needed to
release the 'trigger' file, like releasing the parser and trigger
iterator, etc.

A couple of functions for event command registration and
unregistration are added, along with a list to add them to and a mutex
to protect them, as well as an (initially empty) registration function
to add the set of commands that will be added by future commits, and
call to it from the trace event initialization code.

also added are a couple trigger-specific data structures needed for
these implementations such as a trigger iterator and a struct for
trigger-specific data.

A couple structs consisting mostly of function meant to be implemented
in command-specific ways, event_command and event_trigger_ops, are
used by the generic event trigger command implementations.  They're
being put into trace.h alongside the other trace_event data structures
and functions, in the expectation that they'll be needed in several
trace_event-related files such as trace_events_trigger.c and
trace_events.c.

The event_command.func() function is meant to be called by the trigger
parsing code in order to add a trigger instance to the corresponding
event.  It essentially coordinates adding a live trigger instance to
the event, and arming the triggering the event.

Every event_command func() implementation essentially does the
same thing for any command:

   - choose ops - use the value of param to choose either a number or
 count version of event_trigger_ops specific to the command
   - do the register or unregister of those ops
   - associate a filter, if specified, with the triggering event

The reg() and unreg() ops allow command-specific implementations for
event_trigger_op registration and unregistration, and the
get_trigger_ops() op allows command-specific event_trigger_ops
selection to be parameterized.  When a trigger instance is added, the
reg() op essentially adds that trigger to the triggering event and
arms it, while unreg() does the opposite.  The set_filter() function
is used to associate a filter with the trigger - if the command
doesn't specify a set_filter() implementation, the command will ignore
filters.

Each command has an associated trigger_type, which serves double duty,
both as a unique identifier for the command as well as a value that
can be used for setting a trigger mode bit during trigger invocation.

The signature of func() adds a pointer to the event_command struct,
used to invoke those functions, along with a command_data param that
can be passed to the reg/unreg functions.  This allows func()
implementations to use command-specific blobs and supports code
re-use.

The event_trigger_ops.func() command corrsponds to the trigger 'probe'
function that gets called when the triggering event is actually
invoked.  The other 

[PATCH v8 03/10] tracing: Add 'traceon' and 'traceoff' event trigger commands

[Tom Zanussi]

Add 'traceon' and 'traceoff' event_command commands.  traceon and
traceoff event triggers are added by the user via these commands in a
similar way and using practically the same syntax as the analagous
'traceon' and 'traceoff' ftrace function commands, but instead of
writing to the set_ftrace_filter file, the traceon and traceoff
triggers are written to the per-event 'trigger' files:

echo 'traceon'  .../tracing/events/somesys/someevent/trigger
echo 'traceoff'  .../tracing/events/somesys/someevent/trigger

The above command will turn tracing on or off whenever someevent is
hit.

This also adds a 'count' version that limits the number of times the
command will be invoked:

echo 'traceon:N'  .../tracing/events/somesys/someevent/trigger
echo 'traceoff:N'  .../tracing/events/somesys/someevent/trigger

Where N is the number of times the command will be invoked.

The above commands will will turn tracing on or off whenever someevent
is hit, but only N times.

Some common register/unregister_trigger() implementations of the
event_command reg()/unreg() callbacks are also provided, which add and
remove trigger instances to the per-event list of triggers, and
arm/disarm them as appropriate.  event_trigger_callback() is a
general-purpose event_command func() implementation that orchestrates
command parsing and registration for most normal commands.

Most event commands will use these, but some will override and
possibly reuse them.

The event_trigger_init(), event_trigger_free(), and
event_trigger_print() functions are meant to be common implementations
of the event_trigger_ops init(), free(), and print() ops,
respectively.

Most trigger_ops implementations will use these, but some will
override and possibly reuse them.

Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com
---
 include/linux/ftrace_event.h|   1 +
 kernel/trace/trace_events_trigger.c | 436 
 2 files changed, 437 insertions(+)

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 34ae1d4..a14650b 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -318,6 +318,7 @@ struct ftrace_event_file {
 
 enum event_trigger_type {
ETT_NONE= (0),
+   ETT_TRACE_ONOFF = (1  0),
 };
 
 extern void destroy_preds(struct ftrace_event_call *call);
diff --git a/kernel/trace/trace_events_trigger.c 
b/kernel/trace/trace_events_trigger.c
index 85319cf..5388d55 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -28,6 +28,13 @@
 static LIST_HEAD(trigger_commands);
 static DEFINE_MUTEX(trigger_cmd_mutex);
 
+static void
+trigger_data_free(struct event_trigger_data *data)
+{
+   synchronize_sched(); /* make sure current triggers exit before free */
+   kfree(data);
+}
+
 void event_triggers_call(struct ftrace_event_file *file)
 {
struct event_trigger_data *data;
@@ -215,6 +222,121 @@ const struct file_operations event_trigger_fops = {
.release = event_trigger_release,
 };
 
+/*
+ * Currently we only register event commands from __init, so mark this
+ * __init too.
+ */
+static __init int register_event_command(struct event_command *cmd,
+struct list_head *cmd_list,
+struct mutex *cmd_list_mutex)
+{
+   struct event_command *p;
+   int ret = 0;
+
+   mutex_lock(cmd_list_mutex);
+   list_for_each_entry(p, cmd_list, list) {
+   if (strcmp(cmd-name, p-name) == 0) {
+   ret = -EBUSY;
+   goto out_unlock;
+   }
+   }
+   list_add(cmd-list, cmd_list);
+ out_unlock:
+   mutex_unlock(cmd_list_mutex);
+
+   return ret;
+}
+
+/*
+ * Currently we only unregister event commands from __init, so mark
+ * this __init too.
+ */
+static __init int unregister_event_command(struct event_command *cmd,
+  struct list_head *cmd_list,
+  struct mutex *cmd_list_mutex)
+{
+   struct event_command *p, *n;
+   int ret = -ENODEV;
+
+   mutex_lock(cmd_list_mutex);
+   list_for_each_entry_safe(p, n, cmd_list, list) {
+   if (strcmp(cmd-name, p-name) == 0) {
+   ret = 0;
+   list_del_init(p-list);
+   goto out_unlock;
+   }
+   }
+ out_unlock:
+   mutex_unlock(cmd_list_mutex);
+
+   return ret;
+}
+
+/**
+ * event_trigger_print - generic event_trigger_ops @print implementation
+ *
+ * Common implementation for event triggers to print themselves.
+ *
+ * Usually wrapped by a function that simply sets the @name of the
+ * trigger command and then invokes this.
+ */
+static int
+event_trigger_print(const char *name, struct seq_file *m,
+   void *data, char *filter_str)
+{
+   long count = (long)data;
+
+   

Re: [PATCH v2 0/8] Drop support for Renesas H8/300 architecture

[Chen Gang F T]

On 09/03/2013 11:26 AM, Guenter Roeck wrote:
 On 09/02/2013 07:53 PM, Chen Gang F T wrote:
 Hello Guenter Roeck:


 I don't care about whether I am in cc mailing list, but at least,
 please help confirm 2 things:

Is what I had done for h8300 just making wastes and noisy in kernel and 
 related sub-system mailing list ?

and is the disccusion about h8300 between us also wastes and noisy in 
 kernel mailing list ?

 
 It raised my awareness of the status of h8300 maintenance,
 so I would not see it as noise or waste. I might have suggested
 a different target for your efforts, but that is your choice to make,
 not mine.
 

OK, thank you for your confirmation, I plan to scan all architectures
one by one with allmodconfig.

Hmm... if suitable, next, when I focus one of architectures, I also cc
to you, if it can be removed, please let me know in time, so can avoid
sending waste mails to mailing list.

I plan to try one of architectures within arc, hexagon, and metag. I
will begin at 2013-09-20 (or later), if some (or all) of them can be
removed, please let me know, thanks.


 On the code review side, I had suggested that you should not add new
 ifdefs into code, much less unnecessary ones. Your counter-argument
 was that you wanted to follow the existing coding style in the file
 in question. To me, that argument is along the line of the coding
 style in this file is bad, let's do more of it.

Hmm... in fact, I will not say whether the code style is good or bad. I
mainly focus on to try to avoid multiple code styles within one file.

  extreme sample: let 'kernel code style' and 'gcc code style' in one file, 
that will make the code very ugly.

 That doesn't make much sense to me, so I did not bother to respond.
 Setting that aside, it is not up to me to approve or reject your patches.
 Whoever does that would be the one you have to convince.
 

OK, I can understand, and now it seems it can be canceled, since h8300
has been removed.

 Guenter
 


Thanks.
-- 
Chen Gang
--
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 v8 09/10] tracing: Add documentation for trace event triggers

[Tom Zanussi]

Provide a basic overview of trace event triggers and document the
available trigger commands, along with a few simple examples.

Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com
---
 Documentation/trace/events.txt | 207 +
 1 file changed, 207 insertions(+)

diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
index 37732a2..c94435d 100644
--- a/Documentation/trace/events.txt
+++ b/Documentation/trace/events.txt
@@ -287,3 +287,210 @@ their old filters):
 prev_pid == 0
 # cat sched_wakeup/filter
 common_pid == 0
+
+6. Event triggers
+=
+
+Trace events can be made to conditionally invoke trigger 'commands'
+which can take various forms and are described in detail below;
+examples would be enabling or disabling other trace events or invoking
+a stack trace whenever the trace event is hit.  Whenever a trace event
+with attached triggers is invoked, the set of trigger commands
+associated with that event is invoked.  Any given trigger can
+additionally have an event filter of the same form as described in
+section 5 (Event filtering) associated with it - the command will only
+be invoked if the event being invoked passes the associated filter.
+If no filter is associated with the trigger, it always passes.
+
+Triggers are added to and removed from a particular event by writing
+trigger expressions to the 'trigger' file for the given event.
+
+A given event can have any number of triggers associated with it,
+subject to any restrictions that individual commands may have in that
+regard.
+
+Event triggers are implemented on top of soft mode, which means that
+whenever a trace event has one or more triggers associated with it,
+the event is activated even if it isn't actually enabled, but is
+disabled in a soft mode.  That is, the tracepoint will be called,
+but just will not be traced, unless of course it's actually enabled.
+This scheme allows triggers to be invoked even for events that aren't
+enabled, and also allows the current event filter implementation to be
+used for conditionally invoking triggers.
+
+The syntax for event triggers is roughly based on the syntax for
+set_ftrace_filter 'ftrace filter commands' (see the 'Filter commands'
+section of Documentation/trace/ftrace.txt), but there are major
+differences and the implementation isn't currently tied to it in any
+way, so beware about making generalizations between the two.
+
+6.1 Expression syntax
+-
+
+Triggers are added by echoing the command to the 'trigger' file:
+
+  # echo 'command[:count] [if filter]'  trigger
+
+Triggers are removed by echoing the same command but starting with '!'
+to the 'trigger' file:
+
+  # echo '!command[:count] [if filter]'  trigger
+
+The [if filter] part isn't used in matching commands when removing, so
+leaving that off in a '!' command will accomplish the same thing as
+having it in.
+
+The filter syntax is the same as that described in the 'Event
+filtering' section above.
+
+For ease of use, writing to the trigger file using '' currently just
+adds or removes a single trigger and there's no explicit '' support
+('' actually behaves like '') or truncation support to remove all
+triggers (you have to use '!' for each one added.)
+
+6.2 Supported trigger commands
+--
+
+The following commands are supported:
+
+- enable_event/disable_event
+
+  These commands can enable or disable another trace event whenever
+  the triggering event is hit.  When these commands are registered,
+  the other trace event is activated, but disabled in a soft mode.
+  That is, the tracepoint will be called, but just will not be traced.
+  The event tracepoint stays in this mode as long as there's a trigger
+  in effect that can trigger it.
+
+  For example, the following trigger causes kmalloc events to be
+  traced when a read system call is entered, and the :1 at the end
+  specifies that this enablement happens only once:
+
+  # echo 'enable_event:kmem:kmalloc:1'  \
+  /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
+
+  The following trigger causes kmalloc events to stop being traced
+  when a read system call exits.  This disablement happens on every
+  read system call exit:
+
+  # echo 'disable_event:kmem:kmalloc'  \
+  /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger
+
+  The format is:
+
+  enable_event:system:event[:count]
+  disable_event:system:event[:count]
+
+  To remove the above commands:
+
+  # echo '!enable_event:kmem:kmalloc:1'  \
+  /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
+
+  # echo '!disable_event:kmem:kmalloc'  \
+  /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger
+
+  Note that there can be any number of enable/disable_event triggers
+  per triggering event, but there can only be one trigger per
+  triggered event. e.g. sys_enter_read can have triggers enabling both
+  kmem:kmalloc and 

[PATCH v8 06/10] tracing: Add 'enable_event' and 'disable_event' event trigger commands

[Tom Zanussi]

Add 'enable_event' and 'disable_event' event_command commands.

enable_event and disable_event event triggers are added by the user
via these commands in a similar way and using practically the same
syntax as the analagous 'enable_event' and 'disable_event' ftrace
function commands, but instead of writing to the set_ftrace_filter
file, the enable_event and disable_event triggers are written to the
per-event 'trigger' files:

echo 'enable_event:system:event'  .../othersys/otherevent/trigger
echo 'disable_event:system:event'  .../othersys/otherevent/trigger

The above commands will enable or disable the 'system:event' trace
events whenever the othersys:otherevent events are hit.

This also adds a 'count' version that limits the number of times the
command will be invoked:

echo 'enable_event:system:event:N'  .../othersys/otherevent/trigger
echo 'disable_event:system:event:N'  .../othersys/otherevent/trigger

Where N is the number of times the command will be invoked.

The above commands will will enable or disable the 'system:event'
trace events whenever the othersys:otherevent events are hit, but only
N times.

This also makes the find_event_file() helper function extern, since
it's useful to use from other places, such as the event triggers code,
so make it accessible.

Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com
---
 include/linux/ftrace_event.h|   1 +
 kernel/trace/trace.h|   4 +
 kernel/trace/trace_events.c |   2 +-
 kernel/trace/trace_events_trigger.c | 379 
 4 files changed, 385 insertions(+), 1 deletion(-)

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 31750df..8e87302 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -321,6 +321,7 @@ enum event_trigger_type {
ETT_TRACE_ONOFF = (1  0),
ETT_SNAPSHOT= (1  1),
ETT_STACKTRACE  = (1  2),
+   ETT_EVENT_ENABLE= (1  3),
 };
 
 extern void destroy_preds(struct ftrace_event_call *call);
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index f032dd8..3941499 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1016,6 +1016,10 @@ extern void trace_event_enable_cmd_record(bool enable);
 extern int event_trace_add_tracer(struct dentry *parent, struct trace_array 
*tr);
 extern int event_trace_del_tracer(struct trace_array *tr);
 
+extern struct ftrace_event_file *find_event_file(struct trace_array *tr,
+const char *system,
+const char *event);
+
 static inline void *event_file_data(struct file *filp)
 {
return ACCESS_ONCE(file_inode(filp)-i_private);
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 7d8eb8a..25b2c86 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1860,7 +1860,7 @@ struct event_probe_data {
boolenable;
 };
 
-static struct ftrace_event_file *
+struct ftrace_event_file *
 find_event_file(struct trace_array *tr, const char *system,  const char *event)
 {
struct ftrace_event_file *file;
diff --git a/kernel/trace/trace_events_trigger.c 
b/kernel/trace/trace_events_trigger.c
index 36b6601..cab187b 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -807,6 +807,373 @@ static __init void 
unregister_trigger_traceon_traceoff_cmds(void)
 trigger_cmd_mutex);
 }
 
+/* Avoid typos */
+#define ENABLE_EVENT_STR   enable_event
+#define DISABLE_EVENT_STR  disable_event
+
+struct enable_trigger_data {
+   struct ftrace_event_file*file;
+   boolenable;
+};
+
+static void
+event_enable_trigger(struct event_trigger_data *data)
+{
+   struct enable_trigger_data *enable_data = data-private_data;
+
+   if (enable_data-enable)
+   clear_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, 
enable_data-file-flags);
+   else
+   set_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, 
enable_data-file-flags);
+}
+
+static void
+event_enable_count_trigger(struct event_trigger_data *data)
+{
+   struct enable_trigger_data *enable_data = data-private_data;
+
+   if (!data-count)
+   return;
+
+   /* Skip if the event is in a state we want to switch to */
+   if (enable_data-enable == !(enable_data-file-flags  
FTRACE_EVENT_FL_SOFT_DISABLED))
+   return;
+
+   if (data-count != -1)
+   (data-count)--;
+
+   event_enable_trigger(data);
+}
+
+static int
+event_enable_trigger_print(struct seq_file *m, struct event_trigger_ops *ops,
+  struct event_trigger_data *data)
+{
+   struct enable_trigger_data *enable_data = data-private_data;
+
+   seq_printf(m, %s:%s:%s,
+  enable_data-enable ? 

[PATCH v8 05/10] tracing: Add 'stacktrace' event trigger command

[Tom Zanussi]

Add 'stacktrace' event_command.  stacktrace event triggers are added
by the user via this command in a similar way and using practically
the same syntax as the analogous 'stacktrace' ftrace function command,
but instead of writing to the set_ftrace_filter file, the stacktrace
event trigger is written to the per-event 'trigger' files:

echo 'stacktrace'  .../tracing/events/somesys/someevent/trigger

The above command will turn on stacktraces for someevent i.e. whenever
someevent is hit, a stacktrace will be logged.

This also adds a 'count' version that limits the number of times the
command will be invoked:

echo 'stacktrace:N'  .../tracing/events/somesys/someevent/trigger

Where N is the number of times the command will be invoked.

The above command will log N stacktraces for someevent i.e. whenever
someevent is hit N times, a stacktrace will be logged.

Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com
---
 include/linux/ftrace_event.h|  1 +
 kernel/trace/trace_events_trigger.c | 76 +
 2 files changed, 77 insertions(+)

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 40b517b..31750df 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -320,6 +320,7 @@ enum event_trigger_type {
ETT_NONE= (0),
ETT_TRACE_ONOFF = (1  0),
ETT_SNAPSHOT= (1  1),
+   ETT_STACKTRACE  = (1  2),
 };
 
 extern void destroy_preds(struct ftrace_event_call *call);
diff --git a/kernel/trace/trace_events_trigger.c 
b/kernel/trace/trace_events_trigger.c
index 9bdcc38..36b6601 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -732,6 +732,71 @@ static struct event_command trigger_snapshot_cmd = {
.get_trigger_ops= snapshot_get_trigger_ops,
 };
 
+/*
+ * Skip 4:
+ *   ftrace_stacktrace()
+ *   function_trace_probe_call()
+ *   ftrace_ops_list_func()
+ *   ftrace_call()
+ */
+#define STACK_SKIP 4
+
+static void
+stacktrace_trigger(struct event_trigger_data *data)
+{
+   trace_dump_stack(STACK_SKIP);
+}
+
+static void
+stacktrace_count_trigger(struct event_trigger_data *data)
+{
+   if (!data-count)
+   return;
+
+   if (data-count != -1)
+   (data-count)--;
+
+   stacktrace_trigger(data);
+}
+
+static int
+stacktrace_trigger_print(struct seq_file *m, struct event_trigger_ops *ops,
+struct event_trigger_data *data)
+{
+   return event_trigger_print(stacktrace, m, (void *)data-count,
+  data-filter_str);
+}
+
+static struct event_trigger_ops stacktrace_trigger_ops = {
+   .func   = stacktrace_trigger,
+   .print  = stacktrace_trigger_print,
+   .init   = event_trigger_init,
+   .free   = event_trigger_free,
+};
+
+static struct event_trigger_ops stacktrace_count_trigger_ops = {
+   .func   = stacktrace_count_trigger,
+   .print  = stacktrace_trigger_print,
+   .init   = event_trigger_init,
+   .free   = event_trigger_free,
+};
+
+static struct event_trigger_ops *
+stacktrace_get_trigger_ops(char *cmd, char *param)
+{
+   return param ? stacktrace_count_trigger_ops : stacktrace_trigger_ops;
+}
+
+static struct event_command trigger_stacktrace_cmd = {
+   .name   = stacktrace,
+   .trigger_type   = ETT_STACKTRACE,
+   .post_trigger   = true,
+   .func   = event_trigger_callback,
+   .reg= register_trigger,
+   .unreg  = unregister_trigger,
+   .get_trigger_ops= stacktrace_get_trigger_ops,
+};
+
 static __init void unregister_trigger_traceon_traceoff_cmds(void)
 {
unregister_event_command(trigger_traceon_cmd,
@@ -776,5 +841,16 @@ __init int register_trigger_cmds(void)
return ret;
}
 
+   ret = register_event_command(trigger_stacktrace_cmd,
+ trigger_commands,
+ trigger_cmd_mutex);
+   if (WARN_ON(ret  0)) {
+   unregister_trigger_traceon_traceoff_cmds();
+   unregister_event_command(trigger_snapshot_cmd,
+trigger_commands,
+trigger_cmd_mutex);
+   return ret;
+   }
+
return 0;
 }
-- 
1.7.11.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 v8 04/10] tracing: Add 'snapshot' event trigger command

[Tom Zanussi]

Add 'snapshot' event_command.  snapshot event triggers are added by
the user via this command in a similar way and using practically the
same syntax as the analogous 'snapshot' ftrace function command, but
instead of writing to the set_ftrace_filter file, the snapshot event
trigger is written to the per-event 'trigger' files:

echo 'snapshot'  .../somesys/someevent/trigger

The above command will turn on snapshots for someevent i.e. whenever
someevent is hit, a snapshot will be done.

This also adds a 'count' version that limits the number of times the
command will be invoked:

echo 'snapshot:N'  .../somesys/someevent/trigger

Where N is the number of times the command will be invoked.

The above command will snapshot N times for someevent i.e. whenever
someevent is hit N times, a snapshot will be done.

Also adds a new ftrace_alloc_snapshot() function - the ftrace snapshot
command defines code that allocates a snapshot, which would be nice to
be able to reuse, which this does.

Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com
---
 include/linux/ftrace_event.h|  1 +
 kernel/trace/trace.c|  9 +
 kernel/trace/trace.h|  1 +
 kernel/trace/trace_events_trigger.c | 76 +
 4 files changed, 87 insertions(+)

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index a14650b..40b517b 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -319,6 +319,7 @@ struct ftrace_event_file {
 enum event_trigger_type {
ETT_NONE= (0),
ETT_TRACE_ONOFF = (1  0),
+   ETT_SNAPSHOT= (1  1),
 };
 
 extern void destroy_preds(struct ftrace_event_call *call);
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 496f94d..5a61dbe 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5358,6 +5358,15 @@ static const struct file_operations 
tracing_dyn_info_fops = {
 };
 #endif /* CONFIG_DYNAMIC_FTRACE */
 
+#if defined(CONFIG_TRACER_SNAPSHOT)
+int ftrace_alloc_snapshot(void)
+{
+   return alloc_snapshot(global_trace);
+}
+#else
+int ftrace_alloc_snapshot(void) { return -ENOSYS; }
+#endif
+
 #if defined(CONFIG_TRACER_SNAPSHOT)  defined(CONFIG_DYNAMIC_FTRACE)
 static void
 ftrace_snapshot(unsigned long ip, unsigned long parent_ip, void **data)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 37b8ecf..f032dd8 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1200,6 +1200,7 @@ struct event_command {
 
 extern int trace_event_enable_disable(struct ftrace_event_file *file,
  int enable, int soft_disable);
+extern int ftrace_alloc_snapshot(void);
 
 extern const char *__start___trace_bprintk_fmt[];
 extern const char *__stop___trace_bprintk_fmt[];
diff --git a/kernel/trace/trace_events_trigger.c 
b/kernel/trace/trace_events_trigger.c
index 5388d55..9bdcc38 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -664,6 +664,74 @@ static struct event_command trigger_traceoff_cmd = {
.get_trigger_ops= onoff_get_trigger_ops,
 };
 
+static void
+snapshot_trigger(struct event_trigger_data *data)
+{
+   tracing_snapshot();
+}
+
+static void
+snapshot_count_trigger(struct event_trigger_data *data)
+{
+   if (!data-count)
+   return;
+
+   if (data-count != -1)
+   (data-count)--;
+
+   snapshot_trigger(data);
+}
+
+static int
+register_snapshot_trigger(char *glob, struct event_trigger_ops *ops,
+ struct event_trigger_data *data,
+ struct ftrace_event_file *file)
+{
+   int ret = register_trigger(glob, ops, data, file);
+
+   if (ret  0)
+   ftrace_alloc_snapshot();
+
+   return ret;
+}
+
+static int
+snapshot_trigger_print(struct seq_file *m, struct event_trigger_ops *ops,
+  struct event_trigger_data *data)
+{
+   return event_trigger_print(snapshot, m, (void *)data-count,
+  data-filter_str);
+}
+
+static struct event_trigger_ops snapshot_trigger_ops = {
+   .func   = snapshot_trigger,
+   .print  = snapshot_trigger_print,
+   .init   = event_trigger_init,
+   .free   = event_trigger_free,
+};
+
+static struct event_trigger_ops snapshot_count_trigger_ops = {
+   .func   = snapshot_count_trigger,
+   .print  = snapshot_trigger_print,
+   .init   = event_trigger_init,
+   .free   = event_trigger_free,
+};
+
+static struct event_trigger_ops *
+snapshot_get_trigger_ops(char *cmd, char *param)
+{
+   return param ? snapshot_count_trigger_ops : snapshot_trigger_ops;
+}
+
+static struct event_command trigger_snapshot_cmd = {
+   .name   = snapshot,
+   .trigger_type   = 

[PATCH v8 00/10] tracing: trace event triggers

[Tom Zanussi]

Hi,

This is v8 of the trace event triggers patchset.  This version
addresses the comments and feedback from Steve Rostedt on v7.

v8:
 - changed rcu_dereference_raw() to rcu_dereference() and moved
   synchronize_sched() out from under the syscall_trace_lock mutex.
 - got rid of the various void ** usages in the basic framework and
   individual trigger patches.  Since triggers always expect an
   event_trigger_data instance, there's not even any reason to make it
   a void *, so those along with the void * usages were changed to use
   event_trigger_data * directly.  To allow for trigger-specific data,
   a new void * field named private_data was added to
   event_trigger_data; this is made use of by the enable/disable_event
   triggers.
 - fixed various style nitpicks.
 - added a new TRIGGER_COND flag to ftrace_file - this flag basically
   tracks whether or not an event has any triggers that have a
   condition associated with them that requires looking at the data
   being logged (or that would be in the case of soft-disable) for the
   current event.  If TRIGGER_COND is not set, then the triggers can
   be invoked immediately without forcing the ineffeciency of actually
   generating the log event when not necessary.
 - patch 8 removed the obsolete filter_current_check_discard() and
   replaced it with filter_check_discard() but accidentally made the
   new function static inline, which is obviously not what was
   intended.  That and the new call_filter_check_discard() functions
   are now normal functions as filter_current_check_discard() was.
 - isolated all the ugly 'if (USE_CALL_FILTER) else' usages in patch 8
   which significantly cleaned up that patch as a result.

v7:
 - moved find_event_file() extern declartion to patch 06.
 - moved helper functions from patch 02 to 03, where they're first
   used.
 - removed copies of cmd_ops fields from trigger_data and changed to
   use cmd_ops diretly instead.
 - renamed trigger_mode to trigger_type to avoid confusion with the
   FTRACE_EVENT_FL_TRIGGER_MODE_BIT bitflag, and fixed up
   usage/documentation, etc.

v6:
 - fixed up the conflicts in trace_events.c related to the actual
   creation of the per-event 'trigger' files.

v5:
 - got rid of the trigger_iterator, a vestige of the first patchset,
   which attempted to abstract the ftrace_iterator for triggers, and
   cleaned up related code simplified as a result.
 - replaced the void *cmd_data everywhere with ftrace_event_file *,
   another vestige of the initial patchset.
 - updated the patchset to use event_file_data() to grab the i_private
   ftrace_event_files where appropriate (this was a separate patch in
   the previous patchset, but was merged into the basic framework
   patch as suggested by Masami.  The only interesting part about this
   is that it moved event_file_data() from kernel/trace/trace_events.c
   to kernel/trace/trace.h so it can be used in
   e.g. trace_events_trigger.c as well.)
 - add missing grab of event_mutex in event_trigger_regex_write().
 - realized when making the above changes that the trigger filters
   weren't being freed when the trigger was freed, so added a
   trigger_data_free() to do that.  It also ensures that trigger_data
   won't be freed until nothing is using it.
 - added clear_event_triggers(), which clears all triggers in a trace
   array (and soft-disable associated with event_enable/disable
   events).
 - added a comment to ftrace_syscall_enter/exit to document the use of
   rcu_dereference_raw() there.

v4:
 - made some changes to the soft-disable for syscall patch, according
   to Masami's suggestions.  Actually, since there's now an array of
   ftrace_files for syscalls that can serve the same purpose, the
   enabled_enter/exit_syscalls bit arrays became redundant and were
   removed.
 - moved all the remaining common functions out of the
   traceon/traceoff patch and into the basic trigger framework patch
   and added comments to all the common functions.
 - extensively commented the event_trigger_ops and event_command ops.
 - made the register/unregister_command functions __init.  Since that
   code was originally inspired by similar ftrace code, a new patch
   was added to do the same thing for the register/unregister of the
   ftrace commands (patch 10/11).
 - fixed the event_trigger_regex_open i_private problem noted by
   Masami that's currently being addressed by Oleg Nesterov's fixes
   for this.  Note that that patchset also affects patch 8/11 (update
   filters for multi-buffer, since it touches event filters as well).
   Patch 11/11 depends on that patchset and also moves
   event_file_data() to trace.h.b

v3:
 - added a new patch to the series (patch 8/9 - update event filters
   for multibuffer) to bring the event filters up-to-date wrt the
   multibuffer changes - without this patch, the same filter is
   applied to all buffers regardless of which instance sets it; this
   patch allows you to set per-instance filters as you'd expect. 

[PATCH 2/2] audit: Two efficiency fixes for audit mechanism

[Chuck Anderson]

audit: Two efficiency fixes for audit mechanism

author: Dan Duval dan.du...@oracle.com

These and similar errors were seen on a patched 3.8 kernel when the
audit subsystem was overrun during boot:

  udevd[876]: worker [887] unexpectedly returned with status 0x0100
  udevd[876]: worker [887] failed while handling 
'/devices/pci:00/:00:03.0/:40:00.0'

  udevd[876]: worker [880] unexpectedly returned with status 0x0100
  udevd[876]: worker [880] failed while handling 
'/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/event1'


  udevadm settle - timeout of 180 seconds reached, the event queue 
contains:

/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/event1 (3995)
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT3F0D:00 (4034)

  audit: audit_backlog=258  audit_backlog_limit=256
  audit: audit_lost=1 audit_rate_limit=0 audit_backlog_limit=256

The changes below increase the efficiency of the audit code and
prevent it from being overrun:

1. Only issue a wake_up in kauditd if the length of the skb queue
   is less than the backlog limit.  Otherwise, threads waiting in
   wait_for_auditd() will simply wake up, discover that the
   queue is still too long for them to proceed, and go back
   to sleep.  This results in wasted context switches and
   machine cycles.  kauditd_thread() is the only function that
   removes buffers from audit_skb_queue so we can't race.  If we
   did, the timeout in wait_for_auditd() would expire and the
   waiting thread would continue.

2. Use add_wait_queue_exclusive() in wait_for_auditd() to put the
   thread on the wait queue.  When kauditd dequeues an skb, all
   of the waiting threads are waiting for the same resource, but
   only one is going to get it, so there's no need to wake up
   more than one waiter.

Signed-off-by: Dan Duval dan.du...@oracle.com
Signed-off-by: Chuck Anderson chuck.ander...@oracle.com
---
 kernel/audit.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 9a78dde..d87b4dd 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -449,8 +449,11 @@ static int kauditd_thread(void *dummy)
flush_hold_queue();

skb = skb_dequeue(audit_skb_queue);
-   wake_up(audit_backlog_wait);
+
if (skb) {
+   if(skb_queue_len(audit_skb_queue) = audit_backlog_limi
t)
+   wake_up(audit_backlog_wait);
+
if (audit_pid)
kauditd_send_skb(skb);
else
@@ -1059,7 +1062,7 @@ static void wait_for_auditd(unsigned long 
sleep_time, int

limit)
 {
DECLARE_WAITQUEUE(wait, current);
set_current_state(TASK_UNINTERRUPTIBLE);
-   add_wait_queue(audit_backlog_wait, wait);
+   add_wait_queue_exclusive(audit_backlog_wait, wait);

if (audit_backlog_limit 
skb_queue_len(audit_skb_queue)  limit)
--
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 v8 10/10] tracing: Make register/unregister_ftrace_command __init

[Tom Zanussi]

register/unregister_ftrace_command() are only ever called from __init
functions, so can themselves be made __init.

Also make register_snapshot_cmd() __init for the same reason.

Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com
---
 include/linux/ftrace.h |  4 ++--
 kernel/trace/ftrace.c  | 12 ++--
 kernel/trace/trace.c   |  4 ++--
 3 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 9f15c00..6062491 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -533,11 +533,11 @@ static inline int ftrace_force_update(void) { return 0; }
 static inline void ftrace_disable_daemon(void) { }
 static inline void ftrace_enable_daemon(void) { }
 static inline void ftrace_release_mod(struct module *mod) {}
-static inline int register_ftrace_command(struct ftrace_func_command *cmd)
+static inline __init int register_ftrace_command(struct ftrace_func_command 
*cmd)
 {
return -EINVAL;
 }
-static inline int unregister_ftrace_command(char *cmd_name)
+static inline __init int unregister_ftrace_command(char *cmd_name)
 {
return -EINVAL;
 }
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index a6d098c..64f7f39 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3292,7 +3292,11 @@ void unregister_ftrace_function_probe_all(char *glob)
 static LIST_HEAD(ftrace_commands);
 static DEFINE_MUTEX(ftrace_cmd_mutex);
 
-int register_ftrace_command(struct ftrace_func_command *cmd)
+/*
+ * Currently we only register ftrace commands from __init, so mark this
+ * __init too.
+ */
+__init int register_ftrace_command(struct ftrace_func_command *cmd)
 {
struct ftrace_func_command *p;
int ret = 0;
@@ -3311,7 +3315,11 @@ int register_ftrace_command(struct ftrace_func_command 
*cmd)
return ret;
 }
 
-int unregister_ftrace_command(struct ftrace_func_command *cmd)
+/*
+ * Currently we only unregister ftrace commands from __init, so mark
+ * this __init too.
+ */
+__init int unregister_ftrace_command(struct ftrace_func_command *cmd)
 {
struct ftrace_func_command *p, *n;
int ret = -ENODEV;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 69f5796..76e2ecf 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5486,12 +5486,12 @@ static struct ftrace_func_command ftrace_snapshot_cmd = 
{
.func   = ftrace_trace_snapshot_callback,
 };
 
-static int register_snapshot_cmd(void)
+static __init int register_snapshot_cmd(void)
 {
return register_ftrace_command(ftrace_snapshot_cmd);
 }
 #else
-static inline int register_snapshot_cmd(void) { return 0; }
+static inline __init int register_snapshot_cmd(void) { return 0; }
 #endif /* defined(CONFIG_TRACER_SNAPSHOT)  defined(CONFIG_DYNAMIC_FTRACE) */
 
 struct dentry *tracing_init_dentry_tr(struct trace_array *tr)
-- 
1.7.11.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 v8 01/10] tracing: Add support for SOFT_DISABLE to syscall events

[Tom Zanussi]

The original SOFT_DISABLE patches didn't add support for soft disable
of syscall events; this adds it and paves the way for future patches
allowing triggers to be added to syscall events, since triggers are
built on top of SOFT_DISABLE.

Add an array of ftrace_event_file pointers indexed by syscall number
to the trace array and remove the existing enabled bitmaps, which as a
result are now redundant.  The ftrace_event_file structs in turn
contain the soft disable flags we need for per-syscall soft disable
accounting; later patches add additional 'trigger' flags and
per-syscall triggers and filters.

Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com
---
 kernel/trace/trace.h  |  4 ++--
 kernel/trace/trace_syscalls.c | 36 ++--
 2 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index fe39acd..b1227b9 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -192,8 +192,8 @@ struct trace_array {
 #ifdef CONFIG_FTRACE_SYSCALLS
int sys_refcount_enter;
int sys_refcount_exit;
-   DECLARE_BITMAP(enabled_enter_syscalls, NR_syscalls);
-   DECLARE_BITMAP(enabled_exit_syscalls, NR_syscalls);
+   struct ftrace_event_file *enter_syscall_files[NR_syscalls];
+   struct ftrace_event_file *exit_syscall_files[NR_syscalls];
 #endif
int stop_count;
int clock_id;
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 559329d..af4b71c 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -302,6 +302,7 @@ static int __init syscall_exit_define_fields(struct 
ftrace_event_call *call)
 static void ftrace_syscall_enter(void *data, struct pt_regs *regs, long id)
 {
struct trace_array *tr = data;
+   struct ftrace_event_file *ftrace_file;
struct syscall_trace_enter *entry;
struct syscall_metadata *sys_data;
struct ring_buffer_event *event;
@@ -314,7 +315,13 @@ static void ftrace_syscall_enter(void *data, struct 
pt_regs *regs, long id)
syscall_nr = trace_get_syscall_nr(current, regs);
if (syscall_nr  0)
return;
-   if (!test_bit(syscall_nr, tr-enabled_enter_syscalls))
+
+   /* Here we're inside the tp handler's rcu_read_lock (__DO_TRACE()) */
+   ftrace_file = rcu_dereference(tr-enter_syscall_files[syscall_nr]);
+   if (!ftrace_file)
+   return;
+
+   if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, ftrace_file-flags))
return;
 
sys_data = syscall_nr_to_meta(syscall_nr);
@@ -345,6 +352,7 @@ static void ftrace_syscall_enter(void *data, struct pt_regs 
*regs, long id)
 static void ftrace_syscall_exit(void *data, struct pt_regs *regs, long ret)
 {
struct trace_array *tr = data;
+   struct ftrace_event_file *ftrace_file;
struct syscall_trace_exit *entry;
struct syscall_metadata *sys_data;
struct ring_buffer_event *event;
@@ -356,7 +364,13 @@ static void ftrace_syscall_exit(void *data, struct pt_regs 
*regs, long ret)
syscall_nr = trace_get_syscall_nr(current, regs);
if (syscall_nr  0)
return;
-   if (!test_bit(syscall_nr, tr-enabled_exit_syscalls))
+
+   /* Here we're inside the tp handler's rcu_read_lock (__DO_TRACE()) */
+   ftrace_file = rcu_dereference(tr-exit_syscall_files[syscall_nr]);
+   if (!ftrace_file)
+   return;
+
+   if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, ftrace_file-flags))
return;
 
sys_data = syscall_nr_to_meta(syscall_nr);
@@ -397,7 +411,7 @@ static int reg_event_syscall_enter(struct ftrace_event_file 
*file,
if (!tr-sys_refcount_enter)
ret = register_trace_sys_enter(ftrace_syscall_enter, tr);
if (!ret) {
-   set_bit(num, tr-enabled_enter_syscalls);
+   rcu_assign_pointer(tr-enter_syscall_files[num], file);
tr-sys_refcount_enter++;
}
mutex_unlock(syscall_trace_lock);
@@ -415,10 +429,15 @@ static void unreg_event_syscall_enter(struct 
ftrace_event_file *file,
return;
mutex_lock(syscall_trace_lock);
tr-sys_refcount_enter--;
-   clear_bit(num, tr-enabled_enter_syscalls);
+   rcu_assign_pointer(tr-enter_syscall_files[num], NULL);
if (!tr-sys_refcount_enter)
unregister_trace_sys_enter(ftrace_syscall_enter, tr);
mutex_unlock(syscall_trace_lock);
+   /*
+* Callers expect the event to be completely disabled on
+* return, so wait for current handlers to finish.
+*/
+   synchronize_sched();
 }
 
 static int reg_event_syscall_exit(struct ftrace_event_file *file,
@@ -435,7 +454,7 @@ static int reg_event_syscall_exit(struct ftrace_event_file 
*file,
if (!tr-sys_refcount_exit)
ret = 

[PATCH v8 07/10] tracing: Add and use generic set_trigger_filter() implementation

[Tom Zanussi]

Add a generic event_command.set_trigger_filter() op implementation and
have the current set of trigger commands use it - this essentially
gives them all support for filters.

Syntactically, filters are supported by adding 'if filter' just
after the command, in which case only events matching the filter will
invoke the trigger.  For example, to add a filter to an
enable/disable_event command:

echo 'enable_event:system:event if common_pid == 999'  \
  .../othersys/otherevent/trigger

The above command will only enable the system:event event if the
common_pid field in the othersys:otherevent event is 999.

As another example, to add a filter to a stacktrace command:

echo 'stacktrace if common_pid == 999'  \
   .../somesys/someevent/trigger

The above command will only trigger a stacktrace if the common_pid
field in the event is 999.

The filter syntax is the same as that described in the 'Event
filtering' section of Documentation/trace/events.txt.

Because triggers can now use filters, the trigger-invoking logic needs
to be moved in those cases - e.g. for ftrace_raw_event_calls, if a
trigger has a filter associated with it, the trigger invocation now
needs to happen after the { assign; } part of the call, in order for
the trigger condition to be tested.

There's still a SOFT_DISABLED-only check at the top of e.g. the
ftrace_raw_events function, so when an event is soft disabled but not
because of the presence of a trigger, the original SOFT_DISABLED
behavior remains unchanged.

There's also a bit of trickiness in that some triggers need to avoid
being invoked while an event is currently in the process of being
logged, since the trigger may itself log data into the trace buffer.
Thus we make sure the current event is committed before invoking those
triggers.  To do that, we split the trigger invocation in two - the
first part (event_triggers_call()) checks the filter using the current
trace record; if a command has the post_trigger flag set, it sets a
bit for itself in the return value, otherwise it directly invoks the
trigger.  Once all commands have been either invoked or set their
return flag, event_triggers_call() returns.  The current record is
then either committed or discarded; if any commands have deferred
their triggers, those commands are finally invoked following the close
of the current event by event_triggers_post_call().

To simplify the above and make it more efficient, the TRIGGER_COND bit
is introduced, which is set only if a soft-disabled trigger needs to
use the log record for filter testing or needs to wait until the
current log record is closed.

The syscall event invocation code is also changed in analogous ways.

Because event triggers need to be able to create and free filters,
this also adds a couple external wrappers for the existing
create_filter and free_filter functions, which are too generic to be
made extern functions themselves.

Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com
---
 include/linux/ftrace_event.h|  10 ++-
 include/trace/ftrace.h  |  53 ++
 kernel/trace/trace.h|   5 ++
 kernel/trace/trace_events_filter.c  |  13 
 kernel/trace/trace_events_trigger.c | 142 +++-
 kernel/trace/trace_syscalls.c   |  50 ++---
 6 files changed, 243 insertions(+), 30 deletions(-)

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 8e87302..8365a4c 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -1,3 +1,4 @@
+
 #ifndef _LINUX_FTRACE_EVENT_H
 #define _LINUX_FTRACE_EVENT_H
 
@@ -256,6 +257,7 @@ enum {
FTRACE_EVENT_FL_SOFT_MODE_BIT,
FTRACE_EVENT_FL_SOFT_DISABLED_BIT,
FTRACE_EVENT_FL_TRIGGER_MODE_BIT,
+   FTRACE_EVENT_FL_TRIGGER_COND_BIT,
 };
 
 /*
@@ -266,6 +268,7 @@ enum {
  *  SOFT_DISABLED - When set, do not trace the event (even though its
  *   tracepoint may be enabled)
  *  TRIGGER_MODE  - When set, invoke the triggers associated with the event
+ *  TRIGGER_COND  - When set, one or more triggers has an associated filter
  */
 enum {
FTRACE_EVENT_FL_ENABLED = (1  FTRACE_EVENT_FL_ENABLED_BIT),
@@ -273,6 +276,7 @@ enum {
FTRACE_EVENT_FL_SOFT_MODE   = (1  FTRACE_EVENT_FL_SOFT_MODE_BIT),
FTRACE_EVENT_FL_SOFT_DISABLED   = (1  
FTRACE_EVENT_FL_SOFT_DISABLED_BIT),
FTRACE_EVENT_FL_TRIGGER_MODE= (1  
FTRACE_EVENT_FL_TRIGGER_MODE_BIT),
+   FTRACE_EVENT_FL_TRIGGER_COND= (1  
FTRACE_EVENT_FL_TRIGGER_COND_BIT),
 };
 
 struct ftrace_event_file {
@@ -326,11 +330,15 @@ enum event_trigger_type {
 
 extern void destroy_preds(struct ftrace_event_call *call);
 extern int filter_match_preds(struct event_filter *filter, void *rec);
+
 extern int filter_current_check_discard(struct ring_buffer *buffer,
struct ftrace_event_call *call,

[PATCH v8 08/10] tracing: Update event filters for multibuffer

[Tom Zanussi]

The trace event filters are still tied to event calls rather than
event files, which means you don't get what you'd expect when using
filters in the multibuffer case:

Before:

  # echo 'count  65536'  
/sys/kernel/debug/tracing/events/syscalls/sys_enter_read/filter
  # cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/filter
  count  65536
  # mkdir /sys/kernel/debug/tracing/instances/test1
  # echo 'count  4096'  
/sys/kernel/debug/tracing/instances/test1/events/syscalls/sys_enter_read/filter
  # cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/filter
  count  4096

Setting the filter in tracing/instances/test1/events shouldn't affect
the same event in tracing/events as it does above.

After:

  # echo 'count  65536'  
/sys/kernel/debug/tracing/events/syscalls/sys_enter_read/filter
  # cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/filter
  count  65536
  # mkdir /sys/kernel/debug/tracing/instances/test1
  # echo 'count  4096'  
/sys/kernel/debug/tracing/instances/test1/events/syscalls/sys_enter_read/filter
  # cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/filter
count  65536

We'd like to just move the filter directly from ftrace_event_call to
ftrace_event_file, but there are a couple cases that don't yet have
multibuffer support and therefore have to continue using the current
event_call-based filters.  For those cases, a new USE_CALL_FILTER bit
is added to the event_call flags, whose main purpose is to keep the
old behavioir for those cases until they can be updated with
multibuffer support; at that point, the USE_CALL_FILTER flag (and the
new associated call_filter_check_discard() function) can go away.

The multibuffer support also made filter_current_check_discard()
redundant, so this change removes that function as well and replaces
it with filter_check_discard() (or call_filter_check_discard() as
appropriate).

Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com
---
 include/linux/ftrace_event.h |  31 +++--
 include/trace/ftrace.h   |   6 +-
 kernel/trace/trace.c |  40 +--
 kernel/trace/trace.h |  18 +--
 kernel/trace/trace_branch.c  |   2 +-
 kernel/trace/trace_events.c  |  23 ++--
 kernel/trace/trace_events_filter.c   | 218 ---
 kernel/trace/trace_export.c  |   2 +-
 kernel/trace/trace_functions_graph.c |   4 +-
 kernel/trace/trace_kprobe.c  |   4 +-
 kernel/trace/trace_mmiotrace.c   |   4 +-
 kernel/trace/trace_sched_switch.c|   4 +-
 kernel/trace/trace_syscalls.c|   7 +-
 kernel/trace/trace_uprobe.c  |   3 +-
 14 files changed, 263 insertions(+), 103 deletions(-)

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 8365a4c..c96009c 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -203,6 +203,7 @@ enum {
TRACE_EVENT_FL_NO_SET_FILTER_BIT,
TRACE_EVENT_FL_IGNORE_ENABLE_BIT,
TRACE_EVENT_FL_WAS_ENABLED_BIT,
+   TRACE_EVENT_FL_USE_CALL_FILTER_BIT,
 };
 
 /*
@@ -214,6 +215,7 @@ enum {
  *  WAS_ENABLED   - Set and stays set when an event was ever enabled
  *(used for module unloading, if a module event is enabled,
  * it is best to clear the buffers that used it).
+ *  USE_CALL_FILTER - For ftrace internal events, don't use file filter
  */
 enum {
TRACE_EVENT_FL_FILTERED = (1  TRACE_EVENT_FL_FILTERED_BIT),
@@ -221,6 +223,7 @@ enum {
TRACE_EVENT_FL_NO_SET_FILTER= (1  
TRACE_EVENT_FL_NO_SET_FILTER_BIT),
TRACE_EVENT_FL_IGNORE_ENABLE= (1  
TRACE_EVENT_FL_IGNORE_ENABLE_BIT),
TRACE_EVENT_FL_WAS_ENABLED  = (1  TRACE_EVENT_FL_WAS_ENABLED_BIT),
+   TRACE_EVENT_FL_USE_CALL_FILTER  = (1  
TRACE_EVENT_FL_USE_CALL_FILTER_BIT),
 };
 
 struct ftrace_event_call {
@@ -239,6 +242,7 @@ struct ftrace_event_call {
 *   bit 2: failed to apply filter
 *   bit 3: ftrace internal event (do not enable)
 *   bit 4: Event was enabled by module
+*   bit 5: use call filter rather than file filter
 */
int flags; /* static flags of different events */
 
@@ -254,6 +258,8 @@ struct ftrace_subsystem_dir;
 enum {
FTRACE_EVENT_FL_ENABLED_BIT,
FTRACE_EVENT_FL_RECORDED_CMD_BIT,
+   FTRACE_EVENT_FL_FILTERED_BIT,
+   FTRACE_EVENT_FL_NO_SET_FILTER_BIT,
FTRACE_EVENT_FL_SOFT_MODE_BIT,
FTRACE_EVENT_FL_SOFT_DISABLED_BIT,
FTRACE_EVENT_FL_TRIGGER_MODE_BIT,
@@ -264,6 +270,8 @@ enum {
  * Ftrace event file flags:
  *  ENABLED  - The event is enabled
  *  RECORDED_CMD  - The comms should be recorded at sched_switch
+ *  FILTERED - The event has a filter attached
+ *  NO_SET_FILTER - Set when filter has error and is to be ignored
  *  SOFT_MODE - The event is enabled/disabled by SOFT_DISABLED
  *  

RE: [PATCHv2 1/4] pwm: Add Freescale FTM PWM driver support

[Xiubo Li-B47053]

 Subject: Re: [PATCHv2 1/4] pwm: Add Freescale FTM PWM driver support
 
 On Mon, Sep 02, 2013 at 03:33:37AM +, Xiubo Li-B47053 wrote:
 
+static void fsl_pwm_free(struct pwm_chip *chip, struct pwm_device
+*pwm) {
+   struct fsl_pwm_chip *fpc;
+   struct fsl_pwm_data *pwm_data;
+
+   fpc = to_fsl_chip(chip);
+
+   pwm_data = pwm_get_chip_data(pwm);
+   if (!pwm_data)
+   return;
  
   THis check seems unnecessary.
  
 
  But if do not check it here, I must check it in the following code.
 
+
+   if (pwm_data-available != FSL_AVAILABLE)
+   return;
+
 
  So the ' struct fsl_pwm_data' may be removed in the future.
 
  
+
+
+   pwm_data-period_cycles = period_cycles;
+   pwm_data-duty_cycles = duty_cycles;
  
   These fields are set but never read. Please drop them.
  
   If you drop the 'available' field also the you can drop chip_data
   completely.
  
 
  I think I may move the 'available' field to the PWM driver data struct.
 
 You simply don't need the available field. You don't need to track
 whether they are available. If a user enables a pwm which is not routed
 out of the SoC (disabled in the iomux) simply nothing will happen except
 for a slightly increased power consumption.
 
If the there is not need to explicitly specify the channels are available or 
not, so there is no doubt that the 'available' field will be dropt.
Why I added this here is because that the 4th and 5th channels' pinctrls are 
used as UART TX and RX as I have mentioned before, so here if you configure 
these two pinctrls, the UART TX and RX will be polluted, there maybe some other 
cases like this.
So, if there is no need to worry about this in PWM driver, the customer should 
be aware of it and be responsible for the potential risk.
I will think it over and optimize it then.



Thanks very much.
--
Best Regards.
Xiubo





--
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] rbtree: Add some necessary condition checks

[Zhi Yong Wu]

On Mon, Sep 2, 2013 at 4:57 PM, Michel Lespinasse wal...@google.com wrote:
 On Sun, Sep 1, 2013 at 11:30 PM, Zhi Yong Wu zwu.ker...@gmail.com wrote:
 In Tue, Aug 27, 2013 at 6:01 AM, Michel Lespinasse wal...@google.com wrote:
 On Fri, Aug 23, 2013 at 7:45 AM,  zwu.ker...@gmail.com wrote:
 From: Zhi Yong Wu wu...@linux.vnet.ibm.com

 Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
 ---
  include/linux/rbtree_augmented.h | 3 ++-
  lib/rbtree.c | 5 +++--
  2 files changed, 5 insertions(+), 3 deletions(-)

 So, you are saying that the checks are necessary, but you are not saying 
 why.

 The way I see it, the checks are *not* necessary, because the rbtree
 invariants guarantee them to be true. The only way for the checks to
 fail would be if people directly manipulate the rbtrees without going
 through the proper APIs, and if they do that then I think they're on
 their own. So to me, I think it's the same situation as dereferencing
 a pointer without checking if it's NULL, because you know it should
 never be NULL - which in my eyes is perfectly acceptable.
 In my patchset, some rbtree APIs to be invoked, and I think that those
 rbtree APIs are used corrently, Below is the pointer of its code:
 https://github.com/wuzhy/kernel/compare/torvalds:master...hot_tracking
 But I hit some issues when using compilebench to do perf benchmark.
 compile dir kernel-7 691MB in 8.92 seconds (77.53 MB/s)

 Thanks for the link - I now better understand where you are coming
 from with these fixes.

 Going back to the original message:

 diff --git a/include/linux/rbtree_augmented.h 
 b/include/linux/rbtree_augmented.h
 index fea49b5..7d19770 100644
 --- a/include/linux/rbtree_augmented.h
 +++ b/include/linux/rbtree_augmented.h
 @@ -199,7 +199,8 @@ __rb_erase_augmented(struct rb_node *node, struct 
 rb_root *root,
 }

 successor-rb_left = tmp = node-rb_left;
 -   rb_set_parent(tmp, successor);
 +   if (tmp)
 +   rb_set_parent(tmp, successor);

 pc = node-__rb_parent_color;
 tmp = __rb_parent(pc);

 Note that node-rb_left was already fetched at the top of
 __rb_erase_augmented(), and was checked to be non-NULL at the time -
 otherwise we would have executed 'Case 1' in that function. So, you
If 'Case 1' is executed, this line of code is also done, how about the result?
'Case 1' seems *not* to change node-rb_left at all.

 are not expected to find tmp == NULL here.

 diff --git a/lib/rbtree.c b/lib/rbtree.c
 index c0e31fe..2cb01ba 100644
 --- a/lib/rbtree.c
 +++ b/lib/rbtree.c
 @@ -214,7 +214,7 @@ rb_erase_color(struct rb_node *parent, struct 
 rb_root *root,
  */
 sibling = parent-rb_right;
 if (node != sibling) {  /* node == parent-rb_left */
 -   if (rb_is_red(sibling)) {
 +   if (sibling  rb_is_red(sibling)) {
 /*
  * Case 1 - left rotate at parent
  *

 Note the loop invariants quoted just above:

 /*
  * Loop invariants:
  * - node is black (or NULL on first iteration)
  * - node is not the root (parent is not NULL)
  * - All leaf paths going through parent and node have a
  *   black node count that is 1 lower than other leaf paths.
  */

 Because of these, each path from sibling to a leaf must include at
 least one black node, which implies that sibling can't be NULL - or to
 put it another way, if sibling is null then the expected invariants
 were violated before we even got there.
In theory, i can understand what you mean, But don't know why and
where it got violated.

 @@ -226,7 +226,8 @@ rb_erase_color(struct rb_node *parent, struct 
 rb_root *root,
  */
 parent-rb_right = tmp1 = sibling-rb_left;
 sibling-rb_left = parent;
 -   rb_set_parent_color(tmp1, parent, RB_BLACK);
 +   if (tmp1)
 +   rb_set_parent_color(tmp1, parent, 
 RB_BLACK);
 __rb_rotate_set_parents(parent, sibling, 
 root,
 RB_RED);
 augment_rotate(parent, sibling);

 This is actually the same invariant here - each path from sibling to a
 leaf must include at least one black node, and sibling is now known to
 be red, so it must have two black children.
Ditto.


 Now I had a quick look at your code and I couldn't tell at which point
 the invariants are violated. However I did notice a couple suspicious
 things in the very first patch
 (f5c8f2b256d87ac0bf789a787e6b795ac0c736e8):

 1- In both hot_range_tree_free() and and 

Re: [PATCH 0/2] audit: fix soft lockups and udevd errors when audit is overrun

[Luiz Capitulino]

On Mon, 02 Sep 2013 20:45:14 -0700
Chuck Anderson chuck.ander...@oracle.com wrote:

 The two patches that follow in separate emails resolve soft lockups and
 udevd reported errors that prevented a large memory 3.8 system from booting.
 
 The patches are based on 3.11-rc7.
 
 I believe it is the same issue recently posted as:
 
[RFC] audit: avoid soft lockup in audit_log_start()
https://lkml.org/lkml/2013/8/28/626

Nice to see someone else looking into this! And Thanks for CC'ing me.

I've a couple of news to you.

First, I've tried to apply your series but got this:

[lcapitulino@volcano linux-2.6]$ git am ~/audit-fix.mbox
Applying: audit: fix soft lockups due to loop in audit_log_start() wh,en 
audit_backlog_limit exceeded
fatal: corrupt patch at line 23
Patch failed at 0001 audit: fix soft lockups due to loop in audit_log_start() 
wh,en audit_backlog_limit exceeded
The copy of the patch that failed is found in:
   /home/lcapitulino/work/src/upstream/linux-2.6/.git/rebase-apply/patch
When you have resolved this problem, run git am --resolved.
If you prefer to skip this patch, run git am --skip instead.
To restore the original branch and stop patching, run git am --abort.
[lcapitulino@volcano linux-2.6]$

Now, I was a few minutes a away before sending a different fix I cooked
this evening when I got your series in my inbox. So I really wanted to give
this a try and applied the first patch manually (resulting version is
attached). The softlockup is gone, but I still get a hang for several
seconds just like I did with my first rfc.

I found a very easy way to reproduce the problem and our analysis is
similar, but our solutions differs.

I'm going to send my solution right now, sorry for any mistakes it's
almost 1h AM here but I really wanted to give your version a try before
sending my version (and before going to bed). If you send a v2 I'll try
it again and we can discuss our approaches.
diff --git a/kernel/audit.c b/kernel/audit.c
index 91e53d0..8255d9b 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -103,9 +103,11 @@ static int	audit_rate_limit;
 
 /* Number of outstanding audit_buffers allowed. */
 static int	audit_backlog_limit = 64;
-static int	audit_backlog_wait_time = 60 * HZ;
 static int	audit_backlog_wait_overflow = 0;
 
+#define AUDIT_BACKLOG_WAIT_TIME (60 * HZ)
+static int audit_backlog_wait_time = AUDIT_BACKLOG_WAIT_TIME;
+
 /* The identity of the user shutting down the audit system. */
 kuid_t		audit_sig_uid = INVALID_UID;
 pid_t		audit_sig_pid = -1;
@@ -1053,14 +1055,14 @@ static inline void audit_get_stamp(struct audit_context *ctx,
 /*
  * Wait for auditd to drain the queue a little
  */
-static void wait_for_auditd(unsigned long sleep_time)
+static void wait_for_auditd(unsigned long sleep_time, int limit)
 {
 	DECLARE_WAITQUEUE(wait, current);
 	set_current_state(TASK_UNINTERRUPTIBLE);
 	add_wait_queue(audit_backlog_wait, wait);
 
 	if (audit_backlog_limit 
-	skb_queue_len(audit_skb_queue)  audit_backlog_limit)
+	skb_queue_len(audit_skb_queue)  limit)
 		schedule_timeout(sleep_time);
 
 	__set_current_state(TASK_RUNNING);
@@ -1095,8 +1097,8 @@ struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask,
 	struct audit_buffer	*ab	= NULL;
 	struct timespec		t;
 	unsigned int		uninitialized_var(serial);
-	int reserve;
 	unsigned long timeout_start = jiffies;
+	int limit;
 
 	if (audit_initialized != AUDIT_INITIALIZED)
 		return NULL;
@@ -1104,22 +1106,21 @@ struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask,
 	if (unlikely(audit_filter_type(type)))
 		return NULL;
 
-	if (gfp_mask  __GFP_WAIT)
-		reserve = 0;
-	else
-		reserve = 5; /* Allow atomic callers to go up to five
-entries over the normal backlog limit */
+	limit = audit_backlog_limit;
+	 if (!(gfp_mask  __GFP_WAIT))
+	 	limit += 5;
 
 	while (audit_backlog_limit
-	skb_queue_len(audit_skb_queue)  audit_backlog_limit + reserve) {
+	skb_queue_len(audit_skb_queue)  limit) {
 		if (gfp_mask  __GFP_WAIT  audit_backlog_wait_time) {
 			unsigned long sleep_time;
 
 			sleep_time = timeout_start + audit_backlog_wait_time -
 	jiffies;
-			if ((long)sleep_time  0)
-wait_for_auditd(sleep_time);
-			continue;
+			if ((long)sleep_time  0) {
+wait_for_auditd(sleep_time, limit);
+continue;
+			}
 		}
 		if (audit_rate_check()  printk_ratelimit())
 			printk(KERN_WARNING
@@ -1133,6 +1134,8 @@ struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask,
 		return NULL;
 	}
 
+	audit_backlog_wait_time = AUDIT_BACKLOG_WAIT_TIME;
+
 	ab = audit_buffer_alloc(ctx, gfp_mask, type);
 	if (!ab) {
 		audit_log_lost(out of memory in audit_log_start);

[PATCH 0/2] audit: fix soft lockup

[Luiz Capitulino]

The second patch fixes a softlockup which is fully described and now is
100% reproducible with simple steps. The first patch fixes a bug I found
while working on the second patch.

Chuck Anderson just posted a different solution for the same problem.
I was about to post this solution when he posted his version, so I'm
posting it anyway.

Luiz capitulino (2):
  audit: flush_hold_queue(): don't drop queued SKBs
  audit: kaudit_send_skb(): make non-blocking call to netlink_unicast()

 kernel/audit.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

-- 
1.8.1.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 2/2] audit: kaudit_send_skb(): make non-blocking call to netlink_unicast()

[Luiz Capitulino]

From: Luiz capitulino lcapitul...@redhat.com

Try this:

 1. Download the readahead-collector program and build it
 2. Run it with:
   # readahead-collector -f
 3. From another terminal do:
   # pkill -SIGSTOP readahead-collector
 4. Keep using the system, run top -d1, vmstat -S 1, etc
 5. Eventually, you'll get something like this:

[  124.046016] BUG: soft lockup - CPU#0 stuck for 22s! [login:2196]
[  124.046016] Modules linked in:
[  124.046016] CPU: 0 PID: 2196 Comm: login Not tainted 
3.11.0-rc7-00030-g41615e8 #13
[  124.046016] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  124.046016] task: 88003d92c970 ti: 88003cd5 task.ti: 
88003cd5
[  124.046016] RIP: 0010:[8108a36c]  [8108a36c] 
audit_log_start+0x99/0x349
[  124.046016] RSP: 0018:88003cd51db0  EFLAGS: 0202
[  124.046016] RAX: 0100 RBX: 8107115e RCX: ea60
[  124.046016] RDX: 95f3 RSI: 0101 RDI: ea60
[  124.046016] RBP: 88003cd51e30 R08: 0100 R09: 
[  124.046016] R10: 000399b3 R11: 88003fc0d4a0 R12: 0046
[  124.046016] R13: 88003cd51d28 R14: 0046 R15: 810501ac
[  124.046016] FS:  7f80d3efa800() GS:88003fc0() 
knlGS:
[  124.046016] CS:  0010 DS:  ES:  CR0: 80050033
[  124.046016] CR2: 7f3f04f8c000 CR3: 3cd41000 CR4: 06b0
[  124.046016] Stack:
[  124.046016]  95f3 88003d747800 fffbfc40 
05160010
[  124.046016]  88003cd51e30   
88003d92c970
[  124.046016]  8105b3a6 dead00100100 dead00200200 
88003d747860
[  124.046016] Call Trace:
[  124.046016]  [8105b3a6] ? wake_up_state+0x12/0x12
[  124.046016]  [8108b6cb] audit_log_name+0x34/0x1a2
[  124.046016]  [8136f52b] ? _raw_spin_unlock_irqrestore+0x34/0x48
[  124.046016]  [8108ebe8] audit_log_exit+0xa44/0xa8f
[  124.046016]  [8108e07e] ? rcu_read_unlock+0x1c/0x2d
[  124.046016]  [8108efe8] ? audit_filter_inodes+0xf5/0x10e
[  124.046016]  [8108e17d] ? audit_filter_syscall+0xb2/0xd9
[  124.046016]  [8108f374] __audit_syscall_exit+0x4d/0x108
[  124.046016]  [813709c5] sysret_audit+0x17/0x21
[  124.046016] Code: e7 8b 05 1c ed 59 00 8b 0d 12 ed 59 00 8b 35 1c 24 e1 00 
46 8d 04 30 48 63 f9 85 c0 0f 84 29 01 00 00 44 39 c6 0f 86 20 01 00 00 83 7c 
24 18 00 0f 84 a4 00 00 00 85 c9 0f 84 9c 00 00 00 48 8b

This is what happens:

 1. The readahead-collector daemon got stuck and stops reading
from the netlink socket
 2. The kernel keeps logging stuff to the audit subsystem at
a high rate
 3. Because kauditd's call to netlink_unicast() is blocking and
as the netlink socket got a backlog, the kaudit thread will
eventually get blocked when trying to send an SKB to user-space
 4. As the kaudit thread is blocked, SKBs start to accumulate.
This will cause a thread calling audit_log_start() to
be put to sleep when a threshold of queued SBKs is reached
 5. The kaudit thread never wakes up, but the kernel thread
put to sleep in step 4 does. Soon or later sleep_time will be
negative, causing it to busy-wait in the while() loop

This commit fixes that problem by making the call to netlink_unicast()
non-blocking in kaudit_send_skb(). This way the kaudit thread
never gets blocked, completely avoiding the scenario described above.

Signed-off-by: Luiz capitulino lcapitul...@redhat.com
---
 kernel/audit.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 475c1d1..2b34bd6 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -385,8 +385,12 @@ static int kauditd_send_skb(struct sk_buff *skb)
int err;
/* take a reference in case we can't send it and we want to hold it */
skb_get(skb);
-   err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
-   if (err  0) {
+   err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 1);
+   if (err == -EAGAIN) {
+   pr_warn_ratelimited(auditd (pid=%d) is not responding\n, 
audit_pid);
+   audit_hold_skb(skb);
+   return err;
+   } else if (err  0) {
BUG_ON(err != -ECONNREFUSED); /* Shouldn't happen */
printk(KERN_ERR audit: *NO* daemon at audit_pid=%d\n, 
audit_pid);
audit_log_lost(auditd disappeared\n);
-- 
1.8.1.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 1/2] audit: flush_hold_queue(): don't drop queued SKBs

[Luiz Capitulino]

From: Luiz capitulino lcapitul...@redhat.com

flush_hold_queue() first dequeues an SKB and then checks if
auditd exists. If auditd doesn't exist, the SKB is silently
dropped.

Avoid this by not dequeing an SKB when we detected that
auditd disappeared.

Signed-off-by: Luiz capitulino lcapitul...@redhat.com
---
 kernel/audit.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 91e53d0..475c1d1 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -380,7 +380,7 @@ static void audit_printk_skb(struct sk_buff *skb)
audit_hold_skb(skb);
 }
 
-static void kauditd_send_skb(struct sk_buff *skb)
+static int kauditd_send_skb(struct sk_buff *skb)
 {
int err;
/* take a reference in case we can't send it and we want to hold it */
@@ -393,9 +393,12 @@ static void kauditd_send_skb(struct sk_buff *skb)
audit_pid = 0;
/* we might get lucky and get this in the next auditd */
audit_hold_skb(skb);
+   return err;
} else
/* drop the extra reference if sent ok */
consume_skb(skb);
+
+   return 0;
 }
 
 /*
@@ -416,6 +419,7 @@ static void kauditd_send_skb(struct sk_buff *skb)
 static void flush_hold_queue(void)
 {
struct sk_buff *skb;
+   int err;
 
if (!audit_default || !audit_pid)
return;
@@ -424,17 +428,12 @@ static void flush_hold_queue(void)
if (likely(!skb))
return;
 
-   while (skb  audit_pid) {
-   kauditd_send_skb(skb);
+   while (skb) {
+   err = kauditd_send_skb(skb);
+   if (err)
+   break;
skb = skb_dequeue(audit_skb_hold_queue);
}
-
-   /*
-* if auditd just disappeared but we
-* dequeued an skb we need to drop ref
-*/
-   if (skb)
-   consume_skb(skb);
 }
 
 static int kauditd_thread(void *dummy)
-- 
1.8.1.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/

Re: [PATCH v4 2/6] dma: edma: Write out and handle MAX_NR_SG at a given time

[Vinod Koul]

On Thu, Aug 29, 2013 at 06:05:41PM -0500, Joel Fernandes wrote:
 Process SG-elements in batches of MAX_NR_SG if they are greater
 than MAX_NR_SG. Due to this, at any given time only those many
 slots will be used in the given channel no matter how long the
 scatter list is. We keep track of how much has been written
 inorder to process the next batch of elements in the scatter-list
 and detect completion.
 
 For such intermediate transfer completions (one batch of MAX_NR_SG),
 make use of pause and resume functions instead of start and stop
 when such intermediate transfer is in progress or completed as we
 donot want to clear any pending events.
 
 Signed-off-by: Joel Fernandes jo...@ti.com
 ---
  drivers/dma/edma.c | 79 
 --
  1 file changed, 53 insertions(+), 26 deletions(-)
 
 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index e522ad5..732829b 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -56,6 +56,7 @@ struct edma_desc {
   struct list_headnode;
   int absync;
   int pset_nr;
 + int processed;
   struct edmacc_param pset[0];
  };
  
 @@ -104,22 +105,34 @@ static void edma_desc_free(struct virt_dma_desc *vdesc)
  /* Dispatch a queued descriptor to the controller (caller holds lock) */
  static void edma_execute(struct edma_chan *echan)
  {
 - struct virt_dma_desc *vdesc = vchan_next_desc(echan-vchan);
 + struct virt_dma_desc *vdesc;
   struct edma_desc *edesc;
 - int i;
 -
 - if (!vdesc) {
 - echan-edesc = NULL;
 - return;
 + struct device *dev = echan-vchan.chan.device-dev;
 + int i, j, left, nslots;
 +
 + /* If either we processed all psets or we're still not started */
 + if (!echan-edesc ||
 + echan-edesc-pset_nr == echan-edesc-processed) {
 + /* Get next vdesc */
 + vdesc = vchan_next_desc(echan-vchan);
 + if (!vdesc) {
 + echan-edesc = NULL;
 + return;
 + }
 + list_del(vdesc-node);
 + echan-edesc = to_edma_desc(vdesc-tx);
   }
  
 - list_del(vdesc-node);
 + edesc = echan-edesc;
  
 - echan-edesc = edesc = to_edma_desc(vdesc-tx);
 + /* Find out how many left */
 + left = edesc-pset_nr - edesc-processed;
 + nslots = min(MAX_NR_SG, left);
  
   /* Write descriptor PaRAM set(s) */
 - for (i = 0; i  edesc-pset_nr; i++) {
 - edma_write_slot(echan-slot[i], edesc-pset[i]);
 + for (i = 0; i  nslots; i++) {
 + j = i + edesc-processed;
 + edma_write_slot(echan-slot[i], edesc-pset[j]);
   dev_dbg(echan-vchan.chan.device-dev,
   \n pset[%d]:\n
 chnum\t%d\n
 @@ -132,24 +145,31 @@ static void edma_execute(struct edma_chan *echan)
 bidx\t%08x\n
 cidx\t%08x\n
 lkrld\t%08x\n,
 - i, echan-ch_num, echan-slot[i],
 - edesc-pset[i].opt,
 - edesc-pset[i].src,
 - edesc-pset[i].dst,
 - edesc-pset[i].a_b_cnt,
 - edesc-pset[i].ccnt,
 - edesc-pset[i].src_dst_bidx,
 - edesc-pset[i].src_dst_cidx,
 - edesc-pset[i].link_bcntrld);
 + j, echan-ch_num, echan-slot[i],
 + edesc-pset[j].opt,
 + edesc-pset[j].src,
 + edesc-pset[j].dst,
 + edesc-pset[j].a_b_cnt,
 + edesc-pset[j].ccnt,
 + edesc-pset[j].src_dst_bidx,
 + edesc-pset[j].src_dst_cidx,
 + edesc-pset[j].link_bcntrld);
   /* Link to the previous slot if not the last set */
 - if (i != (edesc-pset_nr - 1))
 + if (i != (nslots - 1))
   edma_link(echan-slot[i], echan-slot[i+1]);
   /* Final pset links to the dummy pset */
   else
   edma_link(echan-slot[i], echan-ecc-dummy_slot);
   }
  
 - edma_start(echan-ch_num);
 + edesc-processed += nslots;
 +
 + edma_resume(echan-ch_num);
 +
 + if (edesc-processed = MAX_NR_SG) {
 + dev_dbg(dev, first transfer starting %d\n, echan-ch_num);
 + edma_start(echan-ch_num);
 + }
  }
  
  static int edma_terminate_all(struct edma_chan *echan)
 @@ -368,19 +388,26 @@ static void edma_callback(unsigned ch_num, u16 
 ch_status, void *data)
   struct edma_desc *edesc;
   unsigned long flags;
  
 - /* Stop the channel */
 - edma_stop(echan-ch_num);
 + /* Pause the channel */
 + edma_pause(echan-ch_num);
  
   switch (ch_status) {
   case 

Re: [RFC PATCH v3 04/35] mm: Initialize node memory regions during boot

[Yasuaki Ishimatsu]

(2013/09/03 2:43), Srivatsa S. Bhat wrote:

On 09/02/2013 11:50 AM, Yasuaki Ishimatsu wrote:

(2013/08/30 22:15), Srivatsa S. Bhat wrote:

Initialize the node's memory-regions structures with the information
about
the region-boundaries, at boot time.

Based-on-patch-by: Ankita Garg gargank...@gmail.com
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---

   include/linux/mm.h |4 
   mm/page_alloc.c|   28 
   2 files changed, 32 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index f022460..18fdec4 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -627,6 +627,10 @@ static inline pte_t maybe_mkwrite(pte_t pte,
struct vm_area_struct *vma)
   #define LAST_NID_MASK((1UL  LAST_NID_WIDTH) - 1)
   #define ZONEID_MASK((1UL  ZONEID_SHIFT) - 1)

+/* Hard-code memory region size to be 512 MB for now. */
+#define MEM_REGION_SHIFT(29 - PAGE_SHIFT)
+#define MEM_REGION_SIZE(1UL  MEM_REGION_SHIFT)
+
   static inline enum zone_type page_zonenum(const struct page *page)
   {
   return (page-flags  ZONES_PGSHIFT)  ZONES_MASK;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b86d7e3..bb2d5d4 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4809,6 +4809,33 @@ static void __init_refok
alloc_node_mem_map(struct pglist_data *pgdat)
   #endif /* CONFIG_FLAT_NODE_MEM_MAP */
   }

+static void __meminit init_node_memory_regions(struct pglist_data
*pgdat)
+{
+int nid = pgdat-node_id;
+unsigned long start_pfn = pgdat-node_start_pfn;
+unsigned long end_pfn = start_pfn + pgdat-node_spanned_pages;
+struct node_mem_region *region;
+unsigned long i, absent;
+int idx;
+
+for (i = start_pfn, idx = 0; i  end_pfn;
+i += region-spanned_pages, idx++) {
+



+region = pgdat-node_regions[idx];


It seems that overflow easily occurs.
node_regions[] has 256 entries and MEM_REGION_SIZE is 512MiB. So if
the pgdat has more than 128 GiB, overflow will occur. Am I wrong?



No, you are right. It should be made dynamic to accommodate larger
memory. I just used that value as a placeholder, since my focus was to
demonstrate what algorithms and designs could be developed on top of
this infrastructure, to help shape memory allocations. But certainly
this needs to be modified to be flexible enough to work with any memory
size. Thank you for your review!


Thank you for your explanation. I understood it.

Thanks,
Yasuaki Ishimatsu



Regards,
Srivatsa S. Bhat




+region-pgdat = pgdat;
+region-start_pfn = i;
+region-spanned_pages = min(MEM_REGION_SIZE, end_pfn - i);
+region-end_pfn = region-start_pfn + region-spanned_pages;
+
+absent = __absent_pages_in_range(nid, region-start_pfn,
+ region-end_pfn);
+
+region-present_pages = region-spanned_pages - absent;
+}
+
+pgdat-nr_node_regions = idx;
+}
+
   void __paginginit free_area_init_node(int nid, unsigned long
*zones_size,
   unsigned long node_start_pfn, unsigned long *zholes_size)
   {
@@ -4837,6 +4864,7 @@ void __paginginit free_area_init_node(int nid,
unsigned long *zones_size,

   free_area_init_core(pgdat, start_pfn, end_pfn,
   zones_size, zholes_size);
+init_node_memory_regions(pgdat);
   }

   #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP









--
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/8] partitions/efi: use lba-aware partition records

[Davidlohr Bueso]

On Mon, 2013-09-02 at 12:10 +0200, Karel Zak wrote:
 On Mon, Aug 05, 2013 at 10:21:09PM -0700, Davidlohr Bueso wrote:
   
  +typedef struct _gpt_record {
  +u8  boot_indicator; /* unused by EFI, set to 0x80 for bootable 
  */
  +u8  start_head; /* unused by EFI, pt start in CHS */
  +u8  start_sector;   /* unused by EFI, pt start in CHS */
  +u8  start_track;
  +u8  os_type;/* EFI and legacy non-EFI OS types */
  +u8  end_head;   /* unused by EFI, pt end in CHS */
  +u8  end_sector; /* unused by EFI, pt end in CHS */
  +u8  end_track;  /* unused by EFI, pt end in CHS */
  +__le32  starting_lba;   /* used by EFI - start addr of the on disk 
  pt */
  +__le32  size_in_lba;/* used by EFI - size of pt in LBA */
  +} __attribute__ ((packed)) gpt_record;
  +
 
  Maybe it would be better to rename this struct to gpt_mbr_record to
  make it more obvious.

Yes, good idea. I've added the patch below.

8--
From: Davidlohr Bueso davidl...@hp.com
Subject: [PATCH] partitions/efi: rename gpt_record structure

Since the gpt_record structure is an MBR-specific
type, rename it to gpt_mbr_record for obvious
reading.

Suggested-by: Karel Zak k...@redhat.com
Signed-off-by: Davidlohr Bueso davidl...@hp.com
---
 block/partitions/efi.c | 2 +-
 block/partitions/efi.h | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/block/partitions/efi.c b/block/partitions/efi.c
index 8e6d77e..9a4eba7 100644
--- a/block/partitions/efi.c
+++ b/block/partitions/efi.c
@@ -152,7 +152,7 @@ static u64 last_lba(struct block_device *bdev)
   bdev_logical_block_size(bdev)) - 1ULL;
 }
 
-static inline int pmbr_part_valid(gpt_record *part)
+static inline int pmbr_part_valid(gpt_mbr_record *part)
 {
 if (part-os_type != EFI_PMBR_OSTYPE_EFI_GPT)
 goto invalid;
diff --git a/block/partitions/efi.h b/block/partitions/efi.h
index 9ab8ee9..54b2687 100644
--- a/block/partitions/efi.h
+++ b/block/partitions/efi.h
@@ -104,7 +104,7 @@ typedef struct _gpt_entry {
efi_char16_t partition_name[72 / sizeof (efi_char16_t)];
 } __attribute__ ((packed)) gpt_entry;
 
-typedef struct _gpt_record {
+typedef struct _gpt_mbr_record {
 u8  boot_indicator; /* unused by EFI, set to 0x80 for bootable */
 u8  start_head; /* unused by EFI, pt start in CHS */
 u8  start_sector;   /* unused by EFI, pt start in CHS */
@@ -115,14 +115,14 @@ typedef struct _gpt_record {
 u8  end_track;  /* unused by EFI, pt end in CHS */
 __le32  starting_lba;   /* used by EFI - start addr of the on disk pt 
*/
 __le32  size_in_lba;/* used by EFI - size of pt in LBA */
-} __attribute__ ((packed)) gpt_record;
+} __attribute__ ((packed)) gpt_mbr_record;
 
 
 typedef struct _legacy_mbr {
u8 boot_code[440];
__le32 unique_mbr_signature;
__le16 unknown;
-   gpt_record partition_record[4];
+   gpt_mbr_record partition_record[4];
__le16 signature;
 } __attribute__ ((packed)) legacy_mbr;
 
-- 
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] kernel/delayacct.c: remove redundancy checking in __delayacct_add_tsk()

[Chen Gang]

The wrapper function delayacct_add_tsk() already checked 'tsk-delays',
and __delayacct_add_tsk() has no another direct callers, so can remove
the redundancy checking code.

And the label 'done' is also useless, so remove it, too.


Signed-off-by: Chen Gang gang.c...@asianux.com
---
 kernel/delayacct.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/kernel/delayacct.c b/kernel/delayacct.c
index d473988..54996b7 100644
--- a/kernel/delayacct.c
+++ b/kernel/delayacct.c
@@ -108,12 +108,6 @@ int __delayacct_add_tsk(struct taskstats *d, struct 
task_struct *tsk)
struct timespec ts;
cputime_t utime, stime, stimescaled, utimescaled;
 
-   /* Though tsk-delays accessed later, early exit avoids
-* unnecessary returning of other data
-*/
-   if (!tsk-delays)
-   goto done;
-
tmp = (s64)d-cpu_run_real_total;
task_cputime(tsk, utime, stime);
cputime_to_timespec(utime + stime, ts);
@@ -158,7 +152,6 @@ int __delayacct_add_tsk(struct taskstats *d, struct 
task_struct *tsk)
d-freepages_count += tsk-delays-freepages_count;
spin_unlock_irqrestore(tsk-delays-lock, flags);
 
-done:
return 0;
 }
 
-- 
1.7.7.6
--
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/

[RFC/PATCH] ftrace: add set_graph_notrace filter

[Namhyung Kim]

From: Namhyung Kim namhyung@lge.com

The set_graph_notrace filter is analogous to set_ftrace_notrace and
can be used for eliminating uninteresting part of function graph trace
output.  It also works with set_graph_function nicely.

  # cd /sys/kernel/debug/tracing/
  # echo do_page_fault  set_graph_function
  # perf ftrace live true
   2)   |  do_page_fault() {
   2)   |__do_page_fault() {
   2)   0.381 us|  down_read_trylock();
   2)   0.055 us|  __might_sleep();
   2)   0.696 us|  find_vma();
   2)   |  handle_mm_fault() {
   2)   |handle_pte_fault() {
   2)   |  __do_fault() {
   2)   |filemap_fault() {
   2)   |  find_get_page() {
   2)   0.033 us|__rcu_read_lock();
   2)   0.035 us|__rcu_read_unlock();
   2)   1.696 us|  }
   2)   0.031 us|  __might_sleep();
   2)   2.831 us|}
   2)   |_raw_spin_lock() {
   2)   0.046 us|  add_preempt_count();
   2)   0.841 us|}
   2)   0.033 us|page_add_file_rmap();
   2)   |_raw_spin_unlock() {
   2)   0.057 us|  sub_preempt_count();
   2)   0.568 us|}
   2)   |unlock_page() {
   2)   0.084 us|  page_waitqueue();
   2)   0.126 us|  __wake_up_bit();
   2)   1.117 us|}
   2)   7.729 us|  }
   2)   8.397 us|}
   2)   8.956 us|  }
   2)   0.085 us|  up_read();
   2) + 12.745 us   |}
   2) + 13.401 us   |  }
  ...

  # echo handle_mm_fault  set_graph_notrace
  # perf ftrace live true
   1)   |  do_page_fault() {
   1)   |__do_page_fault() {
   1)   0.205 us|  down_read_trylock();
   1)   0.041 us|  __might_sleep();
   1)   0.344 us|  find_vma();
   1)   0.069 us|  up_read();
   1)   4.692 us|}
   1)   5.311 us|  }
  ...

Signed-off-by: Namhyung Kim namhy...@kernel.org
---
 include/linux/ftrace.h   |   1 +
 kernel/trace/ftrace.c| 118 ++-
 kernel/trace/trace.h |  23 +++
 kernel/trace/trace_functions_graph.c |  21 ++-
 4 files changed, 159 insertions(+), 4 deletions(-)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 9f15c0064c50..ec85d48619e1 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -721,6 +721,7 @@ ftrace_push_return_trace(unsigned long ret, unsigned long 
func, int *depth,
 extern char __irqentry_text_start[];
 extern char __irqentry_text_end[];
 
+#define FTRACE_NOTRACE_DEPTH 65536
 #define FTRACE_RETFUNC_DEPTH 50
 #define FTRACE_RETSTACK_ALLOC_SIZE 32
 extern int register_ftrace_graph(trace_func_graph_ret_t retfunc,
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index a6d098c6df3f..1b1f3409f788 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3819,6 +3819,43 @@ static const struct seq_operations ftrace_graph_seq_ops 
= {
.show = g_show,
 };
 
+int ftrace_graph_notrace_count;
+int ftrace_graph_notrace_enabled;
+unsigned long ftrace_graph_notrace_funcs[FTRACE_GRAPH_MAX_FUNCS] __read_mostly;
+
+static void *
+__n_next(struct seq_file *m, loff_t *pos)
+{
+   if (*pos = ftrace_graph_notrace_count)
+   return NULL;
+   return ftrace_graph_notrace_funcs[*pos];
+}
+
+static void *
+n_next(struct seq_file *m, void *v, loff_t *pos)
+{
+   (*pos)++;
+   return __n_next(m, pos);
+}
+
+static void *n_start(struct seq_file *m, loff_t *pos)
+{
+   mutex_lock(graph_lock);
+
+   /* Nothing, tell g_show to print all functions are enabled */
+   if (!ftrace_graph_notrace_enabled  !*pos)
+   return (void *)1;
+
+   return __n_next(m, pos);
+}
+
+static const struct seq_operations ftrace_graph_notrace_seq_ops = {
+   .start = n_start,
+   .next = n_next,
+   .stop = g_stop,
+   .show = g_show,
+};
+
 static int
 ftrace_graph_open(struct inode *inode, struct file *file)
 {
@@ -3843,6 +3880,30 @@ ftrace_graph_open(struct inode *inode, struct file *file)
 }
 
 static int
+ftrace_graph_notrace_open(struct inode *inode, struct file *file)
+{
+   int ret = 0;
+
+   if (unlikely(ftrace_disabled))
+   return -ENODEV;
+
+   mutex_lock(graph_lock);
+   if ((file-f_mode  FMODE_WRITE) 
+   (file-f_flags  O_TRUNC)) {
+   ftrace_graph_notrace_enabled = 0;
+   ftrace_graph_notrace_count = 0;
+   memset(ftrace_graph_notrace_funcs, 0,
+  sizeof(ftrace_graph_notrace_funcs));
+   }
+   mutex_unlock(graph_lock);
+
+   if (file-f_mode  FMODE_READ)
+   ret = seq_open(file, ftrace_graph_notrace_seq_ops);
+
+  

Re: [PATCH] kernel/taskstats.c: add nla_nest_cancel() for failure processing between nla_nest_start() and nla_nest_end()

[Chen Gang]

Hello maintainers:

Please help check this patch, when you have time.

Thanks.

On 08/20/2013 10:44 AM, Chen Gang wrote:
 When failure occurs between nla_nest_start() and nla_nest_end(), need
 call nla_nest_cancel() to clean up related things.
 
 Signed-off-by: Chen Gang gang.c...@asianux.com
 ---
  kernel/taskstats.c |8 ++--
  1 files changed, 6 insertions(+), 2 deletions(-)
 
 diff --git a/kernel/taskstats.c b/kernel/taskstats.c
 index 145bb4d..1db6808 100644
 --- a/kernel/taskstats.c
 +++ b/kernel/taskstats.c
 @@ -404,11 +404,15 @@ static struct taskstats *mk_reply(struct sk_buff *skb, 
 int type, u32 pid)
   if (!na)
   goto err;
  
 - if (nla_put(skb, type, sizeof(pid), pid)  0)
 + if (nla_put(skb, type, sizeof(pid), pid)  0) {
 + nla_nest_cancel(skb, na);
   goto err;
 + }
   ret = nla_reserve(skb, TASKSTATS_TYPE_STATS, sizeof(struct taskstats));
 - if (!ret)
 + if (!ret) {
 + nla_nest_cancel(skb, na);
   goto err;
 + }
   nla_nest_end(skb, na);
  
   return nla_data(ret);
 


-- 
Chen Gang
--
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] kernel/futex.c: notice the return value after rt_mutex_finish_proxy_lock() fails

[Chen Gang]

Hello Maintainers:

Please help check this patch, when you have time.


Thanks.

On 08/21/2013 11:48 AM, Chen Gang wrote:
 On 08/21/2013 12:19 AM, Darren Hart wrote:
 HopingOn Tue, 2013-08-20 at 11:07 +0800, Chen Gang wrote:


 Hi Chen,

 rt_mutex_finish_proxy_lock() can return failure code (e.g. -EINTR,
 -ETIMEDOUT).

 Original implementation has already noticed about it, but not check it
 before next work.

 Also let coments within 80 columns to pass ./scripts/checkpatch.pl.


 Signed-off-by: Chen Gang gang.c...@asianux.com
 ---
  kernel/futex.c |   30 --
  1 files changed, 16 insertions(+), 14 deletions(-)

 diff --git a/kernel/futex.c b/kernel/futex.c
 index c3a1a55..1a94e7d 100644
 --- a/kernel/futex.c
 +++ b/kernel/futex.c
 @@ -2373,21 +2373,23 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, 
 unsigned int flags,
 ret = rt_mutex_finish_proxy_lock(pi_mutex, to, rt_waiter, 1);
 debug_rt_mutex_free_waiter(rt_waiter);
  
 -   spin_lock(q.lock_ptr);
 -   /*
 -* Fixup the pi_state owner and possibly acquire the lock if we
 -* haven't already.
 -*/
 -   res = fixup_owner(uaddr2, q, !ret);


 This call catches a corner case which appears to be skipped now. Or am I
 missing how you accounted for that?


 
 Pardon ?
 
 Hmm... this patch lets related code block in if(!ret) {...}, should
 not remove any code.
 
 Please help check again for whether what I have done is correct or not.
 
 Thanks.
 
 -   /*
 -* If fixup_owner() returned an error, proprogate that.  If it
 -* acquired the lock, clear -ETIMEDOUT or -EINTR.
 -*/
 -   if (res)
 -   ret = (res  0) ? res : 0;
 +   if (!ret) {
 +   spin_lock(q.lock_ptr);
 +   /*
 +* Fixup the pi_state owner and possibly acquire the
 +* lock if we haven't already.
 +*/
 +   res = fixup_owner(uaddr2, q, !ret);
 +   /*
 +* If fixup_owner() returned an error, proprogate that.
 +* If it acquired the lock, clear -ETIMEDOUT or -EINTR.
 +*/
 +   if (res)
 +   ret = (res  0) ? res : 0;
  
 -   /* Unqueue and drop the lock. */
 -   unqueue_me_pi(q);
 +   /* Unqueue and drop the lock. */
 +   unqueue_me_pi(q);
 +   }
 }
  
 /*

 Thanks,

 
 


-- 
Chen Gang
--
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] kernel/sysctl.c: check return value after call proc_put_char() in __do_proc_doulongvec_minmax()

[Chen Gang]

Need check the return value of proc_put_char(), just like another have
done in __do_proc_doulongvec_minmax().

Signed-off-by: Chen Gang gang.c...@asianux.com
---
 kernel/sysctl.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index b2f06f3..7453418 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2214,8 +2214,11 @@ static int __do_proc_doulongvec_minmax(void *data, 
struct ctl_table *table, int
*i = val;
} else {
val = convdiv * (*i) / convmul;
-   if (!first)
+   if (!first) {
err = proc_put_char(buffer, left, '\t');
+   if (err)
+   break;
+   }
err = proc_put_long(buffer, left, val, false);
if (err)
break;
-- 
1.7.7.6
--
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: Large pastes into readline enabled programs causes breakage from v2.6.31 onwards

[Arkadiusz Miskiewicz]

On Sunday 18 of August 2013, Margarita Manterola wrote:
 Hi,
 
 On Sat, Aug 17, 2013 at 5:28 PM, Pavel Machek pa...@ucw.cz wrote:
  diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
  index 4bf0fc0..2ba7f4e 100644
  --- a/drivers/tty/n_tty.c
  +++ b/drivers/tty/n_tty.c
  @@ -149,7 +149,8 @@ static int set_room(struct tty_struct *tty)
  
   * characters will be beeped.
   */
  
  if (left = 0)
  
  -   left = ldata-icanon  !ldata-canon_data;
  +   if (waitqueue_active(tty-read_wait))
  +   left = ldata-icanon  !ldata-canon_data;
  
  old_left = tty-receive_room;
  tty-receive_room = left;
  
  Was this applied? You may want to cc rjw... it is a regression, it is
  not pretty, and it is something I blieve I hit but thought it was some
  kind of X weirdness.
 
 There were no replies to the previous mail asking for comments, and as
 far as I can see this has not been applied. I don't know who rjw is,
 could you be a bit more explicit, please?

Hi.

Was there some kind of continuation of this thread or the thing died 
completly?

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
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] kernel/groups.c: consider about NULL for 'group_info' in all related extern functions

[Chen Gang]

Hello Maintainers:

Please help check this patch, when you have time.

If need a related test, please let me know, I should try (better to
provide some suggestions for test).


Thanks.

On 08/20/2013 11:03 AM, Chen Gang wrote:
 
 If this patch is correct, also need modify the man page for the return
 value of getgroups().
 
 Thanks.
 
 On 08/20/2013 11:01 AM, Chen Gang wrote:
 groups_alloc() can return NULL for 'group_info', also group_search()
 already considers about NULL for 'group_info', so can assume the caller
 has right to use all related extern functions when 'group_info' is NULL.

 For groups_free(), need check NULL to match groups_alloc(), just like
 kmalloc/free().

 For set_groups(), can allow the caller to set NULL parameter to new
 'cred'.

 For system call getgroups(), if 'cred-group_info' is NULL, need return
 the related error code (no related data), also need change the related
 man page (man 2 getgroups) to complete the return value.


 Signed-off-by: Chen Gang gang.c...@asianux.com
 ---
  kernel/groups.c |   14 +++---
  1 files changed, 11 insertions(+), 3 deletions(-)

 diff --git a/kernel/groups.c b/kernel/groups.c
 index 6b2588d..a21a4ce 100644
 --- a/kernel/groups.c
 +++ b/kernel/groups.c
 @@ -52,6 +52,9 @@ EXPORT_SYMBOL(groups_alloc);

  void groups_free(struct group_info *group_info)
  {
 +if (!group_info)
 +return;
 +
  if (group_info-blocks[0] != group_info-small_block) {
  int i;
  for (i = 0; i  group_info-nblocks; i++)
 @@ -163,9 +166,12 @@ int groups_search(const struct group_info
 *group_info, kgid_t grp)
   */
  int set_groups(struct cred *new, struct group_info *group_info)
  {
 -put_group_info(new-group_info);
 -groups_sort(group_info);
 -get_group_info(group_info);
 +if (new-group_info)
 +put_group_info(new-group_info);
 +if (group_info) {
 +groups_sort(group_info);
 +get_group_info(group_info);
 +}
  new-group_info = group_info;
  return 0;
  }
 @@ -206,6 +212,8 @@ SYSCALL_DEFINE2(getgroups, int, gidsetsize, gid_t
 __user *, grouplist)

  if (gidsetsize  0)
  return -EINVAL;
 +if (!cred-group_info)
 +return -ENODATA;

  /* no need to grab task_lock here; it cannot change */
  i = cred-group_info-ngroups;

 
 


-- 
Chen Gang
--
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 4/4] Documentation: Add device tree bindings for Freescale FTM PWM

[Xiubo Li-B47053]

 Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for
 Freescale FTM PWM
 
 On 08/30/2013 01:19 PM, Kumar Gala wrote:
  Should have at least something w/regards to a commit message.
 
  On Aug 20, 2013, at 10:07 PM, Xiubo Li wrote:
 
  Signed-off-by: Xiubo Li li.xi...@freescale.com
  ---
  .../devicetree/bindings/pwm/fsl-ftm-pwm.txt| 52
 ++
  1 file changed, 52 insertions(+)
  create mode 100644
  Documentation/devicetree/bindings/pwm/fsl-ftm-pwm.txt
 
  diff --git a/Documentation/devicetree/bindings/pwm/fsl-ftm-pwm.txt
  b/Documentation/devicetree/bindings/pwm/fsl-ftm-pwm.txt
  new file mode 100644
  index 000..698965b
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/pwm/fsl-ftm-pwm.txt
  @@ -0,0 +1,52 @@
  +Freescale FTM PWM controller
  +
  +Required properties:
  +- compatible: should be fsl,vf610-ftm-pwm
  +- reg: physical base address and length of the controller's
  +registers
  +- #pwm-cells: Should be 3. Number of cells being used to specify PWM
 property.
  +  First cell specifies the per-chip channel index of the PWM to use,
  +the
  +  second cell is the period in nanoseconds and bit 0 in the third
  +cell is
  +  used to encode the polarity of PWM output. Set bit 0 of the third
  +in PWM
  +  specifier to 1 for inverse polarity  set to 0 for normal polarity.
  +- fsl,pwm-clk-ps: the ftm0 pwm clock's prescaler, divide-by 2^n(n = 0
 ~ 7).
  +- fsl,pwm-cpwm: Center-Aligned PWM (CPWM) mode.
 
  Should describe this in more detail, what does the value actually mean
 for what modes there are?
 
 Assuming CPWM is clearly explained in the HW documentation for this
 chip (I have no idea if that's actually the case), then is it still
 necessary to explain what this means in *detail*? Perhaps simply see
 section XXX in the TRM or see register XXX, bit YYY in the HW
 documentation would be enough?

If to clearly explain the 'CPWM' mode, there maybe need much more words, I 
think just simply explain it, and then for more detail information see section 
XXX in the TRM or see register XXX, bit YYY in HW documentation.


Thanks.

--
Best Regards,
Xiubo


--
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/shmem.c: check the return value of mpol_to_str()

[Chen Gang]

Hello Maintainers:

Please help check this patch, when you have time.

If it need additional test, please let me know, I should try (better to
provide some suggestions for test).


Thanks.

On 08/22/2013 09:04 AM, Chen Gang wrote:
 mpol_to_str() may fail, and not fill the buffer (e.g. -EINVAL), so need
 check about it, or buffer may not be zero based, and next seq_printf()
 will cause issue.
 
 Also need let shmem_show_mpol() return value, since it may fail.
 
 Signed-off-by: Chen Gang gang.c...@asianux.com
 Reviewed-by: Cyrill Gorcunov gorcu...@gmail.com
 ---
  mm/shmem.c |   16 ++--
  1 files changed, 10 insertions(+), 6 deletions(-)
 
 diff --git a/mm/shmem.c b/mm/shmem.c
 index f00c1c1..b4d44db 100644
 --- a/mm/shmem.c
 +++ b/mm/shmem.c
 @@ -883,16 +883,20 @@ redirty:
  
  #ifdef CONFIG_NUMA
  #ifdef CONFIG_TMPFS
 -static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
 +static int shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
  {
   char buffer[64];
 + int ret;
  
   if (!mpol || mpol-mode == MPOL_DEFAULT)
 - return; /* show nothing */
 + return 0;   /* show nothing */
  
 - mpol_to_str(buffer, sizeof(buffer), mpol);
 + ret = mpol_to_str(buffer, sizeof(buffer), mpol);
 + if (ret  0)
 + return ret;
  
   seq_printf(seq, ,mpol=%s, buffer);
 + return 0;
  }
  
  static struct mempolicy *shmem_get_sbmpol(struct shmem_sb_info *sbinfo)
 @@ -951,8 +955,9 @@ static struct page *shmem_alloc_page(gfp_t gfp,
  }
  #else /* !CONFIG_NUMA */
  #ifdef CONFIG_TMPFS
 -static inline void shmem_show_mpol(struct seq_file *seq, struct mempolicy 
 *mpol)
 +static inline int shmem_show_mpol(struct seq_file *seq, struct mempolicy 
 *mpol)
  {
 + return 0;
  }
  #endif /* CONFIG_TMPFS */
  
 @@ -2555,8 +2560,7 @@ static int shmem_show_options(struct seq_file *seq, 
 struct dentry *root)
   if (!gid_eq(sbinfo-gid, GLOBAL_ROOT_GID))
   seq_printf(seq, ,gid=%u,
   from_kgid_munged(init_user_ns, sbinfo-gid));
 - shmem_show_mpol(seq, sbinfo-mpol);
 - return 0;
 + return shmem_show_mpol(seq, sbinfo-mpol);
  }
  #endif /* CONFIG_TMPFS */
  
 


-- 
Chen Gang
--
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 1/3] mm/vmalloc: don't set area-caller twice

[Zhang Yanfei]

On 09/03/2013 11:00 AM, Wanpeng Li wrote:
 Changelog:
  * rebase against mmotm tree
 
 The caller address has already been set in set_vmalloc_vm(), there's no need
 to set it again in __vmalloc_area_node.
 
 Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com

Reviewed-by: Zhang Yanfei zhangyan...@cn.fujitsu.com

 ---
  mm/vmalloc.c |1 -
  1 files changed, 0 insertions(+), 1 deletions(-)
 
 diff --git a/mm/vmalloc.c b/mm/vmalloc.c
 index 1074543..d78d117 100644
 --- a/mm/vmalloc.c
 +++ b/mm/vmalloc.c
 @@ -1566,7 +1566,6 @@ static void *__vmalloc_area_node(struct vm_struct 
 *area, gfp_t gfp_mask,
   pages = kmalloc_node(array_size, nested_gfp, node);
   }
   area-pages = pages;
 - area-caller = caller;
   if (!area-pages) {
   remove_vm_area(area-addr);
   kfree(area);
 


-- 
Thanks.
Zhang Yanfei
--
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 2/3] mm/vmalloc: don't warning vmalloc allocation failure twice

[Zhang Yanfei]

On 09/03/2013 11:00 AM, Wanpeng Li wrote:
 Don't warning twice in __vmalloc_area_node and __vmalloc_node_range if
 __vmalloc_area_node allocation failure.
 
 Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com

OK, I missed the warning in __vmalloc_area_node(), so you are right.
You can just revert the commit 46c001a2753f47ffa621131baa3409e636515347.

 ---
  mm/vmalloc.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/mm/vmalloc.c b/mm/vmalloc.c
 index d78d117..e3ec8b4 100644
 --- a/mm/vmalloc.c
 +++ b/mm/vmalloc.c
 @@ -1635,7 +1635,7 @@ void *__vmalloc_node_range(unsigned long size, unsigned 
 long align,
  
   addr = __vmalloc_area_node(area, gfp_mask, prot, node, caller);
   if (!addr)
 - goto fail;
 + return NULL;
  
   /*
* In this function, newly allocated vm_struct has VM_UNINITIALIZED
 


-- 
Thanks.
Zhang Yanfei
--
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 RESEND 2/3] x86, mm: Update min_pfn_mapped in add_pfn_range_mapped().

[Tang Chen]

On 09/03/2013 10:48 AM, Yinghai Lu wrote:

On Mon, Sep 2, 2013 at 6:06 PM, Tang Chentangc...@cn.fujitsu.com  wrote:

Hi Yinghai,

On 09/03/2013 02:41 AM, Yinghai Lu wrote:



How about change the for (from low to high) in init_range_memory_mapping()
to
for_rev(from high to low) ?
Then we can update min_pfn_mapped in add_pfn_range_mapped().

And also, the outer loop is from high to low, we can change the inner loop
to be from high
to low too.


No. there is other reason for doing local from low to high.

kernel_physical_mapping_init() could clear some mapping near the end
of PUG/PMD entries but not the head.


Thanks for your explanation. But sorry, I'd like to understand it more 
clearly.


Are you talking about the following code ?
phys_pud_init()
{
if (addr = end) {
if (!after_bootmem 
!e820_any_mapped(addr  PUD_MASK, next, 
E820_RAM) 
!e820_any_mapped(addr  PUD_MASK, next, 
E820_RESERVED_KERN))

set_pud(pud, __pud(0));
continue;
}
}
It will clear the PUD/PMD out of range.


But,
init_mem_mapping()
{
while (from high to low) {
init_range_memory_mapping()
{
for (from low to high) {		/* I'm saying changing this 
loop */

init_memory_mapping()
{
for () {
/* Not this one */
kernel_physical_mapping_init();
}
add_pfn_range_mapped();
}
}
}
}
}

I'm saying changing the outer loop in init_range_memory_mapping(), not 
the one in init_memory_mapping().
I think it is OK to call init_memory_mapping() with any order. The loop 
is out of init_memory_mapping(), right ?


In init_memory_mapping(), it is still from low to high. But when the 
kernel_physical_mapping_init() finished,
we can update min_pfn_mapped in add_pfn_range_mapped() because the outer 
loop is from high to low.


Am I missing something here ?  Please tell me.





I think updating min_pfn_mapped in init_mem_mapping() is less readable. And
min_pfn_mapped
and max_pfn_mapped should be updated together.


min_pfn_mapped is early local variable to control allocation in alloc_low_pages.
put it in init_mem_mapping is more readable.



But add_pfn_range_mapped() is in the same file with init_mem_mapping(). 
I think

it is OK to update min_pfn_mapped in it.

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: [PATCH v2 3/3] mm/vmalloc: move VM_UNINITIALIZED just before show_numa_info

[Zhang Yanfei]

On 09/03/2013 11:00 AM, Wanpeng Li wrote:
 The VM_UNINITIALIZED/VM_UNLIST flag introduced by commit f5252e00(mm: avoid
 null pointer access in vm_struct via /proc/vmallocinfo) is used to avoid
 accessing the pages field with unallocated page when show_numa_info() is
 called. This patch move the check just before show_numa_info in order that
 some messages still can be dumped via /proc/vmallocinfo.
 
 Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com

Hmmm, sorry again. Please revert commit
d157a5581548caec311dfb543ce8a79e283e. That said, we could still
do the check in show_numa_info like before.

 ---
  mm/vmalloc.c |   10 +-
  1 files changed, 5 insertions(+), 5 deletions(-)
 
 diff --git a/mm/vmalloc.c b/mm/vmalloc.c
 index e3ec8b4..c4720cd 100644
 --- a/mm/vmalloc.c
 +++ b/mm/vmalloc.c
 @@ -2590,11 +2590,6 @@ static int s_show(struct seq_file *m, void *p)
  
   v = va-vm;
  
 - /* Pair with smp_wmb() in clear_vm_uninitialized_flag() */
 - smp_rmb();
 - if (v-flags  VM_UNINITIALIZED)
 - return 0;
 -
   seq_printf(m, 0x%pK-0x%pK %7ld,
   v-addr, v-addr + v-size, v-size);
  
 @@ -2622,6 +2617,11 @@ static int s_show(struct seq_file *m, void *p)
   if (v-flags  VM_VPAGES)
   seq_printf(m,  vpages);
  
 + /* Pair with smp_wmb() in clear_vm_uninitialized_flag() */
 + smp_rmb();
 + if (v-flags  VM_UNINITIALIZED)
 + return 0;
 +
   show_numa_info(m, v);
   seq_putc(m, '\n');
   return 0;
 


-- 
Thanks.
Zhang Yanfei
--
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] kernel/rcutree.c: deem to be lazy if there are no callbacks.

[Chen Gang]

Hello Maintainers:

Is this issue finished ?

If need additional help from me (e.g. some test things, or others, if
you have no time, can let me try), please let me know, I should try.


Thanks.

On 08/26/2013 10:21 AM, Chen Gang F T wrote:
 
 Firstly, thank you for your reply with these details. 
 
 On 08/26/2013 03:18 AM, Paul E. McKenney wrote:
 On Thu, Aug 22, 2013 at 11:01:53AM +0800, Chen Gang wrote:
 On 08/21/2013 10:23 PM, Paul E. McKenney wrote:
 On Wed, Aug 21, 2013 at 01:59:29PM +0800, Chen Gang wrote:

 [ . . . ]

 Don't get me wrong, I do welcome appropriate patches.  In fact, if
 you look at RCU's git history, you will see that I frequently accept
 patches from a fair number of people.  And if you were willing to
 invest some time and thought, you might eventually be able to generate
 an appropriate (albeit low priority) patch to this function.  However,
 you seem to be motivated to submit small patches with a minimum of
 thought and preparation, perhaps because you need to meet some external
 or self-imposed quota of accepted patches.  And if you are in fact driven
 by a quota that prevents you from taking the time required to carefully
 think things through, you are wasting your time with RCU.

 Hmm... at least, some contents you said above is correct to me.

 At least, I should provide 10 patches per month, it is a necessary
 basic requirement to me.

 OK, that does help explain the otherwise inexplicable approach you have
 been taking.  Let's see how you have been doing, based on committer date
 in Linus's tree:

   1 2012-11
  15 2013-01
   7 2013-02
  20 2013-03
  21 2013-04
  12 2013-05
  17 2013-06
  10 2013-07

 The last few months might be understated a bit due to patches
 still being in maintainer trees.  This is a nice contrast from my
 first impression of you from https://lkml.org/lkml/2013/6/9/64 and
 https://lkml.org/lkml/2013/8/19/650, neither of which gave me any
 reason to trust your work, to put it mildly.  And if I cannot trust
 your work, I obviously cannot accept your patches.

 
 Hmm... better to check patches independent personal feelings (trust
 some one, or not).
 
 ;-)
 
 
 You do seem to select for localized bug fixes, which require less work
 than the performance-motivated patches you were putting forward earlier
 in this thread.  With a localized bug, you demonstrate the bug, show the
 fix, and that is that.  From what I can see, part of the problem with
 your patches in this email thread is that you are trying to move from
 localized bug fixes to performance issues without doing the additional
 work required.  Please see below for a rough outline of this additional
 work.

 
 Hmm... it seems I need describe my work flow for fixing bugs in details.
 
   1. Is it a bug ?
  if so, I can be marked as Reported-by and continue to 2nd.
  else, it is a waste mail.
 
   2. Try to fix it in simple ways (so can save the maintainers time resource).
  if it can be accepted by maintainers, it is OK (I can be Signed-off-by).
  else need continue to 3rd.
 
exception: if I can not find a simple way to fix it, I will send 
 [Suggestion] mail.
 
   3. Do the maintainers know how to fix it ?
  if yes, fix it together with maintainers (may mark me only as 
 Reported-by).
  else need continue to Last.
 
   Last: I should analyze it and fix it (it is my duty to fix it).
 
 
 How do you feel about this work flow ? welcome any suggestions or
 completions.
 
 Thanks.
 
 And what my focus is efficiency: let appliers and maintainers together
 to provide contributes to outside with efficiency.

 Sounds great, but there are many possible definitions of efficiency.
 Given your quota, I would expect your definition to involve number of
 patches accepted.  In contrast, my definition for RCU instead involves
 maintainability, robustness, scalability, and, for a few critical
 code paths, performance.  I therefore need you to have thought through
 and carefully tested your patch.

 
 Hmm... it seems I need give more description for the 'efficiency' which
 I point to.
 
 If it is no negative effect with the quality, we need try to use less
 resources (e.g. time resources) to provide more contributions (e.g. fix
 issue).
 
 
 If you already know about it, why need I continue ?  but if you don't
 know either, I should try.

 What I need you to do in future RCU performance patch submissions is:

 1.   Think through your patch and the code that it is modifying.
  If you submit a patch to me, you should be able to answer the
  sorts of questions that I was asking in this thread.

 2.   Tell me what situations your patch helps and not.

 3.   Tell me how much your patch improves performance in the
  situations where it helps.

 4.   Test the code.  If it makes a measurable difference, present
  the performance results.  (It would be very surprising if your
  early-loop exit patch made a significant difference, expecially

Re: [GIT PULL rcu/next] RCU commits for 3.12

[Ingo Molnar]

* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:

 Hello, Ingo,
 
 The major changes for this series are:
 
 1.Update RCU documentation.  These were posted to LKML at
   https://lkml.org/lkml/2013/8/19/611.
 
 2.Miscellaneous fixes.  These were posted to LKML at
   https://lkml.org/lkml/2013/8/19/619.
 
 3.Full-system idle detection.  This is for use by Frederic
   Weisbecker's adaptive-ticks mechanism.  Its purpose is
   to allow the timekeeping CPU to shut off its tick when
   all other CPUs are idle.  These were posted to LKML at
   https://lkml.org/lkml/2013/8/19/648.
 
 4.Improve rcutorture test coverage.  These were posted to LKML at
   https://lkml.org/lkml/2013/8/19/675.
 
 All of these commits have been subjected to -next testing and are
 available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next
 
 for you to fetch changes up to 25f27ce4a6a4995c8bdd69b4b2180465ed5ad2b8:
 
   Merge branches 'doc.2013.08.19a', 'fixes.2013.08.20a', 
 'sysidle.2013.08.31a' and 'torture.2013.08.20a' into HEAD (2013-08-31 
 14:44:45 -0700)
 
 
 
 Borislav Petkov (1):
   rcu: Expedite grace periods during suspend/resume
 
 James Hogan (1):
   rcu: Select IRQ_WORK from TREE_PREEMPT_RCU
 
 Paul E. McKenney (24):
   rcu: Fix rcu_barrier() documentation
   rcu: Simplify debug-objects fixups
   debugobjects: Make debug_object_activate() return status
   rcu: Make call_rcu() leak callbacks for debug-object errors
   rcu: Avoid redundant grace-period kthread wakeups
   rcu: Eliminate unused APIs intended for adaptive ticks
   nohz_full: Add testing information to documentation
   nohz_full: Add Kconfig parameter for scalable detection of all-idle 
 state
   nohz_full: Add rcu_dyntick data for scalable detection of all-idle state
   nohz_full: Add per-CPU idle-state tracking
   nohz_full: Add full-system idle states and variables
   nohz_full: Add full-system-idle arguments to API
   rcu: Update RTFP documentation
   doc: Fix memory-barrier control-dependency example
   rcu: Add duplicate-callback tests to rcutorture
   rcu: Increase rcutorture test coverage
   rcu: Sort rcutorture module parameters
   rcu: Remove unused variable from rcu_torture_writer()
   rcu: Make rcutorture emit online failures if verbose
   rcu: Simplify _rcu_barrier() processing
   jiffies: Avoid undefined behavior from signed overflow
   nohz_full: Add full-system-idle state machine
   nohz_full: Force RCU's grace-period kthreads onto timekeeping CPU
   Merge branches 'doc.2013.08.19a', 'fixes.2013.08.20a', 
 'sysidle.2013.08.31a' and 'torture.2013.08.20a' into HEAD
 
 Tejun Heo (1):
   rculist: list_first_or_null_rcu() should use list_entry_rcu()
 
  Documentation/RCU/RTFP.txt| 858 
 --
  Documentation/RCU/rcubarrier.txt  |  12 +-
  Documentation/RCU/torture.txt |  10 +
  Documentation/memory-barriers.txt |  10 +-
  Documentation/timers/NO_HZ.txt|  44 +-
  include/linux/debugobjects.h  |   6 +-
  include/linux/jiffies.h   |   8 +-
  include/linux/rculist.h   |   5 +-
  include/linux/rcupdate.h  |  22 +-
  init/Kconfig  |   1 +
  kernel/rcu.h  |  10 +-
  kernel/rcupdate.c | 100 -
  kernel/rcutorture.c   | 388 -
  kernel/rcutree.c  | 150 ---
  kernel/rcutree.h  |  17 +
  kernel/rcutree_plugin.h   | 424 ++-
  kernel/time/Kconfig   |  50 +++
  lib/debugobjects.c|  20 +-
  18 files changed, 1418 insertions(+), 717 deletions(-)

Pulled, thanks a lot Paul!

Ingo
--
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 08/13] tracing/kprobes: Move common functions to trace_probe.h

[Namhyung Kim]

From: Namhyung Kim namhyung@lge.com

The __get_data_size() and store_trace_args() will be used by uprobes
too.  Move them to a common location.

Acked-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Srikar Dronamraju sri...@linux.vnet.ibm.com
Cc: Oleg Nesterov o...@redhat.com
Cc: zhangwei(Jovi) jovi.zhang...@huawei.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
 kernel/trace/trace_kprobe.c | 48 -
 kernel/trace/trace_probe.h  | 48 +
 2 files changed, 48 insertions(+), 48 deletions(-)

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 6d33cfee9448..2a668516f0e4 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -909,54 +909,6 @@ const struct fetch_type kprobes_fetch_type_table[] = {
ASSIGN_FETCH_TYPE(s64, u64, 1),
 };
 
-/* Sum up total data length for dynamic arraies (strings) */
-static __kprobes int __get_data_size(struct trace_probe *tp,
-struct pt_regs *regs)
-{
-   int i, ret = 0;
-   u32 len;
-
-   for (i = 0; i  tp-nr_args; i++)
-   if (unlikely(tp-args[i].fetch_size.fn)) {
-   call_fetch(tp-args[i].fetch_size, regs, len);
-   ret += len;
-   }
-
-   return ret;
-}
-
-/* Store the value of each argument */
-static __kprobes void store_trace_args(int ent_size, struct trace_probe *tp,
-  struct pt_regs *regs,
-  u8 *data, int maxlen)
-{
-   int i;
-   u32 end = tp-size;
-   u32 *dl;/* Data (relative) location */
-
-   for (i = 0; i  tp-nr_args; i++) {
-   if (unlikely(tp-args[i].fetch_size.fn)) {
-   /*
-* First, we set the relative location and
-* maximum data length to *dl
-*/
-   dl = (u32 *)(data + tp-args[i].offset);
-   *dl = make_data_rloc(maxlen, end - tp-args[i].offset);
-   /* Then try to fetch string or dynamic array data */
-   call_fetch(tp-args[i].fetch, regs, dl);
-   /* Reduce maximum length */
-   end += get_rloc_len(*dl);
-   maxlen -= get_rloc_len(*dl);
-   /* Trick here, convert data_rloc to data_loc */
-   *dl = convert_rloc_to_loc(*dl,
-ent_size + tp-args[i].offset);
-   } else
-   /* Just fetching data normally */
-   call_fetch(tp-args[i].fetch, regs,
-  data + tp-args[i].offset);
-   }
-}
-
 /* Kprobe handler */
 static __kprobes void
 __kprobe_trace_func(struct trace_kprobe *tp, struct pt_regs *regs,
diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
index 63e5da4e3073..189a40baea98 100644
--- a/kernel/trace/trace_probe.h
+++ b/kernel/trace/trace_probe.h
@@ -302,3 +302,51 @@ extern ssize_t traceprobe_probes_write(struct file *file,
int (*createfn)(int, char**));
 
 extern int traceprobe_command(const char *buf, int (*createfn)(int, char**));
+
+/* Sum up total data length for dynamic arraies (strings) */
+static inline __kprobes int
+__get_data_size(struct trace_probe *tp, struct pt_regs *regs)
+{
+   int i, ret = 0;
+   u32 len;
+
+   for (i = 0; i  tp-nr_args; i++)
+   if (unlikely(tp-args[i].fetch_size.fn)) {
+   call_fetch(tp-args[i].fetch_size, regs, len);
+   ret += len;
+   }
+
+   return ret;
+}
+
+/* Store the value of each argument */
+static inline __kprobes void
+store_trace_args(int ent_size, struct trace_probe *tp, struct pt_regs *regs,
+u8 *data, int maxlen)
+{
+   int i;
+   u32 end = tp-size;
+   u32 *dl;/* Data (relative) location */
+
+   for (i = 0; i  tp-nr_args; i++) {
+   if (unlikely(tp-args[i].fetch_size.fn)) {
+   /*
+* First, we set the relative location and
+* maximum data length to *dl
+*/
+   dl = (u32 *)(data + tp-args[i].offset);
+   *dl = make_data_rloc(maxlen, end - tp-args[i].offset);
+   /* Then try to fetch string or dynamic array data */
+   call_fetch(tp-args[i].fetch, regs, dl);
+   /* Reduce maximum length */
+   end += get_rloc_len(*dl);
+   maxlen -= get_rloc_len(*dl);
+   /* Trick here, convert data_rloc to data_loc */
+   *dl = convert_rloc_to_loc(*dl,
+