* (no subject)
@ 2001-06-13 1:55 Colonel
2001-06-13 9:32 ` your mail Luigi Genoni
2001-06-18 13:55 ` Jan Hudec
0 siblings, 2 replies; 348+ messages in thread
From: Colonel @ 2001-06-13 1:55 UTC (permalink / raw)
To: linux-kernel
From: Colonel <klink@clouddancer.com>
To: linux-kernel@vger.kernel.org
Subject: ISA Soundblaster problem
Reply-to: klink@clouddancer.com
The Maintainers list does not contain anyone for 2.4 Soundblaster
modules, so perhaps some one on the mailing list is aware of a
solution. My ISA Soundblaster 16waveffects worked fine in kernel 2.2
with XMMS. But I have never been successful in a varity of 2.4
kernels, the latest being 2.4.5-ac12. This is what I know:
[DMESG]
isapnp: Scanning for PnP cards...
isapnp: Calling quirk for 01:00
isapnp: SB audio device quirk - increasing port range
isapnp: Card 'Creative SB16 PnP'
isapnp: 1 Plug & Play card detected total
}modprobe sb
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: init_module: No such device
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o failed
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod sb failed
[/etc/modules.conf]
options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
[DMESG}
Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
sb: No ISAPnP cards found, trying standard ones...
sb: dsp reset failed.
So it seems that PnP finds the card, but the connections (or even the
forced values) to the sb module fail. Back when this was a single
processor machine, but still running 2.4 kernel, a windoze
installation found the SB at the listed interface parameters.
Anyone have a solution?
Same problem without modules.conf settings, valid version of mod
utilities, a web search did not help,...
TIA
please CC: klink@clouddancer.com, not currently on the mailing list.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2001-06-13 1:55 Colonel
@ 2001-06-13 9:32 ` Luigi Genoni
2001-06-18 13:55 ` Jan Hudec
1 sibling, 0 replies; 348+ messages in thread
From: Luigi Genoni @ 2001-06-13 9:32 UTC (permalink / raw)
To: Colonel; +Cc: linux-kernel
I have the sound blaster 16 card on one of my athlon (on PIII i have
es1731), that has one isa slot on its MB.
It works well, but i do not use isapnp nor any pnp support is enabled
inside of the kernel.
running 2.4.5/2.4.6-pre2
Luigi
On Tue, 12 Jun 2001, Colonel wrote:
> From: Colonel <klink@clouddancer.com>
> To: linux-kernel@vger.kernel.org
> Subject: ISA Soundblaster problem
> Reply-to: klink@clouddancer.com
>
>
> The Maintainers list does not contain anyone for 2.4 Soundblaster
> modules, so perhaps some one on the mailing list is aware of a
> solution. My ISA Soundblaster 16waveffects worked fine in kernel 2.2
> with XMMS. But I have never been successful in a varity of 2.4
> kernels, the latest being 2.4.5-ac12. This is what I know:
>
> [DMESG]
> isapnp: Scanning for PnP cards...
> isapnp: Calling quirk for 01:00
> isapnp: SB audio device quirk - increasing port range
> isapnp: Card 'Creative SB16 PnP'
> isapnp: 1 Plug & Play card detected total
>
> }modprobe sb
> /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: init_module: No such device
> /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
> /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o failed
> /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod sb failed
>
>
> [/etc/modules.conf]
> options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
>
>
> [DMESG}
> Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
> sb: No ISAPnP cards found, trying standard ones...
> sb: dsp reset failed.
>
>
> So it seems that PnP finds the card, but the connections (or even the
> forced values) to the sb module fail. Back when this was a single
> processor machine, but still running 2.4 kernel, a windoze
> installation found the SB at the listed interface parameters.
>
>
> Anyone have a solution?
>
> Same problem without modules.conf settings, valid version of mod
> utilities, a web search did not help,...
>
>
>
> TIA
>
>
> please CC: klink@clouddancer.com, not currently on the mailing list.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2001-06-13 1:55 Colonel
2001-06-13 9:32 ` your mail Luigi Genoni
@ 2001-06-18 13:55 ` Jan Hudec
1 sibling, 0 replies; 348+ messages in thread
From: Jan Hudec @ 2001-06-18 13:55 UTC (permalink / raw)
To: Colonel; +Cc: linux-kernel
> So it seems that PnP finds the card, but the connections (or even the
> forced values) to the sb module fail. Back when this was a single
> processor machine, but still running 2.4 kernel, a windoze
> installation found the SB at the listed interface parameters.
>
>
> Anyone have a solution?
>
> Same problem without modules.conf settings, valid version of mod
> utilities, a web search did not help,...
I had a similar problem with different card (Gravi Usltrasound PnP).
The solution turned out to be to avoid dma 1 channel. May be some BIOSes
or ISA chipsets got the 8-bit dma channels handling wrong, but I really
don't know. Btw: for me 2.2.x autodetected right, 2.4.x need explicit setting.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2023-10-16 12:31 Gilbert Adikankwu
2023-10-16 12:34 ` your mail Julia Lawall
0 siblings, 1 reply; 348+ messages in thread
From: Gilbert Adikankwu @ 2023-10-16 12:31 UTC (permalink / raw)
To: Julia Lawall; +Cc: outreachy, gregkh, linux-staging, linux-kernel
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Bcc:
Subject: Re: [PATCH] staging: emxx_udc: Remove unnecessary parentheses around
condition tests
Reply-To:
In-Reply-To: <6b60ed7-9d97-2071-44f8-83b173191ed@inria.fr>
On Mon, Oct 16, 2023 at 02:15:06PM +0200, Julia Lawall wrote:
>
>
> On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
>
> > Fix 47 warnings detected by checkpatch.pl about unnecessary parenthesis
> > around condition tests.
>
> If you need to make any changes to the patch, there is no need to give the
> count of the changes. It doesn't matter if it's 47, 46, 35, etc.
>
> julia
>
Hi Julia,
I added the number because I saw I similar commit on the logs that did
so. (commit b83970f23f36f0e2968872140e69f68118d82fe3)
> >
> > Signed-off-by: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
> > ---
> > drivers/staging/emxx_udc/emxx_udc.c | 72 ++++++++++++++---------------
> > 1 file changed, 36 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c
> > index eb63daaca702..e8ddd691b788 100644
> > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > @@ -149,8 +149,8 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct usb_request *_req)
> > /* SET_FEATURE */
> > recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
> > selector = le16_to_cpu(p_ctrl->wValue);
> > - if ((recipient == USB_RECIP_DEVICE) &&
> > - (selector == USB_DEVICE_TEST_MODE)) {
> > + if (recipient == USB_RECIP_DEVICE &&
> > + selector == USB_DEVICE_TEST_MODE) {
> > wIndex = le16_to_cpu(p_ctrl->wIndex);
> > test_mode = (u32)(wIndex >> 8);
> > _nbu2ss_set_test_mode(udc, test_mode);
> > @@ -287,7 +287,7 @@ static int _nbu2ss_epn_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > u32 num;
> > u32 data;
> >
> > - if ((ep->epnum == 0) || (udc->vbus_active == 0))
> > + if (ep->epnum == 0 || udc->vbus_active == 0)
> > return -EINVAL;
> >
> > num = ep->epnum - 1;
> > @@ -336,7 +336,7 @@ static void _nbu2ss_ep_dma_init(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > u32 data;
> >
> > data = _nbu2ss_readl(&udc->p_regs->USBSSCONF);
> > - if (((ep->epnum == 0) || (data & (1 << ep->epnum)) == 0))
> > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > return; /* Not Support DMA */
> >
> > num = ep->epnum - 1;
> > @@ -380,7 +380,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > return; /* VBUS OFF */
> >
> > data = _nbu2ss_readl(&preg->USBSSCONF);
> > - if ((ep->epnum == 0) || ((data & (1 << ep->epnum)) == 0))
> > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > return; /* Not Support DMA */
> >
> > num = ep->epnum - 1;
> > @@ -560,7 +560,7 @@ static int ep0_out_overbytes(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
> > union usb_reg_access temp_32;
> > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> >
> > - if ((length > 0) && (length < sizeof(u32))) {
> > + if (length > 0 && length < sizeof(u32)) {
> > temp_32.dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> > for (i = 0 ; i < length ; i++)
> > p_buf_32->byte.DATA[i] = temp_32.byte.DATA[i];
> > @@ -608,7 +608,7 @@ static int ep0_in_overbytes(struct nbu2ss_udc *udc,
> > union usb_reg_access temp_32;
> > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> >
> > - if ((i_remain_size > 0) && (i_remain_size < sizeof(u32))) {
> > + if (i_remain_size > 0 && i_remain_size < sizeof(u32)) {
> > for (i = 0 ; i < i_remain_size ; i++)
> > temp_32.byte.DATA[i] = p_buf_32->byte.DATA[i];
> > _nbu2ss_ep_in_end(udc, 0, temp_32.dw, i_remain_size);
> > @@ -701,7 +701,7 @@ static int _nbu2ss_ep0_in_transfer(struct nbu2ss_udc *udc,
> > return result;
> > }
> >
> > - if ((i_remain_size < sizeof(u32)) && (result != EP0_PACKETSIZE)) {
> > + if (i_remain_size < sizeof(u32) && result != EP0_PACKETSIZE) {
> > p_buffer += result;
> > result += ep0_in_overbytes(udc, p_buffer, i_remain_size);
> > req->div_len = result;
> > @@ -738,7 +738,7 @@ static int _nbu2ss_ep0_out_transfer(struct nbu2ss_udc *udc,
> > req->req.actual += result;
> > i_recv_length -= result;
> >
> > - if ((i_recv_length > 0) && (i_recv_length < sizeof(u32))) {
> > + if (i_recv_length > 0 && i_recv_length < sizeof(u32)) {
> > p_buffer += result;
> > i_remain_size -= result;
> >
> > @@ -891,8 +891,8 @@ static int _nbu2ss_epn_out_pio(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> >
> > req->req.actual += result;
> >
> > - if ((req->req.actual == req->req.length) ||
> > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > + if (req->req.actual == req->req.length ||
> > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > result = 0;
> > }
> >
> > @@ -914,8 +914,8 @@ static int _nbu2ss_epn_out_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> >
> > i_buf_size = min((req->req.length - req->req.actual), data_size);
> >
> > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > - (i_buf_size >= sizeof(u32))) {
> > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > + i_buf_size >= sizeof(u32)) {
> > nret = _nbu2ss_out_dma(udc, req, num, i_buf_size);
> > } else {
> > i_buf_size = min_t(u32, i_buf_size, ep->ep.maxpacket);
> > @@ -954,8 +954,8 @@ static int _nbu2ss_epn_out_transfer(struct nbu2ss_udc *udc,
> > }
> > }
> > } else {
> > - if ((req->req.actual == req->req.length) ||
> > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > + if (req->req.actual == req->req.length ||
> > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > result = 0;
> > }
> > }
> > @@ -1106,8 +1106,8 @@ static int _nbu2ss_epn_in_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> >
> > num = ep->epnum - 1;
> >
> > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > - (data_size >= sizeof(u32))) {
> > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > + data_size >= sizeof(u32)) {
> > nret = _nbu2ss_in_dma(udc, ep, req, num, data_size);
> > } else {
> > data_size = min_t(u32, data_size, ep->ep.maxpacket);
> > @@ -1238,7 +1238,7 @@ static void _nbu2ss_endpoint_toggle_reset(struct nbu2ss_udc *udc, u8 ep_adrs)
> > u8 num;
> > u32 data;
> >
> > - if ((ep_adrs == 0) || (ep_adrs == 0x80))
> > + if (ep_adrs == 0 || ep_adrs == 0x80)
> > return;
> >
> > num = (ep_adrs & 0x7F) - 1;
> > @@ -1261,7 +1261,7 @@ static void _nbu2ss_set_endpoint_stall(struct nbu2ss_udc *udc,
> > struct nbu2ss_ep *ep;
> > struct fc_regs __iomem *preg = udc->p_regs;
> >
> > - if ((ep_adrs == 0) || (ep_adrs == 0x80)) {
> > + if (ep_adrs == 0 || ep_adrs == 0x80) {
> > if (bstall) {
> > /* Set STALL */
> > _nbu2ss_bitset(&preg->EP0_CONTROL, EP0_STL);
> > @@ -1392,8 +1392,8 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc *udc, bool bset)
> > u8 ep_adrs;
> > int result = -EOPNOTSUPP;
> >
> > - if ((udc->ctrl.wLength != 0x0000) ||
> > - (direction != USB_DIR_OUT)) {
> > + if (udc->ctrl.wLength != 0x0000 ||
> > + direction != USB_DIR_OUT) {
> > return -EINVAL;
> > }
> >
> > @@ -1480,7 +1480,7 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
> > u8 ep_adrs;
> > int result = -EINVAL;
> >
> > - if ((udc->ctrl.wValue != 0x0000) || (direction != USB_DIR_IN))
> > + if (udc->ctrl.wValue != 0x0000 || direction != USB_DIR_IN)
> > return result;
> >
> > length =
> > @@ -1542,9 +1542,9 @@ static int std_req_set_address(struct nbu2ss_udc *udc)
> > int result = 0;
> > u32 wValue = le16_to_cpu(udc->ctrl.wValue);
> >
> > - if ((udc->ctrl.bRequestType != 0x00) ||
> > - (udc->ctrl.wIndex != 0x0000) ||
> > - (udc->ctrl.wLength != 0x0000)) {
> > + if (udc->ctrl.bRequestType != 0x00 ||
> > + udc->ctrl.wIndex != 0x0000 ||
> > + udc->ctrl.wLength != 0x0000) {
> > return -EINVAL;
> > }
> >
> > @@ -1564,9 +1564,9 @@ static int std_req_set_configuration(struct nbu2ss_udc *udc)
> > {
> > u32 config_value = (u32)(le16_to_cpu(udc->ctrl.wValue) & 0x00ff);
> >
> > - if ((udc->ctrl.wIndex != 0x0000) ||
> > - (udc->ctrl.wLength != 0x0000) ||
> > - (udc->ctrl.bRequestType != 0x00)) {
> > + if (udc->ctrl.wIndex != 0x0000 ||
> > + udc->ctrl.wLength != 0x0000 ||
> > + udc->ctrl.bRequestType != 0x00) {
> > return -EINVAL;
> > }
> >
> > @@ -1838,8 +1838,8 @@ static void _nbu2ss_ep_done(struct nbu2ss_ep *ep,
> > }
> >
> > #ifdef USE_DMA
> > - if ((ep->direct == USB_DIR_OUT) && (ep->epnum > 0) &&
> > - (req->req.dma != 0))
> > + if (ep->direct == USB_DIR_OUT && ep->epnum > 0 &&
> > + req->req.dma != 0)
> > _nbu2ss_dma_unmap_single(udc, ep, req, USB_DIR_OUT);
> > #endif
> >
> > @@ -1931,7 +1931,7 @@ static inline void _nbu2ss_epn_in_dma_int(struct nbu2ss_udc *udc,
> > mpkt = ep->ep.maxpacket;
> > size = preq->actual % mpkt;
> > if (size > 0) {
> > - if (((preq->actual & 0x03) == 0) && (size < mpkt))
> > + if ((preq->actual & 0x03) == 0 && size < mpkt)
> > _nbu2ss_ep_in_end(udc, ep->epnum, 0, 0);
> > } else {
> > _nbu2ss_epn_in_int(udc, ep, req);
> > @@ -2428,8 +2428,8 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > }
> >
> > ep_type = usb_endpoint_type(desc);
> > - if ((ep_type == USB_ENDPOINT_XFER_CONTROL) ||
> > - (ep_type == USB_ENDPOINT_XFER_ISOC)) {
> > + if (ep_type == USB_ENDPOINT_XFER_CONTROL ||
> > + ep_type == USB_ENDPOINT_XFER_ISOC) {
> > pr_err(" *** %s, bat bmAttributes\n", __func__);
> > return -EINVAL;
> > }
> > @@ -2438,7 +2438,7 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > if (udc->vbus_active == 0)
> > return -ESHUTDOWN;
> >
> > - if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > + if (!udc->driver || udc->gadget.speed == USB_SPEED_UNKNOWN) {
> > dev_err(ep->udc->dev, " *** %s, udc !!\n", __func__);
> > return -ESHUTDOWN;
> > }
> > @@ -2603,8 +2603,8 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
> > }
> > }
> >
> > - if ((ep->epnum > 0) && (ep->direct == USB_DIR_OUT) &&
> > - (req->req.dma != 0))
> > + if (ep->epnum > 0 && ep->direct == USB_DIR_OUT &&
> > + req->req.dma != 0)
> > _nbu2ss_dma_map_single(udc, ep, req, USB_DIR_OUT);
> > #endif
> >
> > --
> > 2.34.1
> >
> >
> >
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2023-10-16 12:31 Gilbert Adikankwu
@ 2023-10-16 12:34 ` Julia Lawall
2023-10-16 12:42 ` Gilbert Adikankwu
0 siblings, 1 reply; 348+ messages in thread
From: Julia Lawall @ 2023-10-16 12:34 UTC (permalink / raw)
To: Gilbert Adikankwu; +Cc: outreachy, gregkh, linux-staging, linux-kernel
On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
> Bcc:
> Subject: Re: [PATCH] staging: emxx_udc: Remove unnecessary parentheses around
> condition tests
> Reply-To:
> In-Reply-To: <6b60ed7-9d97-2071-44f8-83b173191ed@inria.fr>
>
> On Mon, Oct 16, 2023 at 02:15:06PM +0200, Julia Lawall wrote:
> >
> >
> > On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> >
> > > Fix 47 warnings detected by checkpatch.pl about unnecessary parenthesis
> > > around condition tests.
> >
> > If you need to make any changes to the patch, there is no need to give the
> > count of the changes. It doesn't matter if it's 47, 46, 35, etc.
> >
> > julia
> >
> Hi Julia,
>
> I added the number because I saw I similar commit on the logs that did
> so. (commit b83970f23f36f0e2968872140e69f68118d82fe3)
OK, I still think it's pointless... The person who looks at the commit 5
years from now won't care about this information. They care about what
you did and why.
julia
> > >
> > > Signed-off-by: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
> > > ---
> > > drivers/staging/emxx_udc/emxx_udc.c | 72 ++++++++++++++---------------
> > > 1 file changed, 36 insertions(+), 36 deletions(-)
> > >
> > > diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c
> > > index eb63daaca702..e8ddd691b788 100644
> > > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > > @@ -149,8 +149,8 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct usb_request *_req)
> > > /* SET_FEATURE */
> > > recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
> > > selector = le16_to_cpu(p_ctrl->wValue);
> > > - if ((recipient == USB_RECIP_DEVICE) &&
> > > - (selector == USB_DEVICE_TEST_MODE)) {
> > > + if (recipient == USB_RECIP_DEVICE &&
> > > + selector == USB_DEVICE_TEST_MODE) {
> > > wIndex = le16_to_cpu(p_ctrl->wIndex);
> > > test_mode = (u32)(wIndex >> 8);
> > > _nbu2ss_set_test_mode(udc, test_mode);
> > > @@ -287,7 +287,7 @@ static int _nbu2ss_epn_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > u32 num;
> > > u32 data;
> > >
> > > - if ((ep->epnum == 0) || (udc->vbus_active == 0))
> > > + if (ep->epnum == 0 || udc->vbus_active == 0)
> > > return -EINVAL;
> > >
> > > num = ep->epnum - 1;
> > > @@ -336,7 +336,7 @@ static void _nbu2ss_ep_dma_init(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > u32 data;
> > >
> > > data = _nbu2ss_readl(&udc->p_regs->USBSSCONF);
> > > - if (((ep->epnum == 0) || (data & (1 << ep->epnum)) == 0))
> > > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > return; /* Not Support DMA */
> > >
> > > num = ep->epnum - 1;
> > > @@ -380,7 +380,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > return; /* VBUS OFF */
> > >
> > > data = _nbu2ss_readl(&preg->USBSSCONF);
> > > - if ((ep->epnum == 0) || ((data & (1 << ep->epnum)) == 0))
> > > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > return; /* Not Support DMA */
> > >
> > > num = ep->epnum - 1;
> > > @@ -560,7 +560,7 @@ static int ep0_out_overbytes(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
> > > union usb_reg_access temp_32;
> > > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> > >
> > > - if ((length > 0) && (length < sizeof(u32))) {
> > > + if (length > 0 && length < sizeof(u32)) {
> > > temp_32.dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> > > for (i = 0 ; i < length ; i++)
> > > p_buf_32->byte.DATA[i] = temp_32.byte.DATA[i];
> > > @@ -608,7 +608,7 @@ static int ep0_in_overbytes(struct nbu2ss_udc *udc,
> > > union usb_reg_access temp_32;
> > > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> > >
> > > - if ((i_remain_size > 0) && (i_remain_size < sizeof(u32))) {
> > > + if (i_remain_size > 0 && i_remain_size < sizeof(u32)) {
> > > for (i = 0 ; i < i_remain_size ; i++)
> > > temp_32.byte.DATA[i] = p_buf_32->byte.DATA[i];
> > > _nbu2ss_ep_in_end(udc, 0, temp_32.dw, i_remain_size);
> > > @@ -701,7 +701,7 @@ static int _nbu2ss_ep0_in_transfer(struct nbu2ss_udc *udc,
> > > return result;
> > > }
> > >
> > > - if ((i_remain_size < sizeof(u32)) && (result != EP0_PACKETSIZE)) {
> > > + if (i_remain_size < sizeof(u32) && result != EP0_PACKETSIZE) {
> > > p_buffer += result;
> > > result += ep0_in_overbytes(udc, p_buffer, i_remain_size);
> > > req->div_len = result;
> > > @@ -738,7 +738,7 @@ static int _nbu2ss_ep0_out_transfer(struct nbu2ss_udc *udc,
> > > req->req.actual += result;
> > > i_recv_length -= result;
> > >
> > > - if ((i_recv_length > 0) && (i_recv_length < sizeof(u32))) {
> > > + if (i_recv_length > 0 && i_recv_length < sizeof(u32)) {
> > > p_buffer += result;
> > > i_remain_size -= result;
> > >
> > > @@ -891,8 +891,8 @@ static int _nbu2ss_epn_out_pio(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > >
> > > req->req.actual += result;
> > >
> > > - if ((req->req.actual == req->req.length) ||
> > > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > + if (req->req.actual == req->req.length ||
> > > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > > result = 0;
> > > }
> > >
> > > @@ -914,8 +914,8 @@ static int _nbu2ss_epn_out_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > >
> > > i_buf_size = min((req->req.length - req->req.actual), data_size);
> > >
> > > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > - (i_buf_size >= sizeof(u32))) {
> > > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > + i_buf_size >= sizeof(u32)) {
> > > nret = _nbu2ss_out_dma(udc, req, num, i_buf_size);
> > > } else {
> > > i_buf_size = min_t(u32, i_buf_size, ep->ep.maxpacket);
> > > @@ -954,8 +954,8 @@ static int _nbu2ss_epn_out_transfer(struct nbu2ss_udc *udc,
> > > }
> > > }
> > > } else {
> > > - if ((req->req.actual == req->req.length) ||
> > > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > + if (req->req.actual == req->req.length ||
> > > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > > result = 0;
> > > }
> > > }
> > > @@ -1106,8 +1106,8 @@ static int _nbu2ss_epn_in_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > >
> > > num = ep->epnum - 1;
> > >
> > > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > - (data_size >= sizeof(u32))) {
> > > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > + data_size >= sizeof(u32)) {
> > > nret = _nbu2ss_in_dma(udc, ep, req, num, data_size);
> > > } else {
> > > data_size = min_t(u32, data_size, ep->ep.maxpacket);
> > > @@ -1238,7 +1238,7 @@ static void _nbu2ss_endpoint_toggle_reset(struct nbu2ss_udc *udc, u8 ep_adrs)
> > > u8 num;
> > > u32 data;
> > >
> > > - if ((ep_adrs == 0) || (ep_adrs == 0x80))
> > > + if (ep_adrs == 0 || ep_adrs == 0x80)
> > > return;
> > >
> > > num = (ep_adrs & 0x7F) - 1;
> > > @@ -1261,7 +1261,7 @@ static void _nbu2ss_set_endpoint_stall(struct nbu2ss_udc *udc,
> > > struct nbu2ss_ep *ep;
> > > struct fc_regs __iomem *preg = udc->p_regs;
> > >
> > > - if ((ep_adrs == 0) || (ep_adrs == 0x80)) {
> > > + if (ep_adrs == 0 || ep_adrs == 0x80) {
> > > if (bstall) {
> > > /* Set STALL */
> > > _nbu2ss_bitset(&preg->EP0_CONTROL, EP0_STL);
> > > @@ -1392,8 +1392,8 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc *udc, bool bset)
> > > u8 ep_adrs;
> > > int result = -EOPNOTSUPP;
> > >
> > > - if ((udc->ctrl.wLength != 0x0000) ||
> > > - (direction != USB_DIR_OUT)) {
> > > + if (udc->ctrl.wLength != 0x0000 ||
> > > + direction != USB_DIR_OUT) {
> > > return -EINVAL;
> > > }
> > >
> > > @@ -1480,7 +1480,7 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
> > > u8 ep_adrs;
> > > int result = -EINVAL;
> > >
> > > - if ((udc->ctrl.wValue != 0x0000) || (direction != USB_DIR_IN))
> > > + if (udc->ctrl.wValue != 0x0000 || direction != USB_DIR_IN)
> > > return result;
> > >
> > > length =
> > > @@ -1542,9 +1542,9 @@ static int std_req_set_address(struct nbu2ss_udc *udc)
> > > int result = 0;
> > > u32 wValue = le16_to_cpu(udc->ctrl.wValue);
> > >
> > > - if ((udc->ctrl.bRequestType != 0x00) ||
> > > - (udc->ctrl.wIndex != 0x0000) ||
> > > - (udc->ctrl.wLength != 0x0000)) {
> > > + if (udc->ctrl.bRequestType != 0x00 ||
> > > + udc->ctrl.wIndex != 0x0000 ||
> > > + udc->ctrl.wLength != 0x0000) {
> > > return -EINVAL;
> > > }
> > >
> > > @@ -1564,9 +1564,9 @@ static int std_req_set_configuration(struct nbu2ss_udc *udc)
> > > {
> > > u32 config_value = (u32)(le16_to_cpu(udc->ctrl.wValue) & 0x00ff);
> > >
> > > - if ((udc->ctrl.wIndex != 0x0000) ||
> > > - (udc->ctrl.wLength != 0x0000) ||
> > > - (udc->ctrl.bRequestType != 0x00)) {
> > > + if (udc->ctrl.wIndex != 0x0000 ||
> > > + udc->ctrl.wLength != 0x0000 ||
> > > + udc->ctrl.bRequestType != 0x00) {
> > > return -EINVAL;
> > > }
> > >
> > > @@ -1838,8 +1838,8 @@ static void _nbu2ss_ep_done(struct nbu2ss_ep *ep,
> > > }
> > >
> > > #ifdef USE_DMA
> > > - if ((ep->direct == USB_DIR_OUT) && (ep->epnum > 0) &&
> > > - (req->req.dma != 0))
> > > + if (ep->direct == USB_DIR_OUT && ep->epnum > 0 &&
> > > + req->req.dma != 0)
> > > _nbu2ss_dma_unmap_single(udc, ep, req, USB_DIR_OUT);
> > > #endif
> > >
> > > @@ -1931,7 +1931,7 @@ static inline void _nbu2ss_epn_in_dma_int(struct nbu2ss_udc *udc,
> > > mpkt = ep->ep.maxpacket;
> > > size = preq->actual % mpkt;
> > > if (size > 0) {
> > > - if (((preq->actual & 0x03) == 0) && (size < mpkt))
> > > + if ((preq->actual & 0x03) == 0 && size < mpkt)
> > > _nbu2ss_ep_in_end(udc, ep->epnum, 0, 0);
> > > } else {
> > > _nbu2ss_epn_in_int(udc, ep, req);
> > > @@ -2428,8 +2428,8 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > }
> > >
> > > ep_type = usb_endpoint_type(desc);
> > > - if ((ep_type == USB_ENDPOINT_XFER_CONTROL) ||
> > > - (ep_type == USB_ENDPOINT_XFER_ISOC)) {
> > > + if (ep_type == USB_ENDPOINT_XFER_CONTROL ||
> > > + ep_type == USB_ENDPOINT_XFER_ISOC) {
> > > pr_err(" *** %s, bat bmAttributes\n", __func__);
> > > return -EINVAL;
> > > }
> > > @@ -2438,7 +2438,7 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > if (udc->vbus_active == 0)
> > > return -ESHUTDOWN;
> > >
> > > - if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > > + if (!udc->driver || udc->gadget.speed == USB_SPEED_UNKNOWN) {
> > > dev_err(ep->udc->dev, " *** %s, udc !!\n", __func__);
> > > return -ESHUTDOWN;
> > > }
> > > @@ -2603,8 +2603,8 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
> > > }
> > > }
> > >
> > > - if ((ep->epnum > 0) && (ep->direct == USB_DIR_OUT) &&
> > > - (req->req.dma != 0))
> > > + if (ep->epnum > 0 && ep->direct == USB_DIR_OUT &&
> > > + req->req.dma != 0)
> > > _nbu2ss_dma_map_single(udc, ep, req, USB_DIR_OUT);
> > > #endif
> > >
> > > --
> > > 2.34.1
> > >
> > >
> > >
>
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2023-10-16 12:34 ` your mail Julia Lawall
@ 2023-10-16 12:42 ` Gilbert Adikankwu
2023-10-16 13:23 ` Julia Lawall
0 siblings, 1 reply; 348+ messages in thread
From: Gilbert Adikankwu @ 2023-10-16 12:42 UTC (permalink / raw)
To: Julia Lawall, outreachy; +Cc: linux-staging, linux-kernel, gregkh
On Mon, Oct 16, 2023 at 02:34:48PM +0200, Julia Lawall wrote:
>
>
> On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
>
> > linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
> > Bcc:
> > Subject: Re: [PATCH] staging: emxx_udc: Remove unnecessary parentheses around
> > condition tests
> > Reply-To:
> > In-Reply-To: <6b60ed7-9d97-2071-44f8-83b173191ed@inria.fr>
> >
> > On Mon, Oct 16, 2023 at 02:15:06PM +0200, Julia Lawall wrote:
> > >
> > >
> > > On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> > >
> > > > Fix 47 warnings detected by checkpatch.pl about unnecessary parenthesis
> > > > around condition tests.
> > >
> > > If you need to make any changes to the patch, there is no need to give the
> > > count of the changes. It doesn't matter if it's 47, 46, 35, etc.
> > >
> > > julia
> > >
> > Hi Julia,
> >
> > I added the number because I saw I similar commit on the logs that did
> > so. (commit b83970f23f36f0e2968872140e69f68118d82fe3)
>
> OK, I still think it's pointless... The person who looks at the commit 5
> years from now won't care about this information. They care about what
> you did and why.
>
> julia
>
Ok that make sense. I will revise it. Do I send revision patch now or
later today?
>
> > > >
> > > > Signed-off-by: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
> > > > ---
> > > > drivers/staging/emxx_udc/emxx_udc.c | 72 ++++++++++++++---------------
> > > > 1 file changed, 36 insertions(+), 36 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c
> > > > index eb63daaca702..e8ddd691b788 100644
> > > > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > > > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > > > @@ -149,8 +149,8 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct usb_request *_req)
> > > > /* SET_FEATURE */
> > > > recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
> > > > selector = le16_to_cpu(p_ctrl->wValue);
> > > > - if ((recipient == USB_RECIP_DEVICE) &&
> > > > - (selector == USB_DEVICE_TEST_MODE)) {
> > > > + if (recipient == USB_RECIP_DEVICE &&
> > > > + selector == USB_DEVICE_TEST_MODE) {
> > > > wIndex = le16_to_cpu(p_ctrl->wIndex);
> > > > test_mode = (u32)(wIndex >> 8);
> > > > _nbu2ss_set_test_mode(udc, test_mode);
> > > > @@ -287,7 +287,7 @@ static int _nbu2ss_epn_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > u32 num;
> > > > u32 data;
> > > >
> > > > - if ((ep->epnum == 0) || (udc->vbus_active == 0))
> > > > + if (ep->epnum == 0 || udc->vbus_active == 0)
> > > > return -EINVAL;
> > > >
> > > > num = ep->epnum - 1;
> > > > @@ -336,7 +336,7 @@ static void _nbu2ss_ep_dma_init(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > u32 data;
> > > >
> > > > data = _nbu2ss_readl(&udc->p_regs->USBSSCONF);
> > > > - if (((ep->epnum == 0) || (data & (1 << ep->epnum)) == 0))
> > > > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > > return; /* Not Support DMA */
> > > >
> > > > num = ep->epnum - 1;
> > > > @@ -380,7 +380,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > return; /* VBUS OFF */
> > > >
> > > > data = _nbu2ss_readl(&preg->USBSSCONF);
> > > > - if ((ep->epnum == 0) || ((data & (1 << ep->epnum)) == 0))
> > > > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > > return; /* Not Support DMA */
> > > >
> > > > num = ep->epnum - 1;
> > > > @@ -560,7 +560,7 @@ static int ep0_out_overbytes(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
> > > > union usb_reg_access temp_32;
> > > > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> > > >
> > > > - if ((length > 0) && (length < sizeof(u32))) {
> > > > + if (length > 0 && length < sizeof(u32)) {
> > > > temp_32.dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> > > > for (i = 0 ; i < length ; i++)
> > > > p_buf_32->byte.DATA[i] = temp_32.byte.DATA[i];
> > > > @@ -608,7 +608,7 @@ static int ep0_in_overbytes(struct nbu2ss_udc *udc,
> > > > union usb_reg_access temp_32;
> > > > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> > > >
> > > > - if ((i_remain_size > 0) && (i_remain_size < sizeof(u32))) {
> > > > + if (i_remain_size > 0 && i_remain_size < sizeof(u32)) {
> > > > for (i = 0 ; i < i_remain_size ; i++)
> > > > temp_32.byte.DATA[i] = p_buf_32->byte.DATA[i];
> > > > _nbu2ss_ep_in_end(udc, 0, temp_32.dw, i_remain_size);
> > > > @@ -701,7 +701,7 @@ static int _nbu2ss_ep0_in_transfer(struct nbu2ss_udc *udc,
> > > > return result;
> > > > }
> > > >
> > > > - if ((i_remain_size < sizeof(u32)) && (result != EP0_PACKETSIZE)) {
> > > > + if (i_remain_size < sizeof(u32) && result != EP0_PACKETSIZE) {
> > > > p_buffer += result;
> > > > result += ep0_in_overbytes(udc, p_buffer, i_remain_size);
> > > > req->div_len = result;
> > > > @@ -738,7 +738,7 @@ static int _nbu2ss_ep0_out_transfer(struct nbu2ss_udc *udc,
> > > > req->req.actual += result;
> > > > i_recv_length -= result;
> > > >
> > > > - if ((i_recv_length > 0) && (i_recv_length < sizeof(u32))) {
> > > > + if (i_recv_length > 0 && i_recv_length < sizeof(u32)) {
> > > > p_buffer += result;
> > > > i_remain_size -= result;
> > > >
> > > > @@ -891,8 +891,8 @@ static int _nbu2ss_epn_out_pio(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > >
> > > > req->req.actual += result;
> > > >
> > > > - if ((req->req.actual == req->req.length) ||
> > > > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > > + if (req->req.actual == req->req.length ||
> > > > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > > > result = 0;
> > > > }
> > > >
> > > > @@ -914,8 +914,8 @@ static int _nbu2ss_epn_out_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > >
> > > > i_buf_size = min((req->req.length - req->req.actual), data_size);
> > > >
> > > > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > > - (i_buf_size >= sizeof(u32))) {
> > > > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > > + i_buf_size >= sizeof(u32)) {
> > > > nret = _nbu2ss_out_dma(udc, req, num, i_buf_size);
> > > > } else {
> > > > i_buf_size = min_t(u32, i_buf_size, ep->ep.maxpacket);
> > > > @@ -954,8 +954,8 @@ static int _nbu2ss_epn_out_transfer(struct nbu2ss_udc *udc,
> > > > }
> > > > }
> > > > } else {
> > > > - if ((req->req.actual == req->req.length) ||
> > > > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > > + if (req->req.actual == req->req.length ||
> > > > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > > > result = 0;
> > > > }
> > > > }
> > > > @@ -1106,8 +1106,8 @@ static int _nbu2ss_epn_in_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > >
> > > > num = ep->epnum - 1;
> > > >
> > > > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > > - (data_size >= sizeof(u32))) {
> > > > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > > + data_size >= sizeof(u32)) {
> > > > nret = _nbu2ss_in_dma(udc, ep, req, num, data_size);
> > > > } else {
> > > > data_size = min_t(u32, data_size, ep->ep.maxpacket);
> > > > @@ -1238,7 +1238,7 @@ static void _nbu2ss_endpoint_toggle_reset(struct nbu2ss_udc *udc, u8 ep_adrs)
> > > > u8 num;
> > > > u32 data;
> > > >
> > > > - if ((ep_adrs == 0) || (ep_adrs == 0x80))
> > > > + if (ep_adrs == 0 || ep_adrs == 0x80)
> > > > return;
> > > >
> > > > num = (ep_adrs & 0x7F) - 1;
> > > > @@ -1261,7 +1261,7 @@ static void _nbu2ss_set_endpoint_stall(struct nbu2ss_udc *udc,
> > > > struct nbu2ss_ep *ep;
> > > > struct fc_regs __iomem *preg = udc->p_regs;
> > > >
> > > > - if ((ep_adrs == 0) || (ep_adrs == 0x80)) {
> > > > + if (ep_adrs == 0 || ep_adrs == 0x80) {
> > > > if (bstall) {
> > > > /* Set STALL */
> > > > _nbu2ss_bitset(&preg->EP0_CONTROL, EP0_STL);
> > > > @@ -1392,8 +1392,8 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc *udc, bool bset)
> > > > u8 ep_adrs;
> > > > int result = -EOPNOTSUPP;
> > > >
> > > > - if ((udc->ctrl.wLength != 0x0000) ||
> > > > - (direction != USB_DIR_OUT)) {
> > > > + if (udc->ctrl.wLength != 0x0000 ||
> > > > + direction != USB_DIR_OUT) {
> > > > return -EINVAL;
> > > > }
> > > >
> > > > @@ -1480,7 +1480,7 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
> > > > u8 ep_adrs;
> > > > int result = -EINVAL;
> > > >
> > > > - if ((udc->ctrl.wValue != 0x0000) || (direction != USB_DIR_IN))
> > > > + if (udc->ctrl.wValue != 0x0000 || direction != USB_DIR_IN)
> > > > return result;
> > > >
> > > > length =
> > > > @@ -1542,9 +1542,9 @@ static int std_req_set_address(struct nbu2ss_udc *udc)
> > > > int result = 0;
> > > > u32 wValue = le16_to_cpu(udc->ctrl.wValue);
> > > >
> > > > - if ((udc->ctrl.bRequestType != 0x00) ||
> > > > - (udc->ctrl.wIndex != 0x0000) ||
> > > > - (udc->ctrl.wLength != 0x0000)) {
> > > > + if (udc->ctrl.bRequestType != 0x00 ||
> > > > + udc->ctrl.wIndex != 0x0000 ||
> > > > + udc->ctrl.wLength != 0x0000) {
> > > > return -EINVAL;
> > > > }
> > > >
> > > > @@ -1564,9 +1564,9 @@ static int std_req_set_configuration(struct nbu2ss_udc *udc)
> > > > {
> > > > u32 config_value = (u32)(le16_to_cpu(udc->ctrl.wValue) & 0x00ff);
> > > >
> > > > - if ((udc->ctrl.wIndex != 0x0000) ||
> > > > - (udc->ctrl.wLength != 0x0000) ||
> > > > - (udc->ctrl.bRequestType != 0x00)) {
> > > > + if (udc->ctrl.wIndex != 0x0000 ||
> > > > + udc->ctrl.wLength != 0x0000 ||
> > > > + udc->ctrl.bRequestType != 0x00) {
> > > > return -EINVAL;
> > > > }
> > > >
> > > > @@ -1838,8 +1838,8 @@ static void _nbu2ss_ep_done(struct nbu2ss_ep *ep,
> > > > }
> > > >
> > > > #ifdef USE_DMA
> > > > - if ((ep->direct == USB_DIR_OUT) && (ep->epnum > 0) &&
> > > > - (req->req.dma != 0))
> > > > + if (ep->direct == USB_DIR_OUT && ep->epnum > 0 &&
> > > > + req->req.dma != 0)
> > > > _nbu2ss_dma_unmap_single(udc, ep, req, USB_DIR_OUT);
> > > > #endif
> > > >
> > > > @@ -1931,7 +1931,7 @@ static inline void _nbu2ss_epn_in_dma_int(struct nbu2ss_udc *udc,
> > > > mpkt = ep->ep.maxpacket;
> > > > size = preq->actual % mpkt;
> > > > if (size > 0) {
> > > > - if (((preq->actual & 0x03) == 0) && (size < mpkt))
> > > > + if ((preq->actual & 0x03) == 0 && size < mpkt)
> > > > _nbu2ss_ep_in_end(udc, ep->epnum, 0, 0);
> > > > } else {
> > > > _nbu2ss_epn_in_int(udc, ep, req);
> > > > @@ -2428,8 +2428,8 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > > }
> > > >
> > > > ep_type = usb_endpoint_type(desc);
> > > > - if ((ep_type == USB_ENDPOINT_XFER_CONTROL) ||
> > > > - (ep_type == USB_ENDPOINT_XFER_ISOC)) {
> > > > + if (ep_type == USB_ENDPOINT_XFER_CONTROL ||
> > > > + ep_type == USB_ENDPOINT_XFER_ISOC) {
> > > > pr_err(" *** %s, bat bmAttributes\n", __func__);
> > > > return -EINVAL;
> > > > }
> > > > @@ -2438,7 +2438,7 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > > if (udc->vbus_active == 0)
> > > > return -ESHUTDOWN;
> > > >
> > > > - if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > > > + if (!udc->driver || udc->gadget.speed == USB_SPEED_UNKNOWN) {
> > > > dev_err(ep->udc->dev, " *** %s, udc !!\n", __func__);
> > > > return -ESHUTDOWN;
> > > > }
> > > > @@ -2603,8 +2603,8 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
> > > > }
> > > > }
> > > >
> > > > - if ((ep->epnum > 0) && (ep->direct == USB_DIR_OUT) &&
> > > > - (req->req.dma != 0))
> > > > + if (ep->epnum > 0 && ep->direct == USB_DIR_OUT &&
> > > > + req->req.dma != 0)
> > > > _nbu2ss_dma_map_single(udc, ep, req, USB_DIR_OUT);
> > > > #endif
> > > >
> > > > --
> > > > 2.34.1
> > > >
> > > >
> > > >
> >
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2023-10-16 12:42 ` Gilbert Adikankwu
@ 2023-10-16 13:23 ` Julia Lawall
0 siblings, 0 replies; 348+ messages in thread
From: Julia Lawall @ 2023-10-16 13:23 UTC (permalink / raw)
To: Gilbert Adikankwu; +Cc: outreachy, linux-staging, linux-kernel, gregkh
On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> On Mon, Oct 16, 2023 at 02:34:48PM +0200, Julia Lawall wrote:
> >
> >
> > On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> >
> > > linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
> > > Bcc:
> > > Subject: Re: [PATCH] staging: emxx_udc: Remove unnecessary parentheses around
> > > condition tests
> > > Reply-To:
> > > In-Reply-To: <6b60ed7-9d97-2071-44f8-83b173191ed@inria.fr>
> > >
> > > On Mon, Oct 16, 2023 at 02:15:06PM +0200, Julia Lawall wrote:
> > > >
> > > >
> > > > On Mon, 16 Oct 2023, Gilbert Adikankwu wrote:
> > > >
> > > > > Fix 47 warnings detected by checkpatch.pl about unnecessary parenthesis
> > > > > around condition tests.
> > > >
> > > > If you need to make any changes to the patch, there is no need to give the
> > > > count of the changes. It doesn't matter if it's 47, 46, 35, etc.
> > > >
> > > > julia
> > > >
> > > Hi Julia,
> > >
> > > I added the number because I saw I similar commit on the logs that did
> > > so. (commit b83970f23f36f0e2968872140e69f68118d82fe3)
> >
> > OK, I still think it's pointless... The person who looks at the commit 5
> > years from now won't care about this information. They care about what
> > you did and why.
> >
> > julia
> >
> Ok that make sense. I will revise it. Do I send revision patch now or
> later today?
You can wait, in case there are other comments.
julia
> >
> > > > >
> > > > > Signed-off-by: Gilbert Adikankwu <gilbertadikankwu@gmail.com>
> > > > > ---
> > > > > drivers/staging/emxx_udc/emxx_udc.c | 72 ++++++++++++++---------------
> > > > > 1 file changed, 36 insertions(+), 36 deletions(-)
> > > > >
> > > > > diff --git a/drivers/staging/emxx_udc/emxx_udc.c b/drivers/staging/emxx_udc/emxx_udc.c
> > > > > index eb63daaca702..e8ddd691b788 100644
> > > > > --- a/drivers/staging/emxx_udc/emxx_udc.c
> > > > > +++ b/drivers/staging/emxx_udc/emxx_udc.c
> > > > > @@ -149,8 +149,8 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct usb_request *_req)
> > > > > /* SET_FEATURE */
> > > > > recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
> > > > > selector = le16_to_cpu(p_ctrl->wValue);
> > > > > - if ((recipient == USB_RECIP_DEVICE) &&
> > > > > - (selector == USB_DEVICE_TEST_MODE)) {
> > > > > + if (recipient == USB_RECIP_DEVICE &&
> > > > > + selector == USB_DEVICE_TEST_MODE) {
> > > > > wIndex = le16_to_cpu(p_ctrl->wIndex);
> > > > > test_mode = (u32)(wIndex >> 8);
> > > > > _nbu2ss_set_test_mode(udc, test_mode);
> > > > > @@ -287,7 +287,7 @@ static int _nbu2ss_epn_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > > u32 num;
> > > > > u32 data;
> > > > >
> > > > > - if ((ep->epnum == 0) || (udc->vbus_active == 0))
> > > > > + if (ep->epnum == 0 || udc->vbus_active == 0)
> > > > > return -EINVAL;
> > > > >
> > > > > num = ep->epnum - 1;
> > > > > @@ -336,7 +336,7 @@ static void _nbu2ss_ep_dma_init(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > > u32 data;
> > > > >
> > > > > data = _nbu2ss_readl(&udc->p_regs->USBSSCONF);
> > > > > - if (((ep->epnum == 0) || (data & (1 << ep->epnum)) == 0))
> > > > > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > > > return; /* Not Support DMA */
> > > > >
> > > > > num = ep->epnum - 1;
> > > > > @@ -380,7 +380,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
> > > > > return; /* VBUS OFF */
> > > > >
> > > > > data = _nbu2ss_readl(&preg->USBSSCONF);
> > > > > - if ((ep->epnum == 0) || ((data & (1 << ep->epnum)) == 0))
> > > > > + if (ep->epnum == 0 || (data & (1 << ep->epnum)) == 0)
> > > > > return; /* Not Support DMA */
> > > > >
> > > > > num = ep->epnum - 1;
> > > > > @@ -560,7 +560,7 @@ static int ep0_out_overbytes(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
> > > > > union usb_reg_access temp_32;
> > > > > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> > > > >
> > > > > - if ((length > 0) && (length < sizeof(u32))) {
> > > > > + if (length > 0 && length < sizeof(u32)) {
> > > > > temp_32.dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> > > > > for (i = 0 ; i < length ; i++)
> > > > > p_buf_32->byte.DATA[i] = temp_32.byte.DATA[i];
> > > > > @@ -608,7 +608,7 @@ static int ep0_in_overbytes(struct nbu2ss_udc *udc,
> > > > > union usb_reg_access temp_32;
> > > > > union usb_reg_access *p_buf_32 = (union usb_reg_access *)p_buf;
> > > > >
> > > > > - if ((i_remain_size > 0) && (i_remain_size < sizeof(u32))) {
> > > > > + if (i_remain_size > 0 && i_remain_size < sizeof(u32)) {
> > > > > for (i = 0 ; i < i_remain_size ; i++)
> > > > > temp_32.byte.DATA[i] = p_buf_32->byte.DATA[i];
> > > > > _nbu2ss_ep_in_end(udc, 0, temp_32.dw, i_remain_size);
> > > > > @@ -701,7 +701,7 @@ static int _nbu2ss_ep0_in_transfer(struct nbu2ss_udc *udc,
> > > > > return result;
> > > > > }
> > > > >
> > > > > - if ((i_remain_size < sizeof(u32)) && (result != EP0_PACKETSIZE)) {
> > > > > + if (i_remain_size < sizeof(u32) && result != EP0_PACKETSIZE) {
> > > > > p_buffer += result;
> > > > > result += ep0_in_overbytes(udc, p_buffer, i_remain_size);
> > > > > req->div_len = result;
> > > > > @@ -738,7 +738,7 @@ static int _nbu2ss_ep0_out_transfer(struct nbu2ss_udc *udc,
> > > > > req->req.actual += result;
> > > > > i_recv_length -= result;
> > > > >
> > > > > - if ((i_recv_length > 0) && (i_recv_length < sizeof(u32))) {
> > > > > + if (i_recv_length > 0 && i_recv_length < sizeof(u32)) {
> > > > > p_buffer += result;
> > > > > i_remain_size -= result;
> > > > >
> > > > > @@ -891,8 +891,8 @@ static int _nbu2ss_epn_out_pio(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > > >
> > > > > req->req.actual += result;
> > > > >
> > > > > - if ((req->req.actual == req->req.length) ||
> > > > > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > > > + if (req->req.actual == req->req.length ||
> > > > > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > > > > result = 0;
> > > > > }
> > > > >
> > > > > @@ -914,8 +914,8 @@ static int _nbu2ss_epn_out_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > > >
> > > > > i_buf_size = min((req->req.length - req->req.actual), data_size);
> > > > >
> > > > > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > > > - (i_buf_size >= sizeof(u32))) {
> > > > > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > > > + i_buf_size >= sizeof(u32)) {
> > > > > nret = _nbu2ss_out_dma(udc, req, num, i_buf_size);
> > > > > } else {
> > > > > i_buf_size = min_t(u32, i_buf_size, ep->ep.maxpacket);
> > > > > @@ -954,8 +954,8 @@ static int _nbu2ss_epn_out_transfer(struct nbu2ss_udc *udc,
> > > > > }
> > > > > }
> > > > > } else {
> > > > > - if ((req->req.actual == req->req.length) ||
> > > > > - ((req->req.actual % ep->ep.maxpacket) != 0)) {
> > > > > + if (req->req.actual == req->req.length ||
> > > > > + (req->req.actual % ep->ep.maxpacket) != 0) {
> > > > > result = 0;
> > > > > }
> > > > > }
> > > > > @@ -1106,8 +1106,8 @@ static int _nbu2ss_epn_in_data(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep,
> > > > >
> > > > > num = ep->epnum - 1;
> > > > >
> > > > > - if ((ep->ep_type != USB_ENDPOINT_XFER_INT) && (req->req.dma != 0) &&
> > > > > - (data_size >= sizeof(u32))) {
> > > > > + if (ep->ep_type != USB_ENDPOINT_XFER_INT && req->req.dma != 0 &&
> > > > > + data_size >= sizeof(u32)) {
> > > > > nret = _nbu2ss_in_dma(udc, ep, req, num, data_size);
> > > > > } else {
> > > > > data_size = min_t(u32, data_size, ep->ep.maxpacket);
> > > > > @@ -1238,7 +1238,7 @@ static void _nbu2ss_endpoint_toggle_reset(struct nbu2ss_udc *udc, u8 ep_adrs)
> > > > > u8 num;
> > > > > u32 data;
> > > > >
> > > > > - if ((ep_adrs == 0) || (ep_adrs == 0x80))
> > > > > + if (ep_adrs == 0 || ep_adrs == 0x80)
> > > > > return;
> > > > >
> > > > > num = (ep_adrs & 0x7F) - 1;
> > > > > @@ -1261,7 +1261,7 @@ static void _nbu2ss_set_endpoint_stall(struct nbu2ss_udc *udc,
> > > > > struct nbu2ss_ep *ep;
> > > > > struct fc_regs __iomem *preg = udc->p_regs;
> > > > >
> > > > > - if ((ep_adrs == 0) || (ep_adrs == 0x80)) {
> > > > > + if (ep_adrs == 0 || ep_adrs == 0x80) {
> > > > > if (bstall) {
> > > > > /* Set STALL */
> > > > > _nbu2ss_bitset(&preg->EP0_CONTROL, EP0_STL);
> > > > > @@ -1392,8 +1392,8 @@ static inline int _nbu2ss_req_feature(struct nbu2ss_udc *udc, bool bset)
> > > > > u8 ep_adrs;
> > > > > int result = -EOPNOTSUPP;
> > > > >
> > > > > - if ((udc->ctrl.wLength != 0x0000) ||
> > > > > - (direction != USB_DIR_OUT)) {
> > > > > + if (udc->ctrl.wLength != 0x0000 ||
> > > > > + direction != USB_DIR_OUT) {
> > > > > return -EINVAL;
> > > > > }
> > > > >
> > > > > @@ -1480,7 +1480,7 @@ static int std_req_get_status(struct nbu2ss_udc *udc)
> > > > > u8 ep_adrs;
> > > > > int result = -EINVAL;
> > > > >
> > > > > - if ((udc->ctrl.wValue != 0x0000) || (direction != USB_DIR_IN))
> > > > > + if (udc->ctrl.wValue != 0x0000 || direction != USB_DIR_IN)
> > > > > return result;
> > > > >
> > > > > length =
> > > > > @@ -1542,9 +1542,9 @@ static int std_req_set_address(struct nbu2ss_udc *udc)
> > > > > int result = 0;
> > > > > u32 wValue = le16_to_cpu(udc->ctrl.wValue);
> > > > >
> > > > > - if ((udc->ctrl.bRequestType != 0x00) ||
> > > > > - (udc->ctrl.wIndex != 0x0000) ||
> > > > > - (udc->ctrl.wLength != 0x0000)) {
> > > > > + if (udc->ctrl.bRequestType != 0x00 ||
> > > > > + udc->ctrl.wIndex != 0x0000 ||
> > > > > + udc->ctrl.wLength != 0x0000) {
> > > > > return -EINVAL;
> > > > > }
> > > > >
> > > > > @@ -1564,9 +1564,9 @@ static int std_req_set_configuration(struct nbu2ss_udc *udc)
> > > > > {
> > > > > u32 config_value = (u32)(le16_to_cpu(udc->ctrl.wValue) & 0x00ff);
> > > > >
> > > > > - if ((udc->ctrl.wIndex != 0x0000) ||
> > > > > - (udc->ctrl.wLength != 0x0000) ||
> > > > > - (udc->ctrl.bRequestType != 0x00)) {
> > > > > + if (udc->ctrl.wIndex != 0x0000 ||
> > > > > + udc->ctrl.wLength != 0x0000 ||
> > > > > + udc->ctrl.bRequestType != 0x00) {
> > > > > return -EINVAL;
> > > > > }
> > > > >
> > > > > @@ -1838,8 +1838,8 @@ static void _nbu2ss_ep_done(struct nbu2ss_ep *ep,
> > > > > }
> > > > >
> > > > > #ifdef USE_DMA
> > > > > - if ((ep->direct == USB_DIR_OUT) && (ep->epnum > 0) &&
> > > > > - (req->req.dma != 0))
> > > > > + if (ep->direct == USB_DIR_OUT && ep->epnum > 0 &&
> > > > > + req->req.dma != 0)
> > > > > _nbu2ss_dma_unmap_single(udc, ep, req, USB_DIR_OUT);
> > > > > #endif
> > > > >
> > > > > @@ -1931,7 +1931,7 @@ static inline void _nbu2ss_epn_in_dma_int(struct nbu2ss_udc *udc,
> > > > > mpkt = ep->ep.maxpacket;
> > > > > size = preq->actual % mpkt;
> > > > > if (size > 0) {
> > > > > - if (((preq->actual & 0x03) == 0) && (size < mpkt))
> > > > > + if ((preq->actual & 0x03) == 0 && size < mpkt)
> > > > > _nbu2ss_ep_in_end(udc, ep->epnum, 0, 0);
> > > > > } else {
> > > > > _nbu2ss_epn_in_int(udc, ep, req);
> > > > > @@ -2428,8 +2428,8 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > > > }
> > > > >
> > > > > ep_type = usb_endpoint_type(desc);
> > > > > - if ((ep_type == USB_ENDPOINT_XFER_CONTROL) ||
> > > > > - (ep_type == USB_ENDPOINT_XFER_ISOC)) {
> > > > > + if (ep_type == USB_ENDPOINT_XFER_CONTROL ||
> > > > > + ep_type == USB_ENDPOINT_XFER_ISOC) {
> > > > > pr_err(" *** %s, bat bmAttributes\n", __func__);
> > > > > return -EINVAL;
> > > > > }
> > > > > @@ -2438,7 +2438,7 @@ static int nbu2ss_ep_enable(struct usb_ep *_ep,
> > > > > if (udc->vbus_active == 0)
> > > > > return -ESHUTDOWN;
> > > > >
> > > > > - if ((!udc->driver) || (udc->gadget.speed == USB_SPEED_UNKNOWN)) {
> > > > > + if (!udc->driver || udc->gadget.speed == USB_SPEED_UNKNOWN) {
> > > > > dev_err(ep->udc->dev, " *** %s, udc !!\n", __func__);
> > > > > return -ESHUTDOWN;
> > > > > }
> > > > > @@ -2603,8 +2603,8 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
> > > > > }
> > > > > }
> > > > >
> > > > > - if ((ep->epnum > 0) && (ep->direct == USB_DIR_OUT) &&
> > > > > - (req->req.dma != 0))
> > > > > + if (ep->epnum > 0 && ep->direct == USB_DIR_OUT &&
> > > > > + req->req.dma != 0)
> > > > > _nbu2ss_dma_map_single(udc, ep, req, USB_DIR_OUT);
> > > > > #endif
> > > > >
> > > > > --
> > > > > 2.34.1
> > > > >
> > > > >
> > > > >
> > >
>
^ permalink raw reply [flat|nested] 348+ messages in thread
* [PATCH] maple_tree: Fix a few documentation issues,
@ 2023-05-10 19:01 Thomas Gleixner
2023-05-15 19:27 ` your mail Liam R. Howlett
0 siblings, 1 reply; 348+ messages in thread
From: Thomas Gleixner @ 2023-05-10 19:01 UTC (permalink / raw)
To: LKML; +Cc: Liam R. Howlett, Matthew Wilcox, linux-mm, Shanker Donthineni
The documentation of mt_next() claims that it starts the search at the
provided index. That's incorrect as it starts the search after the provided
index.
The documentation of mt_find() is slightly confusing. "Handles locking" is
not really helpful as it does not explain how the "locking" works. Also the
documentation of index talks about a range, while in reality the index
is updated on a succesful search to the index of the found entry plus one.
Fix similar issues for mt_find_after() and mt_prev().
Remove the completely confusing and pointless "Note: Will not return the
zero entry." comment from mt_for_each() and document @__index correctly.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
include/linux/maple_tree.h | 4 +---
lib/maple_tree.c | 23 ++++++++++++++++++-----
2 files changed, 19 insertions(+), 8 deletions(-)
--- a/include/linux/maple_tree.h
+++ b/include/linux/maple_tree.h
@@ -659,10 +659,8 @@ void *mt_next(struct maple_tree *mt, uns
* mt_for_each - Iterate over each entry starting at index until max.
* @__tree: The Maple Tree
* @__entry: The current entry
- * @__index: The index to update to track the location in the tree
+ * @__index: The index to start the search from. Subsequently used as iterator.
* @__max: The maximum limit for @index
- *
- * Note: Will not return the zero entry.
*/
#define mt_for_each(__tree, __entry, __index, __max) \
for (__entry = mt_find(__tree, &(__index), __max); \
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -5947,7 +5947,10 @@ EXPORT_SYMBOL_GPL(mas_next);
* @index: The start index
* @max: The maximum index to check
*
- * Return: The entry at @index or higher, or %NULL if nothing is found.
+ * Takes RCU read lock internally to protect the search, which does not
+ * protect the returned pointer after dropping RCU read lock.
+ *
+ * Return: The entry higher than @index or %NULL if nothing is found.
*/
void *mt_next(struct maple_tree *mt, unsigned long index, unsigned long max)
{
@@ -6012,7 +6015,10 @@ EXPORT_SYMBOL_GPL(mas_prev);
* @index: The start index
* @min: The minimum index to check
*
- * Return: The entry at @index or lower, or %NULL if nothing is found.
+ * Takes RCU read lock internally to protect the search, which does not
+ * protect the returned pointer after dropping RCU read lock.
+ *
+ * Return: The entry before @index or %NULL if nothing is found.
*/
void *mt_prev(struct maple_tree *mt, unsigned long index, unsigned long min)
{
@@ -6487,9 +6493,14 @@ EXPORT_SYMBOL(mtree_destroy);
* mt_find() - Search from the start up until an entry is found.
* @mt: The maple tree
* @index: Pointer which contains the start location of the search
- * @max: The maximum value to check
+ * @max: The maximum value of the search range
+ *
+ * Takes RCU read lock internally to protect the search, which does not
+ * protect the returned pointer after dropping RCU read lock.
*
- * Handles locking. @index will be incremented to one beyond the range.
+ * In case that an entry is found @index contains the index of the found
+ * entry plus one, so it can be used as iterator index to find the next
+ * entry.
*
* Return: The entry at or after the @index or %NULL
*/
@@ -6548,7 +6559,9 @@ EXPORT_SYMBOL(mt_find);
* @index: Pointer which contains the start location of the search
* @max: The maximum value to check
*
- * Handles locking, detects wrapping on index == 0
+ * Same as mt_find() except that it checks @index for 0 before
+ * searching. If @index == 0, the search is aborted. This covers a wrap
+ * around of @index to 0 in an iterator loop.
*
* Return: The entry at or after the @index or %NULL
*/
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2023-05-10 19:01 [PATCH] maple_tree: Fix a few documentation issues, Thomas Gleixner
@ 2023-05-15 19:27 ` Liam R. Howlett
2023-05-15 21:16 ` Thomas Gleixner
2023-05-16 22:47 ` Thomas Gleixner
0 siblings, 2 replies; 348+ messages in thread
From: Liam R. Howlett @ 2023-05-15 19:27 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Matthew Wilcox, linux-mm, Shanker Donthineni
* Thomas Gleixner <tglx@linutronix.de> [230510 15:01]:
> The documentation of mt_next() claims that it starts the search at the
> provided index. That's incorrect as it starts the search after the provided
> index.
>
> The documentation of mt_find() is slightly confusing. "Handles locking" is
> not really helpful as it does not explain how the "locking" works.
More locking notes can be found in Documentation/core-api/maple_tree.rst
which lists mt_find() under the "Takes RCU read lock" list. I'm okay
with duplicating the comment of taking the RCU read lock in here.
>Also the
> documentation of index talks about a range, while in reality the index
> is updated on a succesful search to the index of the found entry plus one.
This is a range based tree, so the index is incremented beyond the last
entry which would return the entry. That is, if you search for 5 and
there is an entry at 4-100, the index would be 101 after the search -
or, one beyond the range. If you have single entries at a specific
index, then index would be equal to last and it would be one beyond the
index you found - but only because index == last in this case.
>
> Fix similar issues for mt_find_after() and mt_prev().
>
> Remove the completely confusing and pointless "Note: Will not return the
> zero entry." comment from mt_for_each() and document @__index correctly.
The zero entry concept is an advanced API concept which allows you to
store something that cannot be seen by the mt_* family of users, so it
will not be returned and, instead, it will return NULL. Think of it as
a reservation for an entry that isn't fully initialized. Perhaps it
should read "Will not return the XA_ZERO_ENTRY" ?
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> include/linux/maple_tree.h | 4 +---
> lib/maple_tree.c | 23 ++++++++++++++++++-----
> 2 files changed, 19 insertions(+), 8 deletions(-)
>
> --- a/include/linux/maple_tree.h
> +++ b/include/linux/maple_tree.h
> @@ -659,10 +659,8 @@ void *mt_next(struct maple_tree *mt, uns
> * mt_for_each - Iterate over each entry starting at index until max.
> * @__tree: The Maple Tree
> * @__entry: The current entry
> - * @__index: The index to update to track the location in the tree
> + * @__index: The index to start the search from. Subsequently used as iterator.
> * @__max: The maximum limit for @index
> - *
> - * Note: Will not return the zero entry.
This function "will not return the zero entry", meaning it will return
NULL if xa_is_zero(entry).
> */
> #define mt_for_each(__tree, __entry, __index, __max) \
> for (__entry = mt_find(__tree, &(__index), __max); \
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -5947,7 +5947,10 @@ EXPORT_SYMBOL_GPL(mas_next);
> * @index: The start index
> * @max: The maximum index to check
> *
> - * Return: The entry at @index or higher, or %NULL if nothing is found.
> + * Takes RCU read lock internally to protect the search, which does not
> + * protect the returned pointer after dropping RCU read lock.
> + *
> + * Return: The entry higher than @index or %NULL if nothing is found.
> */
> void *mt_next(struct maple_tree *mt, unsigned long index, unsigned long max)
> {
> @@ -6012,7 +6015,10 @@ EXPORT_SYMBOL_GPL(mas_prev);
> * @index: The start index
> * @min: The minimum index to check
> *
> - * Return: The entry at @index or lower, or %NULL if nothing is found.
> + * Takes RCU read lock internally to protect the search, which does not
> + * protect the returned pointer after dropping RCU read lock.
> + *
> + * Return: The entry before @index or %NULL if nothing is found.
> */
> void *mt_prev(struct maple_tree *mt, unsigned long index, unsigned long min)
> {
> @@ -6487,9 +6493,14 @@ EXPORT_SYMBOL(mtree_destroy);
> * mt_find() - Search from the start up until an entry is found.
> * @mt: The maple tree
> * @index: Pointer which contains the start location of the search
> - * @max: The maximum value to check
> + * @max: The maximum value of the search range
> + *
> + * Takes RCU read lock internally to protect the search, which does not
> + * protect the returned pointer after dropping RCU read lock.
> *
> - * Handles locking. @index will be incremented to one beyond the range.
> + * In case that an entry is found @index contains the index of the found
> + * entry plus one, so it can be used as iterator index to find the next
> + * entry.
What about:
"In case that an entry is found @index contains the last index of the
found entry plus one"
> *
> * Return: The entry at or after the @index or %NULL
> */
> @@ -6548,7 +6559,9 @@ EXPORT_SYMBOL(mt_find);
> * @index: Pointer which contains the start location of the search
> * @max: The maximum value to check
> *
> - * Handles locking, detects wrapping on index == 0
> + * Same as mt_find() except that it checks @index for 0 before
> + * searching. If @index == 0, the search is aborted. This covers a wrap
> + * around of @index to 0 in an iterator loop.
> *
> * Return: The entry at or after the @index or %NULL
> */
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2023-05-15 19:27 ` your mail Liam R. Howlett
@ 2023-05-15 21:16 ` Thomas Gleixner
2023-05-16 22:47 ` Thomas Gleixner
1 sibling, 0 replies; 348+ messages in thread
From: Thomas Gleixner @ 2023-05-15 21:16 UTC (permalink / raw)
To: Liam R. Howlett; +Cc: LKML, Matthew Wilcox, linux-mm, Shanker Donthineni
Liam!
On Mon, May 15 2023 at 15:27, Liam R. Howlett wrote:
> * Thomas Gleixner <tglx@linutronix.de> [230510 15:01]:
>>Also the
>> documentation of index talks about a range, while in reality the index
>> is updated on a succesful search to the index of the found entry plus one.
>
> This is a range based tree, so the index is incremented beyond the last
> entry which would return the entry. That is, if you search for 5 and
> there is an entry at 4-100, the index would be 101 after the search -
> or, one beyond the range. If you have single entries at a specific
> index, then index would be equal to last and it would be one beyond the
> index you found - but only because index == last in this case.
Thanks for the explanation
>>
>> Fix similar issues for mt_find_after() and mt_prev().
>>
>> Remove the completely confusing and pointless "Note: Will not return the
>> zero entry." comment from mt_for_each() and document @__index correctly.
>
> The zero entry concept is an advanced API concept which allows you to
> store something that cannot be seen by the mt_* family of users, so it
> will not be returned and, instead, it will return NULL. Think of it as
> a reservation for an entry that isn't fully initialized. Perhaps it
> should read "Will not return the XA_ZERO_ENTRY" ?
That makes actually sense.
>> --- a/include/linux/maple_tree.h
>> +++ b/include/linux/maple_tree.h
>> @@ -659,10 +659,8 @@ void *mt_next(struct maple_tree *mt, uns
>> * mt_for_each - Iterate over each entry starting at index until max.
>> * @__tree: The Maple Tree
>> * @__entry: The current entry
>> - * @__index: The index to update to track the location in the tree
>> + * @__index: The index to start the search from. Subsequently used as iterator.
>> * @__max: The maximum limit for @index
>> - *
>> - * Note: Will not return the zero entry.
>
> This function "will not return the zero entry", meaning it will return
> NULL if xa_is_zero(entry).
Ack.
>> + * Takes RCU read lock internally to protect the search, which does not
>> + * protect the returned pointer after dropping RCU read lock.
>> *
>> - * Handles locking. @index will be incremented to one beyond the range.
>> + * In case that an entry is found @index contains the index of the found
>> + * entry plus one, so it can be used as iterator index to find the next
>> + * entry.
>
> What about:
> "In case that an entry is found @index contains the last index of the
> found entry plus one"
Something like that, yes.
Let me try again.
Thanks,
tglx
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2023-05-15 19:27 ` your mail Liam R. Howlett
2023-05-15 21:16 ` Thomas Gleixner
@ 2023-05-16 22:47 ` Thomas Gleixner
2023-05-23 13:46 ` Liam R. Howlett
1 sibling, 1 reply; 348+ messages in thread
From: Thomas Gleixner @ 2023-05-16 22:47 UTC (permalink / raw)
To: Liam R. Howlett; +Cc: LKML, Matthew Wilcox, linux-mm, Shanker Donthineni
On Mon, May 15 2023 at 15:27, Liam R. Howlett wrote:
> * Thomas Gleixner <tglx@linutronix.de> [230510 15:01]:
>> The documentation of mt_next() claims that it starts the search at the
>> provided index. That's incorrect as it starts the search after the provided
>> index.
>>
>> The documentation of mt_find() is slightly confusing. "Handles locking" is
>> not really helpful as it does not explain how the "locking" works.
>
> More locking notes can be found in Documentation/core-api/maple_tree.rst
> which lists mt_find() under the "Takes RCU read lock" list. I'm okay
> with duplicating the comment of taking the RCU read lock in here.
Without a reference to the actual locking documentation such comments
are not super helpful.
>> Fix similar issues for mt_find_after() and mt_prev().
>>
>> Remove the completely confusing and pointless "Note: Will not return the
>> zero entry." comment from mt_for_each() and document @__index correctly.
>
> The zero entry concept is an advanced API concept which allows you to
> store something that cannot be seen by the mt_* family of users, so it
> will not be returned and, instead, it will return NULL. Think of it as
> a reservation for an entry that isn't fully initialized. Perhaps it
> should read "Will not return the XA_ZERO_ENTRY" ?
>>
>> - *
>> - * Note: Will not return the zero entry.
>
> This function "will not return the zero entry", meaning it will return
> NULL if xa_is_zero(entry).
If I understand correctly, this translates to:
This iterator skips entries, which have been reserved for future use
but have not yet been fully initialized.
Right?
>> @@ -6487,9 +6493,14 @@ EXPORT_SYMBOL(mtree_destroy);
>> * mt_find() - Search from the start up until an entry is found.
>> * @mt: The maple tree
>> * @index: Pointer which contains the start location of the search
>> - * @max: The maximum value to check
>> + * @max: The maximum value of the search range
>> + *
>> + * Takes RCU read lock internally to protect the search, which does not
>> + * protect the returned pointer after dropping RCU read lock.
>> *
>> - * Handles locking. @index will be incremented to one beyond the range.
>> + * In case that an entry is found @index contains the index of the found
>> + * entry plus one, so it can be used as iterator index to find the next
>> + * entry.
>
> What about:
> "In case that an entry is found @index contains the last index of the
> found entry plus one"
Still confusing to the casual reader like me :)
"In case that an entry is found @index is updated to point to the next
possible entry independent whether the found entry is occupying a
single index or a range if indices."
Hmm?
Thanks,
tglx
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2023-05-16 22:47 ` Thomas Gleixner
@ 2023-05-23 13:46 ` Liam R. Howlett
0 siblings, 0 replies; 348+ messages in thread
From: Liam R. Howlett @ 2023-05-23 13:46 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Matthew Wilcox, linux-mm, Shanker Donthineni
* Thomas Gleixner <tglx@linutronix.de> [230516 18:48]:
> On Mon, May 15 2023 at 15:27, Liam R. Howlett wrote:
> > * Thomas Gleixner <tglx@linutronix.de> [230510 15:01]:
> >> The documentation of mt_next() claims that it starts the search at the
> >> provided index. That's incorrect as it starts the search after the provided
> >> index.
> >>
> >> The documentation of mt_find() is slightly confusing. "Handles locking" is
> >> not really helpful as it does not explain how the "locking" works.
> >
> > More locking notes can be found in Documentation/core-api/maple_tree.rst
> > which lists mt_find() under the "Takes RCU read lock" list. I'm okay
> > with duplicating the comment of taking the RCU read lock in here.
>
> Without a reference to the actual locking documentation such comments
> are not super helpful.
Noted. A reference to the larger document should probably be added.
Thanks.
>
> >> Fix similar issues for mt_find_after() and mt_prev().
> >>
> >> Remove the completely confusing and pointless "Note: Will not return the
> >> zero entry." comment from mt_for_each() and document @__index correctly.
> >
> > The zero entry concept is an advanced API concept which allows you to
> > store something that cannot be seen by the mt_* family of users, so it
> > will not be returned and, instead, it will return NULL. Think of it as
> > a reservation for an entry that isn't fully initialized. Perhaps it
> > should read "Will not return the XA_ZERO_ENTRY" ?
> >>
> >> - *
> >> - * Note: Will not return the zero entry.
> >
> > This function "will not return the zero entry", meaning it will return
> > NULL if xa_is_zero(entry).
>
> If I understand correctly, this translates to:
>
> This iterator skips entries, which have been reserved for future use
> but have not yet been fully initialized.
>
> Right?
Well, that's one use of using the XA_ZERO_ENTRY, but it's really up to
the user to decide why they are adding something that returns NULL in a
specific range for the not-advanced API. It might be worth adding the
XA_ZERO_ENTRY in here, since that's the only special value right now?
>
> >> @@ -6487,9 +6493,14 @@ EXPORT_SYMBOL(mtree_destroy);
> >> * mt_find() - Search from the start up until an entry is found.
> >> * @mt: The maple tree
> >> * @index: Pointer which contains the start location of the search
> >> - * @max: The maximum value to check
> >> + * @max: The maximum value of the search range
> >> + *
> >> + * Takes RCU read lock internally to protect the search, which does not
> >> + * protect the returned pointer after dropping RCU read lock.
> >> *
> >> - * Handles locking. @index will be incremented to one beyond the range.
> >> + * In case that an entry is found @index contains the index of the found
> >> + * entry plus one, so it can be used as iterator index to find the next
> >> + * entry.
> >
> > What about:
> > "In case that an entry is found @index contains the last index of the
> > found entry plus one"
>
> Still confusing to the casual reader like me :)
>
> "In case that an entry is found @index is updated to point to the next
> possible entry independent whether the found entry is occupying a
> single index or a range if indices."
>
> Hmm?
That makes sense to me.
Thanks,
Liam
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <CAP7CzPfLu6mm6f2fon-zez3PW6rDACEH6ihF2aG+1Dc7Zc2WuQ@mail.gmail.com>]
* Re: your mail
[not found] <CAP7CzPfLu6mm6f2fon-zez3PW6rDACEH6ihF2aG+1Dc7Zc2WuQ@mail.gmail.com>
@ 2021-09-13 6:06 ` Willy Tarreau
0 siblings, 0 replies; 348+ messages in thread
From: Willy Tarreau @ 2021-09-13 6:06 UTC (permalink / raw)
To: zhao xc
Cc: tglx, peterz, keescook, mingo, joe, john.garry, song.bao.hua,
linux-kernel
Hi,
On Mon, Sep 13, 2021 at 01:32:51PM +0800, zhao xc wrote:
> Hi maintainer:
> delete blank line between two enum definitions
Could you please make sure to place a subject (and a meaningful one) in
the "subject" field of your e-mails ? There's nothing more annoying than
receiving messages with no subject and having to read them to figure you
were not interested!
Thanks,
Willy
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2021-08-21 8:59 Kari Argillander
2021-08-22 13:13 ` your mail CGEL
0 siblings, 1 reply; 348+ messages in thread
From: Kari Argillander @ 2021-08-21 8:59 UTC (permalink / raw)
To: cgel.zte
Cc: viro, christian.brauner, jamorris, gladkov.alexey, yang.yang29,
tj, paul.gortmaker, linux-fsdevel, linux-kernel, Zeal Robot
Bcc:
Subject: Re: [PATCH] proc: prevent mount proc on same mountpoint in one pid
namespace
Reply-To:
In-Reply-To: <20210821083105.30336-1-yang.yang29@zte.com.cn>
On Sat, Aug 21, 2021 at 01:31:05AM -0700, cgel.zte@gmail.com wrote:
> From: Yang Yang <yang.yang29@zte.com.cn>
>
> Patch "proc: allow to mount many instances of proc in one pid namespace"
> aims to mount many instances of proc on different mountpoint, see
> tools/testing/selftests/proc/proc-multiple-procfs.c.
>
> But there is a side-effects, user can mount many instances of proc on
> the same mountpoint in one pid namespace, which is not allowed before.
> This duplicate mount makes no sense but wastes memory and CPU, and user
> may be confused why kernel allows it.
>
> The logic of this patch is: when try to mount proc on /mnt, check if
> there is a proc instance mount on /mnt in the same pid namespace. If
> answer is yes, return -EBUSY.
>
> Since this check can't be done in proc_get_tree(), which call
> get_tree_nodev() and will create new super_block unconditionally.
> And other nodev fs may faces the same case, so add a new hook in
> fs_context_operations.
>
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Signed-off-by: Yang Yang <yang.yang29@zte.com.cn>
> ---
> fs/namespace.c | 9 +++++++++
> fs/proc/root.c | 15 +++++++++++++++
> include/linux/fs_context.h | 1 +
> 3 files changed, 25 insertions(+)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index f79d9471cb76..84da649a70c5 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2878,6 +2878,7 @@ static int do_new_mount_fc(struct fs_context *fc, struct path *mountpoint,
> static int do_new_mount(struct path *path, const char *fstype, int sb_flags,
> int mnt_flags, const char *name, void *data)
> {
> + int (*check_mntpoint)(struct fs_context *fc, struct path *path);
> struct file_system_type *type;
> struct fs_context *fc;
> const char *subtype = NULL;
> @@ -2906,6 +2907,13 @@ static int do_new_mount(struct path *path, const char *fstype, int sb_flags,
> if (IS_ERR(fc))
> return PTR_ERR(fc);
>
> + /* check if there is a same super_block mount on path*/
> + check_mntpoint = fc->ops->check_mntpoint;
> + if (check_mntpoint)
> + err = check_mntpoint(fc, path);
> + if (err < 0)
> + goto err_fc;
> +
> if (subtype)
> err = vfs_parse_fs_string(fc, "subtype",
> subtype, strlen(subtype));
> @@ -2920,6 +2928,7 @@ static int do_new_mount(struct path *path, const char *fstype, int sb_flags,
> if (!err)
> err = do_new_mount_fc(fc, path, mnt_flags);
>
> +err_fc:
> put_fs_context(fc);
> return err;
> }
> diff --git a/fs/proc/root.c b/fs/proc/root.c
> index c7e3b1350ef8..0971d6b0bec2 100644
> --- a/fs/proc/root.c
> +++ b/fs/proc/root.c
> @@ -237,11 +237,26 @@ static void proc_fs_context_free(struct fs_context *fc)
> kfree(ctx);
> }
>
> +static int proc_check_mntpoint(struct fs_context *fc, struct path *path)
> +{
> + struct super_block *mnt_sb = path->mnt->mnt_sb;
> + struct proc_fs_info *fs_info;
> +
> + if (strcmp(mnt_sb->s_type->name, "proc") == 0) {
> + fs_info = mnt_sb->s_fs_info;
> + if (fs_info->pid_ns == task_active_pid_ns(current) &&
> + path->mnt->mnt_root == path->dentry)
> + return -EBUSY;
> + }
> + return 0;
> +}
> +
> static const struct fs_context_operations proc_fs_context_ops = {
> .free = proc_fs_context_free,
> .parse_param = proc_parse_param,
> .get_tree = proc_get_tree,
> .reconfigure = proc_reconfigure,
> + .check_mntpoint = proc_check_mntpoint,
> };
>
> static int proc_init_fs_context(struct fs_context *fc)
> diff --git a/include/linux/fs_context.h b/include/linux/fs_context.h
> index 6b54982fc5f3..090a05fb2d7d 100644
> --- a/include/linux/fs_context.h
> +++ b/include/linux/fs_context.h
> @@ -119,6 +119,7 @@ struct fs_context_operations {
> int (*parse_monolithic)(struct fs_context *fc, void *data);
> int (*get_tree)(struct fs_context *fc);
> int (*reconfigure)(struct fs_context *fc);
> + int (*check_mntpoint)(struct fs_context *fc, struct path *path);
Don't you think this should be it's own patch. It is after all internal
api change. This also needs documentation. It would be confusing if
someone convert to new mount api and there is one line which just
address some proc stuff but even commit message does not address does
every fs needs to add this.
Documentation is very good shape right now and we are in face that
everyone is migrating to use new mount api so everyting should be well
documented.
> };
>
> /*
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2021-08-21 8:59 Kari Argillander
@ 2021-08-22 13:13 ` CGEL
0 siblings, 0 replies; 348+ messages in thread
From: CGEL @ 2021-08-22 13:13 UTC (permalink / raw)
To: Kari Argillander
Cc: viro, christian.brauner, jamorris, gladkov.alexey, yang.yang29,
tj, paul.gortmaker, linux-fsdevel, linux-kernel, Zeal Robot
O
Sat, Aug 21, 2021 at 11:59:39AM +0300, Kari Argillander wrote:
> Bcc:
> Subject: Re: [PATCH] proc: prevent mount proc on same mountpoint in one pid
> namespace
> Reply-To:
> In-Reply-To: <20210821083105.30336-1-yang.yang29@zte.com.cn>
>
> On Sat, Aug 21, 2021 at 01:31:05AM -0700, cgel.zte@gmail.com wrote:
> > From: Yang Yang <yang.yang29@zte.com.cn>
> >
> > Patch "proc: allow to mount many instances of proc in one pid namespace"
> > aims to mount many instances of proc on different mountpoint, see
> > tools/testing/selftests/proc/proc-multiple-procfs.c.
> >
> > But there is a side-effects, user can mount many instances of proc on
> > the same mountpoint in one pid namespace, which is not allowed before.
> > This duplicate mount makes no sense but wastes memory and CPU, and user
> > may be confused why kernel allows it.
> >
> > The logic of this patch is: when try to mount proc on /mnt, check if
> > there is a proc instance mount on /mnt in the same pid namespace. If
> > answer is yes, return -EBUSY.
> >
> > Since this check can't be done in proc_get_tree(), which call
> > get_tree_nodev() and will create new super_block unconditionally.
> > And other nodev fs may faces the same case, so add a new hook in
> > fs_context_operations.
> >
> > Reported-by: Zeal Robot <zealci@zte.com.cn>
> > Signed-off-by: Yang Yang <yang.yang29@zte.com.cn>
> > ---
> > fs/namespace.c | 9 +++++++++
> > fs/proc/root.c | 15 +++++++++++++++
> > include/linux/fs_context.h | 1 +
> > 3 files changed, 25 insertions(+)
> >
> > diff --git a/fs/namespace.c b/fs/namespace.c
> > index f79d9471cb76..84da649a70c5 100644
> > --- a/fs/namespace.c
> > +++ b/fs/namespace.c
> > @@ -2878,6 +2878,7 @@ static int do_new_mount_fc(struct fs_context *fc, struct path *mountpoint,
> > static int do_new_mount(struct path *path, const char *fstype, int sb_flags,
> > int mnt_flags, const char *name, void *data)
> > {
> > + int (*check_mntpoint)(struct fs_context *fc, struct path *path);
> > struct file_system_type *type;
> > struct fs_context *fc;
> > const char *subtype = NULL;
> > @@ -2906,6 +2907,13 @@ static int do_new_mount(struct path *path, const char *fstype, int sb_flags,
> > if (IS_ERR(fc))
> > return PTR_ERR(fc);
> >
> > + /* check if there is a same super_block mount on path*/
> > + check_mntpoint = fc->ops->check_mntpoint;
> > + if (check_mntpoint)
> > + err = check_mntpoint(fc, path);
> > + if (err < 0)
> > + goto err_fc;
> > +
> > if (subtype)
> > err = vfs_parse_fs_string(fc, "subtype",
> > subtype, strlen(subtype));
> > @@ -2920,6 +2928,7 @@ static int do_new_mount(struct path *path, const char *fstype, int sb_flags,
> > if (!err)
> > err = do_new_mount_fc(fc, path, mnt_flags);
> >
> > +err_fc:
> > put_fs_context(fc);
> > return err;
> > }
> > diff --git a/fs/proc/root.c b/fs/proc/root.c
> > index c7e3b1350ef8..0971d6b0bec2 100644
> > --- a/fs/proc/root.c
> > +++ b/fs/proc/root.c
> > @@ -237,11 +237,26 @@ static void proc_fs_context_free(struct fs_context *fc)
> > kfree(ctx);
> > }
> >
> > +static int proc_check_mntpoint(struct fs_context *fc, struct path *path)
> > +{
> > + struct super_block *mnt_sb = path->mnt->mnt_sb;
> > + struct proc_fs_info *fs_info;
> > +
> > + if (strcmp(mnt_sb->s_type->name, "proc") == 0) {
> > + fs_info = mnt_sb->s_fs_info;
> > + if (fs_info->pid_ns == task_active_pid_ns(current) &&
> > + path->mnt->mnt_root == path->dentry)
> > + return -EBUSY;
> > + }
> > + return 0;
> > +}
> > +
> > static const struct fs_context_operations proc_fs_context_ops = {
> > .free = proc_fs_context_free,
> > .parse_param = proc_parse_param,
> > .get_tree = proc_get_tree,
> > .reconfigure = proc_reconfigure,
> > + .check_mntpoint = proc_check_mntpoint,
> > };
> >
> > static int proc_init_fs_context(struct fs_context *fc)
> > diff --git a/include/linux/fs_context.h b/include/linux/fs_context.h
> > index 6b54982fc5f3..090a05fb2d7d 100644
> > --- a/include/linux/fs_context.h
> > +++ b/include/linux/fs_context.h
> > @@ -119,6 +119,7 @@ struct fs_context_operations {
> > int (*parse_monolithic)(struct fs_context *fc, void *data);
> > int (*get_tree)(struct fs_context *fc);
> > int (*reconfigure)(struct fs_context *fc);
> > + int (*check_mntpoint)(struct fs_context *fc, struct path *path);
>
> Don't you think this should be it's own patch. It is after all internal
> api change. This also needs documentation. It would be confusing if
> someone convert to new mount api and there is one line which just
> address some proc stuff but even commit message does not address does
> every fs needs to add this.
>
> Documentation is very good shape right now and we are in face that
> everyone is migrating to use new mount api so everyting should be well
> documented.
> i
Thanks for your reply!
I will take commit message more carefully next time.
Sinece I am not quit sure about this patch, so I didn't write
Documentation for patch v1. AIViro had made it clear, so this
patch is abondoned.
> > };
> >
> > /*
> > --
> > 2.25.1
> >
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2021-08-16 2:46 Kari Argillander
2021-08-16 12:27 ` your mail Christoph Hellwig
0 siblings, 1 reply; 348+ messages in thread
From: Kari Argillander @ 2021-08-16 2:46 UTC (permalink / raw)
To: Konstantin Komarov, Christoph Hellwig
Cc: Kari Argillander, ntfs3, linux-kernel, linux-fsdevel,
Pali Rohár, Matthew Wilcox
Date: Mon, 16 Aug 2021 04:08:46 +0300
Subject: [RFC PATCH 0/4] fs/ntfs3: Use new mount api and change some opts
This series modify ntfs3 to use new mount api as Christoph Hellwig wish
for.
https://lore.kernel.org/linux-fsdevel/20210810090234.GA23732@lst.de/
It also modify mount options noatime (not needed) and make new alias
for nls because kernel is changing to use it as described in here
https://lore.kernel.org/linux-fsdevel/20210808162453.1653-1-pali@kernel.org/
I would like really like to get fsparam_flag_no also for no_acs_rules
but then we have to make new name for it. Other possibility is to
modify mount api so it mount option can be no/no_. I think that would
maybe be good change.
I did not quite like how I did nls table loading because now it always
first load default table and if user give option then default table is
dropped and if reconfigure is happening and this was same as before then
it is dropped. I try to make loading in fill_super and fs_reconfigure
but that just look ugly. This is quite readible so I leave it like this.
We also do not mount/remount so often that this probebly does not
matter. It seems that if new mount api had possibility to give default
value for mount option then there is not this kind of problem.
I would hope that these will added top of the now going ntfs3 patch
series. I do not have so many contributions to kernel yet and I would
like to get my name going there so that in future it would be easier to
contribute kernel.
Kari Argillander (4):
fs/ntfs3: Use new api for mounting
fs/ntfs3: Remove unnecesarry mount option noatime
fs/ntfs3: Make mount option nohidden more universal
fs/ntfs3: Add iocharset= mount option as alias for nls=
Documentation/filesystems/ntfs3.rst | 4 -
fs/ntfs3/super.c | 391 ++++++++++++++--------------
2 files changed, 196 insertions(+), 199 deletions(-)
--
2.25.1
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2021-08-16 2:46 Kari Argillander
@ 2021-08-16 12:27 ` Christoph Hellwig
0 siblings, 0 replies; 348+ messages in thread
From: Christoph Hellwig @ 2021-08-16 12:27 UTC (permalink / raw)
To: Kari Argillander
Cc: Konstantin Komarov, Christoph Hellwig, ntfs3, linux-kernel,
linux-fsdevel, Pali Rohár, Matthew Wilcox
On Mon, Aug 16, 2021 at 05:46:59AM +0300, Kari Argillander wrote:
> I would like really like to get fsparam_flag_no also for no_acs_rules
> but then we have to make new name for it. Other possibility is to
> modify mount api so it mount option can be no/no_. I think that would
> maybe be good change.
I don't think adding another no_ alias is a good idea. I'd suggest
to just rename the existing flag before the ntfs3 driver ever hits
mainline.
^ permalink raw reply [flat|nested] 348+ messages in thread
* [PATCH] drivers/gpu/drm/ttm/ttm_page_allo.c: adjust ttm pages refcount fix the bug: Feb 6 17:13:13 aaa-PC kernel: [ 466.271034] BUG: Bad page state in process blur_image pfn:7aee2 Feb 6 17:13:13 aaa-PC kernel: [ 466.271037] page:980000025fca4170 count:0 mapcount:0 mapping:980000025a0dca60 index:0x0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271039] flags: 0x1e01fff000000() Feb 6 17:13:13 aaa-PC kernel: [ 466.271042] raw: 0001e01fff000000 0000000000000100 0000000000000200 980000025a0dca60 Feb 6 17:13:13 aaa-PC kernel: [ 466.271044] raw: 0000000000000000 0000000000000000 00000000ffffffff Feb 6 17:13:13 aaa-PC kernel: [ 466.271046] page dumped because: non-NULL mapping Feb 6 17:13:13 aaa-PC kernel: [ 466.271047] Modules linked in: bnep fuse bluetooth ecdh_generic sha256_generic cfg80211 rfkill vfat fat serio_raw uio_pdrv_genirq binfmt_misc ip_tables amdgpu chash radeon r8168 loongson gpu_sched Feb 6 17:13:13 aaa-PC kernel: [ 466.271059] CPU: 3 PID: 9554 Comm: blur_image Tainted: G B 4.19.0-loongson-3-desktop #3036 Feb 6 17:13:13 aaa-PC kernel: [ 466.271061] Hardware name: Haier Kunlun-LS3A4000-LS7A-desktop/Kunlun-LS3A4000-LS7A-desktop, BIOS Kunlun-V4.0.12V4.0 LS3A4000 03/19/2020 Feb 6 17:13:13 aaa-PC kernel: [ 466.271063] Stack : 000000000000007b 000000007400cce0 0000000000000000 0000000000000007 Feb 6 17:13:13 aaa-PC kernel: [ 466.271067] 0000000000000000 0000000000000000 0000000000002a82 ffffffff8202c910 Feb 6 17:13:13 aaa-PC kernel: [ 466.271070] 0000000000000000 0000000000002a82 0000000000000000 ffffffff81e20000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271074] 0000000000000000 ffffffff8021301c ffffffff82040000 6e754b20534f4942 Feb 6 17:13:13 aaa-PC kernel: [ 466.271078] ffff000000000000 0000000000000000 000000007400cce0 0000000000000000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271082] 9800000007155d40 ffffffff81cc5470 0000000000000005 6db6db6db6db0000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271086] 0000000000000003 fffffffffffffffb 0000000000006000 98000002559f4000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271090] 980000024a448000 980000024a44b7f0 9800000007155d50 ffffffff819f5158 Feb 6 17:13:13 aaa-PC kernel: [ 466.271094] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271097] 9800000007155d40 ffffffff802310c4 ffffffff81e70000 ffffffff819f5158 Feb 6 17:13:13 aaa-PC kernel: [ 466.271101] ... Feb 6 17:13:13 aaa-PC kernel: [ 466.271103] Call Trace: Feb 6 17:13:13 aaa-PC kernel: [ 466.271107] [<ffffffff802310c4>] show_stack+0x44/0x1c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271110] [<ffffffff819f5158>] dump_stack+0x1d8/0x240 Feb 6 17:13:13 aaa-PC kernel: [ 466.271113] [<ffffffff80491c10>] bad_page+0x210/0x2c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271116] [<ffffffff804931c8>] free_pcppages_bulk+0x708/0x900 Feb 6 17:13:13 aaa-PC kernel: [ 46 6.271119] [<ffffffff804980cc>] free_unref_page_list+0x1cc/0x2c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271122] [<ffffffff804ad2c8>] release_pages+0x648/0x900 Feb 6 17:13:13 aaa-PC kernel: [ 466.271125] [<ffffffff804f3b48>] tlb_flush_mmu_free+0x88/0x100 Feb 6 17:13:13 aaa-PC kernel: [ 466.271128] [<ffffffff804f8a24>] zap_pte_range+0xa24/0x1480 Feb 6 17:13:13 aaa-PC kernel: [ 466.271132] [<ffffffff804f98b0>] unmap_page_range+0x1f0/0x500 Feb 6 17:13:13 aaa-PC kernel: [ 466.271135] [<ffffffff804fa054>] unmap_vmas+0x154/0x200 Feb 6 17:13:13 aaa-PC kernel: [ 466.271138] [<ffffffff8051190c>] exit_mmap+0x20c/0x380 Feb 6 17:13:13 aaa-PC kernel: [ 466.271142] [<ffffffff802bb9c8>] mmput+0x148/0x300 Feb 6 17:13:13 aaa-PC kernel: [ 466.271145] [<ffffffff802c80d8>] do_exit+0x6d8/0x1900 Feb 6 17:13:13 aaa-PC kernel: [ 466.271148] [<ffffffff802cb288>] do_group_exit+0x88/0x1c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271151] [<ffffffff802cb3d8>] sys_exit_group+0x18/0x40 Feb 6 17 :13:13 aaa-PC kernel: [ 466.271155] [<ffffffff8023f954>] syscall_common+0x34/0xa4
@ 2021-04-07 1:27 songqiang
2021-04-07 8:25 ` your mail Huang Rui
0 siblings, 1 reply; 348+ messages in thread
From: songqiang @ 2021-04-07 1:27 UTC (permalink / raw)
To: christian.koenig, ray.huang, airlied, daniel
Cc: dri-devel, linux-kernel, songqiang
Signed-off-by: songqiang <songqiang@uniontech.com>
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 14660f723f71..f3698f0ad4d7 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -736,8 +736,16 @@ static void ttm_put_pages(struct page **pages, unsigned npages, int flags,
if (++p != pages[i + j])
break;
- if (j == HPAGE_PMD_NR)
+ if (j == HPAGE_PMD_NR) {
order = HPAGE_PMD_ORDER;
+ for (j = 1; j < HPAGE_PMD_NR; ++j)
+ page_ref_dec(pages[i+j]);
+ }
}
#endif
@@ -868,10 +876,12 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,
p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
if (!p)
break;
-
- for (j = 0; j < HPAGE_PMD_NR; ++j)
+ for (j = 0; j < HPAGE_PMD_NR; ++j) {
pages[i++] = p++;
-
+ if (j > 0)
+ page_ref_inc(pages[i-1]);
+ }
npages -= HPAGE_PMD_NR;
}
}
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2021-04-07 1:27 [PATCH] drivers/gpu/drm/ttm/ttm_page_allo.c: adjust ttm pages refcount fix the bug: Feb 6 17:13:13 aaa-PC kernel: [ 466.271034] BUG: Bad page state in process blur_image pfn:7aee2 Feb 6 17:13:13 aaa-PC kernel: [ 466.271037] page:980000025fca4170 count:0 mapcount:0 mapping:980000025a0dca60 index:0x0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271039] flags: 0x1e01fff000000() Feb 6 17:13:13 aaa-PC kernel: [ 466.271042] raw: 0001e01fff000000 0000000000000100 0000000000000200 980000025a0dca60 Feb 6 17:13:13 aaa-PC kernel: [ 466.271044] raw: 0000000000000000 0000000000000000 00000000ffffffff Feb 6 17:13:13 aaa-PC kernel: [ 466.271046] page dumped because: non-NULL mapping Feb 6 17:13:13 aaa-PC kernel: [ 466.271047] Modules linked in: bnep fuse bluetooth ecdh_generic sha256_generic cfg80211 rfkill vfat fat serio_raw uio_pdrv_genirq binfmt_misc ip_tables amdgpu chash radeon r8168 loongson gpu_sched Feb 6 17:13:13 aaa-PC kernel: [ 466.271059] CPU: 3 PID: 9554 Comm: blur_image Tainted: G B 4.19.0-loongson-3-desktop #3036 Feb 6 17:13:13 aaa-PC kernel: [ 466.271061] Hardware name: Haier Kunlun-LS3A4000-LS7A-desktop/Kunlun-LS3A4000-LS7A-desktop, BIOS Kunlun-V4.0.12V4.0 LS3A4000 03/19/2020 Feb 6 17:13:13 aaa-PC kernel: [ 466.271063] Stack : 000000000000007b 000000007400cce0 0000000000000000 0000000000000007 Feb 6 17:13:13 aaa-PC kernel: [ 466.271067] 0000000000000000 0000000000000000 0000000000002a82 ffffffff8202c910 Feb 6 17:13:13 aaa-PC kernel: [ 466.271070] 0000000000000000 0000000000002a82 0000000000000000 ffffffff81e20000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271074] 0000000000000000 ffffffff8021301c ffffffff82040000 6e754b20534f4942 Feb 6 17:13:13 aaa-PC kernel: [ 466.271078] ffff000000000000 0000000000000000 000000007400cce0 0000000000000000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271082] 9800000007155d40 ffffffff81cc5470 0000000000000005 6db6db6db6db0000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271086] 0000000000000003 fffffffffffffffb 0000000000006000 98000002559f4000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271090] 980000024a448000 980000024a44b7f0 9800000007155d50 ffffffff819f5158 Feb 6 17:13:13 aaa-PC kernel: [ 466.271094] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Feb 6 17:13:13 aaa-PC kernel: [ 466.271097] 9800000007155d40 ffffffff802310c4 ffffffff81e70000 ffffffff819f5158 Feb 6 17:13:13 aaa-PC kernel: [ 466.271101] ... Feb 6 17:13:13 aaa-PC kernel: [ 466.271103] Call Trace: Feb 6 17:13:13 aaa-PC kernel: [ 466.271107] [<ffffffff802310c4>] show_stack+0x44/0x1c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271110] [<ffffffff819f5158>] dump_stack+0x1d8/0x240 Feb 6 17:13:13 aaa-PC kernel: [ 466.271113] [<ffffffff80491c10>] bad_page+0x210/0x2c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271116] [<ffffffff804931c8>] free_pcppages_bulk+0x708/0x900 Feb 6 17:13:13 aaa-PC kernel: [ 46 6.271119] [<ffffffff804980cc>] free_unref_page_list+0x1cc/0x2c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271122] [<ffffffff804ad2c8>] release_pages+0x648/0x900 Feb 6 17:13:13 aaa-PC kernel: [ 466.271125] [<ffffffff804f3b48>] tlb_flush_mmu_free+0x88/0x100 Feb 6 17:13:13 aaa-PC kernel: [ 466.271128] [<ffffffff804f8a24>] zap_pte_range+0xa24/0x1480 Feb 6 17:13:13 aaa-PC kernel: [ 466.271132] [<ffffffff804f98b0>] unmap_page_range+0x1f0/0x500 Feb 6 17:13:13 aaa-PC kernel: [ 466.271135] [<ffffffff804fa054>] unmap_vmas+0x154/0x200 Feb 6 17:13:13 aaa-PC kernel: [ 466.271138] [<ffffffff8051190c>] exit_mmap+0x20c/0x380 Feb 6 17:13:13 aaa-PC kernel: [ 466.271142] [<ffffffff802bb9c8>] mmput+0x148/0x300 Feb 6 17:13:13 aaa-PC kernel: [ 466.271145] [<ffffffff802c80d8>] do_exit+0x6d8/0x1900 Feb 6 17:13:13 aaa-PC kernel: [ 466.271148] [<ffffffff802cb288>] do_group_exit+0x88/0x1c0 Feb 6 17:13:13 aaa-PC kernel: [ 466.271151] [<ffffffff802cb3d8>] sys_exit_group+0x18/0x40 Feb 6 17 :13:13 aaa-PC kernel: [ 466.271155] [<ffffffff8023f954>] syscall_common+0x34/0xa4 songqiang
@ 2021-04-07 8:25 ` Huang Rui
2021-04-07 9:25 ` Christian König
0 siblings, 1 reply; 348+ messages in thread
From: Huang Rui @ 2021-04-07 8:25 UTC (permalink / raw)
To: songqiang; +Cc: Koenig, Christian, airlied, daniel, linux-kernel, dri-devel
On Wed, Apr 07, 2021 at 09:27:46AM +0800, songqiang wrote:
Please add the description in the commit message and subject.
Thanks,
Ray
> Signed-off-by: songqiang <songqiang@uniontech.com>
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index 14660f723f71..f3698f0ad4d7 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -736,8 +736,16 @@ static void ttm_put_pages(struct page **pages, unsigned npages, int flags,
> if (++p != pages[i + j])
> break;
>
> - if (j == HPAGE_PMD_NR)
> + if (j == HPAGE_PMD_NR) {
> order = HPAGE_PMD_ORDER;
> + for (j = 1; j < HPAGE_PMD_NR; ++j)
> + page_ref_dec(pages[i+j]);
> + }
> }
> #endif
>
> @@ -868,10 +876,12 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,
> p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
> if (!p)
> break;
> -
> - for (j = 0; j < HPAGE_PMD_NR; ++j)
> + for (j = 0; j < HPAGE_PMD_NR; ++j) {
> pages[i++] = p++;
> -
> + if (j > 0)
> + page_ref_inc(pages[i-1]);
> + }
> npages -= HPAGE_PMD_NR;
> }
> }
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cray.huang%40amd.com%7C4ccc617b77d746db5af108d8f98db612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533734805563118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9bSP90LYdJyJYJYmuphVmqk%2B3%2FE4JPrtXkQTbxwAt68%3D&reserved=0
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2021-04-07 8:25 ` your mail Huang Rui
@ 2021-04-07 9:25 ` Christian König
0 siblings, 0 replies; 348+ messages in thread
From: Christian König @ 2021-04-07 9:25 UTC (permalink / raw)
To: Huang Rui, songqiang; +Cc: airlied, daniel, linux-kernel, dri-devel
Thanks Ray for pointing this out. Looks like the mail ended up in my
spam folder otherwise.
Apart from that this patch is a really really big NAK. I can't count how
often I had to reject stuff like this!
Using the page reference for TTM pages is illegal and can lead to struct
page corruption.
Can you please describe why you need that?
Regards,
Christian.
Am 07.04.21 um 10:25 schrieb Huang Rui:
> On Wed, Apr 07, 2021 at 09:27:46AM +0800, songqiang wrote:
>
> Please add the description in the commit message and subject.
>
> Thanks,
> Ray
>
>> Signed-off-by: songqiang <songqiang@uniontech.com>
>> ---
>> drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++++++++++++++----
>> 1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>> index 14660f723f71..f3698f0ad4d7 100644
>> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>> @@ -736,8 +736,16 @@ static void ttm_put_pages(struct page **pages, unsigned npages, int flags,
>> if (++p != pages[i + j])
>> break;
>>
>> - if (j == HPAGE_PMD_NR)
>> + if (j == HPAGE_PMD_NR) {
>> order = HPAGE_PMD_ORDER;
>> + for (j = 1; j < HPAGE_PMD_NR; ++j)
>> + page_ref_dec(pages[i+j]);
>> + }
>> }
>> #endif
>>
>> @@ -868,10 +876,12 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags,
>> p = alloc_pages(huge_flags, HPAGE_PMD_ORDER);
>> if (!p)
>> break;
>> -
>> - for (j = 0; j < HPAGE_PMD_NR; ++j)
>> + for (j = 0; j < HPAGE_PMD_NR; ++j) {
>> pages[i++] = p++;
>> -
>> + if (j > 0)
>> + page_ref_inc(pages[i-1]);
>> + }
>> npages -= HPAGE_PMD_NR;
>> }
>> }
>>
>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cray.huang%40amd.com%7C4ccc617b77d746db5af108d8f98db612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533734805563118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9bSP90LYdJyJYJYmuphVmqk%2B3%2FE4JPrtXkQTbxwAt68%3D&reserved=0
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2021-04-01 21:16 Bhaumik Bhatt
2021-04-07 6:56 ` your mail Manivannan Sadhasivam
0 siblings, 1 reply; 348+ messages in thread
From: Bhaumik Bhatt @ 2021-04-01 21:16 UTC (permalink / raw)
To: manivannan.sadhasivam
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, carl.yin,
naveen.kumar, loic.poulain, Bhaumik Bhatt
Subject: [PATCH v8 0/9] Updates to MHI channel handling
MHI specification shows a state machine with support for STOP channel command
and the validity of certain state transitions. MHI host currently does not
provide any mechanism to stop a channel and restart it without resetting it.
There are also times when the device moves on to a different execution
environment while client drivers on the host are unaware of it and still
attempt to reset the channels facing unnecessary timeouts.
This series addresses the above areas to provide support for stopping an MHI
channel, resuming it back, improved documentation and improving upon channel
state machine handling in general.
This set of patches was tested on arm64 and x86_64 architecture.
v8:
-Split the state machine improvements patch to three patches as per review
v7:
-Tested on x86_64 architecture
-Drop the patch "Do not clear channel context more than once" as issue is fixed
differently using "bus: mhi: core: Fix double dma free()"
-Update the commit text to better reflect changes on state machine improvements
v6:
-Dropped the patch which introduced start/stop transfer APIs for lack of users
-Updated error handling and debug prints on channel handling improvements patch
-Improved commit text to better explain certain patches based on review comments
-Removed references to new APIs from the documentation improvement patch
v5:
-Added reviewed-by tags from Hemant I missed earlier
-Added patch to prevent kernel warnings on clearing channel context twice
v4:
-Updated commit text/descriptions and addressed checkpatch checks
-Added context validity check before starting/stopping channels from new API
-Added patch to clear channel context configuration after reset/unprepare
v3:
-Updated documentation for channel transfer APIs to highlight differences
-Create separate patch for "allowing channel to be disabled from stopped state"
v2:
-Renamed the newly introduced APIs to mhi_start_transfer() / mhi_stop_transfer()
-Added improved documentation to avoid confusion with the new APIs
-Removed the __ prefix from mhi_unprepare_channel() API for consistency.
Bhaumik Bhatt (9):
bus: mhi: core: Allow sending the STOP channel command
bus: mhi: core: Clear context for stopped channels from remove()
bus: mhi: core: Improvements to the channel handling state machine
bus: mhi: core: Update debug messages to use client device
bus: mhi: core: Hold device wake for channel update commands
bus: mhi: core: Clear configuration from channel context during reset
bus: mhi: core: Check channel execution environment before issuing
reset
bus: mhi: core: Remove __ prefix for MHI channel unprepare function
bus: mhi: Improve documentation on channel transfer setup APIs
drivers/bus/mhi/core/init.c | 22 ++++-
drivers/bus/mhi/core/internal.h | 12 +++
drivers/bus/mhi/core/main.c | 190 ++++++++++++++++++++++++----------------
include/linux/mhi.h | 18 +++-
4 files changed, 162 insertions(+), 80 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2021-04-01 21:16 Bhaumik Bhatt
@ 2021-04-07 6:56 ` Manivannan Sadhasivam
0 siblings, 0 replies; 348+ messages in thread
From: Manivannan Sadhasivam @ 2021-04-07 6:56 UTC (permalink / raw)
To: Bhaumik Bhatt
Cc: linux-arm-msm, hemantk, jhugo, linux-kernel, carl.yin,
naveen.kumar, loic.poulain
On Thu, Apr 01, 2021 at 02:16:09PM -0700, Bhaumik Bhatt wrote:
> Subject: [PATCH v8 0/9] Updates to MHI channel handling
>
Subject is present in the body ;)
> MHI specification shows a state machine with support for STOP channel command
> and the validity of certain state transitions. MHI host currently does not
> provide any mechanism to stop a channel and restart it without resetting it.
> There are also times when the device moves on to a different execution
> environment while client drivers on the host are unaware of it and still
> attempt to reset the channels facing unnecessary timeouts.
>
> This series addresses the above areas to provide support for stopping an MHI
> channel, resuming it back, improved documentation and improving upon channel
> state machine handling in general.
>
> This set of patches was tested on arm64 and x86_64 architecture.
>
Series applied to mhi-next!
Thanks,
Mani
> v8:
> -Split the state machine improvements patch to three patches as per review
>
> v7:
> -Tested on x86_64 architecture
> -Drop the patch "Do not clear channel context more than once" as issue is fixed
> differently using "bus: mhi: core: Fix double dma free()"
> -Update the commit text to better reflect changes on state machine improvements
>
> v6:
> -Dropped the patch which introduced start/stop transfer APIs for lack of users
> -Updated error handling and debug prints on channel handling improvements patch
> -Improved commit text to better explain certain patches based on review comments
> -Removed references to new APIs from the documentation improvement patch
>
> v5:
> -Added reviewed-by tags from Hemant I missed earlier
> -Added patch to prevent kernel warnings on clearing channel context twice
>
> v4:
> -Updated commit text/descriptions and addressed checkpatch checks
> -Added context validity check before starting/stopping channels from new API
> -Added patch to clear channel context configuration after reset/unprepare
>
> v3:
> -Updated documentation for channel transfer APIs to highlight differences
> -Create separate patch for "allowing channel to be disabled from stopped state"
>
> v2:
> -Renamed the newly introduced APIs to mhi_start_transfer() / mhi_stop_transfer()
> -Added improved documentation to avoid confusion with the new APIs
> -Removed the __ prefix from mhi_unprepare_channel() API for consistency.
>
> Bhaumik Bhatt (9):
> bus: mhi: core: Allow sending the STOP channel command
> bus: mhi: core: Clear context for stopped channels from remove()
> bus: mhi: core: Improvements to the channel handling state machine
> bus: mhi: core: Update debug messages to use client device
> bus: mhi: core: Hold device wake for channel update commands
> bus: mhi: core: Clear configuration from channel context during reset
> bus: mhi: core: Check channel execution environment before issuing
> reset
> bus: mhi: core: Remove __ prefix for MHI channel unprepare function
> bus: mhi: Improve documentation on channel transfer setup APIs
>
> drivers/bus/mhi/core/init.c | 22 ++++-
> drivers/bus/mhi/core/internal.h | 12 +++
> drivers/bus/mhi/core/main.c | 190 ++++++++++++++++++++++++----------------
> include/linux/mhi.h | 18 +++-
> 4 files changed, 162 insertions(+), 80 deletions(-)
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <20210322213644.333112726@goodmis.org>]
[parent not found: <20210322212156.440428241@goodmis.org>]
* [PATCH] lib/find_bit: Add find_prev_*_bit functions.
@ 2020-12-02 1:10 Yun Levi
2020-12-02 9:47 ` Andy Shevchenko
0 siblings, 1 reply; 348+ messages in thread
From: Yun Levi @ 2020-12-02 1:10 UTC (permalink / raw)
To: dushistov, arnd, akpm, gustavo, vilhelm.gray, richard.weiyang,
andriy.shevchenko, joseph.qi, skalluru, yury.norov, jpoimboe
Cc: linux-kernel, linux-arch
Inspired find_next_*bit function series, add find_prev_*_bit series.
I'm not sure whether it'll be used right now But, I add these functions
for future usage.
Signed-off-by: Levi Yun <ppbuk5246@gmail.com>
---
fs/ufs/util.h | 24 +++---
include/asm-generic/bitops/find.h | 69 ++++++++++++++++
include/asm-generic/bitops/le.h | 33 ++++++++
include/linux/bitops.h | 34 +++++---
lib/find_bit.c | 126 +++++++++++++++++++++++++++++-
5 files changed, 260 insertions(+), 26 deletions(-)
diff --git a/fs/ufs/util.h b/fs/ufs/util.h
index 4931bec1a01c..7c87c77d10ca 100644
--- a/fs/ufs/util.h
+++ b/fs/ufs/util.h
@@ -2,7 +2,7 @@
/*
* linux/fs/ufs/util.h
*
- * Copyright (C) 1998
+ * Copyright (C) 1998
* Daniel Pirkl <daniel.pirkl@email.cz>
* Charles University, Faculty of Mathematics and Physics
*/
@@ -263,7 +263,7 @@ extern int ufs_prepare_chunk(struct page *page,
loff_t pos, unsigned len);
/*
* These functions manipulate ufs buffers
*/
-#define ubh_bread(sb,fragment,size) _ubh_bread_(uspi,sb,fragment,size)
+#define ubh_bread(sb,fragment,size) _ubh_bread_(uspi,sb,fragment,size)
extern struct ufs_buffer_head * _ubh_bread_(struct
ufs_sb_private_info *, struct super_block *, u64 , u64);
extern struct ufs_buffer_head * ubh_bread_uspi(struct
ufs_sb_private_info *, struct super_block *, u64, u64);
extern void ubh_brelse (struct ufs_buffer_head *);
@@ -296,7 +296,7 @@ static inline void *get_usb_offset(struct
ufs_sb_private_info *uspi,
unsigned int offset)
{
unsigned int index;
-
+
index = offset >> uspi->s_fshift;
offset &= ~uspi->s_fmask;
return uspi->s_ubh.bh[index]->b_data + offset;
@@ -411,9 +411,9 @@ static inline unsigned _ubh_find_next_zero_bit_(
offset = 0;
}
return (base << uspi->s_bpfshift) + pos - begin;
-}
+}
-static inline unsigned find_last_zero_bit (unsigned char * bitmap,
+static inline unsigned __ubh_find_last_zero_bit(unsigned char * bitmap,
unsigned size, unsigned offset)
{
unsigned bit, i;
@@ -453,7 +453,7 @@ static inline unsigned _ubh_find_last_zero_bit_(
size + (uspi->s_bpf - start), uspi->s_bpf)
- (uspi->s_bpf - start);
size -= count;
- pos = find_last_zero_bit (ubh->bh[base]->b_data,
+ pos = __ubh_find_last_zero_bit(ubh->bh[base]->b_data,
start, start - count);
if (pos > start - count || !size)
break;
@@ -461,7 +461,7 @@ static inline unsigned _ubh_find_last_zero_bit_(
start = uspi->s_bpf;
}
return (base << uspi->s_bpfshift) + pos - begin;
-}
+}
#define ubh_isblockclear(ubh,begin,block)
(!_ubh_isblockset_(uspi,ubh,begin,block))
@@ -483,7 +483,7 @@ static inline int _ubh_isblockset_(struct
ufs_sb_private_info * uspi,
mask = 0x01 << (block & 0x07);
return (*ubh_get_addr (ubh, begin + (block >> 3)) &
mask) == mask;
}
- return 0;
+ return 0;
}
#define ubh_clrblock(ubh,begin,block) _ubh_clrblock_(uspi,ubh,begin,block)
@@ -492,8 +492,8 @@ static inline void _ubh_clrblock_(struct
ufs_sb_private_info * uspi,
{
switch (uspi->s_fpb) {
case 8:
- *ubh_get_addr (ubh, begin + block) = 0x00;
- return;
+ *ubh_get_addr (ubh, begin + block) = 0x00;
+ return;
case 4:
*ubh_get_addr (ubh, begin + (block >> 1)) &= ~(0x0f <<
((block & 0x01) << 2));
return;
@@ -531,9 +531,9 @@ static inline void ufs_fragacct (struct
super_block * sb, unsigned blockmap,
{
struct ufs_sb_private_info * uspi;
unsigned fragsize, pos;
-
+
uspi = UFS_SB(sb)->s_uspi;
-
+
fragsize = 0;
for (pos = 0; pos < uspi->s_fpb; pos++) {
if (blockmap & (1 << pos)) {
diff --git a/include/asm-generic/bitops/find.h
b/include/asm-generic/bitops/find.h
index 9fdf21302fdf..ca18b2ec954c 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -16,6 +16,20 @@ extern unsigned long find_next_bit(const unsigned
long *addr, unsigned long
size, unsigned long offset);
#endif
+#ifndef find_prev_bit
+/**
+ * find_prev_bit - find the prev set bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ *
+ * Returns the bit number for the prev set bit
+ * If no bits are set, returns @size.
+ */
+extern unsigned long find_prev_bit(const unsigned long *addr, unsigned long
+ size, unsigned long offset);
+#endif
+
#ifndef find_next_and_bit
/**
* find_next_and_bit - find the next set bit in both memory regions
@@ -32,6 +46,22 @@ extern unsigned long find_next_and_bit(const
unsigned long *addr1,
unsigned long offset);
#endif
+#ifndef find_prev_and_bit
+/**
+ * find_prev_and_bit - find the prev set bit in both memory regions
+ * @addr1: The first address to base the search on
+ * @addr2: The second address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ *
+ * Returns the bit number for the prev set bit
+ * If no bits are set, returns @size.
+ */
+extern unsigned long find_prev_and_bit(const unsigned long *addr1,
+ const unsigned long *addr2, unsigned long size,
+ unsigned long offset);
+#endif
+
#ifndef find_next_zero_bit
/**
* find_next_zero_bit - find the next cleared bit in a memory region
@@ -46,6 +76,20 @@ extern unsigned long find_next_zero_bit(const
unsigned long *addr, unsigned
long size, unsigned long offset);
#endif
+#ifndef find_prev_zero_bit
+/**
+ * find_prev_zero_bit - find the prev cleared bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ *
+ * Returns the bit number of the prev zero bit
+ * If no bits are zero, returns @size.
+ */
+extern unsigned long find_prev_zero_bit(const unsigned long *addr, unsigned
+ long size, unsigned long offset);
+#endif
+
#ifdef CONFIG_GENERIC_FIND_FIRST_BIT
/**
@@ -80,6 +124,31 @@ extern unsigned long find_first_zero_bit(const
unsigned long *addr,
#endif /* CONFIG_GENERIC_FIND_FIRST_BIT */
+#ifndef find_last_bit
+/**
+ * find_last_bit - find the last set bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The number of bits to search
+ *
+ * Returns the bit number of the last set bit, or size.
+ */
+extern unsigned long find_last_bit(const unsigned long *addr,
+ unsigned long size);
+#endif
+
+#ifndef find_last_zero_bit
+/**
+ * find_last_zero_bit - find the last cleared bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The maximum number of bits to search
+ *
+ * Returns the bit number of the first cleared bit.
+ * If no bits are zero, returns @size.
+ */
+extern unsigned long find_last_zero_bit(const unsigned long *addr,
+ unsigned long size);
+#endif
+
/**
* find_next_clump8 - find next 8-bit clump with set bits in a memory region
* @clump: location to store copy of found clump
diff --git a/include/asm-generic/bitops/le.h b/include/asm-generic/bitops/le.h
index 188d3eba3ace..d0bd15bc34d9 100644
--- a/include/asm-generic/bitops/le.h
+++ b/include/asm-generic/bitops/le.h
@@ -27,6 +27,24 @@ static inline unsigned long
find_first_zero_bit_le(const void *addr,
return find_first_zero_bit(addr, size);
}
+static inline unsigned long find_prev_zero_bit_le(const void *addr,
+ unsigned long size, unsigned long offset)
+{
+ return find_prev_zero_bit(addr, size, offset);
+}
+
+static inline unsigned long find_prev_bit_le(const void *addr,
+ unsigned long size, unsigned long offset)
+{
+ return find_prev_bit(addr, size, offset);
+}
+
+static inline unsigned long find_last_zero_bit_le(const void *addr,
+ unsigned long size)
+{
+ return find_last_zero_bit(addr, size);
+}
+
#elif defined(__BIG_ENDIAN)
#define BITOP_LE_SWIZZLE ((BITS_PER_LONG-1) & ~0x7)
@@ -41,11 +59,26 @@ extern unsigned long find_next_bit_le(const void *addr,
unsigned long size, unsigned long offset);
#endif
+#ifndef find_prev_zero_bit_le
+extern unsigned long find_prev_zero_bit_le(const void *addr,
+ unsigned long size, unsigned long offset);
+#endif
+
+#ifndef find_prev_bit_le
+extern unsigned long find_prev_bit_le(const void *addr,
+ unsigned long size, unsigned long offset);
+#endif
+
#ifndef find_first_zero_bit_le
#define find_first_zero_bit_le(addr, size) \
find_next_zero_bit_le((addr), (size), 0)
#endif
+#ifndef find_last_zero_bit_le
+#define find_last_zero_bit_le(addr, size) \
+ find_prev_zero_bit_le((addr), (size), (size - 1))
+#endif
+
#else
#error "Please fix <asm/byteorder.h>"
#endif
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 5b74bdf159d6..124c68929861 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -50,6 +50,28 @@ extern unsigned long __sw_hweight64(__u64 w);
(bit) < (size); \
(bit) = find_next_zero_bit((addr), (size), (bit) + 1))
+#define for_each_set_bit_reverse(bit, addr, size) \
+ for ((bit) = find_last_bit((addr), (size)); \
+ (bit) < (size); \
+ (bit) = find_prev_bit((addr), (size), (bit)))
+
+/* same as for_each_set_bit_reverse() but use bit as value to start with */
+#define for_each_set_bit_from_reverse(bit, addr, size) \
+ for ((bit) = find_prev_bit((addr), (size), (bit)); \
+ (bit) < (size); \
+ (bit) = find_prev_bit((addr), (size), (bit - 1)))
+
+#define for_each_clear_bit_reverse(bit, addr, size) \
+ for ((bit) = find_last_zero_bit((addr), (size)); \
+ (bit) < (size); \
+ (bit) = find_prev_zero_bit((addr), (size), (bit)))
+
+/* same as for_each_clear_bit_reverse() but use bit as value to start with */
+#define for_each_clear_bit_from_reverse(bit, addr, size) \
+ for ((bit) = find_prev_zero_bit((addr), (size), (bit)); \
+ (bit) < (size); \
+ (bit) = find_next_zero_bit((addr), (size), (bit - 1)))
+
/**
* for_each_set_clump8 - iterate over bitmap for each 8-bit clump with set bits
* @start: bit offset to start search and to store the current iteration offset
@@ -283,17 +305,5 @@ static __always_inline void __assign_bit(long nr,
volatile unsigned long *addr,
})
#endif
-#ifndef find_last_bit
-/**
- * find_last_bit - find the last set bit in a memory region
- * @addr: The address to start the search at
- * @size: The number of bits to search
- *
- * Returns the bit number of the last set bit, or size.
- */
-extern unsigned long find_last_bit(const unsigned long *addr,
- unsigned long size);
-#endif
-
#endif /* __KERNEL__ */
#endif
diff --git a/lib/find_bit.c b/lib/find_bit.c
index 4a8751010d59..cbe06abd3d21 100644
--- a/lib/find_bit.c
+++ b/lib/find_bit.c
@@ -69,6 +69,58 @@ static unsigned long _find_next_bit(const unsigned
long *addr1,
}
#endif
+#if !defined(find_prev_bit) || !defined(find_prev_zero_bit) ||
\
+ !defined(find_prev_bit_le) || !defined(find_prev_zero_bit_le)
|| \
+ !defined(find_prev_and_bit)
+/*
+ * This is a common helper function for find_prev_bit, find_prev_zero_bit, and
+ * find_prev_and_bit. The differences are:
+ * - The "invert" argument, which is XORed with each fetched word before
+ * searching it for one bits.
+ * - The optional "addr2", which is anded with "addr1" if present.
+ */
+static unsigned long _find_prev_bit(const unsigned long *addr1,
+ const unsigned long *addr2, unsigned long nbits,
+ unsigned long start, unsigned long invert, unsigned long le)
+{
+ unsigned long tmp, mask;
+
+ if (unlikely(start >= nbits))
+ return nbits;
+
+ tmp = addr1[start / BITS_PER_LONG];
+ if (addr2)
+ tmp &= addr2[start / BITS_PER_LONG];
+ tmp ^= invert;
+
+ /* Handle 1st word. */
+ mask = BITMAP_LAST_WORD_MASK(start + 1);
+ if (le)
+ mask = swab(mask);
+
+ tmp &= mask;
+
+ start = round_down(start, BITS_PER_LONG);
+
+ while (!tmp) {
+ start -= BITS_PER_LONG;
+ if (start >= nbits)
+ return nbits;
+
+ tmp = addr1[start / BITS_PER_LONG];
+ if (addr2)
+ tmp &= addr2[start / BITS_PER_LONG];
+ tmp ^= invert;
+ }
+
+ if (le)
+ tmp = swab(tmp);
+
+ return start + __fls(tmp);
+}
+#endif
+
+
#ifndef find_next_bit
/*
* Find the next set bit in a memory region.
@@ -81,6 +133,18 @@ unsigned long find_next_bit(const unsigned long
*addr, unsigned long size,
EXPORT_SYMBOL(find_next_bit);
#endif
+#ifndef find_prev_bit
+/*
+ * Find the prev set bit in a memory region.
+ */
+unsigned long find_prev_bit(const unsigned long *addr, unsigned long size,
+ unsigned long offset)
+{
+ return _find_prev_bit(addr, NULL, size, offset, 0UL, 0);
+}
+EXPORT_SYMBOL(find_prev_bit);
+#endif
+
#ifndef find_next_zero_bit
unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
unsigned long offset)
@@ -90,7 +154,16 @@ unsigned long find_next_zero_bit(const unsigned
long *addr, unsigned long size,
EXPORT_SYMBOL(find_next_zero_bit);
#endif
-#if !defined(find_next_and_bit)
+#ifndef find_prev_zero_bit
+unsigned long find_prev_zero_bit(const unsigned long *addr, unsigned long size,
+ unsigned long offset)
+{
+ return _find_prev_bit(addr, NULL, size, offset, ~0UL, 0);
+}
+EXPORT_SYMBOL(find_prev_zero_bit);
+#endif
+
+#ifndef find_next_and_bit
unsigned long find_next_and_bit(const unsigned long *addr1,
const unsigned long *addr2, unsigned long size,
unsigned long offset)
@@ -100,6 +173,16 @@ unsigned long find_next_and_bit(const unsigned long *addr1,
EXPORT_SYMBOL(find_next_and_bit);
#endif
+#ifndef find_prev_and_bit
+unsigned long find_prev_and_bit(const unsigned long *addr1,
+ const unsigned long *addr2, unsigned long size,
+ unsigned long offset)
+{
+ return _find_prev_bit(addr1, addr2, size, offset, 0UL, 0);
+}
+EXPORT_SYMBOL(find_prev_and_bit);
+#endif
+
#ifndef find_first_bit
/*
* Find the first set bit in a memory region.
@@ -141,7 +224,7 @@ unsigned long find_last_bit(const unsigned long
*addr, unsigned long size)
{
if (size) {
unsigned long val = BITMAP_LAST_WORD_MASK(size);
- unsigned long idx = (size-1) / BITS_PER_LONG;
+ unsigned long idx = (size - 1) / BITS_PER_LONG;
do {
val &= addr[idx];
@@ -156,6 +239,27 @@ unsigned long find_last_bit(const unsigned long
*addr, unsigned long size)
EXPORT_SYMBOL(find_last_bit);
#endif
+#ifndef find_last_zero_bit
+unsigned long find_last_zero_bit(const unsigned long *addr, unsigned long size)
+{
+ if (size) {
+ unsigned long val = BITMAP_LAST_WORD_MASK(size);
+ unsigned long idx = (size - 1) / BITS_PER_LONG;
+
+ do {
+ val &= ~addr[idx];
+ if (val)
+ return idx * BITS_PER_LONG + __fls(val);
+
+ val = ~0ul;
+ } while (idx--);
+ }
+
+ return size;
+}
+EXPORT_SYMBOL(find_last_zero_bit);
+#endif
+
#ifdef __BIG_ENDIAN
#ifndef find_next_zero_bit_le
@@ -167,6 +271,15 @@ unsigned long find_next_zero_bit_le(const void
*addr, unsigned
EXPORT_SYMBOL(find_next_zero_bit_le);
#endif
+#ifndef find_prev_zero_bit_le
+unsigned long find_prev_zero_bit_le(const void *addr, unsigned
+ long size, unsigned long offset)
+{
+ return _find_prev_bit(addr, NULL, size, offset, ~0UL, 1);
+}
+EXPORT_SYMBOL(find_prev_zero_bit_le);
+#endif
+
#ifndef find_next_bit_le
unsigned long find_next_bit_le(const void *addr, unsigned
long size, unsigned long offset)
@@ -176,6 +289,15 @@ unsigned long find_next_bit_le(const void *addr, unsigned
EXPORT_SYMBOL(find_next_bit_le);
#endif
+#ifdef find_prev_bit_le
+unsigned long find_prev_bit_le(const void *addr, unsigned
+ long size, unsigned long offset)
+{
+ return _find_prev_bit(addr, NULL, size, offset, 0UL, 1);
+}
+EXPORT_SYMBOL(find_prev_bit_le);
+#endif
+
#endif /* __BIG_ENDIAN */
unsigned long find_next_clump8(unsigned long *clump, const unsigned long *addr,
--
2.29.2
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: [PATCH] lib/find_bit: Add find_prev_*_bit functions.
2020-12-02 1:10 [PATCH] lib/find_bit: Add find_prev_*_bit functions Yun Levi
@ 2020-12-02 9:47 ` Andy Shevchenko
2020-12-02 10:04 ` Rasmus Villemoes
0 siblings, 1 reply; 348+ messages in thread
From: Andy Shevchenko @ 2020-12-02 9:47 UTC (permalink / raw)
To: Yun Levi
Cc: dushistov, arnd, akpm, gustavo, vilhelm.gray, richard.weiyang,
joseph.qi, skalluru, yury.norov, jpoimboe, linux-kernel,
linux-arch
On Wed, Dec 02, 2020 at 10:10:09AM +0900, Yun Levi wrote:
> Inspired find_next_*bit function series, add find_prev_*_bit series.
> I'm not sure whether it'll be used right now But, I add these functions
> for future usage.
This patch has few issues:
- it has more things than described (should be several patches instead)
- new functionality can be split logically to couple or more pieces as well
- it proposes functionality w/o user (dead code)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH] lib/find_bit: Add find_prev_*_bit functions.
2020-12-02 9:47 ` Andy Shevchenko
@ 2020-12-02 10:04 ` Rasmus Villemoes
2020-12-02 11:50 ` Yun Levi
0 siblings, 1 reply; 348+ messages in thread
From: Rasmus Villemoes @ 2020-12-02 10:04 UTC (permalink / raw)
To: Andy Shevchenko, Yun Levi
Cc: dushistov, arnd, akpm, gustavo, vilhelm.gray, richard.weiyang,
joseph.qi, skalluru, yury.norov, jpoimboe, linux-kernel,
linux-arch
On 02/12/2020 10.47, Andy Shevchenko wrote:
> On Wed, Dec 02, 2020 at 10:10:09AM +0900, Yun Levi wrote:
>> Inspired find_next_*bit function series, add find_prev_*_bit series.
>> I'm not sure whether it'll be used right now But, I add these functions
>> for future usage.
>
> This patch has few issues:
> - it has more things than described (should be several patches instead)
> - new functionality can be split logically to couple or more pieces as well
> - it proposes functionality w/o user (dead code)
Yeah, the last point means it can't be applied - please submit it again
if and when you have an actual use case. And I'll add
- it lacks extension of the bitmap test module to cover the new
functions (that also wants to be a separate patch).
Rasmus
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH] lib/find_bit: Add find_prev_*_bit functions.
2020-12-02 10:04 ` Rasmus Villemoes
@ 2020-12-02 11:50 ` Yun Levi
[not found] ` <CAAH8bW-jUeFVU-0OrJzK-MuGgKJgZv38RZugEQzFRJHSXFRRDA@mail.gmail.com>
0 siblings, 1 reply; 348+ messages in thread
From: Yun Levi @ 2020-12-02 11:50 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Andy Shevchenko, dushistov, arnd, akpm, gustavo, vilhelm.gray,
richard.weiyang, joseph.qi, skalluru, yury.norov, jpoimboe,
linux-kernel, linux-arch
Thanks for kind advice. But I'm so afraid to have questions below:
> - it proposes functionality w/o user (dead code)
Actually, I add these series functions to rewrite some of the
resource clean-up routine.
A typical case is ethtool_set_per_queue_coalesce 's rollback label.
Could this usage be an actual use case?
>- it lacks extension of the bitmap test module to cover the new
> functions (that also wants to be a separate patch).
I see, then Could I add some of testcase on lib/test_bitops.c for testing?
On Wed, Dec 2, 2020 at 7:04 PM Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
>
> On 02/12/2020 10.47, Andy Shevchenko wrote:
> > On Wed, Dec 02, 2020 at 10:10:09AM +0900, Yun Levi wrote:
> >> Inspired find_next_*bit function series, add find_prev_*_bit series.
> >> I'm not sure whether it'll be used right now But, I add these functions
> >> for future usage.
> >
> > This patch has few issues:
> > - it has more things than described (should be several patches instead)
> > - new functionality can be split logically to couple or more pieces as well
> > - it proposes functionality w/o user (dead code)
>
> Yeah, the last point means it can't be applied - please submit it again
> if and when you have an actual use case. And I'll add
>
> - it lacks extension of the bitmap test module to cover the new
> functions (that also wants to be a separate patch).
>
> Rasmus
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
@ 2020-08-05 11:02 Amit Pundir
2020-08-06 22:31 ` Konrad Dybcio
0 siblings, 1 reply; 348+ messages in thread
From: Amit Pundir @ 2020-08-05 11:02 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, John Stultz, Sumit Semwal
Cc: linux-arm-msm, dt, lkml
On Wed, 5 Aug 2020 at 16:21, Amit Pundir <amit.pundir@linaro.org> wrote:
>
> Add initial dts support for Xiaomi Poco F1 (Beryllium).
>
> This initial support is based on upstream Dragonboard 845c
> (sdm845) device. With this dts, Beryllium boots AOSP up to
> ADB shell over USB-C.
>
> Supported functionality includes UFS, USB-C (peripheral),
> microSD card and Vol+/Vol-/power keys. Bluetooth should work
> too but couldn't be verified from adb command line, it is
> verified when enabled from UI with few WIP display patches.
>
> Just like initial db845c support, initializing the SMMU is
> clearing the mapping used for the splash screen framebuffer,
> which causes the device to hang during boot and recovery
> needs a hard power reset. This can be worked around using:
>
> fastboot oem select-display-panel none
>
> To switch ON the display back run:
>
> fastboot oem select-display-panel
>
> But this only works on Beryllium devices running bootloader
> version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
> Android-9 based release. Newer bootloader version do not
> support switching OFF the display panel at all. So we need
> a few additional smmu patches (under review) from here to
> boot to shell:
> https://github.com/pundiramit/linux/commits/beryllium-mainline
>
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> ---
> v4: Added more downstream reserved memory regions. It probably
> need more work, but for now I see adsp/cdsp/wlan remoteprocs
> powering up properly. Also removed the regulator nodes not
> required for the device, as suggested by Bjorn.
Forgot to mention that I added couple of clocks to protected clocks in v4,
which need for display to work.
> v3: Added a reserved-memory region from downstream kernel to fix
> a boot regression with recent dma-pool changes in v5.8-rc6.
> v2: Updated machine compatible string for seemingly inevitable
> future quirks.
>
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 383 ++++++++++++++++++++++++++
> 2 files changed, 384 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 0f2c33d611df..3ef1b48bc0cb 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r3.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += sdm845-beryllium.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm845-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sdm850-lenovo-yoga-c630.dtb
> dtb-$(CONFIG_ARCH_QCOM) += sm8150-mtp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> new file mode 100644
> index 000000000000..0f9f61bf9fa4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> @@ -0,0 +1,383 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> +#include "sdm845.dtsi"
> +#include "pm8998.dtsi"
> +#include "pmi8998.dtsi"
> +
> +/ {
> + model = "Xiaomi Technologies Inc. Beryllium";
> + compatible = "xiaomi,beryllium", "qcom,sdm845";
> +
> + /* required for bootloader to select correct board */
> + qcom,board-id = <69 0>;
> + qcom,msm-id = <321 0x20001>;
> +
> + aliases {
> + hsuart0 = &uart6;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&vol_up_pin_a>;
> +
> + vol-up {
> + label = "Volume Up";
> + linux,code = <KEY_VOLUMEUP>;
> + gpios = <&pm8998_gpio 6 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + vreg_s4a_1p8: vreg-s4a-1p8 {
> + compatible = "regulator-fixed";
> + regulator-name = "vreg_s4a_1p8";
> +
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +};
> +
> +&adsp_pas {
> + status = "okay";
> + firmware-name = "qcom/sdm845/adsp.mdt";
> +};
> +
> +&apps_rsc {
> + pm8998-rpmh-regulators {
> + compatible = "qcom,pm8998-rpmh-regulators";
> + qcom,pmic-id = "a";
> +
> + vreg_l1a_0p875: ldo1 {
> + regulator-min-microvolt = <880000>;
> + regulator-max-microvolt = <880000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l5a_0p8: ldo5 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <800000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l7a_1p8: ldo7 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l12a_1p8: ldo12 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l13a_2p95: ldo13 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2960000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l17a_1p3: ldo17 {
> + regulator-min-microvolt = <1304000>;
> + regulator-max-microvolt = <1304000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l20a_2p95: ldo20 {
> + regulator-min-microvolt = <2960000>;
> + regulator-max-microvolt = <2968000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l21a_2p95: ldo21 {
> + regulator-min-microvolt = <2960000>;
> + regulator-max-microvolt = <2968000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l24a_3p075: ldo24 {
> + regulator-min-microvolt = <3088000>;
> + regulator-max-microvolt = <3088000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l25a_3p3: ldo25 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3312000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l26a_1p2: ldo26 {
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> + };
> +};
> +
> +&cdsp_pas {
> + status = "okay";
> + firmware-name = "qcom/sdm845/cdsp.mdt";
> +};
> +
> +&gcc {
> + protected-clocks = <GCC_QSPI_CORE_CLK>,
> + <GCC_QSPI_CORE_CLK_SRC>,
> + <GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
> + <GCC_LPASS_Q6_AXI_CLK>,
> + <GCC_LPASS_SWAY_CLK>;
> +};
> +
> +&gpu {
> + zap-shader {
> + memory-region = <&gpu_mem>;
> + firmware-name = "qcom/sdm845/a630_zap.mbn";
> + };
> +};
> +
> +/* Reserved memory changes from downstream */
> +/delete-node/ &adsp_mem;
> +/delete-node/ &wlan_msa_mem;
> +/delete-node/ &mpss_region;
> +/delete-node/ &venus_mem;
> +/delete-node/ &cdsp_mem;
> +/delete-node/ &mba_region;
> +/delete-node/ &slpi_mem;
> +/delete-node/ &spss_mem;
> +/delete-node/ &rmtfs_mem;
> +/ {
> + reserved-memory {
> + // This removed_region is needed to boot the device
> + // TODO: Find out the user of this reserved memory
> + removed_region: memory@88f00000 {
> + reg = <0 0x88f00000 0 0x1a00000>;
> + no-map;
> + };
> +
> + adsp_mem: memory@8c500000 {
> + reg = <0 0x8c500000 0 0x1e00000>;
> + no-map;
> + };
> +
> + wlan_msa_mem: memory@8e300000 {
> + reg = <0 0x8e300000 0 0x100000>;
> + no-map;
> + };
> +
> + mpss_region: memory@8e400000 {
> + reg = <0 0x8e400000 0 0x7800000>;
> + no-map;
> + };
> +
> + venus_mem: memory@95c00000 {
> + reg = <0 0x95c00000 0 0x500000>;
> + no-map;
> + };
> +
> + cdsp_mem: memory@96100000 {
> + reg = <0 0x96100000 0 0x800000>;
> + no-map;
> + };
> +
> + mba_region: memory@96900000 {
> + reg = <0 0x96900000 0 0x200000>;
> + no-map;
> + };
> +
> + slpi_mem: memory@96b00000 {
> + reg = <0 0x96b00000 0 0x1400000>;
> + no-map;
> + };
> +
> + spss_mem: memory@97f00000 {
> + reg = <0 0x97f00000 0 0x100000>;
> + no-map;
> + };
> +
> + rmtfs_mem: memory@f6301000 {
> + compatible = "qcom,rmtfs-mem";
> + reg = <0 0xf6301000 0 0x200000>;
> + no-map;
> +
> + qcom,client-id = <1>;
> + qcom,vmid = <15>;
> + };
> + };
> +};
> +
> +&mss_pil {
> + status = "okay";
> + firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
> +};
> +
> +&pm8998_gpio {
> + vol_up_pin_a: vol-up-active {
> + pins = "gpio6";
> + function = "normal";
> + input-enable;
> + bias-pull-up;
> + qcom,drive-strength = <PMIC_GPIO_STRENGTH_NO>;
> + };
> +};
> +
> +&pm8998_pon {
> + resin {
> + compatible = "qcom,pm8941-resin";
> + interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
> + debounce = <15625>;
> + bias-pull-up;
> + linux,code = <KEY_VOLUMEDOWN>;
> + };
> +};
> +
> +&qupv3_id_0 {
> + status = "okay";
> +};
> +
> +&sdhc_2 {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdc2_default_state &sdc2_card_det_n>;
> +
> + vmmc-supply = <&vreg_l21a_2p95>;
> + vqmmc-supply = <&vreg_l13a_2p95>;
> +
> + bus-width = <4>;
> + cd-gpios = <&tlmm 126 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&tlmm {
> + gpio-reserved-ranges = <0 4>, <81 4>;
> +
> + sdc2_default_state: sdc2-default {
> + clk {
> + pins = "sdc2_clk";
> + bias-disable;
> +
> + /*
> + * It seems that mmc_test reports errors if drive
> + * strength is not 16 on clk, cmd, and data pins.
> + */
> + drive-strength = <16>;
> + };
> +
> + cmd {
> + pins = "sdc2_cmd";
> + bias-pull-up;
> + drive-strength = <10>;
> + };
> +
> + data {
> + pins = "sdc2_data";
> + bias-pull-up;
> + drive-strength = <10>;
> + };
> + };
> +
> + sdc2_card_det_n: sd-card-det-n {
> + pins = "gpio126";
> + function = "gpio";
> + bias-pull-up;
> + };
> +};
> +
> +&uart6 {
> + status = "okay";
> +
> + bluetooth {
> + compatible = "qcom,wcn3990-bt";
> +
> + vddio-supply = <&vreg_s4a_1p8>;
> + vddxo-supply = <&vreg_l7a_1p8>;
> + vddrf-supply = <&vreg_l17a_1p3>;
> + vddch0-supply = <&vreg_l25a_3p3>;
> + max-speed = <3200000>;
> + };
> +};
> +
> +&usb_1 {
> + status = "okay";
> +};
> +
> +&usb_1_dwc3 {
> + dr_mode = "peripheral";
> +};
> +
> +&usb_1_hsphy {
> + status = "okay";
> +
> + vdd-supply = <&vreg_l1a_0p875>;
> + vdda-pll-supply = <&vreg_l12a_1p8>;
> + vdda-phy-dpdm-supply = <&vreg_l24a_3p075>;
> +
> + qcom,imp-res-offset-value = <8>;
> + qcom,hstx-trim-value = <QUSB2_V2_HSTX_TRIM_21_6_MA>;
> + qcom,preemphasis-level = <QUSB2_V2_PREEMPHASIS_5_PERCENT>;
> + qcom,preemphasis-width = <QUSB2_V2_PREEMPHASIS_WIDTH_HALF_BIT>;
> +};
> +
> +&usb_1_qmpphy {
> + status = "okay";
> +
> + vdda-phy-supply = <&vreg_l26a_1p2>;
> + vdda-pll-supply = <&vreg_l1a_0p875>;
> +};
> +
> +&ufs_mem_hc {
> + status = "okay";
> +
> + reset-gpios = <&tlmm 150 GPIO_ACTIVE_LOW>;
> +
> + vcc-supply = <&vreg_l20a_2p95>;
> + vcc-max-microamp = <800000>;
> +};
> +
> +&ufs_mem_phy {
> + status = "okay";
> +
> + vdda-phy-supply = <&vreg_l1a_0p875>;
> + vdda-pll-supply = <&vreg_l26a_1p2>;
> +};
> +
> +&wifi {
> + status = "okay";
> +
> + vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>;
> + vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
> + vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
> + vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
> +};
> +
> +/* PINCTRL - additions to nodes defined in sdm845.dtsi */
> +
> +&qup_uart6_default {
> + pinmux {
> + pins = "gpio45", "gpio46", "gpio47", "gpio48";
> + function = "qup6";
> + };
> +
> + cts {
> + pins = "gpio45";
> + bias-disable;
> + };
> +
> + rts-tx {
> + pins = "gpio46", "gpio47";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + rx {
> + pins = "gpio48";
> + bias-pull-up;
> + };
> +};
> --
> 2.7.4
>
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
2020-08-05 11:02 [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium) Amit Pundir
@ 2020-08-06 22:31 ` Konrad Dybcio
2020-08-13 7:04 ` your mail Bjorn Andersson
0 siblings, 1 reply; 348+ messages in thread
From: Konrad Dybcio @ 2020-08-06 22:31 UTC (permalink / raw)
To: amit.pundir
Cc: agross, bjorn.andersson, devicetree, john.stultz, linux-arm-msm,
linux-kernel, robh+dt, sumit.semwal, Konrad Dybcio
Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
>// This removed_region is needed to boot the device
> // TODO: Find out the user of this reserved memory
> removed_region: memory@88f00000 {
This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down.
Konrad
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2020-08-06 22:31 ` Konrad Dybcio
@ 2020-08-13 7:04 ` Bjorn Andersson
2020-08-17 17:12 ` Amit Pundir
0 siblings, 1 reply; 348+ messages in thread
From: Bjorn Andersson @ 2020-08-13 7:04 UTC (permalink / raw)
To: Konrad Dybcio
Cc: amit.pundir, agross, devicetree, john.stultz, linux-arm-msm,
linux-kernel, robh+dt, sumit.semwal
On Thu 06 Aug 15:31 PDT 2020, Konrad Dybcio wrote:
> Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
>
> >// This removed_region is needed to boot the device
> > // TODO: Find out the user of this reserved memory
> > removed_region: memory@88f00000 {
>
> This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down.
>
This is in line with what the documentation indicates and then it would
be better to just bump &tz_mem to a size of 0x4900000.
Regards,
Bjorn
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2020-08-13 7:04 ` your mail Bjorn Andersson
@ 2020-08-17 17:12 ` Amit Pundir
2020-08-30 18:58 ` Bjorn Andersson
0 siblings, 1 reply; 348+ messages in thread
From: Amit Pundir @ 2020-08-17 17:12 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Andy Gross, dt, John Stultz, linux-arm-msm, lkml,
Rob Herring, Sumit Semwal
On Thu, 13 Aug 2020 at 12:38, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Thu 06 Aug 15:31 PDT 2020, Konrad Dybcio wrote:
>
> > Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
> >
> > >// This removed_region is needed to boot the device
> > > // TODO: Find out the user of this reserved memory
> > > removed_region: memory@88f00000 {
> >
> > This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down.
> >
>
> This is in line with what the documentation indicates and then it would
> be better to just bump &tz_mem to a size of 0x4900000.
Hi, so just to be sure that I got this right, you want me to extend
&tz_mem to the size of 0x4900000 from the default size of 0x2D00000 by
including this downstream &removed_region (of size 0x1A00000) +
previously unreserved downstream memory region (of size 0x200000), to
align with the starting address of &qseecom_mem?
I just gave this &tz_mem change a spin and I do not see any obvious
regression in my limited smoke testing (Boots AOSP to UI with
v5.9-rc1. Touch/BT/WiFi works) so far, with 20+ out-of-tree patches.
Regards,
Amit Pundir
>
> Regards,
> Bjorn
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2020-08-17 17:12 ` Amit Pundir
@ 2020-08-30 18:58 ` Bjorn Andersson
0 siblings, 0 replies; 348+ messages in thread
From: Bjorn Andersson @ 2020-08-30 18:58 UTC (permalink / raw)
To: Amit Pundir
Cc: Konrad Dybcio, Andy Gross, dt, John Stultz, linux-arm-msm, lkml,
Rob Herring, Sumit Semwal
On Mon 17 Aug 17:12 UTC 2020, Amit Pundir wrote:
> On Thu, 13 Aug 2020 at 12:38, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> >
> > On Thu 06 Aug 15:31 PDT 2020, Konrad Dybcio wrote:
> >
> > > Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
> > >
> > > >// This removed_region is needed to boot the device
> > > > // TODO: Find out the user of this reserved memory
> > > > removed_region: memory@88f00000 {
> > >
> > > This region seems to belong to the Trust Zone. When Linux tries to access it, TZ bites and shuts the device down.
> > >
> >
> > This is in line with what the documentation indicates and then it would
> > be better to just bump &tz_mem to a size of 0x4900000.
>
> Hi, so just to be sure that I got this right, you want me to extend
> &tz_mem to the size of 0x4900000 from the default size of 0x2D00000 by
> including this downstream &removed_region (of size 0x1A00000) +
> previously unreserved downstream memory region (of size 0x200000), to
> align with the starting address of &qseecom_mem?
>
Yes
Regards,
Bjorn
> I just gave this &tz_mem change a spin and I do not see any obvious
> regression in my limited smoke testing (Boots AOSP to UI with
> v5.9-rc1. Touch/BT/WiFi works) so far, with 20+ out-of-tree patches.
>
> Regards,
> Amit Pundir
>
> >
> > Regards,
> > Bjorn
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2020-06-09 11:38 Gaurav Singh
2020-06-09 11:54 ` your mail Greg KH
0 siblings, 1 reply; 348+ messages in thread
From: Gaurav Singh @ 2020-06-09 11:38 UTC (permalink / raw)
To: gaurav1086, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Andrii Nakryiko,
John Fastabend, KP Singh, David S. Miller, Jakub Kicinski,
Jesper Dangaard Brouer,
open list:BPF (Safe dynamic programs and tools),
open list:BPF (Safe dynamic programs and tools),
open list
Please find the patch below.
Thanks and regards,
Gaurav.
From Gaurav Singh <gaurav1086@gmail.com> # This line is ignored.
From: Gaurav Singh <gaurav1086@gmail.com>
Reply-To:
Subject:
In-Reply-To:
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2020-06-09 11:38 Gaurav Singh
@ 2020-06-09 11:54 ` Greg KH
0 siblings, 0 replies; 348+ messages in thread
From: Greg KH @ 2020-06-09 11:54 UTC (permalink / raw)
To: Gaurav Singh
Cc: Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, Andrii Nakryiko, John Fastabend, KP Singh,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
open list:BPF (Safe dynamic programs and tools),
open list:BPF (Safe dynamic programs and tools),
open list
On Tue, Jun 09, 2020 at 07:38:38AM -0400, Gaurav Singh wrote:
> Please find the patch below.
>
> Thanks and regards,
> Gaurav.
>
> >From Gaurav Singh <gaurav1086@gmail.com> # This line is ignored.
> From: Gaurav Singh <gaurav1086@gmail.com>
> Reply-To:
> Subject:
> In-Reply-To:
>
>
I think something went wrong in your submission, just use 'git
send-email' to send the patch out.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2020-05-06 5:52 Jiaxun Yang
2020-05-07 11:00 ` your mail Thomas Bogendoerfer
0 siblings, 1 reply; 348+ messages in thread
From: Jiaxun Yang @ 2020-05-06 5:52 UTC (permalink / raw)
To: linux-mips
Cc: Jiaxun Yang, clang-built-linux, Maciej W . Rozycki, Fangrui Song,
Kees Cook, Nathan Chancellor, Thomas Bogendoerfer, Paul Burton,
Masahiro Yamada, Jouni Hogander, Kevin Darbyshire-Bryant,
Borislav Petkov, Heiko Carstens, linux-kernel
Subject: [PATCH v6] MIPS: Truncate link address into 32bit for 32bit kernel
In-Reply-To: <20200413062651.3992652-1-jiaxun.yang@flygoat.com>
LLD failed to link vmlinux with 64bit load address for 32bit ELF
while bfd will strip 64bit address into 32bit silently.
To fix LLD build, we should truncate load address provided by platform
into 32bit for 32bit kernel.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/786
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784
Reviewed-by: Fangrui Song <maskray@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
---
V2: Take MaskRay's shell magic.
V3: After spent an hour on dealing with special character issue in
Makefile, I gave up to do shell hacks and write a util in C instead.
Thanks Maciej for pointing out Makefile variable problem.
v4: Finally we managed to find a Makefile method to do it properly
thanks to Kees. As it's too far from the initial version, I removed
Review & Test tag from Nick and Fangrui and Cc instead.
v5: Care vmlinuz as well.
v6: Rename to LIKER_LOAD_ADDRESS
---
arch/mips/Makefile | 13 ++++++++++++-
arch/mips/boot/compressed/Makefile | 2 +-
arch/mips/kernel/vmlinux.lds.S | 2 +-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index e1c44aed8156..68c0f22fefc0 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -288,12 +288,23 @@ ifdef CONFIG_64BIT
endif
endif
+# When linking a 32-bit executable the LLVM linker cannot cope with a
+# 32-bit load address that has been sign-extended to 64 bits. Simply
+# remove the upper 32 bits then, as it is safe to do so with other
+# linkers.
+ifdef CONFIG_64BIT
+ load-ld = $(load-y)
+else
+ load-ld = $(subst 0xffffffff,0x,$(load-y))
+endif
+
KBUILD_AFLAGS += $(cflags-y)
KBUILD_CFLAGS += $(cflags-y)
-KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y)
+KBUILD_CPPFLAGS += -DVMLINUX_LOAD_ADDRESS=$(load-y) -DLINKER_LOAD_ADDRESS=$(load-ld)
KBUILD_CPPFLAGS += -DDATAOFFSET=$(if $(dataoffset-y),$(dataoffset-y),0)
bootvars-y = VMLINUX_LOAD_ADDRESS=$(load-y) \
+ LINKER_LOAD_ADDRESS=$(load-ld) \
VMLINUX_ENTRY_ADDRESS=$(entry-y) \
PLATFORM="$(platform-y)" \
ITS_INPUTS="$(its-y)"
diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile
index 0df0ee8a298d..3d391256ab7e 100644
--- a/arch/mips/boot/compressed/Makefile
+++ b/arch/mips/boot/compressed/Makefile
@@ -90,7 +90,7 @@ ifneq ($(zload-y),)
VMLINUZ_LOAD_ADDRESS := $(zload-y)
else
VMLINUZ_LOAD_ADDRESS = $(shell $(obj)/calc_vmlinuz_load_addr \
- $(obj)/vmlinux.bin $(VMLINUX_LOAD_ADDRESS))
+ $(obj)/vmlinux.bin $(LINKER_LOAD_ADDRESS))
endif
UIMAGE_LOADADDR = $(VMLINUZ_LOAD_ADDRESS)
diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
index a5f00ec73ea6..5226cd8e4bee 100644
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -55,7 +55,7 @@ SECTIONS
/* . = 0xa800000000300000; */
. = 0xffffffff80300000;
#endif
- . = VMLINUX_LOAD_ADDRESS;
+ . = LINKER_LOAD_ADDRESS;
/* read-only */
_text = .; /* Text and read-only data */
.text : {
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2020-05-06 5:52 Jiaxun Yang
@ 2020-05-07 11:00 ` Thomas Bogendoerfer
0 siblings, 0 replies; 348+ messages in thread
From: Thomas Bogendoerfer @ 2020-05-07 11:00 UTC (permalink / raw)
To: Jiaxun Yang
Cc: linux-mips, clang-built-linux, Maciej W . Rozycki, Fangrui Song,
Kees Cook, Nathan Chancellor, Paul Burton, Masahiro Yamada,
Jouni Hogander, Kevin Darbyshire-Bryant, Borislav Petkov,
Heiko Carstens, linux-kernel
On Wed, May 06, 2020 at 01:52:45PM +0800, Jiaxun Yang wrote:
> Subject: [PATCH v6] MIPS: Truncate link address into 32bit for 32bit kernel
> In-Reply-To: <20200413062651.3992652-1-jiaxun.yang@flygoat.com>
>
> LLD failed to link vmlinux with 64bit load address for 32bit ELF
> while bfd will strip 64bit address into 32bit silently.
> To fix LLD build, we should truncate load address provided by platform
> into 32bit for 32bit kernel.
>
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> Link: https://github.com/ClangBuiltLinux/linux/issues/786
> Link: https://sourceware.org/bugzilla/show_bug.cgi?id=25784
> Reviewed-by: Fangrui Song <maskray@google.com>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> Cc: Maciej W. Rozycki <macro@linux-mips.org>
> ---
> V2: Take MaskRay's shell magic.
>
> V3: After spent an hour on dealing with special character issue in
> Makefile, I gave up to do shell hacks and write a util in C instead.
> Thanks Maciej for pointing out Makefile variable problem.
>
> v4: Finally we managed to find a Makefile method to do it properly
> thanks to Kees. As it's too far from the initial version, I removed
> Review & Test tag from Nick and Fangrui and Cc instead.
>
> v5: Care vmlinuz as well.
>
> v6: Rename to LIKER_LOAD_ADDRESS
> ---
> arch/mips/Makefile | 13 ++++++++++++-
> arch/mips/boot/compressed/Makefile | 2 +-
> arch/mips/kernel/vmlinux.lds.S | 2 +-
> 3 files changed, 14 insertions(+), 3 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <20191026192359.27687-1-frank-w@public-files.de>]
* Re: your mail
[not found] <20191026192359.27687-1-frank-w@public-files.de>
@ 2019-10-26 19:30 ` Greg Kroah-Hartman
0 siblings, 0 replies; 348+ messages in thread
From: Greg Kroah-Hartman @ 2019-10-26 19:30 UTC (permalink / raw)
To: Frank Wunderlich
Cc: linux-mediatek, Matthias Brugger, linux-serial, linux-arm-kernel,
linux-kernel
On Sat, Oct 26, 2019 at 09:23:59PM +0200, Frank Wunderlich wrote:
> Date: Sat, 26 Oct 2019 20:53:28 +0200
> Subject: [PATCH] serial: 8250-mtk: Ask for IRQ-count before request one
Odd email with no subject line :(
Plaese fix up and resend.
thanks,
greg k-h-
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <20190626145238.19708-1-bigeasy@linutronix.de>]
[parent not found: <20190411060536.22409-1-npiggin@gmail.com>]
* Re: your mail
[not found] <20190411060536.22409-1-npiggin@gmail.com>
@ 2019-04-11 10:53 ` Peter Zijlstra
2019-04-12 3:23 ` Nicholas Piggin
0 siblings, 1 reply; 348+ messages in thread
From: Peter Zijlstra @ 2019-04-11 10:53 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Thomas Gleixner, Frederic Weisbecker, Ingo Molnar, linux-kernel
Was this supposed to be patch 6/5 of your previous series?
On Thu, Apr 11, 2019 at 04:05:36PM +1000, Nicholas Piggin wrote:
> Date: Tue, 9 Apr 2019 20:23:16 +1000
> Subject: [PATCH] kernel/sched: run nohz idle load balancer on HK_FLAG_MISC
> CPUs
>
> The nohz idle balancer runs on the lowest idle CPU. This can
> interfere with isolated CPUs, so confine it to HK_FLAG_MISC
> housekeeping CPUs.
>
> HK_FLAG_SCHED is not used for this because it is not set anywhere
> at the moment. This could be folded into HK_FLAG_SCHED once that
> option is fixed.
>
> The problem was observed with increased jitter on an application
> running on CPU0, caused by nohz idle load balancing being run on
> CPU1 (an SMT sibling).
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> kernel/sched/fair.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index fdab7eb6f351..d29ca323214d 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -9522,22 +9522,26 @@ static inline int on_null_domain(struct rq *rq)
> * - When one of the busy CPUs notice that there may be an idle rebalancing
> * needed, they will kick the idle load balancer, which then does idle
> * load balancing for all the idle CPUs.
> + * - HK_FLAG_MISC CPUs are used for this task, because HK_FLAG_SCHED not set
> + * anywhere yet.
> */
>
> static inline int find_new_ilb(void)
> {
> - int ilb = cpumask_first(nohz.idle_cpus_mask);
> + int ilb;
>
> - if (ilb < nr_cpu_ids && idle_cpu(ilb))
> - return ilb;
> + for_each_cpu_and(ilb, nohz.idle_cpus_mask,
> + housekeeping_cpumask(HK_FLAG_MISC)) {
> + if (idle_cpu(ilb))
> + return ilb;
> + }
>
> return nr_cpu_ids;
> }
>
> /*
> - * Kick a CPU to do the nohz balancing, if it is time for it. We pick the
> - * nohz_load_balancer CPU (if there is one) otherwise fallback to any idle
> - * CPU (if there is one).
> + * Kick a CPU to do the nohz balancing, if it is time for it. We pick any
> + * idle CPU in the HK_FLAG_MISC housekeeping set (if there is one).
> */
> static void kick_ilb(unsigned int flags)
> {
> --
> 2.20.1
>
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2019-04-11 10:53 ` Peter Zijlstra
@ 2019-04-12 3:23 ` Nicholas Piggin
0 siblings, 0 replies; 348+ messages in thread
From: Nicholas Piggin @ 2019-04-12 3:23 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Frederic Weisbecker, linux-kernel, Ingo Molnar, Thomas Gleixner
Peter Zijlstra's on April 11, 2019 8:53 pm:
> Was this supposed to be patch 6/5 of your previous series?
Dang, I screwed up the headers? Thanks for the ping, I will resend.
It is standalone. It seems more suited to the scheduler tree than the
timers one, but your call.
It is generally of more use when CPU0 is _not_ a housekeeping one,
and that's where I've done most testing, but I don't see any hard
dependency.
Thanks,
Nick
>
> On Thu, Apr 11, 2019 at 04:05:36PM +1000, Nicholas Piggin wrote:
>> Date: Tue, 9 Apr 2019 20:23:16 +1000
>> Subject: [PATCH] kernel/sched: run nohz idle load balancer on HK_FLAG_MISC
>> CPUs
>>
>> The nohz idle balancer runs on the lowest idle CPU. This can
>> interfere with isolated CPUs, so confine it to HK_FLAG_MISC
>> housekeeping CPUs.
>>
>> HK_FLAG_SCHED is not used for this because it is not set anywhere
>> at the moment. This could be folded into HK_FLAG_SCHED once that
>> option is fixed.
>>
>> The problem was observed with increased jitter on an application
>> running on CPU0, caused by nohz idle load balancing being run on
>> CPU1 (an SMT sibling).
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> kernel/sched/fair.c | 16 ++++++++++------
>> 1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index fdab7eb6f351..d29ca323214d 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -9522,22 +9522,26 @@ static inline int on_null_domain(struct rq *rq)
>> * - When one of the busy CPUs notice that there may be an idle rebalancing
>> * needed, they will kick the idle load balancer, which then does idle
>> * load balancing for all the idle CPUs.
>> + * - HK_FLAG_MISC CPUs are used for this task, because HK_FLAG_SCHED not set
>> + * anywhere yet.
>> */
>>
>> static inline int find_new_ilb(void)
>> {
>> - int ilb = cpumask_first(nohz.idle_cpus_mask);
>> + int ilb;
>>
>> - if (ilb < nr_cpu_ids && idle_cpu(ilb))
>> - return ilb;
>> + for_each_cpu_and(ilb, nohz.idle_cpus_mask,
>> + housekeeping_cpumask(HK_FLAG_MISC)) {
>> + if (idle_cpu(ilb))
>> + return ilb;
>> + }
>>
>> return nr_cpu_ids;
>> }
>>
>> /*
>> - * Kick a CPU to do the nohz balancing, if it is time for it. We pick the
>> - * nohz_load_balancer CPU (if there is one) otherwise fallback to any idle
>> - * CPU (if there is one).
>> + * Kick a CPU to do the nohz balancing, if it is time for it. We pick any
>> + * idle CPU in the HK_FLAG_MISC housekeeping set (if there is one).
>> */
>> static void kick_ilb(unsigned int flags)
>> {
>> --
>> 2.20.1
>>
>
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <20190323171738.GA26736@titus.pi.local>]
* Re: your mail
[not found] <20190323171738.GA26736@titus.pi.local>
@ 2019-03-26 8:42 ` Dan Carpenter
0 siblings, 0 replies; 348+ messages in thread
From: Dan Carpenter @ 2019-03-26 8:42 UTC (permalink / raw)
To: William J. Cunningham; +Cc: gregkh, devel, linux-kernel
On Sat, Mar 23, 2019 at 01:17:38PM -0400, William J. Cunningham wrote:
> >From bb04b0ca982b7042902fffe1377e0e38e83b402b Mon Sep 17 00:00:00 2001
> From: Will Cunningham <wjcunningham7@gmail.com>
> Date: Sat, 23 Mar 2019 12:54:34 -0400
> Subject: [PATCH] Staging: emxx_udc: emxx_udc: Fixed a coding style error
>
> Removed unnecessary parentheses.
>
> Signed-off-by: Will Cunningham <wjcunningham7@gmail.com>
Please fix up the headers and resend.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <20190319144116.400-1-mlevitsk@redhat.com>]
* Re: your mail
[not found] <20190319144116.400-1-mlevitsk@redhat.com>
@ 2019-03-19 15:22 ` Keith Busch
2019-03-19 23:49 ` Chaitanya Kulkarni
` (2 more replies)
2019-03-21 16:13 ` Stefan Hajnoczi
1 sibling, 3 replies; 348+ messages in thread
From: Keith Busch @ 2019-03-19 15:22 UTC (permalink / raw)
To: Maxim Levitsky
Cc: linux-nvme, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney ,
Paolo Bonzini, Liang Cunming, Liu Changpeng, Fam Zheng,
Amnon Ilan, John Ferlan
On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> -> Share the NVMe device between host and guest.
> Even in fully virtualized configurations,
> some partitions of nvme device could be used by guests as block devices
> while others passed through with nvme-mdev to achieve balance between
> all features of full IO stack emulation and performance.
>
> -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> can send interrupts to the guest directly without a context
> switch that can be expensive due to meltdown mitigation.
>
> -> Is able to utilize interrupts to get reasonable performance.
> This is only implemented
> as a proof of concept and not included in the patches,
> but interrupt driven mode shows reasonable performance
>
> -> This is a framework that later can be used to support NVMe devices
> with more of the IO virtualization built-in
> (IOMMU with PASID support coupled with device that supports it)
Would be very interested to see the PASID support. You wouldn't even
need to mediate the IO doorbells or translations if assigning entire
namespaces, and should be much faster than the shadow doorbells.
I think you should send 6/9 "nvme/pci: init shadow doorbell after each
reset" separately for immediate inclusion.
I like the idea in principle, but it will take me a little time to get
through reviewing your implementation. I would have guessed we could
have leveraged something from the existing nvme/target for the mediating
controller register access and admin commands. Maybe even start with
implementing an nvme passthrough namespace target type (we currently
have block and file).
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2019-03-19 15:22 ` Keith Busch
@ 2019-03-19 23:49 ` Chaitanya Kulkarni
2019-03-20 16:44 ` Maxim Levitsky
2019-03-20 16:30 ` Maxim Levitsky
2019-04-08 10:04 ` Maxim Levitsky
2 siblings, 1 reply; 348+ messages in thread
From: Chaitanya Kulkarni @ 2019-03-19 23:49 UTC (permalink / raw)
To: Keith Busch, Maxim Levitsky
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney ,
Amnon Ilan, Christoph Hellwig, John Ferlan
Hi Keith,
On 03/19/2019 08:21 AM, Keith Busch wrote:
> On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
>> -> Share the NVMe device between host and guest.
>> Even in fully virtualized configurations,
>> some partitions of nvme device could be used by guests as block devices
>> while others passed through with nvme-mdev to achieve balance between
>> all features of full IO stack emulation and performance.
>>
>> -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
>> can send interrupts to the guest directly without a context
>> switch that can be expensive due to meltdown mitigation.
>>
>> -> Is able to utilize interrupts to get reasonable performance.
>> This is only implemented
>> as a proof of concept and not included in the patches,
>> but interrupt driven mode shows reasonable performance
>>
>> -> This is a framework that later can be used to support NVMe devices
>> with more of the IO virtualization built-in
>> (IOMMU with PASID support coupled with device that supports it)
>
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
>
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
>
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).
I have the code for the NVMeOf target passthru-ctrl, I think we can use
that as it is if you are looking for the passthru for NVMeOF.
I'll post patch-series based on the latest code base soon.
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
>
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2019-03-19 23:49 ` Chaitanya Kulkarni
@ 2019-03-20 16:44 ` Maxim Levitsky
0 siblings, 0 replies; 348+ messages in thread
From: Maxim Levitsky @ 2019-03-20 16:44 UTC (permalink / raw)
To: Chaitanya Kulkarni, Keith Busch
Cc: Fam Zheng, Jens Axboe, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-nvme,
linux-kernel, Keith Busch, Alex Williamson, Christoph Hellwig,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, David S . Miller,
John Ferlan
On Tue, 2019-03-19 at 23:49 +0000, Chaitanya Kulkarni wrote:
> Hi Keith,
> On 03/19/2019 08:21 AM, Keith Busch wrote:
> > On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > > -> Share the NVMe device between host and guest.
> > > Even in fully virtualized configurations,
> > > some partitions of nvme device could be used by guests as block
> > > devices
> > > while others passed through with nvme-mdev to achieve balance
> > > between
> > > all features of full IO stack emulation and performance.
> > >
> > > -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> > > can send interrupts to the guest directly without a context
> > > switch that can be expensive due to meltdown mitigation.
> > >
> > > -> Is able to utilize interrupts to get reasonable performance.
> > > This is only implemented
> > > as a proof of concept and not included in the patches,
> > > but interrupt driven mode shows reasonable performance
> > >
> > > -> This is a framework that later can be used to support NVMe devices
> > > with more of the IO virtualization built-in
> > > (IOMMU with PASID support coupled with device that supports it)
> >
> > Would be very interested to see the PASID support. You wouldn't even
> > need to mediate the IO doorbells or translations if assigning entire
> > namespaces, and should be much faster than the shadow doorbells.
> >
> > I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> > reset" separately for immediate inclusion.
> >
> > I like the idea in principle, but it will take me a little time to get
> > through reviewing your implementation. I would have guessed we could
> > have leveraged something from the existing nvme/target for the mediating
> > controller register access and admin commands. Maybe even start with
> > implementing an nvme passthrough namespace target type (we currently
> > have block and file).
>
> I have the code for the NVMeOf target passthru-ctrl, I think we can use
> that as it is if you are looking for the passthru for NVMeOF.
>
> I'll post patch-series based on the latest code base soon.
I am very intersing in this code.
Could you explain how your NVMeOF target passthrough works?
Which components of the NVME stack does it involve?
Best regards,
Maxim Levitsky
> >
> > _______________________________________________
> > Linux-nvme mailing list
> > Linux-nvme@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-nvme
> >
>
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2019-03-19 15:22 ` Keith Busch
2019-03-19 23:49 ` Chaitanya Kulkarni
@ 2019-03-20 16:30 ` Maxim Levitsky
2019-03-20 17:03 ` Keith Busch
2019-04-08 10:04 ` Maxim Levitsky
2 siblings, 1 reply; 348+ messages in thread
From: Maxim Levitsky @ 2019-03-20 16:30 UTC (permalink / raw)
To: Keith Busch
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, Christoph Hellwig,
John Ferlan
On Tue, 2019-03-19 at 09:22 -0600, Keith Busch wrote:
> On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > -> Share the NVMe device between host and guest.
> > Even in fully virtualized configurations,
> > some partitions of nvme device could be used by guests as block
> > devices
> > while others passed through with nvme-mdev to achieve balance between
> > all features of full IO stack emulation and performance.
> >
> > -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> > can send interrupts to the guest directly without a context
> > switch that can be expensive due to meltdown mitigation.
> >
> > -> Is able to utilize interrupts to get reasonable performance.
> > This is only implemented
> > as a proof of concept and not included in the patches,
> > but interrupt driven mode shows reasonable performance
> >
> > -> This is a framework that later can be used to support NVMe devices
> > with more of the IO virtualization built-in
> > (IOMMU with PASID support coupled with device that supports it)
>
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
I fully agree with that.
Note that to enable PASID support two things have to happen in this vendor.
1. Mature support for IOMMU with PASID support. On Intel side I know that they
only have a spec released and currently the kernel bits to support it are
placed.
I still don't know when a product actually supporting this spec is going to be
released. For other vendors (ARM/AMD/) I haven't done yet a research on state of
PASID based IOMMU support on their platforms.
2. NVMe spec has to be extended to support PASID. At minimum, we need an ability
to assign an PASID to a sq/cq queue pair and ability to relocate the doorbells,
such as each guest would get its own (hardware backed) MMIO page with its own
doorbells. Plus of course the hardware vendors have to embrace the spec. I guess
these two things will happen in collaborative manner.
>
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
I'll do this soon.
Also '5/9 nvme/pci: add known admin effects to augment admin effects log page'
can be considered for immediate inclusion as well, as it works around a flaw
in the NVMe controller badly done admin side effects page with no side effects
(pun intended) for spec compliant controllers (I think so).
This can be fixed with a quirk if you prefer though.
>
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).
I fully agree with you on that I could have used some of the nvme/target code,
and I am planning to do so eventually.
For that I would need to make my driver, to be one of the target drivers, and I
would need to add another target back end, like you said to allow my target
driver to talk directly to the nvme hardware bypassing the block layer.
Or instead I can use the block backend,
(but note that currently the block back-end doesn't support polling which is
critical for the performance).
Switch to the target code might though have some (probably minor) performance
impact, as it would probably lengthen the critical code path a bit (I might need
for instance to translate the PRP lists I am getting from the virtual controller
to a scattergather list and back).
This is why I did this the way I did, but now knowing that probably I can afford
to loose a bit of performance, I can look at doing that.
Best regards,
Thanks in advance for the review,
Maxim Levitsky
PS:
For reference currently the IO path looks more or less like that:
My IO thread notices a doorbell write, reads a command from a submission queue,
translates it (without even looking at the data pointer) and sends it to the
nvme pci driver together with pointer to data iterator'.
The nvme pci driver calls the data iterator N times, which makes the iterator
translate and fetch the DMA addresses where the data is already mapped on the
its pci nvme device (the mdev driver maps all the guest memory to the nvme pci
device).
The nvme pci driver uses these addresses it receives, to create a prp list,
which it puts into the data pointer.
The nvme pci driver also allocates an free command id, from a list, puts it into
the command ID and sends the command to the real hardware.
Later the IO thread calls to the nvme pci driver to poll the queue. When
completions arrive, the nvme pci driver returns them back to the IO thread.
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2019-03-20 16:30 ` Maxim Levitsky
@ 2019-03-20 17:03 ` Keith Busch
2019-03-20 17:33 ` Maxim Levitsky
0 siblings, 1 reply; 348+ messages in thread
From: Keith Busch @ 2019-03-20 17:03 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, Christoph Hellwig,
John Ferlan
On Wed, Mar 20, 2019 at 06:30:29PM +0200, Maxim Levitsky wrote:
> Or instead I can use the block backend,
> (but note that currently the block back-end doesn't support polling which is
> critical for the performance).
Oh, I think you can do polling through there. For reference, fs/io_uring.c
has a pretty good implementation that aligns with how you could use it.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2019-03-20 17:03 ` Keith Busch
@ 2019-03-20 17:33 ` Maxim Levitsky
0 siblings, 0 replies; 348+ messages in thread
From: Maxim Levitsky @ 2019-03-20 17:33 UTC (permalink / raw)
To: Keith Busch
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, Christoph Hellwig,
John Ferlan
On Wed, 2019-03-20 at 11:03 -0600, Keith Busch wrote:
> On Wed, Mar 20, 2019 at 06:30:29PM +0200, Maxim Levitsky wrote:
> > Or instead I can use the block backend,
> > (but note that currently the block back-end doesn't support polling which is
> > critical for the performance).
>
> Oh, I think you can do polling through there. For reference, fs/io_uring.c
> has a pretty good implementation that aligns with how you could use it.
That is exactly my thought. The polling recently got lot of improvements in the
block layer, which migh make this feasable.
I will give it a try.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2019-03-19 15:22 ` Keith Busch
2019-03-19 23:49 ` Chaitanya Kulkarni
2019-03-20 16:30 ` Maxim Levitsky
@ 2019-04-08 10:04 ` Maxim Levitsky
2 siblings, 0 replies; 348+ messages in thread
From: Maxim Levitsky @ 2019-04-08 10:04 UTC (permalink / raw)
To: Keith Busch
Cc: Fam Zheng, Keith Busch, Sagi Grimberg, kvm, Wolfram Sang,
Greg Kroah-Hartman, Liang Cunming, Nicolas Ferre, linux-kernel,
linux-nvme, David S . Miller, Jens Axboe, Alex Williamson,
Kirti Wankhede, Mauro Carvalho Chehab, Paolo Bonzini,
Liu Changpeng, Paul E . McKenney, Amnon Ilan, Christoph Hellwig,
John Ferlan
On Tue, 2019-03-19 at 09:22 -0600, Keith Busch wrote:
> On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > -> Share the NVMe device between host and guest.
> > Even in fully virtualized configurations,
> > some partitions of nvme device could be used by guests as block
> > devices
> > while others passed through with nvme-mdev to achieve balance between
> > all features of full IO stack emulation and performance.
> >
> > -> NVME-MDEV is a bit faster due to the fact that in-kernel driver
> > can send interrupts to the guest directly without a context
> > switch that can be expensive due to meltdown mitigation.
> >
> > -> Is able to utilize interrupts to get reasonable performance.
> > This is only implemented
> > as a proof of concept and not included in the patches,
> > but interrupt driven mode shows reasonable performance
> >
> > -> This is a framework that later can be used to support NVMe devices
> > with more of the IO virtualization built-in
> > (IOMMU with PASID support coupled with device that supports it)
>
> Would be very interested to see the PASID support. You wouldn't even
> need to mediate the IO doorbells or translations if assigning entire
> namespaces, and should be much faster than the shadow doorbells.
>
> I think you should send 6/9 "nvme/pci: init shadow doorbell after each
> reset" separately for immediate inclusion.
>
> I like the idea in principle, but it will take me a little time to get
> through reviewing your implementation. I would have guessed we could
> have leveraged something from the existing nvme/target for the mediating
> controller register access and admin commands. Maybe even start with
> implementing an nvme passthrough namespace target type (we currently
> have block and file).
Hi!
Sorry to bother you, but any update?
I was somewhat sick for the last week, now finally back in shape to continue
working on this and other tasks I have.
I am studing now the nvme target code and the io_uring to evaluate the
difficultiy of using something similiar to talk to the block device instead of /
in addtion to the direct connection I implemented.
I would be glad to hear more feedback on this project.
I will also soon post the few fixes separately as you suggested.
Best regards,
Maxim Levitskky
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
[not found] <20190319144116.400-1-mlevitsk@redhat.com>
2019-03-19 15:22 ` Keith Busch
@ 2019-03-21 16:13 ` Stefan Hajnoczi
2019-03-21 17:07 ` Maxim Levitsky
1 sibling, 1 reply; 348+ messages in thread
From: Stefan Hajnoczi @ 2019-03-21 16:13 UTC (permalink / raw)
To: Maxim Levitsky
Cc: linux-nvme, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney ,
Paolo Bonzini, Liang Cunming, Liu Changpeng, Fam Zheng,
Amnon Ilan, John Ferlan
[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]
On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> Date: Tue, 19 Mar 2019 14:45:45 +0200
> Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
>
> Hi everyone!
>
> In this patch series, I would like to introduce my take on the problem of doing
> as fast as possible virtualization of storage with emphasis on low latency.
>
> In this patch series I implemented a kernel vfio based, mediated device that
> allows the user to pass through a partition and/or whole namespace to a guest.
>
> The idea behind this driver is based on paper you can find at
> https://www.usenix.org/conference/atc18/presentation/peng,
>
> Although note that I stared the development prior to reading this paper,
> independently.
>
> In addition to that implementation is not based on code used in the paper as
> I wasn't being able at that time to make the source available to me.
>
> ***Key points about the implementation:***
>
> * Polling kernel thread is used. The polling is stopped after a
> predefined timeout (1/2 sec by default).
> Support for all interrupt driven mode is planned, and it shows promising results.
>
> * Guest sees a standard NVME device - this allows to run guest with
> unmodified drivers, for example windows guests.
>
> * The NVMe device is shared between host and guest.
> That means that even a single namespace can be split between host
> and guest based on different partitions.
>
> * Simple configuration
>
> *** Performance ***
>
> Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
> and both latency and throughput is very similar to SPDK.
>
> Soon I will test this on a better server and nvme device and provide
> more formal performance numbers.
>
> Latency numbers:
> ~80ms - spdk with fio plugin on the host.
> ~84ms - nvme driver on the host
> ~87ms - mdev-nvme + nvme driver in the guest
You mentioned the spdk numbers are with vhost-user-nvme. Have you
measured SPDK's vhost-user-blk?
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2019-03-21 16:13 ` Stefan Hajnoczi
@ 2019-03-21 17:07 ` Maxim Levitsky
2019-03-25 16:46 ` Stefan Hajnoczi
0 siblings, 1 reply; 348+ messages in thread
From: Maxim Levitsky @ 2019-03-21 17:07 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: linux-nvme, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney, Paolo Bonzini,
Liang Cunming, Liu Changpeng, Fam Zheng, Amnon Ilan, John Ferlan
On Thu, 2019-03-21 at 16:13 +0000, Stefan Hajnoczi wrote:
> On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > Date: Tue, 19 Mar 2019 14:45:45 +0200
> > Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> >
> > Hi everyone!
> >
> > In this patch series, I would like to introduce my take on the problem of
> > doing
> > as fast as possible virtualization of storage with emphasis on low latency.
> >
> > In this patch series I implemented a kernel vfio based, mediated device
> > that
> > allows the user to pass through a partition and/or whole namespace to a
> > guest.
> >
> > The idea behind this driver is based on paper you can find at
> > https://www.usenix.org/conference/atc18/presentation/peng,
> >
> > Although note that I stared the development prior to reading this paper,
> > independently.
> >
> > In addition to that implementation is not based on code used in the paper
> > as
> > I wasn't being able at that time to make the source available to me.
> >
> > ***Key points about the implementation:***
> >
> > * Polling kernel thread is used. The polling is stopped after a
> > predefined timeout (1/2 sec by default).
> > Support for all interrupt driven mode is planned, and it shows promising
> > results.
> >
> > * Guest sees a standard NVME device - this allows to run guest with
> > unmodified drivers, for example windows guests.
> >
> > * The NVMe device is shared between host and guest.
> > That means that even a single namespace can be split between host
> > and guest based on different partitions.
> >
> > * Simple configuration
> >
> > *** Performance ***
> >
> > Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
> > and both latency and throughput is very similar to SPDK.
> >
> > Soon I will test this on a better server and nvme device and provide
> > more formal performance numbers.
> >
> > Latency numbers:
> > ~80ms - spdk with fio plugin on the host.
> > ~84ms - nvme driver on the host
> > ~87ms - mdev-nvme + nvme driver in the guest
>
> You mentioned the spdk numbers are with vhost-user-nvme. Have you
> measured SPDK's vhost-user-blk?
I had lot of measuments of vhost-user-blk vs vhost-user-nvme.
vhost-user-nvme was always a bit faster but only a bit.
Thus I don't think it makes sense to benchamrk against vhost-user-blk.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2019-03-21 17:07 ` Maxim Levitsky
@ 2019-03-25 16:46 ` Stefan Hajnoczi
0 siblings, 0 replies; 348+ messages in thread
From: Stefan Hajnoczi @ 2019-03-25 16:46 UTC (permalink / raw)
To: Maxim Levitsky
Cc: linux-nvme, linux-kernel, kvm, Jens Axboe, Alex Williamson,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Kirti Wankhede,
David S . Miller, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Wolfram Sang, Nicolas Ferre, Paul E . McKenney, Paolo Bonzini,
Liang Cunming, Liu Changpeng, Fam Zheng, Amnon Ilan, John Ferlan
[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]
On Thu, Mar 21, 2019 at 07:07:38PM +0200, Maxim Levitsky wrote:
> On Thu, 2019-03-21 at 16:13 +0000, Stefan Hajnoczi wrote:
> > On Tue, Mar 19, 2019 at 04:41:07PM +0200, Maxim Levitsky wrote:
> > > Date: Tue, 19 Mar 2019 14:45:45 +0200
> > > Subject: [PATCH 0/9] RFC: NVME VFIO mediated device
> > >
> > > Hi everyone!
> > >
> > > In this patch series, I would like to introduce my take on the problem of
> > > doing
> > > as fast as possible virtualization of storage with emphasis on low latency.
> > >
> > > In this patch series I implemented a kernel vfio based, mediated device
> > > that
> > > allows the user to pass through a partition and/or whole namespace to a
> > > guest.
> > >
> > > The idea behind this driver is based on paper you can find at
> > > https://www.usenix.org/conference/atc18/presentation/peng,
> > >
> > > Although note that I stared the development prior to reading this paper,
> > > independently.
> > >
> > > In addition to that implementation is not based on code used in the paper
> > > as
> > > I wasn't being able at that time to make the source available to me.
> > >
> > > ***Key points about the implementation:***
> > >
> > > * Polling kernel thread is used. The polling is stopped after a
> > > predefined timeout (1/2 sec by default).
> > > Support for all interrupt driven mode is planned, and it shows promising
> > > results.
> > >
> > > * Guest sees a standard NVME device - this allows to run guest with
> > > unmodified drivers, for example windows guests.
> > >
> > > * The NVMe device is shared between host and guest.
> > > That means that even a single namespace can be split between host
> > > and guest based on different partitions.
> > >
> > > * Simple configuration
> > >
> > > *** Performance ***
> > >
> > > Performance was tested on Intel DC P3700, With Xeon E5-2620 v2
> > > and both latency and throughput is very similar to SPDK.
> > >
> > > Soon I will test this on a better server and nvme device and provide
> > > more formal performance numbers.
> > >
> > > Latency numbers:
> > > ~80ms - spdk with fio plugin on the host.
> > > ~84ms - nvme driver on the host
> > > ~87ms - mdev-nvme + nvme driver in the guest
> >
> > You mentioned the spdk numbers are with vhost-user-nvme. Have you
> > measured SPDK's vhost-user-blk?
>
> I had lot of measuments of vhost-user-blk vs vhost-user-nvme.
> vhost-user-nvme was always a bit faster but only a bit.
> Thus I don't think it makes sense to benchamrk against vhost-user-blk.
It's interesting because mdev-nvme is closest to the hardware while
vhost-user-blk is closest to software. Doing things at the NVMe level
isn't buying much performance because it's still going through a
software path comparable to vhost-user-blk.
From what you say it sounds like there isn't much to optimize away :(.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <20190319022012.11051-1-thirtythreeforty@gmail.com>]
* Re: your mail
[not found] <20190319022012.11051-1-thirtythreeforty@gmail.com>
@ 2019-03-20 7:26 ` Greg Kroah-Hartman
0 siblings, 0 replies; 348+ messages in thread
From: Greg Kroah-Hartman @ 2019-03-20 7:26 UTC (permalink / raw)
To: George Hilliard; +Cc: linux-mips, linux-kernel
On Mon, Mar 18, 2019 at 08:20:01PM -0600, George Hilliard wrote:
> Because of this change, the driver now expects a pinctrl device
> reference in the mmc controller's device tree node; without it, it will
> bail out. This could break existing setups that don't specify it
> because it "just worked" up until now. So currently I just let the old
> behavior fall away because this is a staging driver. But if this is a
> problem, the old behavior could be added back as a fallback.
>
> This is version 2 of a patchset that I requested feedback for about a
> month ago. Please review as if they are a new patchset; all the patches
> were rebased several times and a couple new correctness fixes added.
>
> The TODO list is largely unchanged, aside from the couple of TODO
> comments in the code that I have addressed. Ultimately, I think this
> driver could potentially be merged with the "real" mtk-mmc driver as the
> TODO suggests, but someone who is more familiar with the IP core will
> have to do that. Mediatek documentation (that I can find) is very
> sparse.
>
> This is ready to merge if there is no other feedback!
>
> >From George Hilliard <thirtythreeforty@gmail.com> # This line is ignored.
> From: George Hilliard <thirtythreeforty@gmail.com>
> Reply-To:
> Subject: [PATCH v2 00/11] mt7621-mmc: Various correctness fixes
> In-Reply-To:
>
>
No subject for this email?
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <20190225201635.4648-1-hannes@cmpxchg.org>]
* Re: your mail
[not found] <20190225201635.4648-1-hannes@cmpxchg.org>
@ 2019-02-26 23:49 ` Roman Gushchin
0 siblings, 0 replies; 348+ messages in thread
From: Roman Gushchin @ 2019-02-26 23:49 UTC (permalink / raw)
To: up, the, LRU, counts, tracking
Cc: Andrew Morton, Tejun Heo, linux-mm, cgroups, linux-kernel, Kernel Team
On Mon, Feb 25, 2019 at 03:16:29PM -0500, Johannes Weiner wrote:
> [resending, rebased on top of latest mmots]
>
> The memcg LRU stats usage is currently a bit messy. Memcg has private
> per-zone counters because reclaim needs zone granularity sometimes,
> but we also have plenty of users that need to awkwardly sum them up to
> node or memcg granularity. Meanwhile the canonical per-memcg vmstats
> do not track the LRU counts (NR_INACTIVE_ANON etc.) as you'd expect.
>
> This series enables LRU count tracking in the per-memcg vmstats array
> such that lruvec_page_state() and memcg_page_state() work on the enum
> node_stat_item items for the LRU counters. Then it converts all the
> callers that don't specifically need per-zone numbers over to that.
The updated version looks very good* to me!
Please, feel free to use:
Reviewed-by: Roman Gushchin <guro@fb.com>
Looking through the patchset, I have a feeling that we're sometimes
gathering too much data. Perhaps we don't need the whole set
of counters to be per-cpu on both memcg- and memcg-per-node levels.
Merging them can save quite a lot of space. Anyway, it's a separate
topic.
* except "to" and "subject" of the cover letter
Thanks!
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <20180827145032.9522-1-hch@lst.de>]
* Re: your mail
[not found] <20180827145032.9522-1-hch@lst.de>
@ 2018-08-31 20:23 ` Paul Burton
0 siblings, 0 replies; 348+ messages in thread
From: Paul Burton @ 2018-08-31 20:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: iommu, Marek Szyprowski, Robin Murphy, Greg Kroah-Hartman,
linux-mips, linux-kernel
Hi Christoph,
On Mon, Aug 27, 2018 at 04:50:27PM +0200, Christoph Hellwig wrote:
> Subject: [RFC] merge dma_direct_ops and dma_noncoherent_ops
>
> While most architectures are either always or never dma coherent for a
> given build, the arm, arm64, mips and soon arc architectures can have
> different dma coherent settings on a per-device basis. Additionally
> some mips builds can decide at boot time if dma is coherent or not.
>
> I've started to look into handling noncoherent dma in swiotlb, and
> moving the dma-iommu ops into common code [1], and for that we need a
> generic way to check if a given device is coherent or not. Moving
> this flag into struct device also simplifies the conditionally coherent
> architecture implementations.
>
> These patches are also available in a git tree given that they have
> a few previous posted dependencies:
>
> git://git.infradead.org/users/hch/misc.git dma-direct-noncoherent-merge
>
> Gitweb:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-direct-noncoherent-merge
Apart from the nits in patch 2, these look sane to me from a MIPS
perspective, so for patches 1-4:
Acked-by: Paul Burton <paul.burton@mips.com> # MIPS parts
Thanks,
Paul
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <20180724222212.8742-1-tsotsos@gmail.com>]
* Re: your mail
[not found] <20180724222212.8742-1-tsotsos@gmail.com>
@ 2018-07-25 7:39 ` Greg Kroah-Hartman
0 siblings, 0 replies; 348+ messages in thread
From: Greg Kroah-Hartman @ 2018-07-25 7:39 UTC (permalink / raw)
To: Georgios Tsotsos; +Cc: devel, James Hogan, linux-kernel, Aaro Koskinen
On Wed, Jul 25, 2018 at 01:22:07AM +0300, Georgios Tsotsos wrote:
> Date: Wed, 25 Jul 2018 01:18:58 +0300
> Subject: [PATCH 0/4] Staging: octeon-usb: Fixes and Coding style applied.
>
> Hello,
Somehow your subject here got messed up and put in the bod of the email.
Not a big deal this time, but be more careful next time please.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <2018071901551081442221@163.com>]
* Re: your mail
[not found] <2018071901551081442221@163.com>
@ 2018-07-18 20:04 ` Johan Hovold
0 siblings, 0 replies; 348+ messages in thread
From: Johan Hovold @ 2018-07-18 20:04 UTC (permalink / raw)
To: m13297920107; +Cc: johan, gregkh, linux-usb, linux-kernel, moviesong, billli
On Thu, Jul 19, 2018 at 01:55:12AM +0800, m13297920107@163.com wrote:
> From 14bd57ea5c5fc385bd36b5a3ea5c805337bbc8db Mon Sep 17 00:00:00 2001
> From: Movie Song <MovieSong@aten-itlab.cn>
> Date: Thu, 19 Jul 2018 02:20:48 +0800
> Subject: [PATCH] USB:serial:pl2303:add a new device id for ATEN
Add spaces after the colons (':') in the Subject above, and place a
short commit message here before your SoB.
> Signed-off-by:MovieSong<MovieSong@aten-itlab.cn>
Missing spaces in you SoB as well.
> ---
> drivers/usb/serial/pl2303.c | 2 ++
> drivers/usb/serial/pl2303.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
> index 5d1a193..e41f725 100644
> --- a/drivers/usb/serial/pl2303.c
> +++ b/drivers/usb/serial/pl2303.c
> @@ -52,6 +52,8 @@
> .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
> { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_UC485),
> .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
> + { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_UC232B),
> + .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
> { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID2) },
> { USB_DEVICE(ATEN_VENDOR_ID2, ATEN_PRODUCT_ID) },
> { USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID) },
> diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
> index fcd7239..26965cc 100644
> --- a/drivers/usb/serial/pl2303.h
> +++ b/drivers/usb/serial/pl2303.h
> @@ -24,6 +24,7 @@
> #define ATEN_VENDOR_ID2 0x0547
> #define ATEN_PRODUCT_ID 0x2008
> #define ATEN_PRODUCT_UC485 0x2021
> +#define ATEN_PRODUCT_UC232B 0x2022
> #define ATEN_PRODUCT_ID2 0x2118
>
> #define IODATA_VENDOR_ID 0x04bb
As I suggested earlier, try sending the patch to yourself first and run
scripts/checkpatch.pl on it. The patch is still whitespace corrupted
(probably by your mail client) as checkpatch would have let you know:
WARNING: Use a single space after Signed-off-by:
#13:
Signed-off-by:MovieSong<MovieSong@aten-itlab.cn>
WARNING: email address 'MovieSong<MovieSong@aten-itlab.cn>' might be better as 'MovieSong <MovieSong@aten-itlab.cn>'
#13:
Signed-off-by:MovieSong<MovieSong@aten-itlab.cn>
WARNING: please, no spaces at the start of a line
#27: FILE: drivers/usb/serial/pl2303.c:55:
+ { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_UC232B),$
WARNING: please, no spaces at the start of a line
#28: FILE: drivers/usb/serial/pl2303.c:56:
+ .driver_info = PL2303_QUIRK_ENDPOINT_HACK },$
total: 1 errors, 4 warnings, 15 lines checked
git-send-email is convenient for sending patches (e.g. generated with
git-format-patch). Perhaps you can set that up.
One more try?
Thanks,
Johan
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <201807160555.w6G5t9Dc075492@mse.aten.com.tw>]
* Re: your mail
[not found] <201807160555.w6G5t9Dc075492@mse.aten.com.tw>
@ 2018-07-16 10:03 ` Johan Hovold
0 siblings, 0 replies; 348+ messages in thread
From: Johan Hovold @ 2018-07-16 10:03 UTC (permalink / raw)
To: moviesong; +Cc: johan, gregkh, linux-usb, linux-kernel, YorkDai, BillLi
On Mon, Jul 16, 2018 at 09:46:05AM +0800, MovieSong wrote:
> From cff42ec450bdd1fb44dd80564cb622660a9a8071 Mon Sep 17 00:00:00 2001
> From: Movie Song <MovieSong@aten-itlab.cn>
> Date: Fri, 13 Jul 2018 17:46:19 +0800
> Subject: [PATCH] This add a new device for ATEN
>
> Signed-off-by: Movie Song <MovieSong@aten-itlab.cn>
First, your mail still has the legal disclaimer footer which prevents us
from using this patch.
Second, the patch is now inline, but it's unfortunately white-space
damaged (tabs replaces with spaces).
Take a look at
https://marc.info/?l=linux-usb&m=150576193231309
for an example of what the subject and commit message should look like.
Send it to yourself first and make sure it has no legal disclaimer
footers, and that you can apply it using git-am.
> ---
> drivers/usb/serial/pl2303.c | 2 ++
> drivers/usb/serial/pl2303.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
> index 5d1a193..99f7e1f 100644
> --- a/drivers/usb/serial/pl2303.c
> +++ b/drivers/usb/serial/pl2303.c
> @@ -52,6 +52,8 @@
> .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
> { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_UC485),
> .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
> + { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_UC485),
> + .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
And here you add a duplicate entry instead of the one based on the new
id you add.
> { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID2) },
> { USB_DEVICE(ATEN_VENDOR_ID2, ATEN_PRODUCT_ID) },
> { USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID) },
> diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
> index fcd7239..26965cc 100644
> --- a/drivers/usb/serial/pl2303.h
> +++ b/drivers/usb/serial/pl2303.h
> @@ -24,6 +24,7 @@
> #define ATEN_VENDOR_ID2 0x0547
> #define ATEN_PRODUCT_ID 0x2008
> #define ATEN_PRODUCT_UC485 0x2021
> +#define ATEN_PRODUCT_UC232B 0x2022
> #define ATEN_PRODUCT_ID2 0x2118
>
> #define IODATA_VENDOR_ID 0x04bb
Thanks,
Johan
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH v2] staging: rts5208: add check on NULL before dereference
@ 2018-06-13 17:00 Andy Shevchenko
[not found] ` <20180613173128.32384-1-vasilyev@ispras.ru>
0 siblings, 1 reply; 348+ messages in thread
From: Andy Shevchenko @ 2018-06-13 17:00 UTC (permalink / raw)
To: Anton Vasilyev
Cc: Dan Carpenter, Sinan Kaya, Johannes Thumshirn, Gaurav Pathak,
Hannes Reinecke, devel, Linux Kernel Mailing List, ldv-project
On Wed, Jun 13, 2018 at 7:55 PM, Anton Vasilyev <vasilyev@ispras.ru> wrote:
> If rtsx_probe() fails to allocate dev->chip, then NULL pointer
> dereference occurs at release_everything()->rtsx_release_resources().
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
You forgot to adjust subject and commit message to the new reality
which is brought by this change.
> Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
> ---
> v2: Add error handling into rtsx_probe based on Dan Carpenter's comment.
> I do not have corresponding hardware, so patch was tested by compilation only.
>
> I faced with inaccuracy at rtsx_remove() and original rtsx_probe():
> there is quiesce_and_remove_host() call with scsi_remove_host() inside,
> whereas release_everything() calls scsi_host_put() after this
> scsi_remove_host() call. This is strange for me.
>
> Also I do not know is it require to check result value of
> rtsx_init_chip() call on rtsx_probe().
> ---
> drivers/staging/rts5208/rtsx.c | 38 +++++++++++++++++++++++-----------
> 1 file changed, 26 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c
> index 70e0b8623110..69e6abe14abf 100644
> --- a/drivers/staging/rts5208/rtsx.c
> +++ b/drivers/staging/rts5208/rtsx.c
> @@ -857,7 +857,7 @@ static int rtsx_probe(struct pci_dev *pci,
> dev->chip = kzalloc(sizeof(*dev->chip), GFP_KERNEL);
> if (!dev->chip) {
> err = -ENOMEM;
> - goto errout;
> + goto chip_alloc_fail;
> }
>
> spin_lock_init(&dev->reg_lock);
> @@ -879,7 +879,7 @@ static int rtsx_probe(struct pci_dev *pci,
> if (!dev->remap_addr) {
> dev_err(&pci->dev, "ioremap error\n");
> err = -ENXIO;
> - goto errout;
> + goto ioremap_fail;
> }
>
> /*
> @@ -894,7 +894,7 @@ static int rtsx_probe(struct pci_dev *pci,
> if (!dev->rtsx_resv_buf) {
> dev_err(&pci->dev, "alloc dma buffer fail\n");
> err = -ENXIO;
> - goto errout;
> + goto dma_alloc_fail;
> }
> dev->chip->host_cmds_ptr = dev->rtsx_resv_buf;
> dev->chip->host_cmds_addr = dev->rtsx_resv_buf_addr;
> @@ -915,7 +915,7 @@ static int rtsx_probe(struct pci_dev *pci,
>
> if (rtsx_acquire_irq(dev) < 0) {
> err = -EBUSY;
> - goto errout;
> + goto irq_acquire_fail;
> }
>
> pci_set_master(pci);
> @@ -935,14 +935,14 @@ static int rtsx_probe(struct pci_dev *pci,
> if (IS_ERR(th)) {
> dev_err(&pci->dev, "Unable to start control thread\n");
> err = PTR_ERR(th);
> - goto errout;
> + goto control_thread_fail;
> }
> dev->ctl_thread = th;
>
> err = scsi_add_host(host, &pci->dev);
> if (err) {
> dev_err(&pci->dev, "Unable to add the scsi host\n");
> - goto errout;
> + goto scsi_add_host_fail;
> }
>
> /* Start up the thread for delayed SCSI-device scanning */
> @@ -950,18 +950,16 @@ static int rtsx_probe(struct pci_dev *pci,
> if (IS_ERR(th)) {
> dev_err(&pci->dev, "Unable to start the device-scanning thread\n");
> complete(&dev->scanning_done);
> - quiesce_and_remove_host(dev);
> err = PTR_ERR(th);
> - goto errout;
> + goto scan_thread_fail;
> }
>
> /* Start up the thread for polling thread */
> th = kthread_run(rtsx_polling_thread, dev, "rtsx-polling");
> if (IS_ERR(th)) {
> dev_err(&pci->dev, "Unable to start the device-polling thread\n");
> - quiesce_and_remove_host(dev);
> err = PTR_ERR(th);
> - goto errout;
> + goto scan_thread_fail;
> }
> dev->polling_thread = th;
>
> @@ -970,9 +968,25 @@ static int rtsx_probe(struct pci_dev *pci,
> return 0;
>
> /* We come here if there are any problems */
> -errout:
> +scan_thread_fail:
> + quiesce_and_remove_host(dev);
> +scsi_add_host_fail:
> + complete(&dev->cmnd_ready);
> + wait_for_completion(&dev->control_exit);
> +control_thread_fail:
> + free_irq(dev->irq, (void *)dev);
> + rtsx_release_chip(dev->chip);
> +irq_acquire_fail:
> + dev->chip->host_cmds_ptr = NULL;
> + dev->chip->host_sg_tbl_ptr = NULL;
> + if (dev->chip->msi_en)
> + pci_disable_msi(dev->pci);
> +dma_alloc_fail:
> + iounmap(dev->remap_addr);
> +ioremap_fail:
> + kfree(dev->chip);
> +chip_alloc_fail:
> dev_err(&pci->dev, "%s failed\n", __func__);
> - release_everything(dev);
>
> return err;
> }
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2017-12-07 9:26 Alexander Kappner
2017-12-07 10:38 ` your mail Greg Kroah-Hartman
0 siblings, 1 reply; 348+ messages in thread
From: Alexander Kappner @ 2017-12-07 9:26 UTC (permalink / raw)
To: mathias.nyman, Greg Kroah-Hartman, linux-usb, linux-kernel
Cc: Alexander Kappner
Date: Wed, 6 Dec 2017 15:28:37 -0800
Subject: [PATCH] usb-core: Fix potential null pointer dereference in xhci-debugfs.c
My kernel crashed just after resuming from hibernate and starting usbmuxd
(a user-space daemon for iOS device pairing) with several USB devices
connected (dmesg attached).
Backtrace leads to:
0xffffffff8170465d is in xhci_debugfs_create_endpoint
(drivers/usb/host/xhci-debugfs.c:381).
376 int ep_index)
377 {
378 struct xhci_ep_priv *epriv;
379 struct xhci_slot_priv *spriv = dev->debugfs_private;
380
381 if (spriv->eps[ep_index])
382 return;
383
384 epriv = kzalloc(sizeof(*epriv), GFP_KERNEL);
385 if (!epriv)
The read violation happens at address 0x40 and sizeof(struct
xhci_ep_priv)=0x40, so it seems ep_index is 1 and spriv is NULL here.
spriv gets allocated in xhci_debugfs_create_slot:
...
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
return;
...
There's no separate error path if this allocation fails, so we might be
left with NULL in priv. Subsequent users of priv thus need to check for
this NULL - so this is what the patch does.
There might be other ways of triggering this null pointer dereference,
including when xhci_resume frees the device structures (e.g. after
returning from a hibernate), but I wasn't able to find or reproduce it.
[63953.758083] BUG: unable to handle kernel NULL pointer dereference at
0000000000000040
[63953.758090] IP: xhci_debugfs_create_endpoint+0x1d/0xa0
[63953.758091] PGD bb911d067 P4D bb911d067 PUD 10500ff067 PMD 0
[63953.758093] Oops: 0000 [#1] PREEMPT SMP
[63953.758094] Modules linked in: ipheth tun nvidia_modeset(PO) iwlmvm
mac80211 iwlwifi nvidia(PO) btusb btrtl btbcm btintel bluetooth cfg80211
qmi_wwan ecdh_generic thinkpad_acpi rfkill
[63953.758103] CPU: 4 PID: 27091 Comm: usbmuxd Tainted: P O
4.14.0.1-12769-g1deab8c #1
[63953.758104] Hardware name: LENOVO 20ENCTO1WW/20ENCTO1WW, BIOS N1EET62W
(1.35 ) 11/10/2016
[63953.758105] task: ffff8810527ba0c0 task.stack: ffffc9000a8ec000
[63953.758107] RIP: 0010:xhci_debugfs_create_endpoint+0x1d/0xa0
[63953.758108] RSP: 0018:ffffc9000a8efc80 EFLAGS: 00010206
[63953.758109] RAX: 0000000000000000 RBX: ffff88105a71c000 RCX:
0000000000030000
[63953.758110] RDX: 0000000000000003 RSI: ffff880c0b57e000 RDI:
ffff88105a71c238
[63953.758110] RBP: 0000000000000003 R08: ffff881063800600 R09:
0000000000000003
[63953.758111] R10: ffff88105a71c238 R11: 0000000000000001 R12:
0000000000000011
[63953.758112] R13: 0000000000000018 R14: 0000000000000000 R15:
0000000000000000
[63953.758113] FS: 00007f0a77715700(0000) GS:ffff8810a3d00000(0000)
knlGS:0000000000000000
[63953.758114] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[63953.758115] CR2: 0000000000000040 CR3: 00000003f91a8006 CR4:
00000000003606e0
[63953.758115] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[63953.758116] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[63953.758117] Call Trace:
[63953.758120] xhci_add_endpoint+0x127/0x2b0
[63953.758123] usb_hcd_alloc_bandwidth+0x1ad/0x300
[63953.758125] usb_set_configuration+0x1c8/0x880
[63953.758128] usbdev_do_ioctl+0xc41/0x1120
[63953.758130] usbdev_ioctl+0xa/0x10
[63953.758151] do_vfs_ioctl+0x8b/0x5c0
[63953.758153] ? __fget+0x6c/0xb0
[63953.758155] SyS_ioctl+0x76/0x90
[63953.758157] do_syscall_64+0x6b/0x290
[63953.758173] entry_SYSCALL64_slow_path+0x25/0x25
[63953.758175] RIP: 0033:0x7f0a76a151c7
[63953.758175] RSP: 002b:00007ffd1431b0c8 EFLAGS: 00000202 ORIG_RAX:
0000000000000010
[63953.758177] RAX: ffffffffffffffda RBX: 00000000023239a0 RCX:
00007f0a76a151c7
[63953.758178] RDX: 00007ffd1431b0dc RSI: 0000000080045505 RDI:
000000000000000e
[63953.758178] RBP: 00000000023240c0 R08: 00007ffd1431b008 R09:
0000000000000004
[63953.758179] R10: 00007ffd1431aec0 R11: 0000000000000202 R12:
00000000023240c0
[63953.758180] R13: 0000000000000001 R14: 0000000000000056 R15:
0000000000000038
[63953.758182] Code: e9 39 ff ff ff 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00
00 41 57 41 56 41 55 41 54 55 48 63 ea 53 4c 8b b6 88 15 00 00 4d 8d 2c ee
<49> 83 7d 28 00 74 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 8b 3d
[63953.758202] RIP: xhci_debugfs_create_endpoint+0x1d/0xa0 RSP:
ffffc9000a8efc80
[63953.758203] CR2: 0000000000000040
[63953.758204] ---[ end trace 1f7ea9a959f02054 ]---
Signed-off-by: Alexander Kappner <agk@godking.net>
---
drivers/usb/host/xhci-debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
index 4f7895d..1cea59c 100644
--- a/drivers/usb/host/xhci-debugfs.c
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -378,6 +378,9 @@ void xhci_debugfs_create_endpoint(struct xhci_hcd *xhci,
struct xhci_ep_priv *epriv;
struct xhci_slot_priv *spriv = dev->debugfs_private;
+ if (!spriv)
+ return;
+
if (spriv->eps[ep_index])
return;
--
2.1.4
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2017-12-07 9:26 Alexander Kappner
@ 2017-12-07 10:38 ` Greg Kroah-Hartman
0 siblings, 0 replies; 348+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-07 10:38 UTC (permalink / raw)
To: Alexander Kappner; +Cc: mathias.nyman, linux-usb, linux-kernel
On Thu, Dec 07, 2017 at 01:26:14AM -0800, Alexander Kappner wrote:
> Date: Wed, 6 Dec 2017 15:28:37 -0800
> Subject: [PATCH] usb-core: Fix potential null pointer dereference in xhci-debugfs.c
Something went wrong here, resulting in an email with no subject.
Can you fix this up and resend?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2017-08-18 17:42 Rajneesh Bhardwaj
2017-08-18 17:53 ` your mail Rajneesh Bhardwaj
0 siblings, 1 reply; 348+ messages in thread
From: Rajneesh Bhardwaj @ 2017-08-18 17:42 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Peter Zijlstra (Intel),
Platform Driver, dvhart, Andy Shevchenko, linux-kernel,
Vishwanath Somayaji, dbasehore, rjw, rajatja
Bcc:
Subject: Re: [PATCH] platform/x86: intel_pmc_core: Add Package C-states
residency info
Reply-To:
In-Reply-To: <CAHp75Vd5Wnio-RCEBENtonYWOJF2+88FDvqkUv1HzV3CdcaaPA@mail.gmail.com>
On Fri, Aug 18, 2017 at 08:17:32PM +0300, Andy Shevchenko wrote:
> +PeterZ (since I mentioned his name)
>
> On Fri, Aug 18, 2017 at 5:58 PM, Rajneesh Bhardwaj
> <rajneesh.bhardwaj@intel.com> wrote:
> > On Fri, Aug 18, 2017 at 03:57:34PM +0300, Andy Shevchenko wrote:
> >> On Fri, Aug 18, 2017 at 3:37 PM, Rajneesh Bhardwaj
> >> <rajneesh.bhardwaj@intel.com> wrote:
> >> > This patch introduces a new debugfs entry to read current Package C-state
> >> > residency values and, one new kernel API to read the Package C-10 residency
> >> > counter.
> >> >
> >> > Package C-state residency MSRs provide useful debug information about system
> >> > idle states. In idle states system must enter deeper Package C-states.
>
> >> Why this patch is needed?
> >
> > Andy, I'll try to give some background for this.
> >
> > This is needed to enhance the S0ix failure debug capabilities from within
> > the kernel. On ChromeOS we have S0ix failsafe kernel framework that is used
> > to validate S0ix and report the blockers in case of a failure.
> > https://patchwork.kernel.org/patch/9148999/
>
> (It's not part of upstream)
Sorry i sent an older link. There are fresh attempts to get this into
mainline kernel and looks like there is a traction for it.
https://patchwork.kernel.org/patch/9831229/
Package C-state (PC10) validation is discussed there.
>
> > So far only intel_pmc_slp_s0_counter_read is called by this framework to
> > check whether the previous attempt to enter S0ix was success or not.
>
> I harder see even a single user of that API in current kernel. It
> should be unexported and removed I think.
>
> > Having
> > another PC10 counter related exported function enhances the S0ix debug since
> > PC10 state is a prerequisite to enter S0ix.
> >
> >> See, we have turbostat and cpupower user space tools which do this
> >> without any additional code to be written in kernel. What prevents
> >> your user space application do the same?
> >>
> >> Moreover, we have events for cstate, I assume perf or something alike
> >> can monitor those counters as well.
> >
> > You're right, perhaps the debugfs is redundant when we have those user space
> > tools but such tools are not available readily for all platforms/distros.
> > Interfaces like /dev/cpu/*/msr that turbostat uses are not available on all
> > the platforms.
> > PMC driver is a debug driver so i thought its better to show Package C-state
> > related info for low power debug here.
> >
> >>
> >> Sorry, NAK.
> >
> > This patch has two parts i.e. exported PC10 API and the debugfs. Based on
> > the above explanation, if the patch is not good as is, please let me know if
> > i should drop the debugfs part and respin a v2 with just the exported API or
> > drop this totally.
> >
> > Thanks for the feedback and thanks for taking time to review!
>
> Reading above makes me think that entire design of this is misguided.
> Since the most of values are counters they better to be accessed in a
> way how perf does.
>
> In case you need *in-kernel* facility, do some APIs (if it's not done
> yet) for events drivers first.
> cstate event driver is already in upstream.
>
> Sorry, NAK for entire patch until it would be blessed by people like Peter Z.
>
> --
> With Best Regards,
> Andy Shevchenko
--
Best Regards,
Rajneesh
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-08-18 17:42 Rajneesh Bhardwaj
@ 2017-08-18 17:53 ` Rajneesh Bhardwaj
0 siblings, 0 replies; 348+ messages in thread
From: Rajneesh Bhardwaj @ 2017-08-18 17:53 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Peter Zijlstra (Intel),
Platform Driver, dvhart, Andy Shevchenko, linux-kernel,
Vishwanath Somayaji, dbasehore, rjw, rajatja
On Fri, Aug 18, 2017 at 11:12:14PM +0530, Rajneesh Bhardwaj wrote:
> Bcc:
> Subject: Re: [PATCH] platform/x86: intel_pmc_core: Add Package C-states
> residency info
> Reply-To:
> In-Reply-To: <CAHp75Vd5Wnio-RCEBENtonYWOJF2+88FDvqkUv1HzV3CdcaaPA@mail.gmail.com>
>
Please ignore my previous email without subject. It was sent by mistake.
> On Fri, Aug 18, 2017 at 08:17:32PM +0300, Andy Shevchenko wrote:
> > +PeterZ (since I mentioned his name)
> >
> > On Fri, Aug 18, 2017 at 5:58 PM, Rajneesh Bhardwaj
> > <rajneesh.bhardwaj@intel.com> wrote:
> > > On Fri, Aug 18, 2017 at 03:57:34PM +0300, Andy Shevchenko wrote:
> > >> On Fri, Aug 18, 2017 at 3:37 PM, Rajneesh Bhardwaj
> > >> <rajneesh.bhardwaj@intel.com> wrote:
> > >> > This patch introduces a new debugfs entry to read current Package C-state
> > >> > residency values and, one new kernel API to read the Package C-10 residency
> > >> > counter.
> > >> >
> > >> > Package C-state residency MSRs provide useful debug information about system
> > >> > idle states. In idle states system must enter deeper Package C-states.
> >
> > >> Why this patch is needed?
> > >
> > > Andy, I'll try to give some background for this.
> > >
> > > This is needed to enhance the S0ix failure debug capabilities from within
> > > the kernel. On ChromeOS we have S0ix failsafe kernel framework that is used
> > > to validate S0ix and report the blockers in case of a failure.
> > > https://patchwork.kernel.org/patch/9148999/
> >
> > (It's not part of upstream)
>
> Sorry i sent an older link. There are fresh attempts to get this into
> mainline kernel and looks like there is a traction for it.
> https://patchwork.kernel.org/patch/9831229/
>
> Package C-state (PC10) validation is discussed there.
>
> >
> > > So far only intel_pmc_slp_s0_counter_read is called by this framework to
> > > check whether the previous attempt to enter S0ix was success or not.
> >
> > I harder see even a single user of that API in current kernel. It
> > should be unexported and removed I think.
> >
> > > Having
> > > another PC10 counter related exported function enhances the S0ix debug since
> > > PC10 state is a prerequisite to enter S0ix.
> > >
> > >> See, we have turbostat and cpupower user space tools which do this
> > >> without any additional code to be written in kernel. What prevents
> > >> your user space application do the same?
> > >>
> > >> Moreover, we have events for cstate, I assume perf or something alike
> > >> can monitor those counters as well.
> > >
> > > You're right, perhaps the debugfs is redundant when we have those user space
> > > tools but such tools are not available readily for all platforms/distros.
> > > Interfaces like /dev/cpu/*/msr that turbostat uses are not available on all
> > > the platforms.
> > > PMC driver is a debug driver so i thought its better to show Package C-state
> > > related info for low power debug here.
> > >
> > >>
> > >> Sorry, NAK.
> > >
> > > This patch has two parts i.e. exported PC10 API and the debugfs. Based on
> > > the above explanation, if the patch is not good as is, please let me know if
> > > i should drop the debugfs part and respin a v2 with just the exported API or
> > > drop this totally.
> > >
> > > Thanks for the feedback and thanks for taking time to review!
> >
> > Reading above makes me think that entire design of this is misguided.
> > Since the most of values are counters they better to be accessed in a
> > way how perf does.
> >
> > In case you need *in-kernel* facility, do some APIs (if it's not done
> > yet) for events drivers first.
> > cstate event driver is already in upstream.
> >
> > Sorry, NAK for entire patch until it would be blessed by people like Peter Z.
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
>
> --
> Best Regards,
> Rajneesh
--
Best Regards,
Rajneesh
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2017-06-04 11:59 Yury Norov
2017-06-14 20:16 ` your mail Yury Norov
0 siblings, 1 reply; 348+ messages in thread
From: Yury Norov @ 2017-06-04 11:59 UTC (permalink / raw)
To: Catalin Marinas, linux-arm-kernel, linux-kernel, linux-doc,
Arnd Bergmann
Cc: Yury Norov, Andrew Pinski, Andrew Pinski, Adam Borowski,
Chris Metcalf, Steve Ellcey, Maxim Kuvyrkov,
Ramana Radhakrishnan, Florian Weimer, Bamvor Zhangjian,
Andreas Schwab, Chris Metcalf, Heiko Carstens, schwidefsky,
broonie, Joseph Myers, christoph.muellner, szabolcs.nagy,
klimov.linux, Nathan_Lynch, agraf, Prasun.Kapoor, geert,
philipp.tomsich, manuel.montezelo, linyongting, davem,
zhouchengming1
Subject: [PATCH v7 resend 2 00/20] ILP32 for ARM64
Hi Catalin,
Here is a rebase of latest kernel patchset against next-20170602. There's almost
no changes, but there are some conflicts that are not trivial, and I'd like to
refresh the submission therefore.
How are your experiments with testing and benchmarking of ILP32 are going? In
my current tests I see 0 failures on LTP. Benchmarking on SPEC CPU2006 and
LMBench shows no difference for LP64 and expected performance boost for ILP32
(compared to LP64 results).
Steve Ellcey is handling upstream submission of Glibc patches. The patches are
ready and have been reviewed and reworked per community’s comments. There are
no outstanding userspace ABI issues from Glibc. Glibc submission is now waiting
on ILP32 kernel submission.
Catalin, regarding rootfs, is OpenSuSe’s build sufficient for your experiments?
I’ve also seen Wookey merging patches for ILP32 triplet to binutils and pushing
them to Debian.
One last thing I wanted to check with you about is ILP32 PCS - does, in your
view, ARM Ltd. needs to publish any additional docs for ABI to become official?
Below is the regular description.
Thanks.
Yury
--------
This series enables aarch64 with ilp32 mode.
As supporting work, it introduces ARCH_32BIT_OFF_T configuration
option that is enabled for existing 32-bit architectures but disabled
for new arches (so 64-bit off_t is is used by new userspace). Also it
deprecates getrlimit and setrlimit syscalls prior to prlimit64.
This version is based on linux-next from 2017-03-01. It works with
glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
CPUSpec.
Patches 1, 2, 3 and 8 are general, and may be applied separately.
This is the rebase of v7 - still no major changes has been made.
Kernel and GLIBC trees:
https://github.com/norov/linux/tree/ilp32-20170602
https://github.com/norov/glibc/tree/dev9
(GLIBC patches are managed by Steve Ellcey, so my tree is only for
reference.)
Changes:
v3: https://lkml.org/lkml/2014/9/3/704
v4: https://lkml.org/lkml/2015/4/13/691
v5: https://lkml.org/lkml/2015/9/29/911
v6: https://lkml.org/lkml/2016/5/23/661
v7: RFC nowrap: https://lkml.org/lkml/2016/6/17/990
v7: RFC2 nowrap: https://lkml.org/lkml/2016/8/17/245
v7: RFC3 nowrap: https://lkml.org/lkml/2016/10/21/883
v7: https://lkml.org/lkml/2017/1/9/213
v7: Resend: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/490801.html
v7: Resend 2:
- vdso-ilp32 Makefile synced with lp64 Makefile (patch 19);
- rebased on next-20170602.
Andrew Pinski (6):
arm64: rename COMPAT to AARCH32_EL0 in Kconfig
arm64: ensure the kernel is compiled for LP64
arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
it
arm64: ilp32: introduce ilp32-specific handlers for sigframe and
ucontext
arm64:ilp32: add ARM64_ILP32 to Kconfig
Philipp Tomsich (1):
arm64:ilp32: add vdso-ilp32 and use for signal return
Yury Norov (13):
compat ABI: use non-compat openat and open_by_handle_at variants
32-bit ABI: introduce ARCH_32BIT_OFF_T config option
asm-generic: Drop getrlimit and setrlimit syscalls from default list
arm64: ilp32: add documentation on the ILP32 ABI for ARM64
thread: move thread bits accessors to separated file
arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
arm64: introduce binfmt_elf32.c
arm64: ilp32: introduce binfmt_ilp32.c
arm64: ilp32: share aarch32 syscall handlers
arm64: signal: share lp64 signal routines to ilp32
arm64: signal32: move ilp32 and aarch32 common code to separated file
arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
Documentation/arm64/ilp32.txt | 45 +++++++
arch/Kconfig | 4 +
arch/arc/Kconfig | 1 +
arch/arc/include/uapi/asm/unistd.h | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 19 ++-
arch/arm64/Makefile | 8 ++
arch/arm64/include/asm/compat.h | 19 +--
arch/arm64/include/asm/elf.h | 37 ++----
arch/arm64/include/asm/fpsimd.h | 2 +-
arch/arm64/include/asm/ftrace.h | 2 +-
arch/arm64/include/asm/hwcap.h | 6 +-
arch/arm64/include/asm/is_compat.h | 90 ++++++++++++++
arch/arm64/include/asm/memory.h | 5 +-
arch/arm64/include/asm/processor.h | 11 +-
arch/arm64/include/asm/ptrace.h | 2 +-
arch/arm64/include/asm/seccomp.h | 2 +-
arch/arm64/include/asm/signal32.h | 9 +-
arch/arm64/include/asm/signal32_common.h | 27 ++++
arch/arm64/include/asm/signal_common.h | 33 +++++
arch/arm64/include/asm/signal_ilp32.h | 38 ++++++
arch/arm64/include/asm/syscall.h | 2 +-
arch/arm64/include/asm/thread_info.h | 4 +-
arch/arm64/include/asm/unistd.h | 6 +-
arch/arm64/include/asm/vdso.h | 6 +
arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
arch/arm64/include/uapi/asm/unistd.h | 13 ++
arch/arm64/kernel/Makefile | 8 +-
arch/arm64/kernel/asm-offsets.c | 9 +-
arch/arm64/kernel/binfmt_elf32.c | 38 ++++++
arch/arm64/kernel/binfmt_ilp32.c | 85 +++++++++++++
arch/arm64/kernel/cpufeature.c | 8 +-
arch/arm64/kernel/cpuinfo.c | 20 +--
arch/arm64/kernel/entry.S | 34 +++++-
arch/arm64/kernel/entry32.S | 80 ------------
arch/arm64/kernel/entry32_common.S | 107 ++++++++++++++++
arch/arm64/kernel/entry_ilp32.S | 22 ++++
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 8 +-
arch/arm64/kernel/perf_regs.c | 2 +-
arch/arm64/kernel/process.c | 7 +-
arch/arm64/kernel/ptrace.c | 80 ++++++++++--
arch/arm64/kernel/signal.c | 102 ++++++++++------
arch/arm64/kernel/signal32.c | 107 ----------------
arch/arm64/kernel/signal32_common.c | 135 ++++++++++++++++++++
arch/arm64/kernel/signal_ilp32.c | 170 ++++++++++++++++++++++++++
arch/arm64/kernel/sys_ilp32.c | 100 +++++++++++++++
arch/arm64/kernel/traps.c | 5 +-
arch/arm64/kernel/vdso-ilp32/.gitignore | 2 +
arch/arm64/kernel/vdso-ilp32/Makefile | 80 ++++++++++++
arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S | 33 +++++
arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S | 95 ++++++++++++++
arch/arm64/kernel/vdso.c | 69 +++++++++--
arch/arm64/kernel/vdso/gettimeofday.S | 20 ++-
arch/arm64/kernel/vdso/vdso.S | 6 +-
arch/blackfin/Kconfig | 1 +
arch/c6x/include/uapi/asm/unistd.h | 1 +
arch/cris/Kconfig | 1 +
arch/frv/Kconfig | 1 +
arch/h8300/Kconfig | 1 +
arch/h8300/include/uapi/asm/unistd.h | 1 +
arch/hexagon/Kconfig | 1 +
arch/hexagon/include/uapi/asm/unistd.h | 1 +
arch/m32r/Kconfig | 1 +
arch/m68k/Kconfig | 1 +
arch/metag/Kconfig | 1 +
arch/metag/include/uapi/asm/unistd.h | 1 +
arch/microblaze/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/mn10300/Kconfig | 1 +
arch/nios2/Kconfig | 1 +
arch/nios2/include/uapi/asm/unistd.h | 1 +
arch/openrisc/Kconfig | 1 +
arch/openrisc/include/uapi/asm/unistd.h | 1 +
arch/parisc/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/score/Kconfig | 1 +
arch/score/include/uapi/asm/unistd.h | 1 +
arch/sh/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/tile/Kconfig | 1 +
arch/tile/include/uapi/asm/unistd.h | 1 +
arch/tile/kernel/compat.c | 3 +
arch/unicore32/Kconfig | 1 +
arch/unicore32/include/uapi/asm/unistd.h | 1 +
arch/x86/Kconfig | 1 +
arch/x86/um/Kconfig | 1 +
arch/xtensa/Kconfig | 1 +
drivers/clocksource/arm_arch_timer.c | 2 +-
include/linux/fcntl.h | 2 +-
include/linux/thread_bits.h | 63 ++++++++++
include/linux/thread_info.h | 66 ++--------
include/uapi/asm-generic/unistd.h | 10 +-
93 files changed, 1601 insertions(+), 413 deletions(-)
create mode 100644 Documentation/arm64/ilp32.txt
create mode 100644 arch/arm64/include/asm/is_compat.h
create mode 100644 arch/arm64/include/asm/signal32_common.h
create mode 100644 arch/arm64/include/asm/signal_common.h
create mode 100644 arch/arm64/include/asm/signal_ilp32.h
create mode 100644 arch/arm64/kernel/binfmt_elf32.c
create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
create mode 100644 arch/arm64/kernel/entry32_common.S
create mode 100644 arch/arm64/kernel/entry_ilp32.S
create mode 100644 arch/arm64/kernel/signal32_common.c
create mode 100644 arch/arm64/kernel/signal_ilp32.c
create mode 100644 arch/arm64/kernel/sys_ilp32.c
create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore
create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile
create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S
create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
create mode 100644 include/linux/thread_bits.h
--
2.11.0
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-06-04 11:59 Yury Norov
@ 2017-06-14 20:16 ` Yury Norov
0 siblings, 0 replies; 348+ messages in thread
From: Yury Norov @ 2017-06-14 20:16 UTC (permalink / raw)
To: Catalin Marinas, linux-arm-kernel, linux-kernel, linux-doc,
Arnd Bergmann
Cc: Andrew Pinski, Andrew Pinski, Adam Borowski, Chris Metcalf,
Steve Ellcey, Maxim Kuvyrkov, Ramana Radhakrishnan,
Florian Weimer, Bamvor Zhangjian, Andreas Schwab, Chris Metcalf,
Heiko Carstens, schwidefsky, broonie, Joseph Myers,
christoph.muellner, szabolcs.nagy, klimov.linux, Nathan_Lynch,
agraf, Prasun.Kapoor, geert, philipp.tomsich, manuel.montezelo,
linyongting, davem, zhouchengming1
Hi Catalin, all.
Thank you for your time on reviewing the series. I really appreciate it.
This is the updated version where I tried to address all comments:
https://github.com/norov/linux/commits/ilp32-20170613.4
(3 last patches here is the Andrew Pinski's rework of vdso rebased on
ilp32 series)
If nothing will come here on review, I'll send v8 at the beginning of
the next week. Is this plan OK?
And this is the backport on the v4.11 kernel:
https://github.com/norov/linux/commits/ilp32-4.11.4
Yury
On Sun, Jun 04, 2017 at 02:59:49PM +0300, Yury Norov wrote:
> Subject: [PATCH v7 resend 2 00/20] ILP32 for ARM64
>
> Hi Catalin,
>
> Here is a rebase of latest kernel patchset against next-20170602. There's almost
> no changes, but there are some conflicts that are not trivial, and I'd like to
> refresh the submission therefore.
>
> How are your experiments with testing and benchmarking of ILP32 are going? In
> my current tests I see 0 failures on LTP. Benchmarking on SPEC CPU2006 and
> LMBench shows no difference for LP64 and expected performance boost for ILP32
> (compared to LP64 results).
>
> Steve Ellcey is handling upstream submission of Glibc patches. The patches are
> ready and have been reviewed and reworked per community’s comments. There are
> no outstanding userspace ABI issues from Glibc. Glibc submission is now waiting
> on ILP32 kernel submission.
>
> Catalin, regarding rootfs, is OpenSuSe’s build sufficient for your experiments?
> I’ve also seen Wookey merging patches for ILP32 triplet to binutils and pushing
> them to Debian.
>
> One last thing I wanted to check with you about is ILP32 PCS - does, in your
> view, ARM Ltd. needs to publish any additional docs for ABI to become official?
>
> Below is the regular description.
>
> Thanks.
> Yury
>
> --------
>
> This series enables aarch64 with ilp32 mode.
>
> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> option that is enabled for existing 32-bit architectures but disabled
> for new arches (so 64-bit off_t is is used by new userspace). Also it
> deprecates getrlimit and setrlimit syscalls prior to prlimit64.
>
> This version is based on linux-next from 2017-03-01. It works with
> glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
> CPUSpec.
>
> Patches 1, 2, 3 and 8 are general, and may be applied separately.
>
> This is the rebase of v7 - still no major changes has been made.
>
> Kernel and GLIBC trees:
> https://github.com/norov/linux/tree/ilp32-20170602
> https://github.com/norov/glibc/tree/dev9
>
> (GLIBC patches are managed by Steve Ellcey, so my tree is only for
> reference.)
>
> Changes:
> v3: https://lkml.org/lkml/2014/9/3/704
> v4: https://lkml.org/lkml/2015/4/13/691
> v5: https://lkml.org/lkml/2015/9/29/911
> v6: https://lkml.org/lkml/2016/5/23/661
> v7: RFC nowrap: https://lkml.org/lkml/2016/6/17/990
> v7: RFC2 nowrap: https://lkml.org/lkml/2016/8/17/245
> v7: RFC3 nowrap: https://lkml.org/lkml/2016/10/21/883
> v7: https://lkml.org/lkml/2017/1/9/213
> v7: Resend: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/490801.html
> v7: Resend 2:
> - vdso-ilp32 Makefile synced with lp64 Makefile (patch 19);
> - rebased on next-20170602.
>
> Andrew Pinski (6):
> arm64: rename COMPAT to AARCH32_EL0 in Kconfig
> arm64: ensure the kernel is compiled for LP64
> arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
> arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
> it
> arm64: ilp32: introduce ilp32-specific handlers for sigframe and
> ucontext
> arm64:ilp32: add ARM64_ILP32 to Kconfig
>
> Philipp Tomsich (1):
> arm64:ilp32: add vdso-ilp32 and use for signal return
>
> Yury Norov (13):
> compat ABI: use non-compat openat and open_by_handle_at variants
> 32-bit ABI: introduce ARCH_32BIT_OFF_T config option
> asm-generic: Drop getrlimit and setrlimit syscalls from default list
> arm64: ilp32: add documentation on the ILP32 ABI for ARM64
> thread: move thread bits accessors to separated file
> arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
> arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
> arm64: introduce binfmt_elf32.c
> arm64: ilp32: introduce binfmt_ilp32.c
> arm64: ilp32: share aarch32 syscall handlers
> arm64: signal: share lp64 signal routines to ilp32
> arm64: signal32: move ilp32 and aarch32 common code to separated file
> arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
>
> Documentation/arm64/ilp32.txt | 45 +++++++
> arch/Kconfig | 4 +
> arch/arc/Kconfig | 1 +
> arch/arc/include/uapi/asm/unistd.h | 1 +
> arch/arm/Kconfig | 1 +
> arch/arm64/Kconfig | 19 ++-
> arch/arm64/Makefile | 8 ++
> arch/arm64/include/asm/compat.h | 19 +--
> arch/arm64/include/asm/elf.h | 37 ++----
> arch/arm64/include/asm/fpsimd.h | 2 +-
> arch/arm64/include/asm/ftrace.h | 2 +-
> arch/arm64/include/asm/hwcap.h | 6 +-
> arch/arm64/include/asm/is_compat.h | 90 ++++++++++++++
> arch/arm64/include/asm/memory.h | 5 +-
> arch/arm64/include/asm/processor.h | 11 +-
> arch/arm64/include/asm/ptrace.h | 2 +-
> arch/arm64/include/asm/seccomp.h | 2 +-
> arch/arm64/include/asm/signal32.h | 9 +-
> arch/arm64/include/asm/signal32_common.h | 27 ++++
> arch/arm64/include/asm/signal_common.h | 33 +++++
> arch/arm64/include/asm/signal_ilp32.h | 38 ++++++
> arch/arm64/include/asm/syscall.h | 2 +-
> arch/arm64/include/asm/thread_info.h | 4 +-
> arch/arm64/include/asm/unistd.h | 6 +-
> arch/arm64/include/asm/vdso.h | 6 +
> arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
> arch/arm64/include/uapi/asm/unistd.h | 13 ++
> arch/arm64/kernel/Makefile | 8 +-
> arch/arm64/kernel/asm-offsets.c | 9 +-
> arch/arm64/kernel/binfmt_elf32.c | 38 ++++++
> arch/arm64/kernel/binfmt_ilp32.c | 85 +++++++++++++
> arch/arm64/kernel/cpufeature.c | 8 +-
> arch/arm64/kernel/cpuinfo.c | 20 +--
> arch/arm64/kernel/entry.S | 34 +++++-
> arch/arm64/kernel/entry32.S | 80 ------------
> arch/arm64/kernel/entry32_common.S | 107 ++++++++++++++++
> arch/arm64/kernel/entry_ilp32.S | 22 ++++
> arch/arm64/kernel/head.S | 2 +-
> arch/arm64/kernel/hw_breakpoint.c | 8 +-
> arch/arm64/kernel/perf_regs.c | 2 +-
> arch/arm64/kernel/process.c | 7 +-
> arch/arm64/kernel/ptrace.c | 80 ++++++++++--
> arch/arm64/kernel/signal.c | 102 ++++++++++------
> arch/arm64/kernel/signal32.c | 107 ----------------
> arch/arm64/kernel/signal32_common.c | 135 ++++++++++++++++++++
> arch/arm64/kernel/signal_ilp32.c | 170 ++++++++++++++++++++++++++
> arch/arm64/kernel/sys_ilp32.c | 100 +++++++++++++++
> arch/arm64/kernel/traps.c | 5 +-
> arch/arm64/kernel/vdso-ilp32/.gitignore | 2 +
> arch/arm64/kernel/vdso-ilp32/Makefile | 80 ++++++++++++
> arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S | 33 +++++
> arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S | 95 ++++++++++++++
> arch/arm64/kernel/vdso.c | 69 +++++++++--
> arch/arm64/kernel/vdso/gettimeofday.S | 20 ++-
> arch/arm64/kernel/vdso/vdso.S | 6 +-
> arch/blackfin/Kconfig | 1 +
> arch/c6x/include/uapi/asm/unistd.h | 1 +
> arch/cris/Kconfig | 1 +
> arch/frv/Kconfig | 1 +
> arch/h8300/Kconfig | 1 +
> arch/h8300/include/uapi/asm/unistd.h | 1 +
> arch/hexagon/Kconfig | 1 +
> arch/hexagon/include/uapi/asm/unistd.h | 1 +
> arch/m32r/Kconfig | 1 +
> arch/m68k/Kconfig | 1 +
> arch/metag/Kconfig | 1 +
> arch/metag/include/uapi/asm/unistd.h | 1 +
> arch/microblaze/Kconfig | 1 +
> arch/mips/Kconfig | 1 +
> arch/mn10300/Kconfig | 1 +
> arch/nios2/Kconfig | 1 +
> arch/nios2/include/uapi/asm/unistd.h | 1 +
> arch/openrisc/Kconfig | 1 +
> arch/openrisc/include/uapi/asm/unistd.h | 1 +
> arch/parisc/Kconfig | 1 +
> arch/powerpc/Kconfig | 1 +
> arch/score/Kconfig | 1 +
> arch/score/include/uapi/asm/unistd.h | 1 +
> arch/sh/Kconfig | 1 +
> arch/sparc/Kconfig | 1 +
> arch/tile/Kconfig | 1 +
> arch/tile/include/uapi/asm/unistd.h | 1 +
> arch/tile/kernel/compat.c | 3 +
> arch/unicore32/Kconfig | 1 +
> arch/unicore32/include/uapi/asm/unistd.h | 1 +
> arch/x86/Kconfig | 1 +
> arch/x86/um/Kconfig | 1 +
> arch/xtensa/Kconfig | 1 +
> drivers/clocksource/arm_arch_timer.c | 2 +-
> include/linux/fcntl.h | 2 +-
> include/linux/thread_bits.h | 63 ++++++++++
> include/linux/thread_info.h | 66 ++--------
> include/uapi/asm-generic/unistd.h | 10 +-
> 93 files changed, 1601 insertions(+), 413 deletions(-)
> create mode 100644 Documentation/arm64/ilp32.txt
> create mode 100644 arch/arm64/include/asm/is_compat.h
> create mode 100644 arch/arm64/include/asm/signal32_common.h
> create mode 100644 arch/arm64/include/asm/signal_common.h
> create mode 100644 arch/arm64/include/asm/signal_ilp32.h
> create mode 100644 arch/arm64/kernel/binfmt_elf32.c
> create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
> create mode 100644 arch/arm64/kernel/entry32_common.S
> create mode 100644 arch/arm64/kernel/entry_ilp32.S
> create mode 100644 arch/arm64/kernel/signal32_common.c
> create mode 100644 arch/arm64/kernel/signal_ilp32.c
> create mode 100644 arch/arm64/kernel/sys_ilp32.c
> create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore
> create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile
> create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S
> create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
> create mode 100644 include/linux/thread_bits.h
>
> --
> 2.11.0
^ permalink raw reply [flat|nested] 348+ messages in thread
* [PATCH -v2 0/9] mm: make movable onlining suck less
@ 2017-04-10 11:03 Michal Hocko
2017-04-15 12:17 ` Michal Hocko
0 siblings, 1 reply; 348+ messages in thread
From: Michal Hocko @ 2017-04-10 11:03 UTC (permalink / raw)
To: linux-mm
Cc: Andrew Morton, Mel Gorman, Vlastimil Babka, Andrea Arcangeli,
Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu, qiuxishi,
Kani Toshimitsu, slaoub, Joonsoo Kim, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML,
Dan Williams, Heiko Carstens, Lai Jiangshan, Martin Schwidefsky,
Michal Hocko, Tobias Regnery
Hi,
The last version of this series has been posted here [1]. It has seen
some more serious testing (thanks to Reza Arbab) and fixes for the found
issues. I have also decided to drop patch 1 [2] because it turned out to
be more complicated than I initially thought [3]. Few more patches were
added to deal with expectation on zone/node initialization.
I have rebased on top of the current mmotm-2017-04-07-15-53. It
conflicts with HMM because it touches memory hotplug as
well. We have discussed [4] with Jérôme and he agreed to
rebase on top of this rework [5] so I have reverted his series
before applyig mine. I will help him to resolve the resulting
conflicts. You can find the whole series including the HMM revers in
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git branch
attempts/rewrite-mem_hotplug
Motivation:
Movable onlining is a real hack with many downsides - mainly
reintroduction of lowmem/highmem issues we used to have on 32b systems -
but it is the only way to make the memory hotremove more reliable which
is something that people are asking for.
The current semantic of memory movable onlinening is really cumbersome,
however. The main reason for this is that the udev driven approach is
basically unusable because udev races with the memory probing while only
the last memory block or the one adjacent to the existing zone_movable
are allowed to be onlined movable. In short the criterion for the
successful online_movable changes under udev's feet. A reliable udev
approach would require a 2 phase approach where the first successful
movable online would have to check all the previous blocks and online
them in descending order. This is hard to be considered sane.
This patchset aims at making the onlining semantic more usable. First of
all it allows to online memory movable as long as it doesn't clash with
the existing ZONE_NORMAL. That means that ZONE_NORMAL and ZONE_MOVABLE
cannot overlap. Currently I preserve the original ordering semantic so
the zone always precedes the movable zone but I have plans to remove this
restriction in future because it is not really necessary.
First 3 patches are cleanups which should be ready to be merged right
away (unless I have missed something subtle of course).
Patch 4 deals with ZONE_DEVICE dependencies down the __add_pages path.
Patch 5 deals with implicit assumptions of register_one_node on pgdat
initialization.
Patch 6 is the core of the change. In order to make it easier to review
I have tried it to be as minimalistic as possible and the large code
removal is moved to patch 9.
Patch 7 is a trivial follow up cleanup. Patch 8 fixes sparse warnings
and finally patch 9 removes the unused code.
I have tested the patches in kvm:
# qemu-system-x86_64 -enable-kvm -monitor pty -m 2G,slots=4,maxmem=4G -numa node,mem=1G -numa node,mem=1G ...
and then probed the additional memory by
(qemu) object_add memory-backend-ram,id=mem1,size=1G
(qemu) device_add pc-dimm,id=dimm1,memdev=mem1
Then I have used this simple script to probe the memory block by hand
# cat probe_memblock.sh
#!/bin/sh
BLOCK_NR=$1
# echo $((0x100000000+$BLOCK_NR*(128<<20))) > /sys/devices/system/memory/probe
# for i in $(seq 10); do sh probe_memblock.sh $i; done
# grep . /sys/devices/system/memory/memory3?/valid_zones 2>/dev/null
/sys/devices/system/memory/memory33/valid_zones:Normal Movable
/sys/devices/system/memory/memory34/valid_zones:Normal Movable
/sys/devices/system/memory/memory35/valid_zones:Normal Movable
/sys/devices/system/memory/memory36/valid_zones:Normal Movable
/sys/devices/system/memory/memory37/valid_zones:Normal Movable
/sys/devices/system/memory/memory38/valid_zones:Normal Movable
/sys/devices/system/memory/memory39/valid_zones:Normal Movable
The main difference to the original implementation is that all new
memblocks can be both online_kernel and online_movable initially
because there is no clash obviously. For the comparison the original
implementation would have
/sys/devices/system/memory/memory33/valid_zones:Normal
/sys/devices/system/memory/memory34/valid_zones:Normal
/sys/devices/system/memory/memory35/valid_zones:Normal
/sys/devices/system/memory/memory36/valid_zones:Normal
/sys/devices/system/memory/memory37/valid_zones:Normal
/sys/devices/system/memory/memory38/valid_zones:Normal
/sys/devices/system/memory/memory39/valid_zones:Normal Movable
Now
# echo online_movable > /sys/devices/system/memory/memory34/state
# grep . /sys/devices/system/memory/memory3?/valid_zones 2>/dev/null
/sys/devices/system/memory/memory33/valid_zones:Normal Movable
/sys/devices/system/memory/memory34/valid_zones:Movable
/sys/devices/system/memory/memory35/valid_zones:Movable
/sys/devices/system/memory/memory36/valid_zones:Movable
/sys/devices/system/memory/memory37/valid_zones:Movable
/sys/devices/system/memory/memory38/valid_zones:Movable
/sys/devices/system/memory/memory39/valid_zones:Movable
Block 33 can still be online both kernel and movable while all
the remaining can be only movable.
/proc/zonelist says
Node 0, zone Normal
pages free 0
min 0
low 0
high 0
spanned 0
present 0
--
Node 0, zone Movable
pages free 32753
min 85
low 117
high 149
spanned 32768
present 32768
A new memblock at a lower address will result in a new memblock (32)
which will still allow both Normal and Movable.
# sh probe_memblock.sh 0
# grep . /sys/devices/system/memory/memory3[2-5]/valid_zones 2>/dev/null
/sys/devices/system/memory/memory32/valid_zones:Normal Movable
/sys/devices/system/memory/memory33/valid_zones:Normal Movable
/sys/devices/system/memory/memory34/valid_zones:Movable
/sys/devices/system/memory/memory35/valid_zones:Movable
and online_kernel will convert it to the zone normal properly
while 33 can be still onlined both ways.
# echo online_kernel > /sys/devices/system/memory/memory32/state
# grep . /sys/devices/system/memory/memory3[2-5]/valid_zones 2>/dev/null
/sys/devices/system/memory/memory32/valid_zones:Normal
/sys/devices/system/memory/memory33/valid_zones:Normal Movable
/sys/devices/system/memory/memory34/valid_zones:Movable
/sys/devices/system/memory/memory35/valid_zones:Movable
/proc/zoneinfo will now tell
Node 0, zone Normal
pages free 65441
min 165
low 230
high 295
spanned 65536
present 65536
--
Node 0, zone Movable
pages free 32740
min 82
low 114
high 146
spanned 32768
present 32768
so both zones have one memblock spanned and present.
Onlining 39 should associate this block to the movable zone
# echo online > /sys/devices/system/memory/memory39/state
/proc/zoneinfo will now tell
Node 0, zone Normal
pages free 32765
min 80
low 112
high 144
spanned 32768
present 32768
--
Node 0, zone Movable
pages free 65501
min 160
low 225
high 290
spanned 196608
present 65536
so we will have a movable zone which spans 6 memblocks, 2 present and 4
representing a hole.
Offlining both movable blocks will lead to the zone with no present
pages which is the expected behavior I believe.
# echo offline > /sys/devices/system/memory/memory39/state
# echo offline > /sys/devices/system/memory/memory34/state
# grep -A6 "Movable\|Normal" /proc/zoneinfo
Node 0, zone Normal
pages free 32735
min 90
low 122
high 154
spanned 32768
present 32768
--
Node 0, zone Movable
pages free 0
min 0
low 0
high 0
spanned 196608
present 0
Any thoughts, complains, suggestions?
As a bonus we will get a nice cleanup in the memory hotplug codebase
arch/ia64/mm/init.c | 11 +-
arch/powerpc/mm/mem.c | 12 +-
arch/s390/mm/init.c | 32 +--
arch/sh/mm/init.c | 10 +-
arch/x86/mm/init_32.c | 7 +-
arch/x86/mm/init_64.c | 11 +-
drivers/base/memory.c | 74 ++++---
drivers/base/node.c | 58 ++----
include/linux/memory_hotplug.h | 19 +-
include/linux/mmzone.h | 16 +-
include/linux/node.h | 35 +++-
kernel/memremap.c | 6 +-
mm/memory_hotplug.c | 451 ++++++++++++++---------------------------
mm/page_alloc.c | 8 +-
mm/sparse.c | 3 +-
15 files changed, 284 insertions(+), 469 deletions(-)
Shortlog says:
Michal Hocko (9):
mm: remove return value from init_currently_empty_zone
mm, memory_hotplug: use node instead of zone in can_online_high_movable
mm: drop page_initialized check from get_nid_for_pfn
mm, memory_hotplug: get rid of is_zone_device_section
mm, memory_hotplug: split up register_one_node
mm, memory_hotplug: do not associate hotadded memory to zones until online
mm, memory_hotplug: replace for_device by want_memblock in arch_add_memory
mm, memory_hotplug: fix the section mismatch warning
mm, memory_hotplug: remove unused cruft after memory hotplug rework
[1] http://lkml.kernel.org/r/20170330115454.32154-1-mhocko@kernel.org
[2] http://lkml.kernel.org/r/20170331073954.GF27098@dhcp22.suse.cz
[3] http://lkml.kernel.org/r/20170405081400.GE6035@dhcp22.suse.cz
[4] http://lkml.kernel.org/r/20170407121349.GB16392@dhcp22.suse.cz
[5] http://lkml.kernel.org/r/20170407182752.GA17852@redhat.com
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
2017-04-10 11:03 [PATCH -v2 0/9] mm: make movable onlining suck less Michal Hocko
@ 2017-04-15 12:17 ` Michal Hocko
2017-04-17 5:47 ` your mail Joonsoo Kim
0 siblings, 1 reply; 348+ messages in thread
From: Michal Hocko @ 2017-04-15 12:17 UTC (permalink / raw)
To: linux-mm
Cc: Andrew Morton, Mel Gorman, Vlastimil Babka, Andrea Arcangeli,
Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu, qiuxishi,
Kani Toshimitsu, slaoub, Joonsoo Kim, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
Hi,
here I 3 more preparatory patches which I meant to send on Thursday but
forgot... After more thinking about pfn walkers I have realized that
the current code doesn't check offline holes in zones. From a quick
review that doesn't seem to be a problem currently. Pfn walkers can race
with memory offlining and with the original hotplug impementation those
offline pages can change the zone but I wasn't able to find any serious
problem other than small confusion. The new hotplug code, will not have
any valid zone, though so those code paths should check PageReserved
to rule offline holes. I hope I have addressed all of them in these 3
patches. I would appreciate if Vlastimil and Jonsoo double check after
me.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-15 12:17 ` Michal Hocko
@ 2017-04-17 5:47 ` Joonsoo Kim
2017-04-17 8:15 ` Michal Hocko
0 siblings, 1 reply; 348+ messages in thread
From: Joonsoo Kim @ 2017-04-17 5:47 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Sat, Apr 15, 2017 at 02:17:31PM +0200, Michal Hocko wrote:
> Hi,
> here I 3 more preparatory patches which I meant to send on Thursday but
> forgot... After more thinking about pfn walkers I have realized that
> the current code doesn't check offline holes in zones. From a quick
> review that doesn't seem to be a problem currently. Pfn walkers can race
> with memory offlining and with the original hotplug impementation those
> offline pages can change the zone but I wasn't able to find any serious
> problem other than small confusion. The new hotplug code, will not have
> any valid zone, though so those code paths should check PageReserved
> to rule offline holes. I hope I have addressed all of them in these 3
> patches. I would appreciate if Vlastimil and Jonsoo double check after
> me.
Hello, Michal.
s/Jonsoo/Joonsoo. :)
I'm not sure that it's a good idea to add PageResereved() check in pfn
walkers. First, this makes struct page validity check as two steps,
pfn_valid() and then PageResereved(). If we should not use struct page
in this case, it's better to pfn_valid() returns false rather than
adding a separate check. Anyway, we need to fix more places (all pfn
walker?) if we want to check validity by two steps.
The other problem I found is that your change will makes some
contiguous zones to be considered as non-contiguous. Memory allocated
by memblock API is also marked as PageResereved. If we consider this as
a hole, we will set such a zone as non-contiguous.
And, I guess that it's not enough to check PageResereved() in
pageblock_pfn_to_page() in order to skip these pages in compaction. If
holes are in the middle of the pageblock, pageblock_pfn_to_page()
cannot catch it and compaction will use struct page for this hole.
Therefore, I think that making pfn_valid() return false for not
onlined memory is a better solution for this problem. I don't know the
implementation detail for hotplug and I don't see your recent change
but we may defer memmap initialization until the zone is determined.
It will make pfn_valid() return false for un-initialized range.
Thanks.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-17 5:47 ` your mail Joonsoo Kim
@ 2017-04-17 8:15 ` Michal Hocko
2017-04-20 1:27 ` Joonsoo Kim
0 siblings, 1 reply; 348+ messages in thread
From: Michal Hocko @ 2017-04-17 8:15 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Mon 17-04-17 14:47:20, Joonsoo Kim wrote:
> On Sat, Apr 15, 2017 at 02:17:31PM +0200, Michal Hocko wrote:
> > Hi,
> > here I 3 more preparatory patches which I meant to send on Thursday but
> > forgot... After more thinking about pfn walkers I have realized that
> > the current code doesn't check offline holes in zones. From a quick
> > review that doesn't seem to be a problem currently. Pfn walkers can race
> > with memory offlining and with the original hotplug impementation those
> > offline pages can change the zone but I wasn't able to find any serious
> > problem other than small confusion. The new hotplug code, will not have
> > any valid zone, though so those code paths should check PageReserved
> > to rule offline holes. I hope I have addressed all of them in these 3
> > patches. I would appreciate if Vlastimil and Jonsoo double check after
> > me.
>
> Hello, Michal.
>
> s/Jonsoo/Joonsoo. :)
ups, sorry about that.
> I'm not sure that it's a good idea to add PageResereved() check in pfn
> walkers. First, this makes struct page validity check as two steps,
> pfn_valid() and then PageResereved().
Yes, those are two separate checkes because semantically they are
different. Not all pfn walkers do care about the online status.
> If we should not use struct page
> in this case, it's better to pfn_valid() returns false rather than
> adding a separate check. Anyway, we need to fix more places (all pfn
> walker?) if we want to check validity by two steps.
Which pfn walkers you have in mind?
> The other problem I found is that your change will makes some
> contiguous zones to be considered as non-contiguous. Memory allocated
> by memblock API is also marked as PageResereved. If we consider this as
> a hole, we will set such a zone as non-contiguous.
Why would that be a problem? We shouldn't touch those pages anyway?
> And, I guess that it's not enough to check PageResereved() in
> pageblock_pfn_to_page() in order to skip these pages in compaction. If
> holes are in the middle of the pageblock, pageblock_pfn_to_page()
> cannot catch it and compaction will use struct page for this hole.
Yes pageblock_pfn_to_page cannot catch it and it wouldn't with the
current implementation anyway. So the implementation won't be any worse
than with the current code. On the other hand offline holes will always
fill the whole pageblock (assuming those are not spanning multiple
memblocks).
> Therefore, I think that making pfn_valid() return false for not
> onlined memory is a better solution for this problem. I don't know the
> implementation detail for hotplug and I don't see your recent change
> but we may defer memmap initialization until the zone is determined.
> It will make pfn_valid() return false for un-initialized range.
I am not really sure. pfn_valid is used in many context and its only
purpose is to tell whether pfn_to_page will return a valid struct page
AFAIU.
I agree that having more checks is more error prone and we can add a
helper pfn_to_valid_page or something similar but I believe we can do
that on top of the current hotplug rework. This would require a non
trivial amount of changes and I believe that a lacking check for the
offline holes is not critical - we would (ab)use the lowest zone which
is similar to (ab)using ZONE_NORMAL/MOVABLE with the original code.
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-17 8:15 ` Michal Hocko
@ 2017-04-20 1:27 ` Joonsoo Kim
2017-04-20 7:28 ` Michal Hocko
0 siblings, 1 reply; 348+ messages in thread
From: Joonsoo Kim @ 2017-04-20 1:27 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> On Mon 17-04-17 14:47:20, Joonsoo Kim wrote:
> > On Sat, Apr 15, 2017 at 02:17:31PM +0200, Michal Hocko wrote:
> > > Hi,
> > > here I 3 more preparatory patches which I meant to send on Thursday but
> > > forgot... After more thinking about pfn walkers I have realized that
> > > the current code doesn't check offline holes in zones. From a quick
> > > review that doesn't seem to be a problem currently. Pfn walkers can race
> > > with memory offlining and with the original hotplug impementation those
> > > offline pages can change the zone but I wasn't able to find any serious
> > > problem other than small confusion. The new hotplug code, will not have
> > > any valid zone, though so those code paths should check PageReserved
> > > to rule offline holes. I hope I have addressed all of them in these 3
> > > patches. I would appreciate if Vlastimil and Jonsoo double check after
> > > me.
> >
> > Hello, Michal.
> >
> > s/Jonsoo/Joonsoo. :)
>
> ups, sorry about that.
>
> > I'm not sure that it's a good idea to add PageResereved() check in pfn
> > walkers. First, this makes struct page validity check as two steps,
> > pfn_valid() and then PageResereved().
>
> Yes, those are two separate checkes because semantically they are
> different. Not all pfn walkers do care about the online status.
If offlined page has no valid information, reading information
about offlined pages are just wrong. So, all pfn walkers that reads
information about the page should do care about it.
I guess that many callers for pfn_valid() is in this category.
>
> > If we should not use struct page
> > in this case, it's better to pfn_valid() returns false rather than
> > adding a separate check. Anyway, we need to fix more places (all pfn
> > walker?) if we want to check validity by two steps.
>
> Which pfn walkers you have in mind?
For example, kpagecount_read() in fs/proc/page.c. I searched it by
using pfn_valid().
> > The other problem I found is that your change will makes some
> > contiguous zones to be considered as non-contiguous. Memory allocated
> > by memblock API is also marked as PageResereved. If we consider this as
> > a hole, we will set such a zone as non-contiguous.
>
> Why would that be a problem? We shouldn't touch those pages anyway?
Skipping those pages in compaction are valid so no problem in this
case.
The problem I mentioned above is that adding PageReserved() check in
__pageblock_pfn_to_page() invalidates optimization by
set_zone_contiguous(). In compaction, we need to get a valid struct
page and it requires a lot of work. There is performance problem
report due to this so set_zone_contiguous() optimization is added. It
checks if the zone is contiguous or not in boot time. If zone is
determined as contiguous, we can easily get a valid struct page in
runtime without expensive checks.
Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
woule make that zone->contiguous usually returns false since memory
used by memblock API is marked as PageReserved() and your patch regard
it as a hole. It invalidates set_zone_contiguous() optimization and I
worry about it.
>
> > And, I guess that it's not enough to check PageResereved() in
> > pageblock_pfn_to_page() in order to skip these pages in compaction. If
> > holes are in the middle of the pageblock, pageblock_pfn_to_page()
> > cannot catch it and compaction will use struct page for this hole.
>
> Yes pageblock_pfn_to_page cannot catch it and it wouldn't with the
> current implementation anyway. So the implementation won't be any worse
> than with the current code. On the other hand offline holes will always
> fill the whole pageblock (assuming those are not spanning multiple
> memblocks).
>
> > Therefore, I think that making pfn_valid() return false for not
> > onlined memory is a better solution for this problem. I don't know the
> > implementation detail for hotplug and I don't see your recent change
> > but we may defer memmap initialization until the zone is determined.
> > It will make pfn_valid() return false for un-initialized range.
>
> I am not really sure. pfn_valid is used in many context and its only
> purpose is to tell whether pfn_to_page will return a valid struct page
> AFAIU.
>
> I agree that having more checks is more error prone and we can add a
> helper pfn_to_valid_page or something similar but I believe we can do
> that on top of the current hotplug rework. This would require a non
> trivial amount of changes and I believe that a lacking check for the
> offline holes is not critical - we would (ab)use the lowest zone which
> is similar to (ab)using ZONE_NORMAL/MOVABLE with the original code.
I'm not objecting your hotplug rework. In fact, I don't know the
relationship between this work and hotplug rework. I'm agreeing
with checking offline holes but I don't like the design and
implementation about it.
Let me clarify my desire(?) for this issue.
1. If pfn_valid() returns true, struct page has valid information, at
least, in flags (zone id, node id, flags, etc...). So, we can use them
without checking PageResereved().
2. pfn_valid() for offlined holes returns false. This can be easily
(?) implemented by manipulating SECTION_MAP_MASK in hotplug code. I
guess that there is no reason that pfn_valid() returns true for
offlined holes. If there is, please let me know.
3. We don't need to check PageReserved() in most of pfn walkers in
order to check offline holes.
Thanks.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-20 1:27 ` Joonsoo Kim
@ 2017-04-20 7:28 ` Michal Hocko
2017-04-20 8:49 ` Michal Hocko
2017-04-21 4:38 ` Joonsoo Kim
0 siblings, 2 replies; 348+ messages in thread
From: Michal Hocko @ 2017-04-20 7:28 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
[...]
> > Which pfn walkers you have in mind?
>
> For example, kpagecount_read() in fs/proc/page.c. I searched it by
> using pfn_valid().
Yeah, I've checked that one and in fact this is a good example of the
case where you do not really care about holes. It just checks the page
count which is a valid information under any circumstances.
> > > The other problem I found is that your change will makes some
> > > contiguous zones to be considered as non-contiguous. Memory allocated
> > > by memblock API is also marked as PageResereved. If we consider this as
> > > a hole, we will set such a zone as non-contiguous.
> >
> > Why would that be a problem? We shouldn't touch those pages anyway?
>
> Skipping those pages in compaction are valid so no problem in this
> case.
>
> The problem I mentioned above is that adding PageReserved() check in
> __pageblock_pfn_to_page() invalidates optimization by
> set_zone_contiguous(). In compaction, we need to get a valid struct
> page and it requires a lot of work. There is performance problem
> report due to this so set_zone_contiguous() optimization is added. It
> checks if the zone is contiguous or not in boot time. If zone is
> determined as contiguous, we can easily get a valid struct page in
> runtime without expensive checks.
OK, I see. I've had some vague understading and the clarification helps.
> Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> woule make that zone->contiguous usually returns false since memory
> used by memblock API is marked as PageReserved() and your patch regard
> it as a hole. It invalidates set_zone_contiguous() optimization and I
> worry about it.
OK, fair enough. I did't consider memblock allocations. I will rethink
this patch but there are essentially 3 options
- use a different criterion for the offline holes dection. I
have just realized we might do it by storing the online
information into the mem sections
- drop this patch
- move the PageReferenced check down the chain into
isolate_freepages_block resp. isolate_migratepages_block
I would prefer 3 over 2 over 1. I definitely want to make this more
robust so 1 is preferable long term but I do not want this to be a
roadblock to the rest of the rework. Does that sound acceptable to you?
[..]
> Let me clarify my desire(?) for this issue.
>
> 1. If pfn_valid() returns true, struct page has valid information, at
> least, in flags (zone id, node id, flags, etc...). So, we can use them
> without checking PageResereved().
This is no longer true after my rework. Pages are associated with the
zone during _onlining_ rather than when they are physically hotpluged.
Basically only the nid is set properly. Strictly speaking this is the
case also without my rework because the zone might change during online
phase so you cannot assume it is correct even now. It just happens that
it more or less works just fine.
> 2. pfn_valid() for offlined holes returns false. This can be easily
> (?) implemented by manipulating SECTION_MAP_MASK in hotplug code. I
> guess that there is no reason that pfn_valid() returns true for
> offlined holes. If there is, please let me know.
There is some code which really expects that pfn_valid returns true iff
there is a struct page and it doesn't care about the online status.
E.g. hotplug code itself so no, we cannot change pfn_valid. What we can
do though is to add pfn_to_online_page which would do the proper check.
I have already sent [1]. As noted above we can (ab)use the remaining bit
in SECTION_MAP_MASK to detect offline pages more robustly.
> 3. We don't need to check PageReserved() in most of pfn walkers in
> order to check offline holes.
We still have to distinguish those who care about offline pages from
those who do not care about it.
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-20 7:28 ` Michal Hocko
@ 2017-04-20 8:49 ` Michal Hocko
2017-04-20 11:56 ` Vlastimil Babka
2017-04-21 4:38 ` Joonsoo Kim
1 sibling, 1 reply; 348+ messages in thread
From: Michal Hocko @ 2017-04-20 8:49 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu 20-04-17 09:28:20, Michal Hocko wrote:
> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
[...]
> > Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> > woule make that zone->contiguous usually returns false since memory
> > used by memblock API is marked as PageReserved() and your patch regard
> > it as a hole. It invalidates set_zone_contiguous() optimization and I
> > worry about it.
>
> OK, fair enough. I did't consider memblock allocations. I will rethink
> this patch but there are essentially 3 options
> - use a different criterion for the offline holes dection. I
> have just realized we might do it by storing the online
> information into the mem sections
> - drop this patch
> - move the PageReferenced check down the chain into
> isolate_freepages_block resp. isolate_migratepages_block
>
> I would prefer 3 over 2 over 1. I definitely want to make this more
> robust so 1 is preferable long term but I do not want this to be a
> roadblock to the rest of the rework. Does that sound acceptable to you?
So I've played with all three options just to see how the outcome would
look like and it turned out that going with 1 will be easiest in the
end. What do you think about the following? It should be free of any
false positives. I have only compile tested it yet.
---
>From 747794c13c0e82b55b793a31cdbe1a84ee1c6920 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Thu, 13 Apr 2017 10:28:45 +0200
Subject: [PATCH] mm: consider zone which is not fully populated to have holes
__pageblock_pfn_to_page has two users currently, set_zone_contiguous
which checks whether the given zone contains holes and
pageblock_pfn_to_page which then carefully returns a first valid
page from the given pfn range for the given zone. This doesn't handle
zones which are not fully populated though. Memory pageblocks can be
offlined or might not have been onlined yet. In such a case the zone
should be considered to have holes otherwise pfn walkers can touch
and play with offline pages.
Current callers of pageblock_pfn_to_page in compaction seem to work
properly right now because they only isolate PageBuddy
(isolate_freepages_block) or PageLRU resp. __PageMovable
(isolate_migratepages_block) which will be always false for these pages.
It would be safer to skip these pages altogether, though.
In order to do this patch adds a new memory section state
(SECTION_IS_ONLINE) which is set in memory_present (during boot
time) or in online_pages_range during the memory hotplug. Similarly
offline_mem_sections clears the bit and it is called when the memory
range is offlined.
pfn_to_online_page helper is then added which check the mem section and
only returns a page if it is onlined already.
Use the new helper in __pageblock_pfn_to_page and skip the whole page
block in such a case.
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
include/linux/memory_hotplug.h | 21 ++++++++++++++++++++
include/linux/mmzone.h | 20 ++++++++++++++++++-
mm/memory_hotplug.c | 3 +++
mm/page_alloc.c | 5 ++++-
mm/sparse.c | 45 +++++++++++++++++++++++++++++++++++++++++-
5 files changed, 91 insertions(+), 3 deletions(-)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 3c8cf86201c3..fc1c873504eb 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -14,6 +14,19 @@ struct memory_block;
struct resource;
#ifdef CONFIG_MEMORY_HOTPLUG
+/*
+ * Return page for the valid pfn only if the page is online. All pfn
+ * walkers which rely on the fully initialized page->flags and others
+ * should use this rather than pfn_valid && pfn_to_page
+ */
+#define pfn_to_online_page(pfn) \
+({ \
+ struct page *___page = NULL; \
+ \
+ if (online_section_nr(pfn_to_section_nr(pfn))) \
+ ___page = pfn_to_page(pfn); \
+ ___page; \
+})
/*
* Types for free bootmem stored in page->lru.next. These have to be in
@@ -203,6 +216,14 @@ extern void set_zone_contiguous(struct zone *zone);
extern void clear_zone_contiguous(struct zone *zone);
#else /* ! CONFIG_MEMORY_HOTPLUG */
+#define pfn_to_online_page(pfn) \
+({ \
+ struct page *___page = NULL; \
+ if (pfn_valid(pfn)) \
+ ___page = pfn_to_page(pfn); \
+ ___page; \
+ })
+
/*
* Stub functions for when hotplug is off
*/
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 0fc121bbf4ff..cad16ac080f5 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1143,7 +1143,8 @@ extern unsigned long usemap_size(void);
*/
#define SECTION_MARKED_PRESENT (1UL<<0)
#define SECTION_HAS_MEM_MAP (1UL<<1)
-#define SECTION_MAP_LAST_BIT (1UL<<2)
+#define SECTION_IS_ONLINE (1UL<<2)
+#define SECTION_MAP_LAST_BIT (1UL<<3)
#define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1))
#define SECTION_NID_SHIFT 2
@@ -1174,6 +1175,23 @@ static inline int valid_section_nr(unsigned long nr)
return valid_section(__nr_to_section(nr));
}
+static inline int online_section(struct mem_section *section)
+{
+ return (section && (section->section_mem_map & SECTION_IS_ONLINE));
+}
+
+static inline int online_section_nr(unsigned long nr)
+{
+ return online_section(__nr_to_section(nr));
+}
+
+#ifdef CONFIG_MEMORY_HOTPLUG
+void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
+#ifdef CONFIG_MEMORY_HOTREMOVE
+void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
+#endif
+#endif
+
static inline struct mem_section *__pfn_to_section(unsigned long pfn)
{
return __nr_to_section(pfn_to_section_nr(pfn));
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index caa58338d121..98f565c279bf 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -929,6 +929,9 @@ static int online_pages_range(unsigned long start_pfn, unsigned long nr_pages,
unsigned long i;
unsigned long onlined_pages = *(unsigned long *)arg;
struct page *page;
+
+ online_mem_sections(start_pfn, start_pfn + nr_pages);
+
if (PageReserved(pfn_to_page(start_pfn)))
for (i = 0; i < nr_pages; i++) {
page = pfn_to_page(start_pfn + i);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5d72d29a6ece..fa752de84eef 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1353,7 +1353,9 @@ struct page *__pageblock_pfn_to_page(unsigned long start_pfn,
if (!pfn_valid(start_pfn) || !pfn_valid(end_pfn))
return NULL;
- start_page = pfn_to_page(start_pfn);
+ start_page = pfn_to_online_page(start_pfn);
+ if (!start_page)
+ return NULL;
if (page_zone(start_page) != zone)
return NULL;
@@ -7686,6 +7688,7 @@ __offline_isolated_pages(unsigned long start_pfn, unsigned long end_pfn)
break;
if (pfn == end_pfn)
return;
+ offline_mem_sections(pfn, end_pfn);
zone = page_zone(pfn_to_page(pfn));
spin_lock_irqsave(&zone->lock, flags);
pfn = start_pfn;
diff --git a/mm/sparse.c b/mm/sparse.c
index 6903c8fc3085..79017f90d8fc 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -185,7 +185,8 @@ void __init memory_present(int nid, unsigned long start, unsigned long end)
ms = __nr_to_section(section);
if (!ms->section_mem_map)
ms->section_mem_map = sparse_encode_early_nid(nid) |
- SECTION_MARKED_PRESENT;
+ SECTION_MARKED_PRESENT |
+ SECTION_IS_ONLINE;
}
}
@@ -590,6 +591,48 @@ void __init sparse_init(void)
}
#ifdef CONFIG_MEMORY_HOTPLUG
+
+/* Mark all memory sections within the pfn range as online */
+void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
+{
+ unsigned long pfn;
+
+ for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
+ unsigned long section_nr = pfn_to_section_nr(start_pfn);
+ struct mem_section *ms;
+
+ /* onlining code should never touch invalid ranges */
+ if (WARN_ON(!valid_section_nr(section_nr)))
+ continue;
+
+ ms = __nr_to_section(section_nr);
+ ms->section_mem_map |= SECTION_IS_ONLINE;
+ }
+}
+
+#ifdef CONFIG_MEMORY_HOTREMOVE
+/* Mark all memory sections within the pfn range as online */
+void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
+{
+ unsigned long pfn;
+
+ for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
+ unsigned long section_nr = pfn_to_section_nr(start_pfn);
+ struct mem_section *ms;
+
+ /*
+ * TODO this needs some double checking. Offlining code makes
+ * sure to check pfn_valid but those checks might be just bogus
+ */
+ if (WARN_ON(!valid_section_nr(section_nr)))
+ continue;
+
+ ms = __nr_to_section(section_nr);
+ ms->section_mem_map &= ~SECTION_IS_ONLINE;
+ }
+}
+#endif
+
#ifdef CONFIG_SPARSEMEM_VMEMMAP
static inline struct page *kmalloc_section_memmap(unsigned long pnum, int nid)
{
--
2.11.0
--
Michal Hocko
SUSE Labs
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-20 8:49 ` Michal Hocko
@ 2017-04-20 11:56 ` Vlastimil Babka
2017-04-20 12:13 ` Michal Hocko
0 siblings, 1 reply; 348+ messages in thread
From: Vlastimil Babka @ 2017-04-20 11:56 UTC (permalink / raw)
To: Michal Hocko, Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Andrea Arcangeli,
Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu, qiuxishi,
Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On 04/20/2017 10:49 AM, Michal Hocko wrote:
> On Thu 20-04-17 09:28:20, Michal Hocko wrote:
>> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> [...]
>>> Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
>>> woule make that zone->contiguous usually returns false since memory
>>> used by memblock API is marked as PageReserved() and your patch regard
>>> it as a hole. It invalidates set_zone_contiguous() optimization and I
>>> worry about it.
>>
>> OK, fair enough. I did't consider memblock allocations. I will rethink
>> this patch but there are essentially 3 options
>> - use a different criterion for the offline holes dection. I
>> have just realized we might do it by storing the online
>> information into the mem sections
>> - drop this patch
>> - move the PageReferenced check down the chain into
>> isolate_freepages_block resp. isolate_migratepages_block
>>
>> I would prefer 3 over 2 over 1. I definitely want to make this more
>> robust so 1 is preferable long term but I do not want this to be a
>> roadblock to the rest of the rework. Does that sound acceptable to you?
>
> So I've played with all three options just to see how the outcome would
> look like and it turned out that going with 1 will be easiest in the
> end. What do you think about the following? It should be free of any
> false positives. I have only compile tested it yet.
That looks fine, can't say immediately if fully correct. I think you'll
need to bump SECTION_NID_SHIFT as well and make sure things still fit?
Otherwise looks like nobody needed a new section bit since 2005, so we
should be fine.
> ---
> From 747794c13c0e82b55b793a31cdbe1a84ee1c6920 Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@suse.com>
> Date: Thu, 13 Apr 2017 10:28:45 +0200
> Subject: [PATCH] mm: consider zone which is not fully populated to have holes
>
> __pageblock_pfn_to_page has two users currently, set_zone_contiguous
> which checks whether the given zone contains holes and
> pageblock_pfn_to_page which then carefully returns a first valid
> page from the given pfn range for the given zone. This doesn't handle
> zones which are not fully populated though. Memory pageblocks can be
> offlined or might not have been onlined yet. In such a case the zone
> should be considered to have holes otherwise pfn walkers can touch
> and play with offline pages.
>
> Current callers of pageblock_pfn_to_page in compaction seem to work
> properly right now because they only isolate PageBuddy
> (isolate_freepages_block) or PageLRU resp. __PageMovable
> (isolate_migratepages_block) which will be always false for these pages.
> It would be safer to skip these pages altogether, though.
>
> In order to do this patch adds a new memory section state
> (SECTION_IS_ONLINE) which is set in memory_present (during boot
> time) or in online_pages_range during the memory hotplug. Similarly
> offline_mem_sections clears the bit and it is called when the memory
> range is offlined.
>
> pfn_to_online_page helper is then added which check the mem section and
> only returns a page if it is onlined already.
>
> Use the new helper in __pageblock_pfn_to_page and skip the whole page
> block in such a case.
>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> include/linux/memory_hotplug.h | 21 ++++++++++++++++++++
> include/linux/mmzone.h | 20 ++++++++++++++++++-
> mm/memory_hotplug.c | 3 +++
> mm/page_alloc.c | 5 ++++-
> mm/sparse.c | 45 +++++++++++++++++++++++++++++++++++++++++-
> 5 files changed, 91 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 3c8cf86201c3..fc1c873504eb 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -14,6 +14,19 @@ struct memory_block;
> struct resource;
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> +/*
> + * Return page for the valid pfn only if the page is online. All pfn
> + * walkers which rely on the fully initialized page->flags and others
> + * should use this rather than pfn_valid && pfn_to_page
> + */
> +#define pfn_to_online_page(pfn) \
> +({ \
> + struct page *___page = NULL; \
> + \
> + if (online_section_nr(pfn_to_section_nr(pfn))) \
> + ___page = pfn_to_page(pfn); \
> + ___page; \
> +})
>
> /*
> * Types for free bootmem stored in page->lru.next. These have to be in
> @@ -203,6 +216,14 @@ extern void set_zone_contiguous(struct zone *zone);
> extern void clear_zone_contiguous(struct zone *zone);
>
> #else /* ! CONFIG_MEMORY_HOTPLUG */
> +#define pfn_to_online_page(pfn) \
> +({ \
> + struct page *___page = NULL; \
> + if (pfn_valid(pfn)) \
> + ___page = pfn_to_page(pfn); \
> + ___page; \
> + })
> +
> /*
> * Stub functions for when hotplug is off
> */
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 0fc121bbf4ff..cad16ac080f5 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1143,7 +1143,8 @@ extern unsigned long usemap_size(void);
> */
> #define SECTION_MARKED_PRESENT (1UL<<0)
> #define SECTION_HAS_MEM_MAP (1UL<<1)
> -#define SECTION_MAP_LAST_BIT (1UL<<2)
> +#define SECTION_IS_ONLINE (1UL<<2)
> +#define SECTION_MAP_LAST_BIT (1UL<<3)
> #define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1))
> #define SECTION_NID_SHIFT 2
>
> @@ -1174,6 +1175,23 @@ static inline int valid_section_nr(unsigned long nr)
> return valid_section(__nr_to_section(nr));
> }
>
> +static inline int online_section(struct mem_section *section)
> +{
> + return (section && (section->section_mem_map & SECTION_IS_ONLINE));
> +}
> +
> +static inline int online_section_nr(unsigned long nr)
> +{
> + return online_section(__nr_to_section(nr));
> +}
> +
> +#ifdef CONFIG_MEMORY_HOTPLUG
> +void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn);
> +#endif
> +#endif
> +
> static inline struct mem_section *__pfn_to_section(unsigned long pfn)
> {
> return __nr_to_section(pfn_to_section_nr(pfn));
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index caa58338d121..98f565c279bf 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -929,6 +929,9 @@ static int online_pages_range(unsigned long start_pfn, unsigned long nr_pages,
> unsigned long i;
> unsigned long onlined_pages = *(unsigned long *)arg;
> struct page *page;
> +
> + online_mem_sections(start_pfn, start_pfn + nr_pages);
> +
> if (PageReserved(pfn_to_page(start_pfn)))
> for (i = 0; i < nr_pages; i++) {
> page = pfn_to_page(start_pfn + i);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 5d72d29a6ece..fa752de84eef 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1353,7 +1353,9 @@ struct page *__pageblock_pfn_to_page(unsigned long start_pfn,
> if (!pfn_valid(start_pfn) || !pfn_valid(end_pfn))
> return NULL;
>
> - start_page = pfn_to_page(start_pfn);
> + start_page = pfn_to_online_page(start_pfn);
> + if (!start_page)
> + return NULL;
>
> if (page_zone(start_page) != zone)
> return NULL;
> @@ -7686,6 +7688,7 @@ __offline_isolated_pages(unsigned long start_pfn, unsigned long end_pfn)
> break;
> if (pfn == end_pfn)
> return;
> + offline_mem_sections(pfn, end_pfn);
> zone = page_zone(pfn_to_page(pfn));
> spin_lock_irqsave(&zone->lock, flags);
> pfn = start_pfn;
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 6903c8fc3085..79017f90d8fc 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -185,7 +185,8 @@ void __init memory_present(int nid, unsigned long start, unsigned long end)
> ms = __nr_to_section(section);
> if (!ms->section_mem_map)
> ms->section_mem_map = sparse_encode_early_nid(nid) |
> - SECTION_MARKED_PRESENT;
> + SECTION_MARKED_PRESENT |
> + SECTION_IS_ONLINE;
> }
> }
>
> @@ -590,6 +591,48 @@ void __init sparse_init(void)
> }
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> +
> +/* Mark all memory sections within the pfn range as online */
> +void online_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
> +{
> + unsigned long pfn;
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> + unsigned long section_nr = pfn_to_section_nr(start_pfn);
> + struct mem_section *ms;
> +
> + /* onlining code should never touch invalid ranges */
> + if (WARN_ON(!valid_section_nr(section_nr)))
> + continue;
> +
> + ms = __nr_to_section(section_nr);
> + ms->section_mem_map |= SECTION_IS_ONLINE;
> + }
> +}
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +/* Mark all memory sections within the pfn range as online */
> +void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
> +{
> + unsigned long pfn;
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> + unsigned long section_nr = pfn_to_section_nr(start_pfn);
> + struct mem_section *ms;
> +
> + /*
> + * TODO this needs some double checking. Offlining code makes
> + * sure to check pfn_valid but those checks might be just bogus
> + */
> + if (WARN_ON(!valid_section_nr(section_nr)))
> + continue;
> +
> + ms = __nr_to_section(section_nr);
> + ms->section_mem_map &= ~SECTION_IS_ONLINE;
> + }
> +}
> +#endif
> +
> #ifdef CONFIG_SPARSEMEM_VMEMMAP
> static inline struct page *kmalloc_section_memmap(unsigned long pnum, int nid)
> {
>
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-20 11:56 ` Vlastimil Babka
@ 2017-04-20 12:13 ` Michal Hocko
0 siblings, 0 replies; 348+ messages in thread
From: Michal Hocko @ 2017-04-20 12:13 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Joonsoo Kim, linux-mm, Andrew Morton, Mel Gorman,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu 20-04-17 13:56:34, Vlastimil Babka wrote:
> On 04/20/2017 10:49 AM, Michal Hocko wrote:
> > On Thu 20-04-17 09:28:20, Michal Hocko wrote:
> >> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > [...]
> >>> Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> >>> woule make that zone->contiguous usually returns false since memory
> >>> used by memblock API is marked as PageReserved() and your patch regard
> >>> it as a hole. It invalidates set_zone_contiguous() optimization and I
> >>> worry about it.
> >>
> >> OK, fair enough. I did't consider memblock allocations. I will rethink
> >> this patch but there are essentially 3 options
> >> - use a different criterion for the offline holes dection. I
> >> have just realized we might do it by storing the online
> >> information into the mem sections
> >> - drop this patch
> >> - move the PageReferenced check down the chain into
> >> isolate_freepages_block resp. isolate_migratepages_block
> >>
> >> I would prefer 3 over 2 over 1. I definitely want to make this more
> >> robust so 1 is preferable long term but I do not want this to be a
> >> roadblock to the rest of the rework. Does that sound acceptable to you?
> >
> > So I've played with all three options just to see how the outcome would
> > look like and it turned out that going with 1 will be easiest in the
> > end. What do you think about the following? It should be free of any
> > false positives. I have only compile tested it yet.
>
> That looks fine, can't say immediately if fully correct. I think you'll
> need to bump SECTION_NID_SHIFT as well and make sure things still fit?
> Otherwise looks like nobody needed a new section bit since 2005, so we
> should be fine.
You are absolutely right. Thanks for spotting this! I have folded this
in
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 611ff869fa4d..c412e6a3a1e9 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1166,7 +1166,7 @@ extern unsigned long usemap_size(void);
#define SECTION_IS_ONLINE (1UL<<2)
#define SECTION_MAP_LAST_BIT (1UL<<3)
#define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1))
-#define SECTION_NID_SHIFT 2
+#define SECTION_NID_SHIFT 3
static inline struct page *__section_mem_map_addr(struct mem_section *section)
{
--
Michal Hocko
SUSE Labs
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-20 7:28 ` Michal Hocko
2017-04-20 8:49 ` Michal Hocko
@ 2017-04-21 4:38 ` Joonsoo Kim
2017-04-21 7:16 ` Michal Hocko
1 sibling, 1 reply; 348+ messages in thread
From: Joonsoo Kim @ 2017-04-21 4:38 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> [...]
> > > Which pfn walkers you have in mind?
> >
> > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > using pfn_valid().
>
> Yeah, I've checked that one and in fact this is a good example of the
> case where you do not really care about holes. It just checks the page
> count which is a valid information under any circumstances.
I don't think so. First, it checks the page *map* count. Is it still valid
even if PageReserved() is set? What I'd like to ask in this example is
that what information is valid if PageReserved() is set. Is there any
design document on this? I think that we need to define/document it first.
And, I hope that all the information in flags field is valid in all
cases if pfn_valid() return true. By the design.
This makes all the exsiting pfn walkers happy since we don't need an
additional check for PageReserved().
>
> > > > The other problem I found is that your change will makes some
> > > > contiguous zones to be considered as non-contiguous. Memory allocated
> > > > by memblock API is also marked as PageResereved. If we consider this as
> > > > a hole, we will set such a zone as non-contiguous.
> > >
> > > Why would that be a problem? We shouldn't touch those pages anyway?
> >
> > Skipping those pages in compaction are valid so no problem in this
> > case.
> >
> > The problem I mentioned above is that adding PageReserved() check in
> > __pageblock_pfn_to_page() invalidates optimization by
> > set_zone_contiguous(). In compaction, we need to get a valid struct
> > page and it requires a lot of work. There is performance problem
> > report due to this so set_zone_contiguous() optimization is added. It
> > checks if the zone is contiguous or not in boot time. If zone is
> > determined as contiguous, we can easily get a valid struct page in
> > runtime without expensive checks.
>
> OK, I see. I've had some vague understading and the clarification helps.
>
> > Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> > woule make that zone->contiguous usually returns false since memory
> > used by memblock API is marked as PageReserved() and your patch regard
> > it as a hole. It invalidates set_zone_contiguous() optimization and I
> > worry about it.
>
> OK, fair enough. I did't consider memblock allocations. I will rethink
> this patch but there are essentially 3 options
> - use a different criterion for the offline holes dection. I
> have just realized we might do it by storing the online
> information into the mem sections
> - drop this patch
> - move the PageReferenced check down the chain into
> isolate_freepages_block resp. isolate_migratepages_block
>
> I would prefer 3 over 2 over 1. I definitely want to make this more
> robust so 1 is preferable long term but I do not want this to be a
> roadblock to the rest of the rework. Does that sound acceptable to you?
I like #1 among of above options and I already see your patch for #1.
It's much better than your first attempt but I'm still not happy due
to the semantic of pfn_valid().
> [..]
> > Let me clarify my desire(?) for this issue.
> >
> > 1. If pfn_valid() returns true, struct page has valid information, at
> > least, in flags (zone id, node id, flags, etc...). So, we can use them
> > without checking PageResereved().
>
> This is no longer true after my rework. Pages are associated with the
> zone during _onlining_ rather than when they are physically hotpluged.
If your rework make information valid during _onlining_, my
suggestion is making pfn_valid() return false until onlining.
Caller of pfn_valid() expects that they can get valid information from
the struct page. There is no reason to access the struct page if they
can't get valid information from it. So, passing pfn_valid() should
guarantee that, at least, some kind of information is valid.
If pfn_valid() doesn't guarantee it, most of the pfn walker should
check PageResereved() to make sure that validity of information from
the struct page.
> Basically only the nid is set properly. Strictly speaking this is the
> case also without my rework because the zone might change during online
> phase so you cannot assume it is correct even now. It just happens that
> it more or less works just fine.
>
> > 2. pfn_valid() for offlined holes returns false. This can be easily
> > (?) implemented by manipulating SECTION_MAP_MASK in hotplug code. I
> > guess that there is no reason that pfn_valid() returns true for
> > offlined holes. If there is, please let me know.
>
> There is some code which really expects that pfn_valid returns true iff
> there is a struct page and it doesn't care about the online status.
> E.g. hotplug code itself so no, we cannot change pfn_valid. What we can
> do though is to add pfn_to_online_page which would do the proper check.
> I have already sent [1]. As noted above we can (ab)use the remaining bit
> in SECTION_MAP_MASK to detect offline pages more robustly.
Some pfn_valid() caller in hotplug code look wrong. They want to check
section's validity rather than pfn's validity. Others want to access
the struct page so they fit for my assumption (?) for pfn_valid().
Therefore, we can change that pfn_valid() return false until online.
> > 3. We don't need to check PageReserved() in most of pfn walkers in
> > order to check offline holes.
>
> We still have to distinguish those who care about offline pages from
> those who do not care about it.
Hotplug code can distinguish those by another way by using new section
mask as you did in a new patch. If someone excluding hotplug code do
care about offline pages, it would be just for optimization rather
than correteness. I think that it's okay.
Thanks.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-21 4:38 ` Joonsoo Kim
@ 2017-04-21 7:16 ` Michal Hocko
2017-04-24 1:44 ` Joonsoo Kim
0 siblings, 1 reply; 348+ messages in thread
From: Michal Hocko @ 2017-04-21 7:16 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > [...]
> > > > Which pfn walkers you have in mind?
> > >
> > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > using pfn_valid().
> >
> > Yeah, I've checked that one and in fact this is a good example of the
> > case where you do not really care about holes. It just checks the page
> > count which is a valid information under any circumstances.
>
> I don't think so. First, it checks the page *map* count. Is it still valid
> even if PageReserved() is set?
I do not know about any user which would manipulate page map count for
referenced pages. The core MM code doesn't.
> What I'd like to ask in this example is
> that what information is valid if PageReserved() is set. Is there any
> design document on this? I think that we need to define/document it first.
NO, it is not AFAIK.
[...]
> > OK, fair enough. I did't consider memblock allocations. I will rethink
> > this patch but there are essentially 3 options
> > - use a different criterion for the offline holes dection. I
> > have just realized we might do it by storing the online
> > information into the mem sections
> > - drop this patch
> > - move the PageReferenced check down the chain into
> > isolate_freepages_block resp. isolate_migratepages_block
> >
> > I would prefer 3 over 2 over 1. I definitely want to make this more
> > robust so 1 is preferable long term but I do not want this to be a
> > roadblock to the rest of the rework. Does that sound acceptable to you?
>
> I like #1 among of above options and I already see your patch for #1.
> It's much better than your first attempt but I'm still not happy due
> to the semantic of pfn_valid().
You are trying to change a semantic of something that has a well defined
meaning. I disagree that we should change it. It might sound like a
simpler thing to do because pfn walkers will have to be checked but what
you are proposing is conflating two different things together.
> > [..]
> > > Let me clarify my desire(?) for this issue.
> > >
> > > 1. If pfn_valid() returns true, struct page has valid information, at
> > > least, in flags (zone id, node id, flags, etc...). So, we can use them
> > > without checking PageResereved().
> >
> > This is no longer true after my rework. Pages are associated with the
> > zone during _onlining_ rather than when they are physically hotpluged.
>
> If your rework make information valid during _onlining_, my
> suggestion is making pfn_valid() return false until onlining.
>
> Caller of pfn_valid() expects that they can get valid information from
> the struct page. There is no reason to access the struct page if they
> can't get valid information from it. So, passing pfn_valid() should
> guarantee that, at least, some kind of information is valid.
>
> If pfn_valid() doesn't guarantee it, most of the pfn walker should
> check PageResereved() to make sure that validity of information from
> the struct page.
This is true only for those walkers which really depend on the full
initialization. This is not the case for all of them. I do not see any
reason to introduce another _pfn_valid to just check whether there is a
struct page...
So please do not conflate those two different concepts together. I
believe that the most prominent pfn walkers should be covered now and
others can be evaluated later.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-21 7:16 ` Michal Hocko
@ 2017-04-24 1:44 ` Joonsoo Kim
2017-04-24 7:53 ` Michal Hocko
0 siblings, 1 reply; 348+ messages in thread
From: Joonsoo Kim @ 2017-04-24 1:44 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Fri, Apr 21, 2017 at 09:16:16AM +0200, Michal Hocko wrote:
> On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> > On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > > [...]
> > > > > Which pfn walkers you have in mind?
> > > >
> > > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > > using pfn_valid().
> > >
> > > Yeah, I've checked that one and in fact this is a good example of the
> > > case where you do not really care about holes. It just checks the page
> > > count which is a valid information under any circumstances.
> >
> > I don't think so. First, it checks the page *map* count. Is it still valid
> > even if PageReserved() is set?
>
> I do not know about any user which would manipulate page map count for
> referenced pages. The core MM code doesn't.
That's weird that we can get *map* count without PageReserved() check,
but we cannot get zone information.
Zone information is more static information than map count.
It should be defined/documented in this time that what information in
the struct page is valid even if PageReserved() is set. And then, we
need to fix all the things based on this design decision.
>
> > What I'd like to ask in this example is
> > that what information is valid if PageReserved() is set. Is there any
> > design document on this? I think that we need to define/document it first.
>
> NO, it is not AFAIK.
>
> [...]
> > > OK, fair enough. I did't consider memblock allocations. I will rethink
> > > this patch but there are essentially 3 options
> > > - use a different criterion for the offline holes dection. I
> > > have just realized we might do it by storing the online
> > > information into the mem sections
> > > - drop this patch
> > > - move the PageReferenced check down the chain into
> > > isolate_freepages_block resp. isolate_migratepages_block
> > >
> > > I would prefer 3 over 2 over 1. I definitely want to make this more
> > > robust so 1 is preferable long term but I do not want this to be a
> > > roadblock to the rest of the rework. Does that sound acceptable to you?
> >
> > I like #1 among of above options and I already see your patch for #1.
> > It's much better than your first attempt but I'm still not happy due
> > to the semantic of pfn_valid().
>
> You are trying to change a semantic of something that has a well defined
> meaning. I disagree that we should change it. It might sound like a
> simpler thing to do because pfn walkers will have to be checked but what
> you are proposing is conflating two different things together.
I don't think that *I* try to change the semantic of pfn_valid().
It would be original semantic of pfn_valid().
"If pfn_valid() returns true, we can get proper struct page and the
zone information,"
That situation is now being changed by your patch *hotplug rework*.
"Even if pfn_valid() returns true, we cannot get the zone information
without PageReserved() check, since *zone is determined during
onlining* and pfn_valid() return true after adding the memory."
>
> > > [..]
> > > > Let me clarify my desire(?) for this issue.
> > > >
> > > > 1. If pfn_valid() returns true, struct page has valid information, at
> > > > least, in flags (zone id, node id, flags, etc...). So, we can use them
> > > > without checking PageResereved().
> > >
> > > This is no longer true after my rework. Pages are associated with the
> > > zone during _onlining_ rather than when they are physically hotpluged.
> >
> > If your rework make information valid during _onlining_, my
> > suggestion is making pfn_valid() return false until onlining.
> >
> > Caller of pfn_valid() expects that they can get valid information from
> > the struct page. There is no reason to access the struct page if they
> > can't get valid information from it. So, passing pfn_valid() should
> > guarantee that, at least, some kind of information is valid.
> >
> > If pfn_valid() doesn't guarantee it, most of the pfn walker should
> > check PageResereved() to make sure that validity of information from
> > the struct page.
>
> This is true only for those walkers which really depend on the full
> initialization. This is not the case for all of them. I do not see any
> reason to introduce another _pfn_valid to just check whether there is a
> struct page...
It's really confusing concept that only some information is valid for
*not* fully initialized struct page. Even, there is no document that
what information is valid for this half-initialized struct page.
Better design would be that we regard that every information is
invalid for half-initialized struct page. In this case, it's natural
to make pfn_valid() returns false for this half-initialized struct page.
>
> So please do not conflate those two different concepts together. I
> believe that the most prominent pfn walkers should be covered now and
> others can be evaluated later.
Even if original pfn_valid()'s semantic is not the one that I mentioned,
I think that suggested semantic from me is better.
Only hotplug code need to be changed and others doesn't need to be changed.
There is no overhead for others. What's the problem about this approach?
And, I'm not sure that you covered the most prominent pfn walkers.
Please see pagetypeinfo_showblockcount_print() in mm/vmstat.c.
As you admitted, additional check approach is really error-prone and
this example shows that.
Thanks.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-24 1:44 ` Joonsoo Kim
@ 2017-04-24 7:53 ` Michal Hocko
2017-04-25 2:50 ` Joonsoo Kim
0 siblings, 1 reply; 348+ messages in thread
From: Michal Hocko @ 2017-04-24 7:53 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Mon 24-04-17 10:44:43, Joonsoo Kim wrote:
> On Fri, Apr 21, 2017 at 09:16:16AM +0200, Michal Hocko wrote:
> > On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> > > On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > > > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > > > [...]
> > > > > > Which pfn walkers you have in mind?
> > > > >
> > > > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > > > using pfn_valid().
> > > >
> > > > Yeah, I've checked that one and in fact this is a good example of the
> > > > case where you do not really care about holes. It just checks the page
> > > > count which is a valid information under any circumstances.
> > >
> > > I don't think so. First, it checks the page *map* count. Is it still valid
> > > even if PageReserved() is set?
> >
> > I do not know about any user which would manipulate page map count for
> > referenced pages. The core MM code doesn't.
>
> That's weird that we can get *map* count without PageReserved() check,
> but we cannot get zone information.
> Zone information is more static information than map count.
As I've already pointed out the rework of the hotplug code is mainly
about postponing the zone initialization from the physical hot add to
the logical onlining. The zone is really not clear until that moment.
> It should be defined/documented in this time that what information in
> the struct page is valid even if PageReserved() is set. And then, we
> need to fix all the things based on this design decision.
Where would you suggest documenting this? We do have
Documentation/memory-hotplug.txt but it is not really specific about
struct page.
[...]
> > You are trying to change a semantic of something that has a well defined
> > meaning. I disagree that we should change it. It might sound like a
> > simpler thing to do because pfn walkers will have to be checked but what
> > you are proposing is conflating two different things together.
>
> I don't think that *I* try to change the semantic of pfn_valid().
> It would be original semantic of pfn_valid().
>
> "If pfn_valid() returns true, we can get proper struct page and the
> zone information,"
I do not see any guarantee about the zone information anywhere. In fact
this is not true with the original implementation as I've tried to
explain already. We do have new pages associated with a zone but that
association might change during the online phase. So you cannot really
rely on that information until the page is online. There is no real
change in that regards after my rework.
[...]
> > So please do not conflate those two different concepts together. I
> > believe that the most prominent pfn walkers should be covered now and
> > others can be evaluated later.
>
> Even if original pfn_valid()'s semantic is not the one that I mentioned,
> I think that suggested semantic from me is better.
> Only hotplug code need to be changed and others doesn't need to be changed.
> There is no overhead for others. What's the problem about this approach?
That this would require to check _every_ single pfn_valid user in the
kernel. That is beyond my time capacity and not really necessary because
the current code already suffers from the same/similar class of
problems.
> And, I'm not sure that you covered the most prominent pfn walkers.
> Please see pagetypeinfo_showblockcount_print() in mm/vmstat.c.
I probably haven't (and will send a patch to fix this one - thanks for
pointing to it) but the point is they those are broken already and they
can be fixed in follow up patches. If you change pfn_valid you might
break an existing code in an unexpected ways.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-24 7:53 ` Michal Hocko
@ 2017-04-25 2:50 ` Joonsoo Kim
2017-04-26 9:19 ` Michal Hocko
0 siblings, 1 reply; 348+ messages in thread
From: Joonsoo Kim @ 2017-04-25 2:50 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Mon, Apr 24, 2017 at 09:53:12AM +0200, Michal Hocko wrote:
> On Mon 24-04-17 10:44:43, Joonsoo Kim wrote:
> > On Fri, Apr 21, 2017 at 09:16:16AM +0200, Michal Hocko wrote:
> > > On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> > > > On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > > > > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > > > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > > > > [...]
> > > > > > > Which pfn walkers you have in mind?
> > > > > >
> > > > > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > > > > using pfn_valid().
> > > > >
> > > > > Yeah, I've checked that one and in fact this is a good example of the
> > > > > case where you do not really care about holes. It just checks the page
> > > > > count which is a valid information under any circumstances.
> > > >
> > > > I don't think so. First, it checks the page *map* count. Is it still valid
> > > > even if PageReserved() is set?
> > >
> > > I do not know about any user which would manipulate page map count for
> > > referenced pages. The core MM code doesn't.
> >
> > That's weird that we can get *map* count without PageReserved() check,
> > but we cannot get zone information.
> > Zone information is more static information than map count.
>
> As I've already pointed out the rework of the hotplug code is mainly
> about postponing the zone initialization from the physical hot add to
> the logical onlining. The zone is really not clear until that moment.
>
> > It should be defined/documented in this time that what information in
> > the struct page is valid even if PageReserved() is set. And then, we
> > need to fix all the things based on this design decision.
>
> Where would you suggest documenting this? We do have
> Documentation/memory-hotplug.txt but it is not really specific about
> struct page.
pfn_valid() in include/linux/mmzone.h looks proper place.
>
> [...]
>
> > > You are trying to change a semantic of something that has a well defined
> > > meaning. I disagree that we should change it. It might sound like a
> > > simpler thing to do because pfn walkers will have to be checked but what
> > > you are proposing is conflating two different things together.
> >
> > I don't think that *I* try to change the semantic of pfn_valid().
> > It would be original semantic of pfn_valid().
> >
> > "If pfn_valid() returns true, we can get proper struct page and the
> > zone information,"
>
> I do not see any guarantee about the zone information anywhere. In fact
> this is not true with the original implementation as I've tried to
> explain already. We do have new pages associated with a zone but that
> association might change during the online phase. So you cannot really
> rely on that information until the page is online. There is no real
> change in that regards after my rework.
I know that what you did doesn't change thing much. What I try to say
is that previous implementation related to pfn_valid() in hotplug is
wrong. Please do not assume that hotplug implementation is correct and
other pfn_valid() users are incorrect. There is no design document so
I'm not sure which one is correct but assumption that pfn_valid() user
can access whole the struct page information makes much sense to me.
So, I hope that please fix hotplug implementation rather than
modifying each pfn_valid() users.
>
> [...]
> > > So please do not conflate those two different concepts together. I
> > > believe that the most prominent pfn walkers should be covered now and
> > > others can be evaluated later.
> >
> > Even if original pfn_valid()'s semantic is not the one that I mentioned,
> > I think that suggested semantic from me is better.
> > Only hotplug code need to be changed and others doesn't need to be changed.
> > There is no overhead for others. What's the problem about this approach?
>
> That this would require to check _every_ single pfn_valid user in the
> kernel. That is beyond my time capacity and not really necessary because
> the current code already suffers from the same/similar class of
> problems.
I think that all the pfn_valid() user doesn't consider hole case.
Unlike your expectation, if your way is taken, it requires to check
_every_ pfn_valid() users.
Thanks.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-25 2:50 ` Joonsoo Kim
@ 2017-04-26 9:19 ` Michal Hocko
2017-04-27 2:08 ` Joonsoo Kim
0 siblings, 1 reply; 348+ messages in thread
From: Michal Hocko @ 2017-04-26 9:19 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Tue 25-04-17 11:50:45, Joonsoo Kim wrote:
> On Mon, Apr 24, 2017 at 09:53:12AM +0200, Michal Hocko wrote:
> > On Mon 24-04-17 10:44:43, Joonsoo Kim wrote:
> > > On Fri, Apr 21, 2017 at 09:16:16AM +0200, Michal Hocko wrote:
> > > > On Fri 21-04-17 13:38:28, Joonsoo Kim wrote:
> > > > > On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> > > > > > On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > > > > > > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> > > > > > [...]
> > > > > > > > Which pfn walkers you have in mind?
> > > > > > >
> > > > > > > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > > > > > > using pfn_valid().
> > > > > >
> > > > > > Yeah, I've checked that one and in fact this is a good example of the
> > > > > > case where you do not really care about holes. It just checks the page
> > > > > > count which is a valid information under any circumstances.
> > > > >
> > > > > I don't think so. First, it checks the page *map* count. Is it still valid
> > > > > even if PageReserved() is set?
> > > >
> > > > I do not know about any user which would manipulate page map count for
> > > > referenced pages. The core MM code doesn't.
> > >
> > > That's weird that we can get *map* count without PageReserved() check,
> > > but we cannot get zone information.
> > > Zone information is more static information than map count.
> >
> > As I've already pointed out the rework of the hotplug code is mainly
> > about postponing the zone initialization from the physical hot add to
> > the logical onlining. The zone is really not clear until that moment.
> >
> > > It should be defined/documented in this time that what information in
> > > the struct page is valid even if PageReserved() is set. And then, we
> > > need to fix all the things based on this design decision.
> >
> > Where would you suggest documenting this? We do have
> > Documentation/memory-hotplug.txt but it is not really specific about
> > struct page.
>
> pfn_valid() in include/linux/mmzone.h looks proper place.
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index c412e6a3a1e9..443258fcac93 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1288,10 +1288,14 @@ unsigned long __init node_memmap_size_bytes(int, unsigned long, unsigned long);
#ifdef CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
/*
* pfn_valid() is meant to be able to tell if a given PFN has valid memmap
- * associated with it or not. In FLATMEM, it is expected that holes always
- * have valid memmap as long as there is valid PFNs either side of the hole.
- * In SPARSEMEM, it is assumed that a valid section has a memmap for the
- * entire section.
+ * associated with it or not. This means that a struct page exists for this
+ * pfn. The caller cannot assume the page is fully initialized though.
+ * pfn_to_online_page() should be used to make sure the struct page is fully
+ * initialized.
+ *
+ * In FLATMEM, it is expected that holes always have valid memmap as long as
+ * there is valid PFNs either side of the hole. In SPARSEMEM, it is assumed
+ * that a valid section has a memmap for the entire section.
*
* However, an ARM, and maybe other embedded architectures in the future
* free memmap backing holes to save memory on the assumption the memmap is
> > [...]
> >
> > > > You are trying to change a semantic of something that has a well defined
> > > > meaning. I disagree that we should change it. It might sound like a
> > > > simpler thing to do because pfn walkers will have to be checked but what
> > > > you are proposing is conflating two different things together.
> > >
> > > I don't think that *I* try to change the semantic of pfn_valid().
> > > It would be original semantic of pfn_valid().
> > >
> > > "If pfn_valid() returns true, we can get proper struct page and the
> > > zone information,"
> >
> > I do not see any guarantee about the zone information anywhere. In fact
> > this is not true with the original implementation as I've tried to
> > explain already. We do have new pages associated with a zone but that
> > association might change during the online phase. So you cannot really
> > rely on that information until the page is online. There is no real
> > change in that regards after my rework.
>
> I know that what you did doesn't change thing much. What I try to say
> is that previous implementation related to pfn_valid() in hotplug is
> wrong. Please do not assume that hotplug implementation is correct and
> other pfn_valid() users are incorrect. There is no design document so
> I'm not sure which one is correct but assumption that pfn_valid() user
> can access whole the struct page information makes much sense to me.
Not really. E.g. ZONE_DEVICE pages are never online AFAIK. I believe we
still need pfn_valid to work for those pfns. Really, pfn_valid has a
different meaning than you would like it to have. Who knows how many
others like that are lurking there. I feel much more comfortable to go
and hunt already broken code and fix it rathert than break something
unexpectedly.
--
Michal Hocko
SUSE Labs
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-26 9:19 ` Michal Hocko
@ 2017-04-27 2:08 ` Joonsoo Kim
2017-04-27 15:10 ` Michal Hocko
0 siblings, 1 reply; 348+ messages in thread
From: Joonsoo Kim @ 2017-04-27 2:08 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Wed, Apr 26, 2017 at 11:19:06AM +0200, Michal Hocko wrote:
> > > [...]
> > >
> > > > > You are trying to change a semantic of something that has a well defined
> > > > > meaning. I disagree that we should change it. It might sound like a
> > > > > simpler thing to do because pfn walkers will have to be checked but what
> > > > > you are proposing is conflating two different things together.
> > > >
> > > > I don't think that *I* try to change the semantic of pfn_valid().
> > > > It would be original semantic of pfn_valid().
> > > >
> > > > "If pfn_valid() returns true, we can get proper struct page and the
> > > > zone information,"
> > >
> > > I do not see any guarantee about the zone information anywhere. In fact
> > > this is not true with the original implementation as I've tried to
> > > explain already. We do have new pages associated with a zone but that
> > > association might change during the online phase. So you cannot really
> > > rely on that information until the page is online. There is no real
> > > change in that regards after my rework.
> >
> > I know that what you did doesn't change thing much. What I try to say
> > is that previous implementation related to pfn_valid() in hotplug is
> > wrong. Please do not assume that hotplug implementation is correct and
> > other pfn_valid() users are incorrect. There is no design document so
> > I'm not sure which one is correct but assumption that pfn_valid() user
> > can access whole the struct page information makes much sense to me.
>
> Not really. E.g. ZONE_DEVICE pages are never online AFAIK. I believe we
> still need pfn_valid to work for those pfns. Really, pfn_valid has a
It's really contrary example to your insist. They requires not only
struct page but also other information, especially, the zone index.
They checks zone idx to know whether this page is for ZONE_DEVICE or not.
So, pfn_valid() for ZONE_DEVICE pages assume that struct page has all
the valid information. It's perfectly matched with my suggestion.
Online isn't important issue here. What the important point is the condition
that pfn_valid() return true. pfn_valid() for ZONE_DEVICE returns true after
arch_add_memory() since all the struct page information is fixed there.
If zone of hotplugged memory cannot be fixed at this moment, you can
defef it until all the information is fixed (onlining). That
seems to be better semantic of pfn_valid() to me.
> different meaning than you would like it to have. Who knows how many
> others like that are lurking there. I feel much more comfortable to go
> and hunt already broken code and fix it rathert than break something
> unexpectedly.
I think that I did my best to explain my reasoning. It seems that we
cannot agree with each other so it's better for some others to express
their opinion to this problem. I will stop this discussion from now
on.
Thanks.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2017-04-27 2:08 ` Joonsoo Kim
@ 2017-04-27 15:10 ` Michal Hocko
0 siblings, 0 replies; 348+ messages in thread
From: Michal Hocko @ 2017-04-27 15:10 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, Andrew Morton, Mel Gorman, Vlastimil Babka,
Andrea Arcangeli, Jerome Glisse, Reza Arbab, Yasuaki Ishimatsu,
qiuxishi, Kani Toshimitsu, slaoub, Andi Kleen, David Rientjes,
Daniel Kiper, Igor Mammedov, Vitaly Kuznetsov, LKML
On Thu 27-04-17 11:08:38, Joonsoo Kim wrote:
> On Wed, Apr 26, 2017 at 11:19:06AM +0200, Michal Hocko wrote:
> > > > [...]
> > > >
> > > > > > You are trying to change a semantic of something that has a well defined
> > > > > > meaning. I disagree that we should change it. It might sound like a
> > > > > > simpler thing to do because pfn walkers will have to be checked but what
> > > > > > you are proposing is conflating two different things together.
> > > > >
> > > > > I don't think that *I* try to change the semantic of pfn_valid().
> > > > > It would be original semantic of pfn_valid().
> > > > >
> > > > > "If pfn_valid() returns true, we can get proper struct page and the
> > > > > zone information,"
> > > >
> > > > I do not see any guarantee about the zone information anywhere. In fact
> > > > this is not true with the original implementation as I've tried to
> > > > explain already. We do have new pages associated with a zone but that
> > > > association might change during the online phase. So you cannot really
> > > > rely on that information until the page is online. There is no real
> > > > change in that regards after my rework.
> > >
> > > I know that what you did doesn't change thing much. What I try to say
> > > is that previous implementation related to pfn_valid() in hotplug is
> > > wrong. Please do not assume that hotplug implementation is correct and
> > > other pfn_valid() users are incorrect. There is no design document so
> > > I'm not sure which one is correct but assumption that pfn_valid() user
> > > can access whole the struct page information makes much sense to me.
> >
> > Not really. E.g. ZONE_DEVICE pages are never online AFAIK. I believe we
> > still need pfn_valid to work for those pfns. Really, pfn_valid has a
>
> It's really contrary example to your insist. They requires not only
> struct page but also other information, especially, the zone index.
> They checks zone idx to know whether this page is for ZONE_DEVICE or not.
Yes and they guarantee this association is true. Without memory onlining
though. This memory is never online for anybody who is asking.
[...]
> I think that I did my best to explain my reasoning. It seems that we
> cannot agree with each other so it's better for some others to express
> their opinion to this problem. I will stop this discussion from now
> on.
I _do_ appreciate your feedback and if the general consensus is to
modify pfn_valid I can go that direction but my gut feeling tells me
that conflating "existing struct page" test and "fully online and
initialized" one is a wrong thing to do.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2016-11-15 20:29 Christoph Lameter
2016-11-16 10:40 ` your mail Peter Zijlstra
0 siblings, 1 reply; 348+ messages in thread
From: Christoph Lameter @ 2016-11-15 20:29 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Daniel Vacek, Daniel Bristot de Oliveira, Tommaso Cucinotta,
LKML, linux-rt-users, Steven Rostedt, Ingo Molnar
> > There is a deadlock, Peter!!!
>
> Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ?
>
The description was given earlier in the the thread and the drawbacks of
using RT_RUNTIME_SHARE as well.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2016-11-15 20:29 Christoph Lameter
@ 2016-11-16 10:40 ` Peter Zijlstra
2016-11-16 14:25 ` Steven Rostedt
0 siblings, 1 reply; 348+ messages in thread
From: Peter Zijlstra @ 2016-11-16 10:40 UTC (permalink / raw)
To: Christoph Lameter
Cc: Daniel Vacek, Daniel Bristot de Oliveira, Tommaso Cucinotta,
LKML, linux-rt-users, Steven Rostedt, Ingo Molnar
On Tue, Nov 15, 2016 at 02:29:16PM -0600, Christoph Lameter wrote:
>
> > > There is a deadlock, Peter!!!
> >
> > Describe please? Also, have you tried disabling RT_RUNTIME_SHARE ?
> >
>
>
> The description was given earlier in the the thread and the drawbacks of
> using RT_RUNTIME_SHARE as well.
I've not seen a deadlock described. It either was an unbounded priority
inversion or a starvation issue, both of which are 'design' features of
the !rt kernel.
Neither things are new, so its not a regression either.
And, as stated, I'm not really happy to muck with this known troublesome
code and add features for which we must then maintain feature parity
when replacing it either.
On top of which, the implementation had issues; now I know you're the
blinder kind of person that disregards everything not in his immediate
interest, but if you'd looked at the patch you'd have seen he'd added
code the idle entry path, which will slow down every single to-idle
transition.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2016-11-16 10:40 ` your mail Peter Zijlstra
@ 2016-11-16 14:25 ` Steven Rostedt
2016-11-16 14:28 ` Peter Zijlstra
0 siblings, 1 reply; 348+ messages in thread
From: Steven Rostedt @ 2016-11-16 14:25 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Christoph Lameter, Daniel Vacek, Daniel Bristot de Oliveira,
Tommaso Cucinotta, LKML, linux-rt-users, Ingo Molnar
On Wed, 16 Nov 2016 11:40:14 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On top of which, the implementation had issues; now I know you're the
> blinder kind of person that disregards everything not in his immediate
> interest, but if you'd looked at the patch you'd have seen he'd added
> code the idle entry path, which will slow down every single to-idle
> transition.
Isn't to-idle a bit bloated anyway? Or has that been fixed. I know
there was some issues with idle_balance() which can add latency to
wakeups. idle_balance() is also in the to-idle path.
Note, that this is a sched feature which would be a nop (jump_label)
when disabled. And I'm sure it could also be optimized to be a static
inline as well when it is enabled.
I'm not saying we need to go this approach, but I'm just saying that
the to-idle issue is a bit of a red herring.
-- Steve
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2016-11-16 14:25 ` Steven Rostedt
@ 2016-11-16 14:28 ` Peter Zijlstra
0 siblings, 0 replies; 348+ messages in thread
From: Peter Zijlstra @ 2016-11-16 14:28 UTC (permalink / raw)
To: Steven Rostedt
Cc: Christoph Lameter, Daniel Vacek, Daniel Bristot de Oliveira,
Tommaso Cucinotta, LKML, linux-rt-users, Ingo Molnar
On Wed, Nov 16, 2016 at 09:25:43AM -0500, Steven Rostedt wrote:
> On Wed, 16 Nov 2016 11:40:14 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
>
>
> > On top of which, the implementation had issues; now I know you're the
> > blinder kind of person that disregards everything not in his immediate
> > interest, but if you'd looked at the patch you'd have seen he'd added
> > code the idle entry path, which will slow down every single to-idle
> > transition.
>
> Isn't to-idle a bit bloated anyway? Or has that been fixed. I know
> there was some issues with idle_balance() which can add latency to
> wakeups. idle_balance() is also in the to-idle path.
>
Yes it is too heavy as is, but just stacking more crap in just because
its already expensive seems to wrong way around.
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2016-09-20 22:21 Andrew Banman
2016-09-20 22:23 ` your mail andrew banman
0 siblings, 1 reply; 348+ messages in thread
From: Andrew Banman @ 2016-09-20 22:21 UTC (permalink / raw)
To: mingo, akpm; +Cc: tglx, hpa, travis, rja, sivanich, x86, linux-kernel, abanman
>From Andrew Banman <abanman@sgi.com> # This line is ignored.
From: Andrew Banman <abanman@sgi.com>
Subject: [PATCH 0/9] arch/x86/platform/uv: add UV4 support to BAU
In-Reply-To:
The following patch set adds support for UV4 architecture to the Broadcast
Assist Unit (BAU). Major hardware changes to the BAU require these fixes to
ensure correct operation and to avoid illegal MMR writes.
arch/x86/include/asm/uv/uv_bau.h | 45 ++----------------------------
arch/x86/platform/uv/tlb_uv.c | 114 ++++++++++++++++++++++++---------------------------------------
-------------
The patch set can be thought of in three logical groups:
1) General cleanup.
[PATCH 1/9] arch/x86/platform/uv: BAU cleanup: update printks
[PATCH 2/9] arch/x86/platform/uv: BAU cleanup: pq_init
[PATCH 3/9] arch/x86/platform/uv: BAU replace uv_physnodeaddr
These housekeeping patches make the subsequent UV4 patches clearer,
and they should be done in any case.
2) Implement a new scheme to abstract UV version-specific functions.
[PATCH 4/9] arch/x86/platform/uv: BAU add generic function pointers
[PATCH 5/9] arch/x86/platform/uv: BAU use generic function pointers
We add a struct of function pointers to define version-specific BAU
operations. The philosophy is to abstract functions that perform the same
operation on all UV versions but have different implementations. This will
simplify their use in the body of the driver code and greatly simplify the
UV4 patches to follow.
3) Add UV4 functionality.
[PATCH 6/9] arch/x86/platform/uv: BAU UV4 populate uvhub_version
[PATCH 7/9] arch/x86/platform/uv: BAU UV4 disable software timeout
[PATCH 8/9] arch/x86/platform/uv: BAU UV4 fix payload queue setup
[PATCH 9/9] arch/x86/platform/uv: BAU UV4 add version-specific
These patches feature a minimal set of changes to make the BAU on UV4
operational.
This patch set has been tested for regressions on pre-UV4 architectures and
for correct functionality on UV4. The patches apply cleanly to 4.8-rc7.
Fine-tuned performance tweaking for UV4 will come in a future patch set.
Thank you,
Andrew Banman
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2016-09-20 22:21 Andrew Banman
@ 2016-09-20 22:23 ` andrew banman
0 siblings, 0 replies; 348+ messages in thread
From: andrew banman @ 2016-09-20 22:23 UTC (permalink / raw)
To: Andrew Banman
Cc: mingo, akpm, tglx, hpa, travis, rja, sivanich, x86, linux-kernel
Subject line got dropped the first time around. Will send again.
Apologies for the chatter,
Andrew
On Tue, Sep 20, 2016 at 05:21:06PM -0500, Andrew Banman wrote:
> From Andrew Banman <abanman@sgi.com> # This line is ignored.
> From: Andrew Banman <abanman@sgi.com>
> Subject: [PATCH 0/9] arch/x86/platform/uv: add UV4 support to BAU
> In-Reply-To:
>
> The following patch set adds support for UV4 architecture to the Broadcast
> Assist Unit (BAU). Major hardware changes to the BAU require these fixes to
> ensure correct operation and to avoid illegal MMR writes.
>
> arch/x86/include/asm/uv/uv_bau.h | 45 ++----------------------------
> arch/x86/platform/uv/tlb_uv.c | 114 ++++++++++++++++++++++++---------------------------------------
> -------------
>
> The patch set can be thought of in three logical groups:
>
> 1) General cleanup.
>
> [PATCH 1/9] arch/x86/platform/uv: BAU cleanup: update printks
> [PATCH 2/9] arch/x86/platform/uv: BAU cleanup: pq_init
> [PATCH 3/9] arch/x86/platform/uv: BAU replace uv_physnodeaddr
>
> These housekeeping patches make the subsequent UV4 patches clearer,
> and they should be done in any case.
>
>
> 2) Implement a new scheme to abstract UV version-specific functions.
>
> [PATCH 4/9] arch/x86/platform/uv: BAU add generic function pointers
> [PATCH 5/9] arch/x86/platform/uv: BAU use generic function pointers
>
> We add a struct of function pointers to define version-specific BAU
> operations. The philosophy is to abstract functions that perform the same
> operation on all UV versions but have different implementations. This will
> simplify their use in the body of the driver code and greatly simplify the
> UV4 patches to follow.
>
>
> 3) Add UV4 functionality.
>
> [PATCH 6/9] arch/x86/platform/uv: BAU UV4 populate uvhub_version
> [PATCH 7/9] arch/x86/platform/uv: BAU UV4 disable software timeout
> [PATCH 8/9] arch/x86/platform/uv: BAU UV4 fix payload queue setup
> [PATCH 9/9] arch/x86/platform/uv: BAU UV4 add version-specific
>
> These patches feature a minimal set of changes to make the BAU on UV4
> operational.
>
>
> This patch set has been tested for regressions on pre-UV4 architectures and
> for correct functionality on UV4. The patches apply cleanly to 4.8-rc7.
> Fine-tuned performance tweaking for UV4 will come in a future patch set.
>
>
> Thank you,
>
> Andrew Banman
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2015-08-03 6:18 Shraddha Barke
2015-08-03 7:12 ` your mail Sudip Mukherjee
2015-08-03 7:24 ` Dan Carpenter
0 siblings, 2 replies; 348+ messages in thread
From: Shraddha Barke @ 2015-08-03 6:18 UTC (permalink / raw)
To: Oleg Drokin, Al Viro, Julia Lawall, aybuke ozdemir,
Andreas Dilger, John L. Hammond, Frank Zago, Greg Kroah-Hartman,
HPDD-discuss, devel, linux-kernel
Cc: Shraddha Barke
>From b67c6c20455b04b77447ab4561e44f1a75dd978d Mon Sep 17 00:00:00 2001
From: Shraddha Barke <shraddha.6596@gmail.com>
Date: Mon, 3 Aug 2015 11:34:19 +0530
Subject: [PATCH] Staging : lustre : Use -EINVAL instead of -ENOSYS
ENOSYS means that a nonexistent system call was called. This should
not be used for invalid operations on otherwise valid syscalls.
Use -EINVAL instead of -ENOSYS. This fixes checkpatch warning message:
WARNING: ENOSYS means 'invalid syscall nr' and nothing else
Signed-off-by: Shraddha Barke <shraddha.6596@gmail.com>
---
drivers/staging/lustre/lustre/llite/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/llite/file.c b/drivers/staging/lustre/lustre/llite/file.c
index 2c467bf..93619a8 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -2786,7 +2786,7 @@ ll_file_flock(struct file *file, int cmd, struct file_lock *file_lock)
static int
ll_file_noflock(struct file *file, int cmd, struct file_lock *file_lock)
{
- return -ENOSYS;
+ return -EINVAL;
}
/**
--
2.1.0
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2015-08-03 6:18 Shraddha Barke
@ 2015-08-03 7:12 ` Sudip Mukherjee
2015-08-03 7:24 ` Dan Carpenter
1 sibling, 0 replies; 348+ messages in thread
From: Sudip Mukherjee @ 2015-08-03 7:12 UTC (permalink / raw)
To: Shraddha Barke
Cc: Oleg Drokin, Al Viro, Julia Lawall, aybuke ozdemir,
Andreas Dilger, John L. Hammond, Frank Zago, Greg Kroah-Hartman,
HPDD-discuss, devel, linux-kernel
On Mon, Aug 03, 2015 at 11:48:59AM +0530, Shraddha Barke wrote:
> From b67c6c20455b04b77447ab4561e44f1a75dd978d Mon Sep 17 00:00:00 2001
> From: Shraddha Barke <shraddha.6596@gmail.com>
> Date: Mon, 3 Aug 2015 11:34:19 +0530
> Subject: [PATCH] Staging : lustre : Use -EINVAL instead of -ENOSYS
You do not need these in the commit message.
regards
sudip
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2015-08-03 6:18 Shraddha Barke
2015-08-03 7:12 ` your mail Sudip Mukherjee
@ 2015-08-03 7:24 ` Dan Carpenter
1 sibling, 0 replies; 348+ messages in thread
From: Dan Carpenter @ 2015-08-03 7:24 UTC (permalink / raw)
To: Shraddha Barke
Cc: Oleg Drokin, Al Viro, Julia Lawall, aybuke ozdemir,
Andreas Dilger, John L. Hammond, Frank Zago, Greg Kroah-Hartman,
HPDD-discuss, devel, linux-kernel
Returning EINVAL here is the wrong thing. Just leave the code as is.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <20150121201024.GA4548@obsidianresearch.com>]
* (no subject)
@ 2014-10-15 8:10 Christoph Lameter
2014-10-27 15:07 ` your mail Tejun Heo
0 siblings, 1 reply; 348+ messages in thread
From: Christoph Lameter @ 2014-10-15 8:10 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-kernel
Subject: Convert remaining __get_cpu_var uses
During the 3.18 merge period additional __get_cpu_var uses were
added. The patch converts these to this_cpu_ptr().
[This does not address the powerpc issue where the conversion
patches were routed directly to the powerpc maintainers but were
not applied in the merge period. Will have to be handled separately]
Signed-off-by: Christoph Lameter <cl@linux.com>
Index: linux/arch/arm/xen/mm32.c
===================================================================
--- linux.orig/arch/arm/xen/mm32.c
+++ linux/arch/arm/xen/mm32.c
@@ -56,7 +56,7 @@ static struct notifier_block xen_mm32_cp
static void* xen_mm32_remap_page(dma_addr_t handle)
{
unsigned long virt = get_cpu_var(xen_mm32_scratch_virt);
- pte_t *ptep = __get_cpu_var(xen_mm32_scratch_ptep);
+ pte_t *ptep = __this_cpu_read(xen_mm32_scratch_ptep);
*ptep = pfn_pte(handle >> PAGE_SHIFT, PAGE_KERNEL);
local_flush_tlb_kernel_page(virt);
Index: linux/arch/arm64/kernel/psci.c
===================================================================
--- linux.orig/arch/arm64/kernel/psci.c
+++ linux/arch/arm64/kernel/psci.c
@@ -511,7 +511,7 @@ static int cpu_psci_cpu_kill(unsigned in
static int psci_suspend_finisher(unsigned long index)
{
- struct psci_power_state *state = __get_cpu_var(psci_power_state);
+ struct psci_power_state *state = __this_cpu_read(psci_power_state);
return psci_ops.cpu_suspend(state[index - 1],
virt_to_phys(cpu_resume));
@@ -520,7 +520,7 @@ static int psci_suspend_finisher(unsigne
static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
{
int ret;
- struct psci_power_state *state = __get_cpu_var(psci_power_state);
+ struct psci_power_state *state = __this_cpu_read(psci_power_state);
/*
* idle state index 0 corresponds to wfi, should never be called
* from the cpu_suspend operations
Index: linux/kernel/irq_work.c
===================================================================
--- linux.orig/kernel/irq_work.c
+++ linux/kernel/irq_work.c
@@ -175,11 +175,11 @@ EXPORT_SYMBOL_GPL(irq_work_run);
void irq_work_tick(void)
{
- struct llist_head *raised = &__get_cpu_var(raised_list);
+ struct llist_head *raised = this_cpu_ptr(&raised_list);
if (!llist_empty(raised) && !arch_irq_work_has_interrupt())
irq_work_run_list(raised);
- irq_work_run_list(&__get_cpu_var(lazy_list));
+ irq_work_run_list(this_cpu_ptr(&lazy_list));
}
/*
Index: linux/kernel/time/tick-sched.c
===================================================================
--- linux.orig/kernel/time/tick-sched.c
+++ linux/kernel/time/tick-sched.c
@@ -235,7 +235,7 @@ void tick_nohz_full_kick(void)
if (!tick_nohz_full_cpu(smp_processor_id()))
return;
- irq_work_queue(&__get_cpu_var(nohz_full_kick_work));
+ irq_work_queue(this_cpu_ptr(&nohz_full_kick_work));
}
/*
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2014-10-15 8:10 Christoph Lameter
@ 2014-10-27 15:07 ` Tejun Heo
0 siblings, 0 replies; 348+ messages in thread
From: Tejun Heo @ 2014-10-27 15:07 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-kernel
Hello, Christoph.
On Wed, Oct 15, 2014 at 03:10:37AM -0500, Christoph Lameter wrote:
> Subject: Convert remaining __get_cpu_var uses
>
> During the 3.18 merge period additional __get_cpu_var uses were
> added. The patch converts these to this_cpu_ptr().
>
> [This does not address the powerpc issue where the conversion
> patches were routed directly to the powerpc maintainers but were
> not applied in the merge period. Will have to be handled separately]
>
> Signed-off-by: Christoph Lameter <cl@linux.com>
Can you please repost with proper subject line and the subsys
maintainers cc'd?
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2014-09-01 15:47 sunwxg
2014-09-01 17:01 ` your mail Dan Carpenter
0 siblings, 1 reply; 348+ messages in thread
From: sunwxg @ 2014-09-01 15:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, Dulshani Gunawardhana, Josh Triplett,
John L. Hammond, Andreas Dilger, Chi Pham, Oleg Drokin
Cc: Sun Wang, devel, linux-kernel
From: Sun Wang <sun.wxg@gmail.com>
Subject: [PATCH] staging: lustre: lov_pack: fix coding style issue
Fix the style error checking by checkpatch.pl
ERROR: space required after that ','
Signed-off-by: Sun Wang <sun.wxg@gmail.com>
---
drivers/staging/lustre/lustre/lov/lov_pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/lov/lov_pack.c b/drivers/staging/lustre/lustre/lov/lov_pack.c
index 20e5870..62ea223 100644
--- a/drivers/staging/lustre/lustre/lov/lov_pack.c
+++ b/drivers/staging/lustre/lustre/lov/lov_pack.c
@@ -95,7 +95,7 @@ void lov_dump_lmm_v1(int level, struct lov_mds_md_v1 *lmm)
void lov_dump_lmm_v3(int level, struct lov_mds_md_v3 *lmm)
{
lov_dump_lmm_common(level, lmm);
- CDEBUG(level,"pool_name "LOV_POOLNAMEF"\n", lmm->lmm_pool_name);
+ CDEBUG(level, "pool_name "LOV_POOLNAMEF"\n", lmm->lmm_pool_name);
lov_dump_lmm_objects(level, lmm->lmm_objects,
le16_to_cpu(lmm->lmm_stripe_count));
}
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2014-09-01 15:47 sunwxg
@ 2014-09-01 17:01 ` Dan Carpenter
0 siblings, 0 replies; 348+ messages in thread
From: Dan Carpenter @ 2014-09-01 17:01 UTC (permalink / raw)
To: sunwxg
Cc: Greg Kroah-Hartman, Dulshani Gunawardhana, Josh Triplett,
John L. Hammond, Andreas Dilger, Chi Pham, Oleg Drokin, devel,
linux-kernel
No subject.
It should be a subject about adding spaces.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <1409556896-21523-2-git-send-email-xiaoguang_wang5188@qq.com>]
* Re: your mail
[not found] <1409556896-21523-2-git-send-email-xiaoguang_wang5188@qq.com>
@ 2014-09-01 8:04 ` Dan Carpenter
0 siblings, 0 replies; 348+ messages in thread
From: Dan Carpenter @ 2014-09-01 8:04 UTC (permalink / raw)
To: sunwxg
Cc: Benjamin Romer, David Kershner, Greg Kroah-Hartman, Ken Cox,
Iulia Manda, Luis R. Rodriguez, Masaru Nomura, devel,
sparmaintainer, linux-kernel
On Mon, Sep 01, 2014 at 03:34:56PM +0800, sunwxg wrote:
> From: Sun Wang <xiaoguang_wang5188@qq.com>
>
> Subject: [PATCH] staging: unisys: visorutil: procobjecttree: fix coding style issue
>
Your email headers are mangled. The subject is vague.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2014-07-09 1:03 James Ban
2014-07-09 7:56 ` your mail Mark Brown
0 siblings, 1 reply; 348+ messages in thread
From: James Ban @ 2014-07-09 1:03 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, Support Opensource, LKML, David Dajun Chen
> -----Original Message-----
> From: Mark Brown [mailto:broonie@kernel.org]
> Sent: Tuesday, July 08, 2014 4:36 PM
> To: Opensource [James Seong-Won Ban]
> Cc: Liam Girdwood; Support Opensource; LKML; David Dajun Chen
> Subject: Re: [PATCH V4] regulator: DA9211 : new regulator driver
>
> On Thu, Jul 03, 2014 at 04:29:03PM +0900, James Ban wrote:
>
> This is greatly improved, thanks, however there are still a few issues which
> should be addressed:
>
> > +static irqreturn_t da9211_irq_handler(int irq, void *data) {
> > + struct da9211 *chip = data;
> > + int reg_val, ret;
> > +
> > + ret = regmap_read(chip->regmap, DA9211_REG_EVENT_B, ®_val);
> > + if (ret < 0)
> > + goto error_i2c;
> > +
> > + if (reg_val & DA9211_E_OV_CURR_A) {
>
> > + if (reg_val & DA9211_E_OV_CURR_B) {
>
> > +
> > + return IRQ_HANDLED;
>
> This is buggy - the driver should only return IRQ_HANDLED if it handled the
> interrupt somehow, otherwise it should return IRQ_NONE and let the interrupt
> core handle things. This is especially important since the device appears to
> require that interrupts are explicitly acknoweldged so if something is flagged
> but not handled the interrupt will just sit constantly asserted.
Basically all interrupts are masked when the chip wakes up.
Only two interrupts are unmasked at the start of driver like below.
-------------
if (chip->chip_irq != 0) {
ret = regmap_update_bits(chip->regmap,
DA9211_REG_MASK_B, DA9211_M_OV_CURR_A << i, 1);
-----------------
So constant assertion which you are worry about could not happen.
Please let me know if you think other case.
>
> > +static int da9211_regulator_init(struct da9211 *chip) {
> > + struct regulator_config config = { };
> > + int i, ret;
> > + unsigned int data;
> > +
> > + ret = regmap_update_bits(chip->regmap, DA9211_REG_PAGE_CON,
> > + DA9211_REG_PAGE_MASK, DA9211_REG_PAGE2);
> > + if (ret < 0) {
> > + dev_err(chip->dev, "Failed to update PAGE reg: %d\n", ret);
> > + goto err;
> > + }
>
> It would be better to model the paging in the register map in the regmap
> - the API has support for this, it's going to be more robust to use it.
I will change the code for the usage of the API.
>
> > + dev_info(chip->dev, "# IRQ configured [%d]\n", chip->chip_irq);
>
> > + for (i = 0; i < chip->num_regulator; i++)
> > + regulator_unregister(chip->rdev[i]);
>
> Use devm_regulator_register().
I will do it.
>
> > + if (chip->chip_irq != 0)
> > + free_irq(chip->chip_irq, chip);
>
> devm_request_threaded_irq().
I will use devm_request_threaded_irq and remove free_irq.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2014-07-09 1:03 James Ban
@ 2014-07-09 7:56 ` Mark Brown
0 siblings, 0 replies; 348+ messages in thread
From: Mark Brown @ 2014-07-09 7:56 UTC (permalink / raw)
To: James Ban; +Cc: Liam Girdwood, Support Opensource, LKML, David Dajun Chen
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
On Wed, Jul 09, 2014 at 10:03:32AM +0900, James Ban wrote:
> > > + ret = regmap_read(chip->regmap, DA9211_REG_EVENT_B, ®_val);
> > > + if (ret < 0)
> > > + goto error_i2c;
> > > + if (reg_val & DA9211_E_OV_CURR_A) {
> > > + if (reg_val & DA9211_E_OV_CURR_B) {
> > > + return IRQ_HANDLED;
> > This is buggy - the driver should only return IRQ_HANDLED if it handled the
> > interrupt somehow, otherwise it should return IRQ_NONE and let the interrupt
> > core handle things. This is especially important since the device appears to
> > require that interrupts are explicitly acknoweldged so if something is flagged
> > but not handled the interrupt will just sit constantly asserted.
> Basically all interrupts are masked when the chip wakes up.
> Only two interrupts are unmasked at the start of driver like below.
I know that's the intention but the code should still be written
robustly - something might go wrong somewhere which causes another
interrupt to be enabled, or we might even gain support for shared
threaded interrupts in the interrupt core and someone could then
try to use that in a system.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <CAM0G4ztXWM5kw6dV4WRrTVJBMmeJDXuRnbeRBE603hM+7c=PCg@mail.gmail.com>]
* Re: your mail
[not found] <CAM0G4ztXWM5kw6dV4WRrTVJBMmeJDXuRnbeRBE603hM+7c=PCg@mail.gmail.com>
@ 2014-02-25 15:01 ` Will Deacon
0 siblings, 0 replies; 348+ messages in thread
From: Will Deacon @ 2014-02-25 15:01 UTC (permalink / raw)
To: srikanth TS; +Cc: ts.srikanth, linux-kernel, iommu, sungjinn.chung
On Tue, Feb 25, 2014 at 11:20:11AM +0000, srikanth TS wrote:
>
> On Feb 25, 2014 2:28 AM, "Will Deacon" <will.deacon@arm.com<mailto:will.deacon@arm.com>> wrote:
> >
> > On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> > > Hi Will Deacon,
> >
> > Hello,
> >
> > > Currently SMMU driver expecting all stream ID used by respective master
> > > should be defined in the DT.
> > >
> > > We want to know how to handle in the case of virtual functions dynamically
> > > created and destroyed.
> > >
> > > Is PCI driver responsible for creating stream ID respective BDand
> > > requesting SMMU to add to the mapping table[stream Id to context mapping
> > > table]?
> > >
> > > Or is there any right way of doing it?
> >
> > Correct, the driver currently doesn't support dynamic mappings (mainly
> > because I didn't want to try and invent something that I couldn't test).
> >
> > There are a couple of ways to solve this:
> >
> > (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
> > within a fixed range. That would probably need some code in the bus
> > layer, so that a bus notifier can kick and call back to the relevant
> > SMMU.
>
> I think first way of solving seems to be better, because we don't know how many
>
> VF are used and i feel its not good idea to keep whole list of streamID [which is
>
> equal to max num vf] in DT. Again in this method we need to generate the stream ID
>
> dynamically whenever VF is added in pci iov driver side. And then pass that
>
> stream ID to SMMU.
>
> Is it ok this way? Or you prefer 2nd way which is simpler.
I'm happy either way, but I'd need to see some patches before I can merge
anything ;)
Will
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <CAM0G4zvu1BHcOrSgBuobvb-+fVsNWXjXdzZdV51T70B9_ZC4XQ@mail.gmail.com>]
* Re: your mail
[not found] <CAM0G4zvu1BHcOrSgBuobvb-+fVsNWXjXdzZdV51T70B9_ZC4XQ@mail.gmail.com>
@ 2014-02-24 17:28 ` Will Deacon
2014-02-25 11:28 ` Varun Sethi
0 siblings, 1 reply; 348+ messages in thread
From: Will Deacon @ 2014-02-24 17:28 UTC (permalink / raw)
To: srikanth TS; +Cc: iommu, linux-kernel, ts.srikanth, sungjinn.chung
On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> Hi Will Deacon,
Hello,
> Currently SMMU driver expecting all stream ID used by respective master
> should be defined in the DT.
>
> We want to know how to handle in the case of virtual functions dynamically
> created and destroyed.
>
> Is PCI driver responsible for creating stream ID respective BDand
> requesting SMMU to add to the mapping table[stream Id to context mapping
> table]?
>
> Or is there any right way of doing it?
Correct, the driver currently doesn't support dynamic mappings (mainly
because I didn't want to try and invent something that I couldn't test).
There are a couple of ways to solve this:
(1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
within a fixed range. That would probably need some code in the bus
layer, so that a bus notifier can kick and call back to the relevant
SMMU.
(2) Describe the RID -> SID mapping in the device-tree. We probably want
to avoid an enormous table, so this would only work for simple `SID =
RID + offset' or 'SID = RID & mask' cases.
How do your IDs map to each other?
Will
^ permalink raw reply [flat|nested] 348+ messages in thread
* RE: your mail
2014-02-24 17:28 ` Will Deacon
@ 2014-02-25 11:28 ` Varun Sethi
0 siblings, 0 replies; 348+ messages in thread
From: Varun Sethi @ 2014-02-25 11:28 UTC (permalink / raw)
To: Will Deacon, srikanth TS; +Cc: iommu, sungjinn.chung, linux-kernel, ts.srikanth
> -----Original Message-----
> From: iommu-bounces@lists.linux-foundation.org [mailto:iommu-
> bounces@lists.linux-foundation.org] On Behalf Of Will Deacon
> Sent: Monday, February 24, 2014 10:59 PM
> To: srikanth TS
> Cc: iommu@lists.linux-foundation.org; sungjinn.chung@samsung.com; linux-
> kernel@vger.kernel.org; ts.srikanth@samsung.com
> Subject: Re: your mail
>
> On Mon, Feb 24, 2014 at 03:12:21PM +0000, srikanth TS wrote:
> > Hi Will Deacon,
>
> Hello,
>
> > Currently SMMU driver expecting all stream ID used by respective
> > master should be defined in the DT.
> >
> > We want to know how to handle in the case of virtual functions
> > dynamically created and destroyed.
> >
> > Is PCI driver responsible for creating stream ID respective BDand
> > requesting SMMU to add to the mapping table[stream Id to context
> > mapping table]?
> >
> > Or is there any right way of doing it?
>
> Correct, the driver currently doesn't support dynamic mappings (mainly
> because I didn't want to try and invent something that I couldn't test).
>
> There are a couple of ways to solve this:
>
> (1) Add a way for a PCI RC to dynamically allocate StreamIDs on an SMMU
> within a fixed range. That would probably need some code in the bus
> layer, so that a bus notifier can kick and call back to the
> relevant
> SMMU.
This could be done in add device notifier. I am working on similar(not PCI) hot plug device infrastructure for arm smmu driver. I will post an RFC patch by next week.
-Varun
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2014-01-23 9:06 Prabhakar Lad
2014-01-23 19:55 ` your mail Mark Brown
0 siblings, 1 reply; 348+ messages in thread
From: Prabhakar Lad @ 2014-01-23 9:06 UTC (permalink / raw)
To: Mark Brown, broonie; +Cc: LKML
Hi Mark,
I see a issue with one of the davinci boards, where regulator_get() fails
from this patch "regulator: core: Provide a dummy regulator with full
constraints".
as I see regulator_get() supports dummy regulators by default.
So currently I am booting it traditional way (NON DT way) and
regulator_dev_lookup()
fails (return NULL) and for this check it fails.
+ if (ret && ret != -ENODEV) {
regulator = ERR_PTR(ret);
goto out;
}
In the NON-DT case the 'ret' is never updated in regulator_dev_lookup().
I tried adding regulator_has_full_constraints(); call in .init_machine
but results
the same. Any pointer would be helpfull.
Thanks,
--Prabhakar Lad
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <1388425244-10017-1-git-send-email-jdb@sitrep3.com>]
* Re: your mail
[not found] <1388425244-10017-1-git-send-email-jdb@sitrep3.com>
@ 2014-01-09 18:39 ` Greg KH
2014-01-09 18:49 ` Joe Borġ
0 siblings, 1 reply; 348+ messages in thread
From: Greg KH @ 2014-01-09 18:39 UTC (permalink / raw)
To: Joe Borg; +Cc: abbotti, hsweeten, devel, linux-kernel
On Mon, Dec 30, 2013 at 05:40:44PM +0000, Joe Borg wrote:
> >From 6d9f6446434c4021cc9452e31c374ac50e08f0f9 Mon Sep 17 00:00:00 2001
> From: Joe Borg <root@josephb.org>
This isn't matching your "from:" line on your email, why should I trust
it?
And doing kernel work as 'root'? That's not a good idea for lots of
reasons...
> Date: Mon, 30 Dec 2013 15:35:08 +0000
> Subject: [PATCH 62/62] DAS1800: Fixing error from checkpatch.
>
> Fixed pointer typeo; foo * bar should be foo *bar.
>
> Signed-off by Joe Borg <root@josephb.org>
What happened to your Subject:?
And why is the whole git header in the email, please use git send-email
so that I don't have to hand-edit the body of the email to apply it.
Can you please fix this up and resend?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2014-01-09 18:39 ` Greg KH
@ 2014-01-09 18:49 ` Joe Borġ
2014-01-14 16:40 ` Steven Rostedt
0 siblings, 1 reply; 348+ messages in thread
From: Joe Borġ @ 2014-01-09 18:49 UTC (permalink / raw)
To: Greg KH; +Cc: abbotti, hsweeten, devel, linux-kernel
Hi Greg,
I'll re do them tonight.
I didn't do the changes as root, I sent them from my server as it has SMTP out.
Thanks
Regards,
Joseph David Borġ
http://www.jdborg.com
On 9 January 2014 18:39, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Dec 30, 2013 at 05:40:44PM +0000, Joe Borg wrote:
>> >From 6d9f6446434c4021cc9452e31c374ac50e08f0f9 Mon Sep 17 00:00:00 2001
>> From: Joe Borg <root@josephb.org>
>
> This isn't matching your "from:" line on your email, why should I trust
> it?
>
> And doing kernel work as 'root'? That's not a good idea for lots of
> reasons...
>
>> Date: Mon, 30 Dec 2013 15:35:08 +0000
>> Subject: [PATCH 62/62] DAS1800: Fixing error from checkpatch.
>>
>> Fixed pointer typeo; foo * bar should be foo *bar.
>>
>> Signed-off by Joe Borg <root@josephb.org>
>
> What happened to your Subject:?
>
> And why is the whole git header in the email, please use git send-email
> so that I don't have to hand-edit the body of the email to apply it.
>
> Can you please fix this up and resend?
>
> thanks,
>
> greg k-h
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2014-01-09 18:49 ` Joe Borġ
@ 2014-01-14 16:40 ` Steven Rostedt
0 siblings, 0 replies; 348+ messages in thread
From: Steven Rostedt @ 2014-01-14 16:40 UTC (permalink / raw)
To: Joe Bor??; +Cc: Greg KH, abbotti, hsweeten, devel, linux-kernel
On Thu, Jan 09, 2014 at 06:49:39PM +0000, Joe Bor?? wrote:
>
> I didn't do the changes as root, I sent them from my server as it has SMTP out.
>
Hmm, this gives me an idea. There's nothing, I believe, that makes the root user
have to have the name "root" except for the passwd file. Maybe I'll just
rename "root" to "walley" and then use "root" as my normal account. If anyone tries
to break into "root" they will just gain access to a normal account and nothing
more ;-)
/me goes back to hacking
-- Steve
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <CACaajQtCTW_PKA25q3-4o4XAV6sgZnyD+Skkw6mhUHpRBEgbjQ@mail.gmail.com>]
* Re: your mail
[not found] <CACaajQtCTW_PKA25q3-4o4XAV6sgZnyD+Skkw6mhUHpRBEgbjQ@mail.gmail.com>
@ 2012-11-26 18:29 ` Greg KH
0 siblings, 0 replies; 348+ messages in thread
From: Greg KH @ 2012-11-26 18:29 UTC (permalink / raw)
To: Vasiliy Tolstov; +Cc: linux-kernel, stable
On Mon, Nov 26, 2012 at 10:14:44PM +0400, Vasiliy Tolstov wrote:
> Hello, Greg. Hello kernel team! I'm system enginer at clodo.ru (russian cloud
> hosting provider) we are use xen and sles11-sp2 for our compute xen nodes.
> Each virtual machine (domU) have disks that attached by Infiniband SRP. On top
> of disk that attached by srp we use multipath (to do failover)
> Now we have issues like all commands that uses multipath hang while one storage
> is rebooted.
> After some discussion with maintainer of linux-rdma (Bart Van Assche) and using
> it backported ib_srp with HA patches we can't solve deadlock issues. Bart
> thinks that SLES team does not backport some core scsi patches to their kernel
> (3.0.42) to prevent multipath deadlock (currently is about 2.5 minutes) on
> failed target.
> Is that possible to determine or getting help to solve this issue?
As you are using SLES, please contact the SUSE for support for that
kernel, as you are paying for it, and the community can't do anything to
support their kernel, sorry.
Best of luck,
greg k-h
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2012-10-10 15:06 Kent Yoder
2012-10-10 15:12 ` your mail Kent Yoder
0 siblings, 1 reply; 348+ messages in thread
From: Kent Yoder @ 2012-10-10 15:06 UTC (permalink / raw)
Cc: linux-kernel, linux-security-module, tpmdd-devel, Kent Yoder
The following changes since commit ecefbd94b834fa32559d854646d777c56749ef1c:
Merge tag 'kvm-3.7-1' of git://git.kernel.org/pub/scm/virt/kvm/kvm (2012-10-04 09:30:33 -0700)
are available in the git repository at:
git://github.com/shpedoikal/linux.git tpmdd-fixes-v3.6
for you to fetch changes up to 1631cfb7cee28388b04aef6c0a73050f6fd76e4d:
driver/char/tpm: fix regression causesd by ppi (2012-10-10 09:50:56 -0500)
----------------------------------------------------------------
Gang Wei (1):
driver/char/tpm: fix regression causesd by ppi
drivers/char/tpm/tpm.c | 3 ++-
drivers/char/tpm/tpm.h | 9 +++++++--
drivers/char/tpm/tpm_ppi.c | 18 ++++++++++--------
3 files changed, 19 insertions(+), 11 deletions(-)
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2012-10-10 15:06 Kent Yoder
@ 2012-10-10 15:12 ` Kent Yoder
0 siblings, 0 replies; 348+ messages in thread
From: Kent Yoder @ 2012-10-10 15:12 UTC (permalink / raw)
To: Kent Yoder; +Cc: linux-kernel, linux-security-module, tpmdd-devel
Please ignore.
On Wed, Oct 10, 2012 at 10:06:53AM -0500, Kent Yoder wrote:
> The following changes since commit ecefbd94b834fa32559d854646d777c56749ef1c:
>
> Merge tag 'kvm-3.7-1' of git://git.kernel.org/pub/scm/virt/kvm/kvm (2012-10-04 09:30:33 -0700)
>
> are available in the git repository at:
>
>
> git://github.com/shpedoikal/linux.git tpmdd-fixes-v3.6
>
> for you to fetch changes up to 1631cfb7cee28388b04aef6c0a73050f6fd76e4d:
>
> driver/char/tpm: fix regression causesd by ppi (2012-10-10 09:50:56 -0500)
>
> ----------------------------------------------------------------
> Gang Wei (1):
> driver/char/tpm: fix regression causesd by ppi
>
> drivers/char/tpm/tpm.c | 3 ++-
> drivers/char/tpm/tpm.h | 9 +++++++--
> drivers/char/tpm/tpm_ppi.c | 18 ++++++++++--------
> 3 files changed, 19 insertions(+), 11 deletions(-)
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2012-10-04 16:50 Andrea Arcangeli
2012-10-04 18:17 ` your mail Christoph Lameter
0 siblings, 1 reply; 348+ messages in thread
From: Andrea Arcangeli @ 2012-10-04 16:50 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-kernel, linux-mm, Linus Torvalds, Andrew Morton,
Peter Zijlstra, Ingo Molnar, Mel Gorman, Hugh Dickins,
Rik van Riel, Johannes Weiner, Hillf Danton, Andrew Jones,
Dan Smith, Thomas Gleixner, Paul Turner, Suresh Siddha,
Mike Galbraith, Paul E. McKenney
Subject: Re: [PATCH 29/33] autonuma: page_autonuma
Reply-To:
In-Reply-To: <0000013a2c223da2-632aa43e-21f8-4abd-a0ba-2e1b49881e3a-000000@email.amazonses.com>
Hi Christoph,
On Thu, Oct 04, 2012 at 02:16:14PM +0000, Christoph Lameter wrote:
> On Thu, 4 Oct 2012, Andrea Arcangeli wrote:
>
> > Move the autonuma_last_nid from the "struct page" to a separate
> > page_autonuma data structure allocated in the memsection (with
> > sparsemem) or in the pgdat (with flatmem).
>
> Note that there is a available word in struct page before the autonuma
> patches on x86_64 with CONFIG_HAVE_ALIGNED_STRUCT_PAGE.
>
> In fact the page_autonuma fills up the structure to nicely fit in one 64
> byte cacheline.
Good point indeed.
So we could drop page_autonuma by creating a CONFIG_SLUB=y dependency
(AUTONUMA wouldn't be available in the kernel config if SLAB=y, and it
also wouldn't be available on 32bit archs but the latter isn't a
problem).
I think it's a reasonable alternative to page_autonuma. Certainly it
looks more appealing than taking over 16 precious bits from
page->flags. There are still pros and cons. I'm neutral on it so more
comments would be welcome ;).
Andrea
PS. randomly moved some in Cc over to Bcc as I overflowed the max
header allowed on linux-kernel oops!
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2012-10-04 16:50 Andrea Arcangeli
@ 2012-10-04 18:17 ` Christoph Lameter
0 siblings, 0 replies; 348+ messages in thread
From: Christoph Lameter @ 2012-10-04 18:17 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: linux-kernel, linux-mm, Linus Torvalds, Andrew Morton,
Peter Zijlstra, Ingo Molnar, Mel Gorman, Hugh Dickins,
Rik van Riel, Johannes Weiner, Hillf Danton, Andrew Jones,
Dan Smith, Thomas Gleixner, Paul Turner, Suresh Siddha,
Mike Galbraith, Paul E. McKenney
On Thu, 4 Oct 2012, Andrea Arcangeli wrote:
> So we could drop page_autonuma by creating a CONFIG_SLUB=y dependency
> (AUTONUMA wouldn't be available in the kernel config if SLAB=y, and it
> also wouldn't be available on 32bit archs but the latter isn't a
> problem).
Nope it should depend on page struct alignment. Other kernel subsystems
may be depeding on page struct alignment in the future (and some other
arches may already have that requirement)
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2012-08-03 17:43 Tejun Heo
2012-08-08 16:39 ` your mail Tejun Heo
0 siblings, 1 reply; 348+ messages in thread
From: Tejun Heo @ 2012-08-03 17:43 UTC (permalink / raw)
To: linux-kernel
Cc: torvalds, akpm, padovan, marcel, peterz, mingo, davem,
dougthompson, ibm-acpi, cbou, rui.zhang, tomi.valkeinen
delayed_work has been annoyingly missing the mechanism to modify timer
of a pending delayed_work - ie. mod_timer() counterpart. delayed_work
users have been working around this using several methods - using an
explicit timer + work item, messing directly with delayed_work->timer,
and canceling before re-queueing, all of which are error-prone and/or
ugly.
Gustavo Padovan posted a RFC implementation[1] of mod_delayed_work() a
while back but it wasn't complete. To properly implement
mod_delayed_work[_on](), it should be able to steal pending work items
which may be on timer or worklist or anywhere inbetween. This is
similar to what __cancel_work_timer() does but it turns out that there
are a lot of holes around this area and try_to_grab_pending() needs
considerable amount of work to be used for other purposes too.
This patchset improves canceling and try_to_grab_pending(), use it to
implement mod_delayed_work[_on](), convert easy ones, and drop
__cancel_delayed_work_sync() which doesn't have relevant users
afterwards.
Changes from the first take[L] are,
* All updated patches rolled into the series and Acked-by's added.a
* Tomi Valkeinen pointed out that mod_delayed_work() can't be called
from IRQ handlers and thus can't replace __cancel_delayed_work()
users. __cancel_delayed_work() users dropped from conversion. This
will be handled by a future patchset.
* Ensuring preemtion is disabled across PENDING manipulation doesn't
make try_to_grab_pending() safe to use from bh context and making it
impossible to replace even cancel_delayed_work() users. Whole patch
series updated so that IRQ is disabled across PENDING manipulation
instead. As most operations had to grab gcwq->lock anyway, this
doesn't add extra IRQ toggling.
* try_to_grab_pending() and __cancel_work_timer() updated to take bool
@is_dwork instead of @timer and disable IRQ on successful return.
This patchset contains the following fourteen patches.
0001-workqueue-reorder-queueing-functions-so-that-_on-var.patch
0002-workqueue-make-queueing-functions-return-bool.patch
0003-workqueue-add-missing-smp_wmb-in-process_one_work.patch
0004-workqueue-disable-irq-while-manipulating-PENDING.patch
0005-workqueue-set-delayed_work-timer-function-on-initial.patch
0006-workqueue-unify-local-CPU-queueing-handling.patch
0007-workqueue-fix-zero-delay-handling-of-queue_delayed_w.patch
0008-workqueue-move-try_to_grab_pending-upwards.patch
0009-workqueue-introduce-WORK_OFFQ_FLAG_.patch
0010-workqueue-factor-out-__queue_delayed_work-from-queue.patch
0011-workqueue-reorganize-try_to_grab_pending-and-__cance.patch
0012-workqueue-mark-a-work-item-being-canceled-as-such.patch
0013-workqueue-implement-mod_delayed_work-_on.patch
0014-workqueue-use-mod_delayed_work-instead-of-cancel-que.patch
0001-0003 are preparatory.
0004 removes the possibility of cancel_sync spinning for extended
period of time while another task holding PENDING is preempted or
interrupted.
0005-0007 clean up local queueing handling.
0008-0011 prepare for try_to_grab_pending() improvements.
0012 makes try_to_grab_pending() distinguish transient failure which
can be safely busy-retried and failure because the work item is being
canceled, which may take arbitrary amount of time.
0013 uses the improved try_to_grab_pending() to implement
mod_delayed_work[_on]().
0014 converts cancel + queue sequences to mod_delayed_work().
This patchset is also available at the following git branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git review-wq-mod_delayed
If nobody objects, I'd like to route this series through wq/for-3.7.
Changes to other subsystems are fairly localized and conflicts, if
they occur, shouldn't be too painful to handle.
Although this ends up adding ~130 LOC, it contains a lot more
documentation, converted only the apparent ones, and IMHO is
worthwhile to have regardless as it removes an annoyance which is
pretty easy to encounter while using delayed_work.
Thanks.
block/genhd.c | 6
drivers/edac/edac_mc.c | 17
drivers/infiniband/core/addr.c | 4
drivers/infiniband/hw/nes/nes_hw.c | 6
drivers/infiniband/hw/nes/nes_nic.c | 5
drivers/net/wireless/ipw2x00/ipw2100.c | 8
drivers/net/wireless/zd1211rw/zd_usb.c | 3
drivers/platform/x86/thinkpad_acpi.c | 20
drivers/power/charger-manager.c | 9
drivers/power/ds2760_battery.c | 9
drivers/power/jz4740-battery.c | 6
drivers/thermal/thermal_sys.c | 15
fs/afs/callback.c | 4
fs/afs/server.c | 10
fs/afs/vlocation.c | 14
fs/nfs/nfs4renewd.c | 3
include/linux/workqueue.h | 47 +-
kernel/workqueue.c | 732 ++++++++++++++++++++-------------
net/core/dst.c | 4
net/rfkill/input.c | 3
20 files changed, 526 insertions(+), 399 deletions(-)
--
tejun
[1] http://thread.gmane.org/gmane.linux.kernel/1159922
[L] http://thread.gmane.org/gmane.linux.kernel/1334546
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2012-08-03 17:43 Tejun Heo
@ 2012-08-08 16:39 ` Tejun Heo
0 siblings, 0 replies; 348+ messages in thread
From: Tejun Heo @ 2012-08-08 16:39 UTC (permalink / raw)
To: linux-kernel
Cc: torvalds, akpm, padovan, marcel, peterz, mingo, davem,
dougthompson, ibm-acpi, cbou, rui.zhang, tomi.valkeinen
On Fri, Aug 03, 2012 at 10:43:45AM -0700, Tejun Heo wrote:
> delayed_work has been annoyingly missing the mechanism to modify timer
> of a pending delayed_work - ie. mod_timer() counterpart. delayed_work
> users have been working around this using several methods - using an
> explicit timer + work item, messing directly with delayed_work->timer,
> and canceling before re-queueing, all of which are error-prone and/or
> ugly.
>
> Gustavo Padovan posted a RFC implementation[1] of mod_delayed_work() a
> while back but it wasn't complete. To properly implement
> mod_delayed_work[_on](), it should be able to steal pending work items
> which may be on timer or worklist or anywhere inbetween. This is
> similar to what __cancel_work_timer() does but it turns out that there
> are a lot of holes around this area and try_to_grab_pending() needs
> considerable amount of work to be used for other purposes too.
>
> This patchset improves canceling and try_to_grab_pending(), use it to
> implement mod_delayed_work[_on](), convert easy ones, and drop
> __cancel_delayed_work_sync() which doesn't have relevant users
> afterwards.
Applied to wq/for-3.7.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2012-02-21 15:39 Yang Honggang
2012-02-21 11:34 ` your mail Hans J. Koch
0 siblings, 1 reply; 348+ messages in thread
From: Yang Honggang @ 2012-02-21 15:39 UTC (permalink / raw)
To: linux-kernel; +Cc: hjk
hi, everyone
Is there a mail list dedicated for UIO (userspace I/O)?
I want to contribute to UIO but did not find the right
mail list.
thx,
Joseph
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2012-02-21 15:39 Yang Honggang
@ 2012-02-21 11:34 ` Hans J. Koch
0 siblings, 0 replies; 348+ messages in thread
From: Hans J. Koch @ 2012-02-21 11:34 UTC (permalink / raw)
To: Yang Honggang; +Cc: linux-kernel, hjk
On Tue, Feb 21, 2012 at 10:39:18AM -0500, Yang Honggang wrote:
> hi, everyone
Please give your mail a proper subject line before posting.
If you talk about UIO, it should start with uio:
Otherwise, people won't read it and just send it to /dev/null.
>
> Is there a mail list dedicated for UIO (userspace I/O)?
No, there's not enough mail traffic to justify that.
> I want to contribute to UIO but did not find the right
> mail list.
Please send your contribution to LKML and Cc: me and Greg
Kroah-Hartman. If you change an existing driver, also Cc:
the author of that driver.
Thanks,
Hans
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2012-02-12 0:21 Richard Weinberger
2012-02-12 0:25 ` your mail Jesper Juhl
` (2 more replies)
0 siblings, 3 replies; 348+ messages in thread
From: Richard Weinberger @ 2012-02-12 0:21 UTC (permalink / raw)
To: linux-kernel
Cc: user-mode-linux-devel, viro, akpm, alan, gregkh, Richard Weinberger
Can you please review this patch?
Thanks,
//richard
---
>From d8f5e7953def150bcc1e6a39dbbe589f1c68bcbd Mon Sep 17 00:00:00 2001
From: Richard Weinberger <richard@nod.at>
Date: Sun, 12 Feb 2012 01:12:49 +0100
Subject: [PATCH] um: Use tty_port
UML's line driver has to use tty_port.
Signed-off-by: Richard Weinberger <richard@nod.at>
---
arch/um/drivers/line.c | 212 +++++++++++---------------------------
arch/um/drivers/line.h | 13 ++-
arch/um/drivers/ssl.c | 16 +++-
arch/um/drivers/stdio_console.c | 14 ++-
4 files changed, 94 insertions(+), 161 deletions(-)
diff --git a/arch/um/drivers/line.c b/arch/um/drivers/line.c
index c1cf220..c789748 100644
--- a/arch/um/drivers/line.c
+++ b/arch/um/drivers/line.c
@@ -19,19 +19,29 @@ static irqreturn_t line_interrupt(int irq, void *data)
{
struct chan *chan = data;
struct line *line = chan->line;
+ struct tty_struct *tty;
+
+ if (line) {
+ tty = tty_port_tty_get(&line->port);
+ chan_interrupt(&line->chan_list, &line->task, tty, irq);
+ tty_kref_put(tty);
+ }
- if (line)
- chan_interrupt(&line->chan_list, &line->task, line->tty, irq);
return IRQ_HANDLED;
}
static void line_timer_cb(struct work_struct *work)
{
struct line *line = container_of(work, struct line, task.work);
+ struct tty_struct *tty;
- if (!line->throttled)
- chan_interrupt(&line->chan_list, &line->task, line->tty,
+ if (!line->throttled) {
+ tty = tty_port_tty_get(&line->port);
+ chan_interrupt(&line->chan_list, &line->task, tty,
line->driver->read_irq);
+
+ tty_kref_put(tty);
+ }
}
/*
@@ -228,92 +238,6 @@ void line_set_termios(struct tty_struct *tty, struct ktermios * old)
/* nothing */
}
-static const struct {
- int cmd;
- char *level;
- char *name;
-} tty_ioctls[] = {
- /* don't print these, they flood the log ... */
- { TCGETS, NULL, "TCGETS" },
- { TCSETS, NULL, "TCSETS" },
- { TCSETSW, NULL, "TCSETSW" },
- { TCFLSH, NULL, "TCFLSH" },
- { TCSBRK, NULL, "TCSBRK" },
-
- /* general tty stuff */
- { TCSETSF, KERN_DEBUG, "TCSETSF" },
- { TCGETA, KERN_DEBUG, "TCGETA" },
- { TIOCMGET, KERN_DEBUG, "TIOCMGET" },
- { TCSBRKP, KERN_DEBUG, "TCSBRKP" },
- { TIOCMSET, KERN_DEBUG, "TIOCMSET" },
-
- /* linux-specific ones */
- { TIOCLINUX, KERN_INFO, "TIOCLINUX" },
- { KDGKBMODE, KERN_INFO, "KDGKBMODE" },
- { KDGKBTYPE, KERN_INFO, "KDGKBTYPE" },
- { KDSIGACCEPT, KERN_INFO, "KDSIGACCEPT" },
-};
-
-int line_ioctl(struct tty_struct *tty, unsigned int cmd,
- unsigned long arg)
-{
- int ret;
- int i;
-
- ret = 0;
- switch(cmd) {
-#ifdef TIOCGETP
- case TIOCGETP:
- case TIOCSETP:
- case TIOCSETN:
-#endif
-#ifdef TIOCGETC
- case TIOCGETC:
- case TIOCSETC:
-#endif
-#ifdef TIOCGLTC
- case TIOCGLTC:
- case TIOCSLTC:
-#endif
- /* Note: these are out of date as we now have TCGETS2 etc but this
- whole lot should probably go away */
- case TCGETS:
- case TCSETSF:
- case TCSETSW:
- case TCSETS:
- case TCGETA:
- case TCSETAF:
- case TCSETAW:
- case TCSETA:
- case TCXONC:
- case TCFLSH:
- case TIOCOUTQ:
- case TIOCINQ:
- case TIOCGLCKTRMIOS:
- case TIOCSLCKTRMIOS:
- case TIOCPKT:
- case TIOCGSOFTCAR:
- case TIOCSSOFTCAR:
- return -ENOIOCTLCMD;
-#if 0
- case TCwhatever:
- /* do something */
- break;
-#endif
- default:
- for (i = 0; i < ARRAY_SIZE(tty_ioctls); i++)
- if (cmd == tty_ioctls[i].cmd)
- break;
- if (i == ARRAY_SIZE(tty_ioctls)) {
- printk(KERN_ERR "%s: %s: unknown ioctl: 0x%x\n",
- __func__, tty->name, cmd);
- }
- ret = -ENOIOCTLCMD;
- break;
- }
- return ret;
-}
-
void line_throttle(struct tty_struct *tty)
{
struct line *line = tty->driver_data;
@@ -343,7 +267,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
{
struct chan *chan = data;
struct line *line = chan->line;
- struct tty_struct *tty = line->tty;
+ struct tty_struct *tty = tty_port_tty_get(&line->port);
int err;
/*
@@ -354,6 +278,9 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
spin_lock(&line->lock);
err = flush_buffer(line);
if (err == 0) {
+ tty_kref_put(tty);
+
+ spin_unlock(&line->lock);
return IRQ_NONE;
} else if (err < 0) {
line->head = line->buffer;
@@ -365,9 +292,12 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
return IRQ_NONE;
tty_wakeup(tty);
+ tty_kref_put(tty);
return IRQ_HANDLED;
}
+static const struct tty_port_operations line_port_ops;
+
int line_setup_irq(int fd, int input, int output, struct line *line, void *data)
{
const struct line_driver *driver = line->driver;
@@ -404,27 +334,27 @@ int line_setup_irq(int fd, int input, int output, struct line *line, void *data)
* first open or last close. Otherwise, open and close just return.
*/
-int line_open(struct line *lines, struct tty_struct *tty)
+int line_open(struct tty_struct *tty, struct file *filp)
{
- struct line *line = &lines[tty->index];
- int err = -ENODEV;
+ struct line *line = tty->driver_data;
+ return tty_port_open(&line->port, tty, filp);
+}
- spin_lock(&line->count_lock);
- if (!line->valid)
- goto out_unlock;
+int line_install(struct tty_driver *driver, struct tty_struct *tty, struct line *line)
+{
+ int ret = tty_init_termios(tty);
- err = 0;
- if (line->count++)
- goto out_unlock;
+ if (ret)
+ return ret;
- BUG_ON(tty->driver_data);
+ tty_driver_kref_get(driver);
+ tty->count++;
tty->driver_data = line;
- line->tty = tty;
+ driver->ttys[tty->index] = tty;
- spin_unlock(&line->count_lock);
- err = enable_chan(line);
- if (err) /* line_close() will be called by our caller */
- return err;
+ ret = enable_chan(line);
+ if (ret)
+ return ret;
INIT_DELAYED_WORK(&line->task, line_timer_cb);
@@ -437,48 +367,36 @@ int line_open(struct line *lines, struct tty_struct *tty)
&tty->winsize.ws_col);
return 0;
-
-out_unlock:
- spin_unlock(&line->count_lock);
- return err;
}
static void unregister_winch(struct tty_struct *tty);
-void line_close(struct tty_struct *tty, struct file * filp)
+void line_cleanup(struct tty_struct *tty)
{
struct line *line = tty->driver_data;
- /*
- * If line_open fails (and tty->driver_data is never set),
- * tty_open will call line_close. So just return in this case.
- */
- if (line == NULL)
- return;
-
- /* We ignore the error anyway! */
- flush_buffer(line);
-
- spin_lock(&line->count_lock);
- BUG_ON(!line->valid);
-
- if (--line->count)
- goto out_unlock;
-
- line->tty = NULL;
- tty->driver_data = NULL;
-
- spin_unlock(&line->count_lock);
-
if (line->sigio) {
unregister_winch(tty);
line->sigio = 0;
}
- return;
+ tty->driver_data = NULL;
+}
+
+void line_close(struct tty_struct *tty, struct file * filp)
+{
+ struct line *line = tty->driver_data;
+
+ if (!line)
+ return;
+
+ tty_port_close(&line->port, tty, filp);
+}
-out_unlock:
- spin_unlock(&line->count_lock);
+void line_hangup(struct tty_struct *tty)
+{
+ struct line *line = tty->driver_data;
+ tty_port_hangup(&line->port);
}
void close_lines(struct line *lines, int nlines)
@@ -495,13 +413,6 @@ static int setup_one_line(struct line *lines, int n, char *init, int init_prio,
struct line *line = &lines[n];
int err = -EINVAL;
- spin_lock(&line->count_lock);
-
- if (line->count) {
- *error_out = "Device is already open";
- goto out;
- }
-
if (line->init_pri <= init_prio) {
line->init_pri = init_prio;
if (!strcmp(init, "none"))
@@ -512,8 +423,7 @@ static int setup_one_line(struct line *lines, int n, char *init, int init_prio,
}
}
err = 0;
-out:
- spin_unlock(&line->count_lock);
+
return err;
}
@@ -598,6 +508,7 @@ int line_get_config(char *name, struct line *lines, unsigned int num, char *str,
struct line *line;
char *end;
int dev, n = 0;
+ struct tty_struct *tty;
dev = simple_strtoul(name, &end, 0);
if ((*end != '\0') || (end == name)) {
@@ -612,13 +523,15 @@ int line_get_config(char *name, struct line *lines, unsigned int num, char *str,
line = &lines[dev];
- spin_lock(&line->count_lock);
+ tty = tty_port_tty_get(&line->port);
+
if (!line->valid)
CONFIG_CHUNK(str, size, n, "none", 1);
- else if (line->tty == NULL)
+ else if (tty == NULL)
CONFIG_CHUNK(str, size, n, line->init_str, 1);
else n = chan_config_string(&line->chan_list, str, size, error_out);
- spin_unlock(&line->count_lock);
+
+ tty_kref_put(tty);
return n;
}
@@ -678,8 +591,8 @@ struct tty_driver *register_lines(struct line_driver *line_driver,
}
for(i = 0; i < nlines; i++) {
- if (!lines[i].valid)
- tty_unregister_device(driver, i);
+ tty_port_init(&lines[i].port);
+ lines[i].port.ops = &line_port_ops;
}
mconsole_register_dev(&line_driver->mc);
@@ -805,7 +718,6 @@ void register_winch_irq(int fd, int tty_fd, int pid, struct tty_struct *tty,
.pid = pid,
.tty = tty,
.stack = stack });
-
if (um_request_irq(WINCH_IRQ, fd, IRQ_READ, winch_interrupt,
IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
"winch", winch) < 0) {
diff --git a/arch/um/drivers/line.h b/arch/um/drivers/line.h
index 63df3ca..54adfc6 100644
--- a/arch/um/drivers/line.h
+++ b/arch/um/drivers/line.h
@@ -31,9 +31,8 @@ struct line_driver {
};
struct line {
- struct tty_struct *tty;
- spinlock_t count_lock;
- unsigned long count;
+ struct tty_port port;
+
int valid;
char *init_str;
@@ -59,15 +58,17 @@ struct line {
};
#define LINE_INIT(str, d) \
- { .count_lock = __SPIN_LOCK_UNLOCKED((str).count_lock), \
- .init_str = str, \
+ { .init_str = str, \
.init_pri = INIT_STATIC, \
.valid = 1, \
.lock = __SPIN_LOCK_UNLOCKED((str).lock), \
.driver = d }
extern void line_close(struct tty_struct *tty, struct file * filp);
-extern int line_open(struct line *lines, struct tty_struct *tty);
+extern int line_open(struct tty_struct *tty, struct file *filp);
+extern int line_install(struct tty_driver *driver, struct tty_struct *tty, struct line *line);
+extern void line_cleanup(struct tty_struct *tty);
+extern void line_hangup(struct tty_struct *tty);
extern int line_setup(struct line *lines, unsigned int sizeof_lines,
char *init, char **error_out);
extern int line_write(struct tty_struct *tty, const unsigned char *buf,
diff --git a/arch/um/drivers/ssl.c b/arch/um/drivers/ssl.c
index 9d8c20a..89e4e75 100644
--- a/arch/um/drivers/ssl.c
+++ b/arch/um/drivers/ssl.c
@@ -92,6 +92,7 @@ static int ssl_remove(int n, char **error_out)
error_out);
}
+#if 0
static int ssl_open(struct tty_struct *tty, struct file *filp)
{
int err = line_open(serial_lines, tty);
@@ -103,7 +104,6 @@ static int ssl_open(struct tty_struct *tty, struct file *filp)
return err;
}
-#if 0
static void ssl_flush_buffer(struct tty_struct *tty)
{
return;
@@ -124,8 +124,16 @@ void ssl_hangup(struct tty_struct *tty)
}
#endif
+static int ssl_install(struct tty_driver *driver, struct tty_struct *tty)
+{
+ if (tty->index < NR_PORTS)
+ return line_install(driver, tty, &serial_lines[tty->index]);
+ else
+ return -ENODEV;
+}
+
static const struct tty_operations ssl_ops = {
- .open = ssl_open,
+ .open = line_open,
.close = line_close,
.write = line_write,
.put_char = line_put_char,
@@ -134,9 +142,11 @@ static const struct tty_operations ssl_ops = {
.flush_buffer = line_flush_buffer,
.flush_chars = line_flush_chars,
.set_termios = line_set_termios,
- .ioctl = line_ioctl,
.throttle = line_throttle,
.unthrottle = line_unthrottle,
+ .install = ssl_install,
+ .cleanup = line_cleanup,
+ .hangup = line_hangup,
#if 0
.stop = ssl_stop,
.start = ssl_start,
diff --git a/arch/um/drivers/stdio_console.c b/arch/um/drivers/stdio_console.c
index 088776f..014f3ee 100644
--- a/arch/um/drivers/stdio_console.c
+++ b/arch/um/drivers/stdio_console.c
@@ -97,7 +97,7 @@ static int con_remove(int n, char **error_out)
static int con_open(struct tty_struct *tty, struct file *filp)
{
- int err = line_open(vts, tty);
+ int err = line_open(tty, filp);
if (err)
printk(KERN_ERR "Failed to open console %d, err = %d\n",
tty->index, err);
@@ -105,6 +105,14 @@ static int con_open(struct tty_struct *tty, struct file *filp)
return err;
}
+static int con_install(struct tty_driver *driver, struct tty_struct *tty)
+{
+ if (tty->index < MAX_TTYS)
+ return line_install(driver, tty, &vts[tty->index]);
+ else
+ return -ENODEV;
+}
+
/* Set in an initcall, checked in an exitcall */
static int con_init_done = 0;
@@ -118,9 +126,11 @@ static const struct tty_operations console_ops = {
.flush_buffer = line_flush_buffer,
.flush_chars = line_flush_chars,
.set_termios = line_set_termios,
- .ioctl = line_ioctl,
.throttle = line_throttle,
.unthrottle = line_unthrottle,
+ .cleanup = line_cleanup,
+ .install = con_install,
+ .hangup = line_hangup,
};
static void uml_console_write(struct console *console, const char *string,
--
1.7.7.3
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2012-02-12 0:21 Richard Weinberger
@ 2012-02-12 0:25 ` Jesper Juhl
2012-02-12 1:02 ` Al Viro
2012-02-12 19:11 ` Al Viro
2 siblings, 0 replies; 348+ messages in thread
From: Jesper Juhl @ 2012-02-12 0:25 UTC (permalink / raw)
To: Richard Weinberger
Cc: linux-kernel, user-mode-linux-devel, viro, akpm, alan, gregkh
On Sun, 12 Feb 2012, Richard Weinberger wrote:
> Can you please review this patch?
>
A subject on the mail along with a description of the patch would make
that a great deal easier...
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2012-02-12 0:21 Richard Weinberger
2012-02-12 0:25 ` your mail Jesper Juhl
@ 2012-02-12 1:02 ` Al Viro
2012-02-12 12:40 ` Jiri Slaby
2012-02-12 19:11 ` Al Viro
2 siblings, 1 reply; 348+ messages in thread
From: Al Viro @ 2012-02-12 1:02 UTC (permalink / raw)
To: Richard Weinberger
Cc: linux-kernel, user-mode-linux-devel, akpm, alan, gregkh
On Sun, Feb 12, 2012 at 01:21:10AM +0100, Richard Weinberger wrote:
Not a full review by any means, but...
> +++ b/arch/um/drivers/line.c
> @@ -19,19 +19,29 @@ static irqreturn_t line_interrupt(int irq, void *data)
> {
> struct chan *chan = data;
> struct line *line = chan->line;
> + struct tty_struct *tty;
> +
> + if (line) {
> + tty = tty_port_tty_get(&line->port);
> + chan_interrupt(&line->chan_list, &line->task, tty, irq);
> + tty_kref_put(tty);
> + }
>
> - if (line)
> - chan_interrupt(&line->chan_list, &line->task, line->tty, irq);
> return IRQ_HANDLED;
> }
Is tty_kref_put() safe in interrupt? Here it seems to be OK, but in other
callers... More or less at random: drivers/tty/serial/lantiq.c has it
called from lqasc_rx_int(). It seems to be possible to have it end up
calling ->ops->shutdown() and in this case that'd be lqasc_shutdown().
Which does a bunch of free_irq(), including the ->rx_irq, i.e. the one
we have it called from. Alan?
> @@ -495,13 +413,6 @@ static int setup_one_line(struct line *lines, int n, char *init, int init_prio,
> struct line *line = &lines[n];
> int err = -EINVAL;
>
> - spin_lock(&line->count_lock);
> -
> - if (line->count) {
> - *error_out = "Device is already open";
> - goto out;
> - }
... and similar in line_open() - just what happens if you try to reconfigure
an opened one?
> @@ -612,13 +523,15 @@ int line_get_config(char *name, struct line *lines, unsigned int num, char *str,
>
> line = &lines[dev];
>
> - spin_lock(&line->count_lock);
> + tty = tty_port_tty_get(&line->port);
> +
> if (!line->valid)
> CONFIG_CHUNK(str, size, n, "none", 1);
> - else if (line->tty == NULL)
> + else if (tty == NULL)
> CONFIG_CHUNK(str, size, n, line->init_str, 1);
> else n = chan_config_string(&line->chan_list, str, size, error_out);
> - spin_unlock(&line->count_lock);
> +
> + tty_kref_put(tty);
again, where's the exclusion with config changes?
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2012-02-12 1:02 ` Al Viro
@ 2012-02-12 12:40 ` Jiri Slaby
2012-02-12 19:06 ` Al Viro
0 siblings, 1 reply; 348+ messages in thread
From: Jiri Slaby @ 2012-02-12 12:40 UTC (permalink / raw)
To: Al Viro
Cc: Richard Weinberger, linux-kernel, user-mode-linux-devel, akpm,
alan, gregkh, Jiri Slaby
On 02/12/2012 02:02 AM, Al Viro wrote:
> On Sun, Feb 12, 2012 at 01:21:10AM +0100, Richard Weinberger wrote:
>> +++ b/arch/um/drivers/line.c
>> @@ -19,19 +19,29 @@ static irqreturn_t line_interrupt(int irq, void *data)
>> {
>> struct chan *chan = data;
>> struct line *line = chan->line;
>> + struct tty_struct *tty;
>> +
>> + if (line) {
>> + tty = tty_port_tty_get(&line->port);
>> + chan_interrupt(&line->chan_list, &line->task, tty, irq);
>> + tty_kref_put(tty);
>> + }
>>
>> - if (line)
>> - chan_interrupt(&line->chan_list, &line->task, line->tty, irq);
>> return IRQ_HANDLED;
>> }
>
> Is tty_kref_put() safe in interrupt? Here it seems to be OK, but in other
> callers... More or less at random: drivers/tty/serial/lantiq.c has it
> called from lqasc_rx_int(). It seems to be possible to have it end up
> calling ->ops->shutdown() and in this case that'd be lqasc_shutdown().
> Which does a bunch of free_irq(), including the ->rx_irq, i.e. the one
> we have it called from. Alan?
I'm not Alan, but will reply anyway. Yes, it is safe (unless the driver
does something tricky). In the driver you mention, this is uart_ops,
called from tty_port_operations' ->shutdown. And that's a different from
tty_operations' ->shutdown.
Yes, there are:
* tty->ops
* tty_port->ops
* uart_port->ops
uart_port->ops->shutdown is supposed to tear down interrupts like in
lantiq.c. It is called from tty_port->ops->shutdown. And that one is
allowed to be called only from user context (tty->ops->close and
tty->ops->hangup).
thanks,
--
js
suse labs
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2012-02-12 12:40 ` Jiri Slaby
@ 2012-02-12 19:06 ` Al Viro
2012-02-13 9:40 ` Jiri Slaby
0 siblings, 1 reply; 348+ messages in thread
From: Al Viro @ 2012-02-12 19:06 UTC (permalink / raw)
To: Jiri Slaby
Cc: Richard Weinberger, linux-kernel, user-mode-linux-devel, akpm,
alan, gregkh, Jiri Slaby
On Sun, Feb 12, 2012 at 01:40:47PM +0100, Jiri Slaby wrote:
> > Is tty_kref_put() safe in interrupt? Here it seems to be OK, but in other
> > callers... More or less at random: drivers/tty/serial/lantiq.c has it
> > called from lqasc_rx_int(). It seems to be possible to have it end up
> > calling ->ops->shutdown() and in this case that'd be lqasc_shutdown().
> > Which does a bunch of free_irq(), including the ->rx_irq, i.e. the one
> > we have it called from. Alan?
>
> I'm not Alan, but will reply anyway. Yes, it is safe (unless the driver
> does something tricky). In the driver you mention, this is uart_ops,
> called from tty_port_operations' ->shutdown. And that's a different from
> tty_operations' ->shutdown.
>
> Yes, there are:
> * tty->ops
> * tty_port->ops
> * uart_port->ops
>
> uart_port->ops->shutdown is supposed to tear down interrupts like in
> lantiq.c. It is called from tty_port->ops->shutdown. And that one is
> allowed to be called only from user context (tty->ops->close and
> tty->ops->hangup).
Yecchhh... If I'm reading (and grepping) it right, there are only two
non-default instance of tty_operations ->shutdown() - pty and vt ones.
Lovely... And while we are at it, vt instance is definitely not safe
from interrupts - calls console_lock(). Not that it was relevant in
this case...
It's probably too late in this case, but I would've called that method
->sync_cleanup(). Assuming I'm not misreading its intent and history...
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2012-02-12 19:06 ` Al Viro
@ 2012-02-13 9:40 ` Jiri Slaby
0 siblings, 0 replies; 348+ messages in thread
From: Jiri Slaby @ 2012-02-13 9:40 UTC (permalink / raw)
To: Al Viro
Cc: Jiri Slaby, Richard Weinberger, linux-kernel,
user-mode-linux-devel, akpm, alan, gregkh
On 02/12/2012 08:06 PM, Al Viro wrote:
> Yecchhh... If I'm reading (and grepping) it right, there are only two
> non-default instance of tty_operations ->shutdown() - pty and vt ones.
> Lovely... And while we are at it, vt instance is definitely not safe
> from interrupts - calls console_lock(). Not that it was relevant in
> this case...
Thanks for looking into that. I was too lazy to do that on Sunday.
You're right that it may cause problems. Fortunately vt doesn't refcount
ttys. Hence con_shutdown can be called only from release_tty (close
path) in the user context.
Adding to my TODO list, unless somebody beats me to fix it.
thanks,
--
js
suse labs
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2012-02-12 0:21 Richard Weinberger
2012-02-12 0:25 ` your mail Jesper Juhl
2012-02-12 1:02 ` Al Viro
@ 2012-02-12 19:11 ` Al Viro
2012-02-13 9:15 ` Jiri Slaby
2 siblings, 1 reply; 348+ messages in thread
From: Al Viro @ 2012-02-12 19:11 UTC (permalink / raw)
To: Richard Weinberger
Cc: linux-kernel, user-mode-linux-devel, akpm, alan, gregkh
On Sun, Feb 12, 2012 at 01:21:10AM +0100, Richard Weinberger wrote:
> @@ -343,7 +267,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
> {
> struct chan *chan = data;
> struct line *line = chan->line;
> - struct tty_struct *tty = line->tty;
> + struct tty_struct *tty = tty_port_tty_get(&line->port);
> int err;
>
> /*
> @@ -354,6 +278,9 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
> spin_lock(&line->lock);
> err = flush_buffer(line);
> if (err == 0) {
> + tty_kref_put(tty);
> +
> + spin_unlock(&line->lock);
> return IRQ_NONE;
> } else if (err < 0) {
> line->head = line->buffer;
> @@ -365,9 +292,12 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
> return IRQ_NONE;
>
> tty_wakeup(tty);
> + tty_kref_put(tty);
> return IRQ_HANDLED;
> }
That, BTW, smells ugly. Note that return before the last one has no
tty_kref_put() for a very good reason - it's under if (!tty). And
just as line->tty, port->tty can become NULL, so tty_port_tty_get()
can, indeed, return NULL here. Which makes the first tty_kref_put()
oopsable...
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2012-02-12 19:11 ` Al Viro
@ 2012-02-13 9:15 ` Jiri Slaby
0 siblings, 0 replies; 348+ messages in thread
From: Jiri Slaby @ 2012-02-13 9:15 UTC (permalink / raw)
To: Al Viro
Cc: Richard Weinberger, linux-kernel, user-mode-linux-devel, akpm,
alan, gregkh
On 02/12/2012 08:11 PM, Al Viro wrote:
> On Sun, Feb 12, 2012 at 01:21:10AM +0100, Richard Weinberger wrote:
>
>> @@ -343,7 +267,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>> {
>> struct chan *chan = data;
>> struct line *line = chan->line;
>> - struct tty_struct *tty = line->tty;
>> + struct tty_struct *tty = tty_port_tty_get(&line->port);
>> int err;
>>
>> /*
>> @@ -354,6 +278,9 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>> spin_lock(&line->lock);
>> err = flush_buffer(line);
>> if (err == 0) {
>> + tty_kref_put(tty);
>> +
>> + spin_unlock(&line->lock);
>> return IRQ_NONE;
>> } else if (err < 0) {
>> line->head = line->buffer;
>> @@ -365,9 +292,12 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>> return IRQ_NONE;
>>
>> tty_wakeup(tty);
>> + tty_kref_put(tty);
>> return IRQ_HANDLED;
>> }
>
> That, BTW, smells ugly. Note that return before the last one has no
> tty_kref_put() for a very good reason - it's under if (!tty). And
> just as line->tty, port->tty can become NULL, so tty_port_tty_get()
> can, indeed, return NULL here. Which makes the first tty_kref_put()
> oopsable...
Nope, it is allowed to call tty_kref_put(NULL).
regards,
--
js
suse labs
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <20120110061735.9BD676BA98@mailhub.coreip.homeip.net>]
* Re: your mail
[not found] <20120110061735.9BD676BA98@mailhub.coreip.homeip.net>
@ 2012-01-10 7:45 ` Dmitry Torokhov
0 siblings, 0 replies; 348+ messages in thread
From: Dmitry Torokhov @ 2012-01-10 7:45 UTC (permalink / raw)
To: Milton Miller; +Cc: Che-Liang Chiou, linux-kernel
On Mon, Jan 09, 2012 at 10:17:35PM -0800, Milton Miller wrote:
> Subject Re: [PATCH 1/2] Input: serio_raw - cosmetic fixes
> In-Reply-To: <20120109082412.GC4049@core.coreip.homeip.net>
> References: <20120109082412.GC4049@core.coreip.homeip.net>
> <1325847795-30486-1-git-send-email-clchiou@chromium.org>
> Date: Tue, 10 Jan 2012 00:14:35 -0600
> Subject: (No subject header)
> X-Originating-IP: 71.22.127.106
> Message-ID: <1326176075_1502@mail4.comsite.net>
>
> On Mon, 9 Jan 2012 about 00:24:12 -0800, Dmitry Torokhov wrote:
> > > struct serio_raw_client *client = file->private_data;
> > > struct serio_raw *serio_raw = client->serio_raw;
> > > - unsigned int mask;
> > >
> > > poll_wait(file, &serio_raw->wait, wait);
> > >
> > > - mask = serio_raw->dead ? POLLHUP | POLLERR : POLLOUT | POLLWRNORM;
> > > if (serio_raw->head != serio_raw->tail)
> > > return POLLIN | POLLRDNORM;
> > >
> >
> > This however is not quite correct. I will be applying the patch below
> > instead.
> >
> >
> > diff --git a/drivers/input/serio/serio_raw.c b/drivers/input/serio/serio_raw.c
> > index ca78a89..c2c6ad8 100644
> > --- a/drivers/input/serio/serio_raw.c
> > +++ b/drivers/input/serio/serio_raw.c
> > @@ -237,7 +237,7 @@ static unsigned int serio_raw_poll(struct file *file, poll_table *wait)
> >
> > mask = serio_raw->dead ? POLLHUP | POLLERR : POLLOUT | POLLWRNORM;
> > if (serio_raw->head != serio_raw->tail)
> > - return POLLIN | POLLRDNORM;
> > + mask |= POLLIN | POLLRDNORM;
> >
> > return 0;
>
> doesn't this need to be changed to return mask?
Doh! Of course it does.
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2011-09-21 21:54 jim.cromie
2011-09-26 23:23 ` your mail Greg KH
0 siblings, 1 reply; 348+ messages in thread
From: jim.cromie @ 2011-09-21 21:54 UTC (permalink / raw)
To: jbaron; +Cc: joe, bart.vanassche, greg, linux-kernel
hi all,
this reworked* patchset enhances dynamic-debug with:
- multiple queries on bootline, via ddebug_query='"...", formerly just
1 query was accepted. This also allows cat foo-queries > $CONTROL
to add numerous rules together.
- tolerance to errors in ddebug_query. Formerly, a bad rule would
kill the facility, now it stays up, you can correct the rule without
rebooting.
- pending queries. bootline can enable pr_debugs in an uninstalled
module, by adding 'a' flag. When module is loaded later, pr_debug
callsites are enabled, before module-init is run, so pr_debug can be
used in module-init. Currently pending queries are readable in
$DBGMT/dynamic_debug/pending
- filter flags. flags before the operator [+-=] are used to narrow
selection of callsites. This augments module, filename, function
filters, allowing:
echo p+t > $CONTROL # add TID to ALL enabled sites
echo ml+p > $CONTROL # enable sites marked earlier.
- src-dir relative paths in $CONTROL. Formerly, filenames were
printed with full path, and new rules had to use full path if
basename wasnt enough. Now theyre printed with relative paths, and
relative paths are accepted when writing new rules.
Minor things
- added warn if >1 function, filename, module filter is used. also
fix a pr_err() conditional on verbose.
- '_' (empty) flag added. $CONTROL now says '=_' for disabled
callsites, so your grep command can be more selective than '='
- printing is enabled by p flag only, formerly any flag enabled
callsite. this fix is needed for filter-flags as described above.
- dynamic debug supercedes DEBUG - Formerly ddebug couldnt control
callsites when module had DEBUG 1, now it can. DEBUG 1 now enables
callsites by default, but you can turn them off.
- shrink _ddebug.lineno:24 to 18
lineno:24 allows 16G-lines files to be 'pr_debug'd, which is silly.
Largest in tree is 29k-lines, future additions that large are
*unlikely*. Even allowing for out-of-tree machine-generated code
(which shouldnt need ddebug, right? ;-), 256k-lines should be
enough.
- pr_fmt_dbg() - like pr_fmt(), but used in dynamic_pr_debug().
Allows independent control of the prefix-text added by pr_debug vs
pr_info and others. TBD - Joe Perches had issues with this, maybe
addressed here. Its also at end of set, so can be trivially
excluded from upstream.
- internal ddebug verbosity - this modparam enables several levels of
internal debugging. Previous patchsets used the ddebug facilities
within ddebug (eat your own dogfood) but that was deemed too
aggressive.
Future additions.
- user flags: If we can free up extra bits (32bit is currently tight),
adding user-flags (say: x,y,z) would let users mark groups of
callsites, then enable and disable them in a single operation:
echo module foo +x > $CONTROL
echo module bar +x > $CONTROL
...
echo x+p > $CONTROL
Breakdown:
1-15 prep, cleanups, minor things
16-23 major enhancements, doc
24-26 non-essentials, worth considering, discussing.
If you like, you can also get it from github,
git://github.com/jimc/linux-2.6.git dyndbg/on-driver-core
This is a clone of GregKH's driver-core tree, circa -rc3,
which includes 8/12 of Jason Barons dynamic-debug patches.
Ive added Jason's last 4/12, and my 26 patches.
thanks
Jim Cromie
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH] module: Use binary search in lookup_symbol()
@ 2011-05-17 23:33 Tim Bird
2011-05-18 18:55 ` Alessio Igor Bogani
0 siblings, 1 reply; 348+ messages in thread
From: Tim Bird @ 2011-05-17 23:33 UTC (permalink / raw)
To: Greg KH
Cc: Alessio Igor Bogani, Rusty Russell, Anders Kaseorg, Tim Abbott,
LKML, Linux Embedded, Jason Wessel, Dirk Behme
On 05/17/2011 04:22 PM, Greg KH wrote:
> On Tue, May 17, 2011 at 10:56:03PM +0200, Alessio Igor Bogani wrote:
>> This work was supported by a hardware donation from the CE Linux Forum.
>>
>> Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
>> ---
>
> That's nice, but _why_ do this change? What does it buy us?
>
> Please explain why you make a change, not just who sponsored the change,
> that's not very interesting to developers.
Just a note here on the attribution...
Alessio - you can remove the "hardware donation from CELF" line
after the first submission or so. It doesn't need to be on
every submission of the patch set, and it doesn't need to go into
the commit message for the patch set. We only want it associated
with the patch set somewhere Google-able (like LKML).
That said, I can answer Greg's question. This is to speed up
the symbol resolution on module loading. The last numbers I
saw showed a reduction of about 15-20% for the module load
time, for large-ish modules. Of course this is highly dependent
on the size of the modules, what they do at load time, and how many
symbols are looked up to link them into the kernel.
Alessio - do you have any timings you can share for the speedup?
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
2011-05-17 23:33 [PATCH] module: Use binary search in lookup_symbol() Tim Bird
@ 2011-05-18 18:55 ` Alessio Igor Bogani
2011-05-18 19:22 ` your mail Greg KH
0 siblings, 1 reply; 348+ messages in thread
From: Alessio Igor Bogani @ 2011-05-18 18:55 UTC (permalink / raw)
To: Greg KH, Rusty Russell, Tim Bird, Christoph Hellwig
Cc: Anders Kaseorg, Tim Abbott, LKML, Linux Embedded, Jason Wessel,
Dirk Behme, Alessio Igor Bogani
Dear Mr. Bird, Dear Mr. Kroah-Hartman,
Sorry for my very bad English.
2011/5/18 Tim Bird <tim.bird@am.sony.com>:
[...]
> Alessio - do you have any timings you can share for the speedup?
You can find a little benchmark using ftrace at end of this email:
https://lkml.org/lkml/2011/4/5/341
> On 05/17/2011 04:22 PM, Greg KH wrote:
>> On Tue, May 17, 2011 at 10:56:03PM +0200, Alessio Igor Bogani wrote:
>>> This work was supported by a hardware donation from the CE Linux Forum.
[...]
>> Please explain why you make a change, not just who sponsored the change,
>> that's not very interesting to developers.
You are right. I apologize.
This patch is a missing piece (not essential it is only a further little
optimization) of this little patchset:
https://lkml.org/lkml/2011/4/16/48
Unfortunately I forgot to include this patch in the series (my first error)
then I avoided explaining the changes because I had thought that those were
already enough explained in the cover-letter of the patchset (my second error).
Sorry for my mistakes.
Is this better?
Subject: [PATCH] module: Use binary search in lookup_symbol()
The function is_exported() with its helper function lookup_symbol() are used to
verify if a provided symbol is effectively exported by the kernel or by the
modules. Now that both have their symbols sorted we can replace a linear search
with a binary search which provide a considerably speed-up.
This work was supported by a hardware donation from the CE Linux Forum.
Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
---
kernel/module.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 1e2b657..795bdc7 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2055,11 +2055,8 @@ static const struct kernel_symbol *lookup_symbol(const char *name,
const struct kernel_symbol *start,
const struct kernel_symbol *stop)
{
- const struct kernel_symbol *ks = start;
- for (; ks < stop; ks++)
- if (strcmp(ks->name, name) == 0)
- return ks;
- return NULL;
+ return bsearch(name, start, stop - start,
+ sizeof(struct kernel_symbol), cmp_name);
}
static int is_exported(const char *name, unsigned long value,
--
Thank you very much!
Ciao,
Alessio
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2011-05-18 18:55 ` Alessio Igor Bogani
@ 2011-05-18 19:22 ` Greg KH
2011-05-18 20:35 ` Alessio Igor Bogani
0 siblings, 1 reply; 348+ messages in thread
From: Greg KH @ 2011-05-18 19:22 UTC (permalink / raw)
To: Alessio Igor Bogani
Cc: Rusty Russell, Tim Bird, Christoph Hellwig, Anders Kaseorg,
Tim Abbott, LKML, Linux Embedded, Jason Wessel, Dirk Behme
On Wed, May 18, 2011 at 08:55:25PM +0200, Alessio Igor Bogani wrote:
> Dear Mr. Bird, Dear Mr. Kroah-Hartman,
>
> Sorry for my very bad English.
>
> 2011/5/18 Tim Bird <tim.bird@am.sony.com>:
> [...]
> > Alessio - do you have any timings you can share for the speedup?
>
> You can find a little benchmark using ftrace at end of this email:
> https://lkml.org/lkml/2011/4/5/341
>
> > On 05/17/2011 04:22 PM, Greg KH wrote:
> >> On Tue, May 17, 2011 at 10:56:03PM +0200, Alessio Igor Bogani wrote:
> >>> This work was supported by a hardware donation from the CE Linux Forum.
> [...]
> >> Please explain why you make a change, not just who sponsored the change,
> >> that's not very interesting to developers.
>
> You are right. I apologize.
>
> This patch is a missing piece (not essential it is only a further little
> optimization) of this little patchset:
> https://lkml.org/lkml/2011/4/16/48
>
> Unfortunately I forgot to include this patch in the series (my first error)
> then I avoided explaining the changes because I had thought that those were
> already enough explained in the cover-letter of the patchset (my second error).
>
> Sorry for my mistakes.
>
> Is this better?
>
> Subject: [PATCH] module: Use binary search in lookup_symbol()
>
> The function is_exported() with its helper function lookup_symbol() are used to
> verify if a provided symbol is effectively exported by the kernel or by the
> modules. Now that both have their symbols sorted we can replace a linear search
> with a binary search which provide a considerably speed-up.
>
> This work was supported by a hardware donation from the CE Linux Forum.
>
> Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
Much better, I have no objection to this at all.
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Care to resend it without all the stuff above so someone (Rusty I guess)
can apply it?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2011-05-18 19:22 ` your mail Greg KH
@ 2011-05-18 20:35 ` Alessio Igor Bogani
0 siblings, 0 replies; 348+ messages in thread
From: Alessio Igor Bogani @ 2011-05-18 20:35 UTC (permalink / raw)
To: Greg KH
Cc: Rusty Russell, Tim Bird, Christoph Hellwig, Anders Kaseorg,
Tim Abbott, LKML, Linux Embedded, Jason Wessel, Dirk Behme
Dear Mr. Kroah-Hartman,
2011/5/18 Greg KH <greg@kroah.com>:
[...]
> Care to resend it without all the stuff above so someone (Rusty I guess)
> can apply it?
Sure! It'll follow in few minutes.
Thank you very much!
Ciao,
Alessio
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2011-05-16 9:34 Keshava Munegowda
2011-05-16 9:44 ` your mail Felipe Balbi
0 siblings, 1 reply; 348+ messages in thread
From: Keshava Munegowda @ 2011-05-16 9:34 UTC (permalink / raw)
To: linux-usb, linux-omap, linux-kernel
Cc: Keshava Munegowda, balbi, gadiyar, sameo, parthab
Following 2 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and
EHCI , OHCI irq and base addresses.
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 184 ++++++++++++++++++++++++++++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 153 +++++++++++++++++++++++
2 files changed, 337 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 909a84d..fe9a176 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -84,6 +84,8 @@ static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod;
/* L3 -> L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -3574,6 +3576,185 @@ static struct omap_hwmod omap3xxx_mmc3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap34xx_usb_host_hs__l3_main_2 = {
+ .master = &omap34xx_usb_host_hs_hwmod,
+ .slave = &omap3xxx_l3_main_hwmod,
+ .clk = "core_l3_ick",
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_class_sysconfig omap34xx_usb_host_hs_sysc = {
+ .rev_offs = 0x0000,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_host_hs_hwmod_class = {
+ .name = "usbhs_uhh",
+ .sysc = &omap34xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_masters[] = {
+ &omap34xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_irq_info omap34xx_usb_host_hs_irqs[] = {
+ { .name = "ohci-irq", .irq = 76 },
+ { .name = "ehci-irq", .irq = 77 },
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_host_hs_addrs[] = {
+ {
+ .name = "uhh",
+ .pa_start = 0x48064000,
+ .pa_end = 0x480643ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = "ohci",
+ .pa_start = 0x48064400,
+ .pa_end = 0x480647FF,
+ .flags = ADDR_MAP_ON_INIT
+ },
+ {
+ .name = "ehci",
+ .pa_start = 0x48064800,
+ .pa_end = 0x48064CFF,
+ .flags = ADDR_MAP_ON_INIT
+ }
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_host_hs = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap34xx_usb_host_hs_hwmod,
+ .clk = "l4_ick",
+ .addr = omap34xx_usb_host_hs_addrs,
+ .addr_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
+ .clk = "usbhost_120m_fck",
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f48m_cfg__usb_host_hs = {
+ .clk = "usbhost_48m_fck",
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_host_hs_slaves[] = {
+ &omap34xx_l4_cfg__usb_host_hs,
+ &omap34xx_f128m_cfg__usb_host_hs,
+ &omap34xx_f48m_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_host_hs_hwmod = {
+ .name = "usbhs_uhh",
+ .class = &omap34xx_usb_host_hs_hwmod_class,
+ .mpu_irqs = omap34xx_usb_host_hs_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_irqs),
+ .main_clk = "usbhost_ick",
+ .prcm = {
+ .omap2 = {
+ .module_offs = OMAP3430ES2_USBHOST_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = 0,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = 1,
+ .idlest_stdby_bit = 0,
+ },
+ },
+ .slaves = omap34xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_slaves),
+ .masters = omap34xx_usb_host_hs_masters,
+ .masters_cnt = ARRAY_SIZE(omap34xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
+/*
+ * 'usb_tll_hs' class
+ * usb_tll_hs module is the adapter on the usb_host_hs ports
+ */
+static struct omap_hwmod_class_sysconfig omap34xx_usb_tll_hs_sysc = {
+ .rev_offs = 0x0000,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_usb_tll_hs_hwmod_class = {
+ .name = "usbhs_tll",
+ .sysc = &omap34xx_usb_tll_hs_sysc,
+};
+
+static struct omap_hwmod_irq_info omap34xx_usb_tll_hs_irqs[] = {
+ { .name = "tll-irq", .irq = 78 },
+};
+
+static struct omap_hwmod_addr_space omap34xx_usb_tll_hs_addrs[] = {
+ {
+ .name = "tll",
+ .pa_start = 0x48062000,
+ .pa_end = 0x48062fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_f_cfg__usb_tll_hs = {
+ .clk = "usbtll_fck",
+ .user = OCP_USER_MPU,
+ .flags = OCPIF_SWSUP_IDLE,
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_cfg__usb_tll_hs = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap34xx_usb_tll_hs_hwmod,
+ .clk = "l4_ick",
+ .addr = omap34xx_usb_tll_hs_addrs,
+ .addr_cnt = ARRAY_SIZE(omap34xx_usb_tll_hs_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_usb_tll_hs_slaves[] = {
+ &omap34xx_l4_cfg__usb_tll_hs,
+ &omap34xx_f_cfg__usb_tll_hs,
+};
+
+static struct omap_hwmod omap34xx_usb_tll_hs_hwmod = {
+ .name = "usbhs_tll",
+ .class = &omap34xx_usb_tll_hs_hwmod_class,
+ .mpu_irqs = omap34xx_usb_tll_hs_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap34xx_usb_tll_hs_irqs),
+ .main_clk = "usbtll_ick",
+ .prcm = {
+ .omap2 = {
+ .module_offs = CORE_MOD,
+ .prcm_reg_id = 3,
+ .module_bit = 2,
+ .idlest_reg_id = 3,
+ .idlest_idle_bit = 2,
+ },
+ },
+ .slaves = omap34xx_usb_tll_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap34xx_usb_tll_hs_slaves),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_l3_main_hwmod,
&omap3xxx_l4_core_hwmod,
@@ -3656,6 +3837,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
/* usbotg for am35x */
&am35xx_usbhsotg_hwmod,
+ &omap34xx_usb_host_hs_hwmod,
+ &omap34xx_usb_tll_hs_hwmod,
+
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index abc548a..d7112b0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -66,6 +66,8 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
/*
* Interconnects omap_hwmod structures
@@ -5027,6 +5029,155 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master = &omap44xx_usb_host_hs_hwmod,
+ .slave = &omap44xx_l3_main_2_hwmod,
+ .clk = "l3_div_ck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x0000,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = "usbhs_uhh",
+ .sysc = &omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+ &omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_irq_info omap44xx_usb_host_hs_irqs[] = {
+ { .name = "ohci-irq", .irq = 76 + OMAP44XX_IRQ_GIC_START },
+ { .name = "ehci-irq", .irq = 77 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = "uhh",
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .name = "ohci",
+ .pa_start = 0x4A064800,
+ .pa_end = 0x4A064BFF,
+ .flags = ADDR_MAP_ON_INIT
+ },
+ {
+ .name = "ehci",
+ .pa_start = 0x4A064C00,
+ .pa_end = 0x4A064FFF,
+ .flags = ADDR_MAP_ON_INIT
+ }
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master = &omap44xx_l4_cfg_hwmod,
+ .slave = &omap44xx_usb_host_hs_hwmod,
+ .clk = "l4_div_ck",
+ .addr = omap44xx_usb_host_hs_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+ &omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+ .name = "usbhs_uhh",
+ .class = &omap44xx_usb_host_hs_hwmod_class,
+ .mpu_irqs = omap44xx_usb_host_hs_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_irqs),
+ .main_clk = "usb_host_hs_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_slaves),
+ .masters = omap44xx_usb_host_hs_masters,
+ .masters_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
+ * 'usb_tll_hs' class
+ * usb_tll_hs module is the adapter on the usb_host_hs ports
+ */
+static struct omap_hwmod_class_sysconfig omap44xx_usb_tll_hs_sysc = {
+ .rev_offs = 0x0000,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_usb_tll_hs_hwmod_class = {
+ .name = "usbhs_tll",
+ .sysc = &omap44xx_usb_tll_hs_sysc,
+};
+
+static struct omap_hwmod_irq_info omap44xx_usb_tll_hs_irqs[] = {
+ { .name = "tll-irq", .irq = 78 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_tll_hs_addrs[] = {
+ {
+ .name = "tll",
+ .pa_start = 0x4a062000,
+ .pa_end = 0x4a063fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_tll_hs = {
+ .master = &omap44xx_l4_cfg_hwmod,
+ .slave = &omap44xx_usb_tll_hs_hwmod,
+ .clk = "l4_div_ck",
+ .addr = omap44xx_usb_tll_hs_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_usb_tll_hs_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_tll_hs_slaves[] = {
+ &omap44xx_l4_cfg__usb_tll_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod = {
+ .name = "usbhs_tll",
+ .class = &omap44xx_usb_tll_hs_hwmod_class,
+ .mpu_irqs = omap44xx_usb_tll_hs_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_usb_tll_hs_irqs),
+ .main_clk = "usb_tll_hs_ick",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L3INIT_USB_TLL_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_usb_tll_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_usb_tll_hs_slaves),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
@@ -5173,6 +5324,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_wd_timer2_hwmod,
&omap44xx_wd_timer3_hwmod,
+ &omap44xx_usb_host_hs_hwmod,
+ &omap44xx_usb_tll_hs_hwmod,
NULL,
};
--
1.6.0.4
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2011-05-16 9:34 Keshava Munegowda
@ 2011-05-16 9:44 ` Felipe Balbi
2011-05-16 10:07 ` Munegowda, Keshava
0 siblings, 1 reply; 348+ messages in thread
From: Felipe Balbi @ 2011-05-16 9:44 UTC (permalink / raw)
To: Keshava Munegowda
Cc: linux-usb, linux-omap, linux-kernel, balbi, gadiyar, sameo, parthab
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
Hi,
On Mon, May 16, 2011 at 03:04:20PM +0530, Keshava Munegowda wrote:
> Following 2 hwmod strcuture are added:
> UHH hwmod of usbhs with uhh base address and
> EHCI , OHCI irq and base addresses.
> TLL hwmod of usbhs with the TLL base address and irq.
>
> Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
missing subject line.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2011-05-16 9:44 ` your mail Felipe Balbi
@ 2011-05-16 10:07 ` Munegowda, Keshava
0 siblings, 0 replies; 348+ messages in thread
From: Munegowda, Keshava @ 2011-05-16 10:07 UTC (permalink / raw)
To: balbi; +Cc: linux-usb, linux-omap, linux-kernel, gadiyar, sameo, parthab
On Mon, May 16, 2011 at 3:14 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Mon, May 16, 2011 at 03:04:20PM +0530, Keshava Munegowda wrote:
>> Following 2 hwmod strcuture are added:
>> UHH hwmod of usbhs with uhh base address and
>> EHCI , OHCI irq and base addresses.
>> TLL hwmod of usbhs with the TLL base address and irq.
>>
>> Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
>
> missing subject line.
Ya, I have already correct it and resend this patch [RESEND] [PATCH 1/5]...
Regards
keshava
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2011-01-14 1:14 Omar Ramirez Luna
2011-01-14 4:36 ` your mail Greg KH
0 siblings, 1 reply; 348+ messages in thread
From: Omar Ramirez Luna @ 2011-01-14 1:14 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Felipe Contreras, devel, linux-kernel
Please pull these changes for 2.6.38:
The following changes since commit 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5:
Linux 2.6.37 (2011-01-04 16:50:19 -0800)
are available in the git repository at:
git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git for-gkh-2.6.38
Guzman Lugo, Fernando (1):
staging: tidspbridge: configure full L1 MMU range
Omar Ramirez Luna (1):
staging: tidspbridge: replace mbox callback with notifier_call
drivers/staging/tidspbridge/core/tiomap3430.c | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
Regards,
Omar
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2011-01-14 1:14 Omar Ramirez Luna
@ 2011-01-14 4:36 ` Greg KH
0 siblings, 0 replies; 348+ messages in thread
From: Greg KH @ 2011-01-14 4:36 UTC (permalink / raw)
To: Omar Ramirez Luna; +Cc: Felipe Contreras, devel, linux-kernel
On Thu, Jan 13, 2011 at 07:14:53PM -0600, Omar Ramirez Luna wrote:
> Please pull these changes for 2.6.38:
>
> The following changes since commit 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5:
>
> Linux 2.6.37 (2011-01-04 16:50:19 -0800)
>
> are available in the git repository at:
> git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git for-gkh-2.6.38
>
> Guzman Lugo, Fernando (1):
> staging: tidspbridge: configure full L1 MMU range
>
> Omar Ramirez Luna (1):
> staging: tidspbridge: replace mbox callback with notifier_call
>
> drivers/staging/tidspbridge/core/tiomap3430.c | 15 +++++++--------
> 1 files changed, 7 insertions(+), 8 deletions(-)
You forgot a Subject: line.
Also, as these are just 2 patches, care to just email them so we can
review them?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2011-01-03 16:38 castet.matthieu
2011-01-03 17:03 ` your mail Stanislaw Gruszka
0 siblings, 1 reply; 348+ messages in thread
From: castet.matthieu @ 2011-01-03 16:38 UTC (permalink / raw)
To: linux-kernel, linux-usb; +Cc: stf_xl, tj
Hi,
could you CC me on ueagle-atm.c patches.
>From what I remind we sleep in the workqueue, that's why we couldn't use the
system one (freeze keyboard...). But may be the code changed.
Matthieu
Tejun Heo a écrit :
> With cmwq, there's no reason to use separate workqueues. Drop
> uea_softc->work_q and use system_wq instead. The used work item is
> sync flushed on driver detach.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Stanislaw Gruszka <stf_xl@wp.pl>
> Cc: linux-usb@vger.kernel.org
> ---
> Only compile tested. Please feel free to take it into the subsystem
> tree or simply ack - I'll route it through the wq tree.
>
> Thanks.
>
> drivers/usb/atm/ueagle-atm.c | 19 +++++--------------
> 1 files changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c
> index 44447f5..55c1d3b 100644
> --- a/drivers/usb/atm/ueagle-atm.c
> +++ b/drivers/usb/atm/ueagle-atm.c
> @@ -168,7 +168,6 @@ struct uea_softc {
> union cmv_dsc cmv_dsc;
>
> struct work_struct task;
> - struct workqueue_struct *work_q;
> u16 pageno;
> u16 ovl;
>
> @@ -1879,7 +1878,7 @@ static int uea_start_reset(struct uea_softc *sc)
> /* start loading DSP */
> sc->pageno = 0;
> sc->ovl = 0;
> - queue_work(sc->work_q, &sc->task);
> + schedule_work(&sc->task);
>
> /* wait for modem ready CMV */
> ret = wait_cmv_ack(sc);
> @@ -2091,14 +2090,14 @@ static void uea_schedule_load_page_e1(struct uea_softc
*sc,
> {
> sc->pageno = intr->e1_bSwapPageNo;
> sc->ovl = intr->e1_bOvl >> 4 | intr->e1_bOvl << 4;
> - queue_work(sc->work_q, &sc->task);
> + schedule_work(&sc->task);
> }
>
> static void uea_schedule_load_page_e4(struct uea_softc *sc,
> struct intr_pkt *intr)
> {
> sc->pageno = intr->e4_bSwapPageNo;
> - queue_work(sc->work_q, &sc->task);
> + schedule_work(&sc->task);
> }
>
> /*
> @@ -2170,13 +2169,6 @@ static int uea_boot(struct uea_softc *sc)
>
> init_waitqueue_head(&sc->sync_q);
>
> - sc->work_q = create_workqueue("ueagle-dsp");
> - if (!sc->work_q) {
> - uea_err(INS_TO_USBDEV(sc), "cannot allocate workqueue\n");
> - uea_leaves(INS_TO_USBDEV(sc));
> - return -ENOMEM;
> - }
> -
> if (UEA_CHIP_VERSION(sc) == ADI930)
> load_XILINX_firmware(sc);
>
> @@ -2222,7 +2214,6 @@ err1:
> sc->urb_int = NULL;
> kfree(intr);
> err0:
> - destroy_workqueue(sc->work_q);
> uea_leaves(INS_TO_USBDEV(sc));
> return -ENOMEM;
> }
> @@ -2243,8 +2234,8 @@ static void uea_stop(struct uea_softc *sc)
> kfree(sc->urb_int->transfer_buffer);
> usb_free_urb(sc->urb_int);
>
> - /* stop any pending boot process, when no one can schedule work */
> - destroy_workqueue(sc->work_q);
> + /* flush the work item, when no one can schedule it */
> + flush_work_sync(&sc->task);
>
> if (sc->dsp_firm)
> release_firmware(sc->dsp_firm);
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2011-01-03 16:38 castet.matthieu
@ 2011-01-03 17:03 ` Stanislaw Gruszka
2011-01-04 5:17 ` Tejun Heo
0 siblings, 1 reply; 348+ messages in thread
From: Stanislaw Gruszka @ 2011-01-03 17:03 UTC (permalink / raw)
To: castet.matthieu; +Cc: linux-kernel, linux-usb, stf_xl, tj
On Mon, Jan 03, 2011 at 05:38:00PM +0100, castet.matthieu@free.fr wrote:
> Hi,
>
> could you CC me on ueagle-atm.c patches.
>
> From what I remind we sleep in the workqueue, that's why we couldn't use the
> system one (freeze keyboard...). But may be the code changed.
In case when firmware is not available we can sleep for a few seconds in
work function. That's block keyboard driver who also use common workqueue.
If recent Tejun workqueue rewrite allow to long sleep in work func and
not hurt other workqueue users, patch is ok.
Unfortunately I'm not able to test the patch, my ueagle device was physically
damaged a few months ago.
Stanislaw
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2011-01-03 17:03 ` your mail Stanislaw Gruszka
@ 2011-01-04 5:17 ` Tejun Heo
0 siblings, 0 replies; 348+ messages in thread
From: Tejun Heo @ 2011-01-04 5:17 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: castet.matthieu, linux-kernel, linux-usb, stf_xl
On Mon, Jan 03, 2011 at 06:03:17PM +0100, Stanislaw Gruszka wrote:
> On Mon, Jan 03, 2011 at 05:38:00PM +0100, castet.matthieu@free.fr wrote:
> > could you CC me on ueagle-atm.c patches.
Will try to, but maybe it's a good idea to add a MAINTAINERS entry?
> > From what I remind we sleep in the workqueue, that's why we couldn't use the
> > system one (freeze keyboard...). But may be the code changed.
> In case when firmware is not available we can sleep for a few seconds in
> work function. That's block keyboard driver who also use common workqueue.
> If recent Tejun workqueue rewrite allow to long sleep in work func and
> not hurt other workqueue users, patch is ok.
Yeap, work items can sleep all they want on the system_wq. It won't
delay execution of other work items.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2010-06-13 6:16 Mike Gilks
2010-06-18 23:52 ` your mail Greg KH
0 siblings, 1 reply; 348+ messages in thread
From: Mike Gilks @ 2010-06-13 6:16 UTC (permalink / raw)
To: gregkh, mchehab, julia, joe; +Cc: devel, linux-kernel
Subject:r8192U_core.c Last pass
In-Reply-To:
This is the last patch I can manage for this file.
Everything else to do with checkpatch.pl issues may require an actual developer to look at it.
Mike
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2010-06-13 6:16 Mike Gilks
@ 2010-06-18 23:52 ` Greg KH
0 siblings, 0 replies; 348+ messages in thread
From: Greg KH @ 2010-06-18 23:52 UTC (permalink / raw)
To: Mike Gilks; +Cc: gregkh, mchehab, julia, joe, devel, linux-kernel
On Sun, Jun 13, 2010 at 02:16:47PM +0800, Mike Gilks wrote:
> Subject:r8192U_core.c Last pass
> In-Reply-To:
>
>
> This is the last patch I can manage for this file.
> Everything else to do with checkpatch.pl issues may require an actual developer to look at it.
I have a whole bunch of series of patches from you (one duplicating
Linus's patch, I don't think you ment to send that...) So, which should
I apply?
How about I delete them all and you send me the latest ones that you
want me to apply, as I'm totally confused which is your latest version
and which isn't and I see lots of duplicates.
Sound good?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2010-04-14 12:54 Alan Cox
2010-04-14 23:16 ` your mail Dmitry Torokhov
0 siblings, 1 reply; 348+ messages in thread
From: Alan Cox @ 2010-04-14 12:54 UTC (permalink / raw)
To: linux-i2c, khali, linux-input, linux-kernel
Subject: [FOR COMMENT] cy8ctmg110 for review
From: Samuli Konttila <samuli.konttila@aavamobile.com>
Add support for the cy8ctmg110 capacitive touchscreen used on some embedded
devices.
(Some clean up by Alan Cox)
(No signed off, not yet ready to go in)
---
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 3
drivers/input/touchscreen/cy8ctmg110_ts.c | 521 +++++++++++++++++++++++++++++
3 files changed, 535 insertions(+), 1 deletions(-)
create mode 100644 drivers/input/touchscreen/cy8ctmg110_ts.c
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index b3ba374..89a3eb1 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -591,4 +591,16 @@ config TOUCHSCREEN_TPS6507X
To compile this driver as a module, choose M here: the
module will be called tps6507x_ts.
+config TOUCHSCREEN_CY8CTMG110
+ tristate "cy8ctmg110 touchscreen"
+ depends on I2C
+ help
+ Say Y here if you have a cy8ctmg110 touchscreen capacitive
+ touchscreen
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cy8ctmg110_ts.
+
endif
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index dfb7239..c7acb65 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -1,5 +1,5 @@
#
-# Makefile for the touchscreen drivers.
+# Makefile for the touchscreen drivers.mororor
#
# Each configuration option enables a list of files.
@@ -12,6 +12,7 @@ obj-$(CONFIG_TOUCHSCREEN_AD7879) += ad7879.o
obj-$(CONFIG_TOUCHSCREEN_ADS7846) += ads7846.o
obj-$(CONFIG_TOUCHSCREEN_ATMEL_TSADCC) += atmel_tsadcc.o
obj-$(CONFIG_TOUCHSCREEN_BITSY) += h3600_ts_input.o
+obj-$(CONFIG_TOUCHSCREEN_CY8CTMG110) += cy8ctmg110_ts.o
obj-$(CONFIG_TOUCHSCREEN_DYNAPRO) += dynapro.o
obj-$(CONFIG_TOUCHSCREEN_GUNZE) += gunze.o
obj-$(CONFIG_TOUCHSCREEN_EETI) += eeti_ts.o
diff --git a/drivers/input/touchscreen/cy8ctmg110_ts.c b/drivers/input/touchscreen/cy8ctmg110_ts.c
new file mode 100644
index 0000000..4adbe87
--- /dev/null
+++ b/drivers/input/touchscreen/cy8ctmg110_ts.c
@@ -0,0 +1,521 @@
+/*
+ * cy8ctmg110_ts.c Driver for cypress touch screen controller
+ * Copyright (c) 2009 Aava Mobile
+ *
+ * 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.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/input.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <asm/io.h>
+#include <linux/i2c.h>
+#include <linux/timer.h>
+#include <linux/gpio.h>
+#include <linux/hrtimer.h>
+
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/fs.h>
+#include <asm/ioctl.h>
+#include <asm/uaccess.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/fs.h>
+#include <asm/ioctl.h>
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+
+
+#define CY8CTMG110_DRIVER_NAME "cy8ctmg110"
+
+
+/*HW definations*/
+#define CY8CTMG110_RESET_PIN_GPIO 43
+#define CY8CTMG110_IRQ_PIN_GPIO 59
+#define CY8CTMG110_I2C_ADDR 0x38
+#define CY8CTMG110_I2C_ADDR_EXT 0x39
+#define CY8CTMG110_I2C_ADDR_ 0x2 /*i2c address first sample */
+#define CY8CTMG110_I2C_ADDR__ 53 /*i2c address to FW where irq support missing */
+#define CY8CTMG110_TOUCH_IRQ 21
+#define CY8CTMG110_TOUCH_LENGHT 9787
+#define CY8CTMG110_SCREEN_LENGHT 8424
+
+
+/*Touch coordinates*/
+#define CY8CTMG110_X_MIN 0
+#define CY8CTMG110_Y_MIN 0
+#define CY8CTMG110_X_MAX 864
+#define CY8CTMG110_Y_MAX 480
+
+
+/*cy8ctmg110 registers defination*/
+#define CY8CTMG110_TOUCH_WAKEUP_TIME 0
+#define CY8CTMG110_TOUCH_SLEEP_TIME 2
+#define CY8CTMG110_TOUCH_X1 3
+#define CY8CTMG110_TOUCH_Y1 5
+#define CY8CTMG110_TOUCH_X2 7
+#define CY8CTMG110_TOUCH_Y2 9
+#define CY8CTMG110_FINGERS 11
+#define CY8CTMG110_GESTURE 12
+#define CY8CTMG110_REG_MAX 13
+
+#define CY8CTMG110_POLL_TIMER_DELAY 1000*1000*100
+#define TOUCH_MAX_I2C_FAILS 50
+
+/* Scale factors for coordinates */
+#define X_SCALE_FACTOR 9387/8424
+#define Y_SCALE_FACTOR 97/100
+
+/* For tracing */
+static int g_y_trace_coord = 0;
+module_param(g_y_trace_coord, int, 0600);
+
+/* Polling mode */
+static int polling = 0;
+module_param(polling, int, 0);
+MODULE_PARM_DESC(polling, "Set to enabling polling of the touchscreen");
+
+
+/*
+ * The touch position structure.
+ */
+struct ts_event {
+ int x1;
+ int y1;
+ int x2;
+ int y2;
+ bool event_sended;
+};
+
+/*
+ * The touch driver structure.
+ */
+struct cy8ctmg110 {
+ struct input_dev *input;
+ char phys[32];
+ struct ts_event tc;
+ struct i2c_client *client;
+ bool pending;
+ spinlock_t lock;
+ bool initController;
+ bool sleepmode;
+ int i2c_fail_count;
+ struct hrtimer timer;
+};
+
+/*
+ * cy8ctmg110_poweroff is the routine that is called when touch hardware
+ * will powered off
+ */
+static void cy8ctmg110_power(bool poweron)
+{
+ if (poweron)
+ gpio_direction_output(CY8CTMG110_RESET_PIN_GPIO, 0);
+ else
+ gpio_direction_output(CY8CTMG110_RESET_PIN_GPIO, 1);
+}
+
+/*
+ * cy8ctmg110_write_req write regs to the i2c devices
+ *
+ */
+static int cy8ctmg110_write_req(struct cy8ctmg110 *tsc, unsigned char reg,
+ unsigned char len, unsigned char *value)
+{
+ struct i2c_client *client = tsc->client;
+ unsigned int ret;
+ unsigned char i2c_data[] = { 0, 0, 0, 0, 0, 0 };
+ struct i2c_msg msg[] = {
+ {client->addr, 0, len + 1, i2c_data},
+ };
+
+ i2c_data[0] = reg;
+ memcpy(i2c_data + 1, value, len);
+
+ ret = i2c_transfer(client->adapter, msg, 1);
+ if (ret != 1) {
+ printk("cy8ctmg110 touch : i2c write data cmd failed \n");
+ return ret;
+ }
+ return 0;
+}
+
+/*
+ * cy8ctmg110_read_req read regs from i2c devise
+ *
+ */
+
+static int cy8ctmg110_read_req(struct cy8ctmg110 *tsc,
+ unsigned char *i2c_data, unsigned char len, unsigned char cmd)
+{
+ struct i2c_client *client = tsc->client;
+ unsigned int ret;
+ unsigned char regs_cmd[2] = { 0, 0 };
+ struct i2c_msg msg1[] = {
+ {client->addr, 0, 1, regs_cmd},
+ };
+ struct i2c_msg msg2[] = {
+ {client->addr, I2C_M_RD, len, i2c_data},
+ };
+
+ regs_cmd[0] = cmd;
+
+ /* first write slave position to i2c devices */
+ ret = i2c_transfer(client->adapter, msg1, 1);
+ if (ret != 1) {
+ tsc->i2c_fail_count++;
+ return ret;
+ }
+
+ /* Second read data from position */
+ ret = i2c_transfer(client->adapter, msg2, 1);
+ if (ret != 1) {
+ tsc->i2c_fail_count++;
+ return ret;
+ }
+ return 0;
+}
+
+/*
+ * cy8ctmg110_send_event delevery touch event to the userpace
+ * function use normal input interface
+ */
+static void cy8ctmg110_send_event(void *tsc)
+{
+ struct cy8ctmg110 *ts = tsc;
+ struct input_dev *input = ts->input;
+ u16 x, y;
+ u16 x2, y2;
+
+ x = ts->tc.x1;
+ y = ts->tc.y1;
+
+ if (ts->tc.event_sended == false) {
+ input_report_key(input, BTN_TOUCH, 1);
+ ts->pending = true;
+ x2 = (u16) (y * X_SCALE_FACTOR);
+ y2 = (u16) (x * Y_SCALE_FACTOR);
+ input_report_abs(input, ABS_X, x2);
+ input_report_abs(input, ABS_Y, y2);
+ input_sync(input);
+ if (g_y_trace_coord)
+ printk("cy8ctmg110 touch position X:%d (was = %d) Y:%d (was = %d)\n", x2, y, y2, x);
+ }
+
+}
+
+/*
+ * cy8ctmg110_touch_pos check touch position from i2c devices
+ *
+ */
+static int cy8ctmg110_touch_pos(struct cy8ctmg110 *tsc)
+{
+ unsigned char reg_p[CY8CTMG110_REG_MAX];
+ int x, y;
+
+ memset(reg_p, 0, CY8CTMG110_REG_MAX);
+
+ /*Reading coordinates */
+ if (cy8ctmg110_read_req(tsc, reg_p, 9, CY8CTMG110_TOUCH_X1) != 0)
+ return -EIO;
+
+ y = reg_p[2] << 8 | reg_p[3];
+ x = reg_p[0] << 8 | reg_p[1];
+ /*number of touch */
+ if (reg_p[8] == 0) {
+ if (tsc->pending == true) {
+ struct input_dev *input = tsc->input;
+
+ input_report_key(input, BTN_TOUCH, 0);
+ tsc->tc.event_sended = true;
+ tsc->pending = false;
+ }
+ } else if (tsc->tc.x1 != x || tsc->tc.y1 != y) {
+ tsc->tc.y1 = y;
+ tsc->tc.x1 = x;
+ tsc->tc.event_sended = false;
+ cy8ctmg110_send_event(tsc);
+ }
+ return 0;
+}
+
+/*
+ * if interrupt isn't in use the touch positions can reads by polling
+ *
+ */
+static enum hrtimer_restart cy8ctmg110_timer(struct hrtimer *handle)
+{
+ struct cy8ctmg110 *ts = container_of(handle, struct cy8ctmg110, timer);
+ unsigned long flags;
+
+ spin_lock_irqsave(&ts->lock, flags);
+
+ cy8ctmg110_touch_pos(ts);
+ if (ts->i2c_fail_count < TOUCH_MAX_I2C_FAILS)
+ hrtimer_start(&ts->timer, ktime_set(0, CY8CTMG110_POLL_TIMER_DELAY), HRTIMER_MODE_REL);
+
+ spin_unlock_irqrestore(&ts->lock, flags);
+ return HRTIMER_NORESTART;
+}
+
+/*
+ * cy8ctmg110_init_controller set init value to touchcontroller
+ *
+ */
+static bool cy8ctmg110_set_sleepmode(struct cy8ctmg110 *ts)
+{
+ unsigned char reg_p[3];
+
+ if (ts->sleepmode == true) {
+ reg_p[0] = 0x00;
+ reg_p[1] = 0xff;
+ reg_p[2] = 5;
+ } else {
+ reg_p[0] = 0x10;
+ reg_p[1] = 0xff;
+ reg_p[2] = 0;
+ }
+
+ if (cy8ctmg110_write_req(ts, CY8CTMG110_TOUCH_WAKEUP_TIME, 3, reg_p))
+ return false;
+
+ ts->initController = true;
+ return true;
+}
+
+/*
+ * cy8ctmg110_irq_handler irq handling function
+ *
+ */
+
+static irqreturn_t cy8ctmg110_irq_handler(int irq, void *dev_id)
+{
+ struct cy8ctmg110 *tsc = (struct cy8ctmg110 *) dev_id;
+
+ if (tsc->initController == false) {
+ if (cy8ctmg110_set_sleepmode(tsc) == true)
+ tsc->initController = true;
+ } else
+ cy8ctmg110_touch_pos(tsc);
+
+ /* if interrupt supported in the touch controller
+ timer polling need to stop */
+ tsc->i2c_fail_count = TOUCH_MAX_I2C_FAILS;
+ return IRQ_HANDLED;
+}
+
+
+static int cy8ctmg110_probe(struct i2c_client *client, const struct i2c_device_id *id)
+{
+ struct cy8ctmg110 *ts;
+ struct input_dev *input_dev;
+ int err;
+ client->irq = CY8CTMG110_TOUCH_IRQ;
+
+ if (!i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_READ_WORD_DATA))
+ return -EIO;
+
+ ts = kzalloc(sizeof(struct cy8ctmg110), GFP_KERNEL);
+ input_dev = input_allocate_device();
+
+ if (!ts || !input_dev) {
+ err = -ENOMEM;
+ goto err_free_mem;
+ }
+
+ ts->client = client;
+ i2c_set_clientdata(client, ts);
+
+ ts->input = input_dev;
+ ts->pending = false;
+ ts->sleepmode = false;
+
+ snprintf(ts->phys, sizeof(ts->phys), "%s/input0",
+ dev_name(&client->dev));
+
+ input_dev->name = CY8CTMG110_DRIVER_NAME " Touchscreen";
+ input_dev->phys = ts->phys;
+ input_dev->id.bustype = BUS_I2C;
+
+ spin_lock_init(&ts->lock);
+
+ input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP) |
+ BIT_MASK(EV_REL) | BIT_MASK(EV_ABS);
+ input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+
+ input_set_capability(input_dev, EV_KEY, KEY_F);
+
+ input_set_abs_params(input_dev, ABS_X, CY8CTMG110_X_MIN, CY8CTMG110_X_MAX, 0, 0);
+ input_set_abs_params(input_dev, ABS_Y, CY8CTMG110_Y_MIN, CY8CTMG110_Y_MAX, 0, 0);
+
+ err = gpio_request(CY8CTMG110_RESET_PIN_GPIO, NULL);
+
+ if (err) {
+ dev_err(&client->dev, "cy8ctmg110_ts: Unable to request GPIO pin %d.\n",
+ CY8CTMG110_RESET_PIN_GPIO);
+ goto err_free_irq;
+ }
+ cy8ctmg110_power(true);
+
+ ts->initController = false;
+ ts->i2c_fail_count = 0;
+
+ hrtimer_init(&ts->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ ts->timer.function = cy8ctmg110_timer;
+
+ if (polling)
+ hrtimer_start(&ts->timer, ktime_set(10, 0), HRTIMER_MODE_REL);
+
+ /* Can we fall back to polling if these bits fail - something to look
+ at for robustness */
+
+ err = gpio_request(CY8CTMG110_IRQ_PIN_GPIO, "touch_irq_key");
+ if (err < 0) {
+ dev_err(&client->dev,
+ "cy8ctmg110_ts: failed to request GPIO %d, error %d\n",
+ CY8CTMG110_IRQ_PIN_GPIO, err);
+ goto err_free_timer;
+ }
+
+ err = gpio_direction_input(CY8CTMG110_IRQ_PIN_GPIO);
+
+ if (err < 0) {
+ dev_err(&client->dev,
+ "cy8ctmg110_ts: failed to configure input direction for GPIO %d, error %d\n",
+ CY8CTMG110_IRQ_PIN_GPIO, err);
+ goto err_free_gpio;
+ }
+ client->irq = gpio_to_irq(CY8CTMG110_IRQ_PIN_GPIO);
+
+ if (client->irq < 0) {
+ err = client->irq;
+ dev_err(&client->dev,
+ "cy8ctmg110_ts: Unable to get irq number" " for GPIO %d, error %d\n",
+ CY8CTMG110_IRQ_PIN_GPIO, err);
+ goto err_free_gpio;
+ }
+ err = request_irq(client->irq, cy8ctmg110_irq_handler, IRQF_TRIGGER_RISING | IRQF_SHARED, "touch_reset_key", ts);
+ if (err < 0) {
+ dev_err(&client->dev,
+ "cy8ctmg110 irq %d busy? error %d\n",
+ client->irq, err);
+ goto err_free_gpio;
+ }
+
+ err = input_register_device(input_dev);
+ if (!err)
+ return 0;
+err_free_gpio:
+ gpio_free(CY8CTMG110_IRQ_PIN_GPIO);
+err_free_timer:
+ if (polling)
+ hrtimer_cancel(&ts->timer);
+err_free_irq:
+ free_irq(client->irq, ts);
+err_free_mem:
+ input_free_device(input_dev);
+ kfree(ts);
+ return err;
+}
+
+/*
+ * cy8ctmg110_suspend
+ *
+ */
+
+static int cy8ctmg110_suspend(struct i2c_client *client, pm_message_t mesg)
+{
+ if (device_may_wakeup(&client->dev))
+ enable_irq_wake(client->irq);
+
+ return 0;
+}
+
+/*
+ * cy8ctmg110_resume
+ *
+ */
+
+static int cy8ctmg110_resume(struct i2c_client *client)
+{
+ if (device_may_wakeup(&client->dev))
+ disable_irq_wake(client->irq);
+
+ return 0;
+}
+
+/*
+ * cy8ctmg110_remove
+ *
+ */
+
+static int cy8ctmg110_remove(struct i2c_client *client)
+{
+ struct cy8ctmg110 *ts = i2c_get_clientdata(client);
+
+ cy8ctmg110_power(false);
+
+ if (polling)
+ hrtimer_cancel(&ts->timer);
+ free_irq(client->irq, ts);
+ input_unregister_device(ts->input);
+ /* FIXME: Do we need to free the GPIO ? */
+ kfree(ts);
+ return 0;
+}
+
+static struct i2c_device_id cy8ctmg110_idtable[] = {
+ {CY8CTMG110_DRIVER_NAME, 1},
+ {}
+};
+
+MODULE_DEVICE_TABLE(i2c, cy8ctmg110_idtable);
+
+static struct i2c_driver cy8ctmg110_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = CY8CTMG110_DRIVER_NAME,
+ .bus = &i2c_bus_type,
+ },
+ .id_table = cy8ctmg110_idtable,
+ .probe = cy8ctmg110_probe,
+ .remove = cy8ctmg110_remove,
+ .suspend = cy8ctmg110_suspend,
+ .resume = cy8ctmg110_resume,
+};
+
+static int __init cy8ctmg110_init(void)
+{
+ return i2c_add_driver(&cy8ctmg110_driver);
+}
+
+static void __exit cy8ctmg110_exit(void)
+{
+ i2c_del_driver(&cy8ctmg110_driver);
+}
+
+module_init(cy8ctmg110_init);
+module_exit(cy8ctmg110_exit);
+
+MODULE_AUTHOR("Samuli Konttila <samuli.konttila@aavamobile.com>");
+MODULE_DESCRIPTION("cy8ctmg110 TouchScreen Driver");
+MODULE_LICENSE("GPL v2");
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2010-04-14 12:54 Alan Cox
@ 2010-04-14 23:16 ` Dmitry Torokhov
2010-04-15 23:41 ` Rafi Rubin
0 siblings, 1 reply; 348+ messages in thread
From: Dmitry Torokhov @ 2010-04-14 23:16 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-i2c, khali, linux-input, linux-kernel
On Wed, Apr 14, 2010 at 01:54:02PM +0100, Alan Cox wrote:
> Subject: [FOR COMMENT] cy8ctmg110 for review
>
> From: Samuli Konttila <samuli.konttila@aavamobile.com>
>
> Add support for the cy8ctmg110 capacitive touchscreen used on some embedded
> devices.
>
> (Some clean up by Alan Cox)
>
> (No signed off, not yet ready to go in)
> ---
>
> drivers/input/touchscreen/Kconfig | 12 +
> drivers/input/touchscreen/Makefile | 3
> drivers/input/touchscreen/cy8ctmg110_ts.c | 521 +++++++++++++++++++++++++++++
> 3 files changed, 535 insertions(+), 1 deletions(-)
> create mode 100644 drivers/input/touchscreen/cy8ctmg110_ts.c
>
>
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index b3ba374..89a3eb1 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -591,4 +591,16 @@ config TOUCHSCREEN_TPS6507X
> To compile this driver as a module, choose M here: the
> module will be called tps6507x_ts.
>
> +config TOUCHSCREEN_CY8CTMG110
> + tristate "cy8ctmg110 touchscreen"
> + depends on I2C
> + help
> + Say Y here if you have a cy8ctmg110 touchscreen capacitive
> + touchscreen
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called cy8ctmg110_ts.
> +
> endif
> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> index dfb7239..c7acb65 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -1,5 +1,5 @@
> #
> -# Makefile for the touchscreen drivers.
> +# Makefile for the touchscreen drivers.mororor
> #
>
> # Each configuration option enables a list of files.
> @@ -12,6 +12,7 @@ obj-$(CONFIG_TOUCHSCREEN_AD7879) += ad7879.o
> obj-$(CONFIG_TOUCHSCREEN_ADS7846) += ads7846.o
> obj-$(CONFIG_TOUCHSCREEN_ATMEL_TSADCC) += atmel_tsadcc.o
> obj-$(CONFIG_TOUCHSCREEN_BITSY) += h3600_ts_input.o
> +obj-$(CONFIG_TOUCHSCREEN_CY8CTMG110) += cy8ctmg110_ts.o
> obj-$(CONFIG_TOUCHSCREEN_DYNAPRO) += dynapro.o
> obj-$(CONFIG_TOUCHSCREEN_GUNZE) += gunze.o
> obj-$(CONFIG_TOUCHSCREEN_EETI) += eeti_ts.o
> diff --git a/drivers/input/touchscreen/cy8ctmg110_ts.c b/drivers/input/touchscreen/cy8ctmg110_ts.c
> new file mode 100644
> index 0000000..4adbe87
> --- /dev/null
> +++ b/drivers/input/touchscreen/cy8ctmg110_ts.c
> @@ -0,0 +1,521 @@
> +/*
> + * cy8ctmg110_ts.c Driver for cypress touch screen controller
> + * Copyright (c) 2009 Aava Mobile
> + *
> + * 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.
> + *
> + * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/input.h>
> +#include <linux/slab.h>
> +#include <linux/interrupt.h>
> +#include <asm/io.h>
> +#include <linux/i2c.h>
> +#include <linux/timer.h>
> +#include <linux/gpio.h>
> +#include <linux/hrtimer.h>
> +
> +#include <linux/platform_device.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <asm/ioctl.h>
> +#include <asm/uaccess.h>
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <asm/ioctl.h>
> +#include <linux/fs.h>
> +#include <linux/init.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +
> +
> +#define CY8CTMG110_DRIVER_NAME "cy8ctmg110"
> +
> +
> +/*HW definations*/
> +#define CY8CTMG110_RESET_PIN_GPIO 43
> +#define CY8CTMG110_IRQ_PIN_GPIO 59
> +#define CY8CTMG110_I2C_ADDR 0x38
> +#define CY8CTMG110_I2C_ADDR_EXT 0x39
> +#define CY8CTMG110_I2C_ADDR_ 0x2 /*i2c address first sample */
> +#define CY8CTMG110_I2C_ADDR__ 53 /*i2c address to FW where irq support missing */
> +#define CY8CTMG110_TOUCH_IRQ 21
> +#define CY8CTMG110_TOUCH_LENGHT 9787
> +#define CY8CTMG110_SCREEN_LENGHT 8424
> +
> +
> +/*Touch coordinates*/
> +#define CY8CTMG110_X_MIN 0
> +#define CY8CTMG110_Y_MIN 0
> +#define CY8CTMG110_X_MAX 864
> +#define CY8CTMG110_Y_MAX 480
> +
> +
> +/*cy8ctmg110 registers defination*/
> +#define CY8CTMG110_TOUCH_WAKEUP_TIME 0
> +#define CY8CTMG110_TOUCH_SLEEP_TIME 2
> +#define CY8CTMG110_TOUCH_X1 3
> +#define CY8CTMG110_TOUCH_Y1 5
> +#define CY8CTMG110_TOUCH_X2 7
> +#define CY8CTMG110_TOUCH_Y2 9
> +#define CY8CTMG110_FINGERS 11
> +#define CY8CTMG110_GESTURE 12
> +#define CY8CTMG110_REG_MAX 13
> +
> +#define CY8CTMG110_POLL_TIMER_DELAY 1000*1000*100
> +#define TOUCH_MAX_I2C_FAILS 50
> +
> +/* Scale factors for coordinates */
> +#define X_SCALE_FACTOR 9387/8424
> +#define Y_SCALE_FACTOR 97/100
> +
> +/* For tracing */
> +static int g_y_trace_coord = 0;
> +module_param(g_y_trace_coord, int, 0600);
> +
> +/* Polling mode */
> +static int polling = 0;
> +module_param(polling, int, 0);
> +MODULE_PARM_DESC(polling, "Set to enabling polling of the touchscreen");
> +
> +
> +/*
> + * The touch position structure.
> + */
> +struct ts_event {
> + int x1;
> + int y1;
> + int x2;
> + int y2;
> + bool event_sended;
> +};
> +
> +/*
> + * The touch driver structure.
> + */
> +struct cy8ctmg110 {
> + struct input_dev *input;
> + char phys[32];
> + struct ts_event tc;
> + struct i2c_client *client;
> + bool pending;
> + spinlock_t lock;
> + bool initController;
> + bool sleepmode;
> + int i2c_fail_count;
> + struct hrtimer timer;
> +};
> +
> +/*
> + * cy8ctmg110_poweroff is the routine that is called when touch hardware
> + * will powered off
> + */
> +static void cy8ctmg110_power(bool poweron)
> +{
> + if (poweron)
> + gpio_direction_output(CY8CTMG110_RESET_PIN_GPIO, 0);
> + else
> + gpio_direction_output(CY8CTMG110_RESET_PIN_GPIO, 1);
> +}
> +
> +/*
> + * cy8ctmg110_write_req write regs to the i2c devices
> + *
> + */
> +static int cy8ctmg110_write_req(struct cy8ctmg110 *tsc, unsigned char reg,
> + unsigned char len, unsigned char *value)
> +{
> + struct i2c_client *client = tsc->client;
> + unsigned int ret;
> + unsigned char i2c_data[] = { 0, 0, 0, 0, 0, 0 };
> + struct i2c_msg msg[] = {
> + {client->addr, 0, len + 1, i2c_data},
> + };
> +
> + i2c_data[0] = reg;
> + memcpy(i2c_data + 1, value, len);
> +
> + ret = i2c_transfer(client->adapter, msg, 1);
> + if (ret != 1) {
> + printk("cy8ctmg110 touch : i2c write data cmd failed \n");
> + return ret;
> + }
> + return 0;
> +}
> +
> +/*
> + * cy8ctmg110_read_req read regs from i2c devise
> + *
> + */
> +
> +static int cy8ctmg110_read_req(struct cy8ctmg110 *tsc,
> + unsigned char *i2c_data, unsigned char len, unsigned char cmd)
> +{
> + struct i2c_client *client = tsc->client;
> + unsigned int ret;
> + unsigned char regs_cmd[2] = { 0, 0 };
> + struct i2c_msg msg1[] = {
> + {client->addr, 0, 1, regs_cmd},
> + };
> + struct i2c_msg msg2[] = {
> + {client->addr, I2C_M_RD, len, i2c_data},
> + };
> +
> + regs_cmd[0] = cmd;
> +
> + /* first write slave position to i2c devices */
> + ret = i2c_transfer(client->adapter, msg1, 1);
> + if (ret != 1) {
> + tsc->i2c_fail_count++;
> + return ret;
> + }
> +
> + /* Second read data from position */
> + ret = i2c_transfer(client->adapter, msg2, 1);
> + if (ret != 1) {
> + tsc->i2c_fail_count++;
> + return ret;
> + }
> + return 0;
> +}
> +
> +/*
> + * cy8ctmg110_send_event delevery touch event to the userpace
> + * function use normal input interface
> + */
> +static void cy8ctmg110_send_event(void *tsc)
> +{
> + struct cy8ctmg110 *ts = tsc;
> + struct input_dev *input = ts->input;
> + u16 x, y;
> + u16 x2, y2;
> +
> + x = ts->tc.x1;
> + y = ts->tc.y1;
> +
> + if (ts->tc.event_sended == false) {
We set "event_sended" to false immediately before calling
cy8ctmg110_send_event() so I do not see the point of this flag.
> + input_report_key(input, BTN_TOUCH, 1);
> + ts->pending = true;
> + x2 = (u16) (y * X_SCALE_FACTOR);
> + y2 = (u16) (x * Y_SCALE_FACTOR);
> + input_report_abs(input, ABS_X, x2);
> + input_report_abs(input, ABS_Y, y2);
> + input_sync(input);
> + if (g_y_trace_coord)
> + printk("cy8ctmg110 touch position X:%d (was = %d) Y:%d (was = %d)\n", x2, y, y2, x);
Do we really need this? Seems to be early development diagnostic.
> + }
> +
> +}
> +
> +/*
> + * cy8ctmg110_touch_pos check touch position from i2c devices
> + *
> + */
> +static int cy8ctmg110_touch_pos(struct cy8ctmg110 *tsc)
> +{
> + unsigned char reg_p[CY8CTMG110_REG_MAX];
> + int x, y;
> +
> + memset(reg_p, 0, CY8CTMG110_REG_MAX);
> +
> + /*Reading coordinates */
> + if (cy8ctmg110_read_req(tsc, reg_p, 9, CY8CTMG110_TOUCH_X1) != 0)
> + return -EIO;
> +
> + y = reg_p[2] << 8 | reg_p[3];
> + x = reg_p[0] << 8 | reg_p[1];
> + /*number of touch */
> + if (reg_p[8] == 0) {
> + if (tsc->pending == true) {
> + struct input_dev *input = tsc->input;
> +
> + input_report_key(input, BTN_TOUCH, 0);
> + tsc->tc.event_sended = true;
> + tsc->pending = false;
> + }
Just do input_report_key(input, BTN_TOUCH, 0); and let input core take
care of filtering duplicates. This will allow you get rid of bunch of
flags. Also input_sync() is missing here.
> + } else if (tsc->tc.x1 != x || tsc->tc.y1 != y) {
> + tsc->tc.y1 = y;
> + tsc->tc.x1 = x;
> + tsc->tc.event_sended = false;
> + cy8ctmg110_send_event(tsc);
> + }
> + return 0;
> +}
> +
> +/*
> + * if interrupt isn't in use the touch positions can reads by polling
> + *
> + */
> +static enum hrtimer_restart cy8ctmg110_timer(struct hrtimer *handle)
> +{
> + struct cy8ctmg110 *ts = container_of(handle, struct cy8ctmg110, timer);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&ts->lock, flags);
> +
> + cy8ctmg110_touch_pos(ts);
> + if (ts->i2c_fail_count < TOUCH_MAX_I2C_FAILS)
> + hrtimer_start(&ts->timer, ktime_set(0, CY8CTMG110_POLL_TIMER_DELAY), HRTIMER_MODE_REL);
> +
So device simply dies after so many errors?
> + spin_unlock_irqrestore(&ts->lock, flags);
The timer handler is the only user for the spinlock, what is the point?
> + return HRTIMER_NORESTART;
> +}
> +
> +/*
> + *
> + */
> +static bool cy8ctmg110_set_sleepmode(struct cy8ctmg110 *ts)
> +{
> + unsigned char reg_p[3];
> +
> + if (ts->sleepmode == true) {
> + reg_p[0] = 0x00;
> + reg_p[1] = 0xff;
> + reg_p[2] = 5;
> + } else {
> + reg_p[0] = 0x10;
> + reg_p[1] = 0xff;
> + reg_p[2] = 0;
> + }
> +
> + if (cy8ctmg110_write_req(ts, CY8CTMG110_TOUCH_WAKEUP_TIME, 3, reg_p))
> + return false;
> +
> + ts->initController = true;
> + return true;
> +}
> +
> +/*
> + * cy8ctmg110_irq_handler irq handling function
> + *
> + */
> +
> +static irqreturn_t cy8ctmg110_irq_handler(int irq, void *dev_id)
> +{
> + struct cy8ctmg110 *tsc = (struct cy8ctmg110 *) dev_id;
> +
> + if (tsc->initController == false) {
> + if (cy8ctmg110_set_sleepmode(tsc) == true)
> + tsc->initController = true;
> + } else
> + cy8ctmg110_touch_pos(tsc);
Initalizing device from interrupt handler is quite novel concept...
> +
> + /* if interrupt supported in the touch controller
> + timer polling need to stop */
> + tsc->i2c_fail_count = TOUCH_MAX_I2C_FAILS;
> + return IRQ_HANDLED;
> +}
> +
> +
> +static int cy8ctmg110_probe(struct i2c_client *client, const struct i2c_device_id *id)
> +{
> + struct cy8ctmg110 *ts;
> + struct input_dev *input_dev;
> + int err;
> + client->irq = CY8CTMG110_TOUCH_IRQ;
> +
> + if (!i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_READ_WORD_DATA))
> + return -EIO;
> +
> + ts = kzalloc(sizeof(struct cy8ctmg110), GFP_KERNEL);
> + input_dev = input_allocate_device();
> +
> + if (!ts || !input_dev) {
> + err = -ENOMEM;
> + goto err_free_mem;
> + }
> +
> + ts->client = client;
> + i2c_set_clientdata(client, ts);
> +
> + ts->input = input_dev;
> + ts->pending = false;
> + ts->sleepmode = false;
> +
> + snprintf(ts->phys, sizeof(ts->phys), "%s/input0",
> + dev_name(&client->dev));
> +
> + input_dev->name = CY8CTMG110_DRIVER_NAME " Touchscreen";
> + input_dev->phys = ts->phys;
> + input_dev->id.bustype = BUS_I2C;
> +
> + spin_lock_init(&ts->lock);
> +
> + input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP) |
You usually do not set up autorepeat for pointingt devices.
> + BIT_MASK(EV_REL) | BIT_MASK(EV_ABS);
The device does not emit relative events.
> + input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
> +
> + input_set_capability(input_dev, EV_KEY, KEY_F);
KEY_F?
> +
> + input_set_abs_params(input_dev, ABS_X, CY8CTMG110_X_MIN, CY8CTMG110_X_MAX, 0, 0);
> + input_set_abs_params(input_dev, ABS_Y, CY8CTMG110_Y_MIN, CY8CTMG110_Y_MAX, 0, 0);
> +
> + err = gpio_request(CY8CTMG110_RESET_PIN_GPIO, NULL);
> +
> + if (err) {
> + dev_err(&client->dev, "cy8ctmg110_ts: Unable to request GPIO pin %d.\n",
> + CY8CTMG110_RESET_PIN_GPIO);
> + goto err_free_irq;
> + }
> + cy8ctmg110_power(true);
> +
> + ts->initController = false;
> + ts->i2c_fail_count = 0;
> +
> + hrtimer_init(&ts->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + ts->timer.function = cy8ctmg110_timer;
> +
> + if (polling)
> + hrtimer_start(&ts->timer, ktime_set(10, 0), HRTIMER_MODE_REL);
> +
Polling mode shoudl be controlled by platform data, not kernel module I think.
> + /* Can we fall back to polling if these bits fail - something to look
> + at for robustness */
> +
> + err = gpio_request(CY8CTMG110_IRQ_PIN_GPIO, "touch_irq_key");
> + if (err < 0) {
> + dev_err(&client->dev,
> + "cy8ctmg110_ts: failed to request GPIO %d, error %d\n",
> + CY8CTMG110_IRQ_PIN_GPIO, err);
> + goto err_free_timer;
> + }
> +
> + err = gpio_direction_input(CY8CTMG110_IRQ_PIN_GPIO);
> +
> + if (err < 0) {
> + dev_err(&client->dev,
> + "cy8ctmg110_ts: failed to configure input direction for GPIO %d, error %d\n",
> + CY8CTMG110_IRQ_PIN_GPIO, err);
> + goto err_free_gpio;
> + }
> + client->irq = gpio_to_irq(CY8CTMG110_IRQ_PIN_GPIO);
> +
> + if (client->irq < 0) {
> + err = client->irq;
> + dev_err(&client->dev,
> + "cy8ctmg110_ts: Unable to get irq number" " for GPIO %d, error %d\n",
> + CY8CTMG110_IRQ_PIN_GPIO, err);
> + goto err_free_gpio;
> + }
> + err = request_irq(client->irq, cy8ctmg110_irq_handler, IRQF_TRIGGER_RISING | IRQF_SHARED, "touch_reset_key", ts);
> + if (err < 0) {
> + dev_err(&client->dev,
> + "cy8ctmg110 irq %d busy? error %d\n",
> + client->irq, err);
> + goto err_free_gpio;
> + }
> +
> + err = input_register_device(input_dev);
> + if (!err)
> + return 0;
> +err_free_gpio:
> + gpio_free(CY8CTMG110_IRQ_PIN_GPIO);
> +err_free_timer:
> + if (polling)
> + hrtimer_cancel(&ts->timer);
> +err_free_irq:
> + free_irq(client->irq, ts);
> +err_free_mem:
> + input_free_device(input_dev);
> + kfree(ts);
> + return err;
> +}
> +
> +/*
> + * cy8ctmg110_suspend
> + *
> + */
> +
> +static int cy8ctmg110_suspend(struct i2c_client *client, pm_message_t mesg)
> +{
Stop timer here? Also power down the device?
> + if (device_may_wakeup(&client->dev))
> + enable_irq_wake(client->irq);
> +
> + return 0;
> +}
> +
> +/*
> + * cy8ctmg110_resume
> + *
> + */
> +
> +static int cy8ctmg110_resume(struct i2c_client *client)
> +{
> + if (device_may_wakeup(&client->dev))
> + disable_irq_wake(client->irq);
> +
> + return 0;
> +}
> +
> +/*
> + * cy8ctmg110_remove
> + *
> + */
> +
> +static int cy8ctmg110_remove(struct i2c_client *client)
> +{
> + struct cy8ctmg110 *ts = i2c_get_clientdata(client);
> +
> + cy8ctmg110_power(false);
> +
> + if (polling)
> + hrtimer_cancel(&ts->timer);
Implement close() method and move the code above there? Also do open().
> + free_irq(client->irq, ts);
> + input_unregister_device(ts->input);
> + /* FIXME: Do we need to free the GPIO ? */
> + kfree(ts);
> + return 0;
> +}
> +
> +static struct i2c_device_id cy8ctmg110_idtable[] = {
> + {CY8CTMG110_DRIVER_NAME, 1},
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, cy8ctmg110_idtable);
> +
> +static struct i2c_driver cy8ctmg110_driver = {
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = CY8CTMG110_DRIVER_NAME,
> + .bus = &i2c_bus_type,
> + },
> + .id_table = cy8ctmg110_idtable,
> + .probe = cy8ctmg110_probe,
> + .remove = cy8ctmg110_remove,
> + .suspend = cy8ctmg110_suspend,
> + .resume = cy8ctmg110_resume,
> +};
> +
> +static int __init cy8ctmg110_init(void)
> +{
> + return i2c_add_driver(&cy8ctmg110_driver);
> +}
> +
> +static void __exit cy8ctmg110_exit(void)
> +{
> + i2c_del_driver(&cy8ctmg110_driver);
> +}
> +
> +module_init(cy8ctmg110_init);
> +module_exit(cy8ctmg110_exit);
> +
> +MODULE_AUTHOR("Samuli Konttila <samuli.konttila@aavamobile.com>");
> +MODULE_DESCRIPTION("cy8ctmg110 TouchScreen Driver");
> +MODULE_LICENSE("GPL v2");
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dmitry
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2010-04-14 23:16 ` your mail Dmitry Torokhov
@ 2010-04-15 23:41 ` Rafi Rubin
2010-04-16 4:21 ` Dmitry Torokhov
0 siblings, 1 reply; 348+ messages in thread
From: Rafi Rubin @ 2010-04-15 23:41 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Alan Cox, linux-i2c, khali, linux-input, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> + if (ts->tc.event_sended == false) {
>
> We set "event_sended" to false immediately before calling
> cy8ctmg110_send_event() so I do not see the point of this flag.
On that note:
$ git grep -n sended
drivers/net/eth16i.c:1295:
how many packets there is to be sended */
drivers/net/wan/sbni.c:638:
/* if frame was sended but not ACK'ed - resend it */
drivers/net/wan/sbni.c:659:
* frame sended then in prepare_to_send next frame
drivers/usb/serial/aircable.c:13:
* next two bytes must say how much data will be sended.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvHpB4ACgkQwuRiAT9o609wAgCfbGjTP2lIN6JJyX28VzjPHxTY
ylIAn15FZRPpBEkWaFR8oAFKCCRmNF4d
=u4nx
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2010-04-15 23:41 ` Rafi Rubin
@ 2010-04-16 4:21 ` Dmitry Torokhov
0 siblings, 0 replies; 348+ messages in thread
From: Dmitry Torokhov @ 2010-04-16 4:21 UTC (permalink / raw)
To: Rafi Rubin; +Cc: Alan Cox, linux-i2c, khali, linux-input, linux-kernel
On Thu, Apr 15, 2010 at 07:41:22PM -0400, Rafi Rubin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >> + if (ts->tc.event_sended == false) {
> >
> > We set "event_sended" to false immediately before calling
> > cy8ctmg110_send_event() so I do not see the point of this flag.
>
> On that note:
>
> $ git grep -n sended
> drivers/net/eth16i.c:1295:
> how many packets there is to be sended */
> drivers/net/wan/sbni.c:638:
> /* if frame was sended but not ACK'ed - resend it */
> drivers/net/wan/sbni.c:659:
> * frame sended then in prepare_to_send next frame
> drivers/usb/serial/aircable.c:13:
> * next two bytes must say how much data will be sended.
>
Well, if you want to go down that path...
[dtor@hammer work]$ grep -r -e "\(setted\|setuped\|split\+ed\)" . | wc -l
54
[dtor@hammer work]$
--
Dmitry
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <20100113004939.289333186@suse.com>]
* Re: your mail
[not found] <20100113004939.289333186@suse.com>
@ 2010-01-13 14:57 ` scameron
0 siblings, 0 replies; 348+ messages in thread
From: scameron @ 2010-01-13 14:57 UTC (permalink / raw)
To: Jeff Mahoney; +Cc: Linux Kernel Mailing List, Andrew Morton, Linux SCSI
On Tue, Jan 12, 2010 at 07:49:00PM -0500, Jeff Mahoney wrote:
> Subject: [patch 5/6] hpsa: Fix section mismatch
> References: <20100113004855.550486769@suse.com>
> Content-Disposition: inline; filename=patches.rpmify/hpsa-fix-section-mismatch
>
> hpsa_pci_init calls hpsa_interrupt_mode which is a __devinit function.
> hpsa_pci_init is only called by hpsa_init_one which is also __devinit, so
> mark it __devinit as well.
>
> Signed-off-by: Jeff Mahoney <jeffm@suse.com>
> ---
> drivers/scsi/hpsa.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -3111,7 +3111,7 @@ default_int_mode:
> return;
> }
>
> -static int hpsa_pci_init(struct ctlr_info *h, struct pci_dev *pdev)
> +static int __devinit hpsa_pci_init(struct ctlr_info *h, struct pci_dev *pdev)
> {
> ushort subsystem_vendor_id, subsystem_device_id, command;
> __u32 board_id, scratchpad = 0;
>
Thanks.
-- steve
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
@ 2009-05-06 23:53 Oleg Nesterov
2009-05-07 0:21 ` Roland McGrath
0 siblings, 1 reply; 348+ messages in thread
From: Oleg Nesterov @ 2009-05-06 23:53 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Andrew Morton, Chris Wright, Roland McGrath, linux-kernel
On 05/06, Ingo Molnar wrote:
>
> * Oleg Nesterov <oleg@redhat.com> wrote:
>
> > + task_lock(task);
> > retval = __ptrace_may_access(task, PTRACE_MODE_ATTACH);
> > + task_unlock(task);
> > if (retval)
> > - goto bad;
> > + goto unlock_creds;
>
> Hm, that's a bit ugly - why dont you reuse ptrace_may_access(),
> which does much of this already?
Indeed, even the changelog mentions this.
I was going to cleanup this later. Because I think that
__ptrace_may_access() should die. It has only one caller, mm_for_maps().
I will re-check, but it looks a bit strange. More precisely, I just
can't understand it. Why we can't just do
struct mm_struct *mm_for_maps(struct task_struct *task)
{
struct mm_struct *mm = get_task_mm(task);
if (mm && mm != current->mm && !ptrace_may_access()) {
mmput(mm);
mm = NULL;
}
return mm;
}
? We do not care if this task exits and clears ->mm right before
or after ptrace_may_access(), and this is possible eith the current
code too once it drops tasklist.
Oleg.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-06 23:53 [RFC PATCH 3/3a] ptrace: add _ptrace_may_access() Oleg Nesterov
@ 2009-05-07 0:21 ` Roland McGrath
2009-05-07 6:36 ` Oleg Nesterov
0 siblings, 1 reply; 348+ messages in thread
From: Roland McGrath @ 2009-05-07 0:21 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Ingo Molnar, Andrew Morton, Chris Wright, linux-kernel, Al Viro
> I was going to cleanup this later. Because I think that
> __ptrace_may_access() should die. It has only one caller, mm_for_maps().
CC'ing Al Viro, who wrote mm_for_maps() (and no one has touched it since,
see commit 831830b).
> I will re-check, but it looks a bit strange. More precisely, I just
> can't understand it. Why we can't just do
>
> struct mm_struct *mm_for_maps(struct task_struct *task)
> {
> struct mm_struct *mm = get_task_mm(task);
>
> if (mm && mm != current->mm && !ptrace_may_access()) {
> mmput(mm);
> mm = NULL;
> }
>
> return mm;
> }
That seems fine to me. I suspect the old code just predated the PF_KTHREAD
check in get_task_mm() and excluding the borrowed-mm window races was the
only reason for using task_lock() that way.
> ? We do not care if this task exits and clears ->mm right before
> or after ptrace_may_access(), and this is possible eith the current
> code too once it drops tasklist.
I agree.
Thanks,
Roland
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 0:21 ` Roland McGrath
@ 2009-05-07 6:36 ` Oleg Nesterov
2009-05-07 8:20 ` Ingo Molnar
0 siblings, 1 reply; 348+ messages in thread
From: Oleg Nesterov @ 2009-05-07 6:36 UTC (permalink / raw)
To: Roland McGrath
Cc: Ingo Molnar, Andrew Morton, Chris Wright, linux-kernel, Al Viro
On 05/06, Roland McGrath wrote:
>
> > I was going to cleanup this later. Because I think that
> > __ptrace_may_access() should die. It has only one caller, mm_for_maps().
>
> CC'ing Al Viro, who wrote mm_for_maps() (and no one has touched it since,
> see commit 831830b).
>
> > I will re-check, but it looks a bit strange. More precisely, I just
> > can't understand it. Why we can't just do
> >
> > struct mm_struct *mm_for_maps(struct task_struct *task)
> > {
> > struct mm_struct *mm = get_task_mm(task);
> >
> > if (mm && mm != current->mm && !ptrace_may_access()) {
> > mmput(mm);
> > mm = NULL;
> > }
> >
> > return mm;
> > }
>
> That seems fine to me. I suspect the old code just predated the PF_KTHREAD
> check in get_task_mm() and excluding the borrowed-mm window races was the
> only reason for using task_lock() that way.
>
> > ? We do not care if this task exits and clears ->mm right before
> > or after ptrace_may_access(), and this is possible eith the current
> > code too once it drops tasklist.
>
> I agree.
Great. Will try to make the patches soon.
And I forgot to mention, there is another reason to kill __ptrace_may_access.
Because we can "narrow" the critical section protected by task_lock(). Not
for performance of course, just for clarity:
/* the callers of ptrace_may_access should be fixed */
int ptrace_may_access(struct task_struct *task, unsigned int mode)
{
const struct cred *cred = current_cred(), *tcred;
int ret = 0;
/* May we inspect the given task?
* This check is used both for attaching with ptrace
* and for allowing access to sensitive information in /proc.
*
* ptrace_attach denies several cases that /proc allows
* because setting up the necessary parent/child relationship
* or halting the specified task is impossible.
*/
/* Don't let security modules deny introspection */
if (task == current)
return ret;
rcu_read_lock();
tcred = __task_cred(task);
if ((cred->uid != tcred->euid ||
cred->uid != tcred->suid ||
cred->uid != tcred->uid ||
cred->gid != tcred->egid ||
cred->gid != tcred->sgid ||
cred->gid != tcred->gid) &&
!capable(CAP_SYS_PTRACE))
ret = -EPERM;
rcu_read_unlock();
if (ret)
return ret;
/* kill rmb ? */
task_lock(task);
if (!task->mm || !get_dumpable(task->mm)) {
if (!capable(CAP_SYS_PTRACE))
ret = -EPERM;
task_unclock(task);
if (ret)
return ret;
return security_ptrace_may_access(task, mode);
}
Btw, "[PATCH 3/3]" notes that security_ptrace_may_access() is called without
task_lock(), this note "leaked" from this change in future ;)
But firsty I'll try to grep/recheck this all.
Oleg.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 6:36 ` Oleg Nesterov
@ 2009-05-07 8:20 ` Ingo Molnar
2009-05-07 8:31 ` Oleg Nesterov
0 siblings, 1 reply; 348+ messages in thread
From: Ingo Molnar @ 2009-05-07 8:20 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Roland McGrath, Andrew Morton, Chris Wright, linux-kernel, Al Viro
* Oleg Nesterov <oleg@redhat.com> wrote:
> /* the callers of ptrace_may_access should be fixed */
>
> int ptrace_may_access(struct task_struct *task, unsigned int mode)
Sigh, NAK, for the reasons explained in the previous mails.
Ingo
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 8:20 ` Ingo Molnar
@ 2009-05-07 8:31 ` Oleg Nesterov
2009-05-07 8:38 ` Ingo Molnar
0 siblings, 1 reply; 348+ messages in thread
From: Oleg Nesterov @ 2009-05-07 8:31 UTC (permalink / raw)
To: Ingo Molnar
Cc: Roland McGrath, Andrew Morton, Chris Wright, linux-kernel, Al Viro
On 05/07, Ingo Molnar wrote:
>
> * Oleg Nesterov <oleg@redhat.com> wrote:
>
> > /* the callers of ptrace_may_access should be fixed */
> >
> > int ptrace_may_access(struct task_struct *task, unsigned int mode)
>
> Sigh, NAK, for the reasons explained in the previous mails.
Agreed, but what about security_operations->ptrace_may_access ?
It has the same (bad) name, but returns the error code or 0 on
success.
Oleg.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 8:31 ` Oleg Nesterov
@ 2009-05-07 8:38 ` Ingo Molnar
2009-05-07 8:57 ` Chris Wright
0 siblings, 1 reply; 348+ messages in thread
From: Ingo Molnar @ 2009-05-07 8:38 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Roland McGrath, Andrew Morton, Chris Wright, linux-kernel, Al Viro
* Oleg Nesterov <oleg@redhat.com> wrote:
> On 05/07, Ingo Molnar wrote:
> >
> > * Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > > /* the callers of ptrace_may_access should be fixed */
> > >
> > > int ptrace_may_access(struct task_struct *task, unsigned int mode)
> >
> > Sigh, NAK, for the reasons explained in the previous mails.
>
> Agreed, but what about security_operations->ptrace_may_access ?
>
> It has the same (bad) name, but returns the error code or 0 on
> success.
Bad code should generally be fixed, or in exceptional circumstances
it can tolerated if it's pre-existing bad code, but it should never
be propagated. It has not spread _that_ widely yet, and is isolated
to the security subsystem:
include/linux/security.h
security/capability.c
security/commoncap.c
security/root_plug.c
security/security.c
security/selinux/hooks.c
security/smack/smack_lsm.c
Ingo
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 8:38 ` Ingo Molnar
@ 2009-05-07 8:57 ` Chris Wright
2009-05-07 9:04 ` Ingo Molnar
0 siblings, 1 reply; 348+ messages in thread
From: Chris Wright @ 2009-05-07 8:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: Oleg Nesterov, Roland McGrath, Andrew Morton, Chris Wright,
linux-kernel, Al Viro
* Ingo Molnar (mingo@elte.hu) wrote:
> * Oleg Nesterov <oleg@redhat.com> wrote:
> > Agreed, but what about security_operations->ptrace_may_access ?
> > It has the same (bad) name, but returns the error code or 0 on
> > success.
>
> Bad code should generally be fixed, or in exceptional circumstances
> it can tolerated if it's pre-existing bad code, but it should never
> be propagated. It has not spread _that_ widely yet, and is isolated
> to the security subsystem:
And the security hooks tend to all follow the 0 success -ve ERR on error.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 8:57 ` Chris Wright
@ 2009-05-07 9:04 ` Ingo Molnar
2009-05-07 9:20 ` Chris Wright
0 siblings, 1 reply; 348+ messages in thread
From: Ingo Molnar @ 2009-05-07 9:04 UTC (permalink / raw)
To: Chris Wright
Cc: Oleg Nesterov, Roland McGrath, Andrew Morton, linux-kernel, Al Viro
* Chris Wright <chrisw@sous-sol.org> wrote:
> * Ingo Molnar (mingo@elte.hu) wrote:
> > * Oleg Nesterov <oleg@redhat.com> wrote:
> > > Agreed, but what about security_operations->ptrace_may_access ?
> > > It has the same (bad) name, but returns the error code or 0 on
> > > success.
> >
> > Bad code should generally be fixed, or in exceptional circumstances
> > it can tolerated if it's pre-existing bad code, but it should never
> > be propagated. It has not spread _that_ widely yet, and is isolated
> > to the security subsystem:
>
> And the security hooks tend to all follow the 0 success -ve ERR on error.
I just sent a patch (see below) that renames them to
ptrace_access_check().
They have no active connection to the core kernel
ptrace_may_access() check in any case: the methods seem to be
home-brewn, security-module specific checks for how wide ptrace is
allowed to go.
The design around that code does not seem to be very consistent.
One solution would be for the default "plain Linux" security module
to have a stock ->ptrace_access_check() that does the current
ptrace_may_access() check, and then procfs could be updated to use
that callback - instead of calling into the ptrace core code
directly.
This would mean that in the end the 'may' usage is eliminated
altogether, and we have a clean ptrace_access_check() facility with
a retval convention.
Ingo
-------------->
Subject: security: rename ptrace_may_access => ptrace_access_check
From: Ingo Molnar <mingo@elte.hu>
The ->ptrace_may_access methods are named confusingly - the real
ptrace_may_access() returns a bool, while these security checks have
a retval convention.
Rename it to ptrace_access_check, to reduce the confusion factor.
[ Impact: cleanup, no code changed ]
Signed-off-by-if-you-test-it: Ingo Molnar <mingo@elte.hu>
---
include/linux/security.h | 14 +++++++-------
security/capability.c | 2 +-
security/commoncap.c | 4 ++--
security/root_plug.c | 2 +-
security/security.c | 4 ++--
security/selinux/hooks.c | 6 +++---
security/smack/smack_lsm.c | 8 ++++----
7 files changed, 20 insertions(+), 20 deletions(-)
Index: tip/include/linux/security.h
===================================================================
--- tip.orig/include/linux/security.h
+++ tip/include/linux/security.h
@@ -52,7 +52,7 @@ struct audit_krule;
extern int cap_capable(struct task_struct *tsk, const struct cred *cred,
int cap, int audit);
extern int cap_settime(struct timespec *ts, struct timezone *tz);
-extern int cap_ptrace_may_access(struct task_struct *child, unsigned int mode);
+extern int cap_ptrace_access_check(struct task_struct *child, unsigned int mode);
extern int cap_ptrace_traceme(struct task_struct *parent);
extern int cap_capget(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted);
extern int cap_capset(struct cred *new, const struct cred *old,
@@ -1209,7 +1209,7 @@ static inline void security_free_mnt_opt
* @alter contains the flag indicating whether changes are to be made.
* Return 0 if permission is granted.
*
- * @ptrace_may_access:
+ * @ptrace_access_check:
* Check permission before allowing the current process to trace the
* @child process.
* Security modules may also want to perform a process tracing check
@@ -1224,7 +1224,7 @@ static inline void security_free_mnt_opt
* Check that the @parent process has sufficient permission to trace the
* current process before allowing the current process to present itself
* to the @parent process for tracing.
- * The parent process will still have to undergo the ptrace_may_access
+ * The parent process will still have to undergo the ptrace_access_check
* checks before it is allowed to trace this one.
* @parent contains the task_struct structure for debugger process.
* Return 0 if permission is granted.
@@ -1336,7 +1336,7 @@ static inline void security_free_mnt_opt
struct security_operations {
char name[SECURITY_NAME_MAX + 1];
- int (*ptrace_may_access) (struct task_struct *child, unsigned int mode);
+ int (*ptrace_access_check) (struct task_struct *child, unsigned int mode);
int (*ptrace_traceme) (struct task_struct *parent);
int (*capget) (struct task_struct *target,
kernel_cap_t *effective,
@@ -1617,7 +1617,7 @@ extern int security_module_enable(struct
extern int register_security(struct security_operations *ops);
/* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode);
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
int security_ptrace_traceme(struct task_struct *parent);
int security_capget(struct task_struct *target,
kernel_cap_t *effective,
@@ -1798,10 +1798,10 @@ static inline int security_init(void)
return 0;
}
-static inline int security_ptrace_may_access(struct task_struct *child,
+static inline int security_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
- return cap_ptrace_may_access(child, mode);
+ return cap_ptrace_access_check(child, mode);
}
static inline int security_ptrace_traceme(struct task_struct *parent)
Index: tip/security/capability.c
===================================================================
--- tip.orig/security/capability.c
+++ tip/security/capability.c
@@ -867,7 +867,7 @@ struct security_operations default_secur
void security_fixup_ops(struct security_operations *ops)
{
- set_to_cap_if_null(ops, ptrace_may_access);
+ set_to_cap_if_null(ops, ptrace_access_check);
set_to_cap_if_null(ops, ptrace_traceme);
set_to_cap_if_null(ops, capget);
set_to_cap_if_null(ops, capset);
Index: tip/security/commoncap.c
===================================================================
--- tip.orig/security/commoncap.c
+++ tip/security/commoncap.c
@@ -79,7 +79,7 @@ int cap_settime(struct timespec *ts, str
}
/**
- * cap_ptrace_may_access - Determine whether the current process may access
+ * cap_ptrace_access_check - Determine whether the current process may access
* another
* @child: The process to be accessed
* @mode: The mode of attachment.
@@ -87,7 +87,7 @@ int cap_settime(struct timespec *ts, str
* Determine whether a process may access another, returning 0 if permission
* granted, -ve if denied.
*/
-int cap_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int cap_ptrace_access_check(struct task_struct *child, unsigned int mode)
{
int ret = 0;
Index: tip/security/root_plug.c
===================================================================
--- tip.orig/security/root_plug.c
+++ tip/security/root_plug.c
@@ -72,7 +72,7 @@ static int rootplug_bprm_check_security
static struct security_operations rootplug_security_ops = {
/* Use the capability functions for some of the hooks */
- .ptrace_may_access = cap_ptrace_may_access,
+ .ptrace_access_check = cap_ptrace_access_check,
.ptrace_traceme = cap_ptrace_traceme,
.capget = cap_capget,
.capset = cap_capset,
Index: tip/security/security.c
===================================================================
--- tip.orig/security/security.c
+++ tip/security/security.c
@@ -127,9 +127,9 @@ int register_security(struct security_op
/* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode)
{
- return security_ops->ptrace_may_access(child, mode);
+ return security_ops->ptrace_access_check(child, mode);
}
int security_ptrace_traceme(struct task_struct *parent)
Index: tip/security/selinux/hooks.c
===================================================================
--- tip.orig/security/selinux/hooks.c
+++ tip/security/selinux/hooks.c
@@ -1854,12 +1854,12 @@ static inline u32 open_file_to_av(struct
/* Hook functions begin here. */
-static int selinux_ptrace_may_access(struct task_struct *child,
+static int selinux_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
int rc;
- rc = cap_ptrace_may_access(child, mode);
+ rc = cap_ptrace_access_check(child, mode);
if (rc)
return rc;
@@ -5318,7 +5318,7 @@ static int selinux_key_getsecurity(struc
static struct security_operations selinux_ops = {
.name = "selinux",
- .ptrace_may_access = selinux_ptrace_may_access,
+ .ptrace_access_check = selinux_ptrace_access_check,
.ptrace_traceme = selinux_ptrace_traceme,
.capget = selinux_capget,
.capset = selinux_capset,
Index: tip/security/smack/smack_lsm.c
===================================================================
--- tip.orig/security/smack/smack_lsm.c
+++ tip/security/smack/smack_lsm.c
@@ -92,7 +92,7 @@ struct inode_smack *new_inode_smack(char
*/
/**
- * smack_ptrace_may_access - Smack approval on PTRACE_ATTACH
+ * smack_ptrace_access_check - Smack approval on PTRACE_ATTACH
* @ctp: child task pointer
* @mode: ptrace attachment mode
*
@@ -100,11 +100,11 @@ struct inode_smack *new_inode_smack(char
*
* Do the capability checks, and require read and write.
*/
-static int smack_ptrace_may_access(struct task_struct *ctp, unsigned int mode)
+static int smack_ptrace_access_check(struct task_struct *ctp, unsigned int mode)
{
int rc;
- rc = cap_ptrace_may_access(ctp, mode);
+ rc = cap_ptrace_access_check(ctp, mode);
if (rc != 0)
return rc;
@@ -2826,7 +2826,7 @@ static void smack_release_secctx(char *s
struct security_operations smack_ops = {
.name = "smack",
- .ptrace_may_access = smack_ptrace_may_access,
+ .ptrace_access_check = smack_ptrace_access_check,
.ptrace_traceme = smack_ptrace_traceme,
.capget = cap_capget,
.capset = cap_capset,
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()
2009-05-07 9:04 ` Ingo Molnar
@ 2009-05-07 9:20 ` Chris Wright
2009-05-07 9:54 ` James Morris
0 siblings, 1 reply; 348+ messages in thread
From: Chris Wright @ 2009-05-07 9:20 UTC (permalink / raw)
To: Ingo Molnar
Cc: Chris Wright, Oleg Nesterov, Roland McGrath, Andrew Morton,
linux-kernel, Al Viro
* Ingo Molnar (mingo@elte.hu) wrote:
>
> * Chris Wright <chrisw@sous-sol.org> wrote:
>
> > * Ingo Molnar (mingo@elte.hu) wrote:
> > > * Oleg Nesterov <oleg@redhat.com> wrote:
> > > > Agreed, but what about security_operations->ptrace_may_access ?
> > > > It has the same (bad) name, but returns the error code or 0 on
> > > > success.
> > >
> > > Bad code should generally be fixed, or in exceptional circumstances
> > > it can tolerated if it's pre-existing bad code, but it should never
> > > be propagated. It has not spread _that_ widely yet, and is isolated
> > > to the security subsystem:
> >
> > And the security hooks tend to all follow the 0 success -ve ERR on error.
>
> I just sent a patch (see below) that renames them to
> ptrace_access_check().
>
> They have no active connection to the core kernel
> ptrace_may_access() check in any case:
Not sure what you mean:
ptrace_may_access
__ptrace_may_access
security_ptrace_may_access
Looks like your patch won't compile.
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
2009-05-07 9:20 ` Chris Wright
@ 2009-05-07 9:54 ` James Morris
2009-05-07 10:20 ` your mail Ingo Molnar
0 siblings, 1 reply; 348+ messages in thread
From: James Morris @ 2009-05-07 9:54 UTC (permalink / raw)
To: Chris Wright
Cc: Ingo Molnar, Oleg Nesterov, Roland McGrath, Andrew Morton,
linux-kernel, Al Viro, linux-security-module
On Thu, 7 May 2009, Chris Wright wrote:
> * Ingo Molnar (mingo@elte.hu) wrote:
[Added LSM list to the CC; please do so whenever making changes in this
area...]
> > They have no active connection to the core kernel
> > ptrace_may_access() check in any case:
>
> Not sure what you mean:
>
> ptrace_may_access
> __ptrace_may_access
> security_ptrace_may_access
>
> Looks like your patch won't compile.
>
Below is an updated version which fixes the bug, against
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
Boot tested with SELinux.
commit c4c79671177dc3e8387c337f75f3c664cdf08838
Author: Ingo Molnar <mingo@elte.hu>
Date: Thu May 7 19:26:19 2009 +1000
security: rename ptrace_may_access => ptrace_access_check
The ->ptrace_may_access() methods are named confusingly - the real
ptrace_may_access() returns a bool, while these security checks have
a retval convention.
Rename it to ptrace_access_check, to reduce the confusion factor.
[ Impact: cleanup, no code changed ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: James Morris <jmorris@namei.org>
diff --git a/include/linux/security.h b/include/linux/security.h
index 54ed157..0147def 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -51,7 +51,7 @@ struct audit_krule;
extern int cap_capable(struct task_struct *tsk, const struct cred *cred,
int cap, int audit);
extern int cap_settime(struct timespec *ts, struct timezone *tz);
-extern int cap_ptrace_may_access(struct task_struct *child, unsigned int mode);
+extern int cap_ptrace_access_check(struct task_struct *child, unsigned int mode);
extern int cap_ptrace_traceme(struct task_struct *parent);
extern int cap_capget(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted);
extern int cap_capset(struct cred *new, const struct cred *old,
@@ -1208,7 +1208,7 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
* @alter contains the flag indicating whether changes are to be made.
* Return 0 if permission is granted.
*
- * @ptrace_may_access:
+ * @ptrace_access_check:
* Check permission before allowing the current process to trace the
* @child process.
* Security modules may also want to perform a process tracing check
@@ -1223,7 +1223,7 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
* Check that the @parent process has sufficient permission to trace the
* current process before allowing the current process to present itself
* to the @parent process for tracing.
- * The parent process will still have to undergo the ptrace_may_access
+ * The parent process will still have to undergo the ptrace_access_check
* checks before it is allowed to trace this one.
* @parent contains the task_struct structure for debugger process.
* Return 0 if permission is granted.
@@ -1335,7 +1335,7 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
struct security_operations {
char name[SECURITY_NAME_MAX + 1];
- int (*ptrace_may_access) (struct task_struct *child, unsigned int mode);
+ int (*ptrace_access_check) (struct task_struct *child, unsigned int mode);
int (*ptrace_traceme) (struct task_struct *parent);
int (*capget) (struct task_struct *target,
kernel_cap_t *effective,
@@ -1616,7 +1616,7 @@ extern int security_module_enable(struct security_operations *ops);
extern int register_security(struct security_operations *ops);
/* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode);
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
int security_ptrace_traceme(struct task_struct *parent);
int security_capget(struct task_struct *target,
kernel_cap_t *effective,
@@ -1797,10 +1797,10 @@ static inline int security_init(void)
return 0;
}
-static inline int security_ptrace_may_access(struct task_struct *child,
+static inline int security_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
- return cap_ptrace_may_access(child, mode);
+ return cap_ptrace_access_check(child, mode);
}
static inline int security_ptrace_traceme(struct task_struct *parent)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index c9cf48b..284d0ac 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -160,7 +160,7 @@ int __ptrace_may_access(struct task_struct *task, unsigned int mode)
if (!dumpable && !capable(CAP_SYS_PTRACE))
return -EPERM;
- return security_ptrace_may_access(task, mode);
+ return security_ptrace_access_check(task, mode);
}
bool ptrace_may_access(struct task_struct *task, unsigned int mode)
diff --git a/security/capability.c b/security/capability.c
index 21b6cea..f218dd3 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -863,7 +863,7 @@ struct security_operations default_security_ops = {
void security_fixup_ops(struct security_operations *ops)
{
- set_to_cap_if_null(ops, ptrace_may_access);
+ set_to_cap_if_null(ops, ptrace_access_check);
set_to_cap_if_null(ops, ptrace_traceme);
set_to_cap_if_null(ops, capget);
set_to_cap_if_null(ops, capset);
diff --git a/security/commoncap.c b/security/commoncap.c
index 97ac1f1..e57611a 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -101,7 +101,7 @@ int cap_settime(struct timespec *ts, struct timezone *tz)
}
/**
- * cap_ptrace_may_access - Determine whether the current process may access
+ * cap_ptrace_access_check - Determine whether the current process may access
* another
* @child: The process to be accessed
* @mode: The mode of attachment.
@@ -109,7 +109,7 @@ int cap_settime(struct timespec *ts, struct timezone *tz)
* Determine whether a process may access another, returning 0 if permission
* granted, -ve if denied.
*/
-int cap_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int cap_ptrace_access_check(struct task_struct *child, unsigned int mode)
{
int ret = 0;
diff --git a/security/root_plug.c b/security/root_plug.c
index 40fb4f1..e8d5861 100644
--- a/security/root_plug.c
+++ b/security/root_plug.c
@@ -72,7 +72,7 @@ static int rootplug_bprm_check_security (struct linux_binprm *bprm)
static struct security_operations rootplug_security_ops = {
/* Use the capability functions for some of the hooks */
- .ptrace_may_access = cap_ptrace_may_access,
+ .ptrace_access_check = cap_ptrace_access_check,
.ptrace_traceme = cap_ptrace_traceme,
.capget = cap_capget,
.capset = cap_capset,
diff --git a/security/security.c b/security/security.c
index 206e538..a3e6918 100644
--- a/security/security.c
+++ b/security/security.c
@@ -127,9 +127,9 @@ int register_security(struct security_operations *ops)
/* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode)
{
- return security_ops->ptrace_may_access(child, mode);
+ return security_ops->ptrace_access_check(child, mode);
}
int security_ptrace_traceme(struct task_struct *parent)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 39046dd..e30c4bb 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1854,12 +1854,12 @@ static inline u32 open_file_to_av(struct file *file)
/* Hook functions begin here. */
-static int selinux_ptrace_may_access(struct task_struct *child,
+static int selinux_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
int rc;
- rc = cap_ptrace_may_access(child, mode);
+ rc = cap_ptrace_access_check(child, mode);
if (rc)
return rc;
@@ -5310,7 +5310,7 @@ static int selinux_key_getsecurity(struct key *key, char **_buffer)
static struct security_operations selinux_ops = {
.name = "selinux",
- .ptrace_may_access = selinux_ptrace_may_access,
+ .ptrace_access_check = selinux_ptrace_access_check,
.ptrace_traceme = selinux_ptrace_traceme,
.capget = selinux_capget,
.capset = selinux_capset,
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index f557767..79949f9 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -91,7 +91,7 @@ struct inode_smack *new_inode_smack(char *smack)
*/
/**
- * smack_ptrace_may_access - Smack approval on PTRACE_ATTACH
+ * smack_ptrace_access_check - Smack approval on PTRACE_ATTACH
* @ctp: child task pointer
* @mode: ptrace attachment mode
*
@@ -99,13 +99,13 @@ struct inode_smack *new_inode_smack(char *smack)
*
* Do the capability checks, and require read and write.
*/
-static int smack_ptrace_may_access(struct task_struct *ctp, unsigned int mode)
+static int smack_ptrace_access_check(struct task_struct *ctp, unsigned int mode)
{
int rc;
struct smk_audit_info ad;
char *sp, *tsp;
- rc = cap_ptrace_may_access(ctp, mode);
+ rc = cap_ptrace_access_check(ctp, mode);
if (rc != 0)
return rc;
@@ -3031,7 +3031,7 @@ static void smack_release_secctx(char *secdata, u32 seclen)
struct security_operations smack_ops = {
.name = "smack",
- .ptrace_may_access = smack_ptrace_may_access,
+ .ptrace_access_check = smack_ptrace_access_check,
.ptrace_traceme = smack_ptrace_traceme,
.capget = cap_capget,
.capset = cap_capset,
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2009-05-07 9:54 ` James Morris
@ 2009-05-07 10:20 ` Ingo Molnar
2009-05-08 3:27 ` Casey Schaufler
0 siblings, 1 reply; 348+ messages in thread
From: Ingo Molnar @ 2009-05-07 10:20 UTC (permalink / raw)
To: James Morris
Cc: Chris Wright, Oleg Nesterov, Roland McGrath, Andrew Morton,
linux-kernel, Al Viro, linux-security-module
* James Morris <jmorris@namei.org> wrote:
> On Thu, 7 May 2009, Chris Wright wrote:
>
> > * Ingo Molnar (mingo@elte.hu) wrote:
>
> [Added LSM list to the CC; please do so whenever making changes in this
> area...]
>
> > > They have no active connection to the core kernel
> > > ptrace_may_access() check in any case:
> >
> > Not sure what you mean:
> >
> > ptrace_may_access
> > __ptrace_may_access
> > security_ptrace_may_access
> >
> > Looks like your patch won't compile.
> >
>
> Below is an updated version which fixes the bug, against
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
>
> Boot tested with SELinux.
thanks! Below are the two patches i wrote and tested.
Ingo
----- Forwarded message from Ingo Molnar <mingo@elte.hu> -----
Date: Thu, 7 May 2009 11:49:47 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Chris Wright <chrisw@sous-sol.org>
Subject: [patch 1/2] ptrace, security: rename ptrace_may_access =>
ptrace_access_check
Cc: Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
The ptrace_may_access() methods are named confusingly - some
variants return a bool, while the security subsystem methods have a
retval convention.
Rename it to ptrace_access_check, to reduce the confusion factor. A
followup patch eliminates the bool usage.
[ Impact: cleanup, no code changed ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Oleg Nesterov <oleg@redhat.com>
LKML-Reference: <20090507084943.GB19133@elte.hu>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
fs/proc/array.c | 2 +-
fs/proc/base.c | 10 +++++-----
fs/proc/task_mmu.c | 2 +-
include/linux/ptrace.h | 4 ++--
include/linux/security.h | 14 +++++++-------
kernel/ptrace.c | 10 +++++-----
security/capability.c | 2 +-
security/commoncap.c | 4 ++--
security/root_plug.c | 2 +-
security/security.c | 4 ++--
security/selinux/hooks.c | 6 +++---
security/smack/smack_lsm.c | 8 ++++----
12 files changed, 34 insertions(+), 34 deletions(-)
Index: linux/fs/proc/array.c
===================================================================
--- linux.orig/fs/proc/array.c
+++ linux/fs/proc/array.c
@@ -366,7 +366,7 @@ static int do_task_stat(struct seq_file
state = *get_task_state(task);
vsize = eip = esp = 0;
- permitted = ptrace_may_access(task, PTRACE_MODE_READ);
+ permitted = ptrace_access_check(task, PTRACE_MODE_READ);
mm = get_task_mm(task);
if (mm) {
vsize = task_vsize(mm);
Index: linux/fs/proc/base.c
===================================================================
--- linux.orig/fs/proc/base.c
+++ linux/fs/proc/base.c
@@ -222,7 +222,7 @@ static int check_mem_permission(struct t
rcu_read_lock();
match = (tracehook_tracer_task(task) == current);
rcu_read_unlock();
- if (match && ptrace_may_access(task, PTRACE_MODE_ATTACH))
+ if (match && ptrace_access_check(task, PTRACE_MODE_ATTACH))
return 0;
}
@@ -242,7 +242,7 @@ struct mm_struct *mm_for_maps(struct tas
if (task->mm != mm)
goto out;
if (task->mm != current->mm &&
- __ptrace_may_access(task, PTRACE_MODE_READ) < 0)
+ __ptrace_access_check(task, PTRACE_MODE_READ) < 0)
goto out;
task_unlock(task);
return mm;
@@ -322,7 +322,7 @@ static int proc_pid_wchan(struct task_st
wchan = get_wchan(task);
if (lookup_symbol_name(wchan, symname) < 0)
- if (!ptrace_may_access(task, PTRACE_MODE_READ))
+ if (!ptrace_access_check(task, PTRACE_MODE_READ))
return 0;
else
return sprintf(buffer, "%lu", wchan);
@@ -559,7 +559,7 @@ static int proc_fd_access_allowed(struct
*/
task = get_proc_task(inode);
if (task) {
- allowed = ptrace_may_access(task, PTRACE_MODE_READ);
+ allowed = ptrace_access_check(task, PTRACE_MODE_READ);
put_task_struct(task);
}
return allowed;
@@ -938,7 +938,7 @@ static ssize_t environ_read(struct file
if (!task)
goto out_no_task;
- if (!ptrace_may_access(task, PTRACE_MODE_READ))
+ if (!ptrace_access_check(task, PTRACE_MODE_READ))
goto out;
ret = -ENOMEM;
Index: linux/fs/proc/task_mmu.c
===================================================================
--- linux.orig/fs/proc/task_mmu.c
+++ linux/fs/proc/task_mmu.c
@@ -656,7 +656,7 @@ static ssize_t pagemap_read(struct file
goto out;
ret = -EACCES;
- if (!ptrace_may_access(task, PTRACE_MODE_READ))
+ if (!ptrace_access_check(task, PTRACE_MODE_READ))
goto out_task;
ret = -EINVAL;
Index: linux/include/linux/ptrace.h
===================================================================
--- linux.orig/include/linux/ptrace.h
+++ linux/include/linux/ptrace.h
@@ -99,9 +99,9 @@ extern void ptrace_fork(struct task_stru
#define PTRACE_MODE_READ 1
#define PTRACE_MODE_ATTACH 2
/* Returns 0 on success, -errno on denial. */
-extern int __ptrace_may_access(struct task_struct *task, unsigned int mode);
+extern int __ptrace_access_check(struct task_struct *task, unsigned int mode);
/* Returns true on success, false on denial. */
-extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
+extern bool ptrace_access_check(struct task_struct *task, unsigned int mode);
static inline int ptrace_reparented(struct task_struct *child)
{
Index: linux/include/linux/security.h
===================================================================
--- linux.orig/include/linux/security.h
+++ linux/include/linux/security.h
@@ -52,7 +52,7 @@ struct audit_krule;
extern int cap_capable(struct task_struct *tsk, const struct cred *cred,
int cap, int audit);
extern int cap_settime(struct timespec *ts, struct timezone *tz);
-extern int cap_ptrace_may_access(struct task_struct *child, unsigned int mode);
+extern int cap_ptrace_access_check(struct task_struct *child, unsigned int mode);
extern int cap_ptrace_traceme(struct task_struct *parent);
extern int cap_capget(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted);
extern int cap_capset(struct cred *new, const struct cred *old,
@@ -1209,7 +1209,7 @@ static inline void security_free_mnt_opt
* @alter contains the flag indicating whether changes are to be made.
* Return 0 if permission is granted.
*
- * @ptrace_may_access:
+ * @ptrace_access_check:
* Check permission before allowing the current process to trace the
* @child process.
* Security modules may also want to perform a process tracing check
@@ -1224,7 +1224,7 @@ static inline void security_free_mnt_opt
* Check that the @parent process has sufficient permission to trace the
* current process before allowing the current process to present itself
* to the @parent process for tracing.
- * The parent process will still have to undergo the ptrace_may_access
+ * The parent process will still have to undergo the ptrace_access_check
* checks before it is allowed to trace this one.
* @parent contains the task_struct structure for debugger process.
* Return 0 if permission is granted.
@@ -1336,7 +1336,7 @@ static inline void security_free_mnt_opt
struct security_operations {
char name[SECURITY_NAME_MAX + 1];
- int (*ptrace_may_access) (struct task_struct *child, unsigned int mode);
+ int (*ptrace_access_check) (struct task_struct *child, unsigned int mode);
int (*ptrace_traceme) (struct task_struct *parent);
int (*capget) (struct task_struct *target,
kernel_cap_t *effective,
@@ -1617,7 +1617,7 @@ extern int security_module_enable(struct
extern int register_security(struct security_operations *ops);
/* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode);
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
int security_ptrace_traceme(struct task_struct *parent);
int security_capget(struct task_struct *target,
kernel_cap_t *effective,
@@ -1798,10 +1798,10 @@ static inline int security_init(void)
return 0;
}
-static inline int security_ptrace_may_access(struct task_struct *child,
+static inline int security_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
- return cap_ptrace_may_access(child, mode);
+ return cap_ptrace_access_check(child, mode);
}
static inline int security_ptrace_traceme(struct task_struct *parent)
Index: linux/kernel/ptrace.c
===================================================================
--- linux.orig/kernel/ptrace.c
+++ linux/kernel/ptrace.c
@@ -127,7 +127,7 @@ int ptrace_check_attach(struct task_stru
return ret;
}
-int __ptrace_may_access(struct task_struct *task, unsigned int mode)
+int __ptrace_access_check(struct task_struct *task, unsigned int mode)
{
const struct cred *cred = current_cred(), *tcred;
@@ -162,14 +162,14 @@ int __ptrace_may_access(struct task_stru
if (!dumpable && !capable(CAP_SYS_PTRACE))
return -EPERM;
- return security_ptrace_may_access(task, mode);
+ return security_ptrace_access_check(task, mode);
}
-bool ptrace_may_access(struct task_struct *task, unsigned int mode)
+bool ptrace_access_check(struct task_struct *task, unsigned int mode)
{
int err;
task_lock(task);
- err = __ptrace_may_access(task, mode);
+ err = __ptrace_access_check(task, mode);
task_unlock(task);
return !err;
}
@@ -217,7 +217,7 @@ repeat:
/* the same process cannot be attached many times */
if (task->ptrace & PT_PTRACED)
goto bad;
- retval = __ptrace_may_access(task, PTRACE_MODE_ATTACH);
+ retval = __ptrace_access_check(task, PTRACE_MODE_ATTACH);
if (retval)
goto bad;
Index: linux/security/capability.c
===================================================================
--- linux.orig/security/capability.c
+++ linux/security/capability.c
@@ -863,7 +863,7 @@ struct security_operations default_secur
void security_fixup_ops(struct security_operations *ops)
{
- set_to_cap_if_null(ops, ptrace_may_access);
+ set_to_cap_if_null(ops, ptrace_access_check);
set_to_cap_if_null(ops, ptrace_traceme);
set_to_cap_if_null(ops, capget);
set_to_cap_if_null(ops, capset);
Index: linux/security/commoncap.c
===================================================================
--- linux.orig/security/commoncap.c
+++ linux/security/commoncap.c
@@ -79,7 +79,7 @@ int cap_settime(struct timespec *ts, str
}
/**
- * cap_ptrace_may_access - Determine whether the current process may access
+ * cap_ptrace_access_check - Determine whether the current process may access
* another
* @child: The process to be accessed
* @mode: The mode of attachment.
@@ -87,7 +87,7 @@ int cap_settime(struct timespec *ts, str
* Determine whether a process may access another, returning 0 if permission
* granted, -ve if denied.
*/
-int cap_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int cap_ptrace_access_check(struct task_struct *child, unsigned int mode)
{
int ret = 0;
Index: linux/security/root_plug.c
===================================================================
--- linux.orig/security/root_plug.c
+++ linux/security/root_plug.c
@@ -72,7 +72,7 @@ static int rootplug_bprm_check_security
static struct security_operations rootplug_security_ops = {
/* Use the capability functions for some of the hooks */
- .ptrace_may_access = cap_ptrace_may_access,
+ .ptrace_access_check = cap_ptrace_access_check,
.ptrace_traceme = cap_ptrace_traceme,
.capget = cap_capget,
.capset = cap_capset,
Index: linux/security/security.c
===================================================================
--- linux.orig/security/security.c
+++ linux/security/security.c
@@ -127,9 +127,9 @@ int register_security(struct security_op
/* Security operations */
-int security_ptrace_may_access(struct task_struct *child, unsigned int mode)
+int security_ptrace_access_check(struct task_struct *child, unsigned int mode)
{
- return security_ops->ptrace_may_access(child, mode);
+ return security_ops->ptrace_access_check(child, mode);
}
int security_ptrace_traceme(struct task_struct *parent)
Index: linux/security/selinux/hooks.c
===================================================================
--- linux.orig/security/selinux/hooks.c
+++ linux/security/selinux/hooks.c
@@ -1854,12 +1854,12 @@ static inline u32 open_file_to_av(struct
/* Hook functions begin here. */
-static int selinux_ptrace_may_access(struct task_struct *child,
+static int selinux_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
int rc;
- rc = cap_ptrace_may_access(child, mode);
+ rc = cap_ptrace_access_check(child, mode);
if (rc)
return rc;
@@ -5318,7 +5318,7 @@ static int selinux_key_getsecurity(struc
static struct security_operations selinux_ops = {
.name = "selinux",
- .ptrace_may_access = selinux_ptrace_may_access,
+ .ptrace_access_check = selinux_ptrace_access_check,
.ptrace_traceme = selinux_ptrace_traceme,
.capget = selinux_capget,
.capset = selinux_capset,
Index: linux/security/smack/smack_lsm.c
===================================================================
--- linux.orig/security/smack/smack_lsm.c
+++ linux/security/smack/smack_lsm.c
@@ -92,7 +92,7 @@ struct inode_smack *new_inode_smack(char
*/
/**
- * smack_ptrace_may_access - Smack approval on PTRACE_ATTACH
+ * smack_ptrace_access_check - Smack approval on PTRACE_ATTACH
* @ctp: child task pointer
* @mode: ptrace attachment mode
*
@@ -100,11 +100,11 @@ struct inode_smack *new_inode_smack(char
*
* Do the capability checks, and require read and write.
*/
-static int smack_ptrace_may_access(struct task_struct *ctp, unsigned int mode)
+static int smack_ptrace_access_check(struct task_struct *ctp, unsigned int mode)
{
int rc;
- rc = cap_ptrace_may_access(ctp, mode);
+ rc = cap_ptrace_access_check(ctp, mode);
if (rc != 0)
return rc;
@@ -2826,7 +2826,7 @@ static void smack_release_secctx(char *s
struct security_operations smack_ops = {
.name = "smack",
- .ptrace_may_access = smack_ptrace_may_access,
+ .ptrace_access_check = smack_ptrace_access_check,
.ptrace_traceme = smack_ptrace_traceme,
.capget = cap_capget,
.capset = cap_capset,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----- End forwarded message -----
----- Forwarded message from Ingo Molnar <mingo@elte.hu> -----
Date: Thu, 7 May 2009 11:50:54 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Chris Wright <chrisw@sous-sol.org>
Subject: [patch 2/2] ptrace: turn ptrace_access_check() into a retval
function
Cc: Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
ptrace_access_check() returns a bool, while most of the ptrace
access check machinery works with Linux retvals (where 0 indicates
success, negative indicates an error).
So eliminate the bool and invert the usage at the call sites.
( Note: "< 0" checks are used instead of !0 checks, because that's
the convention for retval checks and it results in similarly fast
assembly code. )
[ Impact: cleanup ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
fs/proc/array.c | 2 +-
fs/proc/base.c | 8 ++++----
fs/proc/task_mmu.c | 2 +-
include/linux/ptrace.h | 2 +-
kernel/ptrace.c | 6 ++++--
5 files changed, 11 insertions(+), 9 deletions(-)
Index: linux/fs/proc/array.c
===================================================================
--- linux.orig/fs/proc/array.c
+++ linux/fs/proc/array.c
@@ -366,7 +366,7 @@ static int do_task_stat(struct seq_file
state = *get_task_state(task);
vsize = eip = esp = 0;
- permitted = ptrace_access_check(task, PTRACE_MODE_READ);
+ permitted = !ptrace_access_check(task, PTRACE_MODE_READ);
mm = get_task_mm(task);
if (mm) {
vsize = task_vsize(mm);
Index: linux/fs/proc/base.c
===================================================================
--- linux.orig/fs/proc/base.c
+++ linux/fs/proc/base.c
@@ -222,7 +222,7 @@ static int check_mem_permission(struct t
rcu_read_lock();
match = (tracehook_tracer_task(task) == current);
rcu_read_unlock();
- if (match && ptrace_access_check(task, PTRACE_MODE_ATTACH))
+ if (match && !ptrace_access_check(task, PTRACE_MODE_ATTACH))
return 0;
}
@@ -322,7 +322,7 @@ static int proc_pid_wchan(struct task_st
wchan = get_wchan(task);
if (lookup_symbol_name(wchan, symname) < 0)
- if (!ptrace_access_check(task, PTRACE_MODE_READ))
+ if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
return 0;
else
return sprintf(buffer, "%lu", wchan);
@@ -559,7 +559,7 @@ static int proc_fd_access_allowed(struct
*/
task = get_proc_task(inode);
if (task) {
- allowed = ptrace_access_check(task, PTRACE_MODE_READ);
+ allowed = !ptrace_access_check(task, PTRACE_MODE_READ);
put_task_struct(task);
}
return allowed;
@@ -938,7 +938,7 @@ static ssize_t environ_read(struct file
if (!task)
goto out_no_task;
- if (!ptrace_access_check(task, PTRACE_MODE_READ))
+ if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
goto out;
ret = -ENOMEM;
Index: linux/fs/proc/task_mmu.c
===================================================================
--- linux.orig/fs/proc/task_mmu.c
+++ linux/fs/proc/task_mmu.c
@@ -656,7 +656,7 @@ static ssize_t pagemap_read(struct file
goto out;
ret = -EACCES;
- if (!ptrace_access_check(task, PTRACE_MODE_READ))
+ if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
goto out_task;
ret = -EINVAL;
Index: linux/include/linux/ptrace.h
===================================================================
--- linux.orig/include/linux/ptrace.h
+++ linux/include/linux/ptrace.h
@@ -101,7 +101,7 @@ extern void ptrace_fork(struct task_stru
/* Returns 0 on success, -errno on denial. */
extern int __ptrace_access_check(struct task_struct *task, unsigned int mode);
/* Returns true on success, false on denial. */
-extern bool ptrace_access_check(struct task_struct *task, unsigned int mode);
+extern int ptrace_access_check(struct task_struct *task, unsigned int mode);
static inline int ptrace_reparented(struct task_struct *child)
{
Index: linux/kernel/ptrace.c
===================================================================
--- linux.orig/kernel/ptrace.c
+++ linux/kernel/ptrace.c
@@ -165,13 +165,15 @@ int __ptrace_access_check(struct task_st
return security_ptrace_access_check(task, mode);
}
-bool ptrace_access_check(struct task_struct *task, unsigned int mode)
+int ptrace_access_check(struct task_struct *task, unsigned int mode)
{
int err;
+
task_lock(task);
err = __ptrace_access_check(task, mode);
task_unlock(task);
- return !err;
+
+ return err;
}
int ptrace_attach(struct task_struct *task)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----- End forwarded message -----
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2009-05-07 10:20 ` your mail Ingo Molnar
@ 2009-05-08 3:27 ` Casey Schaufler
0 siblings, 0 replies; 348+ messages in thread
From: Casey Schaufler @ 2009-05-08 3:27 UTC (permalink / raw)
To: Ingo Molnar
Cc: James Morris, Chris Wright, Oleg Nesterov, Roland McGrath,
Andrew Morton, linux-kernel, Al Viro, linux-security-module
Ingo Molnar wrote:
> * James Morris <jmorris@namei.org> wrote:
>
>
>> On Thu, 7 May 2009, Chris Wright wrote:
>>
>>
>>> * Ingo Molnar (mingo@elte.hu) wrote:
>>>
>> [Added LSM list to the CC; please do so whenever making changes in this
>> area...]
>>
>>
>>>> They have no active connection to the core kernel
>>>> ptrace_may_access() check in any case:
>>>>
>>> Not sure what you mean:
>>>
>>> ptrace_may_access
>>> __ptrace_may_access
>>> security_ptrace_may_access
>>>
>>> Looks like your patch won't compile.
>>>
>>>
>> Below is an updated version which fixes the bug, against
>> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
>>
>> Boot tested with SELinux.
>>
>
> thanks! Below are the two patches i wrote and tested.
>
I hate to make an assumption regarding whether or not your tests
included Smack, so I'll ask. Does tested mean with Smack?
Thank you.
> Ingo
>
> ----- Forwarded message from Ingo Molnar <mingo@elte.hu> -----
>
> Date: Thu, 7 May 2009 11:49:47 +0200
> From: Ingo Molnar <mingo@elte.hu>
> To: Chris Wright <chrisw@sous-sol.org>
> Subject: [patch 1/2] ptrace, security: rename ptrace_may_access =>
> ptrace_access_check
> Cc: Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
> Andrew Morton <akpm@linux-foundation.org>,
> linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
>
> The ptrace_may_access() methods are named confusingly - some
> variants return a bool, while the security subsystem methods have a
> retval convention.
>
> Rename it to ptrace_access_check, to reduce the confusion factor. A
> followup patch eliminates the bool usage.
>
> [ Impact: cleanup, no code changed ]
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> Cc: Roland McGrath <roland@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Chris Wright <chrisw@sous-sol.org>
> Cc: Al Viro <viro@ZenIV.linux.org.uk>
> Cc: Oleg Nesterov <oleg@redhat.com>
> LKML-Reference: <20090507084943.GB19133@elte.hu>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> fs/proc/array.c | 2 +-
> fs/proc/base.c | 10 +++++-----
> fs/proc/task_mmu.c | 2 +-
> include/linux/ptrace.h | 4 ++--
> include/linux/security.h | 14 +++++++-------
> kernel/ptrace.c | 10 +++++-----
> security/capability.c | 2 +-
> security/commoncap.c | 4 ++--
> security/root_plug.c | 2 +-
> security/security.c | 4 ++--
> security/selinux/hooks.c | 6 +++---
> security/smack/smack_lsm.c | 8 ++++----
> 12 files changed, 34 insertions(+), 34 deletions(-)
>
> Index: linux/fs/proc/array.c
> ===================================================================
> --- linux.orig/fs/proc/array.c
> +++ linux/fs/proc/array.c
> @@ -366,7 +366,7 @@ static int do_task_stat(struct seq_file
>
> state = *get_task_state(task);
> vsize = eip = esp = 0;
> - permitted = ptrace_may_access(task, PTRACE_MODE_READ);
> + permitted = ptrace_access_check(task, PTRACE_MODE_READ);
> mm = get_task_mm(task);
> if (mm) {
> vsize = task_vsize(mm);
> Index: linux/fs/proc/base.c
> ===================================================================
> --- linux.orig/fs/proc/base.c
> +++ linux/fs/proc/base.c
> @@ -222,7 +222,7 @@ static int check_mem_permission(struct t
> rcu_read_lock();
> match = (tracehook_tracer_task(task) == current);
> rcu_read_unlock();
> - if (match && ptrace_may_access(task, PTRACE_MODE_ATTACH))
> + if (match && ptrace_access_check(task, PTRACE_MODE_ATTACH))
> return 0;
> }
>
> @@ -242,7 +242,7 @@ struct mm_struct *mm_for_maps(struct tas
> if (task->mm != mm)
> goto out;
> if (task->mm != current->mm &&
> - __ptrace_may_access(task, PTRACE_MODE_READ) < 0)
> + __ptrace_access_check(task, PTRACE_MODE_READ) < 0)
> goto out;
> task_unlock(task);
> return mm;
> @@ -322,7 +322,7 @@ static int proc_pid_wchan(struct task_st
> wchan = get_wchan(task);
>
> if (lookup_symbol_name(wchan, symname) < 0)
> - if (!ptrace_may_access(task, PTRACE_MODE_READ))
> + if (!ptrace_access_check(task, PTRACE_MODE_READ))
> return 0;
> else
> return sprintf(buffer, "%lu", wchan);
> @@ -559,7 +559,7 @@ static int proc_fd_access_allowed(struct
> */
> task = get_proc_task(inode);
> if (task) {
> - allowed = ptrace_may_access(task, PTRACE_MODE_READ);
> + allowed = ptrace_access_check(task, PTRACE_MODE_READ);
> put_task_struct(task);
> }
> return allowed;
> @@ -938,7 +938,7 @@ static ssize_t environ_read(struct file
> if (!task)
> goto out_no_task;
>
> - if (!ptrace_may_access(task, PTRACE_MODE_READ))
> + if (!ptrace_access_check(task, PTRACE_MODE_READ))
> goto out;
>
> ret = -ENOMEM;
> Index: linux/fs/proc/task_mmu.c
> ===================================================================
> --- linux.orig/fs/proc/task_mmu.c
> +++ linux/fs/proc/task_mmu.c
> @@ -656,7 +656,7 @@ static ssize_t pagemap_read(struct file
> goto out;
>
> ret = -EACCES;
> - if (!ptrace_may_access(task, PTRACE_MODE_READ))
> + if (!ptrace_access_check(task, PTRACE_MODE_READ))
> goto out_task;
>
> ret = -EINVAL;
> Index: linux/include/linux/ptrace.h
> ===================================================================
> --- linux.orig/include/linux/ptrace.h
> +++ linux/include/linux/ptrace.h
> @@ -99,9 +99,9 @@ extern void ptrace_fork(struct task_stru
> #define PTRACE_MODE_READ 1
> #define PTRACE_MODE_ATTACH 2
> /* Returns 0 on success, -errno on denial. */
> -extern int __ptrace_may_access(struct task_struct *task, unsigned int mode);
> +extern int __ptrace_access_check(struct task_struct *task, unsigned int mode);
> /* Returns true on success, false on denial. */
> -extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
> +extern bool ptrace_access_check(struct task_struct *task, unsigned int mode);
>
> static inline int ptrace_reparented(struct task_struct *child)
> {
> Index: linux/include/linux/security.h
> ===================================================================
> --- linux.orig/include/linux/security.h
> +++ linux/include/linux/security.h
> @@ -52,7 +52,7 @@ struct audit_krule;
> extern int cap_capable(struct task_struct *tsk, const struct cred *cred,
> int cap, int audit);
> extern int cap_settime(struct timespec *ts, struct timezone *tz);
> -extern int cap_ptrace_may_access(struct task_struct *child, unsigned int mode);
> +extern int cap_ptrace_access_check(struct task_struct *child, unsigned int mode);
> extern int cap_ptrace_traceme(struct task_struct *parent);
> extern int cap_capget(struct task_struct *target, kernel_cap_t *effective, kernel_cap_t *inheritable, kernel_cap_t *permitted);
> extern int cap_capset(struct cred *new, const struct cred *old,
> @@ -1209,7 +1209,7 @@ static inline void security_free_mnt_opt
> * @alter contains the flag indicating whether changes are to be made.
> * Return 0 if permission is granted.
> *
> - * @ptrace_may_access:
> + * @ptrace_access_check:
> * Check permission before allowing the current process to trace the
> * @child process.
> * Security modules may also want to perform a process tracing check
> @@ -1224,7 +1224,7 @@ static inline void security_free_mnt_opt
> * Check that the @parent process has sufficient permission to trace the
> * current process before allowing the current process to present itself
> * to the @parent process for tracing.
> - * The parent process will still have to undergo the ptrace_may_access
> + * The parent process will still have to undergo the ptrace_access_check
> * checks before it is allowed to trace this one.
> * @parent contains the task_struct structure for debugger process.
> * Return 0 if permission is granted.
> @@ -1336,7 +1336,7 @@ static inline void security_free_mnt_opt
> struct security_operations {
> char name[SECURITY_NAME_MAX + 1];
>
> - int (*ptrace_may_access) (struct task_struct *child, unsigned int mode);
> + int (*ptrace_access_check) (struct task_struct *child, unsigned int mode);
> int (*ptrace_traceme) (struct task_struct *parent);
> int (*capget) (struct task_struct *target,
> kernel_cap_t *effective,
> @@ -1617,7 +1617,7 @@ extern int security_module_enable(struct
> extern int register_security(struct security_operations *ops);
>
> /* Security operations */
> -int security_ptrace_may_access(struct task_struct *child, unsigned int mode);
> +int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
> int security_ptrace_traceme(struct task_struct *parent);
> int security_capget(struct task_struct *target,
> kernel_cap_t *effective,
> @@ -1798,10 +1798,10 @@ static inline int security_init(void)
> return 0;
> }
>
> -static inline int security_ptrace_may_access(struct task_struct *child,
> +static inline int security_ptrace_access_check(struct task_struct *child,
> unsigned int mode)
> {
> - return cap_ptrace_may_access(child, mode);
> + return cap_ptrace_access_check(child, mode);
> }
>
> static inline int security_ptrace_traceme(struct task_struct *parent)
> Index: linux/kernel/ptrace.c
> ===================================================================
> --- linux.orig/kernel/ptrace.c
> +++ linux/kernel/ptrace.c
> @@ -127,7 +127,7 @@ int ptrace_check_attach(struct task_stru
> return ret;
> }
>
> -int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> +int __ptrace_access_check(struct task_struct *task, unsigned int mode)
> {
> const struct cred *cred = current_cred(), *tcred;
>
> @@ -162,14 +162,14 @@ int __ptrace_may_access(struct task_stru
> if (!dumpable && !capable(CAP_SYS_PTRACE))
> return -EPERM;
>
> - return security_ptrace_may_access(task, mode);
> + return security_ptrace_access_check(task, mode);
> }
>
> -bool ptrace_may_access(struct task_struct *task, unsigned int mode)
> +bool ptrace_access_check(struct task_struct *task, unsigned int mode)
> {
> int err;
> task_lock(task);
> - err = __ptrace_may_access(task, mode);
> + err = __ptrace_access_check(task, mode);
> task_unlock(task);
> return !err;
> }
> @@ -217,7 +217,7 @@ repeat:
> /* the same process cannot be attached many times */
> if (task->ptrace & PT_PTRACED)
> goto bad;
> - retval = __ptrace_may_access(task, PTRACE_MODE_ATTACH);
> + retval = __ptrace_access_check(task, PTRACE_MODE_ATTACH);
> if (retval)
> goto bad;
>
> Index: linux/security/capability.c
> ===================================================================
> --- linux.orig/security/capability.c
> +++ linux/security/capability.c
> @@ -863,7 +863,7 @@ struct security_operations default_secur
>
> void security_fixup_ops(struct security_operations *ops)
> {
> - set_to_cap_if_null(ops, ptrace_may_access);
> + set_to_cap_if_null(ops, ptrace_access_check);
> set_to_cap_if_null(ops, ptrace_traceme);
> set_to_cap_if_null(ops, capget);
> set_to_cap_if_null(ops, capset);
> Index: linux/security/commoncap.c
> ===================================================================
> --- linux.orig/security/commoncap.c
> +++ linux/security/commoncap.c
> @@ -79,7 +79,7 @@ int cap_settime(struct timespec *ts, str
> }
>
> /**
> - * cap_ptrace_may_access - Determine whether the current process may access
> + * cap_ptrace_access_check - Determine whether the current process may access
> * another
> * @child: The process to be accessed
> * @mode: The mode of attachment.
> @@ -87,7 +87,7 @@ int cap_settime(struct timespec *ts, str
> * Determine whether a process may access another, returning 0 if permission
> * granted, -ve if denied.
> */
> -int cap_ptrace_may_access(struct task_struct *child, unsigned int mode)
> +int cap_ptrace_access_check(struct task_struct *child, unsigned int mode)
> {
> int ret = 0;
>
> Index: linux/security/root_plug.c
> ===================================================================
> --- linux.orig/security/root_plug.c
> +++ linux/security/root_plug.c
> @@ -72,7 +72,7 @@ static int rootplug_bprm_check_security
>
> static struct security_operations rootplug_security_ops = {
> /* Use the capability functions for some of the hooks */
> - .ptrace_may_access = cap_ptrace_may_access,
> + .ptrace_access_check = cap_ptrace_access_check,
> .ptrace_traceme = cap_ptrace_traceme,
> .capget = cap_capget,
> .capset = cap_capset,
> Index: linux/security/security.c
> ===================================================================
> --- linux.orig/security/security.c
> +++ linux/security/security.c
> @@ -127,9 +127,9 @@ int register_security(struct security_op
>
> /* Security operations */
>
> -int security_ptrace_may_access(struct task_struct *child, unsigned int mode)
> +int security_ptrace_access_check(struct task_struct *child, unsigned int mode)
> {
> - return security_ops->ptrace_may_access(child, mode);
> + return security_ops->ptrace_access_check(child, mode);
> }
>
> int security_ptrace_traceme(struct task_struct *parent)
> Index: linux/security/selinux/hooks.c
> ===================================================================
> --- linux.orig/security/selinux/hooks.c
> +++ linux/security/selinux/hooks.c
> @@ -1854,12 +1854,12 @@ static inline u32 open_file_to_av(struct
>
> /* Hook functions begin here. */
>
> -static int selinux_ptrace_may_access(struct task_struct *child,
> +static int selinux_ptrace_access_check(struct task_struct *child,
> unsigned int mode)
> {
> int rc;
>
> - rc = cap_ptrace_may_access(child, mode);
> + rc = cap_ptrace_access_check(child, mode);
> if (rc)
> return rc;
>
> @@ -5318,7 +5318,7 @@ static int selinux_key_getsecurity(struc
> static struct security_operations selinux_ops = {
> .name = "selinux",
>
> - .ptrace_may_access = selinux_ptrace_may_access,
> + .ptrace_access_check = selinux_ptrace_access_check,
> .ptrace_traceme = selinux_ptrace_traceme,
> .capget = selinux_capget,
> .capset = selinux_capset,
> Index: linux/security/smack/smack_lsm.c
> ===================================================================
> --- linux.orig/security/smack/smack_lsm.c
> +++ linux/security/smack/smack_lsm.c
> @@ -92,7 +92,7 @@ struct inode_smack *new_inode_smack(char
> */
>
> /**
> - * smack_ptrace_may_access - Smack approval on PTRACE_ATTACH
> + * smack_ptrace_access_check - Smack approval on PTRACE_ATTACH
> * @ctp: child task pointer
> * @mode: ptrace attachment mode
> *
> @@ -100,11 +100,11 @@ struct inode_smack *new_inode_smack(char
> *
> * Do the capability checks, and require read and write.
> */
> -static int smack_ptrace_may_access(struct task_struct *ctp, unsigned int mode)
> +static int smack_ptrace_access_check(struct task_struct *ctp, unsigned int mode)
> {
> int rc;
>
> - rc = cap_ptrace_may_access(ctp, mode);
> + rc = cap_ptrace_access_check(ctp, mode);
> if (rc != 0)
> return rc;
>
> @@ -2826,7 +2826,7 @@ static void smack_release_secctx(char *s
> struct security_operations smack_ops = {
> .name = "smack",
>
> - .ptrace_may_access = smack_ptrace_may_access,
> + .ptrace_access_check = smack_ptrace_access_check,
> .ptrace_traceme = smack_ptrace_traceme,
> .capget = cap_capget,
> .capset = cap_capset,
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> ----- End forwarded message -----
> ----- Forwarded message from Ingo Molnar <mingo@elte.hu> -----
>
> Date: Thu, 7 May 2009 11:50:54 +0200
> From: Ingo Molnar <mingo@elte.hu>
> To: Chris Wright <chrisw@sous-sol.org>
> Subject: [patch 2/2] ptrace: turn ptrace_access_check() into a retval
> function
> Cc: Oleg Nesterov <oleg@redhat.com>, Roland McGrath <roland@redhat.com>,
> Andrew Morton <akpm@linux-foundation.org>,
> linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
>
> ptrace_access_check() returns a bool, while most of the ptrace
> access check machinery works with Linux retvals (where 0 indicates
> success, negative indicates an error).
>
> So eliminate the bool and invert the usage at the call sites.
>
> ( Note: "< 0" checks are used instead of !0 checks, because that's
> the convention for retval checks and it results in similarly fast
> assembly code. )
>
> [ Impact: cleanup ]
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> fs/proc/array.c | 2 +-
> fs/proc/base.c | 8 ++++----
> fs/proc/task_mmu.c | 2 +-
> include/linux/ptrace.h | 2 +-
> kernel/ptrace.c | 6 ++++--
> 5 files changed, 11 insertions(+), 9 deletions(-)
>
> Index: linux/fs/proc/array.c
> ===================================================================
> --- linux.orig/fs/proc/array.c
> +++ linux/fs/proc/array.c
> @@ -366,7 +366,7 @@ static int do_task_stat(struct seq_file
>
> state = *get_task_state(task);
> vsize = eip = esp = 0;
> - permitted = ptrace_access_check(task, PTRACE_MODE_READ);
> + permitted = !ptrace_access_check(task, PTRACE_MODE_READ);
> mm = get_task_mm(task);
> if (mm) {
> vsize = task_vsize(mm);
> Index: linux/fs/proc/base.c
> ===================================================================
> --- linux.orig/fs/proc/base.c
> +++ linux/fs/proc/base.c
> @@ -222,7 +222,7 @@ static int check_mem_permission(struct t
> rcu_read_lock();
> match = (tracehook_tracer_task(task) == current);
> rcu_read_unlock();
> - if (match && ptrace_access_check(task, PTRACE_MODE_ATTACH))
> + if (match && !ptrace_access_check(task, PTRACE_MODE_ATTACH))
> return 0;
> }
>
> @@ -322,7 +322,7 @@ static int proc_pid_wchan(struct task_st
> wchan = get_wchan(task);
>
> if (lookup_symbol_name(wchan, symname) < 0)
> - if (!ptrace_access_check(task, PTRACE_MODE_READ))
> + if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
> return 0;
> else
> return sprintf(buffer, "%lu", wchan);
> @@ -559,7 +559,7 @@ static int proc_fd_access_allowed(struct
> */
> task = get_proc_task(inode);
> if (task) {
> - allowed = ptrace_access_check(task, PTRACE_MODE_READ);
> + allowed = !ptrace_access_check(task, PTRACE_MODE_READ);
> put_task_struct(task);
> }
> return allowed;
> @@ -938,7 +938,7 @@ static ssize_t environ_read(struct file
> if (!task)
> goto out_no_task;
>
> - if (!ptrace_access_check(task, PTRACE_MODE_READ))
> + if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
> goto out;
>
> ret = -ENOMEM;
> Index: linux/fs/proc/task_mmu.c
> ===================================================================
> --- linux.orig/fs/proc/task_mmu.c
> +++ linux/fs/proc/task_mmu.c
> @@ -656,7 +656,7 @@ static ssize_t pagemap_read(struct file
> goto out;
>
> ret = -EACCES;
> - if (!ptrace_access_check(task, PTRACE_MODE_READ))
> + if (ptrace_access_check(task, PTRACE_MODE_READ) < 0)
> goto out_task;
>
> ret = -EINVAL;
> Index: linux/include/linux/ptrace.h
> ===================================================================
> --- linux.orig/include/linux/ptrace.h
> +++ linux/include/linux/ptrace.h
> @@ -101,7 +101,7 @@ extern void ptrace_fork(struct task_stru
> /* Returns 0 on success, -errno on denial. */
> extern int __ptrace_access_check(struct task_struct *task, unsigned int mode);
> /* Returns true on success, false on denial. */
> -extern bool ptrace_access_check(struct task_struct *task, unsigned int mode);
> +extern int ptrace_access_check(struct task_struct *task, unsigned int mode);
>
> static inline int ptrace_reparented(struct task_struct *child)
> {
> Index: linux/kernel/ptrace.c
> ===================================================================
> --- linux.orig/kernel/ptrace.c
> +++ linux/kernel/ptrace.c
> @@ -165,13 +165,15 @@ int __ptrace_access_check(struct task_st
> return security_ptrace_access_check(task, mode);
> }
>
> -bool ptrace_access_check(struct task_struct *task, unsigned int mode)
> +int ptrace_access_check(struct task_struct *task, unsigned int mode)
> {
> int err;
> +
> task_lock(task);
> err = __ptrace_access_check(task, mode);
> task_unlock(task);
> - return !err;
> +
> + return err;
> }
>
> int ptrace_attach(struct task_struct *task)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> ----- End forwarded message -----
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2009-03-27 23:26 Eric Anholt
2009-03-28 0:02 ` your mail Linus Torvalds
0 siblings, 1 reply; 348+ messages in thread
From: Eric Anholt @ 2009-03-27 23:26 UTC (permalink / raw)
To: Linus Torvalds, lkml, dri-devel
[-- Attachment #1: Type: text/plain, Size: 4382 bytes --]
The following changes since commit be0ea69674ed95e1e98cb3687a241badc756d228:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../penberg/slab-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next
There's only one outside-of-i915 commit here (debugfs), and it's a
prereq for the i915 changes. airlied said he'd pulled my version into
his tree, so we should be OK with it going in through my tree since he
hasn't send a pull request out.
Short summary: Fixing lock order reversals finally. Piles of KMS fixes
as usual. Support for an unreleased chipset. And a bunch of
infrastructure for debugging info we're going to be adding in this
kernel so that just maybe we can get a better handle on these "I use my
machine for a few days and then the GPU falls over" bugs.
Ben Gamari (3):
drm: Convert proc files to seq_file and introduce debugfs
drm/i915: Convert i915 proc files to seq_file and move to debugfs.
drm/i915: Consolidate gem object list dumping
Chris Wilson (2):
drm/i915: Display fence register state in debugfs i915_gem_fence_regs node.
drm/i915: Check for dev->primary->master before dereference.
Eric Anholt (8):
drm/i915: Change DCC tiling detection case to cover only mobile parts.
drm/i915: Fix lock order reversal in GTT pwrite path.
drm/i915: Make GEM object's page lists refcounted instead of get/free.
drm/i915: Fix lock order reversal in shmem pwrite path.
drm/i915: Fix lock order reversal in shmem pread path.
drm/i915: Fix lock order reversal with cliprects and cmdbuf in non-DRI2 paths.
drm/i915: Fix lock order reversal in GEM relocation entry copying.
drm/i915: Add information on pinning and fencing to the i915 list debug.
Kristian Høgsberg (1):
drm/i915: Read the right SDVO register when detecting SVDO/HDMI.
Li Peng (1):
drm/i915: Fix LVDS dither setting
Ma Ling (2):
drm/i915: Use documented PLL timing limits for G4X platform
drm/i915: Use a different PLL timing search function on G4X.
Owain G. Ainsworth (1):
i915/drm: Remove two redundant agp_chipset_flushes
Shaohua Li (1):
agp/intel: Add support for new intel chipset.
Zhao Yakui (2):
drm/i915: Sync mode_valid/mode_set with intel video driver
drm/i915: Sync crt hotplug detection with intel video driver
Zhenyu Wang (4):
drm/i915: TV modes' parameters sync up with 2D driver
drm/i915: Fix TV get_modes to return modes count
drm/i915: TV mode_set sync up with 2D driver
drm/i915: TV detection fix
drivers/char/agp/intel-agp.c | 21 +-
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_debugfs.c | 235 ++++++++
drivers/gpu/drm/drm_drv.c | 12 +-
drivers/gpu/drm/drm_info.c | 328 +++++++++++
drivers/gpu/drm/drm_proc.c | 721 ++++---------------------
drivers/gpu/drm/drm_stub.c | 15 +-
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/i915_dma.c | 116 +++--
drivers/gpu/drm/i915/i915_drv.c | 6 +-
drivers/gpu/drm/i915/i915_drv.h | 21 +-
drivers/gpu/drm/i915/i915_gem.c | 898 +++++++++++++++++++++++++------
drivers/gpu/drm/i915/i915_gem_debugfs.c | 257 +++++++++
drivers/gpu/drm/i915/i915_gem_proc.c | 334 ------------
drivers/gpu/drm/i915/i915_gem_tiling.c | 31 +-
drivers/gpu/drm/i915/i915_reg.h | 22 +-
drivers/gpu/drm/i915/intel_bios.h | 12 +-
drivers/gpu/drm/i915/intel_crt.c | 66 ++-
drivers/gpu/drm/i915/intel_display.c | 406 +++++++++++++-
drivers/gpu/drm/i915/intel_lvds.c | 2 +-
drivers/gpu/drm/i915/intel_tv.c | 148 +++---
include/drm/drmP.h | 77 +++-
include/drm/drm_pciids.h | 2 +
23 files changed, 2431 insertions(+), 1304 deletions(-)
create mode 100644 drivers/gpu/drm/drm_debugfs.c
create mode 100644 drivers/gpu/drm/drm_info.c
create mode 100644 drivers/gpu/drm/i915/i915_gem_debugfs.c
delete mode 100644 drivers/gpu/drm/i915/i915_gem_proc.c
--
Eric Anholt
eric@anholt.net eric.anholt@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2009-03-27 23:26 Eric Anholt
@ 2009-03-28 0:02 ` Linus Torvalds
0 siblings, 0 replies; 348+ messages in thread
From: Linus Torvalds @ 2009-03-28 0:02 UTC (permalink / raw)
To: Eric Anholt; +Cc: lkml, dri-devel
On Fri, 27 Mar 2009, Eric Anholt wrote:
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next
Grr.
Guys, what the *hell* is wrong with you, when you can't even react to
trivial warnings and fix buggy code pointed out by the compiler?
If you had _ever_ compiled this on x86-64, you would have seen:
drivers/gpu/drm/i915/i915_gem_debugfs.c: In function ‘i915_gem_fence_regs_info’:
drivers/gpu/drm/i915/i915_gem_debugfs.c:201: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 7 has type ‘size_t’
and this is not the first time this has happened.
See commits f06da264cfb0f9444d41ca247213e419f90aa72a and
aeb565dfc3ac4c8b47c5049085b4c7bfb2c7d5d7.
What's so hard with keeping the build warning-clean, and fixing these
things _long_ before they hit my tree?
Some basic quality control. PLEASE.
Linus
^ permalink raw reply [flat|nested] 348+ messages in thread
[parent not found: <8F90F944E50427428C60E12A34A309D21C401BA619@carmd-exchmb01.sierrawireless.local>]
* Re: your mail
[not found] <8F90F944E50427428C60E12A34A309D21C401BA619@carmd-exchmb01.sierrawireless.local>
@ 2009-03-13 16:54 ` Ralf Nyren
0 siblings, 0 replies; 348+ messages in thread
From: Ralf Nyren @ 2009-03-13 16:54 UTC (permalink / raw)
To: Rory Filer; +Cc: linux-kernel, Kevin Lloyd
Hi Rory,
Sounds great, send the driver and I'll give it a try at once. I'll report back
to you with the results.
Many thanks, Ralf
On Fri, 13 Mar 2009, Rory Filer wrote:
> Hi Ralf
>
>
>
> Kevin passed your email on to my attention and I think we can help you with this problem. We've been doing a lot of work on our drivers lately and I've got a freshly-ready version of sierra.c just for 2.6.28. We've done a lot of testing here and it seems pretty robust; perhaps you'd be willing to give it a try?
>
>
>
> Since I'm not sure about the etiquette for posting to this list, so I will attach the driver in a separate email to you.
>
>
>
> Regards
>
>
>
> Rory Filer
>
>
>
>
>
> -----Original Message-----
>
> From: Ralf Nyren [mailto:ralf@nyren.net]
>
> Sent: Friday, March 13, 2009 8:01 AM
>
> To: linux-kernel@vger.kernel.org
>
> Cc: Kevin Lloyd
>
> Subject: Sierra Wireless (MC8780) HSDPA speed issue
>
>
>
> Hi,
>
>
>
> I have a Sierra Wireless MC8780 UMTS card in a Fujitsu S6410 laptop running kernel 2.6.28.7. In kernel sierra driver v1.3.2.
>
>
>
> The card works but speed seems limited to approx 1.0 Mbit/s download using the linux driver. Testing the card in Windows XP yields download speeds close to 5.0 Mbit/s.
>
>
>
> I recently updated the firmware of the card to support HSDPA/HSUPA. The update gave the desired result in Windows but not in Linux. The speed improved in Linux but didn't increase above 1 Mbit/s.
>
>
>
> Is there any known driver limitations or is this a configuration issue?
>
>
>
> Please let me know if you need any additional information.
>
>
>
> Best regards, Ralf
>
>
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2009-03-11 10:47 Vitaly Mayatskikh
2009-03-11 14:59 ` your mail Linus Torvalds
0 siblings, 1 reply; 348+ messages in thread
From: Vitaly Mayatskikh @ 2009-03-11 10:47 UTC (permalink / raw)
To: linux-kernel; +Cc: Linus Torvalds
Forgot to sign-off...
(v)scnprintf says it should return 0 when size is 0, but doesn't do
so. Also size_t is unsigned, it can't be less then 0. Fix the code and
comments.
Signed-off-by: Vitaly Mayatskikh <v.mayatskih@gmail.com>
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 0fbd012..8e75c7e 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -947,7 +947,7 @@ EXPORT_SYMBOL(vsnprintf);
* @args: Arguments for the format string
*
* The return value is the number of characters which have been written into
- * the @buf not including the trailing '\0'. If @size is <= 0 the function
+ * the @buf not including the trailing '\0'. If @size is == 0 the function
* returns 0.
*
* Call this function if you are already dealing with a va_list.
@@ -958,7 +958,8 @@ EXPORT_SYMBOL(vsnprintf);
int vscnprintf(char *buf, size_t size, const char *fmt, va_list args)
{
int i;
-
+ if (!size)
+ return 0;
i=vsnprintf(buf,size,fmt,args);
return (i >= size) ? (size - 1) : i;
}
@@ -998,7 +999,7 @@ EXPORT_SYMBOL(snprintf);
* @...: Arguments for the format string
*
* The return value is the number of characters written into @buf not including
- * the trailing '\0'. If @size is <= 0 the function returns 0.
+ * the trailing '\0'. If @size is == 0 the function returns 0.
*/
int scnprintf(char * buf, size_t size, const char *fmt, ...)
@@ -1006,6 +1007,8 @@ int scnprintf(char * buf, size_t size, const char *fmt, ...)
va_list args;
int i;
+ if (!size)
+ return 0;
va_start(args, fmt);
i = vsnprintf(buf, size, fmt, args);
va_end(args);
--
wbr, Vitaly
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: your mail
2009-03-11 10:47 Vitaly Mayatskikh
@ 2009-03-11 14:59 ` Linus Torvalds
2009-03-11 17:23 ` Vitaly Mayatskikh
0 siblings, 1 reply; 348+ messages in thread
From: Linus Torvalds @ 2009-03-11 14:59 UTC (permalink / raw)
To: Vitaly Mayatskikh; +Cc: linux-kernel
On Wed, 11 Mar 2009, Vitaly Mayatskikh wrote:
>
> (v)scnprintf says it should return 0 when size is 0, but doesn't do
> so. Also size_t is unsigned, it can't be less then 0. Fix the code and
> comments.
That is bogus.
The code really does (od "did"? Maybe you removed it) check for _smaller_
than 0:
int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
{
...
/* Reject out-of-range values early. Large positive sizes are
used for unknown buffer sizes. */
if (unlikely((int) size < 0)) {
/* There can be only one.. */
static char warn = 1;
WARN_ON(warn);
warn = 0;
return 0;
}
...
because under/overflows have happened.
The kernel is _not_ a regular libc. We have different rules.
Linus
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2009-03-11 14:59 ` your mail Linus Torvalds
@ 2009-03-11 17:23 ` Vitaly Mayatskikh
0 siblings, 0 replies; 348+ messages in thread
From: Vitaly Mayatskikh @ 2009-03-11 17:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Vitaly Mayatskikh, linux-kernel
> On Wed, 11 Mar 2009, Vitaly Mayatskikh wrote:
> >
> > (v)scnprintf says it should return 0 when size is 0, but doesn't do
> > so. Also size_t is unsigned, it can't be less then 0. Fix the code and
> > comments.
>
> That is bogus.
>
> The code really does (od "did"? Maybe you removed it) check for _smaller_
> than 0:
Well, (v)scnprintf says it returns 0 for size <= 0, but really returns
-1 for size == 0. I think, this code can't return 0 for size == 0:
i=vsnprintf(buf,size,fmt,args);
return (i >= size) ? (size - 1) : i;
Systemtap's script:
function test:long()
%{
char tmp[256];
long err;
err = scnprintf(tmp, 0, "%lu", (long)128);
THIS->__retvalue = err;
%}
probe begin
{
printf("scnprintf returns %d\n", test());
}
stap -g scnprintf.stp
scnprintf returns -1
--
wbr, Vitaly
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2009-02-13 0:45 Youngwhan Kim
2009-02-13 3:40 ` your mail Johannes Weiner
0 siblings, 1 reply; 348+ messages in thread
From: Youngwhan Kim @ 2009-02-13 0:45 UTC (permalink / raw)
To: linux-kernel
unsubscribe
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2009-01-19 2:54 Gao, Yunpeng
2009-01-19 3:07 ` your mail Matthew Wilcox
0 siblings, 1 reply; 348+ messages in thread
From: Gao, Yunpeng @ 2009-01-19 2:54 UTC (permalink / raw)
To: linux-ia64; +Cc: linux-kernel
Hi all,
I have to use 64bit variable in my 2.6.27 kernel NAND driver as below:
---------------------------------------------------------------------------
u64 NAND_capacity;
unsigned int block_num, block_size;
...
block_num = NAND_capacity / block_size;
---------------------------------------------------------------------------
but it failed when compiling and reports 'undefined reference to `__udivdi3'.
Does any idea about this? I need to include some special head file or change something in Kconfig?
BTW, the environment is Fedora Core 9, gcc 4.3.0.
Thanks a lot.
Rgds,
Yunpeng Gao
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2009-01-19 2:54 Gao, Yunpeng
@ 2009-01-19 3:07 ` Matthew Wilcox
0 siblings, 0 replies; 348+ messages in thread
From: Matthew Wilcox @ 2009-01-19 3:07 UTC (permalink / raw)
To: Gao, Yunpeng; +Cc: linux-ia64, linux-kernel
On Mon, Jan 19, 2009 at 10:54:02AM +0800, Gao, Yunpeng wrote:
> I have to use 64bit variable in my 2.6.27 kernel NAND driver as below:
> ---------------------------------------------------------------------------
> u64 NAND_capacity;
> unsigned int block_num, block_size;
> ...
> block_num = NAND_capacity / block_size;
> ---------------------------------------------------------------------------
> but it failed when compiling and reports 'undefined reference to `__udivdi3'.
Presumably block_size is a power of two, so you can do:
block_num = NAND_capacity >> block_shift;
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2009-01-13 6:10 Steven Rostedt
2009-01-13 13:21 ` your mail Steven Rostedt
0 siblings, 1 reply; 348+ messages in thread
From: Steven Rostedt @ 2009-01-13 6:10 UTC (permalink / raw)
To: linux-kernel
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2009-01-11 3:41 Jose Luis Marchetti
2009-01-11 6:47 ` your mail Jesper Juhl
0 siblings, 1 reply; 348+ messages in thread
From: Jose Luis Marchetti @ 2009-01-11 3:41 UTC (permalink / raw)
To: linux-kernel
Hi,
I would like to open/read/write/close a regular file from my device
driver.
I think it would be possible, but I am confused, the "The Linux Kernel
Module Programming Guide" states that I can not use standard libraries
from within a module, I know the standard library ends up calling
system calls, but which calls should I use to deal with regular
files ?
I am developing a Ethernet driver and the Mac address configuration
Thanks in advance!
José Luís Marchetti
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
@ 2008-05-24 20:05 Thomas Gleixner
2008-05-24 21:06 ` Daniel Walker
0 siblings, 1 reply; 348+ messages in thread
From: Thomas Gleixner @ 2008-05-24 20:05 UTC (permalink / raw)
To: Daniel Walker; +Cc: linux-kernel
On Sat, 24 May 2008, Daniel Walker wrote:
> > There is no kernel side controlled handover of a normal futex. The
> > woken up waiters race for it and a low prio thread on another CPU can
> > steal it even if there is a high prio waiter woken up.
>
> After reading futex_wake, Doesn't it depend how many waiters are woken?
> Given that comes from userspace, glibc could wake a single waiter and
> obtain a priority ordering, couldn't it?
It could and it does. Still this does not protect against another
lower prio task taking the futex before the woken waiter can do it,
which is happening way more often than your theoretical setscheduler
case. Again, setscheduler is called in startup code of a program not
at arbitrary points during runtime, which rely on lock ordering.
> > The plist add on works correct in most of the cases, nothing else. To
> > achieve full correctness there is much more necessary than this
> > setscheduler issue. The plist changes were accepted because the
> > overhead is really minimal, but achieving full correctness would hurt
> > performance badly.
>
> If that's the requirement then code that cleans up the corner case that
> I've identified, which is also minimal should be acceptable .. Since
> it's meeting the same requirement you layed out above for the original
> plist changes.
Your code solves the least to worry about corner case and hurts
performance for nothing. You take extra locks in the hot path for no
benefit.
Aside of that it introduces lock order problems and we can really do
without extra useless complexity in the futex code.
You can argue in circles. This is not going anywhere near mainline.
Thanks,
tglx
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2008-05-24 20:05 Thomas Gleixner
@ 2008-05-24 21:06 ` Daniel Walker
0 siblings, 0 replies; 348+ messages in thread
From: Daniel Walker @ 2008-05-24 21:06 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel
On Sat, 2008-05-24 at 22:05 +0200, Thomas Gleixner wrote:
> > If that's the requirement then code that cleans up the corner case that
> > I've identified, which is also minimal should be acceptable .. Since
> > it's meeting the same requirement you layed out above for the original
> > plist changes.
>
> Your code solves the least to worry about corner case and hurts
> performance for nothing. You take extra locks in the hot path for no
> benefit.
>
> Aside of that it introduces lock order problems and we can really do
> without extra useless complexity in the futex code.
>
> You can argue in circles. This is not going anywhere near mainline.
Above I'm not speaking about my code, I'm only speaking in terms of a
solution to this case, even if it isn't mine..
Daniel
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2008-05-20 12:34 Lukas Hejtmanek
2008-05-20 15:20 ` your mail Alan Stern
0 siblings, 1 reply; 348+ messages in thread
From: Lukas Hejtmanek @ 2008-05-20 12:34 UTC (permalink / raw)
To: Oliver Neukum
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, stern, greg, linux-usb
<stern@rowland.harvard.edu>, Greg KH <greg@kroah.com>
Bcc:
Subject: Re: [Bug #10630] USB devices plugged into dock are not discoverred
until reload of ehci-hcd
Reply-To:
In-Reply-To: <200805201327.34678.oliver@neukum.org>
X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb
On Tue, May 20, 2008 at 01:27:34PM +0200, Oliver Neukum wrote:
> > done.
> > http://bugzilla.kernel.org/show_bug.cgi?id=10630
>
> Aha. Thanks.
> Please recompile without CONFIG_USB_SUSPEND
Hm, without USB_SUSPEND it works. So what next, considered fixed or any
further investigation is needed?
--
Lukáš Hejtmánek
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2008-05-20 12:34 Lukas Hejtmanek
@ 2008-05-20 15:20 ` Alan Stern
0 siblings, 0 replies; 348+ messages in thread
From: Alan Stern @ 2008-05-20 15:20 UTC (permalink / raw)
To: Lukas Hejtmanek
Cc: Oliver Neukum, Rafael J. Wysocki, Linux Kernel Mailing List,
greg, linux-usb
On Tue, 20 May 2008, Lukas Hejtmanek wrote:
> <stern@rowland.harvard.edu>, Greg KH <greg@kroah.com>
> Bcc:
> Subject: Re: [Bug #10630] USB devices plugged into dock are not discoverred
> until reload of ehci-hcd
> Reply-To:
> In-Reply-To: <200805201327.34678.oliver@neukum.org>
> X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb
>
> On Tue, May 20, 2008 at 01:27:34PM +0200, Oliver Neukum wrote:
> > > done.
> > > http://bugzilla.kernel.org/show_bug.cgi?id=10630
> >
> > Aha. Thanks.
> > Please recompile without CONFIG_USB_SUSPEND
>
> Hm, without USB_SUSPEND it works. So what next, considered fixed or any
> further investigation is needed?
No further investigation is needed. I tried doing essentially the same
thing on my system and the same problem occurred.
It is caused by the way ehci-hcd "auto-clears" the port
change-suspend feature. This patch should fix the problem. Please
try it out and let us know if it works.
Alan Stern
Index: usb-2.6/drivers/usb/host/ehci.h
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci.h
+++ usb-2.6/drivers/usb/host/ehci.h
@@ -97,6 +97,8 @@ struct ehci_hcd { /* one per controlle
dedicated to the companion controller */
unsigned long owned_ports; /* which ports are
owned by the companion during a bus suspend */
+ unsigned long port_c_suspend; /* which ports have
+ the change-suspend feature turned on */
/* per-HC memory pools (could be per-bus, but ...) */
struct dma_pool *qh_pool; /* qh per active urb */
Index: usb-2.6/drivers/usb/host/ehci-hub.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/ehci-hub.c
+++ usb-2.6/drivers/usb/host/ehci-hub.c
@@ -609,7 +609,7 @@ static int ehci_hub_control (
}
break;
case USB_PORT_FEAT_C_SUSPEND:
- /* we auto-clear this feature */
+ clear_bit(wIndex, &ehci->port_c_suspend);
break;
case USB_PORT_FEAT_POWER:
if (HCS_PPC (ehci->hcs_params))
@@ -688,7 +688,7 @@ static int ehci_hub_control (
/* resume completed? */
else if (time_after_eq(jiffies,
ehci->reset_done[wIndex])) {
- status |= 1 << USB_PORT_FEAT_C_SUSPEND;
+ set_bit(wIndex, &ehci->port_c_suspend);
ehci->reset_done[wIndex] = 0;
/* stop resume signaling */
@@ -765,6 +765,8 @@ static int ehci_hub_control (
status |= 1 << USB_PORT_FEAT_RESET;
if (temp & PORT_POWER)
status |= 1 << USB_PORT_FEAT_POWER;
+ if (test_bit(wIndex, &ehci->port_c_suspend))
+ status |= 1 << USB_PORT_FEAT_C_SUSPEND;
#ifndef VERBOSE_DEBUG
if (status & ~0xffff) /* only if wPortChange is interesting */
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
@ 2007-10-17 18:28 nicholas.thompson1
0 siblings, 0 replies; 348+ messages in thread
From: nicholas.thompson1 @ 2007-10-17 18:28 UTC (permalink / raw)
To: linux-kernel
>Nope, wrong clues.
>The right clues are in the footer of this message after it travels thru the list.
>
>I supplied them to Nicholas already, but apparently others need to be reminded of
>them every now and then :-] That footer is in these list messages for a reason!
>
> /Matti Aarnio -- one of <postmaster@vger.kernel.org>
>
>PS: You want to contact VGER's email and list managers ?
> We use the internet email standard address "postmaster"
>
Jan, Matti, + List,
I am very sorry about the noise, that's what I get for using cut and paste while tired and before my third cup of coffee. ;p Apologies.
Nick
>>On Wed, Oct 17, 2007 at 06:36:19PM +0200, Jan Engelhardt wrote:
>> Date: Wed, 17 Oct 2007 18:36:19 +0200 (CEST)
>> From: Jan Engelhardt <jengelh@computergmbh.de>
>> To: nicholas.thompson1@mchsi.com
>> cc: linux-kernel@vger.kernel.org
>> Subject: Re: your mail
>>
>> On Oct 17 2007 16:30, nicholas.thompson1@mchsi.com wrote:
>> >Date: Wed, 17 Oct 2007 16:30:24 +0000
>> >From: <nicholas.thompson1@mchsi.com>
>> >To: <linux-kernel@vger.kernel.org>
>> ^^^^^^
> >>
> >>subscribe linux-alpha
>> ^^^^^
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2007-10-17 16:30 nicholas.thompson1
2007-10-17 16:36 ` your mail Jan Engelhardt
0 siblings, 1 reply; 348+ messages in thread
From: nicholas.thompson1 @ 2007-10-17 16:30 UTC (permalink / raw)
To: linux-kernel
subscribe linux-alpha
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2007-10-17 16:30 nicholas.thompson1
@ 2007-10-17 16:36 ` Jan Engelhardt
2007-10-17 17:50 ` Matti Aarnio
0 siblings, 1 reply; 348+ messages in thread
From: Jan Engelhardt @ 2007-10-17 16:36 UTC (permalink / raw)
To: nicholas.thompson1; +Cc: linux-kernel
On Oct 17 2007 16:30, nicholas.thompson1@mchsi.com wrote:
>Date: Wed, 17 Oct 2007 16:30:24 +0000
>From: <nicholas.thompson1@mchsi.com>
>To: <linux-kernel@vger.kernel.org>
^^^^^^
>
>subscribe linux-alpha
^^^^^
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2007-10-17 16:36 ` your mail Jan Engelhardt
@ 2007-10-17 17:50 ` Matti Aarnio
0 siblings, 0 replies; 348+ messages in thread
From: Matti Aarnio @ 2007-10-17 17:50 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linux-kernel
Nope, wrong clues.
The right clues are in the footer of this message after it travels thru the list.
I supplied them to Nicholas already, but apparently others need to be reminded of
them every now and then :-] That footer is in these list messages for a reason!
/Matti Aarnio -- one of <postmaster@vger.kernel.org>
PS: You want to contact VGER's email and list managers ?
We use the internet email standard address "postmaster"
On Wed, Oct 17, 2007 at 06:36:19PM +0200, Jan Engelhardt wrote:
> Date: Wed, 17 Oct 2007 18:36:19 +0200 (CEST)
> From: Jan Engelhardt <jengelh@computergmbh.de>
> To: nicholas.thompson1@mchsi.com
> cc: linux-kernel@vger.kernel.org
> Subject: Re: your mail
>
> On Oct 17 2007 16:30, nicholas.thompson1@mchsi.com wrote:
> >Date: Wed, 17 Oct 2007 16:30:24 +0000
> >From: <nicholas.thompson1@mchsi.com>
> >To: <linux-kernel@vger.kernel.org>
> ^^^^^^
> >
> >subscribe linux-alpha
> ^^^^^
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2007-09-24 20:44 Steven Rostedt
2007-09-24 20:50 ` your mail Steven Rostedt
0 siblings, 1 reply; 348+ messages in thread
From: Steven Rostedt @ 2007-09-24 20:44 UTC (permalink / raw)
To: Jaswinder Singh; +Cc: linux-kernel, mingo, linux-rt-users
linux-rt-users@vger.kernel.org
Bcc:
Subject: Re: realtime preemption performance difference
Reply-To:
In-Reply-To: <3f9a31f40709240448h4a9e8337t437328b5c675ecd5@mail.gmail.com>
On Mon, Sep 24, 2007 at 05:18:01PM +0530, Jaswinder Singh wrote:
> Hi all,
>
> I want to check performance difference by using realtime preemption patch :
>
> http://www.kernel.org/pub/linux/kernel/projects/rt/
>
> Please let me know from where I can download samples to test realtime
> preemption performance difference.
>
> Can someone please share performance numbers for your hardware:-
>
> 1. Interrupt latency
> 2. Task switching time
> 3. hard-realtime scheduling latency
>
see http://rt.wiki.kernel.org/index.php/Main_Page
There's also an RT mailing list for users (CC'd).
-- Steve
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
@ 2007-08-15 13:53 Stefan Richter
2007-08-15 14:35 ` Satyam Sharma
0 siblings, 1 reply; 348+ messages in thread
From: Stefan Richter @ 2007-08-15 13:53 UTC (permalink / raw)
To: Heiko Carstens
Cc: Herbert Xu, Chris Snook, satyam, clameter, linux-kernel,
linux-arch, torvalds, netdev, akpm, ak, davem, schwidefsky,
wensong, horms, wjiang, cfriesen, zlynx, rpjday, jesper.juhl,
segher
On 8/15/2007 10:18 AM, Heiko Carstens wrote:
> On Wed, Aug 15, 2007 at 02:49:03PM +0800, Herbert Xu wrote:
>> Chris Snook <csnook@redhat.com> wrote:
>> >
>> > Because atomic operations are generally used for synchronization, which requires
>> > volatile behavior. Most such codepaths currently use an inefficient barrier().
>> > Some forget to and we get bugs, because people assume that atomic_read()
>> > actually reads something, and atomic_write() actually writes something. Worse,
>> > these are architecture-specific, even compiler version-specific bugs that are
>> > often difficult to track down.
>>
>> I'm yet to see a single example from the current tree where
>> this patch series is the correct solution. So far the only
>> example has been a buggy piece of code which has since been
>> fixed with a cpu_relax.
>
> Btw.: we still have
>
> include/asm-i386/mach-es7000/mach_wakecpu.h: while (!atomic_read(deassert));
> include/asm-i386/mach-default/mach_wakecpu.h: while (!atomic_read(deassert));
>
> Looks like they need to be fixed as well.
I don't know if this here is affected:
/* drivers/ieee1394/ieee1394_core.h */
static inline unsigned int get_hpsb_generation(struct hpsb_host *host)
{
return atomic_read(&host->generation);
}
/* drivers/ieee1394/nodemgr.c */
static int nodemgr_host_thread(void *__hi)
{
[...]
for (;;) {
[... sleep until bus reset event ...]
/* Pause for 1/4 second in 1/16 second intervals,
* to make sure things settle down. */
g = get_hpsb_generation(host);
for (i = 0; i < 4 ; i++) {
if (msleep_interruptible(63) ||
kthread_should_stop())
goto exit;
/* Now get the generation in which the node ID's we collect
* are valid. During the bus scan we will use this generation
* for the read transactions, so that if another reset occurs
* during the scan the transactions will fail instead of
* returning bogus data. */
generation = get_hpsb_generation(host);
/* If we get a reset before we are done waiting, then
* start the waiting over again */
if (generation != g)
g = generation, i = 0;
}
[... scan bus, using generation ...]
}
exit:
[...]
}
--
Stefan Richter
-=====-=-=== =--- -====
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 13:53 [PATCH 0/24] make atomic_read() behave consistently across all architectures Stefan Richter
@ 2007-08-15 14:35 ` Satyam Sharma
2007-08-15 14:52 ` Herbert Xu
0 siblings, 1 reply; 348+ messages in thread
From: Satyam Sharma @ 2007-08-15 14:35 UTC (permalink / raw)
To: Stefan Richter
Cc: Heiko Carstens, Herbert Xu, Chris Snook, clameter,
Linux Kernel Mailing List, linux-arch, Linus Torvalds, netdev,
Andrew Morton, ak, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher
Hi Stefan,
On Wed, 15 Aug 2007, Stefan Richter wrote:
> On 8/15/2007 10:18 AM, Heiko Carstens wrote:
> > On Wed, Aug 15, 2007 at 02:49:03PM +0800, Herbert Xu wrote:
> >> Chris Snook <csnook@redhat.com> wrote:
> >> >
> >> > Because atomic operations are generally used for synchronization, which requires
> >> > volatile behavior. Most such codepaths currently use an inefficient barrier().
> >> > Some forget to and we get bugs, because people assume that atomic_read()
> >> > actually reads something, and atomic_write() actually writes something. Worse,
> >> > these are architecture-specific, even compiler version-specific bugs that are
> >> > often difficult to track down.
> >>
> >> I'm yet to see a single example from the current tree where
> >> this patch series is the correct solution. So far the only
> >> example has been a buggy piece of code which has since been
> >> fixed with a cpu_relax.
> >
> > Btw.: we still have
> >
> > include/asm-i386/mach-es7000/mach_wakecpu.h: while (!atomic_read(deassert));
> > include/asm-i386/mach-default/mach_wakecpu.h: while (!atomic_read(deassert));
> >
> > Looks like they need to be fixed as well.
>
>
> I don't know if this here is affected:
Yes, I think it is. You're clearly expecting the read to actually happen
when you call get_hpsb_generation(). It's clearly not a busy-loop, so
cpu_relax() sounds pointless / wrong solution for this case, so I'm now
somewhat beginning to appreciate the motivation behind this series :-)
But as I said, there are ways to achieve the same goals of this series
without using "volatile".
I think I'll submit a RFC/patch or two on this myself (will also fix
the code pieces listed here).
> /* drivers/ieee1394/ieee1394_core.h */
> static inline unsigned int get_hpsb_generation(struct hpsb_host *host)
> {
> return atomic_read(&host->generation);
> }
>
> /* drivers/ieee1394/nodemgr.c */
> static int nodemgr_host_thread(void *__hi)
> {
> [...]
>
> for (;;) {
> [... sleep until bus reset event ...]
>
> /* Pause for 1/4 second in 1/16 second intervals,
> * to make sure things settle down. */
> g = get_hpsb_generation(host);
> for (i = 0; i < 4 ; i++) {
> if (msleep_interruptible(63) ||
> kthread_should_stop())
> goto exit;
Totally unrelated, but this looks weird. IMHO you actually wanted:
msleep_interruptible(63);
if (kthread_should_stop())
goto exit;
here, didn't you? Otherwise the thread will exit even when
kthread_should_stop() != TRUE (just because it received a signal),
and it is not good for a kthread to exit on its own if it uses
kthread_should_stop() or if some other piece of kernel code could
eventually call kthread_stop(tsk) on it.
Ok, probably the thread will never receive a signal in the first
place because it's spawned off kthreadd which ignores all signals
beforehand, but still ...
[PATCH] ieee1394: Fix kthread stopping in nodemgr_host_thread
The nodemgr host thread can exit on its own even when kthread_should_stop
is not true, on receiving a signal (might never happen in practice, as
it ignores signals). But considering kthread_stop() must not be mixed with
kthreads that can exit on their own, I think changing the code like this
is clearer. This change means the thread can cut its sleep short when
receive a signal but looking at the code around, that sounds okay (and
again, it might never actually recieve a signal in practice).
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/ieee1394/nodemgr.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/ieee1394/nodemgr.c b/drivers/ieee1394/nodemgr.c
index 2ffd534..981a7da 100644
--- a/drivers/ieee1394/nodemgr.c
+++ b/drivers/ieee1394/nodemgr.c
@@ -1721,7 +1721,8 @@ static int nodemgr_host_thread(void *__hi)
* to make sure things settle down. */
g = get_hpsb_generation(host);
for (i = 0; i < 4 ; i++) {
- if (msleep_interruptible(63) || kthread_should_stop())
+ msleep_interruptible(63);
+ if (kthread_should_stop())
goto exit;
/* Now get the generation in which the node ID's we collect
^ permalink raw reply related [flat|nested] 348+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 14:35 ` Satyam Sharma
@ 2007-08-15 14:52 ` Herbert Xu
2007-08-15 16:09 ` Stefan Richter
0 siblings, 1 reply; 348+ messages in thread
From: Herbert Xu @ 2007-08-15 14:52 UTC (permalink / raw)
To: Satyam Sharma
Cc: Stefan Richter, Heiko Carstens, Chris Snook, clameter,
Linux Kernel Mailing List, linux-arch, Linus Torvalds, netdev,
Andrew Morton, ak, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher
On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
>
> > I don't know if this here is affected:
>
> Yes, I think it is. You're clearly expecting the read to actually happen
> when you call get_hpsb_generation(). It's clearly not a busy-loop, so
> cpu_relax() sounds pointless / wrong solution for this case, so I'm now
> somewhat beginning to appreciate the motivation behind this series :-)
Nope, we're calling schedule which is a rather heavy-weight
barrier.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 14:52 ` Herbert Xu
@ 2007-08-15 16:09 ` Stefan Richter
2007-08-15 16:27 ` Paul E. McKenney
0 siblings, 1 reply; 348+ messages in thread
From: Stefan Richter @ 2007-08-15 16:09 UTC (permalink / raw)
To: Herbert Xu
Cc: Satyam Sharma, Heiko Carstens, Chris Snook, clameter,
Linux Kernel Mailing List, linux-arch, Linus Torvalds, netdev,
Andrew Morton, ak, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher
Herbert Xu wrote:
> On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
>>> I don't know if this here is affected:
[...something like]
b = atomic_read(a);
for (i = 0; i < 4; i++) {
msleep_interruptible(63);
c = atomic_read(a);
if (c != b) {
b = c;
i = 0;
}
}
> Nope, we're calling schedule which is a rather heavy-weight
> barrier.
How does the compiler know that msleep() has got barrier()s?
--
Stefan Richter
-=====-=-=== =--- -====
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 16:09 ` Stefan Richter
@ 2007-08-15 16:27 ` Paul E. McKenney
2007-08-15 18:31 ` Segher Boessenkool
0 siblings, 1 reply; 348+ messages in thread
From: Paul E. McKenney @ 2007-08-15 16:27 UTC (permalink / raw)
To: Stefan Richter
Cc: Herbert Xu, Satyam Sharma, Heiko Carstens, Chris Snook, clameter,
Linux Kernel Mailing List, linux-arch, Linus Torvalds, netdev,
Andrew Morton, ak, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl, segher
On Wed, Aug 15, 2007 at 06:09:35PM +0200, Stefan Richter wrote:
> Herbert Xu wrote:
> > On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
> >>> I don't know if this here is affected:
>
> [...something like]
> b = atomic_read(a);
> for (i = 0; i < 4; i++) {
> msleep_interruptible(63);
> c = atomic_read(a);
> if (c != b) {
> b = c;
> i = 0;
> }
> }
>
> > Nope, we're calling schedule which is a rather heavy-weight
> > barrier.
>
> How does the compiler know that msleep() has got barrier()s?
Because msleep_interruptible() is in a separate compilation unit,
the compiler has to assume that it might modify any arbitrary global.
In many cases, the compiler also has to assume that msleep_interruptible()
might call back into a function in the current compilation unit, thus
possibly modifying global static variables.
Thanx, Paul
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 16:27 ` Paul E. McKenney
@ 2007-08-15 18:31 ` Segher Boessenkool
2007-08-15 18:57 ` Paul E. McKenney
0 siblings, 1 reply; 348+ messages in thread
From: Segher Boessenkool @ 2007-08-15 18:31 UTC (permalink / raw)
To: paulmck
Cc: horms, Stefan Richter, Satyam Sharma, Linux Kernel Mailing List,
rpjday, netdev, ak, cfriesen, Heiko Carstens, jesper.juhl,
linux-arch, Andrew Morton, zlynx, clameter, schwidefsky,
Chris Snook, Herbert Xu, davem, Linus Torvalds, wensong, wjiang
>> How does the compiler know that msleep() has got barrier()s?
>
> Because msleep_interruptible() is in a separate compilation unit,
> the compiler has to assume that it might modify any arbitrary global.
No; compilation units have nothing to do with it, GCC can optimise
across compilation unit boundaries just fine, if you tell it to
compile more than one compilation unit at once.
What you probably mean is that the compiler has to assume any code
it cannot currently see can do anything (insofar as allowed by the
relevant standards etc.)
> In many cases, the compiler also has to assume that
> msleep_interruptible()
> might call back into a function in the current compilation unit, thus
> possibly modifying global static variables.
It most often is smart enough to see what compilation-unit-local
variables might be modified that way, though :-)
Segher
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 18:31 ` Segher Boessenkool
@ 2007-08-15 18:57 ` Paul E. McKenney
2007-08-15 19:54 ` Satyam Sharma
0 siblings, 1 reply; 348+ messages in thread
From: Paul E. McKenney @ 2007-08-15 18:57 UTC (permalink / raw)
To: Segher Boessenkool
Cc: horms, Stefan Richter, Satyam Sharma, Linux Kernel Mailing List,
rpjday, netdev, ak, cfriesen, Heiko Carstens, jesper.juhl,
linux-arch, Andrew Morton, zlynx, clameter, schwidefsky,
Chris Snook, Herbert Xu, davem, Linus Torvalds, wensong, wjiang
On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
> >>How does the compiler know that msleep() has got barrier()s?
> >
> >Because msleep_interruptible() is in a separate compilation unit,
> >the compiler has to assume that it might modify any arbitrary global.
>
> No; compilation units have nothing to do with it, GCC can optimise
> across compilation unit boundaries just fine, if you tell it to
> compile more than one compilation unit at once.
Last I checked, the Linux kernel build system did compile each .c file
as a separate compilation unit.
> What you probably mean is that the compiler has to assume any code
> it cannot currently see can do anything (insofar as allowed by the
> relevant standards etc.)
Indeed.
> >In many cases, the compiler also has to assume that
> >msleep_interruptible()
> >might call back into a function in the current compilation unit, thus
> >possibly modifying global static variables.
>
> It most often is smart enough to see what compilation-unit-local
> variables might be modified that way, though :-)
Yep. For example, if it knows the current value of a given such local
variable, and if all code paths that would change some other variable
cannot be reached given that current value of the first variable.
At least given that gcc doesn't know about multiple threads of execution!
Thanx, Paul
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 18:57 ` Paul E. McKenney
@ 2007-08-15 19:54 ` Satyam Sharma
2007-08-15 20:47 ` Segher Boessenkool
0 siblings, 1 reply; 348+ messages in thread
From: Satyam Sharma @ 2007-08-15 19:54 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Segher Boessenkool, horms, Stefan Richter,
Linux Kernel Mailing List, rpjday, netdev, ak, cfriesen,
Heiko Carstens, jesper.juhl, linux-arch, Andrew Morton, zlynx,
clameter, schwidefsky, Chris Snook, Herbert Xu, davem,
Linus Torvalds, wensong, wjiang
[ The Cc: list scares me. Should probably trim it. ]
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
> > >>How does the compiler know that msleep() has got barrier()s?
> > >
> > >Because msleep_interruptible() is in a separate compilation unit,
> > >the compiler has to assume that it might modify any arbitrary global.
> >
> > No; compilation units have nothing to do with it, GCC can optimise
> > across compilation unit boundaries just fine, if you tell it to
> > compile more than one compilation unit at once.
>
> Last I checked, the Linux kernel build system did compile each .c file
> as a separate compilation unit.
>
> > What you probably mean is that the compiler has to assume any code
> > it cannot currently see can do anything (insofar as allowed by the
> > relevant standards etc.)
I think this was just terminology confusion here again. Isn't "any code
that it cannot currently see" the same as "another compilation unit",
and wouldn't the "compilation unit" itself expand if we ask gcc to
compile more than one unit at once? Or is there some more specific
"definition" for "compilation unit" (in gcc lingo, possibly?)
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
2007-08-15 19:54 ` Satyam Sharma
@ 2007-08-15 20:47 ` Segher Boessenkool
2007-08-16 0:36 ` Satyam Sharma
0 siblings, 1 reply; 348+ messages in thread
From: Segher Boessenkool @ 2007-08-15 20:47 UTC (permalink / raw)
To: Satyam Sharma
Cc: horms, Stefan Richter, Linux Kernel Mailing List,
Paul E. McKenney, ak, netdev, cfriesen, Heiko Carstens, rpjday,
jesper.juhl, linux-arch, Andrew Morton, zlynx, clameter,
schwidefsky, Chris Snook, Herbert Xu, davem, Linus Torvalds,
wensong, wjiang
>>> What you probably mean is that the compiler has to assume any code
>>> it cannot currently see can do anything (insofar as allowed by the
>>> relevant standards etc.)
>
> I think this was just terminology confusion here again. Isn't "any code
> that it cannot currently see" the same as "another compilation unit",
It is not; try gcc -combine or the upcoming link-time optimisation
stuff, for example.
> and wouldn't the "compilation unit" itself expand if we ask gcc to
> compile more than one unit at once? Or is there some more specific
> "definition" for "compilation unit" (in gcc lingo, possibly?)
"compilation unit" is a C standard term. It typically boils down
to "single .c file".
Segher
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
2007-08-15 20:47 ` Segher Boessenkool
@ 2007-08-16 0:36 ` Satyam Sharma
2007-08-16 0:32 ` your mail Herbert Xu
0 siblings, 1 reply; 348+ messages in thread
From: Satyam Sharma @ 2007-08-16 0:36 UTC (permalink / raw)
To: Segher Boessenkool
Cc: horms, Stefan Richter, Linux Kernel Mailing List,
Paul E. McKenney, ak, netdev, cfriesen, Heiko Carstens, rpjday,
jesper.juhl, linux-arch, Andrew Morton, zlynx, clameter,
schwidefsky, Chris Snook, Herbert Xu, davem, Linus Torvalds,
wensong, wjiang
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> > > > What you probably mean is that the compiler has to assume any code
> > > > it cannot currently see can do anything (insofar as allowed by the
> > > > relevant standards etc.)
> >
> > I think this was just terminology confusion here again. Isn't "any code
> > that it cannot currently see" the same as "another compilation unit",
>
> It is not; try gcc -combine or the upcoming link-time optimisation
> stuff, for example.
>
> > and wouldn't the "compilation unit" itself expand if we ask gcc to
> > compile more than one unit at once? Or is there some more specific
> > "definition" for "compilation unit" (in gcc lingo, possibly?)
>
> "compilation unit" is a C standard term. It typically boils down
> to "single .c file".
As you mentioned later, "single .c file with all the other files (headers
or other .c files) that it pulls in via #include" is actually "translation
unit", both in the C standard as well as gcc docs. "Compilation unit"
doesn't seem to be nearly as standard a term, though in most places it
is indeed meant to be same as "translation unit", but with the new gcc
inter-module-analysis stuff that you referred to above, I suspect one may
reasonably want to call a "compilation unit" as all that the compiler sees
at a given instant.
BTW I did some auditing (only inside include/asm-{i386,x86_64}/ and
arch/{i386,x86_64}/) and found a couple more callsites that don't use
cpu_relax():
arch/i386/kernel/crash.c:101
arch/x86_64/kernel/crash.c:97
that are:
while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
mdelay(1);
msecs--;
}
where mdelay() becomes __const_udelay() which happens to be in another
translation unit (arch/i386/lib/delay.c) and hence saves this callsite
from being a bug :-)
Curiously, __const_udelay() is still marked as "inline" where it is
implemented in lib/delay.c which is weird, considering it won't ever
be inlined, would it? With the kernel presently being compiled one
translation unit at a time, I don't see how the implementation would
be visible to any callsite out there to be able to inline it.
Satyam
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2007-08-16 0:36 ` Satyam Sharma
@ 2007-08-16 0:32 ` Herbert Xu
0 siblings, 0 replies; 348+ messages in thread
From: Herbert Xu @ 2007-08-16 0:32 UTC (permalink / raw)
To: Satyam Sharma
Cc: Segher Boessenkool, horms, Stefan Richter,
Linux Kernel Mailing List, Paul E. McKenney, ak, netdev,
cfriesen, Heiko Carstens, rpjday, jesper.juhl, linux-arch,
Andrew Morton, zlynx, clameter, schwidefsky, Chris Snook, davem,
Linus Torvalds, wensong, wjiang
On Thu, Aug 16, 2007 at 06:06:00AM +0530, Satyam Sharma wrote:
>
> that are:
>
> while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
> mdelay(1);
> msecs--;
> }
>
> where mdelay() becomes __const_udelay() which happens to be in another
> translation unit (arch/i386/lib/delay.c) and hence saves this callsite
> from being a bug :-)
The udelay itself certainly should have some form of cpu_relax in it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2007-05-16 13:30 Bob Picco
2007-05-16 16:43 ` your mail Linas Vepstas
0 siblings, 1 reply; 348+ messages in thread
From: Bob Picco @ 2007-05-16 13:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-dev
bob.picco@hp.com
Bcc:
Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
Reply-To:
In-Reply-To: <20070515201914.16944e04.akpm@linux-foundation.org>
/usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
/usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
make[3]: *** [drivers/pci/hotplug] Error 2
make[2]: *** [drivers/pci] Error 2
make[1]: *** [drivers] Error 2
make: *** [_all] Error 2
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.22-rc1-mm1
# Wed May 16 06:51:38 2007
#
CONFIG_PPC64=y
CONFIG_64BIT=y
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_PPC_UDBG_16550=y
CONFIG_GENERIC_TBSYNC=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_DEFAULT_UIMAGE is not set
#
# Processor support
#
# CONFIG_POWER4_ONLY is not set
CONFIG_POWER3=y
CONFIG_POWER4=y
CONFIG_PPC_FPU=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
# CONFIG_PPC_OF_PLATFORM_PCI is not set
# CONFIG_ALTIVEC is not set
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_MM_SLICES=y
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_SMP=y
CONFIG_NR_CPUS=32
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SWAP_PREFETCH=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CPUSETS is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROC_SMAPS=y
CONFIG_PROC_CLEAR_REFS=y
CONFIG_PROC_PAGEMAP=y
CONFIG_PROC_KPAGEMAP=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_EMBEDDED6xx is not set
# CONFIG_APUS is not set
CONFIG_PPC_PSERIES=y
# CONFIG_PPC_SPLPAR is not set
CONFIG_EEH=y
CONFIG_SCANLOG=y
CONFIG_LPARCFG=y
# CONFIG_PPC_ISERIES is not set
# CONFIG_PPC_MPC52xx is not set
# CONFIG_PPC_MPC5200 is not set
# CONFIG_PPC_PMAC is not set
# CONFIG_PPC_MAPLE is not set
CONFIG_PPC_PASEMI=y
#
# PA Semi PWRficient options
#
# CONFIG_PPC_PASEMI_IOMMU is not set
CONFIG_PPC_PASEMI_MDIO=y
# CONFIG_PPC_CELLEB is not set
# CONFIG_PPC_PS3 is not set
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PPC_IBM_CELL_BLADE is not set
# CONFIG_PQ2ADS is not set
CONFIG_PPC_NATIVE=y
# CONFIG_UDBG_RTAS_CONSOLE is not set
CONFIG_XICS=y
CONFIG_MPIC=y
# CONFIG_MPIC_WEIRD is not set
CONFIG_PPC_I8259=y
# CONFIG_U3_DART is not set
CONFIG_PPC_RTAS=y
CONFIG_RTAS_ERROR_LOGGING=y
CONFIG_RTAS_PROC=y
CONFIG_RTAS_FLASH=y
# CONFIG_MMIO_NVRAM is not set
CONFIG_IBMVIO=y
CONFIG_IBMEBUS=y
# CONFIG_PPC_MPC106 is not set
# CONFIG_PPC_970_NAP is not set
# CONFIG_PPC_INDIRECT_IO is not set
# CONFIG_GENERIC_IOMAP is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_CPM2 is not set
#
# Kernel options
#
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_FORCE_MAX_ZONEORDER=13
# CONFIG_IOMMU_VMERGE is not set
# CONFIG_HOTPLUG_CPU is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_IRQ_ALL_CPUS is not set
CONFIG_NUMA=y
CONFIG_NODES_SHIFT=4
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPARSEMEM_EXTREME=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_PPC_HAS_HASH_64K is not set
# CONFIG_PPC_64K_PAGES is not set
CONFIG_SCHED_SMT=y
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_PM is not set
CONFIG_SECCOMP=y
# CONFIG_WANT_DEVICE_TREE is not set
CONFIG_ISA_DMA_API=y
#
# Bus options
#
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
# CONFIG_PPC_INDIRECT_PCI is not set
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCCARD is not set
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
CONFIG_HOTPLUG_PCI_RPA=y
CONFIG_HOTPLUG_PCI_RPA_DLPAR=y
CONFIG_KERNEL_START=0xc000000000000000
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=y
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NF_CONNTRACK_ENABLED is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_QUEUE=y
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
#
# Wireless
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_MISC_STRANGE_DEV=y
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_BLINK is not set
# CONFIG_EEPROM_93CX6 is not set
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_PROC_FS=y
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
CONFIG_BLK_DEV_PDC202XX_NEW=y
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
CONFIG_BLK_DEV_SL82C105=y
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
CONFIG_SCSI_IPS=y
CONFIG_SCSI_IBMVSCSI=y
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
CONFIG_SCSI_IPR=y
CONFIG_SCSI_IPR_TRACE=y
CONFIG_SCSI_IPR_DUMP=y
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
CONFIG_SCSI_LPFC=y
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_ESP_CORE is not set
# CONFIG_SCSI_SRP is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MIRROR=y
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
CONFIG_IEEE1394_SUPPORT=y
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
# CONFIG_MAC_EMUMOUSEBTN is not set
# CONFIG_WINDFARM is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_BONDING=y
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_FIXED_PHY is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_IBMVETH=y
CONFIG_NET_PCI=y
CONFIG_PCNET32=y
# CONFIG_PCNET32_NAPI is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=y
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
CONFIG_EHEA=y
CONFIG_IXGB=y
# CONFIG_IXGB_NAPI is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
# CONFIG_PASEMI_MAC is not set
# CONFIG_MLX4_CORE is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_RTL818X is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET_MII is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_POLLDEV is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_ICOM is not set
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_OF_PLATFORM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_HVC_DRIVER=y
CONFIG_HVC_CONSOLE=y
# CONFIG_HVC_RTAS is not set
# CONFIG_HVCS is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_PASEMI=y
CONFIG_GEN_RTC=y
# CONFIG_GEN_RTC_X is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=256
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_CHARDEV is not set
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PASEMI is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_TINY_USB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
CONFIG_DAB=y
# CONFIG_USB_DABUSB is not set
#
# Graphics support
#
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_LCD_CLASS_DEVICE=y
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
CONFIG_FB_MACMODES=y
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
CONFIG_FB_OF=y
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G=y
CONFIG_FB_MATROX_I2C=y
CONFIG_FB_MATROX_MAVEN=y
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_IBM_GXT4500 is not set
# CONFIG_FB_VIRTUAL is not set
#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_SOUND is not set
#
# HID Devices
#
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PPC_OF=y
CONFIG_USB_OHCI_HCD_PPC_OF_BE=y
# CONFIG_USB_OHCI_HCD_PPC_OF_LE is not set
CONFIG_USB_OHCI_HCD_PCI=y
CONFIG_USB_OHCI_BIG_ENDIAN_DESC=y
CONFIG_USB_OHCI_BIG_ENDIAN_MMIO=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_UHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
CONFIG_USB_MON=y
#
# USB port drivers
#
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GOTEMP is not set
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_NEW_LEDS is not set
CONFIG_INFINIBAND=y
# CONFIG_INFINIBAND_USER_MAD is not set
# CONFIG_INFINIBAND_USER_ACCESS is not set
CONFIG_INFINIBAND_ADDR_TRANS=y
CONFIG_INFINIBAND_MTHCA=y
CONFIG_INFINIBAND_MTHCA_DEBUG=y
# CONFIG_INFINIBAND_IPATH is not set
# CONFIG_INFINIBAND_EHCA is not set
# CONFIG_INFINIBAND_AMSO1100 is not set
# CONFIG_MLX4_INFINIBAND is not set
CONFIG_INFINIBAND_IPOIB=y
# CONFIG_INFINIBAND_IPOIB_CM is not set
CONFIG_INFINIBAND_IPOIB_DEBUG=y
# CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set
# CONFIG_INFINIBAND_SRP is not set
# CONFIG_INFINIBAND_ISER is not set
#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set
#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set
#
# DMA Clients
#
CONFIG_ASYNC_TX_DMA=y
#
# DMA Devices
#
#
# Userspace I/O
#
# CONFIG_UIO is not set
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_EXT4DEV_FS=y
CONFIG_EXT4DEV_FS_XATTR=y
CONFIG_EXT4DEV_FS_POSIX_ACL=y
CONFIG_EXT4DEV_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISER4_FS is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
# CONFIG_REISERFS_FS_SECURITY is not set
CONFIG_JFS_FS=y
CONFIG_JFS_POSIX_ACL=y
# CONFIG_JFS_SECURITY is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=y
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_SECURITY is not set
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set
#
# Layered filesystems
#
# CONFIG_UNION_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_SUNRPC_BIND34 is not set
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=y
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=y
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Distributed Lock Manager
#
# CONFIG_DLM is not set
# CONFIG_UCC_SLOW is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
# CONFIG_LZO is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
#
# Instrumentation Support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_UNWIND_INFO is not set
# CONFIG_PROFILE_LIKELY is not set
CONFIG_FORCED_INLINING=y
# CONFIG_DEBUG_SYNCHRO_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HCALL_STATS=y
# CONFIG_DEBUGGER is not set
# CONFIG_IRQSTACKS is not set
# CONFIG_BOOTX_TEXT is not set
# CONFIG_PPC_EARLY_DEBUG is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_INTEGRITY is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_PCBC=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_KHAZAD=y
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_HW=y
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2007-05-16 13:30 Bob Picco
@ 2007-05-16 16:43 ` Linas Vepstas
2007-05-16 17:11 ` Olof Johansson
0 siblings, 1 reply; 348+ messages in thread
From: Linas Vepstas @ 2007-05-16 16:43 UTC (permalink / raw)
To: Bob Picco, johnrose; +Cc: Andrew Morton, linuxppc-dev, linux-kernel
On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
>
> /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> make[3]: *** [drivers/pci/hotplug] Error 2
> make[2]: *** [drivers/pci] Error 2
> make[1]: *** [drivers] Error 2
> make: *** [_all] Error 2
John Rose is working to fix this "real soon now".
--linas
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2007-05-16 16:43 ` your mail Linas Vepstas
@ 2007-05-16 17:11 ` Olof Johansson
2007-05-16 17:24 ` Bob Picco
0 siblings, 1 reply; 348+ messages in thread
From: Olof Johansson @ 2007-05-16 17:11 UTC (permalink / raw)
To: Linas Vepstas
Cc: Bob Picco, johnrose, linuxppc-dev, Andrew Morton, linux-kernel
On Wed, May 16, 2007 at 11:43:41AM -0500, Linas Vepstas wrote:
> On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> > Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> >
> > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> > make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> > make[3]: *** [drivers/pci/hotplug] Error 2
> > make[2]: *** [drivers/pci] Error 2
> > make[1]: *** [drivers] Error 2
> > make: *** [_all] Error 2
>
> John Rose is working to fix this "real soon now".
Do you mean the fix Al Viro posted yesterday?
http://patchwork.ozlabs.org/linuxppc/patch?id=11177
-Olof
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2007-05-16 17:11 ` Olof Johansson
@ 2007-05-16 17:24 ` Bob Picco
0 siblings, 0 replies; 348+ messages in thread
From: Bob Picco @ 2007-05-16 17:24 UTC (permalink / raw)
To: Olof Johansson
Cc: Linas Vepstas, Bob Picco, johnrose, linuxppc-dev, Andrew Morton,
linux-kernel
Olof Johansson wrote: [Wed May 16 2007, 01:11:00PM EDT]
> On Wed, May 16, 2007 at 11:43:41AM -0500, Linas Vepstas wrote:
> > On Wed, May 16, 2007 at 09:30:46AM -0400, Bob Picco wrote:
> > > Subject: Re: 2.6.22-rc1-mm1 powerpc build breakage
> > >
> > > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `subsys' specified in initializer
> > > /usr/src/linux-2.6.22-rc1-mm1/drivers/pci/hotplug/rpadlpar_sysfs.c:132: warning: initialization from incompatible pointer type
> > > make[4]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
> > > make[3]: *** [drivers/pci/hotplug] Error 2
> > > make[2]: *** [drivers/pci] Error 2
> > > make[1]: *** [drivers] Error 2
> > > make: *** [_all] Error 2
> >
> > John Rose is working to fix this "real soon now".
>
> Do you mean the fix Al Viro posted yesterday?
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=11177
>
>
> -Olof
Missed that patch.
thanks,
bob
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2007-03-29 21:39 Gerard Braad Jr.
2007-03-29 21:42 ` your mail Jan Engelhardt
0 siblings, 1 reply; 348+ messages in thread
From: Gerard Braad Jr. @ 2007-03-29 21:39 UTC (permalink / raw)
To: linux-kernel
unsubscribe linux-kernel gbraad@member.fsf.org
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2007-02-05 15:41 logic
2007-02-05 12:36 ` your mail Joerg Roedel
0 siblings, 1 reply; 348+ messages in thread
From: logic @ 2007-02-05 15:41 UTC (permalink / raw)
To: linux-kernel
Good morning,
I am experiencing a bug i think. I am running a 2.6.19.2 kernel on a 3Ghz
Intel with HT activated, 1 gb ram, and noname motherboard. Here is the
output of the hang:
------------[ cut here ]------------
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: kernel BUG at mm/slab.c:607!
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: invalid opcode: 0000 [#1]
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: CPU: 1
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: EIP: 0060:[<c0155ebb>] Not tainted VLI
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: eax: 1af3a451 ebx: c89ba000 ecx: 4a5ffc80 edx: c214bfe0
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: ds: 007b es: 007b ss: 0068
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: EIP is at free_block+0x44/0xda
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: PREEMPT SMP
mail kernel: EFLAGS: 00010046 (2.6.19.2 #1)
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: Call Trace:
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: =======================
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: Process events/1 (pid: 9, ti=c19b6000 task=c1983a90
task.ti=c19b6000)
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: Stack: 00000000 0000001e c196d018 c196d018 0000001e c196d000
00000000 c015664d
Message from syslogd@mail at Fri Feb 2 22:47:32 2007 ...
mail kernel: 00000000 00000000 c196fc80 c19485c0 c196fc80 c19485c0
c194b140 00000213
--
--
Va salut,
Alexandru Gheorghita
Technical Manager
Think.Net
phone: 0788.700.842
mail: logic@thinknet.ro
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2007-02-05 15:41 logic
@ 2007-02-05 12:36 ` Joerg Roedel
2007-02-05 14:01 ` Pekka Enberg
0 siblings, 1 reply; 348+ messages in thread
From: Joerg Roedel @ 2007-02-05 12:36 UTC (permalink / raw)
To: logic; +Cc: linux-kernel
On Mon, Feb 05, 2007 at 05:41:29PM +0200, logic@thinknet.ro wrote:
> Good morning,
>
> I am experiencing a bug i think. I am running a 2.6.19.2 kernel on a 3Ghz
> Intel with HT activated, 1 gb ram, and noname motherboard. Here is the
> output of the hang:
Hmm, this seems to be the same issue as in [1] and [2]. A page that is
assumed to belong to the slab but is not longer marked as a slab page.
Could this be a bug in the memory management?
Joerg
[1] http://lkml.org/lkml/2007/2/4/77
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406477
--
Joerg Roedel
Operating System Research Center
AMD Saxony LLC & Co. KG
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2007-02-05 12:36 ` your mail Joerg Roedel
@ 2007-02-05 14:01 ` Pekka Enberg
2007-02-06 9:41 ` Joerg Roedel
0 siblings, 1 reply; 348+ messages in thread
From: Pekka Enberg @ 2007-02-05 14:01 UTC (permalink / raw)
To: Joerg Roedel; +Cc: logic, linux-kernel
Hi Joerg,
On 2/5/07, Joerg Roedel <joerg.roedel@amd.com> wrote:
> Hmm, this seems to be the same issue as in [1] and [2]. A page that is
> assumed to belong to the slab but is not longer marked as a slab page.
> Could this be a bug in the memory management?
The BUG_ON triggers whenever you feed an invalid pointer to kfree() or
kmem_cache_free() so I am guessing the caller is simply broken. Note
that kernels prior to 2.6.18 would quietly corrupt the slab unless
CONFIG_SLAB_DEBUG was enabled which might explain why this hasn't been
noticed before.
Pekka
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2007-02-05 14:01 ` Pekka Enberg
@ 2007-02-06 9:41 ` Joerg Roedel
0 siblings, 0 replies; 348+ messages in thread
From: Joerg Roedel @ 2007-02-06 9:41 UTC (permalink / raw)
To: Pekka Enberg; +Cc: logic, linux-kernel
On Mon, Feb 05, 2007 at 04:01:23PM +0200, Pekka Enberg wrote:
> Hi Joerg,
>
> On 2/5/07, Joerg Roedel <joerg.roedel@amd.com> wrote:
> >Hmm, this seems to be the same issue as in [1] and [2]. A page that is
> >assumed to belong to the slab but is not longer marked as a slab page.
> >Could this be a bug in the memory management?
>
> The BUG_ON triggers whenever you feed an invalid pointer to kfree() or
> kmem_cache_free() so I am guessing the caller is simply broken. Note
> that kernels prior to 2.6.18 would quietly corrupt the slab unless
> CONFIG_SLAB_DEBUG was enabled which might explain why this hasn't been
> noticed before.
Ok. I was not aware of that. Thanks for clarification.
Joerg
--
Joerg Roedel
Operating System Research Center
AMD Saxony LLC & Co. KG
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2005-11-25 22:06 root
2005-11-26 0:11 ` your mail Hugh Dickins
0 siblings, 1 reply; 348+ messages in thread
From: root @ 2005-11-25 22:06 UTC (permalink / raw)
To: linux-kernel
Nov 25 21:59:24 txiringo kernel: [17182458.504000] program ddcprobe is using MAP_PRIVATE, PROT_WRITE mmap of VM_RESERVED memory, which is deprecated. Please report this to linux-kernel@vger.kernel.org
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2005-11-25 22:06 root
@ 2005-11-26 0:11 ` Hugh Dickins
0 siblings, 0 replies; 348+ messages in thread
From: Hugh Dickins @ 2005-11-26 0:11 UTC (permalink / raw)
To: root; +Cc: linux-kernel
On Fri, 25 Nov 2005, root wrote:
> Nov 25 21:59:24 txiringo kernel: [17182458.504000] program ddcprobe
> is using MAP_PRIVATE, PROT_WRITE mmap of VM_RESERVED memory, which
> is deprecated. Please report this to linux-kernel@vger.kernel.org
Thanks for the report: now fixed, please upgrade to 2.6.15-rc2-git3 or later.
Hugh
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2005-06-16 23:08 trmcneal
2005-06-16 23:32 ` your mail Chris Wedgwood
0 siblings, 1 reply; 348+ messages in thread
From: trmcneal @ 2005-06-16 23:08 UTC (permalink / raw)
To: linux-kernel
I posted this on linux-net, and got only one reply, saying that they
had run into this as well. Not much help. I'm thinking that I need to
tune the kernel somehow to prevent this, but I'm not sure how. It doesn't
happen on Solaris, and seems to be a resource issue, but its probably
not memory. Here are the details:
> I've been working with some tcp network test programs that have
> multiple clients opening nonblocking sockets to a single server port,
> sending a short message, and then closing the socket, 100,000 times.
> Since the socket is non-blocking, it generally tries to connect and then
> does a poll since the socket is busy. The test fails if the poll times out in
> 10 seconds. It fails consistently on Linux servers but succeeds on Solaris
> servers; the client is a non-issue unless its loopback on the Linux server.
> This issue crops up both on 2.4 and 2.6 kernels; the main feature seen
> in tcp dumps is that the server gets inundated with retrys, and then starts
> sending RST responses to everything (labelled as ZeroWindow in a
> Ethereal dump). One interesting feature is that many clients thinks the
> 3-way connection handshake is complete, when the server actually
> doesn't get the final ACK; The client starts sending and then retransmitting
> the data, and the server keeps sending back the SYN/ACK part of the
> handshake. Another interesting feature is a group of retries from various
> client ports, followed by a group of ACK,RST responses from the server,
> followed by the ZeroWindow RST to everything.
> On Linux, the only way to succeed is to use remote clients - thus avoiding
> extra work on the server -and changing test parameters to put in a longer
> server delay, which is inserted between the closing of one connection and
> the opening of the next. I'm assuming that the tcp network queues are just
> getting overloaded with the data retransmissions, but I don't know enough
> about the queue management yet. Any suggestions/pointers/fixes?
Any ideas about tuning, or what resource I'm running out of?
Regards -
Tom McNeal
--
Tom McNeal
(650)906-0761(cell)
(650)964-8459(fax)
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2005-06-16 23:08 trmcneal
@ 2005-06-16 23:32 ` Chris Wedgwood
2005-06-17 1:46 ` Tom McNeal
0 siblings, 1 reply; 348+ messages in thread
From: Chris Wedgwood @ 2005-06-16 23:32 UTC (permalink / raw)
To: trmcneal; +Cc: linux-kernel
On Thu, Jun 16, 2005 at 11:08:28PM +0000, trmcneal@comcast.net wrote:
> > I've been working with some tcp network test programs that have
> > multiple clients opening nonblocking sockets to a single server
> > port, sending a short message, and then closing the socket,
> > 100,000 times. Since the socket is non-blocking, it generally
> > tries to connect and then does a poll since the socket is busy.
> > The test fails if the poll times out in 10 seconds. It fails
> > consistently on Linux servers but succeeds on Solaris servers; the
> > client is a non-issue unless its loopback on the Linux server.
where is the code for this? are you sure you're not overflowing the
listen backlog somewhere? that would show up in some cases but not
all depending on latencies and local scheduler behavior
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2005-06-16 23:32 ` your mail Chris Wedgwood
@ 2005-06-17 1:46 ` Tom McNeal
0 siblings, 0 replies; 348+ messages in thread
From: Tom McNeal @ 2005-06-17 1:46 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: linux-kernel
I'll look at that. This occurs on all Linux platforms, including a generic
2.4.31 I downloaded from kernel.org. The user test is trivial, just doing
the nonblocking connect, the poll, the send, and then the close, in that loop.
Tom
Chris Wedgwood wrote:
> On Thu, Jun 16, 2005 at 11:08:28PM +0000, trmcneal@comcast.net wrote:
>
>
>>>I've been working with some tcp network test programs that have
>>>multiple clients opening nonblocking sockets to a single server
>>>port, sending a short message, and then closing the socket,
>>>100,000 times. Since the socket is non-blocking, it generally
>>>tries to connect and then does a poll since the socket is busy.
>>>The test fails if the poll times out in 10 seconds. It fails
>>>consistently on Linux servers but succeeds on Solaris servers; the
>>>client is a non-issue unless its loopback on the Linux server.
>
>
> where is the code for this? are you sure you're not overflowing the
> listen backlog somewhere? that would show up in some cases but not
> all depending on latencies and local scheduler behavior
>
--
Tom McNeal
(650)906-0761(cell)
(650)964-8459(fax)
Email: trmcneal@comcast.net
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2005-02-03 0:17 Aleksey Gorelov
2005-02-03 1:12 ` your mail Matthew Dharm
2005-02-03 16:03 ` Alan Stern
0 siblings, 2 replies; 348+ messages in thread
From: Aleksey Gorelov @ 2005-02-03 0:17 UTC (permalink / raw)
To: stern, mdharm-usb; +Cc: linux-kernel
Hi Matt, Alan,
Could you please tell me (link would do) why it makes default
delay_use=5
really necessary (from the patch below)?
https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074
7.html
It makes USB boot really painfull and slow :(
I understand there should be a good reason for it. I've tried to find
an answer in
archives, without much success though.
Thanks,
Aleks.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2005-02-03 0:17 Aleksey Gorelov
@ 2005-02-03 1:12 ` Matthew Dharm
2005-02-03 16:03 ` Alan Stern
1 sibling, 0 replies; 348+ messages in thread
From: Matthew Dharm @ 2005-02-03 1:12 UTC (permalink / raw)
To: Aleksey Gorelov; +Cc: stern, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]
It's basically just like the code says.
A lot of devices choke if you access them too quickly after enumeration.
The 5 second delay seems to be enough for most devices. But we made it
adjustable exactly for people like you.
Matt
On Wed, Feb 02, 2005 at 04:17:13PM -0800, Aleksey Gorelov wrote:
> Hi Matt, Alan,
>
> Could you please tell me (link would do) why it makes default
> delay_use=5
> really necessary (from the patch below)?
> https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074
> 7.html
>
> It makes USB boot really painfull and slow :(
>
> I understand there should be a good reason for it. I've tried to find
> an answer in
> archives, without much success though.
>
> Thanks,
> Aleks.
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
Now payink attention, please. This is mouse. Click-click. Easy to
use, da? Now you try...
-- Pitr to Miranda
User Friendly, 10/11/1998
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2005-02-03 0:17 Aleksey Gorelov
2005-02-03 1:12 ` your mail Matthew Dharm
@ 2005-02-03 16:03 ` Alan Stern
1 sibling, 0 replies; 348+ messages in thread
From: Alan Stern @ 2005-02-03 16:03 UTC (permalink / raw)
To: Aleksey Gorelov; +Cc: mdharm-usb, linux-kernel
On Wed, 2 Feb 2005, Aleksey Gorelov wrote:
> Hi Matt, Alan,
>
> Could you please tell me (link would do) why it makes default
> delay_use=5
> really necessary (from the patch below)?
> https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/00074
> 7.html
>
> It makes USB boot really painfull and slow :(
>
> I understand there should be a good reason for it. I've tried to find
> an answer in
> archives, without much success though.
Lots of devices don't need that delay, but enough of them do that we
decided to add it. The value of 5 seconds was more or less arbitrary; it
was long enough for every device we could test and it didn't seem _too_
long. Maybe 1 second would be long enough -- we just didn't know so we
were conservative.
Alan Stern
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2004-09-19 12:29 plt
2004-09-19 18:22 ` your mail Jesper Juhl
0 siblings, 1 reply; 348+ messages in thread
From: plt @ 2004-09-19 12:29 UTC (permalink / raw)
To: linux-kernel
Question: Are you guys going to work on please cleaning up some of the errors in
the code so we can get please get a more clean compile?
drivers/mtd/nftlmount.c:44: warning: unused variable `oob'
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-09-19 12:29 plt
@ 2004-09-19 18:22 ` Jesper Juhl
0 siblings, 0 replies; 348+ messages in thread
From: Jesper Juhl @ 2004-09-19 18:22 UTC (permalink / raw)
To: plt; +Cc: linux-kernel
On Sun, 19 Sep 2004 plt@taylorassociate.com wrote:
> Question: Are you guys going to work on please cleaning up some of the errors in
> the code so we can get please get a more clean compile?
>
I think it's safe to say that there is an ongoing effort to do that.
Some more strict typechecking has recently been introduced (read more
here: http://kerneltrap.org/node/view/3848 ) and this currently cause a
lot of compiler warnings that have yet to be cleaned, but that will happen
in time - faster if you lend a hand.
>
> drivers/mtd/nftlmount.c:44: warning: unused variable `oob'
>
This is due to the fact that the code using that variable is currently
within an #if 0 block. I am not familiar with the mtd code, but the
comment in there has this to say :
#if 0 /* Some people seem to have devices without ECC or erase marks
on the Media Header blocks. There are enough other sanity
checks in here that we can probably do without it.
*/
...
#endif
So it would seem that this bit of code could be on its way out. I'd assume
that once it goes (if it does) that the variable will then be removed as
well.
Ohh and btw, if you want people to pay attention to your emails you should
try adding a descriptive Subject: :)
--
Jesper Juhl
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
@ 2004-08-16 15:42 Jon Smirl
2004-08-16 23:55 ` Dave Airlie
0 siblings, 1 reply; 348+ messages in thread
From: Jon Smirl @ 2004-08-16 15:42 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel, Dave Airlie
Graphics drivers in the kernel are broken. The kernel was never
designed to have two device drivers trying to control the same piece of
hardware.
I have posted a long list of 25 points that we are working towards to
unify things. http://lkml.org/lkml/2004/8/2/111 The PCI ROM patch that
has been posted recently addresses the first one.
In the meanwhile we have to transition somehow between what we have and
where we are going. Since fbdev has taken the path to pretend that DRM
doesn't exist DRM has to go through a lot of trouble to work when fbdev
is in the system. DRM also has to work when fbdev is not in the system.
DRM is being reworked into a first class driver with full support for
2.6 and hotplug. Part of being a first class driver means that DRM has
to register itself with the kernel like a real driver and claim all of
it's resources. I'm also fixing the driver to use 2.6 module parameters
and to support dynamic assignment of minors. Sysfs support is in the
patch being discussed.
But DRM still has to live with existing fbdev drivers. The same DRM
code is used in 2.4 and 2.6 so existing fbdev drivers are not going
away anytime soon. When DRM detects a fbdev it will revert back into
stealth mode where is attaches itself to the hardware without telling
the kernel that it is doing so. DRM can not use stealth mode when
running without fbdev present since it will mess up hotplug by not
marking the resources in use.
I don't believe the ordering between fbdev and DRM is an issue. If you
are using fbdev you likely have it compiled in. In that case fbdev
always loads first and DRM second. In the non-ppc world, most of us
have x86 boxes which don't use fbdev. In those machines DRM needs to be
a first class driver. In the real world I don't know anyone other than
a developer who would load DRM first and then fbdev. If this is a
problem you will need to fixed fbdev to fall back into stealth mode
like DRM does.
I would like to encourage you to work towards the points on the above
referenced list. It has been widely distributed and commented on. It
has been posted to lkml, dri-dev, fb-dev and xorg lists and discussed
at OLS.
Sorry, but I can't add an In-Reply-To header in the middle of thread on
yahoo. cc me on a reply to the main thread so that I will pick up the header.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 15:42 Jon Smirl
@ 2004-08-16 23:55 ` Dave Airlie
0 siblings, 0 replies; 348+ messages in thread
From: Dave Airlie @ 2004-08-16 23:55 UTC (permalink / raw)
To: Jon Smirl; +Cc: Christoph Hellwig, torvalds, Andrew Morton, linux-kernel
> But DRM still has to live with existing fbdev drivers. The same DRM
> code is used in 2.4 and 2.6 so existing fbdev drivers are not going
> away anytime soon. When DRM detects a fbdev it will revert back into
> stealth mode where is attaches itself to the hardware without telling
> the kernel that it is doing so. DRM can not use stealth mode when
> running without fbdev present since it will mess up hotplug by not
> marking the resources in use.
>
> I don't believe the ordering between fbdev and DRM is an issue. If you
> are using fbdev you likely have it compiled in. In that case fbdev
> always loads first and DRM second. In the non-ppc world, most of us
> have x86 boxes which don't use fbdev. In those machines DRM needs to be
> a first class driver. In the real world I don't know anyone other than
> a developer who would load DRM first and then fbdev. If this is a
> problem you will need to fixed fbdev to fall back into stealth mode
> like DRM does.
This is a good point, we are being forced into stealth mode by the fb
driver if they want to load after us they should respsect us and do the
same, (nope this isn't an us and them, DRM vs fb - I think we have a
solution and are heading the correct direction)...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 348+ messages in thread
* (no subject)
@ 2004-08-15 12:19 Dave Airlie
2004-08-15 12:34 ` your mail Christoph Hellwig
0 siblings, 1 reply; 348+ messages in thread
From: Dave Airlie @ 2004-08-15 12:19 UTC (permalink / raw)
To: torvalds, Andrew Morton; +Cc: linux-kernel
Hi Linus/Andrew,
I'd like to merge up the DRM tree to the stable branch, these patches have
been in -mm since I added them, they include a new i915 drm from Tungsten
Graphics, and the DRM now uses PCI properly if no framebuffer is loaded
(it falls back if framebuffer is enabled...), the next DRM changes are
lined up on a CVS branch - they start detemplating the DRM...
Please do a
bk pull bk://drm.bkbits.net/drm-2.6
This will include the latest DRM changes and will update the following files:
drivers/char/drm/Kconfig | 17
drivers/char/drm/Makefile | 2
drivers/char/drm/drm.h | 4
drivers/char/drm/drmP.h | 18
drivers/char/drm/drm_bufs.h | 1
drivers/char/drm/drm_drv.h | 188 ++++++---
drivers/char/drm/drm_ioctl.h | 2
drivers/char/drm/drm_os_linux.h | 4
drivers/char/drm/drm_pciids.h | 8
drivers/char/drm/drm_proc.h | 17
drivers/char/drm/drm_stub.h | 201 +++++++---
drivers/char/drm/gamma_old_dma.h | 69 ++-
drivers/char/drm/i810_dma.c | 7
drivers/char/drm/i830_dma.c | 12
drivers/char/drm/i915.h | 95 ++++
drivers/char/drm/i915_dma.c | 760 +++++++++++++++++++++++++++++++++++++++
drivers/char/drm/i915_drm.h | 162 ++++++++
drivers/char/drm/i915_drv.c | 31 +
drivers/char/drm/i915_drv.h | 228 +++++++++++
drivers/char/drm/i915_irq.c | 173 ++++++++
drivers/char/drm/i915_mem.c | 361 ++++++++++++++++++
drivers/char/drm/sis_mm.c | 7
22 files changed, 2194 insertions(+), 173 deletions(-)
through these ChangeSets:
<airlied@starflyer.(none)> (04/08/02 1.1823)
Fix up multiple devices issues with creating /proc/dri/
From: Jon Smirl
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/08/02 1.1822)
add hotplug support function
From: Jon Smirl
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/08/02 1.1821)
fixup prototype..
<airlied@starflyer.(none)> (04/07/31 1.1820)
switch to using i915_dma_cleanup as this conflicts on BSD builds..
<airlied@starflyer.(none)> (04/07/31 1.1819)
sparse: use of user space pointer in kernel...
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/31 1.1818)
sparse: 0->NULL conversions.
From: Dave Airlie
<airlied@starflyer.(none)> (04/07/31 1.1817)
the patch below optimises the drm code to not do put_user() on memory the
kernel allocated and then mmap-installed to userspace, but instead makes it
use the kernel virtual address directly instead.
From: Arjan van de Ven <arjanv@redhat.com>
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/26 1.1816)
ATI Rage 128 and Radeon DRM unconditionally depend on PCI
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
<airlied@starflyer.(none)> (04/07/26 1.1815)
Correct a couple of packet length calculations. - keithw
<airlied@starflyer.(none)> (04/07/25 1.1814)
define user if not already.. this isn't needed in kernel but for building against the kernel headers it is ...
<airlied@starflyer.(none)> (04/07/25 1.1813)
sync up device/driver tracking with CVS,
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/25 1.1812)
fix whitespace on tabbing
<airlied@starflyer.(none)> (04/07/25 1.1811)
add some annotations Als patch missed
add annotations for i915 driver
<airlied@starflyer.(none)> (04/07/25 1.1810)
add missing prototype
<airlied@starflyer.(none)> (04/07/25 1.1809)
fixup annotation
<airlied@starflyer.(none)> (04/07/25 1.1808)
patch from Tom Arbuckle for missing bus_address
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/20 1.1807)
use NULLs instead of 0s
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/20 1.1806)
fixup drm_stub so it works with two-headed cards properly...
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/15 1.1784.4.6)
Add new i915 driver from Tungsten Graphics Inc. This driver covers the i830
chipsets also, a new X 2D + 3D driver are needed to use this but they have
been integrated into at least the X.org tree at this point and I think the
XFree86 tree. There are probably a few cleanups necessary for this driver.
From: Keith Whitwell <keith@tungstengraphics.com>
Approved-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/15 1.1784.4.5)
Fix issue with keeping count of registered DRMs with new driver model
Submitted-by: Dave Airlie <airlied@linux.ie>
<airlied@starflyer.(none)> (04/07/06 1.1784.4.4)
changes for better hotplug and proper PCI device support from Jon Smirl and
Dave Airlie, along with a big fix from Paul Mackerras.
Note: these are complex due to the need for the DRM to fallback if the
framebuffer driver has already taken the device.
These changes have been in the DRM CVS tree for about 3 months, style
comments are appreciated...
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-15 12:19 Dave Airlie
@ 2004-08-15 12:34 ` Christoph Hellwig
2004-08-15 23:40 ` Dave Airlie
0 siblings, 1 reply; 348+ messages in thread
From: Christoph Hellwig @ 2004-08-15 12:34 UTC (permalink / raw)
To: Dave Airlie; +Cc: torvalds, Andrew Morton, linux-kernel
On Sun, Aug 15, 2004 at 01:19:31PM +0100, Dave Airlie wrote:
> Graphics, and the DRM now uses PCI properly if no framebuffer is loaded
> (it falls back if framebuffer is enabled...),
Can you explain what this means?
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-15 12:34 ` your mail Christoph Hellwig
@ 2004-08-15 23:40 ` Dave Airlie
2004-08-16 9:17 ` Christoph Hellwig
0 siblings, 1 reply; 348+ messages in thread
From: Dave Airlie @ 2004-08-15 23:40 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel
> On Sun, Aug 15, 2004 at 01:19:31PM +0100, Dave Airlie wrote:
> > Graphics, and the DRM now uses PCI properly if no framebuffer is loaded
> > (it falls back if framebuffer is enabled...),
>
> Can you explain what this means?
>
Probably should say PCI APIs properly, it now does enable/disable devices
and registers the DRM as owning the memory regions, does proper PCI
probing .. in cases where the fb is loaded on the card already it falls
back to the old ways (evil direct register writing.. ), this change will
stop you loading the fb driver adter the drm driver but this shouldn't be
a common case at all..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-15 23:40 ` Dave Airlie
@ 2004-08-16 9:17 ` Christoph Hellwig
2004-08-16 9:30 ` Dave Airlie
0 siblings, 1 reply; 348+ messages in thread
From: Christoph Hellwig @ 2004-08-16 9:17 UTC (permalink / raw)
To: Dave Airlie; +Cc: Christoph Hellwig, torvalds, Andrew Morton, linux-kernel
On Mon, Aug 16, 2004 at 12:40:43AM +0100, Dave Airlie wrote:
> Probably should say PCI APIs properly, it now does enable/disable devices
> and registers the DRM as owning the memory regions, does proper PCI
> probing .. in cases where the fb is loaded on the card already it falls
> back to the old ways (evil direct register writing.. ), this change will
> stop you loading the fb driver adter the drm driver but this shouldn't be
> a common case at all..
Eeek, doing different styles of probing is even worse than what you did
before. Please revert to pci_find_device() util you havea proper common
driver ready.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 9:17 ` Christoph Hellwig
@ 2004-08-16 9:30 ` Dave Airlie
2004-08-16 9:50 ` Christoph Hellwig
0 siblings, 1 reply; 348+ messages in thread
From: Dave Airlie @ 2004-08-16 9:30 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel
>
> Eeek, doing different styles of probing is even worse than what you did
> before. Please revert to pci_find_device() util you havea proper common
> driver ready.
There was nothing wrong with what we did before it just happened to work
like 2.4. we are now acting like real 2.6 drivers, which we need to do for
sysfs and hotplug to work, Jon Smirl is working on a proper minor device
support (like USB does I think)... we need to get this work done before we
can have proper common drivers and I don't want to do all this work in
hiding and then have it refused because we told no-one,
The DRM will flux a lot over the next while (while we get this common
drm/fb stuff together) and as long as we can keep the changes from
actually breaking it I think people should be able to live with it ...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 9:30 ` Dave Airlie
@ 2004-08-16 9:50 ` Christoph Hellwig
2004-08-16 10:29 ` Dave Airlie
2004-08-16 11:12 ` Alan Cox
0 siblings, 2 replies; 348+ messages in thread
From: Christoph Hellwig @ 2004-08-16 9:50 UTC (permalink / raw)
To: Dave Airlie; +Cc: Christoph Hellwig, torvalds, Andrew Morton, linux-kernel
On Mon, Aug 16, 2004 at 10:30:55AM +0100, Dave Airlie wrote:
> >
> > Eeek, doing different styles of probing is even worse than what you did
> > before. Please revert to pci_find_device() util you havea proper common
> > driver ready.
>
> There was nothing wrong with what we did before it just happened to work
> like 2.4. we are now acting like real 2.6 drivers,
no, now you're acting like an even more broken driver, preventing a fbdev
driver to be loaded afterwards and doing all kinds of funny things. Please
revert to the old method until you have a common pci_driver for fbdev and dri.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 9:50 ` Christoph Hellwig
@ 2004-08-16 10:29 ` Dave Airlie
2004-08-16 10:38 ` Christoph Hellwig
2004-08-16 11:12 ` Alan Cox
1 sibling, 1 reply; 348+ messages in thread
From: Dave Airlie @ 2004-08-16 10:29 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel
>
> no, now you're acting like an even more broken driver, preventing a fbdev
> driver to be loaded afterwards and doing all kinds of funny things. Please
> revert to the old method until you have a common pci_driver for fbdev and dri.
>
the options we have are
1) move the DRM to be a real PCI driver now - stop fb from working on same
card
2) move the DRM to act like a real PCI driver when fb isn't loaded, when
we merge we rip the code out..
the other option is not going to happen unless Linus/Andrew/Alan tell us
to go away do it that away and will then unconditionally merge a
mega-patch when I'm finished - you can't have it both ways we fix things
step-by-step or we leave it as is and nobody fixes it, so Christoph I
repsect your opinion but unless you care about this enough to do the work
on it, the way we are going seems to be the best way to avoid breaking
things and I'm leaving the decision on whether to merge this stuff or not
to Linus/Andrew - btw in case anyone wants to look the patch is whats at:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8-rc4/2.6.8-rc4-mm1/broken-out/bk-drm.patch
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 10:29 ` Dave Airlie
@ 2004-08-16 10:38 ` Christoph Hellwig
2004-08-16 11:02 ` Dave Airlie
0 siblings, 1 reply; 348+ messages in thread
From: Christoph Hellwig @ 2004-08-16 10:38 UTC (permalink / raw)
To: Dave Airlie; +Cc: Christoph Hellwig, torvalds, Andrew Morton, linux-kernel
On Mon, Aug 16, 2004 at 11:29:48AM +0100, Dave Airlie wrote:
> 1) move the DRM to be a real PCI driver now - stop fb from working on same
> card
>
> 2) move the DRM to act like a real PCI driver when fb isn't loaded, when
> we merge we rip the code out..
3) stop making broken changes.
You do stop fb from beeing loaded after drm
and thus break perfectly working setups during stable series. And you
introduce indeterministic behaviour, and although I haven't looked at the
code because unlike every guideline tells you you didn't post it to do the
list, probably horribly broken code.
If you want pci_driver semantics - and apparently you do - move fbdev
and drm into a common driver or introduce a stub. This was discussed to
death and all kinds of list and Kernel Summit and now please follow what
was agreed on instead of introducing subtile hacks.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 10:38 ` Christoph Hellwig
@ 2004-08-16 11:02 ` Dave Airlie
2004-08-16 11:08 ` Christoph Hellwig
0 siblings, 1 reply; 348+ messages in thread
From: Dave Airlie @ 2004-08-16 11:02 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel
>
> 3) stop making broken changes.
The current system is broken in way more subtle ways...
> You do stop fb from beeing loaded after drm
> and thus break perfectly working setups during stable series. And you
I doubt anyone has a system that does it and they should have a broken one
if they do it.. drm has also said you should load fb before it.. and
having both fb and drm loaded on the same hardware is a hack anyways..
> introduce indeterministic behaviour, and although I haven't looked at the
> code because unlike every guideline tells you you didn't post it to do the
> list, probably horribly broken code.
I just did post it, it's been in the DRM CVS tree for 3-6 mths now, it's
been in -mm for 1.5 mths, I've followed what Andrew and Linus told me to
do to get the DRM maintained... the link I posted in the last mail to the
broken out patch in the -mm tree, the only file to change is really
drm_drv.h and some bits in drm_stub.h... the current code is we have
discovered horribly broken in a lot of cases.. I've gotten nothing back to
say this code is any worse....
> If you want pci_driver semantics - and apparently you do - move fbdev
> and drm into a common driver or introduce a stub. This was discussed to
> death and all kinds of list and Kernel Summit and now please follow what
> was agreed on instead of introducing subtile hacks.
Yes and that is the final goal but you are dodging the point we cannot
jump to a fully finished state in one simple transition, it is great to
hear "fbdrv/drm into a common driver" it's a simple sentence surely coding
it must be simple, well its not and we are taking the route that should
affect the least people, I'm majorly involved in the discussion and I was
the one to agree to carry out the maintenance paths between DRM and LK,
this code is needed for us to move forward with the merged drivers - if
Linus/Andrew decide not to merge it I'll go back to the DRM team and it'll
be reworked until they do accept it, but we have to stop the fb from
loading after the DRM at some stage and it may as well be earlier.. (if
2.7 was going to happen I'd wait but kernel development seems to be
changing...)
You seem to want us to go down the finished unmergeable mega-patch road
to avoid breaking something that is broken and might work, the benefits
don't outweight the costs.. so it makes no sense..
Again if Linus/Andrew bounce this we will have to rework it but something
like this has to go in at some stage...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 11:02 ` Dave Airlie
@ 2004-08-16 11:08 ` Christoph Hellwig
2004-08-16 11:12 ` Alan Cox
2004-08-16 11:47 ` Dave Airlie
0 siblings, 2 replies; 348+ messages in thread
From: Christoph Hellwig @ 2004-08-16 11:08 UTC (permalink / raw)
To: Dave Airlie; +Cc: torvalds, Andrew Morton, linux-kernel
On Mon, Aug 16, 2004 at 12:02:15PM +0100, Dave Airlie wrote:
> > You do stop fb from beeing loaded after drm
> > and thus break perfectly working setups during stable series. And you
>
> I doubt anyone has a system that does it and they should have a broken one
> if they do it.. drm has also said you should load fb before it.. and
> having both fb and drm loaded on the same hardware is a hack anyways..
So fix it properly instead of making it even more broken.
> Yes and that is the final goal but you are dodging the point we cannot
> jump to a fully finished state in one simple transition, it is great to
> hear "fbdrv/drm into a common driver" it's a simple sentence surely coding
> it must be simple, well its not and we are taking the route that should
It _is+ simple. Look at drivers/message/fusion/ for a driver doing multiple
protocol on a single pci_driver. I don't demand full-blown memory management
integration or anything pother fancy. Just get your crap sorted out.
ou could propably have done a prototype in the time you wasted arguing here.
> You seem to want us to go down the finished unmergeable mega-patch road
> to avoid breaking something that is broken and might work, the benefits
> don't outweight the costs.. so it makes no sense..
I want you a) to back out this particular broken change in your current
mega-patch. and b) submit small reviewable changes in the future, as every
other driver maintainer does.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 11:08 ` Christoph Hellwig
@ 2004-08-16 11:12 ` Alan Cox
2004-08-16 11:47 ` Dave Airlie
1 sibling, 0 replies; 348+ messages in thread
From: Alan Cox @ 2004-08-16 11:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dave Airlie, torvalds, Andrew Morton, Linux Kernel Mailing List
On Llu, 2004-08-16 at 12:08, Christoph Hellwig wrote:
> I want you a) to back out this particular broken change in your current
> mega-patch. and b) submit small reviewable changes in the future, as every
> other driver maintainer does.
DRI is done as small reviewable changes. If you want to be involved then
follow the DRI list too or ask for the entire list to be gated to
linux-kernel for your pleasure...
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 11:08 ` Christoph Hellwig
2004-08-16 11:12 ` Alan Cox
@ 2004-08-16 11:47 ` Dave Airlie
1 sibling, 0 replies; 348+ messages in thread
From: Dave Airlie @ 2004-08-16 11:47 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: torvalds, Andrew Morton, linux-kernel
> > Yes and that is the final goal but you are dodging the point we cannot
> > jump to a fully finished state in one simple transition, it is great to
> > hear "fbdrv/drm into a common driver" it's a simple sentence surely coding
> > it must be simple, well its not and we are taking the route that should
>
> It _is+ simple. Look at drivers/message/fusion/ for a driver doing multiple
> protocol on a single pci_driver. I don't demand full-blown memory management
> integration or anything pother fancy. Just get your crap sorted out.
>
> ou could propably have done a prototype in the time you wasted arguing here.
we could write one quick enough for one card but now make it work on
combinations of mach64/i810/radeon/r128/i830/i915/mga cards and tested so
that it doesn't break current setups, its just not going to happen, this
change doesn't break near as many setups (I'd be surprised if it broke any
real world setups at all...) I don't have the hardware to test this on all
those cards, the hope is to get the DRM into a state that we can start
proving the shared idea on one card.. it will also make changes to fb
drivers which I'm not comfortable with doing and will cause more hassles..
> I want you a) to back out this particular broken change in your current
> mega-patch. and b) submit small reviewable changes in the future, as every
> other driver maintainer does.
I'm considering your argument and have taken it on-board, I await Linus's
decision for now, I'll start looking into the info you've given me and
I'll talk to the DRM people actually doing the work (not one line of this
is orignally from me!!..)
All DRM changes are available in small chunks in DRM CVS and DRM bk trees,
the -mm tree picks up the DRM changes and I fix the bugs that come up in
the -mm tree and then I submit the bk tree to Linus, I thought this was
how kernel development worked these days,
The patch you are against is
http://drm.bkbits.net:8080/drm-2.6/patch@1.1784.4.4?nav=index.html|tags|ChangeSet@1.1722.154.18..|cset@1.1784.4.4
with a couple of bugfixes on top of it from testing in -mm.. if I'm
missing the kernel development process somehow please inform me.. I'm new
to this maintainer job and the drm hasn't been maintained in years so I'm
not starting from a good place...
Thanks,
Dave.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 9:50 ` Christoph Hellwig
2004-08-16 10:29 ` Dave Airlie
@ 2004-08-16 11:12 ` Alan Cox
2004-08-16 12:20 ` Christoph Hellwig
1 sibling, 1 reply; 348+ messages in thread
From: Alan Cox @ 2004-08-16 11:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dave Airlie, torvalds, Andrew Morton, Linux Kernel Mailing List
On Llu, 2004-08-16 at 10:50, Christoph Hellwig wrote:
> no, now you're acting like an even more broken driver, preventing a fbdev
> driver to be loaded afterwards and doing all kinds of funny things. Please
> revert to the old method until you have a common pci_driver for fbdev and dri.
fbdev and DRI are not functional together in the general case. They
sometimes happen to work by luck. fbdev and X for that matter are
generally incompatible except unaccelerated.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 11:12 ` Alan Cox
@ 2004-08-16 12:20 ` Christoph Hellwig
2004-08-16 12:24 ` Dave Airlie
0 siblings, 1 reply; 348+ messages in thread
From: Christoph Hellwig @ 2004-08-16 12:20 UTC (permalink / raw)
To: Alan Cox
Cc: Christoph Hellwig, Dave Airlie, torvalds, Andrew Morton,
Linux Kernel Mailing List
On Mon, Aug 16, 2004 at 12:12:00PM +0100, Alan Cox wrote:
> On Llu, 2004-08-16 at 10:50, Christoph Hellwig wrote:
> > no, now you're acting like an even more broken driver, preventing a fbdev
> > driver to be loaded afterwards and doing all kinds of funny things. Please
> > revert to the old method until you have a common pci_driver for fbdev and dri.
>
> fbdev and DRI are not functional together in the general case. They
> sometimes happen to work by luck. fbdev and X for that matter are
> generally incompatible except unaccelerated.
Works fine on all my pmacs here. In fact X works only on fbdev for
full features.
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 12:20 ` Christoph Hellwig
@ 2004-08-16 12:24 ` Dave Airlie
2004-08-16 12:37 ` Christoph Hellwig
0 siblings, 1 reply; 348+ messages in thread
From: Dave Airlie @ 2004-08-16 12:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Alan Cox, torvalds, Andrew Morton, Linux Kernel Mailing List
>
> Works fine on all my pmacs here. In fact X works only on fbdev for
> full features.
I think Alan would classify that as luck rathar than design... and I would
tend to agree, does it work if you load the driver modules in any order?
or do you always to fb then drm? or the other way around?
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
^ permalink raw reply [flat|nested] 348+ messages in thread
* Re: your mail
2004-08-16 12:24 ` Dave Airlie
@ 2004-08-16 12:37 ` Christoph Hellwig
2004-08-16 23:33 ` Dave Airlie
0 siblings, 1 reply; 348+ messages in thread
From: Christoph Hellwig @ 2004-08-16 12:37 UTC (permalink / raw)
To: Dave Airlie
Cc: Christoph Hellwig, Alan Cox, torvalds, Andrew Morton,
Linux Kernel Mailing List
On Mon, Aug 16, 2004 at 01:24:30PM +0100, Dave Airlie wrote:
> >
> > Works fine on all my pmacs here. In fact X works only on fbdev for
> > full features.
>
> I think Alan would classify that as luck rathar than design... and I would
All the fbdev handling code in X is also an accident?
Really, why do you even push for this change if the better fix isn't that
far away. Send the i915 driver and the other misc cleanups to Linus now
and get a proper graphics stub driver done, it's not that much work. I'll
hack up the fbdev side once I'll get a little time, but the drm code is
far to disgusting to touch, sorry.
^ permalink raw reply [flat|nested] 348+ messages in thread