* Re: [PATCH 1/2] asciidoctor: fix user-manual to be built by `asciidoctor`
From: Jeff King @ 2017-01-04 8:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, 마누엘, Junio C Hamano
In-Reply-To: <3c160f81a88cf8697f2459bb7f2a3e27fb3e469c.1483373021.git.johannes.schindelin@gmx.de>
On Mon, Jan 02, 2017 at 05:03:57PM +0100, Johannes Schindelin wrote:
> From: =?UTF-8?q?=EB=A7=88=EB=88=84=EC=97=98?= <nalla@hamal.uberspace.de>
>
> The `user-manual.txt` is designed as a `book` but the `Makefile` wants
> to build it as an `article`. This seems to be a problem when building
> the documentation with `asciidoctor`. Furthermore the parts *Git
> Glossary* and *Appendix B* had no subsections which is not allowed when
> building with `asciidoctor`. So lets add a *dummy* section.
The git-scm.com site uses asciidoctor, too, and I think I have seen some
oddness with the rendering though. So in general I am in favor of making
things work under both asciidoc and asciidoctor.
I diffed the results of "make user-manual.html" before and after this
patch. A lot of "h3" chapter titles get bumped to "h2", which is OK. The
chapter titles now say "Chapter 1. Repositories and Branches" rather
than just "Repositories and Branches". Likewise, references now say
Chapter 1, _Repositories and Branches_
rather than:
the section called "Repositories and Branches".
which is probably OK, though the whole thing is short enough that
calling the sections chapters feels a bit over-important. Chapters now
get their own table of contents, too. This is especially silly in
one-section chapters like "Git Glossary".
So I dunno. I really do think "article" is conceptually the most
appropriate style, but I agree that there are some book-like things
(like appendices).
-Peff
^ permalink raw reply
* Re: [KERNEL] Re: Bug 4.9 and memorymanagement
From: Michal Hocko @ 2017-01-04 8:06 UTC (permalink / raw)
To: Klaus Ethgen; +Cc: linux-kernel, linux-mm
In-Reply-To: <20161230172358.GA4266@dhcp22.suse.cz>
On Fri 30-12-16 18:23:58, Michal Hocko wrote:
> On Fri 30-12-16 17:52:30, Klaus Ethgen wrote:
> > Sorry, did reply only you..
> >
> > Am Fr den 30. Dez 2016 um 12:11 schrieb Michal Hocko:
> > > > If this turns out to be memory cgroup related then the patch from
> > > > http://lkml.kernel.org/r/20161226124839.GB20715@dhcp22.suse.cz might
> > > > help.
> > >
> > > Did you get chance to test the above patch? I would like to send it for
> > > merging and having it tested on another system would be really helpeful
> > > and much appreciated.
> >
> > Sorry, no, I was a bit busy when coming back from X-mass. ;-)
> >
> > Maybe I can do so today.
> >
> > The only think is, how can I find out if the bug is fixed? Is 7 days
> > enough? Or is there a change to force the bug to happen (or not)...?
>
> Just try to run with the patch and do what you do normally. If you do
> not see any OOMs in few days it should be sufficient evidence. From your
> previous logs it seems you hit the problem quite early after few hours
> as far as I remember.
Did you have chance to run with the patch? I would like to post it for
inclusion and feedback from you is really useful.
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [KERNEL] Re: Bug 4.9 and memorymanagement
From: Michal Hocko @ 2017-01-04 8:06 UTC (permalink / raw)
To: Klaus Ethgen; +Cc: linux-kernel, linux-mm
In-Reply-To: <20161230172358.GA4266@dhcp22.suse.cz>
On Fri 30-12-16 18:23:58, Michal Hocko wrote:
> On Fri 30-12-16 17:52:30, Klaus Ethgen wrote:
> > Sorry, did reply only you..
> >
> > Am Fr den 30. Dez 2016 um 12:11 schrieb Michal Hocko:
> > > > If this turns out to be memory cgroup related then the patch from
> > > > http://lkml.kernel.org/r/20161226124839.GB20715@dhcp22.suse.cz might
> > > > help.
> > >
> > > Did you get chance to test the above patch? I would like to send it for
> > > merging and having it tested on another system would be really helpeful
> > > and much appreciated.
> >
> > Sorry, no, I was a bit busy when coming back from X-mass. ;-)
> >
> > Maybe I can do so today.
> >
> > The only think is, how can I find out if the bug is fixed? Is 7 days
> > enough? Or is there a change to force the bug to happen (or not)...?
>
> Just try to run with the patch and do what you do normally. If you do
> not see any OOMs in few days it should be sufficient evidence. From your
> previous logs it seems you hit the problem quite early after few hours
> as far as I remember.
Did you have chance to run with the patch? I would like to post it for
inclusion and feedback from you is really useful.
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v4 1/2] net/vhost: create datagram sockets immediately
From: Yuanhan Liu @ 2017-01-04 8:06 UTC (permalink / raw)
To: Charles (Chas) Williams; +Cc: dev, mtetsuyah, stable
In-Reply-To: <1483460563-5003-1-git-send-email-ciwillia@brocade.com>
On Tue, Jan 03, 2017 at 11:22:42AM -0500, Charles (Chas) Williams wrote:
> If you create a vhost server device, it doesn't create the actual datagram
> socket until you call .dev_start(). If you call .dev_stop() is also
> deletes those sockets. For QEMU clients, this is a problem since QEMU
> doesn't know how to re-attach to datagram sockets that have gone away.
>
> To fix this, register and unregister the datagram sockets during device
> creation and removal.
>
> Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
Both patches applied to dpdk-next-virtio. Thanks!
Note that we prefer a title of "prefix: fix ..." for bug fixing patch.
For this reason, I have changed the title for you while apply:
net/vhost: fix socket file being deleted on dev stop
Also, stable is cc'ed.
--yliu
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/2] vmxnet3: VMStatify rx/tx q_descr and int_state
From: Dmitry Fleytman @ 2017-01-04 8:02 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: Qemu Developers, Juan Quintela, amit.shah
In-Reply-To: <20170103194014.GH2340@work-vm>
> On 3 Jan 2017, at 21:40 PM, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote:
>
> * Dmitry Fleytman (dmitry@daynix.com <mailto:dmitry@daynix.com>) wrote:
>>>
>>> On 16 Dec 2016, at 14:19 PM, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote:
>>>
>>> * Dr. David Alan Gilbert (git) (dgilbert@redhat.com) wrote:
>>>> From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
>>>>
>>>> Fairly simple mechanical conversion of all fields.
>>>>
>>>> TODO!!!!
>>>> The problem is vmxnet3-ring size/cell_size/next are declared as size_t
>>>> but written as 32bit.
>>>
>>> Oops, I should have removed that warning in the commit message when
>>> I added the 1st patch in.
>>
>>
>>
>> Acked-by: Dmitry Fleytman <dmitry@daynix.com>
>
> Any reason for Acked-by rather than Reviewed-by ?
> Are you going to pull those?
Hi,
There is no specific reason, the patch is OK as for me.
Reviewed-by: Dmitry Fleytman <dmitry@daynix.com>
Jason, would you pick up this patch?
~Dmitry
>
> Dave
>
>>
>>>
>>> Dave
>>>
>>>> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>>>> ---
>>>> hw/net/vmxnet3.c | 272 ++++++++++++++++++-------------------------------------
>>>> 1 file changed, 90 insertions(+), 182 deletions(-)
>>>>
>>>> diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
>>>> index 7853174..4f7dbaf 100644
>>>> --- a/hw/net/vmxnet3.c
>>>> +++ b/hw/net/vmxnet3.c
>>>> @@ -2403,155 +2403,87 @@ static const VMStateDescription vmxstate_vmxnet3_mcast_list = {
>>>> }
>>>> };
>>>>
>>>> -static void vmxnet3_get_ring_from_file(QEMUFile *f, Vmxnet3Ring *r)
>>>> -{
>>>> - r->pa = qemu_get_be64(f);
>>>> - r->size = qemu_get_be32(f);
>>>> - r->cell_size = qemu_get_be32(f);
>>>> - r->next = qemu_get_be32(f);
>>>> - r->gen = qemu_get_byte(f);
>>>> -}
>>>> -
>>>> -static void vmxnet3_put_ring_to_file(QEMUFile *f, Vmxnet3Ring *r)
>>>> -{
>>>> - qemu_put_be64(f, r->pa);
>>>> - qemu_put_be32(f, r->size);
>>>> - qemu_put_be32(f, r->cell_size);
>>>> - qemu_put_be32(f, r->next);
>>>> - qemu_put_byte(f, r->gen);
>>>> -}
>>>> -
>>>> -static void vmxnet3_get_tx_stats_from_file(QEMUFile *f,
>>>> - struct UPT1_TxStats *tx_stat)
>>>> -{
>>>> - tx_stat->TSOPktsTxOK = qemu_get_be64(f);
>>>> - tx_stat->TSOBytesTxOK = qemu_get_be64(f);
>>>> - tx_stat->ucastPktsTxOK = qemu_get_be64(f);
>>>> - tx_stat->ucastBytesTxOK = qemu_get_be64(f);
>>>> - tx_stat->mcastPktsTxOK = qemu_get_be64(f);
>>>> - tx_stat->mcastBytesTxOK = qemu_get_be64(f);
>>>> - tx_stat->bcastPktsTxOK = qemu_get_be64(f);
>>>> - tx_stat->bcastBytesTxOK = qemu_get_be64(f);
>>>> - tx_stat->pktsTxError = qemu_get_be64(f);
>>>> - tx_stat->pktsTxDiscard = qemu_get_be64(f);
>>>> -}
>>>> -
>>>> -static void vmxnet3_put_tx_stats_to_file(QEMUFile *f,
>>>> - struct UPT1_TxStats *tx_stat)
>>>> -{
>>>> - qemu_put_be64(f, tx_stat->TSOPktsTxOK);
>>>> - qemu_put_be64(f, tx_stat->TSOBytesTxOK);
>>>> - qemu_put_be64(f, tx_stat->ucastPktsTxOK);
>>>> - qemu_put_be64(f, tx_stat->ucastBytesTxOK);
>>>> - qemu_put_be64(f, tx_stat->mcastPktsTxOK);
>>>> - qemu_put_be64(f, tx_stat->mcastBytesTxOK);
>>>> - qemu_put_be64(f, tx_stat->bcastPktsTxOK);
>>>> - qemu_put_be64(f, tx_stat->bcastBytesTxOK);
>>>> - qemu_put_be64(f, tx_stat->pktsTxError);
>>>> - qemu_put_be64(f, tx_stat->pktsTxDiscard);
>>>> -}
>>>> -
>>>> -static int vmxnet3_get_txq_descr(QEMUFile *f, void *pv, size_t size,
>>>> - VMStateField *field)
>>>> -{
>>>> - Vmxnet3TxqDescr *r = pv;
>>>> -
>>>> - vmxnet3_get_ring_from_file(f, &r->tx_ring);
>>>> - vmxnet3_get_ring_from_file(f, &r->comp_ring);
>>>> - r->intr_idx = qemu_get_byte(f);
>>>> - r->tx_stats_pa = qemu_get_be64(f);
>>>> -
>>>> - vmxnet3_get_tx_stats_from_file(f, &r->txq_stats);
>>>> -
>>>> - return 0;
>>>> -}
>>>> -
>>>> -static int vmxnet3_put_txq_descr(QEMUFile *f, void *pv, size_t size,
>>>> - VMStateField *field, QJSON *vmdesc)
>>>> -{
>>>> - Vmxnet3TxqDescr *r = pv;
>>>> -
>>>> - vmxnet3_put_ring_to_file(f, &r->tx_ring);
>>>> - vmxnet3_put_ring_to_file(f, &r->comp_ring);
>>>> - qemu_put_byte(f, r->intr_idx);
>>>> - qemu_put_be64(f, r->tx_stats_pa);
>>>> - vmxnet3_put_tx_stats_to_file(f, &r->txq_stats);
>>>> -
>>>> - return 0;
>>>> -}
>>>> -
>>>> -static const VMStateInfo txq_descr_info = {
>>>> - .name = "txq_descr",
>>>> - .get = vmxnet3_get_txq_descr,
>>>> - .put = vmxnet3_put_txq_descr
>>>> +static const VMStateDescription vmstate_vmxnet3_ring = {
>>>> + .name = "vmxnet3-ring",
>>>> + .version_id = 0,
>>>> + .fields = (VMStateField[]) {
>>>> + VMSTATE_UINT64(pa, Vmxnet3Ring),
>>>> + VMSTATE_UINT32(size, Vmxnet3Ring),
>>>> + VMSTATE_UINT32(cell_size, Vmxnet3Ring),
>>>> + VMSTATE_UINT32(next, Vmxnet3Ring),
>>>> + VMSTATE_UINT8(gen, Vmxnet3Ring),
>>>> + VMSTATE_END_OF_LIST()
>>>> + }
>>>> };
>>>>
>>>> -static void vmxnet3_get_rx_stats_from_file(QEMUFile *f,
>>>> - struct UPT1_RxStats *rx_stat)
>>>> -{
>>>> - rx_stat->LROPktsRxOK = qemu_get_be64(f);
>>>> - rx_stat->LROBytesRxOK = qemu_get_be64(f);
>>>> - rx_stat->ucastPktsRxOK = qemu_get_be64(f);
>>>> - rx_stat->ucastBytesRxOK = qemu_get_be64(f);
>>>> - rx_stat->mcastPktsRxOK = qemu_get_be64(f);
>>>> - rx_stat->mcastBytesRxOK = qemu_get_be64(f);
>>>> - rx_stat->bcastPktsRxOK = qemu_get_be64(f);
>>>> - rx_stat->bcastBytesRxOK = qemu_get_be64(f);
>>>> - rx_stat->pktsRxOutOfBuf = qemu_get_be64(f);
>>>> - rx_stat->pktsRxError = qemu_get_be64(f);
>>>> -}
>>>> -
>>>> -static void vmxnet3_put_rx_stats_to_file(QEMUFile *f,
>>>> - struct UPT1_RxStats *rx_stat)
>>>> -{
>>>> - qemu_put_be64(f, rx_stat->LROPktsRxOK);
>>>> - qemu_put_be64(f, rx_stat->LROBytesRxOK);
>>>> - qemu_put_be64(f, rx_stat->ucastPktsRxOK);
>>>> - qemu_put_be64(f, rx_stat->ucastBytesRxOK);
>>>> - qemu_put_be64(f, rx_stat->mcastPktsRxOK);
>>>> - qemu_put_be64(f, rx_stat->mcastBytesRxOK);
>>>> - qemu_put_be64(f, rx_stat->bcastPktsRxOK);
>>>> - qemu_put_be64(f, rx_stat->bcastBytesRxOK);
>>>> - qemu_put_be64(f, rx_stat->pktsRxOutOfBuf);
>>>> - qemu_put_be64(f, rx_stat->pktsRxError);
>>>> -}
>>>> -
>>>> -static int vmxnet3_get_rxq_descr(QEMUFile *f, void *pv, size_t size,
>>>> - VMStateField *field)
>>>> -{
>>>> - Vmxnet3RxqDescr *r = pv;
>>>> - int i;
>>>> -
>>>> - for (i = 0; i < VMXNET3_RX_RINGS_PER_QUEUE; i++) {
>>>> - vmxnet3_get_ring_from_file(f, &r->rx_ring[i]);
>>>> +static const VMStateDescription vmstate_vmxnet3_tx_stats = {
>>>> + .name = "vmxnet3-tx-stats",
>>>> + .version_id = 0,
>>>> + .fields = (VMStateField[]) {
>>>> + VMSTATE_UINT64(TSOPktsTxOK, struct UPT1_TxStats),
>>>> + VMSTATE_UINT64(TSOBytesTxOK, struct UPT1_TxStats),
>>>> + VMSTATE_UINT64(ucastPktsTxOK, struct UPT1_TxStats),
>>>> + VMSTATE_UINT64(ucastBytesTxOK, struct UPT1_TxStats),
>>>> + VMSTATE_UINT64(mcastPktsTxOK, struct UPT1_TxStats),
>>>> + VMSTATE_UINT64(mcastBytesTxOK, struct UPT1_TxStats),
>>>> + VMSTATE_UINT64(bcastPktsTxOK, struct UPT1_TxStats),
>>>> + VMSTATE_UINT64(bcastBytesTxOK, struct UPT1_TxStats),
>>>> + VMSTATE_UINT64(pktsTxError, struct UPT1_TxStats),
>>>> + VMSTATE_UINT64(pktsTxDiscard, struct UPT1_TxStats),
>>>> + VMSTATE_END_OF_LIST()
>>>> }
>>>> +};
>>>>
>>>> - vmxnet3_get_ring_from_file(f, &r->comp_ring);
>>>> - r->intr_idx = qemu_get_byte(f);
>>>> - r->rx_stats_pa = qemu_get_be64(f);
>>>> -
>>>> - vmxnet3_get_rx_stats_from_file(f, &r->rxq_stats);
>>>> -
>>>> - return 0;
>>>> -}
>>>> -
>>>> -static int vmxnet3_put_rxq_descr(QEMUFile *f, void *pv, size_t size,
>>>> - VMStateField *field, QJSON *vmdesc)
>>>> -{
>>>> - Vmxnet3RxqDescr *r = pv;
>>>> - int i;
>>>> -
>>>> - for (i = 0; i < VMXNET3_RX_RINGS_PER_QUEUE; i++) {
>>>> - vmxnet3_put_ring_to_file(f, &r->rx_ring[i]);
>>>> +static const VMStateDescription vmstate_vmxnet3_txq_descr = {
>>>> + .name = "vmxnet3-txq-descr",
>>>> + .version_id = 0,
>>>> + .fields = (VMStateField[]) {
>>>> + VMSTATE_STRUCT(tx_ring, Vmxnet3TxqDescr, 0, vmstate_vmxnet3_ring,
>>>> + Vmxnet3Ring),
>>>> + VMSTATE_STRUCT(comp_ring, Vmxnet3TxqDescr, 0, vmstate_vmxnet3_ring,
>>>> + Vmxnet3Ring),
>>>> + VMSTATE_UINT8(intr_idx, Vmxnet3TxqDescr),
>>>> + VMSTATE_UINT64(tx_stats_pa, Vmxnet3TxqDescr),
>>>> + VMSTATE_STRUCT(txq_stats, Vmxnet3TxqDescr, 0, vmstate_vmxnet3_tx_stats,
>>>> + struct UPT1_TxStats),
>>>> + VMSTATE_END_OF_LIST()
>>>> }
>>>> +};
>>>>
>>>> - vmxnet3_put_ring_to_file(f, &r->comp_ring);
>>>> - qemu_put_byte(f, r->intr_idx);
>>>> - qemu_put_be64(f, r->rx_stats_pa);
>>>> - vmxnet3_put_rx_stats_to_file(f, &r->rxq_stats);
>>>> +static const VMStateDescription vmstate_vmxnet3_rx_stats = {
>>>> + .name = "vmxnet3-rx-stats",
>>>> + .version_id = 0,
>>>> + .fields = (VMStateField[]) {
>>>> + VMSTATE_UINT64(LROPktsRxOK, struct UPT1_RxStats),
>>>> + VMSTATE_UINT64(LROBytesRxOK, struct UPT1_RxStats),
>>>> + VMSTATE_UINT64(ucastPktsRxOK, struct UPT1_RxStats),
>>>> + VMSTATE_UINT64(ucastBytesRxOK, struct UPT1_RxStats),
>>>> + VMSTATE_UINT64(mcastPktsRxOK, struct UPT1_RxStats),
>>>> + VMSTATE_UINT64(mcastBytesRxOK, struct UPT1_RxStats),
>>>> + VMSTATE_UINT64(bcastPktsRxOK, struct UPT1_RxStats),
>>>> + VMSTATE_UINT64(bcastBytesRxOK, struct UPT1_RxStats),
>>>> + VMSTATE_UINT64(pktsRxOutOfBuf, struct UPT1_RxStats),
>>>> + VMSTATE_UINT64(pktsRxError, struct UPT1_RxStats),
>>>> + VMSTATE_END_OF_LIST()
>>>> + }
>>>> +};
>>>>
>>>> - return 0;
>>>> -}
>>>> +static const VMStateDescription vmstate_vmxnet3_rxq_descr = {
>>>> + .name = "vmxnet3-rxq-descr",
>>>> + .version_id = 0,
>>>> + .fields = (VMStateField[]) {
>>>> + VMSTATE_STRUCT_ARRAY(rx_ring, Vmxnet3RxqDescr,
>>>> + VMXNET3_RX_RINGS_PER_QUEUE, 0,
>>>> + vmstate_vmxnet3_ring, Vmxnet3Ring),
>>>> + VMSTATE_STRUCT(comp_ring, Vmxnet3RxqDescr, 0, vmstate_vmxnet3_ring,
>>>> + Vmxnet3Ring),
>>>> + VMSTATE_UINT8(intr_idx, Vmxnet3RxqDescr),
>>>> + VMSTATE_UINT64(rx_stats_pa, Vmxnet3RxqDescr),
>>>> + VMSTATE_STRUCT(rxq_stats, Vmxnet3RxqDescr, 0, vmstate_vmxnet3_rx_stats,
>>>> + struct UPT1_RxStats),
>>>> + VMSTATE_END_OF_LIST()
>>>> + }
>>>> +};
>>>>
>>>> static int vmxnet3_post_load(void *opaque, int version_id)
>>>> {
>>>> @@ -2577,40 +2509,15 @@ static int vmxnet3_post_load(void *opaque, int version_id)
>>>> return 0;
>>>> }
>>>>
>>>> -static const VMStateInfo rxq_descr_info = {
>>>> - .name = "rxq_descr",
>>>> - .get = vmxnet3_get_rxq_descr,
>>>> - .put = vmxnet3_put_rxq_descr
>>>> -};
>>>> -
>>>> -static int vmxnet3_get_int_state(QEMUFile *f, void *pv, size_t size,
>>>> - VMStateField *field)
>>>> -{
>>>> - Vmxnet3IntState *r = pv;
>>>> -
>>>> - r->is_masked = qemu_get_byte(f);
>>>> - r->is_pending = qemu_get_byte(f);
>>>> - r->is_asserted = qemu_get_byte(f);
>>>> -
>>>> - return 0;
>>>> -}
>>>> -
>>>> -static int vmxnet3_put_int_state(QEMUFile *f, void *pv, size_t size,
>>>> - VMStateField *field, QJSON *vmdesc)
>>>> -{
>>>> - Vmxnet3IntState *r = pv;
>>>> -
>>>> - qemu_put_byte(f, r->is_masked);
>>>> - qemu_put_byte(f, r->is_pending);
>>>> - qemu_put_byte(f, r->is_asserted);
>>>> -
>>>> - return 0;
>>>> -}
>>>> -
>>>> -static const VMStateInfo int_state_info = {
>>>> - .name = "int_state",
>>>> - .get = vmxnet3_get_int_state,
>>>> - .put = vmxnet3_put_int_state
>>>> +static const VMStateDescription vmstate_vmxnet3_int_state = {
>>>> + .name = "vmxnet3-int-state",
>>>> + .version_id = 0,
>>>> + .fields = (VMStateField[]) {
>>>> + VMSTATE_BOOL(is_masked, Vmxnet3IntState),
>>>> + VMSTATE_BOOL(is_pending, Vmxnet3IntState),
>>>> + VMSTATE_BOOL(is_asserted, Vmxnet3IntState),
>>>> + VMSTATE_END_OF_LIST()
>>>> + }
>>>> };
>>>>
>>>> static bool vmxnet3_vmstate_need_pcie_device(void *opaque)
>>>> @@ -2667,14 +2574,15 @@ static const VMStateDescription vmstate_vmxnet3 = {
>>>> VMSTATE_UINT64(drv_shmem, VMXNET3State),
>>>> VMSTATE_UINT64(temp_shared_guest_driver_memory, VMXNET3State),
>>>>
>>>> - VMSTATE_ARRAY(txq_descr, VMXNET3State,
>>>> - VMXNET3_DEVICE_MAX_TX_QUEUES, 0, txq_descr_info,
>>>> + VMSTATE_STRUCT_ARRAY(txq_descr, VMXNET3State,
>>>> + VMXNET3_DEVICE_MAX_TX_QUEUES, 0, vmstate_vmxnet3_txq_descr,
>>>> Vmxnet3TxqDescr),
>>>> - VMSTATE_ARRAY(rxq_descr, VMXNET3State,
>>>> - VMXNET3_DEVICE_MAX_RX_QUEUES, 0, rxq_descr_info,
>>>> + VMSTATE_STRUCT_ARRAY(rxq_descr, VMXNET3State,
>>>> + VMXNET3_DEVICE_MAX_RX_QUEUES, 0, vmstate_vmxnet3_rxq_descr,
>>>> Vmxnet3RxqDescr),
>>>> - VMSTATE_ARRAY(interrupt_states, VMXNET3State, VMXNET3_MAX_INTRS,
>>>> - 0, int_state_info, Vmxnet3IntState),
>>>> + VMSTATE_STRUCT_ARRAY(interrupt_states, VMXNET3State,
>>>> + VMXNET3_MAX_INTRS, 0, vmstate_vmxnet3_int_state,
>>>> + Vmxnet3IntState),
>>>>
>>>> VMSTATE_END_OF_LIST()
>>>> },
>>>> --
>>>> 2.9.3
>>>>
>>>>
>>> --
>>> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>>
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com <mailto:dgilbert@redhat.com> / Manchester, UK
^ permalink raw reply
* Re: [PATCH v2 00/12] Partial Parity Log for MD RAID 5
From: Artur Paszkiewicz @ 2017-01-04 8:01 UTC (permalink / raw)
To: Jes Sorensen, Shaohua Li; +Cc: NeilBrown, linux-raid
In-Reply-To: <wrfjzij8ywtu.fsf@redhat.com>
On 01/03/2017 04:42 PM, Jes Sorensen wrote:
> Artur,
>
> Did you make any progress getting the alignment issue resolved?
>
> I'd really like to get an mdadm release out the door this week, so
> getting this resolved would be awesome. Hint hint ;)
Jes,
The alignment issue is fixed but I'm currently making changes in the
kernel part after comments from Neil. This also requires modifications
in mdadm, maybe even more than in the kernel. I need a few more days to
finish this, I'll be sending the next version of the patches probably
next week. So don't let me keep you if you want to make a release this
week.
Thanks,
Artur
^ permalink raw reply
* RE: [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface
From: Sricharan @ 2017-01-04 8:00 UTC (permalink / raw)
To: 'Lorenzo Pieralisi', iommu
Cc: 'Joerg Roedel', 'Will Deacon', linux-kernel,
'Matthias Brugger', 'Robin Murphy',
linux-arm-kernel, 'Marek Szyprowski'
In-Reply-To: <20170103173456.18154-1-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
>With the introduction of the new iommu_{register/get}_instance()
>interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT
>agnostic") (based on struct fwnode_handle as look-up token, so firmware
>agnostic) to register IOMMU instances with the core IOMMU layer there is
>no reason to keep the old OF based interface around any longer.
>
>Convert all the IOMMU drivers (and OF IOMMU core code) that rely on the
>of_iommu_{set/get}_ops() to the new kernel interface to register/retrieve
>IOMMU instances and remove the of_iommu_{set/get}_ops() remaining glue
>code in order to complete the interface rework.
>
>Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>Cc: Matthias Brugger <matthias.bgg@gmail.com>
>Cc: Will Deacon <will.deacon@arm.com>
>Cc: Robin Murphy <robin.murphy@arm.com>
>Cc: Joerg Roedel <joro@8bytes.org>
>Cc: Marek Szyprowski <m.szyprowski@samsung.com>
>---
>Exynos, msm and mtk code compile tested only owing to lack of
>test platforms, I would appreciate some help in testing this
>patch on those platforms before merging it even if it is just
>a simple interface conversion.
>
For msm,
Tested-by: Sricharan R <sricharan@codeaurora.org>
Regards,
Sricharan
^ permalink raw reply
* [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface
From: Sricharan @ 2017-01-04 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103173456.18154-1-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
>With the introduction of the new iommu_{register/get}_instance()
>interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT
>agnostic") (based on struct fwnode_handle as look-up token, so firmware
>agnostic) to register IOMMU instances with the core IOMMU layer there is
>no reason to keep the old OF based interface around any longer.
>
>Convert all the IOMMU drivers (and OF IOMMU core code) that rely on the
>of_iommu_{set/get}_ops() to the new kernel interface to register/retrieve
>IOMMU instances and remove the of_iommu_{set/get}_ops() remaining glue
>code in order to complete the interface rework.
>
>Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>Cc: Matthias Brugger <matthias.bgg@gmail.com>
>Cc: Will Deacon <will.deacon@arm.com>
>Cc: Robin Murphy <robin.murphy@arm.com>
>Cc: Joerg Roedel <joro@8bytes.org>
>Cc: Marek Szyprowski <m.szyprowski@samsung.com>
>---
>Exynos, msm and mtk code compile tested only owing to lack of
>test platforms, I would appreciate some help in testing this
>patch on those platforms before merging it even if it is just
>a simple interface conversion.
>
For msm,
Tested-by: Sricharan R <sricharan@codeaurora.org>
Regards,
Sricharan
^ permalink raw reply
* RE: [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface
From: Sricharan @ 2017-01-04 8:00 UTC (permalink / raw)
To: 'Lorenzo Pieralisi',
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
Cc: 'Will Deacon', linux-kernel-u79uwXL29TY76Z2rM5mHXA,
'Matthias Brugger',
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170103173456.18154-1-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
Hi Lorenzo,
>With the introduction of the new iommu_{register/get}_instance()
>interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT
>agnostic") (based on struct fwnode_handle as look-up token, so firmware
>agnostic) to register IOMMU instances with the core IOMMU layer there is
>no reason to keep the old OF based interface around any longer.
>
>Convert all the IOMMU drivers (and OF IOMMU core code) that rely on the
>of_iommu_{set/get}_ops() to the new kernel interface to register/retrieve
>IOMMU instances and remove the of_iommu_{set/get}_ops() remaining glue
>code in order to complete the interface rework.
>
>Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
>Cc: Matthias Brugger <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
>Cc: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>Cc: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
>Cc: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>---
>Exynos, msm and mtk code compile tested only owing to lack of
>test platforms, I would appreciate some help in testing this
>patch on those platforms before merging it even if it is just
>a simple interface conversion.
>
For msm,
Tested-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Regards,
Sricharan
^ permalink raw reply
* Re: [PATCH v6 01/14] ACPI: ARM64: IORT: minor cleanup for iort_match_node_callback()
From: Hanjun Guo @ 2017-01-04 7:56 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Marc Zyngier, Rafael J. Wysocki, linux-acpi, linux-arm-kernel,
linux-kernel, linuxarm, Thomas Gleixner, Greg KH, Tomasz Nowicki,
Ma Jun, Kefeng Wang, Agustin Vega-Frias, Sinan Kaya,
charles.garcia-tobin, huxinwei, yimin, Jon Masters
In-Reply-To: <20170103140839.GC7478@red-moon>
Hi Lorenzo,
On 2017/1/3 22:08, Lorenzo Pieralisi wrote:
> On Mon, Jan 02, 2017 at 09:31:32PM +0800, Hanjun Guo wrote:
>> Cleanup iort_match_node_callback() a little bit to reduce
>> some lines of code, aslo fix the indentation in iort_scan_node().
>
> s/aslo/also
>
> "Also" in a commit log is a sign a patch should be split and that's what
> you should do even though I know it is tempting to merge all trivial
> changes into one single patch.
>
> Make it two patches please.
Will do, thanks!
Do you have more comments regarding this patch set? I will
incorporate all the comments and send out a new version.
Thanks
Hanjun
^ permalink raw reply
* [PATCH v6 01/14] ACPI: ARM64: IORT: minor cleanup for iort_match_node_callback()
From: Hanjun Guo @ 2017-01-04 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103140839.GC7478@red-moon>
Hi Lorenzo,
On 2017/1/3 22:08, Lorenzo Pieralisi wrote:
> On Mon, Jan 02, 2017 at 09:31:32PM +0800, Hanjun Guo wrote:
>> Cleanup iort_match_node_callback() a little bit to reduce
>> some lines of code, aslo fix the indentation in iort_scan_node().
>
> s/aslo/also
>
> "Also" in a commit log is a sign a patch should be split and that's what
> you should do even though I know it is tempting to merge all trivial
> changes into one single patch.
>
> Make it two patches please.
Will do, thanks!
Do you have more comments regarding this patch set? I will
incorporate all the comments and send out a new version.
Thanks
Hanjun
^ permalink raw reply
* Re: [PATCH rdma-core 3/4] debian/copyright: Add copyright information
From: Leon Romanovsky @ 2017-01-04 7:55 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Talat Batheesh
In-Reply-To: <20170102221123.GA10226-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 534 bytes --]
On Mon, Jan 02, 2017 at 03:11:23PM -0700, Jason Gunthorpe wrote:
> On Sun, Jan 01, 2017 at 09:54:33AM +0200, Leon Romanovsky wrote:
>
> > > > +License: GPL-2+ or BSD
> > >
> > > I think this should just be 'BSD', same with all the 'or' stanzas.
> >
> > I'm not a lawyer and in the rdma-core.spec it is "or".
>
> The or is fine in other places, but this exact place is before the
> license text itself. The license text stanzas should not have 'or'
Pushed again, together with general cleanup of that license file.
Thanks
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] pathspec: give better message for submodule related pathspec error
From: Jeff King @ 2017-01-04 7:55 UTC (permalink / raw)
To: Stefan Beller; +Cc: gitster, git, bmwill
In-Reply-To: <20170104014835.22377-3-sbeller@google.com>
On Tue, Jan 03, 2017 at 05:48:35PM -0800, Stefan Beller wrote:
> Every once in a while someone complains to the mailing list to have
> run into this weird assertion[1]. The usual response from the mailing
> list is link to old discussions[2], and acknowledging the problem
> stating it is known.
>
> This patch accomplishes two things:
>
> 1. Switch assert() to die("BUG") to give a more readable message.
>
> 2. Take one of the cases where we hit a BUG and turn it into a normal
> "there was something wrong with the input" message.
As this last bit is quoted from me, I won't deny that it's brilliant as
usual.
But as this commit message needs to stand on its own, rather than as part of a
larger discussion thread, it might be worth expanding "one of the cases"
here. And talking about what's happening to the other cases.
Like:
This assertion triggered for cases where there wasn't a programming
bug, but just bogus input. In particular, if the user asks for a
pathspec that is inside a submodule, we shouldn't assert() or
die("BUG"); we should tell the user their request is bogus.
We'll retain the assertion for non-submodule cases, though. We don't
know of any cases that would trigger this, but it _would_ be
indicative of a programming error, and we should catch it here.
or something. Writing the first paragraph made me wonder if a better
solution, though, would be to catch and complain about this case
earlier. IOW, this _is_ a programming bug, because we're violating some
assumption of the pathspec code. And whatever is putting that item into
the pathspec list is what should be fixed.
I haven't looked closely enough to have a real opinion on that, though.
> diff --git a/pathspec.c b/pathspec.c
> index 22ca74a126..574a0bb158 100644
> --- a/pathspec.c
> +++ b/pathspec.c
> @@ -313,8 +313,28 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
> }
>
> /* sanity checks, pathspec matchers assume these are sane */
> - assert(item->nowildcard_len <= item->len &&
> - item->prefix <= item->len);
> + if (item->nowildcard_len > item->len ||
> + item->prefix > item->len) {
> + /* Historically this always was a submodule issue */
> + for (i = 0; i < active_nr; i++) {
> + struct cache_entry *ce = active_cache[i];
> + int len;
Given the discussion, this comment seems funny now. Who cares about
"historically"? It should probably be something like:
/*
* This case can be triggered by the user pointing us to a pathspec
* inside a submodule, which is an input error. Detect that here
* and complain, but fallback in the non-submodule case to a BUG,
* as we have no idea what would trigger that.
*/
-Peff
^ permalink raw reply
* [v1] misc: genwqe: card_base:-Release memory regions obtained by pci_request_mem_regions
From: Arvind Yadav @ 2017-01-04 7:46 UTC (permalink / raw)
To: haver, krisman; +Cc: linux-kernel
Free memory regions, if genwqe_bus_reset is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/misc/genwqe/card_base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/genwqe/card_base.c b/drivers/misc/genwqe/card_base.c
index 6c1f49a..a998d40 100644
--- a/drivers/misc/genwqe/card_base.c
+++ b/drivers/misc/genwqe/card_base.c
@@ -228,6 +228,7 @@ static int genwqe_bus_reset(struct genwqe_dev *cd)
if (cd->mmio == NULL) {
dev_err(&pci_dev->dev,
"[%s] err: mapping BAR0 failed\n", __func__);
+ pci_release_mem_regions(pci_dev);
return -ENOMEM;
}
return 0;
--
1.9.1
^ permalink raw reply related
* Re: [Qemu-devel] vhost-user breaks after 96a3d98.
From: Jason Wang @ 2017-01-04 7:52 UTC (permalink / raw)
To: Michael S. Tsirkin, Flavio Leitner; +Cc: qemu-devel
In-Reply-To: <007b2d16-56f6-a551-815a-527f6732fae7@redhat.com>
On 2017年01月04日 11:26, Jason Wang wrote:
>
>
> On 2017年01月04日 00:27, Michael S. Tsirkin wrote:
>> On Tue, Jan 03, 2017 at 06:28:18PM +0800, Jason Wang wrote:
>>>
>>> On 2017年01月03日 11:09, Jason Wang wrote:
>>>>
>>>> On 2016年12月30日 20:41, Flavio Leitner wrote:
>>>>> Hi,
>>>>>
>>>>> While I was testing vhost-user using OVS 2.5 and DPDK 2.2.0 in the
>>>>> host and testpmd dpdk 2.2.0 in the guest, I found that the commit
>>>>> below breaks the environment and no packets gets into the guest.
>>>>>
>>>>> dpdk port --> OVS --> vhost-user --> guest --> testpmd
>>>>> ^--- drops here ^--- no packets
>>>>> here.
>>>>>
>>>>> commit 96a3d98d2cdbd897ff5ab33427aa4cfb94077665
>>>>> Author: Jason Wang <jasowang@redhat.com>
>>>>> Date: Mon Aug 1 16:07:58 2016 +0800
>>>>>
>>>>> vhost: don't set vring call if no vector
>>>>> We used to set vring call fd unconditionally even if guest
>>>>> driver does
>>>>> not use MSIX for this vritqueue at all. This will cause lots of
>>>>> unnecessary userspace access and other checks for drivers does
>>>>> not use
>>>>> interrupt at all (e.g virtio-net pmd). So check and clean vring
>>>>> call
>>>>> fd if guest does not use any vector for this virtqueue at
>>>>> all.
>>>>> [...]
>>>>>
>>>>> Thanks,
>>>> Hi Flavio:
>>>>
>>>> Thanks for reporting this issue, could this be a bug of vhost-user? (I
>>>> believe virito-net pmd does not use interrupt for rx/tx at all)
>>>>
>>>> Anyway, will try to reproduce it.
>>>>
>>> Could not reproduce this issue on similar setups (the only
>>> difference is I
>>> don't create dpdk port) with dpdk 16.11 and ovs.git HEAD. Suspect an
>>> issue
>>> dpdk. Will try OVS 2.5 + DPDK 2.2.0.
>>>
>>> Thanks
>> Possibly dpdk assumed that call fd must be present unconditionally.
>> Limit this patch to when protocol is updated? add a new protocol flag?
>
> If this is a bug of dpdk, I tend to fix it (or just disable this patch
> for vhost-user). I'm not sure whether or not it's worthwhile to add a
> new protocol flag which was used to tell qemu that bug X was fixed.
>
> Thanks
>
>
Haven't tried but looking at vq_is_ready() in v2.2.0:
static int
vq_is_ready(struct vhost_virtqueue *vq)
{
return vq && vq->desc &&
vq->kickfd != -1 &&
vq->callfd != -1;
}
Which assumes callfd must be set which seems wrong. And this has been
fixed by
commit fb871d0a4dc1c038a381c524cdb86fe83d21d842
Author: Tetsuya Mukawa <mukawa@igel.co.jp>
Date: Mon Mar 14 17:53:32 2016 +0900
vhost: fix default value of kickfd and callfd
Currently, default values of kickfd and callfd are -1.
If the values are -1, current code guesses kickfd and callfd haven't
been initialized yet. Then vhost library will guess the virtqueue isn't
ready for processing.
But callfd and kickfd will be set as -1 when "--enable-kvm"
isn't specified in QEMU command line. It means we cannot treat -1 as
uninitialized state.
The patch defines -1 and -2 as VIRTIO_INVALID_EVENTFD and
VIRTIO_UNINITIALIZED_EVENTFD, and uses VIRTIO_UNINITIALIZED_EVENTFD for
the default values of kickfd and callfd.
Signed-off-by: Tetsuya Mukawa <mukawa@igel.co.jp>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Flavio, you could try to backport this to 2.2.0 to see if it fixes your
issue.
Thanks
^ permalink raw reply
* Re: [PATCH] btrfs: fix false enospc error when truncating heavily reflinked file
From: Qu Wenruo @ 2017-01-04 7:52 UTC (permalink / raw)
To: Wang Xiaoguang, linux-btrfs
In-Reply-To: <20160907121738.23713-1-wangxg.fnst@cn.fujitsu.com>
Hi,
Any comment on this patch?
Without it, btrfs will always fail for generic/387.
Thanks,
Qu
At 09/07/2016 08:17 PM, Wang Xiaoguang wrote:
> Below test script can reveal this bug:
> dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=100
> dev=$(losetup --show -f fs.img)
> mkdir -p /mnt/mntpoint
> mkfs.btrfs -f $dev
> mount $dev /mnt/mntpoint
> cd /mnt/mntpoint
>
> echo "workdir is: /mnt/mntpoint"
> blocksize=$((128 * 1024))
> dd if=/dev/zero of=testfile bs=$blocksize count=1
> sync
> count=$((17*1024*1024*1024/blocksize))
> echo "file size is:" $((count*blocksize))
> for ((i = 1; i <= $count; i++)); do
> dst_offset=$((blocksize * i))
> xfs_io -f -c "reflink testfile 0 $dst_offset $blocksize"\
> testfile > /dev/null
> done
> sync
> truncate --size 0 testfile
>
> The last truncate operation will fail for ENOSPC reason, but indeed
> it should not fail.
>
> In btrfs_truncate(), we use a temporary block_rsv to do truncate
> operation. With every btrfs_truncate_inode_items() call, we migrate space
> to this block_rsv, but forget to cleanup previous reservation, which
> will make this block_rsv's reserved bytes keep growing, and this reserved
> space will only be released in the end of btrfs_truncate(), this metadata
> leak will impact other's metadata reservation. In this case, it's
> "btrfs_start_transaction(root, 2);" fails for enospc error, which make
> this truncate operation fail.
>
> Call btrfs_block_rsv_release() to fix this bug.
>
> Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
> ---
> fs/btrfs/inode.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index e6811c4..40f0762 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -9206,6 +9206,7 @@ static int btrfs_truncate(struct inode *inode)
> break;
> }
>
> + btrfs_block_rsv_release(root, rsv, -1);
> ret = btrfs_block_rsv_migrate(&root->fs_info->trans_block_rsv,
> rsv, min_size, 0);
> BUG_ON(ret); /* shouldn't happen */
>
^ permalink raw reply
* Re: [PATCH v3] ethtool: dispaly bus info and firmware version
From: Wu, Jingjing @ 2017-01-04 7:51 UTC (permalink / raw)
To: Yang, Qiming, dev@dpdk.org, thomas.monjalon@6wind.com
Cc: Horton, Remy, Yigit, Ferruh, Yang, Qiming
In-Reply-To: <1482843968-6483-1-git-send-email-qiming.yang@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qiming Yang
> Sent: Tuesday, December 27, 2016 9:06 PM
> To: dev@dpdk.org; thomas.monjalon@6wind.com
> Cc: Horton, Remy <remy.horton@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Yang, Qiming <qiming.yang@intel.com>
> Subject: [dpdk-dev] [PATCH v3] ethtool: dispaly bus info and firmware version
>
> This patch enhances the ethtool example to support to show bus information
> and firmware version, in the same way that the Linux kernel ethtool does.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
> v3 changes:
> * split this patch from the patch set of rte_eth_dev_fw_info_get
> use the new version function.
> ---
> ---
> examples/ethtool/ethtool-app/ethapp.c | 2 ++
> examples/ethtool/lib/rte_ethtool.c | 11 +++++++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/examples/ethtool/ethtool-app/ethapp.c
> b/examples/ethtool/ethtool-app/ethapp.c
> index 6aeaa06..192d941 100644
> --- a/examples/ethtool/ethtool-app/ethapp.c
> +++ b/examples/ethtool/ethtool-app/ethapp.c
> @@ -185,6 +185,8 @@ pcmd_drvinfo_callback(__rte_unused void *ptr_params,
> printf("Port %i driver: %s (ver: %s)\n",
> id_port, info.driver, info.version
> );
> + printf("bus-info: %s\n", info.bus_info);
This patch has dependence on your get_fw_version patch set.
I think you may misunderstand Ferruh's comments,
I think what he said was ask you to remove bus-info print (above line) from that patch set,
but keep firmware version print.
Thanks
Jingjing
^ permalink raw reply
* Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint
From: Michal Hocko @ 2017-01-04 7:50 UTC (permalink / raw)
To: Minchan Kim
Cc: Hillf Danton, linux-mm, Andrew Morton, Mel Gorman,
Johannes Weiner, Vlastimil Babka, Rik van Riel, LKML
In-Reply-To: <20170104050722.GA17166@bbox>
On Wed 04-01-17 14:07:22, Minchan Kim wrote:
> On Tue, Jan 03, 2017 at 09:21:22AM +0100, Michal Hocko wrote:
[...]
> > with other tracepoints but that can be helpful because you do not have
> > all the tracepoints enabled all the time. So unless you see this
> > particular thing as a road block I would rather keep it.
>
> I didn't know how long this thread becomes lenghy. To me, it was no worth
> to discuss. I did best effot to explain my stand with valid points, I think
> and don't want to go infinite loop. If you don't agree still, separate
> the patch. One includes only necessary things with removing nr_scanned, which
> I am happy to ack it. Based upon it, add one more patch you want adding
> nr_scanned with your claim. I will reply that thread with my claim and
> let's keep an eye on it that whether maintainer will take it or not.
To be honest this is just not worth the effort and rather than
discussing further I will just drop the nr_scanned slthough I disagree
that your concerns regarding this _particular counter_ are really valid.
> If maintainer will take it, it's good indication which will represent
> we can add more extra tracepoint easily with "might be helpful with someone
> although it's redunant" so do not prevent others who want to do
> in the future.
no we do not work in a precedence system like that.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH 2/7] mm, vmscan: add active list aging tracepoint
From: Michal Hocko @ 2017-01-04 7:50 UTC (permalink / raw)
To: Minchan Kim
Cc: Hillf Danton, linux-mm, Andrew Morton, Mel Gorman,
Johannes Weiner, Vlastimil Babka, Rik van Riel, LKML
In-Reply-To: <20170104050722.GA17166@bbox>
On Wed 04-01-17 14:07:22, Minchan Kim wrote:
> On Tue, Jan 03, 2017 at 09:21:22AM +0100, Michal Hocko wrote:
[...]
> > with other tracepoints but that can be helpful because you do not have
> > all the tracepoints enabled all the time. So unless you see this
> > particular thing as a road block I would rather keep it.
>
> I didn't know how long this thread becomes lenghy. To me, it was no worth
> to discuss. I did best effot to explain my stand with valid points, I think
> and don't want to go infinite loop. If you don't agree still, separate
> the patch. One includes only necessary things with removing nr_scanned, which
> I am happy to ack it. Based upon it, add one more patch you want adding
> nr_scanned with your claim. I will reply that thread with my claim and
> let's keep an eye on it that whether maintainer will take it or not.
To be honest this is just not worth the effort and rather than
discussing further I will just drop the nr_scanned slthough I disagree
that your concerns regarding this _particular counter_ are really valid.
> If maintainer will take it, it's good indication which will represent
> we can add more extra tracepoint easily with "might be helpful with someone
> although it's redunant" so do not prevent others who want to do
> in the future.
no we do not work in a precedence system like that.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC PATCH] input: Add disable sysfs entry for every input device
From: Ivaylo Dimitrov @ 2017-01-04 7:43 UTC (permalink / raw)
To: Bastien Nocera, Pali Rohár
Cc: Dmitry Torokhov, Sebastian Reichel, Pavel Machek,
Mauro Carvalho Chehab, Chuck Ebbert, Henrik Rydberg, linux-input,
linux-kernel
In-Reply-To: <1483442481.2420.12.camel@hadess.net>
On 3.01.2017 13:21, Bastien Nocera wrote:
> On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
>> On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
>>> On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
>>>> This patch allows user to disable events from any input device so
>>>> events
>>>> would not be delivered to userspace.
>>>>
>>>> Currently there is no way to disable particular input device by
>>>> kernel.
>>>> User for different reasons would need it for integrated PS/2
>>>> keyboard or
>>>> touchpad in notebook or touchscreen on mobile device to prevent
>>>> sending
>>>> events. E.g. mobile phone in pocket or broken integrated PS/2
>>>> keyboard.
>>>>
>>>> This is just a RFC patch, not tested yet. Original post about
>>>> motivation
>>>> about this patch is there: https://lkml.org/lkml/2014/11/29/92
>>>
>>> Having implemented something of that ilk in user-space (we
>>> automatically disable touch devices when the associated screen is
>>> turned off/suspended), I think this might need more thought.
>>
>> How to implement such thing in userspace? I think you cannot do that
>> without rewriting every one userspace application which uses input.
>>
>>> What happens when a device is opened and the device disabled
>> through
>>> sysfs, are the users revoked?
>>
>> Applications will not receive events. Same as if input device does
>> not
>> generates events.
>>
>>> Does this put the device in suspend in the same way that closing
>> the
>>> device's last user does?
>>
>> Current code not (this is just RFC prototype), but it should be
>> possible
>> to implement.
>>
>>> Is this not better implemented in user-space at the session level,
>>> where it knows about which output corresponds to which input
>> device?
>>
>> How to do that without rewriting existing applications?
>>
>>> Is this useful enough to disable misbehaving devices on hardware,
>> so
>>> that the device is not effective on boot?
>>
>> In case integrated device is absolutely unusable and generates
>> always
>> random events, it does not solve problem at boot time.
>>
>> But more real case is laptop with closed LID press buttons and here
>> it
>> is useful.
>
> There's usually a display manager in between the application and the
> input device. Whether it's X.org, or a Wayland compositor. Even David's
> https://github.com/dvdhrm/kmscon could help for console applications.
>
I think the use cases are not clearly explained, will try to:
1. Imagine you have a mobile phone, with a touchscreen, a slide
keyboard, a keyboard-slide sensor, a proximity sensor and a couple of
GPIOs, set-up as gpio keys. And you want to carry that phone in your
pocket, without being worried that it will pick-up an incoming call by
itself while in the pocket, so:
- slide keyboard is closed, you "lock" the phone before put it in your
pocket - in that state, touchscreen and most of the gpio-keys should be
"disabled", so no touches are registered waking-up the device without need.
- a call comes, proximity gets "enabled", but TS should stay disabled as
proximity detects "the phone is in a pocket"
- you get your phone out of your pocket - proximity detects no more
obstacles, so now TS has to be enabled giving you a chance to pick up
the incoming call.
"disabling" of gpio-keys is clear, but how to make TS and proximity
inactive when needed? Sure, touches can be simply ignored (by using
xinput "Device Enabled" 0 on x11), same for proximity, but keep in mind
this is a battery-operated device, so we don't want CPU wake-ups with no
need.
2. The same device, "locked", but this time with slide keyboard opened:
- both keyboard and TS should be "disabled" so no touches neither key
presses wake-up the system. Only the power-button (or some other,
doesn't matter) should be enabled to activate the device.
There are more use-cases similar to the above as well as use-cases for
laptops, but I hope you're getting the idea.
Also, the interface to "disable" an input devices should be independent
to whether you use X11, wayland or your application draws directly to
the framebuffer.
Ivo
^ permalink raw reply
* Re: [PATCH v3 1/4] ethdev: add firmware information get
From: Wu, Jingjing @ 2017-01-04 7:48 UTC (permalink / raw)
To: Yang, Qiming, Yigit, Ferruh; +Cc: dev@dpdk.org, Horton, Remy, Thomas Monjalon
In-Reply-To: <F5DF4F0E3AFEF648ADC1C3C33AD4DBF16EDC998C@SHSMSX101.ccr.corp.intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yang, Qiming
> Sent: Wednesday, January 4, 2017 11:33 AM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; Horton, Remy <remy.horton@intel.com>; Thomas Monjalon
> <thomas.monjalon@6wind.com>
> Subject: Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add firmware information get
>
> Yes, in my opinion it is. And I use this name already exist in the share code from
> ND team.
>
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Tuesday, January 3, 2017 10:49 PM
> To: Yang, Qiming <qiming.yang@intel.com>
> Cc: dev@dpdk.org; Horton, Remy <remy.horton@intel.com>; Thomas Monjalon
> <thomas.monjalon@6wind.com>
> Subject: Re: [PATCH v3 1/4] ethdev: add firmware information get
>
> On 1/3/2017 9:05 AM, Yang, Qiming wrote:
> > Hi, Ferruh
> > Please see the question below. In my opinion, etrack_id is just a name used to
> define the ID of one NIC.
> > In kernel version ethtool, it will print this ID in the line of firmware verison.
> > I know what is etrack_id mean, but I really don't know why this named
> etrack_id.
>
> Hi Qiming,
>
> I suggested the API based on fields you already used in your patch.
>
> So, this API is to get FW version, is etrack_id something that defines (part of)
> firmware version?
>
> Thanks,
> ferruh
>
>
Different HW may have different version format, so it is better to use string.
And I prefer the API definition in your v2 patch like
rte_eth_dev_fwver_get(uint8_t port_id, char *fw_version, int fw_length);
Thanks
Jingjing
^ permalink raw reply
* [PATCH] Document mfsymlinks in the mount.cifs man page
From: Sachin Prabhu @ 2017-01-04 7:48 UTC (permalink / raw)
To: linux-cifs; +Cc: Jeff Layton
Information from the cifs README in the kernel sources is used.
Signed-off-by: Sachin Prabhu <sprabhu-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
mount.cifs.8 | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/mount.cifs.8 b/mount.cifs.8
index af6b097..01579f6 100644
--- a/mount.cifs.8
+++ b/mount.cifs.8
@@ -450,6 +450,11 @@ sfu
When the CIFS Unix Extensions are not negotiated, attempt to create device files and fifos in a format compatible with Services for Unix (SFU)\&. In addition retrieve bits 10\-12 of the mode via the SETFILEBITS extended attribute (as SFU does)\&. In the future the bottom 9 bits of the mode mode also will be emulated using queries of the security descriptor (ACL)\&. [NB: requires version 1\&.39 or later of the CIFS VFS\&. To recognize symlinks and be able to create symlinks in an SFU interoperable form requires version 1\&.40 or later of the CIFS VFS kernel module\&.
.RE
.PP
+mfsymlinks
+.RS 4
+Enable support for Minshall+French symlinks(see http://wiki.samba.org/index.php/UNIX_Extensions#Minshall.2BFrench_symlinks). This option is ignored when specified together with the 'sfu' option. Minshall+French symlinks are used even if the server supports the CIFS Unix Extensions.
+.RE
+.PP
serverino
.RS 4
Use inode numbers (unique persistent file identifiers) returned by the server instead of automatically generating temporary inode numbers on the client\&. Although server inode numbers make it easier to spot hardlinked files (as they will have the same inode numbers) and inode numbers may be persistent (which is userful for some sofware), the server does not guarantee that the inode numbers are unique if multiple server side mounts are exported under a single share (since inode numbers on the servers might not be unique if multiple filesystems are mounted under the same shared higher level directory)\&. Note that not all servers support returning server inode numbers, although those that support the CIFS Unix Extensions, and Windows 2000 and later servers typically do support this (althou
gh not necessarily on every local server filesystem)\&. Parameter has no effect if the server lacks support for returning inode numbers or equivalent\&. This behavior is enabled by default\!
&.
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 5/7] net/virtio_user: add vhost kernel support
From: Yuanhan Liu @ 2017-01-04 7:46 UTC (permalink / raw)
To: Tan, Jianfeng; +Cc: dev, ferruh.yigit, cunming.liang
In-Reply-To: <59e32f20-fe7a-20ad-1aa6-99fc90322a42@intel.com>
On Wed, Jan 04, 2017 at 03:22:08PM +0800, Tan, Jianfeng wrote:
>
> Sorry, I forget to reply this comment.
>
> On 12/26/2016 3:44 PM, Yuanhan Liu wrote:
> >[...]
> >>+
> >>+ /* Does not work when VIRTIO_F_IOMMU_PLATFORM now, why? */
> >Because this feature need the vhost IOTLB support from the device
> >emulation. Patches for QEMU hasn't been merged yet, but it has been
> >there for a while.
>
> Yes. And it's in need of help from QEMU.
>
> >
> >Since we don't have the support yet, for sure it won't work. But
> >I'm wondering why you have to disable it explicitly?
>
> Here we do not have QEMU. Frontend driver talks with vhost-net through
> virtio_user_dev. And both ends claim to support VIRTIO_F_IOMMU_PLATFORM. So
> this feature bit will be negotiated if we don't explicitly disable it. In my
> previous test, it fails in vhost_init_device_iotlb() of vhost kernel module.
> My guess is that, for this feature, without the help of QEMU, vhost kernel
> module cannot work independently.
The negotiation is a work between the driver, the device and the vhost
backend. If the device doesn't claim to support it, how could it be
nenogitated.
Think that way, does old QEMU (that doesn't support this feature) disable this
feature explicitly? No. Then why do we have to do that?
--yliu
^ permalink raw reply
* Re: [PATCH] virtio_blk: avoid DMA to stack for the sense buffer
From: Jason Wang @ 2017-01-04 7:44 UTC (permalink / raw)
To: Christoph Hellwig, axboe, mst; +Cc: linux-block, linux-kernel, virtualization
In-Reply-To: <1483507505-26797-2-git-send-email-hch@lst.de>
On 2017年01月04日 13:25, Christoph Hellwig wrote:
> Most users of BLOCK_PC requests allocate the sense buffer on the stack,
> so to avoid DMA to the stack copy them to a field in the heap allocated
> virtblk_req structure. Without that any attempt at SCSI passthrough I/O,
> including the SG_IO ioctl from userspace will crash the kernel. Note that
> this includes running tools like hdparm even when the host does not have
> SCSI passthrough enabled.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/block/virtio_blk.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 5545a67..3c3b8f6 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -56,6 +56,7 @@ struct virtblk_req {
> struct virtio_blk_outhdr out_hdr;
> struct virtio_scsi_inhdr in_hdr;
> u8 status;
> + u8 sense[SCSI_SENSE_BUFFERSIZE];
> struct scatterlist sg[];
> };
>
> @@ -102,7 +103,8 @@ static int __virtblk_add_req(struct virtqueue *vq,
> }
>
> if (type == cpu_to_virtio32(vq->vdev, VIRTIO_BLK_T_SCSI_CMD)) {
> - sg_init_one(&sense, vbr->req->sense, SCSI_SENSE_BUFFERSIZE);
> + memcpy(vbr->sense, vbr->req->sense, SCSI_SENSE_BUFFERSIZE);
> + sg_init_one(&sense, vbr->sense, SCSI_SENSE_BUFFERSIZE);
> sgs[num_out + num_in++] = &sense;
> sg_init_one(&inhdr, &vbr->in_hdr, sizeof(vbr->in_hdr));
> sgs[num_out + num_in++] = &inhdr;
Acked-by: Jason Wang <jasowang@redhat.com>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] virtio_blk: avoid DMA to stack for the sense buffer
From: Jason Wang @ 2017-01-04 7:44 UTC (permalink / raw)
To: Christoph Hellwig, axboe, mst; +Cc: linux-block, virtualization, linux-kernel
In-Reply-To: <1483507505-26797-2-git-send-email-hch@lst.de>
On 2017年01月04日 13:25, Christoph Hellwig wrote:
> Most users of BLOCK_PC requests allocate the sense buffer on the stack,
> so to avoid DMA to the stack copy them to a field in the heap allocated
> virtblk_req structure. Without that any attempt at SCSI passthrough I/O,
> including the SG_IO ioctl from userspace will crash the kernel. Note that
> this includes running tools like hdparm even when the host does not have
> SCSI passthrough enabled.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/block/virtio_blk.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 5545a67..3c3b8f6 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -56,6 +56,7 @@ struct virtblk_req {
> struct virtio_blk_outhdr out_hdr;
> struct virtio_scsi_inhdr in_hdr;
> u8 status;
> + u8 sense[SCSI_SENSE_BUFFERSIZE];
> struct scatterlist sg[];
> };
>
> @@ -102,7 +103,8 @@ static int __virtblk_add_req(struct virtqueue *vq,
> }
>
> if (type == cpu_to_virtio32(vq->vdev, VIRTIO_BLK_T_SCSI_CMD)) {
> - sg_init_one(&sense, vbr->req->sense, SCSI_SENSE_BUFFERSIZE);
> + memcpy(vbr->sense, vbr->req->sense, SCSI_SENSE_BUFFERSIZE);
> + sg_init_one(&sense, vbr->sense, SCSI_SENSE_BUFFERSIZE);
> sgs[num_out + num_in++] = &sense;
> sg_init_one(&inhdr, &vbr->in_hdr, sizeof(vbr->in_hdr));
> sgs[num_out + num_in++] = &inhdr;
Acked-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.