Re: 82571EB: Detected Hardware Unit Hang

[Joe Jin]

On 07/15/12 11:42, Dave, Tushar N wrote:
>> -Original Message-
>> From: Joe Jin [mailto:joe@oracle.com]
>> Sent: Thursday, July 12, 2012 9:34 PM
>> To: Dave, Tushar N
>> Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux-
>> ker...@vger.kernel.org
>> Subject: Re: 82571EB: Detected Hardware Unit Hang
>>
>> On 07/13/12 12:10, Dave, Tushar N wrote:
 -Original Message-
 From: Joe Jin [mailto:joe@oracle.com]
 Sent: Thursday, July 12, 2012 4:46 PM
 To: Dave, Tushar N
 Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux-
 ker...@vger.kernel.org
 Subject: Re: 82571EB: Detected Hardware Unit Hang

>>> Thanks for sending full dmesg log. I am still investigating. I think
>> this issue can occur if two PCIe link partner *i.e pcie bridge and pcie
>> device do not have same max payload size.
>>> I need 2 more info.
>>> 1) PBA number of the card.
>>
>> This is a remote server and I could not get this.
>>
>>> 2) full lspci -vvv output of entire system 'after you have changed max
>> payload size to 128'.
> 
> Somehow setting max payload to 256 from BIOS does not set this value for all 
> devices. I believe this is a BIOS bug.
> All devices in path from root complex to 82571, should have same max payload 
> size otherwise it can cause hang. When you set max payload to 128 from BIOS, 
> all device in path from root complex to 82571 got assigned same max payload 
> size. This resolves the issue.
> 
> I hope this helps.

Tushar,

Thanks a lot for your help, will send this to hardware engineer.

Regards,
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: 82571EB: Detected Hardware Unit Hang

[Dave, Tushar N]

>-Original Message-
>From: Joe Jin [mailto:joe@oracle.com]
>Sent: Thursday, July 12, 2012 9:34 PM
>To: Dave, Tushar N
>Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux-
>ker...@vger.kernel.org
>Subject: Re: 82571EB: Detected Hardware Unit Hang
>
>On 07/13/12 12:10, Dave, Tushar N wrote:
>>> -Original Message-
>>> From: Joe Jin [mailto:joe@oracle.com]
>>> Sent: Thursday, July 12, 2012 4:46 PM
>>> To: Dave, Tushar N
>>> Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux-
>>> ker...@vger.kernel.org
>>> Subject: Re: 82571EB: Detected Hardware Unit Hang
>>>
>> Thanks for sending full dmesg log. I am still investigating. I think
>this issue can occur if two PCIe link partner *i.e pcie bridge and pcie
>device do not have same max payload size.
>> I need 2 more info.
>> 1) PBA number of the card.
>
>This is a remote server and I could not get this.
>
>> 2) full lspci -vvv output of entire system 'after you have changed max
>payload size to 128'.

Somehow setting max payload to 256 from BIOS does not set this value for all 
devices. I believe this is a BIOS bug.
All devices in path from root complex to 82571, should have same max payload 
size otherwise it can cause hang. When you set max payload to 128 from BIOS, 
all device in path from root complex to 82571 got assigned same max payload 
size. This resolves the issue.

I hope this helps.

-Tushar
--
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] ext4: fix trivial typo in the comment for extents.c/ext4_split_unwritten_extents

[Wang Sheng-Hui]

Put the sign '/' to the right position.

Signed-off-by: Wang Sheng-Hui 
---
 fs/ext4/extents.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 7f6fb48..f394e0f 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -3241,7 +3241,7 @@ out:
  * to an uninitialized extent.
  *
  * Writing to an uninitialized extent may result in splitting the uninitialized
- * extent into multiple /initialized uninitialized extents (up to three)
+ * extent into multiple initialized/uninitialized extents (up to three)
  * There are three possibilities:
  *   a> There is no split required: Entire extent should be uninitialized
  *   b> Splits in two extents: Write is happening at either end of the extent
-- 
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/

Linux 3.5-rc7

[Linus Torvalds]

Hey guys, remember how things have been stabilizing and slowing down,
and all the kernel developers were off on summer vacation?

Yeah, we need to talk about that. Because I last week I thought that
making an -rc7 was not necessarily realy required, except perhaps
mainly to check the late printk changes. But then today and yesterday,
I got a ton of small pull requests, and now I find myself releasing an
-rc7 that is actually bigger than rc6 was.

Not cool, guys. Not cool.

Now, admittedly, most of this is pretty small. The loadavg calculation
fix patch is pretty big, but quite a lot of that is added comments
(*big* added comments). . But there's Andrew's patch-bomb, there's
media fixes, there's random SOC fixes, powerpc fixes, USB, sound, you
name it.

Ok, so it's still not *huge*, but it's bigger than -rc6 was. I had
hoped for less.

But go forth and test. Make sure it's all good. Because I really wish
I won't have to do an -rc8.

  Linus

---
Alan Cox (1):
  xtensa: fix incorrect memset

Alan Stern (1):
  PCI: EHCI: fix crash during suspend on ASUS computers

Alessandro Rubini (1):
  gpio-sta2x11: don't use pdata if null

Alex Williamson (1):
  KVM: Fix device assignment threaded irq handler

Anton Blanchard (3):
  [media] cx23885: Silence unknown command warnings
  [media] winbond-cir: Fix txandrx module info
  [media] winbond-cir: Initialise timeout, driver_type and allowed_protos

Axel Lin (1):
  mfd: Add terminating entry for i2c_device_id palmas table

Benjamin Herrenschmidt (5):
  powerpc: More fixes for lazy IRQ vs. idle
  powerpc: Fix build of some debug irq code
  powerpc/numa: Avoid stupid uninitialized warning from gcc
  tty/hvc_opal: Fix debug function name
  powerpc/kvm: Fix "PR" KVM implementation of H_CEDE

Benoît Thébaudeau (1):
  drivers/rtc/rtc-mxc.c: fix irq enabled interrupts warning

Bjørn Mork (2):
  USB: option: add ZTE MF60
  USB: cdc-wdm: fix lockup on error in wdm_read

Bob Liu (1):
  fs: ramfs: file-nommu: add SetPageUptodate()

Bob Moore (1):
  ACPICA: Fix possible fault in return package object repair code

Chris Metcalf (1):
  arch/tile: big-endian: properly bswap instruction bundles when backtracing

Christian Dietrich (1):
  gpio/msm_v1: CONFIG_GPIO_MSM_V1 is only available on three SoCs

Corey Minyard (1):
  SH: Convert out[bwl] macros to inline functions

Dan Carpenter (3):
  dma-debug: debugfs_create_bool() takes a u32 pointer
  iommu/amd: fix type bug in flush code
  sgi-xp: nested calls to spin_lock_irqsave()

Dan Williams (1):
  [SCSI] libsas: fix taskfile corruption in sas_ata_qc_fill_rtf

Daniel Mack (1):
  ALSA: snd-usb: move calls to usb_set_interface

Dave Jones (1):
  Remove easily user-triggerable BUG from generic_setlease

David Ahern (3):
  perf script: Fix format regression due to libtraceevent merge
  perf kvm: Fix regression with guest machine creation
  perf kvm: Fix segfault with report and mixed guestmount use

David Dillow (1):
  [media] cx231xx: don't DMA to random addresses

David Howells (1):
  MN10300: Fix a missing semicolon

David Rientjes (1):
  mm, thp: abort compaction if migration page cannot be charged to memcg

Devendra Naga (1):
  drivers/rtc/rtc-spear.c: fix use-after-free in spear_rtc_remove()

Devin Heitmueller (6):
  [media] cx25840: fix regression in HVR-1800 analog support
  [media] cx25840: fix regression in analog support hue/saturation controls
  [media] cx25840: fix regression in HVR-1800 analog audio
  [media] cx25840: fix vsrc/hsrc usage on cx23888 designs
  [media] cx23885: make analog support work for HVR_1250 (cx23885 variant)
  [media] cx23885: add support for HVR-1255 analog (cx23888 variant)

Eddie Wai (1):
  [SCSI] bnx2i: Removed the reference to the netdev->base_addr

Fengguang Wu (1):
  [media] pms: fix build error in pms_probe()

Gaosen Zhang (1):
  USB: option: Add MEDIATEK product ids

Geert Uytterhoeven (11):
  mn10300: move setup_jiffies_interrupt() to cevt-mn10300.c
  mn10300: remove duplicate definition of PTRACE_O_TRACESYSGOOD
  mn10300: kernel/internal.h needs 
  mn10300: kernel/traps.c needs 
  mn10300: mm/dma-alloc.c needs 
  mn10300: use "#elif defined(CONFIG_*)" instead of "#elif CONFIG_*"
  h8300/pgtable: add missing #include 
  h8300/signal: fix typo "statis"
  h8300/time: add missing #include 
  h8300/uaccess: remove assignment to __gu_val in unhandled case
of get_user()
  h8300/uaccess: add mising __clear_user()

Graeme Gregory (2):
  mfd: Fix palmas regulator pdata missing
  mfd: Add missing hunk to change palmas irq to clear on read

Grazvydas Ignotas (1):
  gpio/omap: fix irq loss while in idle with debounce on

Guennadi Liakhovetski (1):
  mmc: cd-gpio: pass IRQF_ONESHOT to request_threaded_irq()

Hans de Goede (1):
  gspca_sn9c20x: Fix NULL pointer 

Re: resurrecting tcphealth

[Piotr Sawuk]

On Sa, 14.07.2012, 23:48, Stephen Hemminger wrote:
> Maybe it would be better to use netlink info (for ss command)
> rather than a /proc/net interface.
> See how existing TCP values and MEMINFO are handled.
>

I'm confused, what exactly do you mean?
of course a library-interface might be more interesting than proc/net.
the proc/net/tcphealth functionality probably could be done in userspace,
although I'm wondering how userspace could traverse all tcp_sock structures
for all clients -- but the gain would be a bit more security. and the rest
of the patch still would need to stay in the kernel since that info it
collects would otherwise be lost completely. so I somehow doubt this would
be worth the effort. better would be optional tcphealth disabled by default
for security-reasons. (i.e. if you're a server you don't want to enable it.)

@"David Miller":
sorry, I forgot an important info about this patch, an info that can be
found in the paper I quoted:

'We concentrate on client side metrics to make our results more applicable
to web clients. We chose this strategy to help answer the often asked
question: "Why is my Internet connection so slow?"
...
Since we only have access to the client node and not the server, we must
find performance data using only the information coming downstream to us.
Savage showed that the TCP protocol maintains data that we can leverage to
our advantage and we use that idea to monitor per-connection TCP health at
the client. This task is made difficult because of the TCP philosophy of
"smart sender, dumb receiver". There is simply more information about the
connection on the server side than on the client.' [1]

tcp_info is such a server-side diagnosis, clients usually don't send enough
data to make the info therein meaningful for checking the "health" of tcp.
it's all about the senders, and the desktop-pc simply isn't that big of a
tcp-sender to slashdot and co.

@"Eric Dumazet":
the same goes for you too. netstat -s and whatever kind of pooling together
statistics on all internet-connections is useful for a server-admin only,
slowness of particular sites can only be investigated with ping and this
tcphealth patch when you're on client-side.

as for userspace-tools, apart from tcp-health display in each
downloading-progress-bar I can think of cron-jobs which wait for better
tcp-health before spidering some site, or an altered wget in mirror-mode.
the gkrellm-plugin that comes with this patch might count together all the
data of tcphealth, but when a tcp_sock isn't stored anymore that data is
forgotten and you get a concurrent info most likely for only one site, since
the client wont have much connections open and will be closing old
connections frequently.

oh, and again I recommend the really short although outdated thesis

[1] https://sacerdoti.org/tcphealth/tcphealth-paper.pdf

--
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 01/15] Drivers: hv: Format GUIDS as per MSFT standards

[Joe Perches]

On Sat, 2012-07-14 at 23:23 +, KY Srinivasan wrote:
> > -Original Message-
> > From: Joe Perches [mailto:j...@perches.com]
> > Sent: Saturday, July 14, 2012 4:25 PM
[]
> > On Sat, 2012-07-14 at 13:34 -0700, K. Y. Srinivasan wrote:
> > > Format GUIDS as per MSFT standard. This makes interacting with MSFT
> > > tool stack easier.
[]
> > > @@ -166,7 +166,7 @@ static ssize_t vmbus_show_device_attr(struct device
> > *dev,
> > >  device_info->chn_type.b[15]);
> > >   } else if (!strcmp(dev_attr->attr.name, "device_id")) {
> > >   ret = sprintf(buf, "{%02x%02x%02x%02x-%02x%02x-%02x%02x-"
> > > -"%02x%02x%02x%02x%02x%02x%02x%02x}\n",
> > > +"%02x%02x-%02x%02x%02x%02x%02x%02x}\n",
> > >  device_info->chn_instance.b[3],
> > >  device_info->chn_instance.b[2],
> > >  device_info->chn_instance.b[1],
> > 
> > ret = sprintf(buf, "{%pUl}\n", device_info->chn_instance.b);
> 
> Thank you Joe. I recall seeing some patches from you a longtime ago on this.
> I was just modifying existing code in this patch; if it is ok with you I will 
> send a
> separate patch using the preferred format string for printing GUIDS.

Hi KY.  It's your code.  Do what you think best.  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: [PATCH 01/15] Drivers: hv: Format GUIDS as per MSFT standards

[KY Srinivasan]

> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Saturday, July 14, 2012 4:25 PM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; virtualizat...@lists.osdl.org; o...@aepfle.de;
> a...@canonical.com
> Subject: Re: [PATCH 01/15] Drivers: hv: Format GUIDS as per MSFT standards
> 
> On Sat, 2012-07-14 at 13:34 -0700, K. Y. Srinivasan wrote:
> > Format GUIDS as per MSFT standard. This makes interacting with MSFT
> > tool stack easier.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > Reviewed-by: Haiyang Zhang 
> > ---
> >  drivers/hv/vmbus_drv.c |4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> > index a220e57..1f7e54a 100644
> > --- a/drivers/hv/vmbus_drv.c
> > +++ b/drivers/hv/vmbus_drv.c
> > @@ -147,7 +147,7 @@ static ssize_t vmbus_show_device_attr(struct device
> *dev,
> >
> > if (!strcmp(dev_attr->attr.name, "class_id")) {
> > ret = sprintf(buf, "{%02x%02x%02x%02x-%02x%02x-%02x%02x-"
> > -  "%02x%02x%02x%02x%02x%02x%02x%02x}\n",
> > +  "%02x%02x-%02x%02x%02x%02x%02x%02x}\n",
> >device_info->chn_type.b[3],
> >device_info->chn_type.b[2],
> >device_info->chn_type.b[1],
> > @@ -166,7 +166,7 @@ static ssize_t vmbus_show_device_attr(struct device
> *dev,
> >device_info->chn_type.b[15]);
> > } else if (!strcmp(dev_attr->attr.name, "device_id")) {
> > ret = sprintf(buf, "{%02x%02x%02x%02x-%02x%02x-%02x%02x-"
> > -  "%02x%02x%02x%02x%02x%02x%02x%02x}\n",
> > +  "%02x%02x-%02x%02x%02x%02x%02x%02x}\n",
> >device_info->chn_instance.b[3],
> >device_info->chn_instance.b[2],
> >device_info->chn_instance.b[1],
> 
>   ret = sprintf(buf, "{%pUl}\n", device_info->chn_instance.b);

Thank you Joe. I recall seeing some patches from you a longtime ago on this.
I was just modifying existing code in this patch; if it is ok with you I will 
send a
separate patch using the preferred format string for printing GUIDS.
 
Regards,

K. Y
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: Small bug: Wrong return check from idr_pre_get in loop.c

[Jesper Juhl]

On Fri, 13 Jul 2012, Silva Paulo wrote:

> idr_pre_get never returns a value < 0. It returns 0 (no memory) or 1 (OK).
> 
Please read Documentation/SubmittingPatches

In summary:
 - you are missing a Signed-off-by: line.
 - there is no diffstat.
 - the patch is an attachment, not inline in the email.
 - the recipients list of the email could be improved (see below).

If you had used scripts/get_maintainer.pl on your patch you'd have gotten 
a better list of recipients for your patch mail:
  $ scripts/get_maintainer.pl My_linux-3.5-rc6_patches
  Jens Axboe  (commit_signer:15/17=88%)
  Andrew Morton  (commit_signer:6/17=35%)
  Kay Sievers  (commit_signer:5/17=29%)
  Jeff Moyer  (commit_signer:2/17=12%)
  Dmitry Monakhov  (commit_signer:2/17=12%)
  linux-kernel@vger.kernel.org (open list)

Please try again.

-- 
Jesper Juhlhttp://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

--
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 12/15] Tools: hv: Gather DHCP information

[KY Srinivasan]

> -Original Message-
> From: richard -rw- weinberger [mailto:richard.weinber...@gmail.com]
> Sent: Saturday, July 14, 2012 5:37 PM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; virtualizat...@lists.osdl.org; o...@aepfle.de;
> a...@canonical.com
> Subject: Re: [PATCH 12/15] Tools: hv: Gather DHCP information
> 
> On Sat, Jul 14, 2012 at 10:34 PM, K. Y. Srinivasan  wrote:
> > Collect information on dhcp setting for the specified interface.
> > We invoke an exyernal script to get this information.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > Reviewed-by: Haiyang Zhang 
> > ---
> >  tools/hv/hv_kvp_daemon.c |   33 +
> >  1 files changed, 33 insertions(+), 0 deletions(-)
> >
> > diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
> > index a81ce67..c510283 100644
> > --- a/tools/hv/hv_kvp_daemon.c
> > +++ b/tools/hv/hv_kvp_daemon.c
> > @@ -524,6 +524,9 @@ static void kvp_get_ipconfig_info(char *if_name,
> >  struct hv_kvp_ipaddr_value *buffer)
> >  {
> > char cmd[512];
> > +   char dhcp_info[128];
> > +   char *p;
> > +   FILE *file;
> >
> > /*
> >  * Get the address of default gateway (ipv4).
> > @@ -580,6 +583,36 @@ static void kvp_get_ipconfig_info(char *if_name,
> >  */
> > kvp_process_ipconfig_file(cmd, (char *)buffer->dns_addr,
> > (MAX_IP_ADDR_SIZE * 2), INET_ADDRSTRLEN, 0);
> > +
> > +   /*
> > +* Gather the DHCP state.
> > +* We will gather this state by invoking an external script.
> > +* The parameter to the script is the interface name.
> > +* Here is the expected output:
> > +*
> > +* Enabled: DHCP enabled.
> > +*/
> > +
> > +   memset(cmd, 0, 512);
> 
> Why not sizeof(cmd)?

I have a bunch of other cleanups lined up for this user level daemon. If it is
ok with you, I could address this as part of that patch set. However, if 
there are more substantive changes needed in this patch-set, I will
also address this. 

Thank you,

K. Y



--
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] two late pinctrl fixes

[Linus Walleij]

Hi Linus,

A last (hopefully) pull request from me, this is two late freescale i.MX
fixes for pinctrl, please pull them in:

The following changes since commit bd0a521e88aa7a06ae7aabaed7ae196ed4ad867a:

  Linux 3.5-rc6 (2012-07-07 17:23:56 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
tags/fixes-for-v3.5-rc6

Dong Aisheng (2):
  pinctrl: pinctrl-imx: only print debug message when DEBUG is defined
  pinctrl: pinctrl-imx6q: add missed mux function for USBOTG_ID

 .../bindings/pinctrl/fsl,imx6q-pinctrl.txt |2 ++
 drivers/pinctrl/pinctrl-imx.c  |2 ++
 drivers/pinctrl/pinctrl-imx6q.c|2 ++
 3 files changed, 6 insertions(+), 0 deletions(-)

Yours,
Linus Walleij
--
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 12/15] Tools: hv: Gather DHCP information

[richard -rw- weinberger]

On Sun, Jul 15, 2012 at 1:02 AM, KY Srinivasan  wrote:
> I have a bunch of other cleanups lined up for this user level daemon. If it is
> ok with you, I could address this as part of that patch set. However, if
> there are more substantive changes needed in this patch-set, I will
> also address this.

No problem.

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

Re: [PATCH 2/3] x86/mm: Simplify for-loop in free_init_pages()

[Joe Perches]

On Sat, 2012-07-14 at 23:48 +0300, Pekka Enberg wrote:
> On Sat, Jul 14, 2012 at 11:43 PM, Joe Perches  wrote:
> > On Sat, 2012-07-14 at 13:36 -0700, Yinghai Lu wrote:
> >> On Sat, Jul 14, 2012 at 6:41 AM, Pekka Enberg  wrote:
> >> > As a cleanup, move initial "addr" assignment to the for-loop construct
> >> > in free_init_pages().
> >
> > Not really a good idea.
> 
> Of course it's a good idea. The current code flow makes no sense.
> 
> >> > diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> > []
> >> > @@ -349,8 +349,6 @@ void free_init_pages(char *what, unsigned long 
> >> > begin, unsigned long end)
> >> > if (begin >= end)
> >> > return;
> >> >
> >> > -   addr = begin;
> >> > -
> >> > /*
> >> >  * If debugging page accesses then do not free this memory but
> >> >  * mark them not present - any buggy init-section access will
> >> > @@ -371,7 +369,7 @@ void free_init_pages(char *what, unsigned long 
> >> > begin, unsigned long end)
> >> >
> >> > printk(KERN_INFO "Freeing %s: %luk freed\n", what, (end - begin) 
> >> > >> 10);
> >> >
> >> > -   for (; addr < end; addr += PAGE_SIZE) {
> >> > +   for (addr = begin; addr < end; addr += PAGE_SIZE) {
> >> > ClearPageReserved(virt_to_page(addr));
> >> > init_page_count(virt_to_page(addr));
> >> > memset((void *)addr, POISON_FREE_INITMEM, PAGE_SIZE);
> >> > --
> >
> > Now there's an unused variable warning when CONFIG_DEBUG_PAGEALLOC
> 
> Sure, that needs fixing. It'd probably be simplest to introduce a
> __free_init_pages() helper.
> 

Perhaps:

 arch/x86/mm/init.c |   14 ++
 1 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index bc4e9d8..1023484 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -330,7 +330,6 @@ int devmem_is_allowed(unsigned long pagenr)
 
 void free_init_pages(char *what, unsigned long begin, unsigned long end)
 {
-   unsigned long addr;
unsigned long begin_aligned, end_aligned;
 
/* Make sure boundaries are page aligned */
@@ -345,8 +344,6 @@ void free_init_pages(char *what, unsigned long begin, 
unsigned long end)
if (begin >= end)
return;
 
-   addr = begin;
-
/*
 * If debugging page accesses then do not free this memory but
 * mark them not present - any buggy init-section access will
@@ -367,12 +364,13 @@ void free_init_pages(char *what, unsigned long begin, 
unsigned long end)
 
printk(KERN_INFO "Freeing %s: %luk freed\n", what, (end - begin) >> 10);
 
-   for (; addr < end; addr += PAGE_SIZE) {
-   ClearPageReserved(virt_to_page(addr));
-   init_page_count(virt_to_page(addr));
-   memset((void *)addr, POISON_FREE_INITMEM, PAGE_SIZE);
-   free_page(addr);
+   while (begin < end) {
+   ClearPageReserved(virt_to_page(begin));
+   init_page_count(virt_to_page(begin));
+   memset((void *)begin, POISON_FREE_INITMEM, PAGE_SIZE);
+   free_page(begin);
totalram_pages++;
+   begin += PAGE_SIZE;
}
 #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/

Re: kmemcheck: Fatal error; system fails to boot when kmemcheck enabled

[Sami Liedes]

On Sat, Jul 14, 2012 at 04:09:02AM +0300, Sami Liedes wrote:
> > Another thing you can try is try to figure out when things went wrong.
> > If you test an old kernel like 3.0 or so -- and find that kmemcheck
> > works, that's great, it means we have a way to narrow it down further.
> > I may also try your config here to see if I can reproduce it.
> 
> I'll probably test 3.0 and could even try to git bisect within a few
> days.

I tested with 3.0.36. It does not boot either.

Also, I tested with both 3.0.36 and 3.4.4 with kmemcheck=2. With that
parameter, both boot fine. Curiously, when booting with kmemcheck=2, I
can see absolutely no messages about kmemcheck, just as with
kmemcheck=0, and the machine boots fine. The crashes happen only with
kmemcheck=1. The speed suggests to me that with kmemcheck=2, kmemcheck
is actually possibly not enabled at all for some reason.

One curious result with 3.0.36: With nosmp, it panics so early that
I'm unable to capture the dmesg (I may experiment with getting some
other video mode than 80x25; not sure if it's possible...). *Without*
nosmp, it boots much further, and I can actually get the dmesg via
netconsole. I tried this a couple of times, with always the same
result.

Dmesg from 3.0.36 without nosmp:

   http://www.niksula.hut.fi/~sliedes/kmemcheck/nc.log.3.0.36

A photo of the (final portion of the) backtrace for 3.0.36 with nosmp:

   http://www.niksula.hut.fi/~sliedes/3.0.36.kmemcheck.nosmp.bt.jpg

Dmesg from 3.4.4 with kmemcheck=2:

   http://www.niksula.hut.fi/~sliedes/kmemcheck/nc.log.3.4.4.kmemcheck-2

Dmesg from 3.0.36 with kmemcheck=2:

   http://www.niksula.hut.fi/~sliedes/kmemcheck/nc.log.3.0.36.kmemcheck-2

Sami


signature.asc
Description: Digital signature

Re: [PATCH 4/5] gpio: tps6586x: add gpio support through platform driver

[Linus Walleij]

On Fri, Jul 13, 2012 at 12:39 PM, Laxman Dewangan  wrote:

> Converting the gpio driver of tps6586x to a platform
> driver in place of registering the gpio through core
> driver.
> The motivation of the change is:
> - This is inline with the mfd drivers implementation.
> - This will move the related gpio support to gpio driver
>   folder where all gpio related drivers are available.
>   This will be easy the maintenance and enhancement is
>   anything done for gpio.
> - The gpio functionality can be selected through config
>   variable.
>
> Signed-off-by: Laxman Dewangan 

Overall this is very, very good and you're doing the right thing.

> --- /dev/null
> +++ b/drivers/gpio/gpio-tps6586x.c

> +#include 

Why?

Reviewed-by: Linus Walleij 

Yours,
Linus Walleij
--
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 00/36] AArch64 Linux kernel port

[Jon Masters]

On 07/10/2012 04:16 PM, Alexander Holler wrote:

> And it isn't so that the name will have to be used that seldom, at least 
> every distribution would need to use it to name the flavour, like e.g. 
> "Fedora AArch64hf" or "Debian AArch64".

The good news is we won't need an "hf" release because we're all going
to just agree on the ABI on day one, and standardize the paths, and all
the distros are going to live happily ever after[0].

Jon.

[0] The first part at least is actually true. There is an ABI that I
reviewed a long time back (you can download it), and we assume the
presence of all kinds of previously optional stuff...like the fp.
--
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 5/5] mfd: tps6586x: remove gpio support from core driver

[Linus Walleij]

On Fri, Jul 13, 2012 at 12:39 PM, Laxman Dewangan  wrote:

> The GPIO functionality of device tps6586x is added through
> platform gpio driver and it can be register as the mfd sub
> device and hence removing the duplicates code which register
> the gpio functionality from core driver.
>
> Signed-off-by: Laxman Dewangan 

The only thing I worry about is if old defconfig files are now
missing this config option and then this patch becomes an
unbisectable showstopper for them because they don't get
this driver by default anymore.

So please make sure you've grepped around and checked
that of some platforms defconfig was previously selecting
the core driver, make sure it selects this driver too for
the moment, it's better if they later deactivate it
if they don't need it.

Yours,
Linus Walleij
--
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: resurrecting tcphealth

[Stephen Hemminger]

Maybe it would be better to use netlink info (for ss command)
rather than a /proc/net interface.
See how existing TCP values and MEMINFO are handled.
--
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 RAID subsystem future

[Zdenek Kaspar]

On 07/12/2012 10:35 PM, NeilBrown wrote:
> On Thu, 12 Jul 2012 13:28:24 -0700 Drew  wrote:
> 
>>> Hello lists,
>>>
>>> I noticed recent patches added MD RAID compatibility into the DM
>>> subsystem. Is there a valid reason to duplicate efforts ?
>>>
>>> Hopefully its not silent preparation step for DM takeover. Can someone
>>> shed more light on this topic ?
>>>
>>> TIA, Z.
>>
>> I'm not a developer by any stretch of the word so take what I say with
>> a grain of salt.
>>
>> I think it's more just a case of dm using md's RAID algorithms, which
>> IMHO are better tested, to support fakeraid controllers like Intel's
>> Matrix RAID. Besides, we're all one big happy linux family so why not
>> borrow your brother's socks? :-)
>>
>>
> Indeed!
> 
> It isn't duplication of effort - it is avoiding or removing duplication of
> effort.  That's the theory any way.
> 
> There is no "DM takeover" - just engineers working together to try to find
> optimal solutions.
> 
> NeilBrown
> 

So this Intel Matrix/Firmware RAID can be used to boot Linux with
/dev/mapper/target - DM-raid. DM-raid is missing some functionality,
most notable raid5 I guess, that was the main reason behind injecting
MD-raid code into DM?

What is clearly a good thing (multiple OS support, easier setup from
firmware and more raid levels to boot from) makes me wonder about MD
future. I'm sure this will attract users to use DM-raid in favor of
MD-raid, if its good or bad, time will tell.

Neil, don't take this in some BAD way please, I'm just not convinced of
dm-every{thing,where} movement. At least not yet..

TIA, Z.

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

Re: [PATCH] Documentation: Describe the AB8500 Device Tree bindings

[Linus Walleij]

On Fri, Jul 13, 2012 at 12:42 PM, Lee Jones  wrote:

> Although for the most part, the AB8500 uses common bindings, some
> of the ways in which they are used differ slightly to the common
> uses of those bindings. To clear up some of these varying concepts
> we provide some documentation describing each of the properties and
> how they are used.
>
> Signed-off-by: Lee Jones 

Cool! Thanks for doing this.
Acked-by: Linus Walleij 

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

Re: [PATCH 7/9] Input: ab8500-ponkey: Create AB8500 domain IRQ mapping

[Linus Walleij]

On Fri, Jul 13, 2012 at 3:43 PM, Lee Jones  wrote:
> On 10/07/12 22:08, Linus Walleij wrote:

>> That's not enough, cat /dev/input/event/* whatever event node is used
>> by the ponkey, press it and verify you get some garbage (=events)
>> in the console.
>
> Yes, garbage seen, works fine.

OK!
Acked-by: on whatever Dmitry Acked.

Yours,
Linus Walleij
--
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 12/15] Tools: hv: Gather DHCP information

[richard -rw- weinberger]

On Sat, Jul 14, 2012 at 10:34 PM, K. Y. Srinivasan  wrote:
> Collect information on dhcp setting for the specified interface.
> We invoke an exyernal script to get this information.
>
> Signed-off-by: K. Y. Srinivasan 
> Reviewed-by: Haiyang Zhang 
> ---
>  tools/hv/hv_kvp_daemon.c |   33 +
>  1 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
> index a81ce67..c510283 100644
> --- a/tools/hv/hv_kvp_daemon.c
> +++ b/tools/hv/hv_kvp_daemon.c
> @@ -524,6 +524,9 @@ static void kvp_get_ipconfig_info(char *if_name,
>  struct hv_kvp_ipaddr_value *buffer)
>  {
> char cmd[512];
> +   char dhcp_info[128];
> +   char *p;
> +   FILE *file;
>
> /*
>  * Get the address of default gateway (ipv4).
> @@ -580,6 +583,36 @@ static void kvp_get_ipconfig_info(char *if_name,
>  */
> kvp_process_ipconfig_file(cmd, (char *)buffer->dns_addr,
> (MAX_IP_ADDR_SIZE * 2), INET_ADDRSTRLEN, 0);
> +
> +   /*
> +* Gather the DHCP state.
> +* We will gather this state by invoking an external script.
> +* The parameter to the script is the interface name.
> +* Here is the expected output:
> +*
> +* Enabled: DHCP enabled.
> +*/
> +
> +   memset(cmd, 0, 512);

Why not sizeof(cmd)?

> +   strcat(cmd, "/sbin/hv_get_dhcp_info ");
> +   strcat(cmd, if_name);

What about strncat()?

-- 
Thanks,
//richard
--
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-next: manual merge of the arm-soc tree with the i2c-embedded tree

[Linus Walleij]

On Thu, Jul 12, 2012 at 3:12 PM, Wolfram Sang  wrote:

> Arnd, since you committed the patches, can you please comment? I'd
> prefer to drop this DT conversion for now, otherwise we might have to
> support this possibly rushed bindings forever? LinusW, what do you
> think?

Well I think I ACKed that from the point of view that it will work as
expected with ux500 with these bindings. What is best from the I2C
subsystem point of view is another question ...

Overall I think we have this general problem with a lot of DT
conversion happening right now: the tempo is set very high and
all chip vendors want DT support RealQuickNowPreferrablyYesterday
and that makes it hard for subsystem maintainers to hold back,
and I also fear vendor-specific properties are overused for this
reason.

And about the perpetual nature of device tree bindings it
appears to me that the modus operandi right now is to not
regard any of these as written in stone until they are removed
from the kernel tree. We have plenty of drivers patching
trees and drivers in one for the moment.

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

Re: [PATCH 2/2] gpio/omap: add *remove* callback in platform_driver

[Linus Walleij]

On Thu, Jul 12, 2012 at 7:48 PM, Kevin Hilman  wrote:

> In the case of OMAP GPIO, unless it's an obvious fix, I would recommend
> you wait at least until you see some acks/tested tags from any of
>
> - Santosh Shilimkar 
> - Rajendra Nayak 
> - Benoit Cousson 
>
> or Tony, Paul or myself.

Instead of trying to store this information in my and Grants brains and
us forgetting it, what about patching MAINTAINERS to reflect the fact
instead? That's better I think, plus I use that file a lot.

> For major series, I have been collecting/queueing them for Grant after
> ensuring they have been well reviewed and well tested (although I am
> eagerly hoping to hand off this role to someone else.)

Listing it under your GIT tree in MAINTAINERS for this driver will make
this work better I think.

One path for OMAP GPIO patches, simple. It's obviously the
ambiguity that cause the trouble. Then you can also decide
on each cycle whether to send these to GPIO or ARM SoC
etc.

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

Re: [PATCH 2/3] x86/mm: Simplify for-loop in free_init_pages()

[Joe Perches]

On Sat, 2012-07-14 at 23:48 +0300, Pekka Enberg wrote:
> On Sat, Jul 14, 2012 at 11:43 PM, Joe Perches  wrote:
> > On Sat, 2012-07-14 at 13:36 -0700, Yinghai Lu wrote:
> >> On Sat, Jul 14, 2012 at 6:41 AM, Pekka Enberg  wrote:
> >> > As a cleanup, move initial "addr" assignment to the for-loop construct
> >> > in free_init_pages().
> >
> > Not really a good idea.
> 
> Of course it's a good idea. The current code flow makes no sense.
> 
> >> > diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> > []
> >> > @@ -349,8 +349,6 @@ void free_init_pages(char *what, unsigned long 
> >> > begin, unsigned long end)
> >> > if (begin >= end)
> >> > return;
> >> >
> >> > -   addr = begin;
> >> > -
> >> > /*
> >> >  * If debugging page accesses then do not free this memory but
> >> >  * mark them not present - any buggy init-section access will
> >> > @@ -371,7 +369,7 @@ void free_init_pages(char *what, unsigned long 
> >> > begin, unsigned long end)
> >> >
> >> > printk(KERN_INFO "Freeing %s: %luk freed\n", what, (end - begin) 
> >> > >> 10);
> >> >
> >> > -   for (; addr < end; addr += PAGE_SIZE) {
> >> > +   for (addr = begin; addr < end; addr += PAGE_SIZE) {
> >> > ClearPageReserved(virt_to_page(addr));
> >> > init_page_count(virt_to_page(addr));
> >> > memset((void *)addr, POISON_FREE_INITMEM, PAGE_SIZE);
> >> > --
> >
> > Now there's an unused variable warning when CONFIG_DEBUG_PAGEALLOC
> 
> Sure, that needs fixing. It'd probably be simplest to introduce a
> __free_init_pages() helper.
> 

The proposed patch introduces a warning.
That's the only reason it's not a good idea.
There are lots of ways to fix it.


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

Re: [PATCH 2/3] x86/mm: Simplify for-loop in free_init_pages()

[Pekka Enberg]

On Sat, Jul 14, 2012 at 11:43 PM, Joe Perches  wrote:
> On Sat, 2012-07-14 at 13:36 -0700, Yinghai Lu wrote:
>> On Sat, Jul 14, 2012 at 6:41 AM, Pekka Enberg  wrote:
>> > As a cleanup, move initial "addr" assignment to the for-loop construct
>> > in free_init_pages().
>
> Not really a good idea.

Of course it's a good idea. The current code flow makes no sense.

>> > diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> []
>> > @@ -349,8 +349,6 @@ void free_init_pages(char *what, unsigned long begin, 
>> > unsigned long end)
>> > if (begin >= end)
>> > return;
>> >
>> > -   addr = begin;
>> > -
>> > /*
>> >  * If debugging page accesses then do not free this memory but
>> >  * mark them not present - any buggy init-section access will
>> > @@ -371,7 +369,7 @@ void free_init_pages(char *what, unsigned long begin, 
>> > unsigned long end)
>> >
>> > printk(KERN_INFO "Freeing %s: %luk freed\n", what, (end - begin) 
>> > >> 10);
>> >
>> > -   for (; addr < end; addr += PAGE_SIZE) {
>> > +   for (addr = begin; addr < end; addr += PAGE_SIZE) {
>> > ClearPageReserved(virt_to_page(addr));
>> > init_page_count(virt_to_page(addr));
>> > memset((void *)addr, POISON_FREE_INITMEM, PAGE_SIZE);
>> > --
>
> Now there's an unused variable warning when CONFIG_DEBUG_PAGEALLOC

Sure, that needs fixing. It'd probably be simplest to introduce a
__free_init_pages() helper.
--
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 3/3] x86/mm: Separate paging setup from memory mapping

[Yinghai Lu]

On Sat, Jul 14, 2012 at 6:41 AM, Pekka Enberg  wrote:
> Move PSE and PGE bit twiddling from init_memory_mapping() to a new
> setup_paging() function to simplify the former function. The
> init_memory_mapping() function is called later in the boot process by
> gart_iommu_init(), efi_ioremap(), and arch_add_memory() which have no
> business whatsover updating the CR4 register.

I have one local patch that will only set that one time too. also do
other page size probe one time.

please check attached one.

Thanks

Yinghai


get_page_size_mask.patch
Description: Binary data

Re: [PATCH 3/4] OMAP: Define TCA6424 max number of possible IRQs

[Linus Walleij]

On Thu, Jul 12, 2012 at 3:00 PM, Mahapatra, Chandrabhanu
 wrote:

> OK, but if your taking this patch through GPIO tree the better if the 4th
> patch is taken through it. TCA6424 fails if both the patches are not
> present.

If the situation is such they should be squashed into one since the
point after the first before the second patch is not bisectable.

Yours,
Linus Walleij
--
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 15/15] Tools: hv: Implement the KVP verb - KVP_OP_GET_IP_INFO

[K. Y. Srinivasan]

Now implement the KVP verb - KVP_OP_GET_IP_INFO. This operation retrieves IP
information for the specified interface.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 tools/hv/hv_kvp_daemon.c |   89 ++
 1 files changed, 89 insertions(+), 0 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 6d224e7..723e78e 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -590,6 +590,69 @@ static char *kvp_if_name_to_mac(char *if_name)
 }
 
 
+/*
+ * Retrieve the interface name given tha MAC address.
+ */
+
+static char *kvp_mac_to_if_name(char *mac)
+{
+   DIR *dir;
+   struct dirent *entry;
+   FILE*file;
+   char*p, *q, *x;
+   char*if_name = NULL;
+   charbuf[256];
+   char *kvp_net_dir = "/sys/class/net/";
+   char dev_id[100];
+   int i;
+
+   dir = opendir(kvp_net_dir);
+   if (dir == NULL)
+   return NULL;
+
+   memset(dev_id, 0, sizeof(dev_id));
+   strcat(dev_id, kvp_net_dir);
+   q = dev_id + strlen(kvp_net_dir);
+
+   while ((entry = readdir(dir)) != NULL) {
+   /*
+* Set the state for the next pass.
+*/
+   *q = '\0';
+
+   strcat(dev_id, entry->d_name);
+   strcat(dev_id, "/address");
+
+   file = fopen(dev_id, "r");
+   if (file == NULL)
+   continue;
+
+   p = fgets(buf, sizeof(buf), file);
+   if (p) {
+   x = strchr(p, '\n');
+   if (x)
+   *x = '\0';
+
+   for (i = 0; i < strlen(p); i++)
+   p[i] = toupper(p[i]);
+
+   if (!strcmp(p, mac)) {
+   /*
+* Found the MAC match; return the interface
+* name. The caller will free the memory.
+*/
+   if_name = strdup(entry->d_name);
+   break;
+   }
+   }
+   fclose(file);
+   }
+
+   closedir(dir);
+   return if_name;
+}
+
+
 static void kvp_process_ipconfig_file(char *cmd,
char *config_buf, int len,
int element_size, int offset)
@@ -1272,6 +1335,32 @@ int main(void)
}
continue;
 
+   case KVP_OP_GET_IP_INFO:
+   kvp_ip_val = &hv_msg->body.kvp_ip_val;
+   if_name =
+   kvp_mac_to_if_name((char *)kvp_ip_val->adapter_id);
+
+   if (if_name == NULL) {
+   /*
+* We could not map the mac address to an
+* interface name; return error.
+*/
+   *((int *)(&hv_msg->kvp_hdr.operation)) =
+   HV_ERROR_DEVICE_NOT_CONNECTED;
+   break;
+   }
+   error = kvp_get_ip_info(
+   0, if_name, KVP_OP_GET_IP_INFO,
+   kvp_ip_val,
+   (MAX_IP_ADDR_SIZE * 2));
+
+   if (error)
+   *((int *)(&hv_msg->kvp_hdr.operation)) =
+   HV_ERROR_DEVICE_NOT_CONNECTED;
+
+   free(if_name);
+   break;
+
case KVP_OP_SET_IP_INFO:
kvp_ip_val = &hv_msg->body.kvp_ip_val;
if_name = kvp_get_if_name(
-- 
1.7.4.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 08/15] Tools: hv: Gather subnet information

[K. Y. Srinivasan]

Now gather sub-net information for the specified interface.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 tools/hv/hv_kvp_daemon.c |   31 +--
 1 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index f687fa5..07f6f7c 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -533,6 +533,7 @@ kvp_get_ip_address(int family, char *if_name, int op,
struct ifaddrs *ifap;
struct ifaddrs *curp;
int offset = 0;
+   int sn_offset = 0;
const char *str;
int error = 0;
char *buffer;
@@ -593,12 +594,38 @@ kvp_get_ip_address(int family, char *if_name, int op,
 * Gather info other than the IP address.
 * IP address info will be gathered later.
 */
-   if (curp->ifa_addr->sa_family == AF_INET)
+   if (curp->ifa_addr->sa_family == AF_INET) {
ip_buffer->addr_family |= ADDR_FAMILY_IPV4;
-   else
+   /*
+* Get subnet info.
+*/
+   error = kvp_process_ip_address(
+   curp->ifa_netmask,
+   AF_INET,
+   (char *)
+   ip_buffer->sub_net,
+   length,
+   &sn_offset);
+   if (error)
+   goto gather_ipaddr;
+   } else {
ip_buffer->addr_family |= ADDR_FAMILY_IPV6;
+   /*
+* Get subnet info.
+*/
+   error = kvp_process_ip_address(
+   curp->ifa_netmask,
+   AF_INET6,
+   (char *)
+   ip_buffer->sub_net,
+   length,
+   &sn_offset);
+   if (error)
+   goto gather_ipaddr;
+   }
}
 
+gather_ipaddr:
error = kvp_process_ip_address(curp->ifa_addr,
curp->ifa_addr->sa_family,
buffer,
-- 
1.7.4.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 09/15] Tools: hv: Represent the ipv6 mask using CIDR notation

[K. Y. Srinivasan]

Transfor ipv6 subnet information to CIDR notation.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 tools/hv/hv_kvp_daemon.c |   45 +++--
 1 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 07f6f7c..b9da130 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -490,6 +490,15 @@ done:
return;
 }
 
+static unsigned int hweight32(unsigned int *w)
+{
+   unsigned int res = *w - ((*w >> 1) & 0x);
+   res = (res & 0x) + ((res >> 2) & 0x);
+   res = (res + (res >> 4)) & 0x0F0F0F0F;
+   res = res + (res >> 8);
+   return (res + (res >> 16)) & 0x00FF;
+}
+
 static int kvp_process_ip_address(void *addrp,
int family, char *buffer,
int length,  int *offset)
@@ -534,10 +543,15 @@ kvp_get_ip_address(int family, char *if_name, int op,
struct ifaddrs *curp;
int offset = 0;
int sn_offset = 0;
-   const char *str;
int error = 0;
char *buffer;
struct hv_kvp_ipaddr_value *ip_buffer;
+   char cidr_mask[5]; /* /xyz */
+   int weight;
+   int i;
+   unsigned int *w;
+   char *sn_str;
+   struct sockaddr_in6 *addr6;
 
if (op == KVP_OP_ENUMERATE) {
buffer = out_buffer;
@@ -611,17 +625,28 @@ kvp_get_ip_address(int family, char *if_name, int op,
} else {
ip_buffer->addr_family |= ADDR_FAMILY_IPV6;
/*
-* Get subnet info.
+* Get subnet info in CIDR format.
 */
-   error = kvp_process_ip_address(
-   curp->ifa_netmask,
-   AF_INET6,
-   (char *)
-   ip_buffer->sub_net,
-   length,
-   &sn_offset);
-   if (error)
+   weight = 0;
+   sn_str = (char *)ip_buffer->sub_net;
+   addr6 = (struct sockaddr_in6 *)
+   curp->ifa_netmask;
+   w = addr6->sin6_addr.s6_addr32;
+
+   for (i = 0; i < 4; i++)
+   weight += hweight32(&w[i]);
+
+   sprintf(cidr_mask, "/%d", weight);
+   if ((length - sn_offset) <
+   (strlen(cidr_mask) + 1))
goto gather_ipaddr;
+
+   if (sn_offset == 0)
+   strcpy(sn_str, cidr_mask);
+   else
+   strcat(sn_str, cidr_mask);
+   strcat((char *)ip_buffer->sub_net, ";");
+   sn_offset += strlen(sn_str) + 1;
}
}
 
-- 
1.7.4.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 14/15] Tools: hv: Rename the function kvp_get_ip_address()

[K. Y. Srinivasan]

Rename the function kvp_get_ip_address().

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 tools/hv/hv_kvp_daemon.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index c33fc8e..6d224e7 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -762,7 +762,7 @@ static int kvp_process_ip_address(void *addrp,
 }
 
 static int
-kvp_get_ip_address(int family, char *if_name, int op,
+kvp_get_ip_info(int family, char *if_name, int op,
 void  *out_buffer, int length)
 {
struct ifaddrs *ifap;
@@ -1360,12 +1360,12 @@ int main(void)
strcpy(key_value, lic_version);
break;
case NetworkAddressIPv4:
-   kvp_get_ip_address(AF_INET, NULL, KVP_OP_ENUMERATE,
+   kvp_get_ip_info(AF_INET, NULL, KVP_OP_ENUMERATE,
key_value, HV_KVP_EXCHANGE_MAX_VALUE_SIZE);
strcpy(key_name, "NetworkAddressIPv4");
break;
case NetworkAddressIPv6:
-   kvp_get_ip_address(AF_INET6, NULL, KVP_OP_ENUMERATE,
+   kvp_get_ip_info(AF_INET6, NULL, KVP_OP_ENUMERATE,
key_value, HV_KVP_EXCHANGE_MAX_VALUE_SIZE);
strcpy(key_name, "NetworkAddressIPv6");
break;
-- 
1.7.4.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 12/15] Tools: hv: Gather DHCP information

[K. Y. Srinivasan]

Collect information on dhcp setting for the specified interface.
We invoke an exyernal script to get this information.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 tools/hv/hv_kvp_daemon.c |   33 +
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index a81ce67..c510283 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -524,6 +524,9 @@ static void kvp_get_ipconfig_info(char *if_name,
 struct hv_kvp_ipaddr_value *buffer)
 {
char cmd[512];
+   char dhcp_info[128];
+   char *p;
+   FILE *file;
 
/*
 * Get the address of default gateway (ipv4).
@@ -580,6 +583,36 @@ static void kvp_get_ipconfig_info(char *if_name,
 */
kvp_process_ipconfig_file(cmd, (char *)buffer->dns_addr,
(MAX_IP_ADDR_SIZE * 2), INET_ADDRSTRLEN, 0);
+
+   /*
+* Gather the DHCP state.
+* We will gather this state by invoking an external script.
+* The parameter to the script is the interface name.
+* Here is the expected output:
+*
+* Enabled: DHCP enabled.
+*/
+
+   memset(cmd, 0, 512);
+   strcat(cmd, "/sbin/hv_get_dhcp_info ");
+   strcat(cmd, if_name);
+
+   file = popen(cmd, "r");
+   if (file == NULL)
+   return;
+
+   p = fgets(dhcp_info, sizeof(dhcp_info), file);
+   if (p == NULL) {
+   pclose(file);
+   return;
+   }
+
+   if (!strncmp(p, "Enabled", 7))
+   buffer->dhcp_enabled = 1;
+   else
+   buffer->dhcp_enabled = 0;
+
+   pclose(file);
 }
 
 
-- 
1.7.4.1

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

Re: [PATCH 2/3] x86/mm: Simplify for-loop in free_init_pages()

[Joe Perches]

On Sat, 2012-07-14 at 13:36 -0700, Yinghai Lu wrote:
> On Sat, Jul 14, 2012 at 6:41 AM, Pekka Enberg  wrote:
> > As a cleanup, move initial "addr" assignment to the for-loop construct
> > in free_init_pages().

Not really a good idea.

> > diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
[]
> > @@ -349,8 +349,6 @@ void free_init_pages(char *what, unsigned long begin, 
> > unsigned long end)
> > if (begin >= end)
> > return;
> >
> > -   addr = begin;
> > -
> > /*
> >  * If debugging page accesses then do not free this memory but
> >  * mark them not present - any buggy init-section access will
> > @@ -371,7 +369,7 @@ void free_init_pages(char *what, unsigned long begin, 
> > unsigned long end)
> >
> > printk(KERN_INFO "Freeing %s: %luk freed\n", what, (end - begin) >> 
> > 10);
> >
> > -   for (; addr < end; addr += PAGE_SIZE) {
> > +   for (addr = begin; addr < end; addr += PAGE_SIZE) {
> > ClearPageReserved(virt_to_page(addr));
> > init_page_count(virt_to_page(addr));
> > memset((void *)addr, POISON_FREE_INITMEM, PAGE_SIZE);
> > --

Now there's an unused variable warning when CONFIG_DEBUG_PAGEALLOC

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

Re: [PATCH 2/3] x86/mm: Simplify for-loop in free_init_pages()

[Yinghai Lu]

On Sat, Jul 14, 2012 at 6:41 AM, Pekka Enberg  wrote:
> As a cleanup, move initial "addr" assignment to the for-loop construct
> in free_init_pages().
>
> Cc: Tejun Heo 
> Cc: Yinghai Lu 
> Signed-off-by: Pekka Enberg 

Acked-by: Yinghai Lu 

> ---
>  arch/x86/mm/init.c |4 +---
>  1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index 9eb53c2..e270f94 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -349,8 +349,6 @@ void free_init_pages(char *what, unsigned long begin, 
> unsigned long end)
> if (begin >= end)
> return;
>
> -   addr = begin;
> -
> /*
>  * If debugging page accesses then do not free this memory but
>  * mark them not present - any buggy init-section access will
> @@ -371,7 +369,7 @@ void free_init_pages(char *what, unsigned long begin, 
> unsigned long end)
>
> printk(KERN_INFO "Freeing %s: %luk freed\n", what, (end - begin) >> 
> 10);
>
> -   for (; addr < end; addr += PAGE_SIZE) {
> +   for (addr = begin; addr < end; addr += PAGE_SIZE) {
> ClearPageReserved(virt_to_page(addr));
> init_page_count(virt_to_page(addr));
> memset((void *)addr, POISON_FREE_INITMEM, PAGE_SIZE);
> --
> 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: [PATCH 1/3] x86/mm: Simplify memory mapping PFN calculation

[Yinghai Lu]

On Sat, Jul 14, 2012 at 6:41 AM, Pekka Enberg  wrote:
> Introduce two new helper functions, addr_to_pmd_pfn() and
> addr_to_pud_pfn(), to simplify init_memory_mapping() code flow.
>
> Cc: Tejun Heo 
> Cc: Yinghai Lu 
> Signed-off-by: Pekka Enberg 

Acked-by: Yinghai Lu 

> ---
>  arch/x86/mm/init.c |   38 +-
>  1 files changed, 21 insertions(+), 17 deletions(-)
>
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index bc4e9d8..9eb53c2 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -117,6 +117,16 @@ static int __meminit save_mr(struct map_range *mr, int 
> nr_range,
> return nr_range;
>  }
>
> +static unsigned long addr_to_pmd_pfn(unsigned long addr)
> +{
> +   return (addr >> PMD_SHIFT) << (PMD_SHIFT - PAGE_SHIFT);
> +}
> +
> +static unsigned long addr_to_pud_pfn(unsigned long addr)
> +{
> +   return (addr >> PUD_SHIFT) << (PUD_SHIFT - PAGE_SHIFT);
> +}
> +
>  /*
>   * Setup the direct mapping of the physical memory at PAGE_OFFSET.
>   * This runs before bootmem is initialized and gets pages directly from
> @@ -180,11 +190,9 @@ unsigned long __init_refok init_memory_mapping(unsigned 
> long start,
> if (pos == 0)
> end_pfn = 1<<(PMD_SHIFT - PAGE_SHIFT);
> else
> -   end_pfn = ((pos + (PMD_SIZE - 1))>>PMD_SHIFT)
> -<< (PMD_SHIFT - PAGE_SHIFT);
> +   end_pfn = addr_to_pmd_pfn(pos + (PMD_SIZE - 1));
>  #else /* CONFIG_X86_64 */
> -   end_pfn = ((pos + (PMD_SIZE - 1)) >> PMD_SHIFT)
> -   << (PMD_SHIFT - PAGE_SHIFT);
> +   end_pfn = addr_to_pmd_pfn(pos + (PMD_SIZE - 1));
>  #endif
> if (end_pfn > (end >> PAGE_SHIFT))
> end_pfn = end >> PAGE_SHIFT;
> @@ -194,15 +202,13 @@ unsigned long __init_refok init_memory_mapping(unsigned 
> long start,
> }
>
> /* big page (2M) range */
> -   start_pfn = ((pos + (PMD_SIZE - 1))>>PMD_SHIFT)
> -<< (PMD_SHIFT - PAGE_SHIFT);
> +   start_pfn = addr_to_pmd_pfn(pos + (PMD_SIZE - 1));
>  #ifdef CONFIG_X86_32
> -   end_pfn = (end>>PMD_SHIFT) << (PMD_SHIFT - PAGE_SHIFT);
> +   end_pfn = addr_to_pmd_pfn(end);
>  #else /* CONFIG_X86_64 */
> -   end_pfn = ((pos + (PUD_SIZE - 1))>>PUD_SHIFT)
> -<< (PUD_SHIFT - PAGE_SHIFT);
> -   if (end_pfn > ((end>>PMD_SHIFT)<<(PMD_SHIFT - PAGE_SHIFT)))
> -   end_pfn = ((end>>PMD_SHIFT)<<(PMD_SHIFT - PAGE_SHIFT));
> +   end_pfn = addr_to_pud_pfn(pos + (PUD_SIZE - 1));
> +   if (end_pfn > addr_to_pmd_pfn(end))
> +   end_pfn = addr_to_pmd_pfn(end);
>  #endif
>
> if (start_pfn < end_pfn) {
> @@ -213,9 +219,8 @@ unsigned long __init_refok init_memory_mapping(unsigned 
> long start,
>
>  #ifdef CONFIG_X86_64
> /* big page (1G) range */
> -   start_pfn = ((pos + (PUD_SIZE - 1))>>PUD_SHIFT)
> -<< (PUD_SHIFT - PAGE_SHIFT);
> -   end_pfn = (end >> PUD_SHIFT) << (PUD_SHIFT - PAGE_SHIFT);
> +   start_pfn = addr_to_pud_pfn(pos + (PUD_SIZE - 1));
> +   end_pfn = addr_to_pud_pfn(end);
> if (start_pfn < end_pfn) {
> nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
> page_size_mask &
> @@ -224,9 +229,8 @@ unsigned long __init_refok init_memory_mapping(unsigned 
> long start,
> }
>
> /* tail is not big page (1G) alignment */
> -   start_pfn = ((pos + (PMD_SIZE - 1))>>PMD_SHIFT)
> -<< (PMD_SHIFT - PAGE_SHIFT);
> -   end_pfn = (end >> PMD_SHIFT) << (PMD_SHIFT - PAGE_SHIFT);
> +   start_pfn = addr_to_pmd_pfn(pos + (PMD_SIZE - 1));
> +   end_pfn = addr_to_pmd_pfn(end);
> if (start_pfn < end_pfn) {
> nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
> page_size_mask & (1< --
> 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: [PATCH 01/15] Drivers: hv: Format GUIDS as per MSFT standards

[Joe Perches]

On Sat, 2012-07-14 at 13:34 -0700, K. Y. Srinivasan wrote:
> Format GUIDS as per MSFT standard. This makes interacting with MSFT
> tool stack easier.
> 
> Signed-off-by: K. Y. Srinivasan 
> Reviewed-by: Haiyang Zhang 
> ---
>  drivers/hv/vmbus_drv.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index a220e57..1f7e54a 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -147,7 +147,7 @@ static ssize_t vmbus_show_device_attr(struct device *dev,
>  
>   if (!strcmp(dev_attr->attr.name, "class_id")) {
>   ret = sprintf(buf, "{%02x%02x%02x%02x-%02x%02x-%02x%02x-"
> -"%02x%02x%02x%02x%02x%02x%02x%02x}\n",
> +"%02x%02x-%02x%02x%02x%02x%02x%02x}\n",
>  device_info->chn_type.b[3],
>  device_info->chn_type.b[2],
>  device_info->chn_type.b[1],
> @@ -166,7 +166,7 @@ static ssize_t vmbus_show_device_attr(struct device *dev,
>  device_info->chn_type.b[15]);
>   } else if (!strcmp(dev_attr->attr.name, "device_id")) {
>   ret = sprintf(buf, "{%02x%02x%02x%02x-%02x%02x-%02x%02x-"
> -"%02x%02x%02x%02x%02x%02x%02x%02x}\n",
> +"%02x%02x-%02x%02x%02x%02x%02x%02x}\n",
>  device_info->chn_instance.b[3],
>  device_info->chn_instance.b[2],
>  device_info->chn_instance.b[1],

ret = sprintf(buf, "{%pUl}\n", device_info->chn_instance.b);


--
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 06/15] Tools: hv: Further refactor kvp_get_ip_address()

[K. Y. Srinivasan]

In preparation for making kvp_get_ip_address() more generic, factor out
the code for handling IP addresses.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 tools/hv/hv_kvp_daemon.c |   94 -
 1 files changed, 42 insertions(+), 52 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 3128e77..218f28d 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -490,17 +490,50 @@ done:
return;
 }
 
+static int kvp_process_ip_address(void *addrp,
+   int family, char *buffer,
+   int length,  int *offset)
+{
+   struct sockaddr_in *addr;
+   struct sockaddr_in6 *addr6;
+   int addr_length;
+   char tmp[50];
+   const char *str;
+
+   if (family == AF_INET) {
+   addr = (struct sockaddr_in *)addrp;
+   str = inet_ntop(family, &addr->sin_addr, tmp, 50);
+   addr_length = INET_ADDRSTRLEN;
+   } else {
+   addr6 = (struct sockaddr_in6 *)addrp;
+   str = inet_ntop(family, &addr6->sin6_addr.s6_addr, tmp, 50);
+   addr_length = INET6_ADDRSTRLEN;
+   }
+
+   if ((length - *offset) < addr_length + 1)
+   return 1;
+   if (str == NULL) {
+   strcpy(buffer, "inet_ntop failed\n");
+   return 1;
+   }
+   if (*offset == 0)
+   strcpy(buffer, tmp);
+   else
+   strcat(buffer, tmp);
+   strcat(buffer, ";");
+
+   *offset += strlen(str) + 1;
+   return 0;
+}
+
 static int
 kvp_get_ip_address(int family, char *if_name, int op,
 void  *out_buffer, int length)
 {
struct ifaddrs *ifap;
struct ifaddrs *curp;
-   int ipv4_len = strlen("255.255.255.255") + 1;
-   int ipv6_len = strlen(":::::::")+1;
int offset = 0;
const char *str;
-   char tmp[50];
int error = 0;
char *buffer;
struct hv_kvp_ipaddr_value *ip_buffer;
@@ -555,55 +588,12 @@ kvp_get_ip_address(int family, char *if_name, int op,
continue;
}
 
-   if ((curp->ifa_addr->sa_family == AF_INET) &&
-   ((family == AF_INET) || (family == 0))) {
-   struct sockaddr_in *addr =
-   (struct sockaddr_in *) curp->ifa_addr;
-
-   str = inet_ntop(AF_INET, &addr->sin_addr, tmp, 50);
-   if (str == NULL) {
-   strcpy(buffer, "inet_ntop failed\n");
-   error = 1;
-   goto getaddr_done;
-   }
-   if (offset == 0)
-   strcpy(buffer, tmp);
-   else
-   strcat(buffer, tmp);
-   strcat(buffer, ";");
-
-   offset += strlen(str) + 1;
-   if ((length - offset) < (ipv4_len + 1))
-   goto getaddr_done;
-
-   } else if ((family == AF_INET6) || (family == 0)) {
-
-   /*
-* We only support AF_INET and AF_INET6
-* and the list of addresses is separated by a ";".
-*/
-   struct sockaddr_in6 *addr =
-   (struct sockaddr_in6 *) curp->ifa_addr;
-
-   str = inet_ntop(AF_INET6,
-   &addr->sin6_addr.s6_addr,
-   tmp, 50);
-   if (str == NULL) {
-   strcpy(buffer, "inet_ntop failed\n");
-   error = 1;
-   goto getaddr_done;
-   }
-   if (offset == 0)
-   strcpy(buffer, tmp);
-   else
-   strcat(buffer, tmp);
-   strcat(buffer, ";");
-   offset += strlen(str) + 1;
-   if ((length - offset) < (ipv6_len + 1))
-   goto getaddr_done;
-
-   }
-
+   error = kvp_process_ip_address(curp->ifa_addr,
+   curp->ifa_addr->sa_family,
+   buffer,
+   length, &offset);
+   if (error)
+   goto getaddr_done;
 
curp = curp->ifa_next;
}
-- 
1.7.4.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.

[PATCH 03/15] Drivers: hv: kvp: Cleanup error handling in KVP

[K. Y. Srinivasan]

In preparation to implementing IP injection, cleanup the way we propagate
and handle errors both in the driver as well as in the user level daemon.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 drivers/hv/hv_kvp.c  |   43 +
 include/linux/hyperv.h   |   17 
 tools/hv/hv_kvp_daemon.c |   59 +++--
 3 files changed, 63 insertions(+), 56 deletions(-)

diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index 0012eed..6e6f0c2 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -50,7 +50,6 @@ static struct {
 
 static void kvp_send_key(struct work_struct *dummy);
 
-#define TIMEOUT_FIRED 1
 
 static void kvp_respond_to_host(char *key, char *value, int error);
 static void kvp_work_func(struct work_struct *dummy);
@@ -97,7 +96,7 @@ kvp_work_func(struct work_struct *dummy)
 * If the timer fires, the user-mode component has not responded;
 * process the pending transaction.
 */
-   kvp_respond_to_host("Unknown key", "Guest timed out", TIMEOUT_FIRED);
+   kvp_respond_to_host("Unknown key", "Guest timed out", HV_E_FAIL);
 }
 
 /*
@@ -109,27 +108,31 @@ kvp_cn_callback(struct cn_msg *msg, struct 
netlink_skb_parms *nsp)
 {
struct hv_kvp_msg *message;
struct hv_kvp_msg_enumerate *data;
+   int error;
 
message = (struct hv_kvp_msg *)msg->data;
-   switch (message->kvp_hdr.operation) {
-   case KVP_OP_REGISTER:
+
+   if (message->kvp_hdr.operation == KVP_OP_REGISTER) {
pr_info("KVP: user-mode registering done.\n");
kvp_register();
kvp_transaction.active = false;
-   hv_kvp_onchannelcallback(kvp_transaction.kvp_context);
-   break;
-
-   default:
-   data = &message->body.kvp_enum_data;
-   /*
-* Complete the transaction by forwarding the key value
-* to the host. But first, cancel the timeout.
-*/
-   if (cancel_delayed_work_sync(&kvp_work))
-   kvp_respond_to_host(data->data.key,
-data->data.value,
-   !strlen(data->data.key));
+   if (kvp_transaction.kvp_context)
+   hv_kvp_onchannelcallback(kvp_transaction.kvp_context);
+   return;
}
+
+   /*
+* We use the message header information from
+* the user level daemon to transmit errors.
+*/
+   error = *((int *)(&message->kvp_hdr.operation));
+   data = &message->body.kvp_enum_data;
+   /*
+* Complete the transaction by forwarding the key value
+* to the host. But first, cancel the timeout.
+*/
+   if (cancel_delayed_work_sync(&kvp_work))
+   kvp_respond_to_host(data->data.key, data->data.value, error);
 }
 
 static void
@@ -287,6 +290,7 @@ kvp_respond_to_host(char *key, char *value, int error)
 */
return;
 
+   icmsghdrp->status = error;
 
/*
 * If the error parameter is set, terminate the host's enumeration
@@ -294,15 +298,12 @@ kvp_respond_to_host(char *key, char *value, int error)
 */
if (error) {
/*
-* Something failed or the we have timedout;
+* Something failed or  we have timedout;
 * terminate the current  host-side iteration.
 */
-   icmsghdrp->status = HV_S_CONT;
goto response_done;
}
 
-   icmsghdrp->status = HV_S_OK;
-
kvp_msg = (struct hv_kvp_msg *)
&recv_buffer[sizeof(struct vmbuspipe_hdr) +
sizeof(struct icmsg_hdr)];
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 38b561a..dfa9bb2 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -142,6 +142,17 @@ enum hv_kvp_exchg_pool {
KVP_POOL_COUNT /* Number of pools, must be last. */
 };
 
+/*
+ * Some Hyper-V status codes.
+ */
+
+#define HV_S_OK0x
+#define HV_E_FAIL  0x80004005
+#define HV_S_CONT  0x80070103
+#define HV_ERROR_NOT_SUPPORTED 0x80070032
+#define HV_ERROR_MACHINE_LOCKED0x800704F7
+#define HV_ERROR_DEVICE_NOT_CONNECTED  0x8007048F
+
 #define ADDR_FAMILY_NONE   0x00
 #define ADDR_FAMILY_IPV4   0x01
 #define ADDR_FAMILY_IPV6   0x02
@@ -1006,12 +1017,6 @@ void vmbus_driver_unregister(struct hv_driver 
*hv_driver);
 #define ICMSGHDRFLAG_REQUEST   2
 #define ICMSGHDRFLAG_RESPONSE  4
 
-#define HV_S_OK0x
-#define HV_E_FAIL  0x80004005
-#define HV_S_CONT  0x80070103
-#define HV_ERROR_NOT_SUPPORTED 0x80070032
-#define HV_ERROR_MACHINE_LOC

[PATCH 04/15] Drivers: hv: kvp: Support the new IP injection messages

[K. Y. Srinivasan]

Implement support for the new IP injection messages in the driver code.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 drivers/hv/hv_kvp.c |  141 ---
 1 files changed, 133 insertions(+), 8 deletions(-)

diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index 6e6f0c2..15c641c 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -51,7 +51,7 @@ static struct {
 static void kvp_send_key(struct work_struct *dummy);
 
 
-static void kvp_respond_to_host(char *key, char *value, int error);
+static void kvp_respond_to_host(struct hv_kvp_msg *msg, int error);
 static void kvp_work_func(struct work_struct *dummy);
 static void kvp_register(void);
 
@@ -96,7 +96,7 @@ kvp_work_func(struct work_struct *dummy)
 * If the timer fires, the user-mode component has not responded;
 * process the pending transaction.
 */
-   kvp_respond_to_host("Unknown key", "Guest timed out", HV_E_FAIL);
+   kvp_respond_to_host(NULL, HV_E_FAIL);
 }
 
 /*
@@ -107,7 +107,6 @@ static void
 kvp_cn_callback(struct cn_msg *msg, struct netlink_skb_parms *nsp)
 {
struct hv_kvp_msg *message;
-   struct hv_kvp_msg_enumerate *data;
int error;
 
message = (struct hv_kvp_msg *)msg->data;
@@ -126,13 +125,119 @@ kvp_cn_callback(struct cn_msg *msg, struct 
netlink_skb_parms *nsp)
 * the user level daemon to transmit errors.
 */
error = *((int *)(&message->kvp_hdr.operation));
-   data = &message->body.kvp_enum_data;
/*
 * Complete the transaction by forwarding the key value
 * to the host. But first, cancel the timeout.
 */
if (cancel_delayed_work_sync(&kvp_work))
-   kvp_respond_to_host(data->data.key, data->data.value, error);
+   kvp_respond_to_host(message, error);
+}
+
+static int process_ob_ipinfo(void *in_msg, void *out_msg, int op)
+{
+   struct hv_kvp_msg *in = in_msg;
+   struct hv_kvp_ip_msg *out = out_msg;
+   int len;
+
+   switch (op) {
+   case KVP_OP_GET_IP_INFO:
+   /*
+* Transform all parameters into utf16 encoding.
+*/
+   len = utf8s_to_utf16s((char *)in->body.kvp_ip_val.ip_addr,
+   strlen((char *)in->body.kvp_ip_val.ip_addr),
+   UTF16_HOST_ENDIAN,
+   (wchar_t *)out->kvp_ip_val.ip_addr,
+   MAX_IP_ADDR_SIZE);
+   if (len < 0)
+   return len;
+
+   len = utf8s_to_utf16s((char *)in->body.kvp_ip_val.sub_net,
+   strlen((char *)in->body.kvp_ip_val.sub_net),
+   UTF16_HOST_ENDIAN,
+   (wchar_t *)out->kvp_ip_val.sub_net,
+   MAX_IP_ADDR_SIZE);
+   if (len < 0)
+   return len;
+
+   len = utf8s_to_utf16s((char *)in->body.kvp_ip_val.gate_way,
+   strlen((char *)in->body.kvp_ip_val.gate_way),
+   UTF16_HOST_ENDIAN,
+   (wchar_t *)out->kvp_ip_val.gate_way,
+   MAX_GATEWAY_SIZE);
+   if (len < 0)
+   return len;
+
+   len = utf8s_to_utf16s((char *)in->body.kvp_ip_val.dns_addr,
+   strlen((char *)in->body.kvp_ip_val.dns_addr),
+   UTF16_HOST_ENDIAN,
+   (wchar_t *)out->kvp_ip_val.dns_addr,
+   MAX_IP_ADDR_SIZE);
+   if (len < 0)
+   return len;
+
+   len = utf8s_to_utf16s((char *)in->body.kvp_ip_val.adapter_id,
+   strlen((char *)in->body.kvp_ip_val.adapter_id),
+   UTF16_HOST_ENDIAN,
+   (wchar_t *)out->kvp_ip_val.adapter_id,
+   MAX_IP_ADDR_SIZE);
+   if (len < 0)
+   return len;
+
+   out->kvp_ip_val.dhcp_enabled =
+   in->body.kvp_ip_val.dhcp_enabled;
+   }
+
+   return 0;
+}
+
+static void process_ib_ipinfo(void *in_msg, void *out_msg, int op)
+{
+   struct hv_kvp_ip_msg *in = in_msg;
+   struct hv_kvp_msg *out = out_msg;
+
+   switch (op) {
+   case KVP_OP_SET_IP_INFO:
+   /*
+* Transform all parameters into utf8 encoding.
+*/
+   utf16s_to_utf8s((wchar_t *)in->kvp_ip_val.ip_addr,
+   MAX_IP_ADDR_SIZE,
+   UTF16_LITTLE_ENDIAN,
+   (__u8 *)out->body.kvp_ip_val.ip_addr,
+   MAX_IP_ADDR_SIZE);
+
+   utf16s_to_utf8s((wchar_t *)in->kvp_ip_val.sub_net,
+ 

[PATCH 13/15] Tools: hv: Implement the KVP verb - KVP_OP_SET_IP_INFO

[K. Y. Srinivasan]

Implement the KVP verb - KVP_OP_SET_IP_INFO. This operation configures the 
specified interface based on the given configuration. Since configuring
an interface is very distro specific, we invoke an external script to
configure the interface.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 tools/hv/hv_kvp_daemon.c |  324 ++
 1 files changed, 324 insertions(+), 0 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index c510283..c33fc8e 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * KVP protocol: The user mode component first registers with the
@@ -490,6 +491,105 @@ done:
return;
 }
 
+
+/*
+ * Retrieve an interface name corresponding to the specified guid.
+ * If there is a match, the function returns a pointer
+ * to the interface name and if not, a NULL is returned.
+ * If a match is found, the caller is responsible for
+ * freeing the memory.
+ */
+
+static char *kvp_get_if_name(char *guid)
+{
+   DIR *dir;
+   struct dirent *entry;
+   FILE*file;
+   char*p, *q, *x;
+   char*if_name = NULL;
+   charbuf[256];
+   char *kvp_net_dir = "/sys/class/net/";
+   char dev_id[100];
+
+   dir = opendir(kvp_net_dir);
+   if (dir == NULL)
+   return NULL;
+
+   memset(dev_id, 0, sizeof(dev_id));
+   strcat(dev_id, kvp_net_dir);
+   q = dev_id + strlen(kvp_net_dir);
+
+   while ((entry = readdir(dir)) != NULL) {
+   /*
+* Set the state for the next pass.
+*/
+   *q = '\0';
+   strcat(dev_id, entry->d_name);
+   strcat(dev_id, "/device/device_id");
+
+   file = fopen(dev_id, "r");
+   if (file == NULL)
+   continue;
+
+   p = fgets(buf, sizeof(buf), file);
+   if (p) {
+   x = strchr(p, '\n');
+   if (x)
+   *x = '\0';
+
+   if (!strcmp(p, guid)) {
+   /*
+* Found the guid match; return the interface
+* name. The caller will free the memory.
+*/
+   if_name = strdup(entry->d_name);
+   break;
+   }
+   }
+   fclose(file);
+   }
+
+   closedir(dir);
+   return if_name;
+}
+
+/*
+ * Retrieve the MAC address given the interface name.
+ */
+
+static char *kvp_if_name_to_mac(char *if_name)
+{
+   FILE*file;
+   char*p, *x;
+   charbuf[256];
+   char addr_file[100];
+   int i;
+   char *mac_addr = NULL;
+
+   memset(addr_file, 0, sizeof(addr_file));
+   strcat(addr_file, "/sys/class/net/");
+   strcat(addr_file, if_name);
+   strcat(addr_file, "/address");
+
+   file = fopen(addr_file, "r");
+   if (file == NULL)
+   return NULL;
+
+   p = fgets(buf, sizeof(buf), file);
+   if (p) {
+   x = strchr(p, '\n');
+   if (x)
+   *x = '\0';
+   for (i = 0; i < strlen(p); i++)
+   p[i] = toupper(p[i]);
+   mac_addr = strdup(p);
+   }
+
+   fclose(file);
+   return mac_addr;
+}
+
+
 static void kvp_process_ipconfig_file(char *cmd,
char *config_buf, int len,
int element_size, int offset)
@@ -799,6 +899,207 @@ getaddr_done:
 }
 
 
+int parse_ip_val_buffer(char *in_buf, int *offset, char *out_buf, int out_len)
+{
+   char *x;
+   char *start;
+
+   /*
+* in_buf has sequence of characters that are seperated by
+* the character ';'. The last sequence is terminated by ';'.
+*/
+   start = in_buf + *offset;
+
+   x = strchr(start, ';');
+   if (x) {
+   *x = 0;
+   if ((x - start) <= out_len) {
+   strcpy(out_buf, start);
+   strcat(out_buf, "\n");
+   *offset = (x - start) + 1;
+   return 1;
+   }
+   }
+   return 0;
+}
+
+
+static int kvp_set_ip_info(char *if_name, struct hv_kvp_ipaddr_value *new_val)
+{
+   int error = 0;
+   char if_file[50];
+   FILE *file;
+   char addr[INET6_ADDRSTRLEN];
+   int i;
+   char str[256];
+   char sub_str[10];
+   int offset;
+   char cmd[512];
+   char *mac_addr;
+
+   /*
+* Set the configuration for the specified interface with
+* the information provided. Since there is no standard
+* way to configure an interface, we will have an external
+* script that does the job of

[PATCH 11/15] Tools: hv: Gather DNS information

[K. Y. Srinivasan]

Now gather DNS information. This information cannot be gathered in
a distro independent fashion. Invoke an external script (that can be
distro dependent) to gather the DNS information.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 tools/hv/hv_kvp_daemon.c |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index b7a2df0..a81ce67 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -553,6 +553,33 @@ static void kvp_get_ipconfig_info(char *if_name,
kvp_process_ipconfig_file(cmd, (char *)buffer->gate_way,
(MAX_GATEWAY_SIZE * 2), INET6_ADDRSTRLEN, 1);
 
+
+   /*
+* Gather the DNS  state.
+* Since there is no standard way to get this information
+* across various distributions of interest; we just invoke
+* an external script that needs to be ported across distros
+* of interest.
+* Input to the script:
+* 1) Interface name
+*
+* Following is the expected format of the information from the script:
+*
+* ipaddr1 (nameserver1)
+* ipaddr2 (nameserver2)
+* .
+* .
+*/
+
+   memset(cmd, 0, 512);
+   strcat(cmd, "/sbin/hv_get_dns_info ");
+   strcat(cmd, if_name);
+
+   /*
+* Execute the command to gather DNS info.
+*/
+   kvp_process_ipconfig_file(cmd, (char *)buffer->dns_addr,
+   (MAX_IP_ADDR_SIZE * 2), INET_ADDRSTRLEN, 0);
 }
 
 
-- 
1.7.4.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 10/15] Tools: hv: Gather ipv[4,6] gateway information

[K. Y. Srinivasan]

Gather information on the default gateways - ipv4/ipv6.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 tools/hv/hv_kvp_daemon.c |   72 ++
 1 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index b9da130..b7a2df0 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -490,6 +490,72 @@ done:
return;
 }
 
+static void kvp_process_ipconfig_file(char *cmd,
+   char *config_buf, int len,
+   int element_size, int offset)
+{
+   char buf[256];
+   char *p;
+   char *x;
+   FILE *file;
+
+   /*
+* First execute the command.
+*/
+   file = popen(cmd, "r");
+   if (file == NULL)
+   return;
+
+   if (offset == 0)
+   memset(config_buf, 0, len);
+   while ((p = fgets(buf, sizeof(buf), file)) != NULL) {
+   if ((len - strlen(config_buf)) < (element_size + 1))
+   break;
+
+   x = strchr(p, '\n');
+   *x = '\0';
+   strcat(config_buf, p);
+   strcat(config_buf, ";");
+   }
+   pclose(file);
+}
+
+static void kvp_get_ipconfig_info(char *if_name,
+struct hv_kvp_ipaddr_value *buffer)
+{
+   char cmd[512];
+
+   /*
+* Get the address of default gateway (ipv4).
+*/
+   memset(cmd, 0, 512);
+   strcat(cmd, "/sbin/ip -f inet  route | grep -w ");
+   strcat(cmd, if_name);
+   strcat(cmd, " | awk '/default/ {print $3 }'");
+
+   /*
+* Execute the command to gather gateway info.
+*/
+   kvp_process_ipconfig_file(cmd, (char *)buffer->gate_way,
+   (MAX_GATEWAY_SIZE * 2), INET_ADDRSTRLEN, 0);
+
+   /*
+* Get the address of default gateway (ipv6).
+*/
+   memset(cmd, 0, 512);
+   strcat(cmd, "/sbin/ip -f inet6  route | grep -w ");
+   strcat(cmd, if_name);
+   strcat(cmd, " | awk '/default/ {print $3 }'");
+
+   /*
+* Execute the command to gather gateway info (ipv6).
+*/
+   kvp_process_ipconfig_file(cmd, (char *)buffer->gate_way,
+   (MAX_GATEWAY_SIZE * 2), INET6_ADDRSTRLEN, 1);
+
+}
+
+
 static unsigned int hweight32(unsigned int *w)
 {
unsigned int res = *w - ((*w >> 1) & 0x);
@@ -648,6 +714,12 @@ kvp_get_ip_address(int family, char *if_name, int op,
strcat((char *)ip_buffer->sub_net, ";");
sn_offset += strlen(sn_str) + 1;
}
+
+   /*
+* Collect other ip related configuration info.
+*/
+
+   kvp_get_ipconfig_info(if_name, ip_buffer);
}
 
 gather_ipaddr:
-- 
1.7.4.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 02/15] Drivers: hv: Add KVP definitions for IP address injection

[K. Y. Srinivasan]

Add the necessary definitions for supporting the IP injection functionality.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 drivers/hv/hv_util.c |4 ++--
 include/linux/hyperv.h   |   30 ++
 tools/hv/hv_kvp_daemon.c |2 +-
 3 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index d3ac6a4..a0667de 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -263,7 +263,7 @@ static int util_probe(struct hv_device *dev,
(struct hv_util_service *)dev_id->driver_data;
int ret;
 
-   srv->recv_buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
+   srv->recv_buffer = kmalloc(PAGE_SIZE * 2, GFP_KERNEL);
if (!srv->recv_buffer)
return -ENOMEM;
if (srv->util_init) {
@@ -274,7 +274,7 @@ static int util_probe(struct hv_device *dev,
}
}
 
-   ret = vmbus_open(dev->channel, 2 * PAGE_SIZE, 2 * PAGE_SIZE, NULL, 0,
+   ret = vmbus_open(dev->channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL, 0,
srv->util_cb, dev->channel);
if (ret)
goto error;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 68ed7f7..38b561a 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -127,6 +127,8 @@ enum hv_kvp_exchg_op {
KVP_OP_SET,
KVP_OP_DELETE,
KVP_OP_ENUMERATE,
+   KVP_OP_GET_IP_INFO,
+   KVP_OP_SET_IP_INFO,
KVP_OP_REGISTER,
KVP_OP_COUNT /* Number of operations, must be last. */
 };
@@ -140,6 +142,26 @@ enum hv_kvp_exchg_pool {
KVP_POOL_COUNT /* Number of pools, must be last. */
 };
 
+#define ADDR_FAMILY_NONE   0x00
+#define ADDR_FAMILY_IPV4   0x01
+#define ADDR_FAMILY_IPV6   0x02
+
+#define MAX_ADAPTER_ID_SIZE128
+#define MAX_IP_ADDR_SIZE   1024
+#define MAX_GATEWAY_SIZE   512
+
+
+struct hv_kvp_ipaddr_value {
+   __u16   adapter_id[MAX_ADAPTER_ID_SIZE];
+   __u8addr_family;
+   __u8dhcp_enabled;
+   __u16   ip_addr[MAX_IP_ADDR_SIZE];
+   __u16   sub_net[MAX_IP_ADDR_SIZE];
+   __u16   gate_way[MAX_GATEWAY_SIZE];
+   __u16   dns_addr[MAX_IP_ADDR_SIZE];
+} __attribute__((packed));
+
+
 struct hv_kvp_hdr {
__u8 operation;
__u8 pool;
@@ -187,10 +209,17 @@ struct hv_kvp_msg {
struct hv_kvp_msg_set   kvp_set;
struct hv_kvp_msg_deletekvp_delete;
struct hv_kvp_msg_enumerate kvp_enum_data;
+   struct hv_kvp_ipaddr_value  kvp_ip_val;
struct hv_kvp_register  kvp_register;
} body;
 } __attribute__((packed));
 
+struct hv_kvp_ip_msg {
+   __u8 operation;
+   __u8 pool;
+   struct hv_kvp_ipaddr_value  kvp_ip_val;
+} __attribute__((packed));
+
 #ifdef __KERNEL__
 #include 
 #include 
@@ -982,6 +1011,7 @@ void vmbus_driver_unregister(struct hv_driver *hv_driver);
 #define HV_S_CONT  0x80070103
 #define HV_ERROR_NOT_SUPPORTED 0x80070032
 #define HV_ERROR_MACHINE_LOCKED0x800704F7
+#define HV_ERROR_DEVICE_NOT_CONNECTED  0x8007048F
 
 /*
  * While we want to handle util services as regular devices,
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index d9834b3..8fbcf7b 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -69,7 +69,7 @@ enum key_index {
 };
 
 static char kvp_send_buffer[4096];
-static char kvp_recv_buffer[4096];
+static char kvp_recv_buffer[4096 * 2];
 static struct sockaddr_nl addr;
 
 static char *os_name = "";
-- 
1.7.4.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 05/15] Tools: hv: Prepare to expand kvp_get_ip_address() functionality

[K. Y. Srinivasan]

kvp_get_ip_address() implemented the functionality to retrieve IP address info.
Make this function more generic so that we could retrieve additional
per-interface information.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 tools/hv/hv_kvp_daemon.c |  129 ++
 1 files changed, 84 insertions(+), 45 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index ffe444b..3128e77 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -491,7 +491,8 @@ done:
 }
 
 static int
-kvp_get_ip_address(int family, char *buffer, int length)
+kvp_get_ip_address(int family, char *if_name, int op,
+void  *out_buffer, int length)
 {
struct ifaddrs *ifap;
struct ifaddrs *curp;
@@ -501,10 +502,19 @@ kvp_get_ip_address(int family, char *buffer, int length)
const char *str;
char tmp[50];
int error = 0;
-
+   char *buffer;
+   struct hv_kvp_ipaddr_value *ip_buffer;
+
+   if (op == KVP_OP_ENUMERATE) {
+   buffer = out_buffer;
+   } else {
+   ip_buffer = out_buffer;
+   buffer = (char *)ip_buffer->ip_addr;
+   ip_buffer->addr_family = 0;
+   }
/*
 * On entry into this function, the buffer is capable of holding the
-* maximum key value (2048 bytes).
+* maximum key value.
 */
 
if (getifaddrs(&ifap)) {
@@ -514,58 +524,87 @@ kvp_get_ip_address(int family, char *buffer, int length)
 
curp = ifap;
while (curp != NULL) {
-   if ((curp->ifa_addr != NULL) &&
-  (curp->ifa_addr->sa_family == family)) {
-   if (family == AF_INET) {
-   struct sockaddr_in *addr =
-   (struct sockaddr_in *) curp->ifa_addr;
-
-   str = inet_ntop(family, &addr->sin_addr,
-   tmp, 50);
-   if (str == NULL) {
-   strcpy(buffer, "inet_ntop failed\n");
-   error = 1;
-   goto getaddr_done;
-   }
-   if (offset == 0)
-   strcpy(buffer, tmp);
-   else
-   strcat(buffer, tmp);
-   strcat(buffer, ";");
+   if (curp->ifa_addr == NULL) {
+   curp = curp->ifa_next;
+   continue;
+   }
 
-   offset += strlen(str) + 1;
-   if ((length - offset) < (ipv4_len + 1))
-   goto getaddr_done;
+   if ((if_name != NULL) &&
+   (strncmp(curp->ifa_name, if_name, strlen(if_name {
+   /*
+* We want info about a specific interface;
+* just continue.
+*/
+   curp = curp->ifa_next;
+   continue;
+   }
 
-   } else {
+   /*
+* We only support two address families: AF_INET and AF_INET6.
+* If a family value of 0 is specified, we collect both
+* supported address families; if not we gather info on
+* the specified address family.
+*/
+   if ((family != 0) && (curp->ifa_addr->sa_family != family)) {
+   curp = curp->ifa_next;
+   continue;
+   }
+   if ((curp->ifa_addr->sa_family != AF_INET) &&
+   (curp->ifa_addr->sa_family != AF_INET6)) {
+   curp = curp->ifa_next;
+   continue;
+   }
+
+   if ((curp->ifa_addr->sa_family == AF_INET) &&
+   ((family == AF_INET) || (family == 0))) {
+   struct sockaddr_in *addr =
+   (struct sockaddr_in *) curp->ifa_addr;
+
+   str = inet_ntop(AF_INET, &addr->sin_addr, tmp, 50);
+   if (str == NULL) {
+   strcpy(buffer, "inet_ntop failed\n");
+   error = 1;
+   goto getaddr_done;
+   }
+   if (offset == 0)
+   strcpy(buffer, tmp);
+   else
+   strcat(buffer, tmp);
+   strcat(buffer, ";");
+
+   offset += strlen(str) + 1;
+   if ((length - offset) < (ipv4_len + 1))
+   goto getaddr_done;
+
+   } else if 

[PATCH 07/15] Tools: hv: Gather address family information

[K. Y. Srinivasan]

Now, gather address family information for the specified interface.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 tools/hv/hv_kvp_daemon.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 218f28d..f687fa5 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -588,6 +588,17 @@ kvp_get_ip_address(int family, char *if_name, int op,
continue;
}
 
+   if (op == KVP_OP_GET_IP_INFO) {
+   /*
+* Gather info other than the IP address.
+* IP address info will be gathered later.
+*/
+   if (curp->ifa_addr->sa_family == AF_INET)
+   ip_buffer->addr_family |= ADDR_FAMILY_IPV4;
+   else
+   ip_buffer->addr_family |= ADDR_FAMILY_IPV6;
+   }
+
error = kvp_process_ip_address(curp->ifa_addr,
curp->ifa_addr->sa_family,
buffer,
-- 
1.7.4.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 01/15] Drivers: hv: Format GUIDS as per MSFT standards

[K. Y. Srinivasan]

Format GUIDS as per MSFT standard. This makes interacting with MSFT
tool stack easier.

Signed-off-by: K. Y. Srinivasan 
Reviewed-by: Haiyang Zhang 
---
 drivers/hv/vmbus_drv.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index a220e57..1f7e54a 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -147,7 +147,7 @@ static ssize_t vmbus_show_device_attr(struct device *dev,
 
if (!strcmp(dev_attr->attr.name, "class_id")) {
ret = sprintf(buf, "{%02x%02x%02x%02x-%02x%02x-%02x%02x-"
-  "%02x%02x%02x%02x%02x%02x%02x%02x}\n",
+  "%02x%02x-%02x%02x%02x%02x%02x%02x}\n",
   device_info->chn_type.b[3],
   device_info->chn_type.b[2],
   device_info->chn_type.b[1],
@@ -166,7 +166,7 @@ static ssize_t vmbus_show_device_attr(struct device *dev,
   device_info->chn_type.b[15]);
} else if (!strcmp(dev_attr->attr.name, "device_id")) {
ret = sprintf(buf, "{%02x%02x%02x%02x-%02x%02x-%02x%02x-"
-  "%02x%02x%02x%02x%02x%02x%02x%02x}\n",
+  "%02x%02x-%02x%02x%02x%02x%02x%02x}\n",
   device_info->chn_instance.b[3],
   device_info->chn_instance.b[2],
   device_info->chn_instance.b[1],
-- 
1.7.4.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 00/15] drivers: hv: kvp

[K. Y. Srinivasan]

This patchset expands the KVP (Key Value Pair) functionality to
implement the mechanism to GET/SET IP addresses in the guest. This
functionality is used in Windows Server 2012 to implement VM
replication functionality. The way IP configuration information
is managed is distro specific. Based on the feedback I have gotten
from Olaf, Greg, Steve, Ben and Mairus, I have chosen to seperate
distro specific code from this patch-set. Most of the GET operation
can be implemented in a way that is completely distro independent and
I have implemented that as such and is included in this patch-set.
Some of the attributes that can only be fetched in a distro
dependent way as well the mechanism for configuring an interface
(the SET operation) that is cledarly distro specific is to be
implemented via external scripts that will be invoked via the KVP
code. We define here the interface to these scripts.

K. Y. Srinivasan (15):
  Drivers: hv: Format GUIDS as per MSFT standards
  Drivers: hv: Add KVP definitions for IP address injection
  Drivers: hv: kvp: Cleanup error handling in KVP
  Drivers: hv: kvp: Support the new IP injection messages
  Tools: hv: Prepare to expand  kvp_get_ip_address() functionality
  Tools: hv: Further refactor kvp_get_ip_address()
  Tools: hv: Gather address family information
  Tools: hv: Gather subnet information
  Tools: hv: Represent the ipv6 mask using CIDR notation
  Tools: hv: Gather ipv[4,6] gateway information
  Tools: hv: Gather DNS information
  Tools: hv: Gather DHCP information
  Tools: hv: Implement the KVP verb - KVP_OP_SET_IP_INFO
  Tools: hv: Rename the function kvp_get_ip_address()
  Tools: hv: Implement the KVP verb - KVP_OP_GET_IP_INFO

 drivers/hv/hv_kvp.c  |  172 +--
 drivers/hv/hv_util.c |4 +-
 drivers/hv/vmbus_drv.c   |4 +-
 include/linux/hyperv.h   |   45 +++-
 tools/hv/hv_kvp_daemon.c |  804 +-
 5 files changed, 914 insertions(+), 115 deletions(-)

-- 
1.7.4.1

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

Re: [PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver

[Linus Walleij]

On Tue, Jul 10, 2012 at 11:11 AM, Tony Lindgren  wrote:

> OK so no comments for a while. Here's the patch updated to leave out
> the comments in the binding example.

I reason like this:

- My fears is that the code gets hopeless to understand the mux, the
 only way to understand that aspect of the system will be to read the DTS
 and have the data sheet ready at hand.

But:

- Tony knows what he's doing and what is best for OMAP. And this gets
 (hopefully) all that OMAP mux code out of arch/arm.

- Surely it will be better to go through this subsystem if we're refactoring
  it all again later, and all drivers can be transferred to the abstract
  pinctrl API which is a big win in itself, bringing coherency to the
  drivers/* at large.

So applied it, so it can be evaluated in real operating environments.

But if I don't see OMAP transferred to use this I'll simply delete it
again. :-)

Yours,
Linus Walleij
--
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] gpio: of_get_named_gpio_flags() return -EPROBE_DEFER if GPIO not yet available

[Linus Walleij]

On Thu, Jun 28, 2012 at 12:32 AM, Roland Stigge  wrote:

> of_get_named_gpio_flags() and of_get_named_gpio() return -EPROBE_DEFER if the
> respective GPIO is not (yet) available. This is useful if driver's probe()
> functions try to get a GPIO whose controller isn't probed yet. Thus, the 
> driver
> can be probed again later on.
>
> The function still returns -EINVAL on other errors (parse error or node 
> doesn't
> exist). This way, the case of an optional/intentionally missing GPIO is 
> handled
> appropriately.
>
> Signed-off-by: Roland Stigge 
> Acked-by: Linus Walleij 

If I understand correctly this relates closely to another patch from Mark Brown
we discussed the other day (sorry for missing this patch, which arrived
earlier, for a while).

Mark/Grant can you look at this patch?

Yours,
Linus Walleij
--
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: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues

[david]

On Sat, 14 Jul 2012, Cyrill Gorcunov wrote:


On Sat, Jul 14, 2012 at 07:48:27PM +0200, Borislav Petkov wrote:

On Sat, Jul 14, 2012 at 04:43:32PM +0400, Cyrill Gorcunov wrote:

For example to enable "PCI driver for virtio devices" I need to go to
Device Drivers -> Virtio drivers, while I think it would be great to
have everything virt. related in Virtualization section.


Actually, we need something more generic than that: everything X-related
should be automatically selected when setting CONFIG_X. And X can be any
subset of configuration options which belong to one feature, be it KVM,
distro-specific stuff, or CPU-vendor specific stuff, or whatever.

I can imagine, for example, that when a user wants to have an
AMD-specific config, it automatically selects CPU_SUP_AMD, X86_MCE_AMD
(for MCE), MICROCODE_AMD (microcode support), AGP_AMD64, EDAC_AMD64 and
a bunch of other AMD-specific features.


sure, no doubts, it would be great! (I must admit I never looked up into
kconfig parser code so i don't know if this could be achieved easily).


think of this as a variation of the miniconfig problem.

Instead of the miniconfig being one file that specifies everything you 
want, that you then use to generate a real .config file, you instead have 
one _or_ _more_ config files that get combined and then used to generate 
the real .config file.


Doing this as a set of miniconfig snippets instead of as menu options in 
the main kconfig has the advantage that once the real .config is created, 
it can then be edited freely, without worrying about things like SELINUX 
being enabled when you want to do development on a different LSM.


The distro config would be the first of these, but then you could have 
multiple hardware specific config files (a vmware config, a KVM config, 
one or more config files for the systems that you own, a USB config to 
enable a bunch of the various USB deices that you want to support, etc)


The distros may choose to produce several miniconfig files, one the 
minimum infrastructure features they need, and then additional files for 
the rest of their config. For example, I could see them having a set of 
files


1. Core
2. architecture
3. architecture specific drivers
4. architecture neutral drivers (USB devices and similar)


starting off with the distro config, the people creating this are going to 
be very familiar with kconfig and could create these by hand, but going 
forward we are going to want to have some tools to help sysadmins to 
create these files. Not knowing kconfig, it may be as simple as taking the 
miniconfig snippets that you start with, creating a .config and then doing 
a diff of that .config with the one the admin created, using the result as 
the new miniconfig snippet.


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

[GIT PULL] ACPI patch for Linux-3.5-rc6 - take 2

[Len Brown]

Hi Linus,

Please pull these ACPI & Power Management patches.

this pull message is identical to take 1 except adds "release" branch.
I can't explain why it was missing, as it is hard-coded into the script
that make this message.  Perhaps a mouse error when I edited the e-mail...

thanks!

Len Brown, Intel Open Source Technology Center

The following changes since commit fdb1335a82ef1ef9442ac9377796e4e7a69d1ae4:

  Merge tag 'md-3.5-fixes' of git://neil.brown.name/md (2012-07-13 17:59:33 
-0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git release

for you to fetch changes up to 46befd6b38d802dfc5998e7d7938854578b45d9d:

  ACPICA: Fix possible fault in return package object repair code (2012-07-14 
11:38:41 -0400)


Bob Moore (1):
  ACPICA: Fix possible fault in return package object repair code

 drivers/acpi/acpica/nspredef.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--
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: [GIT PULL] ACPI patch for Linux-3.5-rc6

[Rafael J. Wysocki]

On Saturday, July 14, 2012, Linus Torvalds wrote:
> On Sat, Jul 14, 2012 at 10:46 AM, Len Brown  wrote:
> >
> > Please pull this ACPI patch.
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git
> 
> There's nothing there. Did you mean some particular tag or branch?
> There seems to be branches named "release" and "next" there.

The commit in question is on the 'release' branch and is on top of
fdb1335a82ef1ef9442ac9377796e4e7a69d1ae4 as described in the request.

The commit hash matches as well, so it must be this one.

Rafael
--
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: resurrecting tcphealth

[David Miller]

Don't we report all of this shit in tcp_info already?

I really hate such cruddy patches like this.
--
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/1] mmc: block: Add write packing control

[Chris Ball]

Hi,

On Wed, Jun 13 2012, Muthu Kumar wrote:
> On Wed, Jun 13, 2012 at 12:52 PM,   wrote:
>>
>> On Mon, June 11, 2012 5:28 pm, Muthu Kumar wrote:
>>> On Mon, Jun 11, 2012 at 2:19 PM, Muthu Kumar  wrote:
 On Fri, Jun 1, 2012 at 11:55 AM, Maya Erez  wrote:
> trigger
> the packing can be configured via sysfs by writing the required value
> to:
> /sys/block//num_wr_reqs_to_start_packing.
> The trigger for disabling the write packing is fetching a read request.
>

 If it is applicable only to MMC why do we have this sysfs attr for all
 block devices?
>>>
>>> Just to be clear, please create a directory, say mmc, under
>>> /sys/block// and create the attr inside that.
>>>
>>> You can refer to dm (dm-sysfs.c) for sample implementation.
>> I understand why you think it would be best to distinguish the MMC
>> specific attribute from the general block devices attributes.
>> However, since this attribute is created only for the MMC block device,
>> other block devices won't be aware of it.
>
> I understand its created by the MMC code so will not be there for
> other block devices. But having the device specific attributes inside
> one  directory is better/cleaner. And since we are already
> following that model for other devices, why not follow that for MMC
> also?

I've already replied to a later version of the patch, but just to get
this comment in at the appropriate point of the discussion as well:

Even though it would result in a cleaner sysfs, I don't want to do
this now because it will break userspace scripts that are depending
on the current locations of these attributes.

Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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 v4 1/2] mmc: card: Move MMC specific attributes to mmc sub-directory

[Chris Ball]

Hi,

On Sat, Jul 14 2012, Maya Erez wrote:
> Separate MMC specific attributes from general block device
> attributes and move them from the /sys/block/ directory
> to /sys/block//mmc directory

I don't think we can do this, even though the change is a good one.
What happens if someone has userspace scripts that manipulate force_ro,
or ro_lock_until_next_power_on?

sysfs isn't a firmly stable kernel ABI, but I think it's much closer
to one than this patch implies.

Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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: [GIT PULL] ACPI patch for Linux-3.5-rc6

[Linus Torvalds]

On Sat, Jul 14, 2012 at 10:46 AM, Len Brown  wrote:
>
> Please pull this ACPI patch.
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git

There's nothing there. Did you mean some particular tag or branch?
There seems to be branches named "release" and "next" there.

  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: [PATCH RESEND v4 2/2] mmc: block: Add write packing control

[merez]

Hi all,

Do you have additional comments on this patch?
I rebased it to the latest linux-next since the write packed command patch
was merged in.

Thanks,
Maya

On Sat, July 14, 2012 11:46 am, Maya Erez wrote:
> The write packing control will ensure that read requests latency is
> not increased due to long write packed commands.
>
> The trigger for enabling the write packing is managing to pack several
> write requests. The number of potential packed requests that will trigger
> the packing can be configured via sysfs by writing the required value to:
> /sys/block//num_wr_reqs_to_start_packing.
> The trigger for disabling the write packing is fetching a read request.
>
> Signed-off-by: Maya Erez 
> ---
>  Documentation/mmc/mmc-dev-attrs.txt |   17 ++
>  drivers/mmc/card/block.c|  105
> ++-
>  drivers/mmc/card/queue.c|8 +++
>  drivers/mmc/card/queue.h|3 +
>  include/linux/mmc/host.h|1 +
>  5 files changed, 133 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/mmc/mmc-dev-attrs.txt
> b/Documentation/mmc/mmc-dev-attrs.txt
> index 22ae844..f4a48a8 100644
> --- a/Documentation/mmc/mmc-dev-attrs.txt
> +++ b/Documentation/mmc/mmc-dev-attrs.txt
> @@ -8,6 +8,23 @@ The following attributes are read/write.
>
>   force_roEnforce read-only access even if write protect 
> switch is off.
>
> + num_wr_reqs_to_start_packingThis attribute is used to determine
> + the trigger for activating the write packing, in case the write
> + packing control feature is enabled.
> +
> + When the MMC manages to reach a point where num_wr_reqs_to_start_packing
> + write requests could be packed, it enables the write packing feature.
> + This allows us to start the write packing only when it is beneficial
> + and has minimum affect on the read latency.
> +
> + The number of potential packed requests that will trigger the packing
> + can be configured via sysfs by writing the required value to:
> + /sys/block//mmc/num_wr_reqs_to_start_packing.
> +
> + The default value of num_wr_reqs_to_start_packing was determined by
> + running parallel lmdd write and lmdd read operations and calculating
> + the max number of packed writes requests.
> +
>  SD and MMC Device Attributes
>  
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 2b8ad9e..6d63ce0 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -114,6 +114,7 @@ struct mmc_blk_data {
>   struct device_attribute force_ro;
>   struct device_attribute power_ro_lock;
>   int area_type;
> + struct device_attribute num_wr_reqs_to_start_packing;
>
>   struct kobject kobj;
>   struct kobj_type kobj_type;
> @@ -329,6 +330,38 @@ out:
>   return ret;
>  }
>
> +static ssize_t
> +num_wr_reqs_to_start_packing_show(struct device *dev,
> +   struct device_attribute *attr, char *buf)
> +{
> + struct mmc_blk_data *md = mmc_blk_get(dev_to_disk(dev));
> + int num_wr_reqs_to_start_packing;
> + int ret;
> +
> + num_wr_reqs_to_start_packing = md->queue.num_wr_reqs_to_start_packing;
> +
> + ret = snprintf(buf, PAGE_SIZE, "%d\n", num_wr_reqs_to_start_packing);
> +
> + mmc_blk_put(md);
> + return ret;
> +}
> +
> +static ssize_t
> +num_wr_reqs_to_start_packing_store(struct device *dev,
> +  struct device_attribute *attr,
> +  const char *buf, size_t count)
> +{
> + int value;
> + struct mmc_blk_data *md = mmc_blk_get(dev_to_disk(dev));
> +
> + sscanf(buf, "%d", &value);
> + if (value >= 0)
> + md->queue.num_wr_reqs_to_start_packing = value;
> +
> + mmc_blk_put(md);
> + return count;
> +}
> +
>  static int mmc_blk_open(struct block_device *bdev, fmode_t mode)
>  {
>   struct mmc_blk_data *md = mmc_blk_get(bdev->bd_disk);
> @@ -1344,6 +1377,49 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req
> *mqrq,
>   mmc_queue_bounce_pre(mqrq);
>  }
>
> +static void mmc_blk_write_packing_control(struct mmc_queue *mq,
> +   struct request *req)
> +{
> + struct mmc_host *host = mq->card->host;
> + int data_dir;
> +
> + if (!(host->caps2 & MMC_CAP2_PACKED_WR))
> + return;
> +
> + /*
> +  * In case the packing control is not supported by the host, it should
> +  * not have an effect on the write packing. Therefore we have to enable
> +  * the write packing
> +  */
> + if (!(host->caps2 & MMC_CAP2_PACKED_WR_CONTROL)) {
> + mq->wr_packing_enabled = true;
> + return;
> + }
> +
> + if (!req || (req && (req->cmd_flags & REQ_FLUSH))) {
> + if (mq->num_of_potential_packed_wr_reqs >
> + mq->num_wr_reqs_to_start_packing)
> + mq-

Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues

[Cyrill Gorcunov]

On Sat, Jul 14, 2012 at 07:48:27PM +0200, Borislav Petkov wrote:
> On Sat, Jul 14, 2012 at 04:43:32PM +0400, Cyrill Gorcunov wrote:
> > For example to enable "PCI driver for virtio devices" I need to go to
> > Device Drivers -> Virtio drivers, while I think it would be great to
> > have everything virt. related in Virtualization section.
> 
> Actually, we need something more generic than that: everything X-related
> should be automatically selected when setting CONFIG_X. And X can be any
> subset of configuration options which belong to one feature, be it KVM,
> distro-specific stuff, or CPU-vendor specific stuff, or whatever.
> 
> I can imagine, for example, that when a user wants to have an
> AMD-specific config, it automatically selects CPU_SUP_AMD, X86_MCE_AMD
> (for MCE), MICROCODE_AMD (microcode support), AGP_AMD64, EDAC_AMD64 and
> a bunch of other AMD-specific features.

sure, no doubts, it would be great! (I must admit I never looked up into
kconfig parser code so i don't know if this could be achieved easily).

Cyrill
--
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 v4 1/2] mmc: card: Move MMC specific attributes to mmc sub-directory

[merez]

Hi all,

Do you have additional comments on this patch?

Thanks,
Maya

On Sat, July 14, 2012 11:46 am, Maya Erez wrote:
> Separate MMC specific attributes from general block device
> attributes and move them from the /sys/block/ directory
> to /sys/block//mmc directory
>
> Signed-off-by: Maya Erez 
> ---
>  drivers/mmc/card/block.c |   71
> +
>  1 files changed, 64 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 4ba0f09..2b8ad9e 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -114,6 +114,9 @@ struct mmc_blk_data {
>   struct device_attribute force_ro;
>   struct device_attribute power_ro_lock;
>   int area_type;
> +
> + struct kobject kobj;
> + struct kobj_type kobj_type;
>  };
>
>  static DEFINE_MUTEX(open_lock);
> @@ -185,6 +188,51 @@ static void mmc_blk_put(struct mmc_blk_data *md)
>   mutex_unlock(&open_lock);
>  }
>
> +static ssize_t mmc_blk_attr_show(struct kobject *kobj, struct attribute
> *attr,
> + char *buf)
> +{
> + struct device_attribute *dev_attr;
> + struct mmc_blk_data *md;
> + ssize_t ret;
> +
> + dev_attr = container_of(attr, struct device_attribute, attr);
> + if (!dev_attr->show)
> + return -EIO;
> +
> + md = container_of(kobj, struct mmc_blk_data, kobj);
> + if (!md || &md->kobj != kobj)
> + return -EINVAL;
> +
> + ret = dev_attr->show(disk_to_dev(md->disk), dev_attr, buf);
> +
> + return ret;
> +}
> +
> +static ssize_t mmc_blk_attr_store(struct kobject *kobj, struct attribute
> *attr,
> + const char *buf, size_t count)
> +{
> + struct device_attribute *dev_attr;
> + struct mmc_blk_data *md;
> + ssize_t ret;
> +
> + dev_attr = container_of(attr, struct device_attribute, attr);
> + if (!dev_attr->store)
> + return -EIO;
> +
> + md = container_of(kobj, struct mmc_blk_data, kobj);
> + if (!md || &md->kobj != kobj)
> + return -EINVAL;
> +
> + ret = dev_attr->store(disk_to_dev(md->disk), dev_attr, buf, count);
> +
> + return ret;
> +}
> +
> +static const struct sysfs_ops mmc_blk_sysfs_ops = {
> + .show   = mmc_blk_attr_show,
> + .store  = mmc_blk_attr_store,
> +};
> +
>  static ssize_t power_ro_lock_show(struct device *dev,
>   struct device_attribute *attr, char *buf)
>  {
> @@ -1999,14 +2047,15 @@ static void mmc_blk_remove_req(struct mmc_blk_data
> *md)
>   if (md) {
>   card = md->queue.card;
>   if (md->disk->flags & GENHD_FL_UP) {
> - device_remove_file(disk_to_dev(md->disk), 
> &md->force_ro);
> + sysfs_remove_file(&md->kobj, &md->force_ro.attr);
>   if ((md->area_type & MMC_BLK_DATA_AREA_BOOT) &&
>   card->ext_csd.boot_ro_lockable)
> - device_remove_file(disk_to_dev(md->disk),
> - &md->power_ro_lock);
> + sysfs_remove_file(&md->kobj,
> + &md->power_ro_lock.attr);
>
>   /* Stop new requests from getting into the queue */
>   del_gendisk(md->disk);
> + kobject_put(&md->kobj);
>   }
>
>   /* Then flush out any already in there */
> @@ -2035,12 +2084,19 @@ static int mmc_add_disk(struct mmc_blk_data *md)
>   struct mmc_card *card = md->queue.card;
>
>   add_disk(md->disk);
> +
> + md->kobj_type.sysfs_ops = &mmc_blk_sysfs_ops;
> + ret = kobject_init_and_add(&md->kobj, &md->kobj_type,
> + &disk_to_dev(md->disk)->kobj, "%s", "mmc");
> + if (ret)
> + goto init_kobj_fail;
> +
>   md->force_ro.show = force_ro_show;
>   md->force_ro.store = force_ro_store;
>   sysfs_attr_init(&md->force_ro.attr);
>   md->force_ro.attr.name = "force_ro";
>   md->force_ro.attr.mode = S_IRUGO | S_IWUSR;
> - ret = device_create_file(disk_to_dev(md->disk), &md->force_ro);
> + ret = sysfs_create_file(&md->kobj, &md->force_ro.attr);
>   if (ret)
>   goto force_ro_fail;
>
> @@ -2059,16 +2115,17 @@ static int mmc_add_disk(struct mmc_blk_data *md)
>   md->power_ro_lock.attr.mode = mode;
>   md->power_ro_lock.attr.name =
>   "ro_lock_until_next_power_on";
> - ret = device_create_file(disk_to_dev(md->disk),
> - &md->power_ro_lock);
> + ret = sysfs_create_file(&md->kobj, &md->power_ro_lock.attr);
>   if (ret)
>   goto power_ro_lock_fail;
>   }
>   return ret;
>
>  power_ro_lock_fail:
> - device_remove_file(disk_to_dev(md->disk), &md->force_ro);
> + sysfs_remove_file(&md->kobj, &md->force_ro.attr);
>  for

[PATCH RESEND v4 2/2] mmc: block: Add write packing control

[Maya Erez]

The write packing control will ensure that read requests latency is
not increased due to long write packed commands.

The trigger for enabling the write packing is managing to pack several
write requests. The number of potential packed requests that will trigger
the packing can be configured via sysfs by writing the required value to:
/sys/block//num_wr_reqs_to_start_packing.
The trigger for disabling the write packing is fetching a read request.

Signed-off-by: Maya Erez 
---
 Documentation/mmc/mmc-dev-attrs.txt |   17 ++
 drivers/mmc/card/block.c|  105 ++-
 drivers/mmc/card/queue.c|8 +++
 drivers/mmc/card/queue.h|3 +
 include/linux/mmc/host.h|1 +
 5 files changed, 133 insertions(+), 1 deletions(-)

diff --git a/Documentation/mmc/mmc-dev-attrs.txt 
b/Documentation/mmc/mmc-dev-attrs.txt
index 22ae844..f4a48a8 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
@@ -8,6 +8,23 @@ The following attributes are read/write.
 
force_roEnforce read-only access even if write protect 
switch is off.
 
+   num_wr_reqs_to_start_packingThis attribute is used to determine
+   the trigger for activating the write packing, in case the write
+   packing control feature is enabled.
+
+   When the MMC manages to reach a point where num_wr_reqs_to_start_packing
+   write requests could be packed, it enables the write packing feature.
+   This allows us to start the write packing only when it is beneficial
+   and has minimum affect on the read latency.
+
+   The number of potential packed requests that will trigger the packing
+   can be configured via sysfs by writing the required value to:
+   /sys/block//mmc/num_wr_reqs_to_start_packing.
+
+   The default value of num_wr_reqs_to_start_packing was determined by
+   running parallel lmdd write and lmdd read operations and calculating
+   the max number of packed writes requests.
+
 SD and MMC Device Attributes
 
 
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 2b8ad9e..6d63ce0 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -114,6 +114,7 @@ struct mmc_blk_data {
struct device_attribute force_ro;
struct device_attribute power_ro_lock;
int area_type;
+   struct device_attribute num_wr_reqs_to_start_packing;
 
struct kobject kobj;
struct kobj_type kobj_type;
@@ -329,6 +330,38 @@ out:
return ret;
 }
 
+static ssize_t
+num_wr_reqs_to_start_packing_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   struct mmc_blk_data *md = mmc_blk_get(dev_to_disk(dev));
+   int num_wr_reqs_to_start_packing;
+   int ret;
+
+   num_wr_reqs_to_start_packing = md->queue.num_wr_reqs_to_start_packing;
+
+   ret = snprintf(buf, PAGE_SIZE, "%d\n", num_wr_reqs_to_start_packing);
+
+   mmc_blk_put(md);
+   return ret;
+}
+
+static ssize_t
+num_wr_reqs_to_start_packing_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   int value;
+   struct mmc_blk_data *md = mmc_blk_get(dev_to_disk(dev));
+
+   sscanf(buf, "%d", &value);
+   if (value >= 0)
+   md->queue.num_wr_reqs_to_start_packing = value;
+
+   mmc_blk_put(md);
+   return count;
+}
+
 static int mmc_blk_open(struct block_device *bdev, fmode_t mode)
 {
struct mmc_blk_data *md = mmc_blk_get(bdev->bd_disk);
@@ -1344,6 +1377,49 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req 
*mqrq,
mmc_queue_bounce_pre(mqrq);
 }
 
+static void mmc_blk_write_packing_control(struct mmc_queue *mq,
+ struct request *req)
+{
+   struct mmc_host *host = mq->card->host;
+   int data_dir;
+
+   if (!(host->caps2 & MMC_CAP2_PACKED_WR))
+   return;
+
+   /*
+* In case the packing control is not supported by the host, it should
+* not have an effect on the write packing. Therefore we have to enable
+* the write packing
+*/
+   if (!(host->caps2 & MMC_CAP2_PACKED_WR_CONTROL)) {
+   mq->wr_packing_enabled = true;
+   return;
+   }
+
+   if (!req || (req && (req->cmd_flags & REQ_FLUSH))) {
+   if (mq->num_of_potential_packed_wr_reqs >
+   mq->num_wr_reqs_to_start_packing)
+   mq->wr_packing_enabled = true;
+   mq->num_of_potential_packed_wr_reqs = 0;
+   return;
+   }
+
+   data_dir = rq_data_dir(req);
+
+   if (data_dir == READ) {
+   mq->num_of_potential_packed_wr_reqs = 0;
+   mq->wr_packing_enabled = false;
+   return;
+   } el

[PATCH RESEND v4 1/2] mmc: card: Move MMC specific attributes to mmc sub-directory

[Maya Erez]

Separate MMC specific attributes from general block device
attributes and move them from the /sys/block/ directory
to /sys/block//mmc directory

Signed-off-by: Maya Erez 
---
 drivers/mmc/card/block.c |   71 +
 1 files changed, 64 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 4ba0f09..2b8ad9e 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -114,6 +114,9 @@ struct mmc_blk_data {
struct device_attribute force_ro;
struct device_attribute power_ro_lock;
int area_type;
+
+   struct kobject kobj;
+   struct kobj_type kobj_type;
 };
 
 static DEFINE_MUTEX(open_lock);
@@ -185,6 +188,51 @@ static void mmc_blk_put(struct mmc_blk_data *md)
mutex_unlock(&open_lock);
 }
 
+static ssize_t mmc_blk_attr_show(struct kobject *kobj, struct attribute *attr,
+   char *buf)
+{
+   struct device_attribute *dev_attr;
+   struct mmc_blk_data *md;
+   ssize_t ret;
+
+   dev_attr = container_of(attr, struct device_attribute, attr);
+   if (!dev_attr->show)
+   return -EIO;
+
+   md = container_of(kobj, struct mmc_blk_data, kobj);
+   if (!md || &md->kobj != kobj)
+   return -EINVAL;
+
+   ret = dev_attr->show(disk_to_dev(md->disk), dev_attr, buf);
+
+   return ret;
+}
+
+static ssize_t mmc_blk_attr_store(struct kobject *kobj, struct attribute *attr,
+   const char *buf, size_t count)
+{
+   struct device_attribute *dev_attr;
+   struct mmc_blk_data *md;
+   ssize_t ret;
+
+   dev_attr = container_of(attr, struct device_attribute, attr);
+   if (!dev_attr->store)
+   return -EIO;
+
+   md = container_of(kobj, struct mmc_blk_data, kobj);
+   if (!md || &md->kobj != kobj)
+   return -EINVAL;
+
+   ret = dev_attr->store(disk_to_dev(md->disk), dev_attr, buf, count);
+
+   return ret;
+}
+
+static const struct sysfs_ops mmc_blk_sysfs_ops = {
+   .show   = mmc_blk_attr_show,
+   .store  = mmc_blk_attr_store,
+};
+
 static ssize_t power_ro_lock_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
@@ -1999,14 +2047,15 @@ static void mmc_blk_remove_req(struct mmc_blk_data *md)
if (md) {
card = md->queue.card;
if (md->disk->flags & GENHD_FL_UP) {
-   device_remove_file(disk_to_dev(md->disk), 
&md->force_ro);
+   sysfs_remove_file(&md->kobj, &md->force_ro.attr);
if ((md->area_type & MMC_BLK_DATA_AREA_BOOT) &&
card->ext_csd.boot_ro_lockable)
-   device_remove_file(disk_to_dev(md->disk),
-   &md->power_ro_lock);
+   sysfs_remove_file(&md->kobj,
+   &md->power_ro_lock.attr);
 
/* Stop new requests from getting into the queue */
del_gendisk(md->disk);
+   kobject_put(&md->kobj);
}
 
/* Then flush out any already in there */
@@ -2035,12 +2084,19 @@ static int mmc_add_disk(struct mmc_blk_data *md)
struct mmc_card *card = md->queue.card;
 
add_disk(md->disk);
+
+   md->kobj_type.sysfs_ops = &mmc_blk_sysfs_ops;
+   ret = kobject_init_and_add(&md->kobj, &md->kobj_type,
+   &disk_to_dev(md->disk)->kobj, "%s", "mmc");
+   if (ret)
+   goto init_kobj_fail;
+
md->force_ro.show = force_ro_show;
md->force_ro.store = force_ro_store;
sysfs_attr_init(&md->force_ro.attr);
md->force_ro.attr.name = "force_ro";
md->force_ro.attr.mode = S_IRUGO | S_IWUSR;
-   ret = device_create_file(disk_to_dev(md->disk), &md->force_ro);
+   ret = sysfs_create_file(&md->kobj, &md->force_ro.attr);
if (ret)
goto force_ro_fail;
 
@@ -2059,16 +2115,17 @@ static int mmc_add_disk(struct mmc_blk_data *md)
md->power_ro_lock.attr.mode = mode;
md->power_ro_lock.attr.name =
"ro_lock_until_next_power_on";
-   ret = device_create_file(disk_to_dev(md->disk),
-   &md->power_ro_lock);
+   ret = sysfs_create_file(&md->kobj, &md->power_ro_lock.attr);
if (ret)
goto power_ro_lock_fail;
}
return ret;
 
 power_ro_lock_fail:
-   device_remove_file(disk_to_dev(md->disk), &md->force_ro);
+   sysfs_remove_file(&md->kobj, &md->force_ro.attr);
 force_ro_fail:
+   kobject_put(&md->kobj);
+init_kobj_fail:
del_gendisk(md->disk);
 
return ret;
-- 
1.7.3.3
-- 
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center,

Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues

[Borislav Petkov]

On Sat, Jul 14, 2012 at 04:43:32PM +0400, Cyrill Gorcunov wrote:
> For example to enable "PCI driver for virtio devices" I need to go to
> Device Drivers -> Virtio drivers, while I think it would be great to
> have everything virt. related in Virtualization section.

Actually, we need something more generic than that: everything X-related
should be automatically selected when setting CONFIG_X. And X can be any
subset of configuration options which belong to one feature, be it KVM,
distro-specific stuff, or CPU-vendor specific stuff, or whatever.

I can imagine, for example, that when a user wants to have an
AMD-specific config, it automatically selects CPU_SUP_AMD, X86_MCE_AMD
(for MCE), MICROCODE_AMD (microcode support), AGP_AMD64, EDAC_AMD64 and
a bunch of other AMD-specific features.

This would simplify not only the configuration process but also
Kconfig-related build failures since for your configuration you'll make
sure that required stuff is selected.

What I'm saying is that not only distro-specific configs but also some
sort of hierarchical config options could be defined to automatically
preselect stuff for a specific aspect and save a lot of time when
configuring a new system. Our config options have grown humongous right
about now and we can use the simplification. Of course, you can always
do fine-grained tuning afterwards but it'll save a lot of time, in
general.

Let's have an example: when I have to build upstream on a distro here,
I take the distro config and use it despite that it takes a long time
to build since everything is module - it is still better for me to
wait that one time instead of doing a dozen of trial and errors after
forgetting a config option each time.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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] ACPI patch for Linux-3.5-rc6

[Len Brown]

Hi Linus,

Please pull this ACPI patch.

thanks!

Len Brown, Intel Open Source Technology Center


The following changes since commit fdb1335a82ef1ef9442ac9377796e4e7a69d1ae4:

  Merge tag 'md-3.5-fixes' of git://neil.brown.name/md (2012-07-13 17:59:33 
-0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git 

for you to fetch changes up to 46befd6b38d802dfc5998e7d7938854578b45d9d:

  ACPICA: Fix possible fault in return package object repair code (2012-07-14 
11:38:41 -0400)


Bob Moore (1):
  ACPICA: Fix possible fault in return package object repair code

 drivers/acpi/acpica/nspredef.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--
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] x86, amd: rename vmmu support capability

[Borislav Petkov]

On Sat, Jul 14, 2012 at 04:28:51PM +0200, Davidlohr Bueso wrote:
> On Sat, 2012-07-14 at 15:38 +0200, H. Peter Anvin wrote:
> > Yep, NAK on this one.
> 
> Ok, we could at least add a comment when defining X86_FEATURE_NPT.

And the valid, sane, technical reason for having a comment where any
internet search could do, is... ?

-- 
Regards/Gruss,
Boris.
--
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: PROBLEM: Silent data corruption when using sendfile()

[Johannes Truschnigg]

On Sat, Jul 14, 2012 at 03:15:40PM +0200, Willy Tarreau wrote:
> On Sat, Jul 14, 2012 at 01:06:07PM +0200, Eric Dumazet wrote:
> [...]
> > Hmmm, this is supposed to fix a bug introduced in 3.4, no ?
> > 
> > So 3.3 kernel should work well ?
> 
> You're right indeed. So maybe it's not the same bug. Or maybe Johannes
> was affected by two different bugs in both versions, since Thorsten's
> report seems to point the finger at the same bug.
> 
> Johannes, are you certain that you were having the exact same issue
> with 3.3 ?

I still have the Linux 3.3-series kernel image around that I _think_ I first
saw the problem occur with. I'll try to reproduce the problem with that
kernel, but I cannot promise that results will be ready before Tuesday. I'll
keep you posted!

-- 
with best regards:
- Johannes Truschnigg ( johan...@truschnigg.info )

www:   http://johannes.truschnigg.info/
phone: +43 650 2 17
xmpp:  johan...@truschnigg.info

Please do not bother me with HTML-email or attachments. Thank you.


signature.asc
Description: Digital signature

Re: [RFC 1/2] PCI-Express Non-Transparent Bridge Support

[Greg KH]

On Fri, Jul 13, 2012 at 02:44:59PM -0700, Jon Mason wrote:
> +static int max_num_cbs = 2;
> +module_param(max_num_cbs, uint, 0644);
> +MODULE_PARM_DESC(max_num_cbs, "Maximum number of NTB transport connections");
> +
> +static bool no_msix;
> +module_param(no_msix, bool, 0644);
> +MODULE_PARM_DESC(no_msix, "Do not allow MSI-X interrupts to be selected");

How would a user, or a distro, know to set these options?  Why are they
even options at all?


> +struct ntb_device {
> + struct pci_dev *pdev;
> + struct msix_entry *msix_entries;
> + void __iomem *reg_base;
> + struct ntb_mw mw[NTB_NUM_MW];
> + struct {
> + unsigned int max_spads;
> + unsigned int max_db_bits;
> + unsigned int msix_cnt;
> + } limits;
> + struct {
> + void __iomem *pdb;
> + void __iomem *pdb_mask;
> + void __iomem *sdb;
> + void __iomem *sbar2_xlat;
> + void __iomem *sbar4_xlat;
> + void __iomem *spad_write;
> + void __iomem *spad_read;
> + void __iomem *lnk_cntl;
> + void __iomem *lnk_stat;
> + void __iomem *spci_cmd;
> + } reg_ofs;
> + void *ntb_transport;
> + void (*event_cb)(void *handle, unsigned int event);

Shouldn't the event be an enum?

> + struct ntb_db_cb *db_cb;
> + unsigned char hw_type;
> + unsigned char conn_type;
> + unsigned char dev_type;
> + unsigned char num_msix;
> + unsigned char bits_per_vector;
> + unsigned char max_cbs;
> + unsigned char link_status;
> + struct delayed_work hb_timer;
> + unsigned long last_ts;
> +};

Why isn't this either a 'struct device' itself, or why isn't the 'struct
pci_device' embedded within it?  What controls the lifetime of this
device?  Why doesn't it show up in sysfs?  Don't you want it to show up
in the global device tree?

> +static DEFINE_PCI_DEVICE_TABLE(ntb_pci_tbl) = {
> + {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_B2B_BWD)},
> + {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_B2B_JSF)},
> + {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_CLASSIC_JSF)},
> + {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_RP_JSF)},
> + {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_RP_SNB)},
> + {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_B2B_SNB)},
> + {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_NTB_CLASSIC_SNB)},
> + {0}
> +};
> +MODULE_DEVICE_TABLE(pci, ntb_pci_tbl);
> +
> +static struct ntb_device *ntbdev;

You can really only have just one of these in the whole system?  Is that
wise?  Why isn't it dynamic and tied to the pci device itself as a
child?

thanks,

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

Re: [RFC 1/2] PCI-Express Non-Transparent Bridge Support

[Greg KH]

On Fri, Jul 13, 2012 at 02:44:59PM -0700, Jon Mason wrote:
> The NTB device driver is needed to configure these memory windows, doorbell, 
> and
> scratch-pad registers as well as use them in such a way as they can be turned
> into a viable communication channel to the remote system.  ntb_hw.[ch]
> determines the usage model (NTB to NTB or NTB to Root Port) and abstracts away
> the underlying hardware to provide access and a common interface to the 
> doorbell
> registers, scratch pads, and memory windows.  These hardware interfaces are
> exported so that other, non-mainlined kernel drivers can access these.

Why would you have non-mainlined drivers?

Can you submit the drivers at the same time so we see how you are using
these new interfaces?

> +++ b/drivers/ntb/ntb_hw.c
> @@ -0,0 +1,1283 @@
> +/*
> + * This file is provided under a dual BSD/GPLv2 license.  When using or
> + *   redistributing this file, you may do so under either license.
> + *
> + *   GPL LICENSE SUMMARY
> + *
> + *   Copyright(c) 2012 Intel Corporation. All rights reserved.
> + *
> + *   This program is free software; you can redistribute it and/or modify
> + *   it under the terms of version 2 of the GNU General Public License as
> + *   published by the Free Software Foundation.
> + *
> + *   This program is distributed in the hope that it will be useful, but
> + *   WITHOUT ANY WARRANTY; without even the implied warranty of
> + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + *   General Public License for more details.
> + *
> + *   You should have received a copy of the GNU General Public License
> + *   along with this program; if not, write to the Free Software
> + *   Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 
> USA.
> + *   The full GNU General Public License is included in this distribution
> + *   in the file called LICENSE.GPL.

You really want to track the office movements of the FSF for the next 40
years?  You should ask your lawyers if you can remove this paragraph.

> +/**
> + * ntb_hw_link_status() - return the hardware link status
> + * @ndev: pointer to ntb_device instance
> + *
> + * Returns true if the hardware is connected to the remote system
> + *
> + * RETURNS: true or false based on the hardware link state
> + */
> +bool ntb_hw_link_status(struct ntb_device *ndev)
> +{
> + return ndev->link_status == NTB_LINK_UP;
> +}
> +EXPORT_SYMBOL(ntb_hw_link_status);

EXPORT_SYMBOL_GPL() perhaps, for these, and the other symbols you are
creating?

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 20/40] autonuma: alloc/free/init mm_autonuma

[Andrea Arcangeli]

On Fri, Jul 13, 2012 at 09:19:06AM -0500, Christoph Lameter wrote:
> On Thu, 12 Jul 2012, Johannes Weiner wrote:
> 
> > On Thu, Jul 12, 2012 at 08:08:28PM +0200, Andrea Arcangeli wrote:
> > > On Sat, Jun 30, 2012 at 01:12:18AM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, Jun 28, 2012 at 02:56:00PM +0200, Andrea Arcangeli wrote:
> > > > > This is where the mm_autonuma structure is being handled. Just like
> > > > > sched_autonuma, this is only allocated at runtime if the hardware the
> > > > > kernel is running on has been detected as NUMA. On not NUMA hardware
> > > >
> > > > I think the correct wording is "non-NUMA", not "not NUMA".
> > >
> > > That sounds far too easy to me, but I've no idea what's the right is here.
> >
> > UMA?
> >
> > Single-node hardware?
> 
> Lets be simple and stay with non-NUMA.

Ok, I already corrected all occurrences.

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 2/3] vsyscall_64: allow SECCOMP_RET_TRACErs to skip

[Will Drewry]

On Sat, Jul 14, 2012 at 11:21 AM, Andrew Lutomirski  wrote:
> On Sat, Jul 14, 2012 at 9:15 AM, Andrew Lutomirski  wrote:
>> On Sat, Jul 14, 2012 at 8:57 AM, Will Drewry  wrote:
>>> On Sat, Jul 14, 2012 at 10:50 AM, Will Drewry  wrote:
 On Sat, Jul 14, 2012 at 10:44 AM, Andrew Lutomirski  wrote:
> I think I'd prefer if changing to something other than whatever value is
> used to cancel the syscall resulted in a crash rather than just being
> ignored.

 I was trying to keep as much seccomp-ptrace behavior intact rather
 than making it terminal in this special case.  Is there a reason why
 it'd make more sense to crash?
>>>
>>> Unless you meant something the tracer could catch?  That may make
>>> sense, but they could also use singlestep or whatever else to get
>>> similar behavior.  But maybe I'm missing the bigger picture!
>>
>> I think it would be nice to not introduce any special behavior that
>> things might rely on if we do this better in the future.  Similarly,
>> for almost all purposes, a tracer could change gettimeofday to write,
>> but there would be a silent behavior change if gettimeofday were
>> entered via vsyscall.
>>
>> What's the standard way of skipping a syscall?  sigreturn?  (I don't
>> know off the top of my head what sigreturn does.)  sys_ni_syscall?

Most implementations I've seen just set orig_rax to -1, but in
practice any system call that is invalid will result in the system
call being skipped in the normal syscall path.  So I could tweak it to
check <0 > __NR_syscalls and add a sigsys generator if it is valid.

Do you think that'd be the most correct move? (As you say below, the
impact of _any_ changes here are very minor :)

>> I'd be all for making those continue to work but making anything that
>> can't be emulated correctly do something sufficiently unpleasant that
>> people won't do it.  Is there a syscall that does nothing at all?
>
> Here's my suggestion for now: any attempt by the seccomp filter to do
> anything other than executing the syscall unchanged, skipping it
> entirely, or killing results in a trap or sigsys with the syscall
> number unchanged.
>
> In the RET_TRACE case, the SIGSYS restarts at the mov nr,%rax
> instruction.  The tracer can deal with it accordingly (via checking
> the rip) -- if the tracer changes rax, it'll get changed right back by
> the emulated mov nr,%rax.  If this results in an infinite loop, so be
> it.
>
> In the RET_TRAP case, do the same thing but via the special ptrace
> event instead of SIGSYS.

You've lost me here.  The flow of a RET_TRAP is:
- enter vsyscall at 0xff600[]00
- run seccomp
- get ret_trap
- queue up a synchronous trap
- skip the vsyscall
- return

Even if the trap were to interrupt the current vsyscall trap handler,
the skip value would still be -1 and the syscall would still get
skipped without touching sp or ip.

Traps cannot provide kernel-side arbitration of allowed syscalls, they
can just emulate them in userspace before "returning" to the original
callsite.  In this case, vsyscall makes returning there harder and the
quirk is to return to the prior address if the ip is in vsyscall's
range.

> This way, the special rip & ~0x0c00 == 0xff60 handling
> becomes part of the ABI, but it looks like the mov instruction
> trapped, which it more or less did.  If we want RET_TRAP to be able to
> skip the syscall, let it happen the normal way.

I *think* trap is ok?

> This stuff probably barely matters.  For example, ptrace currently
> doesn't work right when vsyscalls are being emulated.  No one appears
> to care.

Agreed :) I don't mind making tweaks to get it right, but this only
matters to users that want to:
- use seccomp filter
- with ptrace (or trap with resumption and not sigreturn)
- of time, gettimeofday, and getcpu
since they will then have to include quirk management _just_ in case
their code is linked against something using vsyscall and
vsyscall=emulate is in effect!

thanks!
will
--
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 25/40] autonuma: follow_page check for pte_numa/pmd_numa

[Andrea Arcangeli]

On Mon, Jul 02, 2012 at 12:14:11AM -0400, Rik van Riel wrote:
> On 06/28/2012 08:56 AM, Andrea Arcangeli wrote:
> > Without this, follow_page wouldn't trigger the NUMA hinting faults.
> >
> > Signed-off-by: Andrea Arcangeli
> 
> follow_page is called from many different places, not just
> the process itself. One example would be ksm.
> 
> Do you really want to trigger NUMA hinting faults when the
> mm != current->mm, or is that magically prevented somewhere?

The NUMA hinting page fault will update "current->task_autonuma"
according to the page_nid of the page triggering the numa hinting page
fault in follow_page. It doesn't matter if the page belongs to the
different mm, all we care is the page_nid that was accessed by the
"current" task through a numa hinting fault.

When I started thinking the benefit it could provide, I thought it
wouldn't be worth it because task_autonuma statistics are only used to
balance threads belonging to the same process, and mm_autonuma is used
to balance tasks belonging to different processes. And mm_autonuma
will never be able to take into account things like this.

So I converted the !current->mm check to a current->mm != mm check
here to save a bit of cpu and skip it in the autonuma branch.

void numa_hinting_fault(struct mm_struct *mm, struct page *page, int numpages)
{
/*
 * "current->mm" could be different from "mm" if
 * get_user_pages() triggered the fault on some other process
 * "mm". It wouldn't be a problem to account this NUMA hinting
 * page fault on the current->task_autonuma statistics even if
 * it was triggered on a page mapped on a different
 * "mm". However task_autonuma isn't used to balance threads
 * belonging to different processes so it wouldn't help and in
 * turn it's not worth it.
 */
if (likely(current->mm == mm && !current->mempolicy && 
autonuma_enabled())) {

But I was thinking at the usual case of one ptracer task with a single
thread, however now I changed my mind and I think it can help when
there's just one process and a ton of threads spanning multiple nodes,
and one of the threads is ptracing an otherwise idle task and
accessing lot of ram through ptrace. So I think I'll roll it back to
autonuma21 status and allow the accounting of all page_nid even for
different mm again. But this is mostly a theoretical issue.

It can lead to a funny weighting where mm_autonuma shows 100% of the
weight in one node, and task_autonuma shows 95% of the weight to
another different node. But it should still work fine as we won't
allow the thread to go to that different node if a different process
run there. If a thread of the same process runs in the node where
task_autonuma shows 95% of the weight, then it's better to put the
thread there if it has higher weight than the other thread of the same
process so it'll be fine despite mm_autonuma and task_autonuma disagree.

Disagreement of task_autonuma and mm_autonuma happens all the time and
it's perfectly normal, just this will exacerbate a little more.
--
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 5/6] drivers/pci/hotplug: ensure a consistent return value in error case

[Julia Lawall]

From: Julia Lawall 

Typically, the return value desired for the failure of a function with an
integer return value is a negative integer.  In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return variable within the loop.

A simplified version of the semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)

//
@r exists@
identifier ret;
position p;
constant C;
expression e1,e3,e4;
statement S;
@@

ret = -C
... when != ret = e3
when any
if@p (...) S
... when any
if (\(ret != 0\|ret < 0\|ret > 0\) || ...) { ... return ...; }
... when != ret = e3
when any
*if@p (...)
{
  ... when != ret = e4
  return ret;
}
//

Signed-off-by: Julia Lawall 

---
 drivers/pci/hotplug/cpqphp_core.c|   14 ++
 drivers/pci/hotplug/pcihp_skeleton.c |   14 ++
 drivers/pci/hotplug/shpchp_core.c|   14 ++
 3 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/hotplug/cpqphp_core.c 
b/drivers/pci/hotplug/cpqphp_core.c
index 187a199..c8eaeb4 100644
--- a/drivers/pci/hotplug/cpqphp_core.c
+++ b/drivers/pci/hotplug/cpqphp_core.c
@@ -611,7 +611,7 @@ static int ctrl_slot_setup(struct controller *ctrl,
u32 tempdword;
char name[SLOT_NAME_SIZE];
void __iomem *slot_entry= NULL;
-   int result = -ENOMEM;
+   int result;
 
dbg("%s\n", __func__);
 
@@ -623,19 +623,25 @@ static int ctrl_slot_setup(struct controller *ctrl,
 
while (number_of_slots) {
slot = kzalloc(sizeof(*slot), GFP_KERNEL);
-   if (!slot)
+   if (!slot) {
+   result = -ENOMEM;
goto error;
+   }
 
slot->hotplug_slot = kzalloc(sizeof(*(slot->hotplug_slot)),
GFP_KERNEL);
-   if (!slot->hotplug_slot)
+   if (!slot->hotplug_slot) {
+   result = -ENOMEM;
goto error_slot;
+   }
hotplug_slot = slot->hotplug_slot;
 
hotplug_slot->info = kzalloc(sizeof(*(hotplug_slot->info)),
GFP_KERNEL);
-   if (!hotplug_slot->info)
+   if (!hotplug_slot->info) {
+   result = -ENOMEM;
goto error_hpslot;
+   }
hotplug_slot_info = hotplug_slot->info;
 
slot->ctrl = ctrl;
diff --git a/drivers/pci/hotplug/pcihp_skeleton.c 
b/drivers/pci/hotplug/pcihp_skeleton.c
index b20ceaa..1f00b93 100644
--- a/drivers/pci/hotplug/pcihp_skeleton.c
+++ b/drivers/pci/hotplug/pcihp_skeleton.c
@@ -252,7 +252,7 @@ static int __init init_slots(void)
struct slot *slot;
struct hotplug_slot *hotplug_slot;
struct hotplug_slot_info *info;
-   int retval = -ENOMEM;
+   int retval;
int i;
 
/*
@@ -261,17 +261,23 @@ static int __init init_slots(void)
 */
for (i = 0; i < num_slots; ++i) {
slot = kzalloc(sizeof(*slot), GFP_KERNEL);
-   if (!slot)
+   if (!slot) {
+   retval = -ENOMEM;
goto error;
+   }
 
hotplug_slot = kzalloc(sizeof(*hotplug_slot), GFP_KERNEL);
-   if (!hotplug_slot)
+   if (!hotplug_slot) {
+   retval = -ENOMEM;
goto error_slot;
+   }
slot->hotplug_slot = hotplug_slot;
 
info = kzalloc(sizeof(*info), GFP_KERNEL);
-   if (!info)
+   if (!info) {
+   retval = -ENOMEM;
goto error_hpslot;
+   }
hotplug_slot->info = info;
 
slot->number = i;
diff --git a/drivers/pci/hotplug/shpchp_core.c 
b/drivers/pci/hotplug/shpchp_core.c
index 7414fd9..b6de307 100644
--- a/drivers/pci/hotplug/shpchp_core.c
+++ b/drivers/pci/hotplug/shpchp_core.c
@@ -99,22 +99,28 @@ static int init_slots(struct controller *ctrl)
struct hotplug_slot *hotplug_slot;
struct hotplug_slot_info *info;
char name[SLOT_NAME_SIZE];
-   int retval = -ENOMEM;
+   int retval;
int i;
 
for (i = 0; i < ctrl->num_slots; i++) {
slot = kzalloc(sizeof(*slot), GFP_KERNEL);
-   if (!slot)
+   if (!slot) {
+   retval = -ENOMEM;
goto error;
+   }
 
hotplug_slot = kzalloc(sizeof(*hotplug_slot), GFP_KERNEL);
-   if (!hotplug_slot)
+   if (!hotplug_slot) {
+   retval = -ENOMEM;
goto error_slot;
+   }
slot->hotplug_slot = hotplug_slot;
 
info = kzalloc(sizeof(*info), GFP_KERNEL);
-   

[PATCH 4/6] drivers/cpuidle/sysfs.c: ensure a consistent return value in error case

[Julia Lawall]

From: Julia Lawall 

Typically, the return value desired for the failure of a function with an
integer return value is a negative integer.  In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return variable within the loop.

A simplified version of the semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)

//
@r exists@
identifier ret;
position p;
constant C;
expression e1,e3,e4;
statement S;
@@

ret = -C
... when != ret = e3
when any
if@p (...) S
... when any
if (\(ret != 0\|ret < 0\|ret > 0\) || ...) { ... return ...; }
... when != ret = e3
when any
*if@p (...)
{
  ... when != ret = e4
  return ret;
}
//

Signed-off-by: Julia Lawall 

---
 drivers/cpuidle/sysfs.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index 5f809e3..06df57c 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -361,15 +361,17 @@ static inline void cpuidle_free_state_kobj(struct 
cpuidle_device *device, int i)
  */
 int cpuidle_add_state_sysfs(struct cpuidle_device *device)
 {
-   int i, ret = -ENOMEM;
+   int i, ret;
struct cpuidle_state_kobj *kobj;
struct cpuidle_driver *drv = cpuidle_get_driver();
 
/* state statistics */
for (i = 0; i < device->state_count; i++) {
kobj = kzalloc(sizeof(struct cpuidle_state_kobj), GFP_KERNEL);
-   if (!kobj)
+   if (!kobj) {
+   ret = -ENOMEM;
goto error_state;
+   }
kobj->state = &drv->states[i];
kobj->state_usage = &device->states_usage[i];
init_completion(&kobj->kobj_unregister);

--
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/6] drivers/pci/hotplug/cpci_hotplug_core.c: ensure a consistent return value in error case

[Julia Lawall]

From: Julia Lawall 

Typically, the return value desired for the failure of a function with an
integer return value is a negative integer.  In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return variable within the loop.

A simplified version of the semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)

//
@r exists@
identifier ret;
position p;
constant C;
expression e1,e3,e4;
statement S;
@@

ret = -C
... when != ret = e3
when any
if@p (...) S
... when any
if (\(ret != 0\|ret < 0\|ret > 0\) || ...) { ... return ...; }
... when != ret = e3
when any
*if@p (...)
{
  ... when != ret = e4
  return ret;
}
//

Signed-off-by: Julia Lawall 

---
 drivers/pci/hotplug/cpci_hotplug_core.c |   14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/hotplug/cpci_hotplug_core.c 
b/drivers/pci/hotplug/cpci_hotplug_core.c
index 3fadf2f..2b4c412 100644
--- a/drivers/pci/hotplug/cpci_hotplug_core.c
+++ b/drivers/pci/hotplug/cpci_hotplug_core.c
@@ -225,7 +225,7 @@ cpci_hp_register_bus(struct pci_bus *bus, u8 first, u8 last)
struct hotplug_slot *hotplug_slot;
struct hotplug_slot_info *info;
char name[SLOT_NAME_SIZE];
-   int status = -ENOMEM;
+   int status;
int i;
 
if (!(controller && bus))
@@ -237,18 +237,24 @@ cpci_hp_register_bus(struct pci_bus *bus, u8 first, u8 
last)
 */
for (i = first; i <= last; ++i) {
slot = kzalloc(sizeof (struct slot), GFP_KERNEL);
-   if (!slot)
+   if (!slot) {
+   status = -ENOMEM;
goto error;
+   }
 
hotplug_slot =
kzalloc(sizeof (struct hotplug_slot), GFP_KERNEL);
-   if (!hotplug_slot)
+   if (!hotplug_slot) {
+   status = -ENOMEM;
goto error_slot;
+   }
slot->hotplug_slot = hotplug_slot;
 
info = kzalloc(sizeof (struct hotplug_slot_info), GFP_KERNEL);
-   if (!info)
+   if (!info) {
+   status = -ENOMEM;
goto error_hpslot;
+   }
hotplug_slot->info = info;
 
slot->bus = bus;

--
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/6] drivers/net/can/softing/softing_main.c: ensure a consistent return value in error case

[Julia Lawall]

From: Julia Lawall 

Typically, the return value desired for the failure of a function with an
integer return value is a negative integer.  In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return variable within the loop.

A simplified version of the semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)

//
@r exists@
identifier ret;
position p;
constant C;
expression e1,e3,e4;
statement S;
@@

ret = -C
... when != ret = e3
when any
if@p (...) S
... when any
if (\(ret != 0\|ret < 0\|ret > 0\) || ...) { ... return ...; }
... when != ret = e3
when any
*if@p (...)
{
  ... when != ret = e4
  return ret;
}
//

Signed-off-by: Julia Lawall 

---
 drivers/net/can/softing/softing_main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/softing/softing_main.c 
b/drivers/net/can/softing/softing_main.c
index a7c77c7..f2a221e 100644
--- a/drivers/net/can/softing/softing_main.c
+++ b/drivers/net/can/softing/softing_main.c
@@ -826,12 +826,12 @@ static __devinit int softing_pdev_probe(struct 
platform_device *pdev)
goto sysfs_failed;
}
 
-   ret = -ENOMEM;
for (j = 0; j < ARRAY_SIZE(card->net); ++j) {
card->net[j] = netdev =
softing_netdev_create(card, card->id.chip[j]);
if (!netdev) {
dev_alert(&pdev->dev, "failed to make can[%i]", j);
+   ret = -ENOMEM;
goto netdev_failed;
}
priv = netdev_priv(card->net[j]);

--
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 6/6] arch/x86/kernel/kdebugfs.c: ensure a consistent return value in error case

[Julia Lawall]

From: Julia Lawall 

Typically, the return value desired for the failure of a function with an
integer return value is a negative integer.  In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return variable within the loop.

A simplified version of the semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)

//
@r exists@
identifier ret;
position p;
constant C;
expression e1,e3,e4;
statement S;
@@

ret = -C
... when != ret = e3
when any
if@p (...) S
... when any
if (\(ret != 0\|ret < 0\|ret > 0\) || ...) { ... return ...; }
... when != ret = e3
when any
*if@p (...)
{
  ... when != ret = e4
  return ret;
}
//

Signed-off-by: Julia Lawall 

---
 arch/x86/kernel/kdebugfs.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
index 1d5d31e..dc1404b 100644
--- a/arch/x86/kernel/kdebugfs.c
+++ b/arch/x86/kernel/kdebugfs.c
@@ -107,7 +107,7 @@ static int __init create_setup_data_nodes(struct dentry 
*parent)
 {
struct setup_data_node *node;
struct setup_data *data;
-   int error = -ENOMEM;
+   int error;
struct dentry *d;
struct page *pg;
u64 pa_data;
@@ -121,8 +121,10 @@ static int __init create_setup_data_nodes(struct dentry 
*parent)
 
while (pa_data) {
node = kmalloc(sizeof(*node), GFP_KERNEL);
-   if (!node)
+   if (!node) {
+   error = -ENOMEM;
goto err_dir;
+   }
 
pg = pfn_to_page((pa_data+sizeof(*data)-1) >> PAGE_SHIFT);
if (PageHighMem(pg)) {

--
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 3/6] arch/arm/mach-netx/xc.c: ensure a consistent return value in error case

[Julia Lawall]

From: Julia Lawall 

Typically, the return value desired for the failure of a function with an
integer return value is a negative integer.  In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return variable within the loop.

Resetting ret to 0 at the end of the function is not necessary because the
return value of xc_patch is either 0 or a negative integer.

A simplified version of the semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)

//
@r exists@
identifier ret;
position p;
constant C;
expression e1,e3,e4;
statement S;
@@

ret = -C
... when != ret = e3
when any
if@p (...) S
... when any
if (\(ret != 0\|ret < 0\|ret > 0\) || ...) { ... return ...; }
... when != ret = e3
when any
*if@p (...)
{
  ... when != ret = e4
  return ret;
}
//

Signed-off-by: Julia Lawall 

---
If relying on the return value of xc_patch to set ret to 0 is considered
too fragile this part of the patch could be dropped.

 arch/arm/mach-netx/xc.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-netx/xc.c b/arch/arm/mach-netx/xc.c
index e4cfb7e..18a98e0 100644
--- a/arch/arm/mach-netx/xc.c
+++ b/arch/arm/mach-netx/xc.c
@@ -149,16 +149,16 @@ int xc_request_firmware(struct xc *x)
x->type = head->type;
x->version = head->version;
 
-   ret = -EINVAL;
-
for (i = 0; i < 3; i++) {
src = fw->data + head->fw_desc[i].ofs;
dst = *(unsigned int *)src;
src += sizeof (unsigned int);
size = head->fw_desc[i].size - sizeof (unsigned int);
 
-   if (xc_check_ptr(x, dst, size))
+   if (xc_check_ptr(x, dst, size)) {
+   ret = -EINVAL;
goto exit_release_firmware;
+   }
 
memcpy((void *)io_p2v(dst), src, size);
 
@@ -169,8 +169,6 @@ int xc_request_firmware(struct xc *x)
goto exit_release_firmware;
}
 
-   ret = 0;
-
   exit_release_firmware:
release_firmware(fw);
 

--
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 0/6] ensure a consistent return value in error case

[Julia Lawall]

Typically, the return value desired for the failure of a function with an
integer return value is a negative integer.  In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return variable within the loop.

The semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)

//
@r exists@
identifier ret;
position p;
constant C;
expression e1,e2,e3,e4;
@@

ret = -C
... when != ret = e1
when != ret += e1
when any
if@p (...)
{
  ... when != ret = e2
  when != ret + e2
  return ret;
}
... when any
if (\(ret != 0\|ret < 0\|ret > 0\) || ...)
{
  ...
  return ...;
}
... when != ret = e3
when != ret += e3
when any
if@p (...)
{
  ... when != ret = e4
  when != ret += e4
  return ret;
}

@@
identifier r.ret;
position r.p;
statement S;
@@

(
if@p (<+...ret...+>) S
|
*if@p (...) 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/

[GIT PULL] sound fixes for 3.5-rc7

[Takashi Iwai]

Linus,

The following changes since commit 8663ff75cdca0a66f808e124c5592735793926af:

  ALSA: hda - Fix no sound from ALC662 after Windows reboot (2012-06-29 
09:44:44 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-3.5

for you to fetch changes up to 68e67f40b7343383517c3f951b4b8db7626406bc:

  ALSA: snd-usb: move calls to usb_set_interface (2012-07-13 09:31:42 +0200)


Sound fixes for 3.5-rc7

Containing the regression fixes for USB-audio due to the transition to
the new streaming logic, mostly found on Logitech webcams.


Daniel Mack (1):
  ALSA: snd-usb: move calls to usb_set_interface

Takashi Iwai (1):
  ALSA: usb-audio: Fix the first PCM interface assignment

 sound/usb/endpoint.c |   73 +-
 sound/usb/pcm.c  |   61 -
 2 files changed, 43 insertions(+), 91 deletions(-)

diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
index e690690..0f647d2 100644
--- a/sound/usb/endpoint.c
+++ b/sound/usb/endpoint.c
@@ -414,7 +414,7 @@ struct snd_usb_endpoint *snd_usb_add_endpoint(struct 
snd_usb_audio *chip,
 {
struct list_head *p;
struct snd_usb_endpoint *ep;
-   int ret, is_playback = direction == SNDRV_PCM_STREAM_PLAYBACK;
+   int is_playback = direction == SNDRV_PCM_STREAM_PLAYBACK;
 
mutex_lock(&chip->mutex);
 
@@ -434,16 +434,6 @@ struct snd_usb_endpoint *snd_usb_add_endpoint(struct 
snd_usb_audio *chip,
type == SND_USB_ENDPOINT_TYPE_DATA ? "data" : "sync",
ep_num);
 
-   /* select the alt setting once so the endpoints become valid */
-   ret = usb_set_interface(chip->dev, alts->desc.bInterfaceNumber,
-   alts->desc.bAlternateSetting);
-   if (ret < 0) {
-   snd_printk(KERN_ERR "%s(): usb_set_interface() failed, ret = 
%d\n",
-   __func__, ret);
-   ep = NULL;
-   goto __exit_unlock;
-   }
-
ep = kzalloc(sizeof(*ep), GFP_KERNEL);
if (!ep)
goto __exit_unlock;
@@ -831,9 +821,6 @@ int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
if (++ep->use_count != 1)
return 0;
 
-   if (snd_BUG_ON(!test_bit(EP_FLAG_ACTIVATED, &ep->flags)))
-   return -EINVAL;
-
/* just to be sure */
deactivate_urbs(ep, 0, 1);
wait_clear_urbs(ep);
@@ -911,9 +898,6 @@ void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
if (snd_BUG_ON(ep->use_count == 0))
return;
 
-   if (snd_BUG_ON(!test_bit(EP_FLAG_ACTIVATED, &ep->flags)))
-   return;
-
if (--ep->use_count == 0) {
deactivate_urbs(ep, force, can_sleep);
ep->data_subs = NULL;
@@ -927,42 +911,6 @@ void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep,
 }
 
 /**
- * snd_usb_endpoint_activate: activate an snd_usb_endpoint
- *
- * @ep: the endpoint to activate
- *
- * If the endpoint is not currently in use, this functions will select the
- * correct alternate interface setting for the interface of this endpoint.
- *
- * In case of any active users, this functions does nothing.
- *
- * Returns an error if usb_set_interface() failed, 0 in all other
- * cases.
- */
-int snd_usb_endpoint_activate(struct snd_usb_endpoint *ep)
-{
-   if (ep->use_count != 0)
-   return 0;
-
-   if (!ep->chip->shutdown &&
-   !test_and_set_bit(EP_FLAG_ACTIVATED, &ep->flags)) {
-   int ret;
-
-   ret = usb_set_interface(ep->chip->dev, ep->iface, ep->alt_idx);
-   if (ret < 0) {
-   snd_printk(KERN_ERR "%s() usb_set_interface() failed, 
ret = %d\n",
-   __func__, ret);
-   clear_bit(EP_FLAG_ACTIVATED, &ep->flags);
-   return ret;
-   }
-
-   return 0;
-   }
-
-   return -EBUSY;
-}
-
-/**
  * snd_usb_endpoint_deactivate: deactivate an snd_usb_endpoint
  *
  * @ep: the endpoint to deactivate
@@ -980,24 +928,15 @@ int snd_usb_endpoint_deactivate(struct snd_usb_endpoint 
*ep)
if (!ep)
return -EINVAL;
 
+   deactivate_urbs(ep, 1, 1);
+   wait_clear_urbs(ep);
+
if (ep->use_count != 0)
return 0;
 
-   if (!ep->chip->shutdown &&
-   test_and_clear_bit(EP_FLAG_ACTIVATED, &ep->flags)) {
-   int ret;
-
-   ret = usb_set_interface(ep->chip->dev, ep->iface, 0);
-   if (ret < 0) {
-   snd_printk(KERN_ERR "%s(): usb_set_interface() failed, 
ret = %d\n",
-   __func__, ret);
-   retur

Re: [PATCH 2/3] vsyscall_64: allow SECCOMP_RET_TRACErs to skip

[Andrew Lutomirski]

On Sat, Jul 14, 2012 at 9:15 AM, Andrew Lutomirski  wrote:
> On Sat, Jul 14, 2012 at 8:57 AM, Will Drewry  wrote:
>> On Sat, Jul 14, 2012 at 10:50 AM, Will Drewry  wrote:
>>> On Sat, Jul 14, 2012 at 10:44 AM, Andrew Lutomirski  wrote:
 I think I'd prefer if changing to something other than whatever value is
 used to cancel the syscall resulted in a crash rather than just being
 ignored.
>>>
>>> I was trying to keep as much seccomp-ptrace behavior intact rather
>>> than making it terminal in this special case.  Is there a reason why
>>> it'd make more sense to crash?
>>
>> Unless you meant something the tracer could catch?  That may make
>> sense, but they could also use singlestep or whatever else to get
>> similar behavior.  But maybe I'm missing the bigger picture!
>
> I think it would be nice to not introduce any special behavior that
> things might rely on if we do this better in the future.  Similarly,
> for almost all purposes, a tracer could change gettimeofday to write,
> but there would be a silent behavior change if gettimeofday were
> entered via vsyscall.
>
> What's the standard way of skipping a syscall?  sigreturn?  (I don't
> know off the top of my head what sigreturn does.)  sys_ni_syscall?
> I'd be all for making those continue to work but making anything that
> can't be emulated correctly do something sufficiently unpleasant that
> people won't do it.  Is there a syscall that does nothing at all?

Here's my suggestion for now: any attempt by the seccomp filter to do
anything other than executing the syscall unchanged, skipping it
entirely, or killing results in a trap or sigsys with the syscall
number unchanged.

In the RET_TRACE case, the SIGSYS restarts at the mov nr,%rax
instruction.  The tracer can deal with it accordingly (via checking
the rip) -- if the tracer changes rax, it'll get changed right back by
the emulated mov nr,%rax.  If this results in an infinite loop, so be
it.

In the RET_TRAP case, do the same thing but via the special ptrace
event instead of SIGSYS.

This way, the special rip & ~0x0c00 == 0xff60 handling
becomes part of the ABI, but it looks like the mov instruction
trapped, which it more or less did.  If we want RET_TRAP to be able to
skip the syscall, let it happen the normal way.

This stuff probably barely matters.  For example, ptrace currently
doesn't work right when vsyscalls are being emulated.  No one appears
to care.

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

Re: [RFC][PATCH 14/26] sched, numa: Numa balancer

[Rik van Riel]

On 07/13/2012 10:45 AM, Don Morris wrote:


IIRC the test consisted of a 16GB NUMA system with two 8GB nodes.
It was running 3 KVM guests, two guests of 3GB memory each, and
one guest of 6GB each.


How many cpus per guest (host threads) and how many physical/logical
cpus per node on the host? Any comparisons with a situation where
the memory would fit within nodes but the scheduling load would
be too high?


IIRC this particular test was constructed to have guests
A and B fit in one NUMA node, with guest C in the other
NUMA node.

With schednuma, guest A ended up on one NUMA node, guest
B on the other, and guest C was spread between both nodes.

Only migrating when there is plenty of free space available
means you can end up not doing the right thing when running
a few large workloads on the system.

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

Re: [PATCH 2/3] vsyscall_64: allow SECCOMP_RET_TRACErs to skip

[Andrew Lutomirski]

On Sat, Jul 14, 2012 at 8:57 AM, Will Drewry  wrote:
> On Sat, Jul 14, 2012 at 10:50 AM, Will Drewry  wrote:
>> On Sat, Jul 14, 2012 at 10:44 AM, Andrew Lutomirski  wrote:
>>> I think I'd prefer if changing to something other than whatever value is
>>> used to cancel the syscall resulted in a crash rather than just being
>>> ignored.
>>
>> I was trying to keep as much seccomp-ptrace behavior intact rather
>> than making it terminal in this special case.  Is there a reason why
>> it'd make more sense to crash?
>
> Unless you meant something the tracer could catch?  That may make
> sense, but they could also use singlestep or whatever else to get
> similar behavior.  But maybe I'm missing the bigger picture!

I think it would be nice to not introduce any special behavior that
things might rely on if we do this better in the future.  Similarly,
for almost all purposes, a tracer could change gettimeofday to write,
but there would be a silent behavior change if gettimeofday were
entered via vsyscall.

What's the standard way of skipping a syscall?  sigreturn?  (I don't
know off the top of my head what sigreturn does.)  sys_ni_syscall?
I'd be all for making those continue to work but making anything that
can't be emulated correctly do something sufficiently unpleasant that
people won't do it.  Is there a syscall that does nothing at all?

I wish we could just increment rip by 7 and set a flag to allow the
vsyscall page instructions to be fully emulated until one of the ret
instructions happens, but I don't know how to do that without
monkeying with the entry assembly -- the do_page_fault path doesn't
look enough like system_call to pull it off easily.

In any case, can you change the docs to indicate that the special
behavior only happens iff rip & ~0x0c00 == 0xff60?  That
way a hypothetical future emulator could add better emulation
(incrementing rip by 7, for example) and everything would still work.
(There's no need to check the syscall number.)

FWIW, this crap is why I'm sort of tempted to say that seccomp should
just ignore vsyscalls entirely (except in mode 1).  None of them
actually do anything other than querying things that can be read out
of the vsyscall page (for the most part) without any kernel entry.
(Making *that* part of the ABI would be bad, though.)  Better ideas
are welcome.

--Andy
--
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/1 v1] leds: Add LED driver for lm3554 chip

[Bryan Wu]

On Sat, Jul 14, 2012 at 9:30 PM, G.Shark Jeong  wrote:
> From: "G.Shark Jeong" 
>
> LM3554 :
> The LM3554 is a 2 MHz fixed-frequency synchronous boost
> converter with 1.2A dual high side led drivers.
> Datasheet: www.ti.com
>

I agree with Shuah here. Could we work out an generic version for this
LM355x chip driver? I compared this leds-lm3554.c with leds-lm3556.c
and found the most differences are in register definition, but driver
flow and mechanism are all most the same. Please think about it and we
don't like duplicate code.

Thanks,
-Bryan

> Signed-off-by: G.Shark Jeong 
> ---
>  drivers/leds/Kconfig  |8 +
>  drivers/leds/Makefile |1 +
>  drivers/leds/leds-lm3554.c|  324 
> +
>  include/linux/platform_data/leds-lm3554.h |   66 ++
>  4 files changed, 399 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/leds/leds-lm3554.c
>  create mode 100644 include/linux/platform_data/leds-lm3554.h
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 12b2b55..ad54bc2 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -415,6 +415,14 @@ config LEDS_MAX8997
>   This option enables support for on-chip LED drivers on
>   MAXIM MAX8997 PMIC.
>
> +config LEDS_LM3554
> +   tristate "LED support for LM3554"
> +   depends on LEDS_CLASS && I2C
> +   select REGMAP_I2C
> +   help
> + This option enables support for LEDs connected to LM3554.
> + LM3554 includes Torch, Flash and Indicator functions.
> +
>  config LEDS_OT200
> tristate "LED support for the Bachmann OT200"
> depends on LEDS_CLASS && HAS_IOMEM
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index f8958cd..19903ed 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -47,6 +47,7 @@ obj-$(CONFIG_LEDS_NETXBIG)+= leds-netxbig.o
>  obj-$(CONFIG_LEDS_ASIC3)   += leds-asic3.o
>  obj-$(CONFIG_LEDS_RENESAS_TPU) += leds-renesas-tpu.o
>  obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
> +obj-$(CONFIG_LEDS_LM3554)  += leds-lm3554.o
>
>  # LED SPI Drivers
>  obj-$(CONFIG_LEDS_DAC124S085)  += leds-dac124s085.o
> diff --git a/drivers/leds/leds-lm3554.c b/drivers/leds/leds-lm3554.c
> new file mode 100644
> index 000..55461f1
> --- /dev/null
> +++ b/drivers/leds/leds-lm3554.c
> @@ -0,0 +1,324 @@
> +/*
> +* Simple driver for Texas Instruments LM3554 LED Flash driver chip
> +* Copyright (C) 2012 Texas Instruments
> +*
> +* This program is free software; you can redistribute it and/or modify
> +* it under the terms of the GNU General Public License version 2 as
> +* published by the Free Software Foundation.
> +*
> +*/
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define REG_TORCH  (0xA0)
> +#define REG_FLASH  (0xB0)
> +#define REG_FLASH_TIME (0xC0)
> +#define REG_FLAG   (0xD0)
> +#define REG_CONF1  (0xE0)
> +#define REG_CONF2  (0xF0)
> +#define REG_GPIO   (0x20)
> +#define REG_VIN_MON(0x80)
> +#define REG_MAXREG_VIN_MON
> +
> +enum lm3554_mode {
> +   MODE_SHDN = 0,
> +   MODE_INDIC,
> +   MODE_TORCH,
> +   MODE_FLASH,
> +   MODE_VOUT,
> +   MODE_VOUT_INDIC,
> +   MODE_VOUT_TORCH,
> +   MODE_VOUT_FLASH,
> +};
> +
> +struct lm3554_chip_data {
> +   struct device *dev;
> +
> +   struct led_classdev cdev_flash;
> +   struct led_classdev cdev_torch;
> +   struct led_classdev cdev_indicator;
> +
> +   struct lm3554_platform_data *pdata;
> +
> +   struct mutex lock;
> +   struct regmap *regmap;
> +   unsigned int last_flag;
> +};
> +
> +/* chip initialize */
> +static int __devinit lm3554_chip_init(struct lm3554_chip_data *chip)
> +{
> +   int ret;
> +   unsigned int reg_val;
> +   struct lm3554_platform_data *pdata = chip->pdata;
> +
> +   /* input and output pins configuration */
> +   reg_val = pdata->pin_strobe | pdata->pin_tx1
> +   | pdata->pin_tx2 | pdata->ledi_pin;
> +   ret = regmap_update_bits(chip->regmap, REG_CONF1, 0xAC, reg_val);
> +   if (ret < 0)
> +   goto out;
> +
> +   return ret;
> +out:
> +   dev_err(chip->dev, "%s:i2c access fail to register\n", __func__);
> +   return ret;
> +}
> +
> +/* chip control */
> +static void lm3554_control(struct lm3554_chip_data *chip,
> +  u8 brightness, enum lm3554_mode opmode)
> +{
> +   int ret;
> +   unsigned int reg_val;
> +   struct lm3554_platform_data *pdata = chip->pdata;
> +
> +   ret = regmap_read(chip->regmap, REG_FLAG, &chip->last_flag);
> +   if (ret < 0)
> +   goto out;
> +   if (chip->last_flag)
> +   dev_info(chip->dev, "LM3554 

Re: [PATCH 2/3] vsyscall_64: allow SECCOMP_RET_TRACErs to skip

[Will Drewry]

On Sat, Jul 14, 2012 at 10:50 AM, Will Drewry  wrote:
> On Sat, Jul 14, 2012 at 10:44 AM, Andrew Lutomirski  wrote:
>> I think I'd prefer if changing to something other than whatever value is
>> used to cancel the syscall resulted in a crash rather than just being
>> ignored.
>
> I was trying to keep as much seccomp-ptrace behavior intact rather
> than making it terminal in this special case.  Is there a reason why
> it'd make more sense to crash?

Unless you meant something the tracer could catch?  That may make
sense, but they could also use singlestep or whatever else to get
similar behavior.  But maybe I'm missing the bigger picture!

thanks!
will


>> How hard is it for a page fault to return into the syscall entry path?  It
>> should be possible to do this for rel, although it could be messy and not
>> worth it.
>
> Not sure, tbh. I think given vsyscall's status and the fact that
> ptrace+seccomp+vsyscall=emulate isn't horrible, I think it's fine to
> either ignore (what is in tree now) or to allow ptrace to skip,
> without providing full functionality.  But obviously, my view my be
> biased!
>
> thanks!
> will
>
>>
>> On Jul 14, 2012 10:35 AM, "Will Drewry"  wrote:
>>>
>>> Current quirky ptrace behavior with vsyscall and seccomp
>>> does not allow tracers to bypass the call.  This change
>>> provides that ability by checking if orig_ax changed.
>>>
>>> Signed-off-by: Will Drewry 
>>> ---
>>>  arch/x86/kernel/vsyscall_64.c |   10 +++---
>>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
>>> index 5db36ca..5f9640c 100644
>>> --- a/arch/x86/kernel/vsyscall_64.c
>>> +++ b/arch/x86/kernel/vsyscall_64.c
>>> @@ -142,11 +142,15 @@ static int addr_to_vsyscall_nr(unsigned long addr)
>>>  #ifdef CONFIG_SECCOMP
>>>  static int vsyscall_seccomp(struct task_struct *tsk, int syscall_nr)
>>>  {
>>> +   int ret;
>>> if (!seccomp_mode(&tsk->seccomp))
>>> return 0;
>>> task_pt_regs(tsk)->orig_ax = syscall_nr;
>>> task_pt_regs(tsk)->ax = syscall_nr;
>>> -   return __secure_computing(syscall_nr);
>>> +   ret = __secure_computing(syscall_nr);
>>> +   if (task_pt_regs(tsk)->orig_ax != syscall_nr)
>>> +   return 1; /* ptrace syscall skip */
>>> +   return ret;
>>>  }
>>>  #else
>>>  #define vsyscall_seccomp(_tsk, _nr) 0
>>> @@ -278,9 +282,9 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned
>>> long address)
>>> current_thread_info()->sig_on_uaccess_error =
>>> prev_sig_on_uaccess_error;
>>>
>>> if (skip) {
>>> -   if ((long)regs->ax <= 0L) /* seccomp errno emulation */
>>> +   if ((long)regs->ax <= 0L || skip == 1) /* seccomp
>>> errno/trace */
>>> goto do_ret;
>>> -   goto done; /* seccomp trace/trap */
>>> +   goto done; /* seccomp trap */
>>> }
>>>
>>> if (ret == -EFAULT) {
>>> --
>>> 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 2/3] vsyscall_64: allow SECCOMP_RET_TRACErs to skip

[Will Drewry]

On Sat, Jul 14, 2012 at 10:44 AM, Andrew Lutomirski  wrote:
> I think I'd prefer if changing to something other than whatever value is
> used to cancel the syscall resulted in a crash rather than just being
> ignored.

I was trying to keep as much seccomp-ptrace behavior intact rather
than making it terminal in this special case.  Is there a reason why
it'd make more sense to crash?

> How hard is it for a page fault to return into the syscall entry path?  It
> should be possible to do this for rel, although it could be messy and not
> worth it.

Not sure, tbh. I think given vsyscall's status and the fact that
ptrace+seccomp+vsyscall=emulate isn't horrible, I think it's fine to
either ignore (what is in tree now) or to allow ptrace to skip,
without providing full functionality.  But obviously, my view my be
biased!

thanks!
will

>
> On Jul 14, 2012 10:35 AM, "Will Drewry"  wrote:
>>
>> Current quirky ptrace behavior with vsyscall and seccomp
>> does not allow tracers to bypass the call.  This change
>> provides that ability by checking if orig_ax changed.
>>
>> Signed-off-by: Will Drewry 
>> ---
>>  arch/x86/kernel/vsyscall_64.c |   10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
>> index 5db36ca..5f9640c 100644
>> --- a/arch/x86/kernel/vsyscall_64.c
>> +++ b/arch/x86/kernel/vsyscall_64.c
>> @@ -142,11 +142,15 @@ static int addr_to_vsyscall_nr(unsigned long addr)
>>  #ifdef CONFIG_SECCOMP
>>  static int vsyscall_seccomp(struct task_struct *tsk, int syscall_nr)
>>  {
>> +   int ret;
>> if (!seccomp_mode(&tsk->seccomp))
>> return 0;
>> task_pt_regs(tsk)->orig_ax = syscall_nr;
>> task_pt_regs(tsk)->ax = syscall_nr;
>> -   return __secure_computing(syscall_nr);
>> +   ret = __secure_computing(syscall_nr);
>> +   if (task_pt_regs(tsk)->orig_ax != syscall_nr)
>> +   return 1; /* ptrace syscall skip */
>> +   return ret;
>>  }
>>  #else
>>  #define vsyscall_seccomp(_tsk, _nr) 0
>> @@ -278,9 +282,9 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned
>> long address)
>> current_thread_info()->sig_on_uaccess_error =
>> prev_sig_on_uaccess_error;
>>
>> if (skip) {
>> -   if ((long)regs->ax <= 0L) /* seccomp errno emulation */
>> +   if ((long)regs->ax <= 0L || skip == 1) /* seccomp
>> errno/trace */
>> goto do_ret;
>> -   goto done; /* seccomp trace/trap */
>> +   goto done; /* seccomp trap */
>> }
>>
>> if (ret == -EFAULT) {
>> --
>> 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 2/3] vsyscall_64: allow SECCOMP_RET_TRACErs to skip

[Will Drewry]

Current quirky ptrace behavior with vsyscall and seccomp
does not allow tracers to bypass the call.  This change
provides that ability by checking if orig_ax changed.

Signed-off-by: Will Drewry 
---
 arch/x86/kernel/vsyscall_64.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 5db36ca..5f9640c 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -142,11 +142,15 @@ static int addr_to_vsyscall_nr(unsigned long addr)
 #ifdef CONFIG_SECCOMP
 static int vsyscall_seccomp(struct task_struct *tsk, int syscall_nr)
 {
+   int ret;
if (!seccomp_mode(&tsk->seccomp))
return 0;
task_pt_regs(tsk)->orig_ax = syscall_nr;
task_pt_regs(tsk)->ax = syscall_nr;
-   return __secure_computing(syscall_nr);
+   ret = __secure_computing(syscall_nr);
+   if (task_pt_regs(tsk)->orig_ax != syscall_nr)
+   return 1; /* ptrace syscall skip */
+   return ret;
 }
 #else
 #define vsyscall_seccomp(_tsk, _nr) 0
@@ -278,9 +282,9 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long 
address)
current_thread_info()->sig_on_uaccess_error = prev_sig_on_uaccess_error;
 
if (skip) {
-   if ((long)regs->ax <= 0L) /* seccomp errno emulation */
+   if ((long)regs->ax <= 0L || skip == 1) /* seccomp errno/trace */
goto do_ret;
-   goto done; /* seccomp trace/trap */
+   goto done; /* seccomp trap */
}
 
if (ret == -EFAULT) {
-- 
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 3/3] Documentation: add a caveat for seccomp filter and vsyscall emulation

[Will Drewry]

With the addition of seccomp support to vsyscall emulation:
  http://permalink.gmane.org/gmane.linux.kernel/1327732
and the prior patch in this series.

Update the documentation to indicate quirky behaviors when the 'ip' is
in the vsyscall page and vsyscall emulation is in effect.

Signed-off-by: Will Drewry 
---
 Documentation/prctl/seccomp_filter.txt |   22 ++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/prctl/seccomp_filter.txt 
b/Documentation/prctl/seccomp_filter.txt
index 597c3c5..67ed88b 100644
--- a/Documentation/prctl/seccomp_filter.txt
+++ b/Documentation/prctl/seccomp_filter.txt
@@ -161,3 +161,25 @@ architecture supports both ptrace_event and seccomp, it 
will be able to
 support seccomp filter with minor fixup: SIGSYS support and seccomp return
 value checking.  Then it must just add CONFIG_HAVE_ARCH_SECCOMP_FILTER
 to its arch-specific Kconfig.
+
+
+Caveats
+---
+
+On x86-64 with vsyscall emulation enabled and while servicing a
+vsyscall-emulated system call:
+- A return value of SECCOMP_RET_TRAP will set a si_call_addr pointing to
+  the vsyscall entry for the given call and not the address after the
+  'syscall' instruction.  Any code which wants to restart the call
+  should return to that address and code wishing to return simulating
+  completion may either sigreturn normally or simulate a ret instruction
+  and use the return address from the stack.
+- A return value of SECCOMP_RET_TRACE will signal the tracer as usual,
+  but the syscall may not be changed to another system call using the
+  orig_rax register. It may only be changed to a different value in
+  order to skip the currently emulated call and any change will result
+  in that behavior.  The remainder of the registers may be altered as
+  usual.
+- Detection of this quirky behavior may be done by checking for getcpu,
+  time, or gettimeofday and if the si_call_addr or rip is in the
+  vsyscall page, specifically at the start of the specific entry call.
-- 
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 1/3] vsyscall_64: add missing ifdef CONFIG_SECCOMP

[Will Drewry]

vsyscall_seccomp introduced a dependency on __secure_computing.  On
configurations with CONFIG_SECCOMP disabled, compilation will fail.

Reported-by: feng xiangjun 
Signed-off-by: Will Drewry 
---
 arch/x86/kernel/vsyscall_64.c |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 08a18d0..5db36ca 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -139,6 +139,7 @@ static int addr_to_vsyscall_nr(unsigned long addr)
return nr;
 }
 
+#ifdef CONFIG_SECCOMP
 static int vsyscall_seccomp(struct task_struct *tsk, int syscall_nr)
 {
if (!seccomp_mode(&tsk->seccomp))
@@ -147,6 +148,9 @@ static int vsyscall_seccomp(struct task_struct *tsk, int 
syscall_nr)
task_pt_regs(tsk)->ax = syscall_nr;
return __secure_computing(syscall_nr);
 }
+#else
+#define vsyscall_seccomp(_tsk, _nr) 0
+#endif
 
 static bool write_ok_or_segv(unsigned long ptr, size_t size)
 {
-- 
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: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 on 3.5-rc6

[devendra.aaru]

On Sat, Jul 14, 2012 at 8:07 PM, richard -rw- weinberger
 wrote:
> On Sat, Jul 14, 2012 at 2:11 PM, devendra.aaru  
> wrote:
>> 3.5-rc6 with git head at fdb1335a82e. (from Torvald's branch)
>
> CC'in futex guys...
>
>> dmesg:
>>
>> [43610.535421] BUG: unable to handle kernel NULL pointer dereference
>> at 0010
>
> Is this the first error message in dmesg?
No its not. and i was doing a dmesg -c and run... thats bad i should
not be doing that..
> IOW no WARNING before the BUG?
yeah there were some warnings about the trinity.
>
> Looks like futex_wait_requeue_pi() was called before  pi_state->pi_mutex got
> initialized.
>

Let me reproduce it again... and i will report it with full dmesg again.
> --
> Thanks,
> //richard

Thanks,
Devendra.
--
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: Kernel boot hangs on commit "switch fput to task_work_add"

[Fengguang Wu]

On Sat, Jul 14, 2012 at 04:19:03PM +0100, Al Viro wrote:
> On Sat, Jul 14, 2012 at 10:34:59PM +0800, Fengguang Wu wrote:
> > On Sat, Jul 14, 2012 at 03:14:15PM +0100, Al Viro wrote:
> > > On Sat, Jul 14, 2012 at 09:58:49PM +0800, Fengguang Wu wrote:
> > > > > Hi Al, here I got the output for
> > > > > 
> > > > > (qemu) sendkey alt-sysrq-l
> > > > > (qemu) sendkey alt-sysrq-t
> > > > 
> > > > I repeated that several times and here are the results.
> > > > 
> > > > (qemu) sendkey alt-sysrq-l
> > > > (qemu) sendkey alt-sysrq-l
> > > > (qemu) sendkey alt-sysrq-l
> > > > (qemu) sendkey alt-sysrq-t
> > > > (qemu) sendkey alt-sysrq-t
> > > > (qemu) quit
> > > > 
> > > > The user space shutdown is polling on something, which prevents the
> > > > system from reboot..
> > > 
> > > Which userland it is?
> > 
> > It's a customized ubuntu core. The original tgz image is downloaded
> > here, however it's not directly usable as initrd.. Should I send my
> > hacked one?
> 
> Sigh...  FWIW, with your config neither the mainline nor the tree you'd
> been testing manage to boot with .deb produced by squeeze make-kpkg.
> Both in the same way - they get to busybox, mount(8) in there keeps
> failing wiht -ENODEV all the time and the damn thing ends up in
> busybox shell.  Fsck knows what's going on - apparently the damn thing
> also redirects all printks someplace invisible as soon as it gets to
> userland, so the obvious ways to see what's going on do not work.
> RTFS(busybox) time, I guess...
> 
> With reasonably sane config both trees work fine.  I'll grab your image
> and see what happens with it.

Err, sorry for that! This is some weird randconfig setup, after all...
I've sent you my hacked initrd in a big email, hope you can receive it.
As I already have the reproduce environment, I can help debug it, too.

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: Kernel boot hangs on commit "switch fput to task_work_add"

[Al Viro]

On Sat, Jul 14, 2012 at 10:34:59PM +0800, Fengguang Wu wrote:
> On Sat, Jul 14, 2012 at 03:14:15PM +0100, Al Viro wrote:
> > On Sat, Jul 14, 2012 at 09:58:49PM +0800, Fengguang Wu wrote:
> > > > Hi Al, here I got the output for
> > > > 
> > > > (qemu) sendkey alt-sysrq-l
> > > > (qemu) sendkey alt-sysrq-t
> > > 
> > > I repeated that several times and here are the results.
> > > 
> > > (qemu) sendkey alt-sysrq-l
> > > (qemu) sendkey alt-sysrq-l
> > > (qemu) sendkey alt-sysrq-l
> > > (qemu) sendkey alt-sysrq-t
> > > (qemu) sendkey alt-sysrq-t
> > > (qemu) quit
> > > 
> > > The user space shutdown is polling on something, which prevents the
> > > system from reboot..
> > 
> > Which userland it is?
> 
> It's a customized ubuntu core. The original tgz image is downloaded
> here, however it's not directly usable as initrd.. Should I send my
> hacked one?

Sigh...  FWIW, with your config neither the mainline nor the tree you'd
been testing manage to boot with .deb produced by squeeze make-kpkg.
Both in the same way - they get to busybox, mount(8) in there keeps
failing wiht -ENODEV all the time and the damn thing ends up in
busybox shell.  Fsck knows what's going on - apparently the damn thing
also redirects all printks someplace invisible as soon as it gets to
userland, so the obvious ways to see what's going on do not work.
RTFS(busybox) time, I guess...

With reasonably sane config both trees work fine.  I'll grab your image
and see what happens with it.
--
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: PROBLEM: Silent data corruption when using sendfile()

[Willy Tarreau]

On Sat, Jul 14, 2012 at 04:19:00PM +0200, Eric Dumazet wrote:
> On Sat, 2012-07-14 at 22:08 +0800, Hillf Danton wrote:
> > On Sat, Jul 14, 2012 at 4:20 PM, Eric Dumazet  
> > wrote:
> > >
> > > Might be, or not (could be a NIC bug)
> > >
> > Dunno why sendfile sits in the layer of NIC and
> > how they interact.
> 
> sendfile() relies heavily on TSO capabilities, a buggy NIC could
> corrupt frame content on some obscure occasions.
> 
> We had some known cases on IPv6 for example.

Similarly I remind having experienced bugs on early Yukon chips years
ago that would regularly emit total crap on the wire.

Willy

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

Re: Kernel boot hangs on commit "switch fput to task_work_add"

[Fengguang Wu]

On Sat, Jul 14, 2012 at 03:14:15PM +0100, Al Viro wrote:
> On Sat, Jul 14, 2012 at 09:58:49PM +0800, Fengguang Wu wrote:
> > > Hi Al, here I got the output for
> > > 
> > > (qemu) sendkey alt-sysrq-l
> > > (qemu) sendkey alt-sysrq-t
> > 
> > I repeated that several times and here are the results.
> > 
> > (qemu) sendkey alt-sysrq-l
> > (qemu) sendkey alt-sysrq-l
> > (qemu) sendkey alt-sysrq-l
> > (qemu) sendkey alt-sysrq-t
> > (qemu) sendkey alt-sysrq-t
> > (qemu) quit
> > 
> > The user space shutdown is polling on something, which prevents the
> > system from reboot..
> 
> Which userland it is?

It's a customized ubuntu core. The original tgz image is downloaded
here, however it's not directly usable as initrd.. Should I send my
hacked one?

24M quantal-core-x86_64.cgz

http://cdimage.ubuntu.com/ubuntu-core/releases/quantal/alpha-2/

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: [PATCH] x86, amd: rename vmmu support capability

[Davidlohr Bueso]

On Sat, 2012-07-14 at 15:38 +0200, H. Peter Anvin wrote:
> Yep, NAK on this one.

Ok, we could at least add a comment when defining X86_FEATURE_NPT.

Thanks,
Davidlohr

> 
> Borislav Petkov  wrote:
> 
> >On Fri, Jul 13, 2012 at 08:02:55PM +0200, Davidlohr Bueso wrote:
> >> From: Davidlohr Bueso 
> >> 
> >> AMD has renamed nested page table technology to rapid virtualization
> >indexing,
> >> reflect this change in the kernel.
> >> 
> >> Signed-off-by: Davidlohr Bueso 
> >
> >You know that /proc/cpuinfo is a userspace ABI, right?
> >
> >And are you sure nothing is using that string -
> >"npt" - since it got added almost three years ago by
> >414bb144efa2d2fe16d104d836d0d6b6e9265788?
> >
> >-- 
> >Regards/Gruss,
> >Boris.
> 


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

Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 on 3.5-rc6

[richard -rw- weinberger]

On Sat, Jul 14, 2012 at 2:11 PM, devendra.aaru  wrote:
> 3.5-rc6 with git head at fdb1335a82e. (from Torvald's branch)

CC'in futex guys...

> dmesg:
>
> [43610.535421] BUG: unable to handle kernel NULL pointer dereference
> at 0010

Is this the first error message in dmesg?
IOW no WARNING before the BUG?

Looks like futex_wait_requeue_pi() was called before  pi_state->pi_mutex got
initialized.

-- 
Thanks,
//richard
--
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: PROBLEM: Silent data corruption when using sendfile()

[Eric Dumazet]

On Sat, 2012-07-14 at 22:08 +0800, Hillf Danton wrote:
> On Sat, Jul 14, 2012 at 4:20 PM, Eric Dumazet  wrote:
> >
> > Might be, or not (could be a NIC bug)
> >
> Dunno why sendfile sits in the layer of NIC and
> how they interact.

sendfile() relies heavily on TSO capabilities, a buggy NIC could
corrupt frame content on some obscure occasions.

We had some known cases on IPv6 for example.


--
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: Kernel boot hangs on commit "switch fput to task_work_add"

[Al Viro]

On Sat, Jul 14, 2012 at 09:58:49PM +0800, Fengguang Wu wrote:
> > Hi Al, here I got the output for
> > 
> > (qemu) sendkey alt-sysrq-l
> > (qemu) sendkey alt-sysrq-t
> 
> I repeated that several times and here are the results.
> 
> (qemu) sendkey alt-sysrq-l
> (qemu) sendkey alt-sysrq-l
> (qemu) sendkey alt-sysrq-l
> (qemu) sendkey alt-sysrq-t
> (qemu) sendkey alt-sysrq-t
> (qemu) quit
> 
> The user space shutdown is polling on something, which prevents the
> system from reboot..

Which userland it is?
--
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: PROBLEM: Silent data corruption when using sendfile()

[Hillf Danton]

On Sat, Jul 14, 2012 at 4:20 PM, Eric Dumazet  wrote:
>
> Might be, or not (could be a NIC bug)
>
Dunno why sendfile sits in the layer of NIC and
how they interact.
--
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 3/3] x86/mm: Separate paging setup from memory mapping

[Pekka Enberg]

Move PSE and PGE bit twiddling from init_memory_mapping() to a new
setup_paging() function to simplify the former function. The
init_memory_mapping() function is called later in the boot process by
gart_iommu_init(), efi_ioremap(), and arch_add_memory() which have no
business whatsover updating the CR4 register.

Cc: Tejun Heo 
Cc: Yinghai Lu 
Signed-off-by: Pekka Enberg 
---
 arch/x86/include/asm/page_types.h |2 ++
 arch/x86/kernel/setup.c   |2 ++
 arch/x86/mm/init.c|   23 +--
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/page_types.h 
b/arch/x86/include/asm/page_types.h
index e21fdd1..529905e 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -51,6 +51,8 @@ static inline phys_addr_t get_max_mapped(void)
return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
 }
 
+extern void setup_paging(void);
+
 extern unsigned long init_memory_mapping(unsigned long start,
 unsigned long end);
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 16be6dc..a883978 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -913,6 +913,8 @@ void __init setup_arch(char **cmdline_p)
 
init_gbpages();
 
+   setup_paging();
+
/* max_pfn_mapped is updated here */
max_low_pfn_mapped = init_memory_mapping(0, max_low_pfn<> PUD_SHIFT) << (PUD_SHIFT - PAGE_SHIFT);
 }
 
+void setup_paging(void)
+{
+   /* Enable PSE if available */
+   if (cpu_has_pse)
+   set_in_cr4(X86_CR4_PSE);
+
+   /* Enable PGE if available */
+   if (cpu_has_pge) {
+   set_in_cr4(X86_CR4_PGE);
+   __supported_pte_mask |= _PAGE_GLOBAL;
+   }
+}
+
 /*
  * Setup the direct mapping of the physical memory at PAGE_OFFSET.
  * This runs before bootmem is initialized and gets pages directly from
@@ -159,16 +172,6 @@ unsigned long __init_refok init_memory_mapping(unsigned 
long start,
use_gbpages = direct_gbpages;
 #endif
 
-   /* Enable PSE if available */
-   if (cpu_has_pse)
-   set_in_cr4(X86_CR4_PSE);
-
-   /* Enable PGE if available */
-   if (cpu_has_pge) {
-   set_in_cr4(X86_CR4_PGE);
-   __supported_pte_mask |= _PAGE_GLOBAL;
-   }
-
if (use_gbpages)
page_size_mask |= 1 << PG_LEVEL_1G;
if (use_pse)
-- 
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/

[PATCH 2/3] x86/mm: Simplify for-loop in free_init_pages()

[Pekka Enberg]

As a cleanup, move initial "addr" assignment to the for-loop construct
in free_init_pages().

Cc: Tejun Heo 
Cc: Yinghai Lu 
Signed-off-by: Pekka Enberg 
---
 arch/x86/mm/init.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 9eb53c2..e270f94 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -349,8 +349,6 @@ void free_init_pages(char *what, unsigned long begin, 
unsigned long end)
if (begin >= end)
return;
 
-   addr = begin;
-
/*
 * If debugging page accesses then do not free this memory but
 * mark them not present - any buggy init-section access will
@@ -371,7 +369,7 @@ void free_init_pages(char *what, unsigned long begin, 
unsigned long end)
 
printk(KERN_INFO "Freeing %s: %luk freed\n", what, (end - begin) >> 10);
 
-   for (; addr < end; addr += PAGE_SIZE) {
+   for (addr = begin; addr < end; addr += PAGE_SIZE) {
ClearPageReserved(virt_to_page(addr));
init_page_count(virt_to_page(addr));
memset((void *)addr, POISON_FREE_INITMEM, PAGE_SIZE);
-- 
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/

[PATCH 1/3] x86/mm: Simplify memory mapping PFN calculation

[Pekka Enberg]

Introduce two new helper functions, addr_to_pmd_pfn() and
addr_to_pud_pfn(), to simplify init_memory_mapping() code flow.

Cc: Tejun Heo 
Cc: Yinghai Lu 
Signed-off-by: Pekka Enberg 
---
 arch/x86/mm/init.c |   38 +-
 1 files changed, 21 insertions(+), 17 deletions(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index bc4e9d8..9eb53c2 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -117,6 +117,16 @@ static int __meminit save_mr(struct map_range *mr, int 
nr_range,
return nr_range;
 }
 
+static unsigned long addr_to_pmd_pfn(unsigned long addr)
+{
+   return (addr >> PMD_SHIFT) << (PMD_SHIFT - PAGE_SHIFT);
+}
+
+static unsigned long addr_to_pud_pfn(unsigned long addr)
+{
+   return (addr >> PUD_SHIFT) << (PUD_SHIFT - PAGE_SHIFT);
+}
+
 /*
  * Setup the direct mapping of the physical memory at PAGE_OFFSET.
  * This runs before bootmem is initialized and gets pages directly from
@@ -180,11 +190,9 @@ unsigned long __init_refok init_memory_mapping(unsigned 
long start,
if (pos == 0)
end_pfn = 1<<(PMD_SHIFT - PAGE_SHIFT);
else
-   end_pfn = ((pos + (PMD_SIZE - 1))>>PMD_SHIFT)
-<< (PMD_SHIFT - PAGE_SHIFT);
+   end_pfn = addr_to_pmd_pfn(pos + (PMD_SIZE - 1));
 #else /* CONFIG_X86_64 */
-   end_pfn = ((pos + (PMD_SIZE - 1)) >> PMD_SHIFT)
-   << (PMD_SHIFT - PAGE_SHIFT);
+   end_pfn = addr_to_pmd_pfn(pos + (PMD_SIZE - 1));
 #endif
if (end_pfn > (end >> PAGE_SHIFT))
end_pfn = end >> PAGE_SHIFT;
@@ -194,15 +202,13 @@ unsigned long __init_refok init_memory_mapping(unsigned 
long start,
}
 
/* big page (2M) range */
-   start_pfn = ((pos + (PMD_SIZE - 1))>>PMD_SHIFT)
-<< (PMD_SHIFT - PAGE_SHIFT);
+   start_pfn = addr_to_pmd_pfn(pos + (PMD_SIZE - 1));
 #ifdef CONFIG_X86_32
-   end_pfn = (end>>PMD_SHIFT) << (PMD_SHIFT - PAGE_SHIFT);
+   end_pfn = addr_to_pmd_pfn(end);
 #else /* CONFIG_X86_64 */
-   end_pfn = ((pos + (PUD_SIZE - 1))>>PUD_SHIFT)
-<< (PUD_SHIFT - PAGE_SHIFT);
-   if (end_pfn > ((end>>PMD_SHIFT)<<(PMD_SHIFT - PAGE_SHIFT)))
-   end_pfn = ((end>>PMD_SHIFT)<<(PMD_SHIFT - PAGE_SHIFT));
+   end_pfn = addr_to_pud_pfn(pos + (PUD_SIZE - 1));
+   if (end_pfn > addr_to_pmd_pfn(end))
+   end_pfn = addr_to_pmd_pfn(end);
 #endif
 
if (start_pfn < end_pfn) {
@@ -213,9 +219,8 @@ unsigned long __init_refok init_memory_mapping(unsigned 
long start,
 
 #ifdef CONFIG_X86_64
/* big page (1G) range */
-   start_pfn = ((pos + (PUD_SIZE - 1))>>PUD_SHIFT)
-<< (PUD_SHIFT - PAGE_SHIFT);
-   end_pfn = (end >> PUD_SHIFT) << (PUD_SHIFT - PAGE_SHIFT);
+   start_pfn = addr_to_pud_pfn(pos + (PUD_SIZE - 1));
+   end_pfn = addr_to_pud_pfn(end);
if (start_pfn < end_pfn) {
nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
page_size_mask &
@@ -224,9 +229,8 @@ unsigned long __init_refok init_memory_mapping(unsigned 
long start,
}
 
/* tail is not big page (1G) alignment */
-   start_pfn = ((pos + (PMD_SIZE - 1))>>PMD_SHIFT)
-<< (PMD_SHIFT - PAGE_SHIFT);
-   end_pfn = (end >> PMD_SHIFT) << (PMD_SHIFT - PAGE_SHIFT);
+   start_pfn = addr_to_pmd_pfn(pos + (PMD_SIZE - 1));
+   end_pfn = addr_to_pmd_pfn(end);
if (start_pfn < end_pfn) {
nr_range = save_mr(mr, nr_range, start_pfn, end_pfn,
page_size_mask & (1