(unknown),

(unknown),

[srikanth TS]

[-- Attachment #1.1: Type: text/plain, Size: 427 bytes --]

Hi Will Deacon,



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?



WBRs,

Srikanth.

[-- Attachment #1.2: Type: text/html, Size: 1538 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: your mail

[Will Deacon]

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

Re: your mail

[Will Deacon]

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

RE: your mail

[Varun Sethi]

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

RE: your mail

[Varun Sethi]

> -----Original Message-----
> From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Will Deacon
> Sent: Monday, February 24, 2014 10:59 PM
> To: srikanth TS
> Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linux-
> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
> 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

RE: your mail

[srikanth TS]

[-- Attachment #1.1: Type: text/plain, Size: 2003 bytes --]

On Feb 25, 2014 8:28 PM, "Varun Sethi" <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>
>
>
> > -----Original Message-----
> > From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> > bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Will Deacon
> > Sent: Monday, February 24, 2014 10:59 PM
> > To: srikanth TS
> > Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linux-
> > kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
> > 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.
Can you please explain with little more detail. We just want to make sure
your idea fits in for pci iov also.

-Srikanth ts
>
> -Varun
>

[-- Attachment #1.2: Type: text/html, Size: 3095 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

RE: your mail

[Varun Sethi]

[-- Attachment #1.1: Type: text/plain, Size: 3200 bytes --]



From: srikanth TS [mailto:srikantht.shivanand-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: Wednesday, February 26, 2014 1:53 PM
To: Sethi Varun-B16395
Cc: sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Will Deacon; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
Subject: RE: your mail


On Feb 25, 2014 8:28 PM, "Varun Sethi" <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org<mailto:Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>> wrote:
>
>
>
> > -----Original Message-----
> > From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org<mailto:iommu-bounces@lists.linux-foundation.org> [mailto:iommu-<mailto:iommu->
> > bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org<mailto:bounces-cunTk1MwBs9QetFLy7KEm967fi48ZQAG@public.gmane.orgn.org>] On Behalf Of Will Deacon
> > Sent: Monday, February 24, 2014 10:59 PM
> > To: srikanth TS
> > Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org<mailto:iommu-cunTk1MwBs9QetFLy7KEm967fi48ZQAG@public.gmane.orgn.org>; sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org<mailto:sungjinn.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>; linux-
> > kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org<mailto:kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; ts.srikanth@samsung.com<mailto:ts.srikanth-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> > 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.
Can you please explain with little more detail. We just want to make sure your idea fits in for pci iov also.

[Sethi Varun-B16395] In the add device notifier we can allocate the streamID (and the corresponding smmu master), while allocating the iommu group for the PCI devices. All, the PCIe devices sharing the same iommu group would share the stream ID.  Currently, I am working on a add device framework for hot plug devices.

-Varun

[-- Attachment #1.2: Type: text/html, Size: 6967 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: your mail

[Konstantin Ryabitsev]

On Fri, Feb 09, 2024 at 01:30:34PM +0100, Ulf Hansson wrote:
> -----BEGIN PGP PUBLIC KEY BLOCK-----

Updated, thanks.

-K

Re: your mail

[Julia Lawall]

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

Re: your mail

[Gilbert Adikankwu]

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

Re: your mail

[Julia Lawall]

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

Re: your mail

[Murphy Zhou]

On Thu, May 25, 2023 at 8:04 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Thu, May 25, 2023 at 08:01:22PM +0800, Murphy Zhou wrote:
> > Hi Christoph,
> >
> > The linux-next tree, since the next-20230522 tag, LTP/writev07[1]
> > starts to fail on xfs, not on other fs. It was pass on the previous
> > tag next-20230519.
> >
> > After those 2 commits reverted on the top of 0522 tree, it passed.
> >
> >     iomap: update ki_pos in iomap_file_buffered_write
> >     iomap: assign current->backing_dev_info in iomap_file_buffered_write
> >
> > (the second one was reverted because the first one depends on it)
>
> Yes, they are known broken.  There has been a v2 on the list already,
> which still has issues for fuse, so there will be a v3.

Great! Thank you.
>

Re: your mail

[Christoph Hellwig]

On Thu, May 25, 2023 at 08:01:22PM +0800, Murphy Zhou wrote:
> Hi Christoph,
> 
> The linux-next tree, since the next-20230522 tag, LTP/writev07[1]
> starts to fail on xfs, not on other fs. It was pass on the previous
> tag next-20230519.
> 
> After those 2 commits reverted on the top of 0522 tree, it passed.
> 
>     iomap: update ki_pos in iomap_file_buffered_write
>     iomap: assign current->backing_dev_info in iomap_file_buffered_write
> 
> (the second one was reverted because the first one depends on it)

Yes, they are known broken.  There has been a v2 on the list already,
which still has issues for fuse, so there will be a v3.

Re: your mail

[Liam R. Howlett]

* 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

Re: your mail

[Thomas Gleixner]

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

Re: your mail

[Thomas Gleixner]

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

Re: your mail

[Liam R. Howlett]

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

Re: your mail

[Konstantin Ryabitsev]

On Wed, Apr 26, 2023 at 03:35:10PM +0100, Bryan O'Donoghue wrote:

> -----BEGIN PGP PUBLIC KEY BLOCK-----

Hello:

There are no signatures on this key that we recognize, so we cannot include it
into the kernel.org keyring. Please get at least 2 signatures from someone who
is already in the keyring (or has a kernel.org account) and resubmit.

-K

Re: your mail

[Sumitra Sharma]

On Sun, Mar 19, 2023 at 10:02:46AM +0100, Julia Lawall wrote:
> 
> 
> On Sun, 19 Mar 2023, Sumitra Sharma wrote:
> 
> > On Sun, Mar 19, 2023 at 09:35:50AM +0100, Julia Lawall wrote:
> > > > Actually, the only issue I faced was that the outreachyfirstpatch
> > > > document does not contain the information of how one can set their inbox in mutt.
> > > > Due to which I had problems to send and reply mails. This below
> > > > configuration update will enable the inbox at the client side.
> > > >
> > > > How about this...
> > > >
> > > > Under the section "Configure esmtp":
> > > >
> > > > ###
> > > > Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
> > > >
> > > > Note: The imap_pass, smtp_pass would be the App password or
> > > >  	  the mailbox password.
> > > >
> > > >  		set sendmail="/usr/bin/esmtp"
> > > >  		set envelope_from=yes
> > > >  		set from="Your Name <my.email@gmail.com>"
> > > >  		set use_from=yes
> > > >  		set edit_headers=yes
> > > >
> > > >  		# IMAP settings
> > > >  		set imap_user = "username@gmail.com"
> > > >  		set imap_pass = "<mailbox password>"
> > > >
> > > >  		# SMTP settings
> > > >  		set smtp_url = "smtps://username@smtp.gmail.com"
> > > >  		set smtp_pass = "<mailbox password>"
> > > >
> > > >  		# Remote Gmail folders
> > > >  		set folder = "imaps://imap.gmail.com/"
> > > >  		set spoolfile = "+INBOX"
> > > >  		set postponed = "+[Gmail]/Drafts"
> > > >  		set record = "+[Gmail]/Sent Mail"
> > > >  		set trash = "+[Gmail]/Trash"
> > > > ###
> > >
> > > Does this have anything to do with esmpt?
> > >
> >
> > In the current version of the outreachy firstpatch document the configuration
> > steps for .esmtp and .muttrc are written under the heading
> > "Configure esmtp" and also to configure esmtp we are creating the muttrc
> > file. So, both are linked in a way.
> 
> I don't think so.  Comfiguring esmtp requires adding some information to
> the .muttrc, but people who don't want to configure esmtp may also want to
> add information to the .muttrc.
>

Then, why dont we rename the section as "Configure MTA"

then it will go as follows:

> >
> > > Does "<mailbox password>" mean that you have to put your password in plain
> > > text?
> > >
> >
> > Yes, but it is always prefered to use the app password for better security.
> 
> The existing text about sending mesages with mutt says:
> 
> identity "my.email@gmail.com"
> hostname smtp.gmail.com:587
> username "my.email@gmail.com"
> password "ThisIsNotARealPassWord"
> starttls required
> 
> Why not put "ThisIsNotARealPassWord" in your text as well, if that is
> what you expect people to do?
> 
> That is, when you put something in quotes, the reader doedn't know whether
> they are supposed to put exactly the thing that you have put in the quotes
> or something else.  I guess that for eg "smtps://username@smtp.gmail.com"
> they should fill in their real username.  But for "<mailbox password>" it
> is not clear what is expected.
> 

###
Configure MTA

Note: These instructions assume you're using esmtp, but if you already have another mail transfer agent (MTA) installed, you do not need to install esmtp. Instead, change the .muttrc file "sendmail" line to be the path to your MTA. Mutt uses ssmtp by default, so if your MTA is ssmtp, you can leave that line out entirely.

First, create a .esmtprc file with the right permissions:


			touch ~/.esmtprc
			chmod g-rwx ~/.esmtprc
			chmod o-rwx ~/.esmtprc

Edit the .esmtprc in your home directory, and add lines like this:

			identity "my.email@gmail.com"
			hostname smtp.gmail.com:587
			username "my.email@gmail.com"
			password "ThisIsNotARealPassWord"
			starttls required 

(For Yahoo mail, replace hostname line with:

			hostname smtp.mail.yahoo.com:587

Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
 Note: The imap_pass, smtp_pass would be the App password or the mailbox password.


	           set sendmail="/usr/bin/esmtp"
	           set envelope_from=yes
	           set from="Your Name <my.email@gmail.com>"
	           set use_from=yes
		     set edit_headers=yes

                 # IMAP settings
                 set imap_user = "username@gmail.com"
                 set imap_pass = "<ThisIsNotARealPassWord>"

                 # SMTP settings
                 set smtp_url = "smtps://username@smtp.gmail.com"
                 set smtp_pass = "<ThisIsNotARealPassWord>"

                 # Remote Gmail folders
                 set folder = "imaps://imap.gmail.com/"
                 set spoolfile = "+INBOX"
                 set postponed = "+[Gmail]/Drafts"
                 set record = "+[Gmail]/Sent Mail"
                 set trash = "+[Gmail]/Trash"


###


Regards,

Sumitra

> julia

Re: your mail

[Julia Lawall]

On Sun, 19 Mar 2023, Sumitra Sharma wrote:

> On Sun, Mar 19, 2023 at 09:35:50AM +0100, Julia Lawall wrote:
> > > Actually, the only issue I faced was that the outreachyfirstpatch
> > > document does not contain the information of how one can set their inbox in mutt.
> > > Due to which I had problems to send and reply mails. This below
> > > configuration update will enable the inbox at the client side.
> > >
> > > How about this...
> > >
> > > Under the section "Configure esmtp":
> > >
> > > ###
> > > Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
> > >
> > > Note: The imap_pass, smtp_pass would be the App password or
> > >  	  the mailbox password.
> > >
> > >  		set sendmail="/usr/bin/esmtp"
> > >  		set envelope_from=yes
> > >  		set from="Your Name <my.email@gmail.com>"
> > >  		set use_from=yes
> > >  		set edit_headers=yes
> > >
> > >  		# IMAP settings
> > >  		set imap_user = "username@gmail.com"
> > >  		set imap_pass = "<mailbox password>"
> > >
> > >  		# SMTP settings
> > >  		set smtp_url = "smtps://username@smtp.gmail.com"
> > >  		set smtp_pass = "<mailbox password>"
> > >
> > >  		# Remote Gmail folders
> > >  		set folder = "imaps://imap.gmail.com/"
> > >  		set spoolfile = "+INBOX"
> > >  		set postponed = "+[Gmail]/Drafts"
> > >  		set record = "+[Gmail]/Sent Mail"
> > >  		set trash = "+[Gmail]/Trash"
> > > ###
> >
> > Does this have anything to do with esmpt?
> >
>
> In the current version of the outreachy firstpatch document the configuration
> steps for .esmtp and .muttrc are written under the heading
> "Configure esmtp" and also to configure esmtp we are creating the muttrc
> file. So, both are linked in a way.

I don't think so.  Comfiguring esmtp requires adding some information to
the .muttrc, but people who don't want to configure esmtp may also want to
add information to the .muttrc.

>
> > Does "<mailbox password>" mean that you have to put your password in plain
> > text?
> >
>
> Yes, but it is always prefered to use the app password for better security.

The existing text about sending mesages with mutt says:

identity "my.email@gmail.com"
hostname smtp.gmail.com:587
username "my.email@gmail.com"
password "ThisIsNotARealPassWord"
starttls required

Why not put "ThisIsNotARealPassWord" in your text as well, if that is
what you expect people to do?

That is, when you put something in quotes, the reader doedn't know whether
they are supposed to put exactly the thing that you have put in the quotes
or something else.  I guess that for eg "smtps://username@smtp.gmail.com"
they should fill in their real username.  But for "<mailbox password>" it
is not clear what is expected.

julia

Re: your mail

[Sumitra Sharma]

On Sun, Mar 19, 2023 at 09:35:50AM +0100, Julia Lawall wrote:
> > Actually, the only issue I faced was that the outreachyfirstpatch
> > document does not contain the information of how one can set their inbox in mutt.
> > Due to which I had problems to send and reply mails. This below
> > configuration update will enable the inbox at the client side.
> >
> > How about this...
> >
> > Under the section "Configure esmtp":
> >
> > ###
> > Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
> >
> > Note: The imap_pass, smtp_pass would be the App password or
> >  	  the mailbox password.
> >
> >  		set sendmail="/usr/bin/esmtp"
> >  		set envelope_from=yes
> >  		set from="Your Name <my.email@gmail.com>"
> >  		set use_from=yes
> >  		set edit_headers=yes
> >
> >  		# IMAP settings
> >  		set imap_user = "username@gmail.com"
> >  		set imap_pass = "<mailbox password>"
> >
> >  		# SMTP settings
> >  		set smtp_url = "smtps://username@smtp.gmail.com"
> >  		set smtp_pass = "<mailbox password>"
> >
> >  		# Remote Gmail folders
> >  		set folder = "imaps://imap.gmail.com/"
> >  		set spoolfile = "+INBOX"
> >  		set postponed = "+[Gmail]/Drafts"
> >  		set record = "+[Gmail]/Sent Mail"
> >  		set trash = "+[Gmail]/Trash"
> > ###
> 
> Does this have anything to do with esmpt?
>

In the current version of the outreachy firstpatch document the configuration 
steps for .esmtp and .muttrc are written under the heading
"Configure esmtp" and also to configure esmtp we are creating the muttrc
file. So, both are linked in a way.

> Does "<mailbox password>" mean that you have to put your password in plain
> text?
> 

Yes, but it is always prefered to use the app password for better security.


Regards,

Sumitra

> julia

Re: your mail

[Julia Lawall]

> Actually, the only issue I faced was that the outreachyfirstpatch
> document does not contain the information of how one can set their inbox in mutt.
> Due to which I had problems to send and reply mails. This below
> configuration update will enable the inbox at the client side.
>
> How about this...
>
> Under the section "Configure esmtp":
>
> ###
> Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:
>
> Note: The imap_pass, smtp_pass would be the App password or
>  	  the mailbox password.
>
>  		set sendmail="/usr/bin/esmtp"
>  		set envelope_from=yes
>  		set from="Your Name <my.email@gmail.com>"
>  		set use_from=yes
>  		set edit_headers=yes
>
>  		# IMAP settings
>  		set imap_user = "username@gmail.com"
>  		set imap_pass = "<mailbox password>"
>
>  		# SMTP settings
>  		set smtp_url = "smtps://username@smtp.gmail.com"
>  		set smtp_pass = "<mailbox password>"
>
>  		# Remote Gmail folders
>  		set folder = "imaps://imap.gmail.com/"
>  		set spoolfile = "+INBOX"
>  		set postponed = "+[Gmail]/Drafts"
>  		set record = "+[Gmail]/Sent Mail"
>  		set trash = "+[Gmail]/Trash"
> ###

Does this have anything to do with esmpt?

Does "<mailbox password>" mean that you have to put your password in plain
text?

julia

Re: your mail

[Sumitra Sharma]

On Fri, Mar 17, 2023 at 05:47:23PM +0100, Julia Lawall wrote:
> 
> 
> On Fri, 17 Mar 2023, Sumitra Sharma wrote:
> 
> > , fmdefrancesco@gmail.com
> > Bcc:
> > Subject: Re: [KERNEL NEWBIES ACCESS] Sumitra Sharma
> > Reply-To:
> > In-Reply-To: <936dcbf3-0bf3-0461-1ea5-d71e0e60fa88@gmail.com>
> >
> > On Wed, Mar 15, 2023 at 03:41:40PM +0700, Bagas Sanjaya wrote:
> > > On 3/14/23 19:33, Sumitra Sharma wrote:
> > > >> On Outreachyfirstpatch, there is a pointer to Outreachyfirstpatchalt
> > > >> (which contains instructions on spinning up Ubuntu VM), so you need to
> > > >> install your tools (including postfix and mutt) there if you want to
> > > >> contribute through there. So I think the latter doc should be kept as
> > > >> is.
> > > >>
> > > >
> > > > Hi
> > > >
> > > > Can you send me a link to Outreachyfirstpatchalt, I am unable to find
> > > > it.
> > > >
> > >
> > > For your completeness, see https://kernelnewbies.org/OutreachyfirstpatchAlt.
> > >
> > > Again, what I mean that OutreachyfirstpatchAlt is about spinning up
> > > Linux VM. If you need follow setting up tools in Outreachyfirstpatch,
> > > you can do that in the VM. So I suggest not to modify OutreachyfirstpatchAlt
> > > for now. (But I wish the slug could be better named as LinuxVMSetup).
> > >
> >
> > Hi,
> >
> > Since we discussed all about the outreachyfirstpatchalt only and you
> > also suggested not to modify it for now. I want to clarify that whether we are working on these below changes for the "outreachyfirstpatch". I am again mentioning them below.
> 
> In https://kernelnewbies.org/Outreachyfirstpatch, there is a section
> called Set up email.  This is followed by some sections related to gmail,
> yahoo, etc.  So you could find the best place around there for the new
> information.
> 
> It could be nice to use some subsections, so that one can easily identify
> the complete section about email.
> 

Actually, the only issue I faced was that the outreachyfirstpatch
document does not contain the information of how one can set their inbox in mutt.
Due to which I had problems to send and reply mails. This below
configuration update will enable the inbox at the client side.

How about this...

Under the section "Configure esmtp":

###
Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:

Note: The imap_pass, smtp_pass would be the App password or
 	  the mailbox password.

 		set sendmail="/usr/bin/esmtp"
 		set envelope_from=yes
 		set from="Your Name <my.email@gmail.com>"
 		set use_from=yes
 		set edit_headers=yes

 		# IMAP settings
 		set imap_user = "username@gmail.com"
 		set imap_pass = "<mailbox password>"

 		# SMTP settings
 		set smtp_url = "smtps://username@smtp.gmail.com"
 		set smtp_pass = "<mailbox password>"

 		# Remote Gmail folders
 		set folder = "imaps://imap.gmail.com/"
 		set spoolfile = "+INBOX"
 		set postponed = "+[Gmail]/Drafts"
 		set record = "+[Gmail]/Sent Mail"
 		set trash = "+[Gmail]/Trash"
###
> I notice also that there seems to be randomly "set up" and "setup".  I
> have the impression that "set up" is a verb and "setup" is a noun., so it
> should be "Set up vim as your default editor" (not Setup...) and it should
> be "Gmail setup" (not Gmail set up).
>

Okay! I will take care of it. Thank you.

In addition to this, I would like to bring to your notice that a hyperlink
in outrachyfirstpatch document, under the section "Git post-commit
hooks" does not work and it must be changed.

under Git post-commit hooks; checkpatch.pl:
http://lxr.free-electrons.com/source/scripts/checkpatch.pl
------------------------------------------------------------------
https://elixir.bootlin.com/linux/latest/source/scripts/checkpatch.pl




Regards,

Sumitra

> thanks,
> julia
> 
> 

Re: your mail

[Sumitra Sharma]

On Fri, Mar 17, 2023 at 05:47:23PM +0100, Julia Lawall wrote:
> 
> 
> On Fri, 17 Mar 2023, Sumitra Sharma wrote:
> 
> > , fmdefrancesco@gmail.com
> > Bcc:
> > Subject: Re: [KERNEL NEWBIES ACCESS] Sumitra Sharma
> > Reply-To:
> > In-Reply-To: <936dcbf3-0bf3-0461-1ea5-d71e0e60fa88@gmail.com>
> >
> > On Wed, Mar 15, 2023 at 03:41:40PM +0700, Bagas Sanjaya wrote:
> > > On 3/14/23 19:33, Sumitra Sharma wrote:
> > > >> On Outreachyfirstpatch, there is a pointer to Outreachyfirstpatchalt
> > > >> (which contains instructions on spinning up Ubuntu VM), so you need to
> > > >> install your tools (including postfix and mutt) there if you want to
> > > >> contribute through there. So I think the latter doc should be kept as
> > > >> is.
> > > >>
> > > >
> > > > Hi
> > > >
> > > > Can you send me a link to Outreachyfirstpatchalt, I am unable to find
> > > > it.
> > > >
> > >
> > > For your completeness, see https://kernelnewbies.org/OutreachyfirstpatchAlt.
> > >
> > > Again, what I mean that OutreachyfirstpatchAlt is about spinning up
> > > Linux VM. If you need follow setting up tools in Outreachyfirstpatch,
> > > you can do that in the VM. So I suggest not to modify OutreachyfirstpatchAlt
> > > for now. (But I wish the slug could be better named as LinuxVMSetup).
> > >
> >
> > Hi,
> >
> > Since we discussed all about the outreachyfirstpatchalt only and you
> > also suggested not to modify it for now. I want to clarify that whether we are working on these below changes for the "outreachyfirstpatch". I am again mentioning them below.
> 
> In https://kernelnewbies.org/Outreachyfirstpatch, there is a section
> called Set up email.  This is followed by some sections related to gmail,
> yahoo, etc.  So you could find the best place around there for the new
> information.
> 
> It could be nice to use some subsections, so that one can easily identify
> the complete section about email.
> 

Actually, the only issue I faced was that the outreachyfirstpatch
document do not contain the informatio of how to set your inbox in mutt.
Due to which I was facing issues to send and reply mails. This below
configuration update will enable the inbox at the client side.

How about this...

Under the section "Configure esmtp":

###
Next, set up the mail client, mutt, with some defaults, by creating a .muttrc file in your homedirectory:

Note: The imap_pass, smtp_pass would be the App password or
 	  the mailbox password.

 		set sendmail="/usr/bin/esmtp"
 		set envelope_from=yes
 		set from="Your Name <my.email@gmail.com>"
 		set use_from=yes
 		set edit_headers=yes

 		# IMAP settings
 		set imap_user = "username@gmail.com"
 		set imap_pass = "<mailbox password>"

 		# SMTP settings
 		set smtp_url = "smtps://username@smtp.gmail.com"
 		set smtp_pass = "<mailbox password>"

 		# Remote Gmail folders
 		set folder = "imaps://imap.gmail.com/"
 		set spoolfile = "+INBOX"
 		set postponed = "+[Gmail]/Drafts"
 		set record = "+[Gmail]/Sent Mail"
 		set trash = "+[Gmail]/Trash"
###
> I notice also that there seems to be randomly "set up" and "setup".  I
> have the impression that "set up" is a verb and "setup" is a noun., so it
> should be "Set up vim as your default editor" (not Setup...) and it should
> be "Gmail setup" (not Gmail set up).
>

Okay! I will take care of it. Thank you.

Regards,

Sumitra

> thanks,
> julia
> 
> >
> > 1. The outreachy document does not include the steps to make the inbox with mutt. The steps below can be added to configure mutt with gmail.
> >
> > 	- Open the ~/.muttrc
> > 	- Add the information
> >
> > 		set sendmail="/usr/bin/esmtp"
> > 		set envelope_from=yes
> > 		set from="Your Name <my.email@gmail.com>"
> > 		set use_from=yes
> > 		set edit_headers=yes
> >
> > 		# IMAP settings
> > 		set imap_user = "username@gmail.com"
> > 		set imap_pass = "<mailbox password>"
> >
> > 		# SMTP settings
> > 		set smtp_url = "smtps://username@smtp.gmail.com"
> > 		set smtp_pass = "<mailbox password>"
> >
> > 		# Remote Gmail folders
> > 		set folder = "imaps://imap.gmail.com/"
> > 		set spoolfile = "+INBOX"
> > 		set postponed = "+[Gmail]/Drafts"
> > 		set record = "+[Gmail]/Sent Mail"
> > 		set trash = "+[Gmail]/Trash"
> >
> > 	- Where the imap_pass, smtp_pass would be the App password or
> > 	  the mailbox password.
> >
> >
> > Regards,
> >
> > Sumitra
> >
> >

Re: your mail

[Julia Lawall]

On Fri, 17 Mar 2023, Sumitra Sharma wrote:

> , fmdefrancesco@gmail.com
> Bcc:
> Subject: Re: [KERNEL NEWBIES ACCESS] Sumitra Sharma
> Reply-To:
> In-Reply-To: <936dcbf3-0bf3-0461-1ea5-d71e0e60fa88@gmail.com>
>
> On Wed, Mar 15, 2023 at 03:41:40PM +0700, Bagas Sanjaya wrote:
> > On 3/14/23 19:33, Sumitra Sharma wrote:
> > >> On Outreachyfirstpatch, there is a pointer to Outreachyfirstpatchalt
> > >> (which contains instructions on spinning up Ubuntu VM), so you need to
> > >> install your tools (including postfix and mutt) there if you want to
> > >> contribute through there. So I think the latter doc should be kept as
> > >> is.
> > >>
> > >
> > > Hi
> > >
> > > Can you send me a link to Outreachyfirstpatchalt, I am unable to find
> > > it.
> > >
> >
> > For your completeness, see https://kernelnewbies.org/OutreachyfirstpatchAlt.
> >
> > Again, what I mean that OutreachyfirstpatchAlt is about spinning up
> > Linux VM. If you need follow setting up tools in Outreachyfirstpatch,
> > you can do that in the VM. So I suggest not to modify OutreachyfirstpatchAlt
> > for now. (But I wish the slug could be better named as LinuxVMSetup).
> >
>
> Hi,
>
> Since we discussed all about the outreachyfirstpatchalt only and you
> also suggested not to modify it for now. I want to clarify that whether we are working on these below changes for the "outreachyfirstpatch". I am again mentioning them below.

In https://kernelnewbies.org/Outreachyfirstpatch, there is a section
called Set up email.  This is followed by some sections related to gmail,
yahoo, etc.  So you could find the best place around there for the new
information.

It could be nice to use some subsections, so that one can easily identify
the complete section about email.

I notice also that there seems to be randomly "set up" and "setup".  I
have the impression that "set up" is a verb and "setup" is a noun., so it
should be "Set up vim as your default editor" (not Setup...) and it should
be "Gmail setup" (not Gmail set up).

thanks,
julia

>
> 1. The outreachy document does not include the steps to make the inbox with mutt. The steps below can be added to configure mutt with gmail.
>
> 	- Open the ~/.muttrc
> 	- Add the information
>
> 		set sendmail="/usr/bin/esmtp"
> 		set envelope_from=yes
> 		set from="Your Name <my.email@gmail.com>"
> 		set use_from=yes
> 		set edit_headers=yes
>
> 		# IMAP settings
> 		set imap_user = "username@gmail.com"
> 		set imap_pass = "<mailbox password>"
>
> 		# SMTP settings
> 		set smtp_url = "smtps://username@smtp.gmail.com"
> 		set smtp_pass = "<mailbox password>"
>
> 		# Remote Gmail folders
> 		set folder = "imaps://imap.gmail.com/"
> 		set spoolfile = "+INBOX"
> 		set postponed = "+[Gmail]/Drafts"
> 		set record = "+[Gmail]/Sent Mail"
> 		set trash = "+[Gmail]/Trash"
>
> 	- Where the imap_pass, smtp_pass would be the App password or
> 	  the mailbox password.
>
>
> Regards,
>
> Sumitra
>
>

Re: your mail

[Konstantin Ryabitsev]

On Thu, Feb 03, 2022 at 02:41:44PM +0100, Harald Hoyer wrote:

> -----BEGIN PGP PUBLIC KEY BLOCK-----

Updated, thanks.

-K

Re: your mail

[Willy Tarreau]

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

Re: your mail

[CGEL]

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

Re: your mail

[Christoph Hellwig]

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.

Re: your mail

[Christian König]

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&amp;data=04%7C01%7Cray.huang%40amd.com%7C4ccc617b77d746db5af108d8f98db612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533734805563118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=9bSP90LYdJyJYJYmuphVmqk%2B3%2FE4JPrtXkQTbxwAt68%3D&amp;reserved=0

Re: your mail

[Christian König]

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&amp;data=04%7C01%7Cray.huang%40amd.com%7C4ccc617b77d746db5af108d8f98db612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533734805563118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=9bSP90LYdJyJYJYmuphVmqk%2B3%2FE4JPrtXkQTbxwAt68%3D&amp;reserved=0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: your mail

[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&amp;data=04%7C01%7Cray.huang%40amd.com%7C4ccc617b77d746db5af108d8f98db612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533734805563118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=9bSP90LYdJyJYJYmuphVmqk%2B3%2FE4JPrtXkQTbxwAt68%3D&amp;reserved=0

Re: your mail

[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&amp;data=04%7C01%7Cray.huang%40amd.com%7C4ccc617b77d746db5af108d8f98db612%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533734805563118%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=9bSP90LYdJyJYJYmuphVmqk%2B3%2FE4JPrtXkQTbxwAt68%3D&amp;reserved=0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: your mail

[Manivannan Sadhasivam]

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
> 

Re: your mail

[Steven Rostedt]

On Mon, Mar 22, 2021 at 05:36:44PM -0400, Steven Rostedt wrote:

$@#@#$%%%!!!!

Bah! There was another typo in the email list!

Take 3

-- Steve

Re: your mail

[Steven Rostedt]

On Mon, Mar 22, 2021 at 05:21:56PM -0400, Steven Rostedt wrote:

Bah! John 'Warthog' Hawley email had those single quotes in it that I cut and
pasted into the Cc list, causing the quilt mail parsing to fail, but as LKML
was in the "To" part, it still sent!

Take 2

-- Steve

Re: your mail

[Andy Shevchenko]

On Wed, Dec 02, 2020 at 08:51:27PM +0200, Andy Shevchenko wrote:
> On Thu, Dec 03, 2020 at 03:27:33AM +0900, Yun Levi wrote:
> > On Thu, Dec 3, 2020 at 2:36 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Wed, Dec 02, 2020 at 09:26:05AM -0800, Yury Norov wrote:

...

> > > Side note: speaking of performance, any plans to fix for_each_*_bit*() for
> > > cases when the nbits is known to be <= BITS_PER_LONG?
> > >
> > > Now it makes an awful code generation (something like few hundred bytes of
> > > code).
> 
> > Frankly Speaking, I don't have an idea in now.....
> > Could you share your idea or wisdom?
> 
> Something like (I may be mistaken by names, etc, I'm not a compiler expert,
> and this is in pseudo language, I don't remember all API names by hart,
> just to express the idea) as a rough first step
> 
> __builtin_constant(nbits, find_next_set_bit_long, find_next_set_bit)
> 
> find_next_set_bit_long()
> {
> 	unsigned long v = BIT_LAST_WORD(i);
> 	return ffs_long(v);
> }
> 
> Same for find_first_set_bit() -> map it to ffs_long().
> 
> And I believe it can be optimized more.

Btw it will also require to reconsider test cases where such constant small
nbits values are passed (forcing compiler to avoid optimization somehow, one
way is to try random nbits for some test cases).

-- 
With Best Regards,
Andy Shevchenko

Re: your mail

[Andy Shevchenko]

On Thu, Dec 03, 2020 at 03:27:33AM +0900, Yun Levi wrote:
> On Thu, Dec 3, 2020 at 2:36 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Wed, Dec 02, 2020 at 09:26:05AM -0800, Yury Norov wrote:

...

> > Side note: speaking of performance, any plans to fix for_each_*_bit*() for
> > cases when the nbits is known to be <= BITS_PER_LONG?
> >
> > Now it makes an awful code generation (something like few hundred bytes of
> > code).

> Frankly Speaking, I don't have an idea in now.....
> Could you share your idea or wisdom?

Something like (I may be mistaken by names, etc, I'm not a compiler expert,
and this is in pseudo language, I don't remember all API names by hart,
just to express the idea) as a rough first step

__builtin_constant(nbits, find_next_set_bit_long, find_next_set_bit)

find_next_set_bit_long()
{
	unsigned long v = BIT_LAST_WORD(i);
	return ffs_long(v);
}

Same for find_first_set_bit() -> map it to ffs_long().

And I believe it can be optimized more.

-- 
With Best Regards,
Andy Shevchenko

Re: your mail

[Johan Hovold]

On Thu, Sep 03, 2020 at 05:36:34PM +0000, Barnett, Andy wrote:
> Title - Edgport/4 compatibility question

> Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

Please resend with a proper Subject line and without the above
disclaimer.

And remember to CC the USB list (linux-usb@vger.kernel.org).

Johan

Re: your mail

[Bjorn Andersson]

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

Re: your mail

[Laurent Pinchart]

Hi Jacopo,

On Mon, Aug 10, 2020 at 09:28:14AM +0200, Jacopo Mondi wrote:
> On Sun, Aug 09, 2020 at 06:53:11PM +0300, Laurent Pinchart wrote:
> > On Wed, Aug 05, 2020 at 12:57:17PM +0200, Jacopo Mondi wrote:
> > > Subject: [PATCH 0/4] media: docs: Document pixel array properties
> > >
> > > Hans' patch "[PATCH] imx219: selection compliance fixes" sparkled a discussion
> > > on how the V4L2 selection targets have to be used in order to access an
> > > image sensor pixel array properties.
> > >
> > > The discussion shown how much under-specified that part was, so this is
> > > an attempt to provide a bit documentation for this.
> > >
> > > My feeling is that we're hijacking the existing targets for this use case
> > > and we should probably define new ones, considering how few users we have in
> > > mainline of them at the moment.
> >
> > Do you mean you think we should create new targets instead of reusing
> > the existing ones as you do in this series ? I don't see anything really
> > wrong in reusing the existing targets, provided we document them
> > properly, and it's not too much of a hack (that is, the documented
> > purpose reasonably matches the target name), but maybe I'm missing the
> > issue.
> 
> Yes, that's what I meant.
> 
> To me, if you have something and you need to document it with "if
> applied to X it means Y, if applied to Z it means W etcetc" feels like
> we're abusing it.

I don't really agree, I think this is common, and I don't really see a
problem. Lots of V4L2 ioctls (or the structures they use) document how
they apply to capture and output devices for instance, and I don't think
that splitting ioctls into _CAPTURE and _OUTPUT variants would help
much.

If you were using a COMPOSE rectangle to specify a crop operation when
used with camera sensors it would of course be an API abuse, but as long
as CROP is crop, I see nothing wrong in differences in details of how
the rectangles apply to different types of devices.

> Having sensor's specific targets would make clear
> what a target represents without the ambiguities of defining the
> symbol semantic depending on the device it applies to (which means
> userspace would need to know what kind of device it's dealing with
> precisely).

Userspace would always need that, in order to pick the applicable
target.

> That said, my preference would be using a different API, but see my
> reply to your other email for that.
> 
> > > On top Hans' patch with reworded commit message and minor updates.
> > >
> > > For reference, we're using the V4L2 selection targets in libcamera to retrieve
> > > the sensor pixel array properties to be reported to applications for
> > > calibration purposes. The currently defined pixel properties for libcamera
> > > are available here:
> > > https://git.linuxtv.org/libcamera.git/tree/src/libcamera/property_ids.yaml#n390
> > >
> > > Thanks
> > >    j
> > >
> > > Hans Verkuil (1):
> > >   media: i2c: imx219: Selection compliance fixes
> > >
> > > Jacopo Mondi (3):
> > >   media: docs: Describe pixel array properties
> > >   media: docs: Describe targets for sensor properties
> > >   media: docs: USe SUBDEV_G_SELECTION for sensor properties
> > >
> > >  .../userspace-api/media/v4l/dev-subdev.rst    | 85 +++++++++++++++++++
> > >  .../media/v4l/v4l2-selection-targets.rst      | 49 +++++++++++
> > >  .../media/v4l/vidioc-subdev-g-selection.rst   |  4 +
> > >  drivers/media/i2c/imx219.c                    | 17 ++--
> > >  4 files changed, 147 insertions(+), 8 deletions(-)

-- 
Regards,

Laurent Pinchart

Re: your mail

[Amit Pundir]

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

Re: your mail

[Bjorn Andersson]

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

Re: your mail

[Jacopo Mondi]

Hi Laurent,

On Sun, Aug 09, 2020 at 06:53:11PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Wed, Aug 05, 2020 at 12:57:17PM +0200, Jacopo Mondi wrote:
> > Subject: [PATCH 0/4] media: docs: Document pixel array properties
> >
> > Hans' patch "[PATCH] imx219: selection compliance fixes" sparkled a discussion
> > on how the V4L2 selection targets have to be used in order to access an
> > image sensor pixel array properties.
> >
> > The discussion shown how much under-specified that part was, so this is
> > an attempt to provide a bit documentation for this.
> >
> > My feeling is that we're hijacking the existing targets for this use case
> > and we should probably define new ones, considering how few users we have in
> > mainline of them at the moment.
>
> Do you mean you think we should create new targets instead of reusing
> the existing ones as you do in this series ? I don't see anything really
> wrong in reusing the existing targets, provided we document them
> properly, and it's not too much of a hack (that is, the documented
> purpose reasonably matches the target name), but maybe I'm missing the
> issue.

Yes, that's what I meant.

To me, if you have something and you need to document it with "if
applied to X it means Y, if applied to Z it means W etcetc" feels like
we're abusing it. Having sensor's specific targets would make clear
what a target represents without the ambiguities of defining the
symbol semantic depending on the device it applies to (which means
userspace would need to know what kind of device it's dealing with
precisely).

That said, my preference would be using a different API, but see my
reply to your other email for that.

Thanks
  j

>
> > On top Hans' patch with reworded commit message and minor updates.
> >
> > For reference, we're using the V4L2 selection targets in libcamera to retrieve
> > the sensor pixel array properties to be reported to applications for
> > calibration purposes. The currently defined pixel properties for libcamera
> > are available here:
> > https://git.linuxtv.org/libcamera.git/tree/src/libcamera/property_ids.yaml#n390
> >
> > Thanks
> >    j
> >
> > Hans Verkuil (1):
> >   media: i2c: imx219: Selection compliance fixes
> >
> > Jacopo Mondi (3):
> >   media: docs: Describe pixel array properties
> >   media: docs: Describe targets for sensor properties
> >   media: docs: USe SUBDEV_G_SELECTION for sensor properties
> >
> >  .../userspace-api/media/v4l/dev-subdev.rst    | 85 +++++++++++++++++++
> >  .../media/v4l/v4l2-selection-targets.rst      | 49 +++++++++++
> >  .../media/v4l/vidioc-subdev-g-selection.rst   |  4 +
> >  drivers/media/i2c/imx219.c                    | 17 ++--
> >  4 files changed, 147 insertions(+), 8 deletions(-)
>
> --
> Regards,
>
> Laurent Pinchart

Re: your mail

[Laurent Pinchart]

Hi Jacopo,

On Wed, Aug 05, 2020 at 12:57:17PM +0200, Jacopo Mondi wrote:
> Subject: [PATCH 0/4] media: docs: Document pixel array properties
> 
> Hans' patch "[PATCH] imx219: selection compliance fixes" sparkled a discussion
> on how the V4L2 selection targets have to be used in order to access an
> image sensor pixel array properties.
> 
> The discussion shown how much under-specified that part was, so this is
> an attempt to provide a bit documentation for this.
> 
> My feeling is that we're hijacking the existing targets for this use case
> and we should probably define new ones, considering how few users we have in
> mainline of them at the moment.

Do you mean you think we should create new targets instead of reusing
the existing ones as you do in this series ? I don't see anything really
wrong in reusing the existing targets, provided we document them
properly, and it's not too much of a hack (that is, the documented
purpose reasonably matches the target name), but maybe I'm missing the
issue.

> On top Hans' patch with reworded commit message and minor updates.
> 
> For reference, we're using the V4L2 selection targets in libcamera to retrieve
> the sensor pixel array properties to be reported to applications for
> calibration purposes. The currently defined pixel properties for libcamera
> are available here:
> https://git.linuxtv.org/libcamera.git/tree/src/libcamera/property_ids.yaml#n390
> 
> Thanks
>    j
> 
> Hans Verkuil (1):
>   media: i2c: imx219: Selection compliance fixes
> 
> Jacopo Mondi (3):
>   media: docs: Describe pixel array properties
>   media: docs: Describe targets for sensor properties
>   media: docs: USe SUBDEV_G_SELECTION for sensor properties
> 
>  .../userspace-api/media/v4l/dev-subdev.rst    | 85 +++++++++++++++++++
>  .../media/v4l/v4l2-selection-targets.rst      | 49 +++++++++++
>  .../media/v4l/vidioc-subdev-g-selection.rst   |  4 +
>  drivers/media/i2c/imx219.c                    | 17 ++--
>  4 files changed, 147 insertions(+), 8 deletions(-)

-- 
Regards,

Laurent Pinchart

Re: your mail

[G.W. Haywood]

Hi there,

On Sat, 27 Jun 2020, helen wrote:

> ... lies snipped ...

If anyone is interested, I can stop this with a milter.

-- 

73,
Ged.

Re: your mail

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2847 bytes --]

On 2020-06-24 at 00:38:39, shejan shuza wrote:
> Hi, I have a repository with about 55GB of contents, with binary files
> that are less than 100MB each (so no LFS mode) from a project which
> has almost filled up an entire hard drive. I am trying to add all of
> the contents to a git repo and push it to GitHub but every time I do
> 
> git add .
> 
> in the folder with my contents after initializing and setting my
> remote, git starts caching all the files to .git/objects, making the
> .git folder grow in size rapidly. All the files are binaries, so git
> cannot stage changes between versions anyway, so there is no reason to
> cache versions.

What you're experiencing is normal; storing files in the .git directory
is how Git keeps track of them.  It can't rely on the copies in your
working tree because you can modify those files at any time, and if you
did so, relying on them would corrupt the repository.

Also, note that Git can and does deltify changes between revisions once
the data is packed, regardless of whether the file is binary, but how
well it does so depends on your data.  For example, if it's compressed,
it likely doesn't deltify very well, so storing things like compressed
images or zip files using deflate is generally going to result in a
bloated repository.

However, if you don't need versioning for these files, then you don't
need a Git repository.  Git is a tool for versioning files, not a
general storage mechanism.  You may find a cloud storage bucket or some
other artifact storage service may meet your needs better.

I will also tell you from a practical point of view that almost nobody
(including you) will want to host a 55 GB repository filled with binary
blobs.  Usually repacking these repositories is very expensive,
requiring extensive CPU and memory usage for a prolonged time for little
useful benefit.

> Is there any way, such as editing the git attributes or changing
> something about how files are staged in the git repository, to only
> just add indexes or references to files in the repository rather than
> cache them into the .git folder, while also being able to push all the
> data to GitHub?

This is how Git LFS and similar tools, like git-annex, work.  Git LFS
will create copies of the objects in your .git directory though, at
least until they're pushed to the server, at which point they can be
pruned.  Git LFS has the same limitation as Git here.  I'm less familiar
with git-annex, but it is also a popular choice.

However, as mentioned, it sounds like you don't need versioning at all,
so unless you do, Git with Git LFS will be no more suitable for this
than plain Git.  If that's the case, I encourage you to explore
alternate solutions.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: your mail

[Greg KH]

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

Re: your mail

[Heikki Krogerus]

Hi Jakub,

On Mon, May 11, 2020 at 04:40:05PM +0300, Andy Shevchenko wrote:
> On Mon, May 11, 2020 at 3:29 PM Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On 5/11/20 1:44 PM, Andy Shevchenko wrote:
> 
> ...
> 
> > > I would rather disable them and issue a firmware bug.
> > > Vendors, including us, should do something sane about this.
> >
> > I have to partially disagree here. I agree that for future hardware
> > versions the firmware team of those devices should offer a saner
> > interface. But for the current hardware gen I guess we are stuck
> > with this and having a DMI table for popular models (well any model
> > a Linux user is willing to submit a quirk for) is better then simply
> > not having things working under Linux.
> >
> > I do wonder what Windows does here though. Perhaps the INT3513 device
> > has some ACPI methods to query for more info, like how many Type-C
> > controllers there actually are?
> 
> I think they do silly things there in usual obscure MS way, i.e.
> hardcoding everything in the driver per platform.
> That's why I'm really disappointed how things are going on.

I've been trying to figure out which exact NUC10i3 your NUC is? I
can't find a NUC10i3 that uses Comet Lake -S?

If your NUC isn't actually "-S" variant, then the ACPI device entry
with HID INT3515 should return 0 from its _STA method.

But can you please share the full name of your board (like NUC10i3FNH
or something like that - should read on the bottom of the device).
Also, dmesg output would be useful.

thanks,

-- 
heikki

Re: your mail

[Heikki Krogerus]

Hi Jakub,

On Mon, May 11, 2020 at 04:40:05PM +0300, Andy Shevchenko wrote:
> On Mon, May 11, 2020 at 3:29 PM Hans de Goede <hdegoede@redhat.com> wrote:
> > On 5/11/20 1:44 PM, Andy Shevchenko wrote:
> 
> ...
> 
> > > I would rather disable them and issue a firmware bug.
> > > Vendors, including us, should do something sane about this.
> >
> > I have to partially disagree here. I agree that for future hardware
> > versions the firmware team of those devices should offer a saner
> > interface. But for the current hardware gen I guess we are stuck
> > with this and having a DMI table for popular models (well any model
> > a Linux user is willing to submit a quirk for) is better then simply
> > not having things working under Linux.
> >
> > I do wonder what Windows does here though. Perhaps the INT3513 device
> > has some ACPI methods to query for more info, like how many Type-C
> > controllers there actually are?
> 
> I think they do silly things there in usual obscure MS way, i.e.
> hardcoding everything in the driver per platform.
> That's why I'm really disappointed how things are going on.

I've been trying to figure out which exact NUC10i3 your NUC is? I
can't find a NUC10i3 that uses Comet Lake -S?

If your NUC isn't actually "-S" variant, then the ACPI device entry
with HID INT3515 should return 0 from its _STA method.

But can you please share the full name of your board (like NUC10i3FNH
or something like that - should read on the bottom of the device).
Also, dmesg output would be useful.

thanks,

-- 
heikki

Re: your mail

[Andy Shevchenko]

On Mon, May 11, 2020 at 3:29 PM Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 5/11/20 1:44 PM, Andy Shevchenko wrote:

...

> > I would rather disable them and issue a firmware bug.
> > Vendors, including us, should do something sane about this.
>
> I have to partially disagree here. I agree that for future hardware
> versions the firmware team of those devices should offer a saner
> interface. But for the current hardware gen I guess we are stuck
> with this and having a DMI table for popular models (well any model
> a Linux user is willing to submit a quirk for) is better then simply
> not having things working under Linux.
>
> I do wonder what Windows does here though. Perhaps the INT3513 device
> has some ACPI methods to query for more info, like how many Type-C
> controllers there actually are?

I think they do silly things there in usual obscure MS way, i.e.
hardcoding everything in the driver per platform.
That's why I'm really disappointed how things are going on.

-- 
With Best Regards,
Andy Shevchenko

Re: your mail

[Andy Shevchenko]

On Mon, May 11, 2020 at 3:29 PM Hans de Goede <hdegoede@redhat.com> wrote:
> On 5/11/20 1:44 PM, Andy Shevchenko wrote:

...

> > I would rather disable them and issue a firmware bug.
> > Vendors, including us, should do something sane about this.
>
> I have to partially disagree here. I agree that for future hardware
> versions the firmware team of those devices should offer a saner
> interface. But for the current hardware gen I guess we are stuck
> with this and having a DMI table for popular models (well any model
> a Linux user is willing to submit a quirk for) is better then simply
> not having things working under Linux.
>
> I do wonder what Windows does here though. Perhaps the INT3513 device
> has some ACPI methods to query for more info, like how many Type-C
> controllers there actually are?

I think they do silly things there in usual obscure MS way, i.e.
hardcoding everything in the driver per platform.
That's why I'm really disappointed how things are going on.

-- 
With Best Regards,
Andy Shevchenko

Re: your mail

[Hans de Goede]

Hi,

On 5/11/20 1:44 PM, Andy Shevchenko wrote:
> +Cc: Hans

Thank you, I'm afraid that I do not have much of value
to add here, Heikki knows these systems (with an INT3515 device)
a lot better then I do.

> On Mon, May 11, 2020 at 2:38 PM Heikki Krogerus
> <heikki.krogerus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>>
>> +Andy
>>
>> Adding also the linux-usb mailing list.
>>
>> On Mon, May 11, 2020 at 01:06:18PM +0200, jakub-FiUXBBwNs2Q@public.gmane.org wrote:
>>> Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
>>> with cpu interrups causing issues with deeper CPU sleep and increased power
>>> usage. Also load is always 1 even if machine has nothing to do.
>>>
>>> I made a reasearch and found that device named TPS6598x interrupts my CPU. This
>>> device is related with USB and according to datasheet it's "USB Interface IC USB
>>> Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
>>> nothing connected to NUC except power plug and ethernet cable.
>>>
>>> Screenshots: https://imgur.com/a/uw9NDCi
>>>
>>> How to solve this issue? Could you help me?
>>
>> My guess is that the IRQ resource is not correct for the PD
>> controller causing you to see irq flood.
>>
>> The problem is that the ACPI device entry (the node) on this platform
>> has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
>> single ACPI device entry can represent up to 4 USB PD controllers. The
>> problem is that there is no way to know which IRQ resource belongs to
>> which I2CSerialBus resource :-(.
>>
>> Andy, this is one of those multi-instantiate I2C slave devices with
>> HID INT3515.
>>
>> The only solution I can think of is that we start maintaining DMI
>> quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
>> supply the correct i2c to irq resource mapping for every platform
>> that has this device(s).
> 
> I would rather disable them and issue a firmware bug.
> Vendors, including us, should do something sane about this.

I have to partially disagree here. I agree that for future hardware
versions the firmware team of those devices should offer a saner
interface. But for the current hardware gen I guess we are stuck
with this and having a DMI table for popular models (well any model
a Linux user is willing to submit a quirk for) is better then simply
not having things working under Linux.

I do wonder what Windows does here though. Perhaps the INT3513 device
has some ACPI methods to query for more info, like how many Type-C
controllers there actually are?

Regards,

Hans

Re: your mail

[Hans de Goede]

Hi,

On 5/11/20 1:44 PM, Andy Shevchenko wrote:
> +Cc: Hans

Thank you, I'm afraid that I do not have much of value
to add here, Heikki knows these systems (with an INT3515 device)
a lot better then I do.

> On Mon, May 11, 2020 at 2:38 PM Heikki Krogerus
> <heikki.krogerus@linux.intel.com> wrote:
>>
>> +Andy
>>
>> Adding also the linux-usb mailing list.
>>
>> On Mon, May 11, 2020 at 01:06:18PM +0200, jakub@bilan.me wrote:
>>> Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
>>> with cpu interrups causing issues with deeper CPU sleep and increased power
>>> usage. Also load is always 1 even if machine has nothing to do.
>>>
>>> I made a reasearch and found that device named TPS6598x interrupts my CPU. This
>>> device is related with USB and according to datasheet it's "USB Interface IC USB
>>> Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
>>> nothing connected to NUC except power plug and ethernet cable.
>>>
>>> Screenshots: https://imgur.com/a/uw9NDCi
>>>
>>> How to solve this issue? Could you help me?
>>
>> My guess is that the IRQ resource is not correct for the PD
>> controller causing you to see irq flood.
>>
>> The problem is that the ACPI device entry (the node) on this platform
>> has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
>> single ACPI device entry can represent up to 4 USB PD controllers. The
>> problem is that there is no way to know which IRQ resource belongs to
>> which I2CSerialBus resource :-(.
>>
>> Andy, this is one of those multi-instantiate I2C slave devices with
>> HID INT3515.
>>
>> The only solution I can think of is that we start maintaining DMI
>> quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
>> supply the correct i2c to irq resource mapping for every platform
>> that has this device(s).
> 
> I would rather disable them and issue a firmware bug.
> Vendors, including us, should do something sane about this.

I have to partially disagree here. I agree that for future hardware
versions the firmware team of those devices should offer a saner
interface. But for the current hardware gen I guess we are stuck
with this and having a DMI table for popular models (well any model
a Linux user is willing to submit a quirk for) is better then simply
not having things working under Linux.

I do wonder what Windows does here though. Perhaps the INT3513 device
has some ACPI methods to query for more info, like how many Type-C
controllers there actually are?

Regards,

Hans

Re: your mail

[Andy Shevchenko]

+Cc: Hans

On Mon, May 11, 2020 at 2:38 PM Heikki Krogerus
<heikki.krogerus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>
> +Andy
>
> Adding also the linux-usb mailing list.
>
> On Mon, May 11, 2020 at 01:06:18PM +0200, jakub-FiUXBBwNs2Q@public.gmane.org wrote:
> > Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
> > with cpu interrups causing issues with deeper CPU sleep and increased power
> > usage. Also load is always 1 even if machine has nothing to do.
> >
> > I made a reasearch and found that device named TPS6598x interrupts my CPU. This
> > device is related with USB and according to datasheet it's "USB Interface IC USB
> > Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
> > nothing connected to NUC except power plug and ethernet cable.
> >
> > Screenshots: https://imgur.com/a/uw9NDCi
> >
> > How to solve this issue? Could you help me?
>
> My guess is that the IRQ resource is not correct for the PD
> controller causing you to see irq flood.
>
> The problem is that the ACPI device entry (the node) on this platform
> has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
> single ACPI device entry can represent up to 4 USB PD controllers. The
> problem is that there is no way to know which IRQ resource belongs to
> which I2CSerialBus resource :-(.
>
> Andy, this is one of those multi-instantiate I2C slave devices with
> HID INT3515.
>
> The only solution I can think of is that we start maintaining DMI
> quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
> supply the correct i2c to irq resource mapping for every platform
> that has this device(s).

I would rather disable them and issue a firmware bug.
Vendors, including us, should do something sane about this.

> > Kernel version:
> >
> > Linux NUC 5.6.11-050611-generic #202005061022 SMP Wed May 6 10:27:04 UTC 2020
> > x86_64 x86_64 x86_64 GNU/Linux
> >
> > Bios version:
> > FNCML357 Version: 0039 Date: 3/12/2020

-- 
With Best Regards,
Andy Shevchenko

Re: your mail

[Andy Shevchenko]

+Cc: Hans

On Mon, May 11, 2020 at 2:38 PM Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
>
> +Andy
>
> Adding also the linux-usb mailing list.
>
> On Mon, May 11, 2020 at 01:06:18PM +0200, jakub@bilan.me wrote:
> > Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
> > with cpu interrups causing issues with deeper CPU sleep and increased power
> > usage. Also load is always 1 even if machine has nothing to do.
> >
> > I made a reasearch and found that device named TPS6598x interrupts my CPU. This
> > device is related with USB and according to datasheet it's "USB Interface IC USB
> > Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
> > nothing connected to NUC except power plug and ethernet cable.
> >
> > Screenshots: https://imgur.com/a/uw9NDCi
> >
> > How to solve this issue? Could you help me?
>
> My guess is that the IRQ resource is not correct for the PD
> controller causing you to see irq flood.
>
> The problem is that the ACPI device entry (the node) on this platform
> has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
> single ACPI device entry can represent up to 4 USB PD controllers. The
> problem is that there is no way to know which IRQ resource belongs to
> which I2CSerialBus resource :-(.
>
> Andy, this is one of those multi-instantiate I2C slave devices with
> HID INT3515.
>
> The only solution I can think of is that we start maintaining DMI
> quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
> supply the correct i2c to irq resource mapping for every platform
> that has this device(s).

I would rather disable them and issue a firmware bug.
Vendors, including us, should do something sane about this.

> > Kernel version:
> >
> > Linux NUC 5.6.11-050611-generic #202005061022 SMP Wed May 6 10:27:04 UTC 2020
> > x86_64 x86_64 x86_64 GNU/Linux
> >
> > Bios version:
> > FNCML357 Version: 0039 Date: 3/12/2020

-- 
With Best Regards,
Andy Shevchenko

Re: your mail

[Heikki Krogerus]

+Andy

Adding also the linux-usb mailing list.

On Mon, May 11, 2020 at 01:06:18PM +0200, jakub@bilan.me wrote:
> Hello, I'm running Intel NUC10i3 with Ubuntu 20.04 on board. I have a problem
> with cpu interrups causing issues with deeper CPU sleep and increased power
> usage. Also load is always 1 even if machine has nothing to do.
>  
> I made a reasearch and found that device named TPS6598x interrupts my CPU. This
> device is related with USB and according to datasheet it's "USB Interface IC USB
> Type-CG and USB PD controller power switch and high-speed multiplexer ". I have
> nothing connected to NUC except power plug and ethernet cable.
>  
> Screenshots: https://imgur.com/a/uw9NDCi
>  
> How to solve this issue? Could you help me?

My guess is that the IRQ resource is not correct for the PD
controller causing you to see irq flood.

The problem is that the ACPI device entry (the node) on this platform
has 4 I2CSerialBus resources and 4 IRQ resources. The idea is that the
single ACPI device entry can represent up to 4 USB PD controllers. The
problem is that there is no way to know which IRQ resource belongs to
which I2CSerialBus resource :-(.

Andy, this is one of those multi-instantiate I2C slave devices with
HID INT3515.

The only solution I can think of is that we start maintaining DMI
quirk table in drivers/platform/x86/i2c-multi-instantiate.c where we
supply the correct i2c to irq resource mapping for every platform
that has this device(s).

> Kernel version:
>  
> Linux NUC 5.6.11-050611-generic #202005061022 SMP Wed May 6 10:27:04 UTC 2020
> x86_64 x86_64 x86_64 GNU/Linux
>  
> Bios version:
> FNCML357 Version: 0039 Date: 3/12/2020
> -- 
> Best regards
> Jakub Bilan

thanks,

-- 
heikki

Re: your mail

[Thomas Bogendoerfer]

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 ]

Re: your mail

[Christian Couder]

Hi Taylor and Han-Wen,

On Wed, Nov 20, 2019 at 6:30 AM Taylor Blau <me@ttaylorr.com> wrote:
>
> On Tue, Nov 19, 2019 at 07:49:17PM -0800, Han-Wen Nienhuys wrote:
> >
> > I spent the last few weeks cobbling together an implementation of the
> > reftable format in C and in Go. I thought this would be cool to add to
> > git-core, but I doubt whether I will have enough time to see such an
> > effort through. Maybe some of you would want to try integrating it
> > into the Git-core code base?  Example code is here:
> >
> >   https://github.com/google/reftable/blob/master/c/api.h#L153

Interesting!

> Very exciting, and thanks for your work on this. I haven't taken a
> close look at the code yet, so I'm sure taking this further involves a
> much more careful examination.
>
> I know that Christian Couder (who you CC-d on this thread) was also
> working on this for either GitLab or Booking.com.
>
> Christian -- are you still working on this for either one of those
> entities? If so, is there some way to unify these two efforts?

Yeah, I started working on this last year for Booking.com, and I am
now slowly working on it for GitLab. It is not yet finished because it
has been low priority work.

I took a very quick look at Han-Wen's implementation and it looks very
different from mine from the outside. It seems more complete, but
might be less integrated into the Git code base.

Best,
Christian.

Re: your mail

[Taylor Blau]

Hi Han-Wen,


On Tue, Nov 19, 2019 at 07:49:17PM -0800, Han-Wen Nienhuys wrote:
> Hey folks,
>
> I spent the last few weeks cobbling together an implementation of the
> reftable format in C and in Go. I thought this would be cool to add to
> git-core, but I doubt whether I will have enough time to see such an
> effort through. Maybe some of you would want to try integrating it
> into the Git-core code base?  Example code is here:
>
>   https://github.com/google/reftable/blob/master/c/api.h#L153

Very exciting, and thanks for your work on this. I haven't taken a
close look at the code yet, so I'm sure taking this further involves a
much more careful examination.

I know that Christian Couder (who you CC-d on this thread) was also
working on this for either GitLab or Booking.com.

Christian -- are you still working on this for either one of those
entities? If so, is there some way to unify these two efforts?

> cheers!
> --

Thanks,
Taylor

Re: your mail

[Greg Kroah-Hartman]

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-

Re: your mail

[Greg Kroah-Hartman]

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-

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: your mail

[Greg Kroah-Hartman]

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-

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: your mail

[Robert Morgan]

Apologies list!  Thanks Kevin.  That's what I get for troubleshooting
plain-text in Gmail and quickly sending a subscribe email before
walking out.

Robert


On Thu, Jul 11, 2019 at 3:18 PM Kevin Daudt <me@ikke.info> wrote:
>
> On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> > subscribe git
>
> You need to send this to majordomo@vger.kernel.org. Sending it to the
> git mailing list will not do a lot.
>
> Kevin

Re: your mail

[Kevin Daudt]

On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> subscribe git

You need to send this to majordomo@vger.kernel.org. Sending it to the
git mailing list will not do a lot.

Kevin

Re: your mail

[Tejun Heo]

On Wed, Jun 26, 2019 at 04:52:36PM +0200, Sebastian Andrzej Siewior wrote:
> A small series of tiny cleanups.

Applied 1-2 to wq/for-5.3.

Thanks.

-- 
tejun

Re: your mail

[Karel Zak]

On Thu, Apr 18, 2019 at 08:59:54AM +0100, StuartIanNaylor wrote:
> A strange thing happens with zramctl as if all services where running the
> high order zram device of zramdrive is no longer visible after removing
> lower order devices.

Sounds like https://github.com/karelzak/util-linux/issues/521, fixed
in version 2.31

> Its Raspbian 4.14 with util-linux 2.29.2

The current upstream is 2.33.2 :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: your mail

[Nicholas Piggin]

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

Re: your mail

[Peter Zijlstra]

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
> 

Re: your mail

[Maxim Levitsky]

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

your mail

[Maxim Levitsky]

On Tue, 2019-03-19@09:22 -0600, Keith Busch wrote:
> On Tue, Mar 19, 2019@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

Re: your mail

[Dan Carpenter]

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

Re: your mail

[Stefan Hajnoczi]

[-- 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 --]

Re: your mail

[Stefan Hajnoczi]

[-- 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 --]

your mail

[Stefan Hajnoczi]

On Thu, Mar 21, 2019@07:07:38PM +0200, Maxim Levitsky wrote:
> On Thu, 2019-03-21@16:13 +0000, Stefan Hajnoczi wrote:
> > On Tue, Mar 19, 2019@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20190325/f46e8674/attachment.sig>

Re: your mail

[Maxim Levitsky]

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

Re: your mail

[Maxim Levitsky]

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

your mail

[Maxim Levitsky]

On Thu, 2019-03-21@16:13 +0000, Stefan Hajnoczi wrote:
> On Tue, Mar 19, 2019@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

Re: your mail

[Stefan Hajnoczi]

[-- 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 --]

Re: your mail

[Stefan Hajnoczi]

[-- 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 --]

your mail

[Stefan Hajnoczi]

On Tue, Mar 19, 2019@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20190321/43a43762/attachment.sig>

Re: your mail

[Maxim Levitsky]

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

Re: your mail

[Maxim Levitsky]

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

your mail

[Maxim Levitsky]

On Wed, 2019-03-20@11:03 -0600, Keith Busch wrote:
> On Wed, Mar 20, 2019@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

Re: your mail

[Keith Busch]

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.

Re: your mail

[Keith Busch]

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.

your mail

[Keith Busch]

On Wed, Mar 20, 2019@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.

Re: your mail

[Maxim Levitsky]

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

Re: your mail

[Maxim Levitsky]

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

your mail

[Maxim Levitsky]

On Tue, 2019-03-19@23:49 +0000, Chaitanya Kulkarni wrote:
> Hi Keith,
> On 03/19/2019 08:21 AM, Keith Busch wrote:
> > On Tue, Mar 19, 2019@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 at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-nvme
> > 
> 
> 
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: your mail

[Maxim Levitsky]

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

Re: your mail

[Maxim Levitsky]

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

your mail

[Maxim Levitsky]

On Tue, 2019-03-19@09:22 -0600, Keith Busch wrote:
> On Tue, Mar 19, 2019@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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: your mail

[Greg Kroah-Hartman]

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?

Re: your mail

[Chaitanya Kulkarni]

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
>

Re: your mail

[Chaitanya Kulkarni]

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
>

your mail

[Chaitanya Kulkarni]

Hi Keith,
On 03/19/2019 08:21 AM, Keith Busch wrote:
> On Tue, Mar 19, 2019@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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
>

Re: your mail

[Keith Busch]

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).

Re: your mail

[Keith Busch]

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).

your mail

[Keith Busch]

On Tue, Mar 19, 2019@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).

Re: your mail

[Roman Gushchin]

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!

Re: your mail

[Jarkko Sakkinen]

On Mon, Feb 04, 2019 at 01:32:59PM -0800, Matthew Garrett wrote:
> V2: Rebased on top of Roberto's patches, no other changes. Tested on an
> Intel NUC using PTT-based TPM2, binary_bios_measurements contains boot
> events.

Thank you. Looking forward to review this. I'll land Roberto's patches
and then this would be next in the queue.

/Jarkko

Re: your mail

[Kevin Daudt]

On Fri, Jan 25, 2019 at 12:47:35PM +0300, Furkan DURUL wrote:
> Hello,
> My name is Furkan. I'm a new graduated Electronics and Communication
> Engineer in Turkey. In my current workplace, we use Git in all our
> projects and I really learned a lot from your Pro Git Book. I would
> like to contribute to translation of this book to Turkish. I'm also a
> freelance translator and have experience about translation.
> Look forward to hear you
> Cheers

Hello Furkan,

Welcome to the community. Pro Git is not maintained by the git
community, but is a separate project.

You can find details on how to provide translations here[0]. It looks
from that document that someone started translating the book in Turkish
as well[1].

Kind regards, Kevin


[0]:https://github.com/progit/progit2/blob/master/TRANSLATING.md
[1]:https://github.com/progit/progit2-tr

Re: your mail

[Greg KH]

On Thu, Dec 13, 2018 at 03:09:15PM +0100, Sebastian Andrzej Siewior wrote:
> Hi,
> 
> this is a backport of commit 7aa54be297655 ("locking/qspinlock, x86:
> Provide liveness guarantee") for the v4.9 stable tree.
> For the v4.4 tree the ARCH_USE_QUEUED_SPINLOCKS option got disabled on
> x86.
> For v4.9 it has been decided to do a minimal backport of the final fix
> (including all its dependencies).
> With this backport I can't reproduce the issue in the latest v4.9-RT
> tree. I was able to boot (and use) an arm64 box with these patches so it
> is not broken in an abvious way.

As Peter said, a 4.14 backport would be simpler, but I would prefer to
wait for that before accepting these patches into 4.9.

I don't want people to move from 4.9 to 4.14 and hit a regression right
away.  So if we could get a 4.14 backport first, that would be wonderful
and then allow me to take the 4.9 patches.

Seeing patches in 4.9 and 4.19 but not in 4.14 does not make me feel
good :)

And given the horrible header mistakes on this series, I'm going to drop
them to prevent anyone else from having to hand-edit them in order to
get things cleaned up.  Please resend this series after you have done
that.

thanks,

greg k-h

Re: your mail

[Sebastian Andrzej Siewior]

On 2018-12-13 09:39:46 [-0500], Sasha Levin wrote:
> On Thu, Dec 13, 2018 at 09:33:36AM -0500, Sasha Levin wrote:
> > On Thu, Dec 13, 2018 at 03:09:15PM +0100, Sebastian Andrzej Siewior wrote:
> > > Hi,
> > > 
> > > this is a backport of commit 7aa54be297655 ("locking/qspinlock, x86:
> > > Provide liveness guarantee") for the v4.9 stable tree.
> > > For the v4.4 tree the ARCH_USE_QUEUED_SPINLOCKS option got disabled on
> > > x86.
> > > For v4.9 it has been decided to do a minimal backport of the final fix
> > > (including all its dependencies).
> > > With this backport I can't reproduce the issue in the latest v4.9-RT
> > > tree. I was able to boot (and use) an arm64 box with these patches so it
> > > is not broken in an abvious way.
> > 
> > What about 4.14? I see that at least some of these patches are missing
> > there.

so v4.4 was easy peasy, v4.9 required a little work. So let me worry
about v4.14 and v4.19 next.

> Hrm, there was something really fishy with the headers on your original
> mail...

Interesting and I'm sorry. So infradead.org rejected all of my emails
saying something similar but I have no clue what went wrong.

Sebastian

Re: your mail

[Peter Zijlstra]

On Thu, Dec 13, 2018 at 09:33:36AM -0500, Sasha Levin wrote:
> On Thu, Dec 13, 2018 at 03:09:15PM +0100, Sebastian Andrzej Siewior wrote:
> > Hi,
> > 
> > this is a backport of commit 7aa54be297655 ("locking/qspinlock, x86:
> > Provide liveness guarantee") for the v4.9 stable tree.
> > For the v4.4 tree the ARCH_USE_QUEUED_SPINLOCKS option got disabled on
> > x86.
> > For v4.9 it has been decided to do a minimal backport of the final fix
> > (including all its dependencies).
> > With this backport I can't reproduce the issue in the latest v4.9-RT
> > tree. I was able to boot (and use) an arm64 box with these patches so it
> > is not broken in an abvious way.
> 
> What about 4.14? I see that at least some of these patches are missing
> there.

4.14 can have a simpler backport indeed

Re: your mail

[Sasha Levin]

On Thu, Dec 13, 2018 at 09:33:36AM -0500, Sasha Levin wrote:
>On Thu, Dec 13, 2018 at 03:09:15PM +0100, Sebastian Andrzej Siewior wrote:
>>Hi,
>>
>>this is a backport of commit 7aa54be297655 ("locking/qspinlock, x86:
>>Provide liveness guarantee") for the v4.9 stable tree.
>>For the v4.4 tree the ARCH_USE_QUEUED_SPINLOCKS option got disabled on
>>x86.
>>For v4.9 it has been decided to do a minimal backport of the final fix
>>(including all its dependencies).
>>With this backport I can't reproduce the issue in the latest v4.9-RT
>>tree. I was able to boot (and use) an arm64 box with these patches so it
>>is not broken in an abvious way.
>
>What about 4.14? I see that at least some of these patches are missing
>there.

Hrm, there was something really fishy with the headers on your original
mail...

--
Thanks,
Sasha

Re: your mail

[Sasha Levin]

On Thu, Dec 13, 2018 at 03:09:15PM +0100, Sebastian Andrzej Siewior wrote:
>Hi,
>
>this is a backport of commit 7aa54be297655 ("locking/qspinlock, x86:
>Provide liveness guarantee") for the v4.9 stable tree.
>For the v4.4 tree the ARCH_USE_QUEUED_SPINLOCKS option got disabled on
>x86.
>For v4.9 it has been decided to do a minimal backport of the final fix
>(including all its dependencies).
>With this backport I can't reproduce the issue in the latest v4.9-RT
>tree. I was able to boot (and use) an arm64 box with these patches so it
>is not broken in an abvious way.

What about 4.14? I see that at least some of these patches are missing
there.

--
Thanks,
Sasha

Re: your mail

[Paul Burton]

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

Re: your mail

[Paul Burton]

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-8NJIiSa5LzA@public.gmane.org> # MIPS parts

Thanks,
    Paul

Re: your mail

[Greg Kroah-Hartman]

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

Re: your mail

[Bruce Fields]

On Mon, Jul 23, 2018 at 11:43:55AM -0700, Marc Eshel wrote:
> Do you know of any plans to add  IETF RFC 8276 - File System Extended 
> Attributes in NFSv4 to the Linux NFS Client or Server?

I don't understand why you proposed new protocol without having anyone
in mind to implement it on the platforms where you need it.

Matt Benjamin's expressed interest in the past, but he's got a lot on
his plate so I don't know that we can count on that.

--b.

Re: your mail

[Johan Hovold]

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

Re: your mail

[Johan Hovold]

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

Re: your mail

[Dan Carpenter]

Thanks for this.  This is a lot of work.

On Wed, Jun 13, 2018 at 08:31:28PM +0300, Anton Vasilyev wrote:
> 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;

The most recent successful allocation is scsi_host_alloc().  I was
really hoping this would say something like "goto err_free_host;" or
something.  The naming style here is a "come from" label which doesn't
say if it's going to free the scsi host or not...  It turns out we don't
free the the host, but we should:

err_put_host:
	scsi_host_put(host);

The kzalloc() has it's own error message built in, and all the other
error paths as well so the dev_err() is not super important to me...

Killing the threads seems actually really complicated so maybe we should
just have a separate error paths for that.  I'm not sure...

regards,
dan carpenter

Re: your mail

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Fri, Mar 09, 2018 at 06:51:36PM +0100, Paul Cercueil wrote:
> Le 2018-03-09 16:12, Ezequiel Garcia a écrit :
> > @@ -164,8 +171,46 @@ struct jz4740_mmc_host {
> >   * trigger is when data words in MSC_TXFIFO is < 8.
> >   */
> >  #define JZ4740_MMC_FIFO_HALF_SIZE 8
> > +
> > +	void (*write_irq_mask)(struct jz4740_mmc_host *host, uint32_t val);
> > +	void (*write_irq_reg)(struct jz4740_mmc_host *host, uint32_t val);
> > +	uint32_t (*read_irq_reg)(struct jz4740_mmc_host *host);
> >  };
> 
> I'm not 100% fan about the callback idea, the original commit
> (https://github.com/gcwnow/linux/commit/62472091) doesn't use them and 
> is
> 30 lines shorter.
> 
> I'm not terribly against either, so if nobody else bug on that, feel 
> free
> to ignore my comment.

I was thinking the same as Paul too to be honest. Unless there is a
measurable benefit to having callbacks, I think its cleaner and more
readable to stick to conditionals and normal abstractions where
appropriate.

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: your mail

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Fri, Mar 09, 2018 at 06:51:36PM +0100, Paul Cercueil wrote:
> Le 2018-03-09 16:12, Ezequiel Garcia a écrit :
> > @@ -164,8 +171,46 @@ struct jz4740_mmc_host {
> >   * trigger is when data words in MSC_TXFIFO is < 8.
> >   */
> >  #define JZ4740_MMC_FIFO_HALF_SIZE 8
> > +
> > +	void (*write_irq_mask)(struct jz4740_mmc_host *host, uint32_t val);
> > +	void (*write_irq_reg)(struct jz4740_mmc_host *host, uint32_t val);
> > +	uint32_t (*read_irq_reg)(struct jz4740_mmc_host *host);
> >  };
> 
> I'm not 100% fan about the callback idea, the original commit
> (https://github.com/gcwnow/linux/commit/62472091) doesn't use them and 
> is
> 30 lines shorter.
> 
> I'm not terribly against either, so if nobody else bug on that, feel 
> free
> to ignore my comment.

I was thinking the same as Paul too to be honest. Unless there is a
measurable benefit to having callbacks, I think its cleaner and more
readable to stick to conditionals and normal abstractions where
appropriate.

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: your mail

[Tomasz Pala]

On Sun, Feb 18, 2018 at 10:28:02 +0100, Tomasz Pala wrote:

> I've already noticed this problem on February 10th:
> [btrfs-progs] coreutils-like -i parameter, splitting permissions for various tasks
> 
> In short: not possible. Regular user can only create subvolumes.

Not possible "oficially". Axel Burri has replied with more helpful approach:
https://github.com/digint/btrfs-progs-btrbk

Unfortunately this issue was not picked up by any developer, so for now
we can only wait for splitting libbtrfsutil so this task could be easier.

-- 
Tomasz Pala <gotar@pld-linux.org>

Re: your mail

[Tomasz Pala]

On Sun, Feb 18, 2018 at 08:14:25 +0000, Tomasz Kłoczko wrote:

> For some reasons btrfs pool each volume is not displayed in mount and
> df output, and I cannot find how to display volumes/snapshots usage
> using btrfs command.

In general: not possible without enabling quotas, which in turn impact
snapshot performance significally.

btrfs quota enable /
btrfs quota rescan /
btrfs qgroup sh --sort=excl /

> So now I have many volumes and snapshots in my home directory, but to
> maintain all this I must use root permission. As non-root working in
> my own home which is separated btrfs volume it would be nice to have
> the possibility to delegate permission to create, destroy,
> send/receive, mount/umount etc. snapshots, volumes like it os possible
> on zfs.

I've already noticed this problem on February 10th:
[btrfs-progs] coreutils-like -i parameter, splitting permissions for various tasks

In short: not possible. Regular user can only create subvolumes.

> BTW: someone maybe started working on something like .zfs hidden
> directory functions which is in each zfs volume mountpoint?

In btrfs world this is done differently - don't put main (working) volume in the
root, but mount some branch by default, keeping all the subvolumes next
to it. I.e. don't:

@working_subvolume
@working_subvolume/snapshots

but:

@root_of_the_fs
@root_of_the_fs/working_subvolume
@root_of_the_fs/snapshots

In fact this is manual workaroud for the problem you've mentioned.

> Have few or few tenths snapshots is not so big deal but the same on
> scale few hundreds, thousands or more snapshots I think that would be
> really hard without something like hidden .btrfs/snapshots directory.

With few hundreds of subvolumes btrfs would fail miserably.

> After few years not using btrfs (because previously was quite
> unstable) It is really good to see that now I'm not able to crash it.

It's not crashing with LTS 4.4 and 4.9 kernels, many reports of various
crashes in 4.12, 4.14 and 4.15 were posted here. It is really hard to say,
which of the post-4.9 kernels have reliable btrfs.

-- 
Tomasz Pala <gotar@pld-linux.org>

Re: your mail

[Paul Marques Mota]

Le 07/12/2017 à 23:34, Guenter Roeck a écrit :

> Nack, this is not needed.

Ok, thank you for the quick answer.

> Guenter

Regards,

-- 
Paul

Re: your mail

[Guenter Roeck]

On Thu, Dec 07, 2017 at 09:32:01PM +0000, Paul Marques Mota wrote:
> From: Paul Marques Mota <paul@marquesmota.pt>
> To: HARDWARE MONITORING <linux-hwmon@vger.kernel.org>
> Date: Thu, 7 Dec 2017 20:04:22 +0000
> Subject: [PATCH] add stack trace to deprecated hwmon_device_register()
> 
> Hi,
> 
> hwmon_device_register() in drivers/hwmon/hwmon.c prints the unhelpful
> message below on my machine:
> 
> (NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
> 
> Therefore, this patch dumps the stack at that point. In my case it is
> then obvious in the resulting dmesg, available at
> 
> http://www.marquesmota.pt/dmesg.txt
> 
> that thermal_add_hwmon_sysfs() in drivers/thermal/thermal_hwmon.c needs
> to be converted to the new API.
> 
> This patch is against 4.15.0-rc2
> I believe it is also needed in Bugzilla bug #195843
> https://bugzilla.kernel.org/show_bug.cgi?id=195843
> 
> Signed-off-by: Paul Marques Mota<paul@marquesmota.pt>

Nack, this is not needed. The thermal subsystem is the only subsystem
which doesn't pass a device pointer, and I don't want to have logs
clogged up with unnecessary tracebacks because of it.

If it wasn't for thermal, I would actually let hwmon registrations with
NULL device pointer fail completely. Unfortunately there is no easy way
to convert the thermal subsystem to use hwmon_device_register_with_info(),
since even though thermal_zone_device_register() registers a thermal zone
device, it does not have a notion of 'struct device *'.

Maybe someone can step in and convert the thermal code to use
hwmon_device_register_with_groups(). That doesn't really solve the problem,
but at least the symptom would be gone, and the thermal code would be
a little cleaner.

Guenter

Re: your mail

[Greg Kroah-Hartman]

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

Re: your mail

[Rajneesh Bhardwaj]

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

Re: your mail

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

On Mon, Jun 26, 2017 at 08:21:17AM +0300, Leon Romanovsky wrote:
> David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> Bcc:
> Subject: Re: Proposal for the 2nd RDMA microconference (LPC 2017)
> Reply-To:
> In-Reply-To: <786f10f7-6253-c95b-49e2-a89010a43781-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> On Sun, Jun 25, 2017 at 11:43:35AM +0300, Marcel Apfelbaum wrote:
> > Hi Leon,
> >
> > Here is our proposal for the coming conference.
>
> Thanks Marcel for sending proposal, I'm looking forward to see you and
> Yuval there.
>
> In the meantime, I'm adding David who is our LPC POC and would like to
> ask some questions.
>
> >
> > Abstract
> > --------
> > QEMU's limited RDMA support leaves it behind other modern hypervisors.
> > Marcel and/or Yuval will present the implementation of an emulated RDMA
> > device, analyze its performance and usability, and finally talk about future
> > plans for a possible virtio-rdma device.
>
> How are you implementing different fabrics? Does it completely SW
> implementation and/or it requires HW beneath like prvdma? Namespaces,
> migration?
>
> What are the expectations from the community?
>
> >
> > Audience
> > --------
> > The audience is developers interested in device emulation / RDMA.
> > They can expect an interesting discussion on what are the difficulties to
> > work with RDMA in Virtual Machines and they will be welcomed to share their
> > ideas.
> >
> > Benefits to the Ecosystem
> > -------------------------
> > Knowing how to tackle RDMA on virtualization may give developers an easier
> > start on adding RDMA support to QEMU, which in turn will leverage the modern
> > RDMA cards on virtualized environments.
> >
> >
> > Thanks,
> > Marcel & Yuval



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: your mail

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Thu, Jun 22, 2017 at 10:23:17PM -0700, Junio C Hamano wrote:
>
>> Otoh, "community" page does not encourage subscription as a way to
>> ensure you'll see follow-up discussion, which may be a good thing to
>> add.
>> 
>> A tangent I just found funny is this paragraph on the "community"
>> page:
>> 
>>     The archive can be found on public-inbox. Click here to
>>     subscribe.
>> 
>> Of course clicking does not take you to a subscription page for
>> public-inbox, even though the two sentences appear to be related.
>> 
>> Perhaps swap the order of the two, like so, with a bit richer
>> explanation taken from Ævar's version:
>> 
>> 	... disable HTML in your outgoing messages.
>> 
>> 	By subscribing (click here), you can make sure you're not
>> 	missing follow-up discussion and also learn from other
>> 	development in the community.  The list archive can be found
>> 	on public-inbox.
>
> Yeah, I think that's a good suggestion. Do you want to phrase it in the
> form of a patch? :)

OK. Letme try.

Re: your mail

[Jeff King]

On Thu, Jun 22, 2017 at 10:23:17PM -0700, Junio C Hamano wrote:

> Otoh, "community" page does not encourage subscription as a way to
> ensure you'll see follow-up discussion, which may be a good thing to
> add.
> 
> A tangent I just found funny is this paragraph on the "community"
> page:
> 
>     The archive can be found on public-inbox. Click here to
>     subscribe.
> 
> Of course clicking does not take you to a subscription page for
> public-inbox, even though the two sentences appear to be related.
> 
> Perhaps swap the order of the two, like so, with a bit richer
> explanation taken from Ævar's version:
> 
> 	... disable HTML in your outgoing messages.
> 
> 	By subscribing (click here), you can make sure you're not
> 	missing follow-up discussion and also learn from other
> 	development in the community.  The list archive can be found
> 	on public-inbox.

Yeah, I think that's a good suggestion. Do you want to phrase it in the
form of a patch? :)

-Peff

Re: your mail

[demerphq]

On 22 June 2017 at 23:58, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be

FWIW: "adviced" is misspelled, it should be "advised", and IMO, it
feels like poor style to begin a sentence with a contraction. Not
strictly wrong, but sufficiently informal that I think it is out of
place in docs like this. Better to just say "It is", or even just "You
are", especially as you use "you" later in the sentence.

I actually think simplifying that sentence considerably is preferable:

"To be sure you receive all follow-up mails you should subscribe to the list."

flows better and is more succinct than

"It's advised to subscribe to the list if you want to be sure you're
not missing follow-up discussion".

> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.

cheers,
yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: your mail

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

>> +You don't need to be subscribed to the list to send mail to it, and
>> +others on-list will generally CC you when replying (although some
>> +forget this). It's adviced to subscribe to the list if you want to be
>> +sure you're not missing follow-up discussion, or if your interest in
>> +the project is wider than a one-off bug report, question or patch.
>> +
>>  The maintainer frequently sends the "What's cooking" reports that
>>  list the current status of various development topics to the mailing
>>  list.  The discussion following them give a good reference for
>
> You perhaps already read it, but you may want to steal wording or
> suggestions from the mailing list section at:
>
>   https://git-scm.com/community
>
> which is covering the same ideas (and vice versa, patches to that page
> are welcome if the README says something better).

OK, so... Ævar's version does not mention:

 - text/plain, which is a very good addition.

 - note about CC in a way as useful as the "community" page does,
   which may want to steal from the latter.

 - the archive, but it may not be needed in the context of this
   document.  "Read the archive to make sure you are not repeating
   somebody else said before speaking" is something we silently wish
   everybody to follow, but it is something we do not want to say
   out loud, especially to new people.

 - Windows, but I am not sure if it is necessary or even healthy.
   One thing I would rather not to see is the Windows mailing list
   becomes the first line triage place for any and all issues that
   were experienced by a user who happened to be using Windows, and
   majority of the issues turn out to be unspecific to Windows.  I'd
   suspect that all of us rather would want to see the referral go
   the other way around.

Otoh, "community" page does not encourage subscription as a way to
ensure you'll see follow-up discussion, which may be a good thing to
add.

A tangent I just found funny is this paragraph on the "community"
page:

    The archive can be found on public-inbox. Click here to
    subscribe.

Of course clicking does not take you to a subscription page for
public-inbox, even though the two sentences appear to be related.

Perhaps swap the order of the two, like so, with a bit richer
explanation taken from Ævar's version:

	... disable HTML in your outgoing messages.

	By subscribing (click here), you can make sure you're not
	missing follow-up discussion and also learn from other
	development in the community.  The list archive can be found
	on public-inbox.

Re: your mail

[Jeff King]

On Thu, Jun 22, 2017 at 11:58:08PM +0200, Ævar Arnfjörð Bjarmason wrote:

> Which, in the context of what this follows (how to submit a bug,
> questions etc.) isn't a good use of time for the person reading the
> instructions.
> 
> Maybe something more like:
> 
> diff --git a/README.md b/README.md
> index f17af66a97..dc175757fa 100644
> --- a/README.md
> +++ b/README.md
> @@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
>  available at <https://public-inbox.org/git/>,
>  <http://marc.info/?l=git> and other archival sites.
> 
> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be
> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.
> +
>  The maintainer frequently sends the "What's cooking" reports that
>  list the current status of various development topics to the mailing
>  list.  The discussion following them give a good reference for

You perhaps already read it, but you may want to steal wording or
suggestions from the mailing list section at:

  https://git-scm.com/community

which is covering the same ideas (and vice versa, patches to that page
are welcome if the README says something better).

-Peff

Re: your mail

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Maybe something more like:

Much better.

> diff --git a/README.md b/README.md
> index f17af66a97..dc175757fa 100644
> --- a/README.md
> +++ b/README.md
> @@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
>  available at <https://public-inbox.org/git/>,
>  <http://marc.info/?l=git> and other archival sites.
>
> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be
> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.
> +
>  The maintainer frequently sends the "What's cooking" reports that
>  list the current status of various development topics to the mailing
>  list.  The discussion following them give a good reference for

Re: your mail

[Ævar Arnfjörð Bjarmason]

On Thu, Jun 22 2017, Junio C. Hamano jotted:

> Simon Ruderich <simon@ruderich.org> writes:
>
>> On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
>>> The description on https://github.com/git/git doesn't reflect that policy.
>>>
>>> a)
>>> It explains that discussions take place in the mentioned mailing list.
>>> b)
>>> It describes how to subscribe.
>>
>> However it doesn't say that you have to subscribe to send, only
>> how to subscribe.
>
> For that matter, we also say "everyone is welcome to post", which
> makes it clear that no subscription is required.
>
> But I view these merely being technically correct.  And making it
> absolutely obvious does not cost too much.
>
>>> With knowledge of other mailing lists (mostly managed by mailman),
>>> subscription is required for participation.
>>
>> That depends on the mailing list, some require subscription to
>> prevent spams but not all do.
>
> Yes.  But not many people realize that the world they know is the
> only world.  We are used to an open list and are shocked when we
> encouter a closed one; let's not forget that shock.
>
> How about doing it like this?
>
>  README.md | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/README.md b/README.md
> index f17af66a97..bbaf54bffb 100644
> --- a/README.md
> +++ b/README.md
> @@ -31,6 +31,10 @@ The user discussion and development of Git take place on the Git
>  mailing list -- everyone is welcome to post bug reports, feature
>  requests, comments and patches to git@vger.kernel.org (read
>  [Documentation/SubmittingPatches][] for instructions on patch submission).
> +
> +You can send messages without subscribing to the list, but it is
> +recommended to read what other people are saying on the list before
> +you speak.
>  To subscribe to the list, send an email with just "subscribe git" in
>  the body to majordomo@vger.kernel.org. The mailing list archives are
>  available at <https://public-inbox.org/git/>,

It's unclear what that means. I *think* it means "consider taking a look
around the list before you post", but then it's probably better advice
to tell people to skim the archives first to get an idea of the traffic.

E.g. if I page through the first 2 pages of public-inbox.org I get
messages going back to the 19th, but if I were to subscribe to the list
I'd need to wait 4 days to get the same mail.

Which, in the context of what this follows (how to submit a bug,
questions etc.) isn't a good use of time for the person reading the
instructions.

Maybe something more like:

diff --git a/README.md b/README.md
index f17af66a97..dc175757fa 100644
--- a/README.md
+++ b/README.md
@@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
 available at <https://public-inbox.org/git/>,
 <http://marc.info/?l=git> and other archival sites.

+You don't need to be subscribed to the list to send mail to it, and
+others on-list will generally CC you when replying (although some
+forget this). It's adviced to subscribe to the list if you want to be
+sure you're not missing follow-up discussion, or if your interest in
+the project is wider than a one-off bug report, question or patch.
+
 The maintainer frequently sends the "What's cooking" reports that
 list the current status of various development topics to the mailing
 list.  The discussion following them give a good reference for

Re: your mail

[Junio C Hamano]

Simon Ruderich <simon@ruderich.org> writes:

> On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
>> The description on https://github.com/git/git doesn't reflect that policy.
>>
>> a)
>> It explains that discussions take place in the mentioned mailing list.
>> b)
>> It describes how to subscribe.
>
> However it doesn't say that you have to subscribe to send, only
> how to subscribe.

For that matter, we also say "everyone is welcome to post", which
makes it clear that no subscription is required.

But I view these merely being technically correct.  And making it
absolutely obvious does not cost too much.

>> With knowledge of other mailing lists (mostly managed by mailman),
>> subscription is required for participation.
>
> That depends on the mailing list, some require subscription to
> prevent spams but not all do.

Yes.  But not many people realize that the world they know is the
only world.  We are used to an open list and are shocked when we
encouter a closed one; let's not forget that shock.

How about doing it like this?

 README.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/README.md b/README.md
index f17af66a97..bbaf54bffb 100644
--- a/README.md
+++ b/README.md
@@ -31,6 +31,10 @@ The user discussion and development of Git take place on the Git
 mailing list -- everyone is welcome to post bug reports, feature
 requests, comments and patches to git@vger.kernel.org (read
 [Documentation/SubmittingPatches][] for instructions on patch submission).
+
+You can send messages without subscribing to the list, but it is 
+recommended to read what other people are saying on the list before
+you speak.
 To subscribe to the list, send an email with just "subscribe git" in
 the body to majordomo@vger.kernel.org. The mailing list archives are
 available at <https://public-inbox.org/git/>,

Re: your mail

[Simon Ruderich]

On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
> The description on https://github.com/git/git doesn't reflect that policy.
>
> a)
> It explains that discussions take place in the mentioned mailing list.
> b)
> It describes how to subscribe.

However it doesn't say that you have to subscribe to send, only
how to subscribe.

> With knowledge of other mailing lists (mostly managed by mailman),
> subscription is required for participation.

That depends on the mailing list, some require subscription to
prevent spams but not all do.

Somebody might want to update the documentation, but personally
I see no reason to change anything. If you want to send a patch
to improve it, that would be great of course.

Regards
Simon

PS: Please don't top-post on this mailing list.
-- 
+ Privatsphäre ist notwendig
+ Ich verwende GnuPG http://gnupg.org
+ Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9

Re: your mail

[Simon Ruderich]

On Thu, Jun 22, 2017 at 01:35:33PM +0000, Patrick Lehmann wrote:
> But how can he write to the mailing list without a subscription?
> Is this a security bug or is he already subscribed?

Everybody can send to this mailing list. This is by design so
contributors/bug reporters can send mails without having to
subscribe.

Regards
Simon
-- 
+ Privatsphäre ist notwendig
+ Ich verwende GnuPG http://gnupg.org
+ Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9

Re: your mail

[Simon Ruderich]

On Thu, Jun 22, 2017 at 11:50:01AM +0200, Jessie Hernandez wrote:
> subscribe git

You need to write to majordomo@vger.kernel.org (with subscribe
git in the body) to subscribe.

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

Re: your mail

[Yury Norov]

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

your mail

[Yury Norov]

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

Re: your mail

[Michal Hocko]

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

Re: your mail

[Michal Hocko]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Joonsoo Kim]

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.

Re: your mail

[Joonsoo Kim]

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Michal Hocko]

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

Re: your mail

[Michal Hocko]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Joonsoo Kim]

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.

Re: your mail

[Joonsoo Kim]

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Michal Hocko]

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

Re: your mail

[Michal Hocko]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Joonsoo Kim]

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.

Re: your mail

[Joonsoo Kim]

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Michal Hocko]

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

Re: your mail

[Michal Hocko]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Joonsoo Kim]

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.

Re: your mail

[Joonsoo Kim]

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Michal Hocko]

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

Re: your mail

[Michal Hocko]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Vlastimil Babka]

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)
>  {
> 

Re: your mail

[Vlastimil Babka]

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)
>  {
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Michal Hocko]

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

Re: your mail

[Michal Hocko]

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

Re: your mail

[Michal Hocko]

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

Re: your mail

[Michal Hocko]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Joonsoo Kim]

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.

Re: your mail

[Joonsoo Kim]

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Michal Hocko]

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

Re: your mail

[Michal Hocko]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Joonsoo Kim]

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.

Re: your mail

[Joonsoo Kim]

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Peter Zijlstra]

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.

Re: your mail

[Steven Rostedt]

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

Re: your mail

[Peter Zijlstra]

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.

Re: your mail

[andrew banman]

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

Re: your mail

[Jeff Mahoney]

[-- Attachment #1.1: Type: text/plain, Size: 3943 bytes --]

On 9/1/16 12:44 PM, Kyle Gates wrote:
>> -----Original Message-----
>> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
>> owner@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
>> Sent: Thursday, September 01, 2016 6:18 AM
>> To: linux-btrfs@vger.kernel.org
>> Subject: Re: your mail
>>
>> On 2016-09-01 03:44, M G Berberich wrote:
>>> Am Mittwoch, den 31. August schrieb Fennec Fox:
>>>> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
>> UTC
>>>> 2016 x86_64 GNU/Linux
>>>> btrfs-progs v4.7
>>>>
>>>> Data, single: total=30.01GiB, used=18.95GiB System, single:
>>>> total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
>>>> used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B
>>>>
>>>> {02:50} Wed Aug 31
>>>> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> Sorry, try again.
>>>> [sudo] password for fennectech:
>>>> /: 99.8 GiB (107167244288 bytes) trimmed
>>>>
>>>> {03:08} Wed Aug 31
>>>> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> /: 99.9 GiB (107262181376 bytes) trimmed
>>>>
>>>>   I ran these commands minutes after echother ane each time it is
>>>> trimming the entire free space
>>>>
>>>> Anyone else seen this?   the filesystem is the root FS and is compressed
>>>
>>> You should be very happy that it is trimming at all. Typical situation
>>> on a used btrfs is
>>>
>>>   # fstrim -v /
>>>   /: 0 B (0 bytes) trimmed
>>>
>>> even if there is 33G unused space ob the fs:
>>>
>>>   # df -h /
>>>   Filesystem      Size  Used Avail Use% Mounted on
>>>   /dev/sda2        96G   61G   33G  66% /
>>>
>> I think you're using an old kernel, this has been working since at least 4.5, but
>> was broken in some older releases.
> 
> M G is running 4.7.2
> The problem is that all space has been allocated by block groups and fstrim will only work on unallocated space.

Historically it was the opposite problem.  My fixes made it so it would
work on unallocated space.  We probably need some debugging to see why
it's not discarding extents that are allocated as block groups but
unallocated within them.

-Jeff

> On my system all space has been allocated on my root filesystem so 0 B are trimmed:
> kyle@home:~$  uname -a
> Linux home 4.7.2-040702-generic #201608201334 SMP Sat Aug 20 17:37:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> kyle@home:~$  sudo btrfs fi show /
> Label: 'root'  uuid: 6af4ebde-81ef-428a-a45f-0e8480ad969a
>         Total devices 2 FS bytes used 13.44GiB
>         devid   14 size 20.00GiB used 20.00GiB path /dev/sde2
>         devid   15 size 20.00GiB used 20.00GiB path /dev/sdb2
> kyle@home:~$  btrfs fi df /
> Data, RAID1: total=18.97GiB, used=12.98GiB
> System, RAID1: total=32.00MiB, used=16.00KiB
> Metadata, RAID1: total=1.00GiB, used=473.83MiB
> GlobalReserve, single: total=160.00MiB, used=0.00B
> kyle@home:~$  sudo fstrim -v /
> [sudo] password for kyle:
> /: 0 B (0 bytes) trimmed
> 
> But I do have space trimmed on my home filesystem:
> kyle@home:~$  sudo btrfs fi show /home/
> Label: 'home'  uuid: b75fb450-4a28-434a-a483-e784940d463a
>         Total devices 2 FS bytes used 18.63GiB
>         devid   11 size 64.00GiB used 29.03GiB path /dev/sde3
>         devid   12 size 64.00GiB used 29.03GiB path /dev/sdb3
> kyle@home:~$  btrfs fi df /home/
> Data, RAID1: total=27.00GiB, used=18.46GiB
> System, RAID1: total=32.00MiB, used=16.00KiB
> Metadata, RAID1: total=2.00GiB, used=168.62MiB
> GlobalReserve, single: total=64.00MiB, used=0.00B
> kyle@home:~$  sudo fstrim -v /home
> /home: 70 GiB (75092721664 bytes) trimmed
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Jeff Mahoney
SUSE Labs


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 881 bytes --]

Re: your mail

[M G Berberich]

Am Donnerstag, den 01. September schrieb Austin S. Hemmelgarn:
> On 2016-09-01 03:44, M G Berberich wrote:
> > Am Mittwoch, den 31. August schrieb Fennec Fox:
> > > Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
> > > 2016 x86_64 GNU/Linux
> > > btrfs-progs v4.7
> > > 
> > > Data, single: total=30.01GiB, used=18.95GiB
> > > System, single: total=4.00MiB, used=16.00KiB
> > > Metadata, single: total=1.01GiB, used=422.17MiB
> > > GlobalReserve, single: total=144.00MiB, used=0.00B
> > > 
> > > {02:50} Wed Aug 31
> > > [fennectech@Titanium ~]$  sudo fstrim -v /
> > > [sudo] password for fennectech:
> > > Sorry, try again.
> > > [sudo] password for fennectech:
> > > /: 99.8 GiB (107167244288 bytes) trimmed
> > > 
> > > {03:08} Wed Aug 31
> > > [fennectech@Titanium ~]$  sudo fstrim -v /
> > > [sudo] password for fennectech:
> > > /: 99.9 GiB (107262181376 bytes) trimmed
> > > 
> > >   I ran these commands minutes after echother ane each time it is
> > > trimming the entire free space
> > > 
> > > Anyone else seen this?   the filesystem is the root FS and is compressed
> > 
> > You should be very happy that it is trimming at all. Typical situation
> > on a used btrfs is
> > 
> >   # fstrim -v /
> >   /: 0 B (0 bytes) trimmed
> > 
> > even if there is 33G unused space ob the fs:
> > 
> >   # df -h /
> >   Filesystem      Size  Used Avail Use% Mounted on
> >   /dev/sda2        96G   61G   33G  66% /
> > 
> I think you're using an old kernel, this has been working since at least
> 4.5, but was broken in some older releases.

No, I’m always running a fairly up-to-date vanilla kernel on this
system. At the moment it’s:

  Linux hermione 4.7.2 #4 SMP PREEMPT Wed Aug 24 17:12:03 CEST 2016 x86_64 GNU/Linux

I’m running kernels ≥ 4.5.0 since about April and I first reported this
problem at 7 Jul 2016 (Subject: fstrim problem/bug) probably with a
4.6.3 kernel.

	MfG
	bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“          | mail@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | 

Re: your mail

[Austin S. Hemmelgarn]

On 2016-09-01 12:44, Kyle Gates wrote:
>> -----Original Message-----
>> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
>> owner@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
>> Sent: Thursday, September 01, 2016 6:18 AM
>> To: linux-btrfs@vger.kernel.org
>> Subject: Re: your mail
>>
>> On 2016-09-01 03:44, M G Berberich wrote:
>>> Am Mittwoch, den 31. August schrieb Fennec Fox:
>>>> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
>> UTC
>>>> 2016 x86_64 GNU/Linux
>>>> btrfs-progs v4.7
>>>>
>>>> Data, single: total=30.01GiB, used=18.95GiB System, single:
>>>> total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
>>>> used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B
>>>>
>>>> {02:50} Wed Aug 31
>>>> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> Sorry, try again.
>>>> [sudo] password for fennectech:
>>>> /: 99.8 GiB (107167244288 bytes) trimmed
>>>>
>>>> {03:08} Wed Aug 31
>>>> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
>>>> fennectech:
>>>> /: 99.9 GiB (107262181376 bytes) trimmed
>>>>
>>>>   I ran these commands minutes after echother ane each time it is
>>>> trimming the entire free space
>>>>
>>>> Anyone else seen this?   the filesystem is the root FS and is compressed
>>>
>>> You should be very happy that it is trimming at all. Typical situation
>>> on a used btrfs is
>>>
>>>   # fstrim -v /
>>>   /: 0 B (0 bytes) trimmed
>>>
>>> even if there is 33G unused space ob the fs:
>>>
>>>   # df -h /
>>>   Filesystem      Size  Used Avail Use% Mounted on
>>>   /dev/sda2        96G   61G   33G  66% /
>>>
>> I think you're using an old kernel, this has been working since at least 4.5, but
>> was broken in some older releases.
>
> M G is running 4.7.2
> The problem is that all space has been allocated by block groups and fstrim will only work on unallocated space.
Yep, that would do so also, and this behavior really could be much 
better documented.

Re: your mail

[Kyle Gates]

> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
> owner@vger.kernel.org] On Behalf Of Austin S. Hemmelgarn
> Sent: Thursday, September 01, 2016 6:18 AM
> To: linux-btrfs@vger.kernel.org
> Subject: Re: your mail
> 
> On 2016-09-01 03:44, M G Berberich wrote:
> > Am Mittwoch, den 31. August schrieb Fennec Fox:
> >> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37
> UTC
> >> 2016 x86_64 GNU/Linux
> >> btrfs-progs v4.7
> >>
> >> Data, single: total=30.01GiB, used=18.95GiB System, single:
> >> total=4.00MiB, used=16.00KiB Metadata, single: total=1.01GiB,
> >> used=422.17MiB GlobalReserve, single: total=144.00MiB, used=0.00B
> >>
> >> {02:50} Wed Aug 31
> >> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
> >> fennectech:
> >> Sorry, try again.
> >> [sudo] password for fennectech:
> >> /: 99.8 GiB (107167244288 bytes) trimmed
> >>
> >> {03:08} Wed Aug 31
> >> [fennectech@Titanium ~]$  sudo fstrim -v / [sudo] password for
> >> fennectech:
> >> /: 99.9 GiB (107262181376 bytes) trimmed
> >>
> >>   I ran these commands minutes after echother ane each time it is
> >> trimming the entire free space
> >>
> >> Anyone else seen this?   the filesystem is the root FS and is compressed
> >
> > You should be very happy that it is trimming at all. Typical situation
> > on a used btrfs is
> >
> >   # fstrim -v /
> >   /: 0 B (0 bytes) trimmed
> >
> > even if there is 33G unused space ob the fs:
> >
> >   # df -h /
> >   Filesystem      Size  Used Avail Use% Mounted on
> >   /dev/sda2        96G   61G   33G  66% /
> >
> I think you're using an old kernel, this has been working since at least 4.5, but
> was broken in some older releases.

M G is running 4.7.2
The problem is that all space has been allocated by block groups and fstrim will only work on unallocated space.

On my system all space has been allocated on my root filesystem so 0 B are trimmed:
kyle@home:~$  uname -a
Linux home 4.7.2-040702-generic #201608201334 SMP Sat Aug 20 17:37:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
kyle@home:~$  sudo btrfs fi show /
Label: 'root'  uuid: 6af4ebde-81ef-428a-a45f-0e8480ad969a
        Total devices 2 FS bytes used 13.44GiB
        devid   14 size 20.00GiB used 20.00GiB path /dev/sde2
        devid   15 size 20.00GiB used 20.00GiB path /dev/sdb2
kyle@home:~$  btrfs fi df /
Data, RAID1: total=18.97GiB, used=12.98GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=473.83MiB
GlobalReserve, single: total=160.00MiB, used=0.00B
kyle@home:~$  sudo fstrim -v /
[sudo] password for kyle:
/: 0 B (0 bytes) trimmed

But I do have space trimmed on my home filesystem:
kyle@home:~$  sudo btrfs fi show /home/
Label: 'home'  uuid: b75fb450-4a28-434a-a483-e784940d463a
        Total devices 2 FS bytes used 18.63GiB
        devid   11 size 64.00GiB used 29.03GiB path /dev/sde3
        devid   12 size 64.00GiB used 29.03GiB path /dev/sdb3
kyle@home:~$  btrfs fi df /home/
Data, RAID1: total=27.00GiB, used=18.46GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=2.00GiB, used=168.62MiB
GlobalReserve, single: total=64.00MiB, used=0.00B
kyle@home:~$  sudo fstrim -v /home
/home: 70 GiB (75092721664 bytes) trimmed

Re: your mail

[Austin S. Hemmelgarn]

On 2016-09-01 03:44, M G Berberich wrote:
> Am Mittwoch, den 31. August schrieb Fennec Fox:
>> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
>> 2016 x86_64 GNU/Linux
>> btrfs-progs v4.7
>>
>> Data, single: total=30.01GiB, used=18.95GiB
>> System, single: total=4.00MiB, used=16.00KiB
>> Metadata, single: total=1.01GiB, used=422.17MiB
>> GlobalReserve, single: total=144.00MiB, used=0.00B
>>
>> {02:50} Wed Aug 31
>> [fennectech@Titanium ~]$  sudo fstrim -v /
>> [sudo] password for fennectech:
>> Sorry, try again.
>> [sudo] password for fennectech:
>> /: 99.8 GiB (107167244288 bytes) trimmed
>>
>> {03:08} Wed Aug 31
>> [fennectech@Titanium ~]$  sudo fstrim -v /
>> [sudo] password for fennectech:
>> /: 99.9 GiB (107262181376 bytes) trimmed
>>
>>   I ran these commands minutes after echother ane each time it is
>> trimming the entire free space
>>
>> Anyone else seen this?   the filesystem is the root FS and is compressed
>
> You should be very happy that it is trimming at all. Typical situation
> on a used btrfs is
>
>   # fstrim -v /
>   /: 0 B (0 bytes) trimmed
>
> even if there is 33G unused space ob the fs:
>
>   # df -h /
>   Filesystem      Size  Used Avail Use% Mounted on
>   /dev/sda2        96G   61G   33G  66% /
>
I think you're using an old kernel, this has been working since at least 
4.5, but was broken in some older releases.

Re: your mail

[M G Berberich]

Am Mittwoch, den 31. August schrieb Fennec Fox:
> Linux Titanium 4.7.2-1-MANJARO #1 SMP PREEMPT Sun Aug 21 15:04:37 UTC
> 2016 x86_64 GNU/Linux
> btrfs-progs v4.7
> 
> Data, single: total=30.01GiB, used=18.95GiB
> System, single: total=4.00MiB, used=16.00KiB
> Metadata, single: total=1.01GiB, used=422.17MiB
> GlobalReserve, single: total=144.00MiB, used=0.00B
> 
> {02:50} Wed Aug 31
> [fennectech@Titanium ~]$  sudo fstrim -v /
> [sudo] password for fennectech:
> Sorry, try again.
> [sudo] password for fennectech:
> /: 99.8 GiB (107167244288 bytes) trimmed
> 
> {03:08} Wed Aug 31
> [fennectech@Titanium ~]$  sudo fstrim -v /
> [sudo] password for fennectech:
> /: 99.9 GiB (107262181376 bytes) trimmed
> 
>   I ran these commands minutes after echother ane each time it is
> trimming the entire free space
> 
> Anyone else seen this?   the filesystem is the root FS and is compressed

You should be very happy that it is trimming at all. Typical situation
on a used btrfs is

  # fstrim -v /
  /: 0 B (0 bytes) trimmed

even if there is 33G unused space ob the fs:

  # df -h /
  Filesystem      Size  Used Avail Use% Mounted on
  /dev/sda2        96G   61G   33G  66% /


	MfG
	bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“          | mail@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | 

Re: your mail

[Jeff King]

On Mon, Apr 11, 2016 at 07:04:23PM +0000, miwilliams@google.com wrote:

> From 7201fe08ede76e502211a781250c9a0b702a78b2 Mon Sep 17 00:00:00 2001
> From: Mike Williams <miwilliams@google.com>
> Date: Mon, 11 Apr 2016 14:18:39 -0400
> Subject: [PATCH 1/1] wt-status: Remove '!!' from
> wt_status_collect_changed_cb

These bits (minus the initial "From ..." line) should go into your
actual email headers. As it is, your email has no subject line.

> The wt_status_collect_changed_cb function uses an extraneous double
> negation (!!) when determining whether or not a submodule has new
> commits.
> [...]
> -			d->new_submodule_commits = !!hashcmp(p->one->sha1, p->two->sha1);
> +			d->new_submodule_commits = hashcmp(p->one->sha1, p->two->sha1);

It's not extraneous. hashcmp() returns 0 for equality, but an arbitrary
positive or negative value depending on how the two arguments differ.
The assigned "new_submodule_commits" is a bitfield of size 1. So the
"!!" is normalizing the value into "0" or "1".

-Peff

Re: your mail

[Dan Carpenter]

Returning EINVAL here is the wrong thing.  Just leave the code as is.

regards,
dan carpenter

Re: your mail

[Sudip Mukherjee]

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

Re: your mail

[Dave Chinner]

On Sun, Jun 14, 2015 at 08:39:21AM +1000, Dave Chinner wrote:
> On Sat, Jun 13, 2015 at 01:02:51AM +0000, Tom Christensen wrote:
> > We've run into a bit of an issue with xfs running Ceph.  The following bug details what we are seeing:
> > https://bugs.launchpad.net/ubuntu/+source/xfs/+bug/1464308
> > 
> > Basically the Ceph OSD process gets hung in dstate due to the traceback in the bug.
> > 
> > Here is additional info gathered:
> > 
> > xfs bmap output for a random directory
> > https://gist.github.com/dmmatson/e864252c7ff346df954a
> > 
> > attr -l of the file dchinner indicated from the xfs bmap output
> > (attr -l)
> > (6:11:41 PM) dmatson: Attribute "cephos.spill_out" has a 2 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:11:45 PM) dmatson: Attribute "ceph.snapset@3" has a 263 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:11:49 PM) dmatson: Attribute "ceph.snapset@2" has a 1131 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:11:53 PM) dmatson: Attribute "ceph.snapset@1" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:11:56 PM) dmatson: Attribute "ceph._" has a 259 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > (6:12:00 PM) dmatson: Attribute "ceph.snapset" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> > 
> > xfs_bmap -vp of same file
> > 
> > rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
> > (6:13:21 PM) dmatson: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
> > (6:13:25 PM) dmatson: 0: [0..8191]: 2944471376..2944479567 16 (24445776..24453967) 8192 00000
> 
> And the attribute fork was:
> 
> rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
> EXT: FILE-OFFSET	BLOCK-RANGE		AG AG-OFFSET          TOTAL FLAGS
>   0: [0..7]:		1461176488..1461176495  8  (1163688..1163695)     8 00000
>   1: [8..31]:		1461176504..1461176527  8  (1163704..1163727)    24 00000
> 
> I just created a filesystem and attribute list identical to the
> above, and came up with a attribute fork that looks like:
> 
> /mnt/scratch/udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
>  EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL FLAGS
>    0: [0..7]:          120..127          0 (120..127)           8 00000
>    1: [8..15]:         112..119          0 (112..119)           8 00000
>    2: [16..23]:        104..111          0 (104..111)           8 00000
> 
> IOWs, there's an extra block in the attribute fork that is causing
> problems than there needs to be.  That tends to imply attribute
> overwrites might be contributing here (the 3-phase overwrite
> algorithm increases the space usage) so I'm going to need to try a
> few different things to see if I can get an attribute fork into the
> same shape....

I've had a test running overnight that generates attribute forks of
this shape, but I haven't seen any problems. sequential grow of
attributes, semi random growth, semi random truncation, etc don't
seem to trip over this problem on a 4.1-rc6 kernel. Hence I'm going
to need a metadump image of a filesystem with a broken file in it.
An obfuscated dump is fine; I only need to look at the structure of
the bad attribute fork. If you want to send the link privately to me
that is fine, too.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: your mail

[Dave Chinner]

On Sat, Jun 13, 2015 at 01:02:51AM +0000, Tom Christensen wrote:
> We've run into a bit of an issue with xfs running Ceph.  The following bug details what we are seeing:
> https://bugs.launchpad.net/ubuntu/+source/xfs/+bug/1464308
> 
> Basically the Ceph OSD process gets hung in dstate due to the traceback in the bug.
> 
> Here is additional info gathered:
> 
> xfs bmap output for a random directory
> https://gist.github.com/dmmatson/e864252c7ff346df954a
> 
> attr -l of the file dchinner indicated from the xfs bmap output
> (attr -l)
> (6:11:41 PM) dmatson: Attribute "cephos.spill_out" has a 2 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:11:45 PM) dmatson: Attribute "ceph.snapset@3" has a 263 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:11:49 PM) dmatson: Attribute "ceph.snapset@2" has a 1131 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:11:53 PM) dmatson: Attribute "ceph.snapset@1" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:11:56 PM) dmatson: Attribute "ceph._" has a 259 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> (6:12:00 PM) dmatson: Attribute "ceph.snapset" has a 2048 byte value for rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5
> 
> xfs_bmap -vp of same file
> 
> rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
> (6:13:21 PM) dmatson: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
> (6:13:25 PM) dmatson: 0: [0..8191]: 2944471376..2944479567 16 (24445776..24453967) 8192 00000

And the attribute fork was:

rbd\udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
EXT: FILE-OFFSET	BLOCK-RANGE		AG AG-OFFSET          TOTAL FLAGS
  0: [0..7]:		1461176488..1461176495  8  (1163688..1163695)     8 00000
  1: [8..31]:		1461176504..1461176527  8  (1163704..1163727)    24 00000

I just created a filesystem and attribute list identical to the
above, and came up with a attribute fork that looks like:

/mnt/scratch/udata.66039648e29a80.0000000000000d35__head_23EA10B8__5:
 EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL FLAGS
   0: [0..7]:          120..127          0 (120..127)           8 00000
   1: [8..15]:         112..119          0 (112..119)           8 00000
   2: [16..23]:        104..111          0 (104..111)           8 00000

IOWs, there's an extra block in the attribute fork that is causing
problems than there needs to be.  That tends to imply attribute
overwrites might be contributing here (the 3-phase overwrite
algorithm increases the space usage) so I'm going to need to try a
few different things to see if I can get an attribute fork into the
same shape....

> LVM configuration: None
> 
> HGST 3TB
> 
> meta-data=/dev/mapper/63e3300b-6b7b-41a0-bdf2-b64ec3c20c51 isize=2048   agcount=32, agsize=22812700 blks

agcount=32 will actually be slowing your disks down. The default of
4AGs is usually best for a single spindle as it has sufficient
allocation cncurrency but results in much fewer seeks than a higher
AG count....

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

your mail

[Dave Martin]

On Tue, Apr 21, 2015 at 04:06:02PM +0200, Ard Biesheuvel wrote:
> On 21 April 2015 at 15:55, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Apr 21, 2015 at 02:18:03PM +0100, Dave P Martin wrote:
> >> On Tue, Apr 21, 2015 at 01:50:50PM +0100, Russell King - ARM Linux wrote:
> >> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> >> > > We should probably create a badr macro to complement the adr pseudo-op
> >> > > which incorporates the BSYM thing so make this clearer - and a comment
> >> > > before it.  This is really the case where BSYM should be used.
> >> >
> >> > Something like this.  Note that I've also removed the BSYM() usage in
> >> > the KVM code.
> >>
> >> Nice.  Wrapping this around adr will make the assembler check that it's
> >> not a cross-section reference too.
> >
> > While looking at this, I've become very upset with our toolchain's
> > abilities.  This is with stock binutils 2.22-2.25, and Ard's suggestion
> > for using blx:
> >
> > 00000000 <secondary_startup_arm>:
> >    0:   fafffffe        blx     4 <secondary_startup>
> >
> > 00000004 <secondary_startup>:
> >    4:   f7ff fffe       bl      0 <__hyp_stub_install_secondary>
> >    8:   f3ef 8900       mrs     r9, CPSR
> >    c:   f089 091a       eor.w   r9, r9, #26
> >   10:   f019 0f1f       tst.w   r9, #31
> >
> > That's fine, but now if we look at the .head.text section (I also added
> > an ENTRY(start) to try and solve this):
> >
> > 00000000 <stext>:
> >    0:   ffff faff                       ; <UNDEFINED> instruction: 0xfffffaff
> >
> > 00000004 <start>:
> >    4:   fffef7ff        .word   0xfffef7ff
> >    8:   f3ef 8900       mrs     r9, CPSR
> >    c:   091af089        .word   0x091af089
> >   10:   f019 0f1f       tst.w   r9, #31
> >   14:   091ff029        .word   0x091ff029
> >   18:   09d3f049        .word   0x09d3f049
> >   1c:   f049 0920       orr.w   r9, r9, #32
> >   20:   f449d109        .word   0xf449d109
> >   24:   f20f7980        .word   0xf20f7980
> >   28:   0e13            lsrs    r3, r2, #24
> >   2a:   f399            .short  0xf399
> >   2c:   8f00            ldrh    r0, [r0, #56]   ; 0x38
> >   2e:   f38e            .short  0xf38e
> >   30:   f3de8e30        .word   0xf3de8e30
> >   34:   8f00            .short  0x8f00
> >   36:   f389 8100       msr     CPSR_c, r9
> >
> > readelf for this shows for section 5:
> >
> > Section Headers:
> >   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
> >   [ 5] .head.text        PROGBITS        00000000 000290 000254 00  AX  0   0  4
> > ...
> >    Num:    Value  Size Type    Bind   Vis      Ndx Name
> >      4: 00000000     0 SECTION LOCAL  DEFAULT    5
> >      5: 00000000     0 NOTYPE  LOCAL  DEFAULT    5 $a
> >      6: 00000004     0 NOTYPE  LOCAL  DEFAULT    5 $t
> >      7: 0000002e     0 NOTYPE  LOCAL  DEFAULT    5 $d
> >      8: 00000036     0 NOTYPE  LOCAL  DEFAULT    5 $t
> > ...
> >     65: 00000000     4 FUNC    GLOBAL DEFAULT    5 stext
> >     66: 00000005   122 FUNC    GLOBAL DEFAULT    5 start
> >
> > One has to wonder about the toolchain when the stupid $[adt] hack seems
> > to be going soooo wrong.
> >
> > I think I'm going to stop working on this until we have a toolchain
> > which behaves sensibly... when you can't get the damned thing to
> > disassemble for confirmation purposes, its best to leave the damned
> > code alone.
> >
> 
> It indeed seems to be objdump that is failing, but the code itself
> looks fine to me.  For the record, binutils v2.23.52 works fine

I've come across weird disassembly issues like this in the past.
The objdump code is something of a fragmented mess (shock, horror),
but I think there were fixes in the pipeline for some issues of this
sort.

If it is possible to manually check most or all of the cases of
badr, that might be sufficient -- this only gets used in a few,
specific places.

Objdump doesn't inspire much confidence though :(

Cheers
---Dave

your mail

[Dave Martin]

On Tue, Apr 21, 2015 at 03:28:14PM +0200, Ard Biesheuvel wrote:
> On 21 April 2015 at 15:21, Dave P Martin <Dave.Martin@arm.com> wrote:
> > On Tue, Apr 21, 2015 at 02:10:42PM +0100, Ard Biesheuvel wrote:
> >> On 21 April 2015 at 14:50, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> >> >> We should probably create a badr macro to complement the adr pseudo-op
> >> >> which incorporates the BSYM thing so make this clearer - and a comment
> >> >> before it.  This is really the case where BSYM should be used.
> >> >
> >> > Something like this.  Note that I've also removed the BSYM() usage in
> >> > the KVM code.
> >> >
> >>
> >> Yes, that is much better. It is a pity that we still can't use '| 1'
> >> but the fact that you are forced to use 'adr' now probably mostly
> >> eliminates the risk regarding that.
> >>
> >> I did notice that are are 4 or 5 instances (commented inline) of an
> >> ARM to thumb mode switch which can just as easily be implemented as
> >> 'blx 1f' instead of using this badr macro (whose use we want to
> >> discourage, I assume, since the address arithmetic is still slightly
> >> dodgy). Do you think we should do something about that as well?
> >
> > Err, probably.  That just looks like an oversight -- I think I'm
> > responsible for at least some of those.
> >
> > There's no good reason not to replace adr+BSYM+bx.
> >
> > For switches from ARM, this could be replaced with bx <label> which
> > should work just fine.  There shouldn't be any instances of this from
> > Thumb, because switching instruction set is the whole point here.
> >
> > (Thumb doesn't have bx <label>, but blx <label> is available at the cost
> > of clobbering lr).
> >
> 
> It appears neither have 'bx <label>', but 'add pc, pc, #1; nop' does

Duh, I'm getting myself confused.  Yes, both have blx <label> but not
bx <label>.

Note that blx may result in suboptimal branch prediction because it
looks like a function call.  But these aren't hot paths, so I doubt
it matters.

> the job nicely as well.

Bit icky though...

Cheers
---Dave

your mail

[Ard Biesheuvel]

On 21 April 2015 at 15:55, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Apr 21, 2015 at 02:18:03PM +0100, Dave P Martin wrote:
>> On Tue, Apr 21, 2015 at 01:50:50PM +0100, Russell King - ARM Linux wrote:
>> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
>> > > We should probably create a badr macro to complement the adr pseudo-op
>> > > which incorporates the BSYM thing so make this clearer - and a comment
>> > > before it.  This is really the case where BSYM should be used.
>> >
>> > Something like this.  Note that I've also removed the BSYM() usage in
>> > the KVM code.
>>
>> Nice.  Wrapping this around adr will make the assembler check that it's
>> not a cross-section reference too.
>
> While looking at this, I've become very upset with our toolchain's
> abilities.  This is with stock binutils 2.22-2.25, and Ard's suggestion
> for using blx:
>
> 00000000 <secondary_startup_arm>:
>    0:   fafffffe        blx     4 <secondary_startup>
>
> 00000004 <secondary_startup>:
>    4:   f7ff fffe       bl      0 <__hyp_stub_install_secondary>
>    8:   f3ef 8900       mrs     r9, CPSR
>    c:   f089 091a       eor.w   r9, r9, #26
>   10:   f019 0f1f       tst.w   r9, #31
>
> That's fine, but now if we look at the .head.text section (I also added
> an ENTRY(start) to try and solve this):
>
> 00000000 <stext>:
>    0:   ffff faff                       ; <UNDEFINED> instruction: 0xfffffaff
>
> 00000004 <start>:
>    4:   fffef7ff        .word   0xfffef7ff
>    8:   f3ef 8900       mrs     r9, CPSR
>    c:   091af089        .word   0x091af089
>   10:   f019 0f1f       tst.w   r9, #31
>   14:   091ff029        .word   0x091ff029
>   18:   09d3f049        .word   0x09d3f049
>   1c:   f049 0920       orr.w   r9, r9, #32
>   20:   f449d109        .word   0xf449d109
>   24:   f20f7980        .word   0xf20f7980
>   28:   0e13            lsrs    r3, r2, #24
>   2a:   f399            .short  0xf399
>   2c:   8f00            ldrh    r0, [r0, #56]   ; 0x38
>   2e:   f38e            .short  0xf38e
>   30:   f3de8e30        .word   0xf3de8e30
>   34:   8f00            .short  0x8f00
>   36:   f389 8100       msr     CPSR_c, r9
>
> readelf for this shows for section 5:
>
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>   [ 5] .head.text        PROGBITS        00000000 000290 000254 00  AX  0   0  4
> ...
>    Num:    Value  Size Type    Bind   Vis      Ndx Name
>      4: 00000000     0 SECTION LOCAL  DEFAULT    5
>      5: 00000000     0 NOTYPE  LOCAL  DEFAULT    5 $a
>      6: 00000004     0 NOTYPE  LOCAL  DEFAULT    5 $t
>      7: 0000002e     0 NOTYPE  LOCAL  DEFAULT    5 $d
>      8: 00000036     0 NOTYPE  LOCAL  DEFAULT    5 $t
> ...
>     65: 00000000     4 FUNC    GLOBAL DEFAULT    5 stext
>     66: 00000005   122 FUNC    GLOBAL DEFAULT    5 start
>
> One has to wonder about the toolchain when the stupid $[adt] hack seems
> to be going soooo wrong.
>
> I think I'm going to stop working on this until we have a toolchain
> which behaves sensibly... when you can't get the damned thing to
> disassemble for confirmation purposes, its best to leave the damned
> code alone.
>

It indeed seems to be objdump that is failing, but the code itself
looks fine to me.  For the record, binutils v2.23.52 works fine

your mail

[Russell King - ARM Linux]

On Tue, Apr 21, 2015 at 02:21:46PM +0100, Dave P Martin wrote:
> On Tue, Apr 21, 2015 at 02:10:42PM +0100, Ard Biesheuvel wrote:
> > Yes, that is much better. It is a pity that we still can't use '| 1'
> > but the fact that you are forced to use 'adr' now probably mostly
> > eliminates the risk regarding that.
> > 
> > I did notice that are are 4 or 5 instances (commented inline) of an
> > ARM to thumb mode switch which can just as easily be implemented as
> > 'blx 1f' instead of using this badr macro (whose use we want to
> > discourage, I assume, since the address arithmetic is still slightly
> > dodgy). Do you think we should do something about that as well?
> 
> Err, probably.  That just looks like an oversight -- I think I'm
> responsible for at least some of those.
> 
> There's no good reason not to replace adr+BSYM+bx.
> 
> For switches from ARM, this could be replaced with bx <label> which
> should work just fine.  There shouldn't be any instances of this from
> Thumb, because switching instruction set is the whole point here.

Where do you get this bx <label> from?  It doesn't seem to be in
DDI0406C.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

your mail

[Russell King - ARM Linux]

On Tue, Apr 21, 2015 at 02:18:03PM +0100, Dave P Martin wrote:
> On Tue, Apr 21, 2015 at 01:50:50PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> > > We should probably create a badr macro to complement the adr pseudo-op
> > > which incorporates the BSYM thing so make this clearer - and a comment
> > > before it.  This is really the case where BSYM should be used.
> > 
> > Something like this.  Note that I've also removed the BSYM() usage in
> > the KVM code.
> 
> Nice.  Wrapping this around adr will make the assembler check that it's
> not a cross-section reference too.

While looking at this, I've become very upset with our toolchain's
abilities.  This is with stock binutils 2.22-2.25, and Ard's suggestion
for using blx:

00000000 <secondary_startup_arm>:
   0:   fafffffe        blx     4 <secondary_startup>

00000004 <secondary_startup>:
   4:   f7ff fffe       bl      0 <__hyp_stub_install_secondary>
   8:   f3ef 8900       mrs     r9, CPSR
   c:   f089 091a       eor.w   r9, r9, #26
  10:   f019 0f1f       tst.w   r9, #31

That's fine, but now if we look at the .head.text section (I also added
an ENTRY(start) to try and solve this):

00000000 <stext>:
   0:   ffff faff                       ; <UNDEFINED> instruction: 0xfffffaff

00000004 <start>:
   4:   fffef7ff        .word   0xfffef7ff
   8:   f3ef 8900       mrs     r9, CPSR
   c:   091af089        .word   0x091af089
  10:   f019 0f1f       tst.w   r9, #31
  14:   091ff029        .word   0x091ff029
  18:   09d3f049        .word   0x09d3f049
  1c:   f049 0920       orr.w   r9, r9, #32
  20:   f449d109        .word   0xf449d109
  24:   f20f7980        .word   0xf20f7980
  28:   0e13            lsrs    r3, r2, #24
  2a:   f399            .short  0xf399
  2c:   8f00            ldrh    r0, [r0, #56]   ; 0x38
  2e:   f38e            .short  0xf38e
  30:   f3de8e30        .word   0xf3de8e30
  34:   8f00            .short  0x8f00
  36:   f389 8100       msr     CPSR_c, r9

readelf for this shows for section 5:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 5] .head.text        PROGBITS        00000000 000290 000254 00  AX  0   0  4
...
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     4: 00000000     0 SECTION LOCAL  DEFAULT    5
     5: 00000000     0 NOTYPE  LOCAL  DEFAULT    5 $a
     6: 00000004     0 NOTYPE  LOCAL  DEFAULT    5 $t
     7: 0000002e     0 NOTYPE  LOCAL  DEFAULT    5 $d
     8: 00000036     0 NOTYPE  LOCAL  DEFAULT    5 $t
...
    65: 00000000     4 FUNC    GLOBAL DEFAULT    5 stext
    66: 00000005   122 FUNC    GLOBAL DEFAULT    5 start

One has to wonder about the toolchain when the stupid $[adt] hack seems
to be going soooo wrong.

I think I'm going to stop working on this until we have a toolchain
which behaves sensibly... when you can't get the damned thing to
disassemble for confirmation purposes, its best to leave the damned
code alone.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

your mail

[Ard Biesheuvel]

On 21 April 2015 at 15:21, Dave P Martin <Dave.Martin@arm.com> wrote:
> On Tue, Apr 21, 2015 at 02:10:42PM +0100, Ard Biesheuvel wrote:
>> On 21 April 2015 at 14:50, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
>> >> We should probably create a badr macro to complement the adr pseudo-op
>> >> which incorporates the BSYM thing so make this clearer - and a comment
>> >> before it.  This is really the case where BSYM should be used.
>> >
>> > Something like this.  Note that I've also removed the BSYM() usage in
>> > the KVM code.
>> >
>>
>> Yes, that is much better. It is a pity that we still can't use '| 1'
>> but the fact that you are forced to use 'adr' now probably mostly
>> eliminates the risk regarding that.
>>
>> I did notice that are are 4 or 5 instances (commented inline) of an
>> ARM to thumb mode switch which can just as easily be implemented as
>> 'blx 1f' instead of using this badr macro (whose use we want to
>> discourage, I assume, since the address arithmetic is still slightly
>> dodgy). Do you think we should do something about that as well?
>
> Err, probably.  That just looks like an oversight -- I think I'm
> responsible for at least some of those.
>
> There's no good reason not to replace adr+BSYM+bx.
>
> For switches from ARM, this could be replaced with bx <label> which
> should work just fine.  There shouldn't be any instances of this from
> Thumb, because switching instruction set is the whole point here.
>
> (Thumb doesn't have bx <label>, but blx <label> is available at the cost
> of clobbering lr).
>

It appears neither have 'bx <label>', but 'add pc, pc, #1; nop' does
the job nicely as well.
And as you say, there are no instances of Thumb->ARM mode switches.

your mail

[Dave P Martin]

On Tue, Apr 21, 2015 at 02:10:42PM +0100, Ard Biesheuvel wrote:
> On 21 April 2015 at 14:50, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> >> We should probably create a badr macro to complement the adr pseudo-op
> >> which incorporates the BSYM thing so make this clearer - and a comment
> >> before it.  This is really the case where BSYM should be used.
> >
> > Something like this.  Note that I've also removed the BSYM() usage in
> > the KVM code.
> >
> 
> Yes, that is much better. It is a pity that we still can't use '| 1'
> but the fact that you are forced to use 'adr' now probably mostly
> eliminates the risk regarding that.
> 
> I did notice that are are 4 or 5 instances (commented inline) of an
> ARM to thumb mode switch which can just as easily be implemented as
> 'blx 1f' instead of using this badr macro (whose use we want to
> discourage, I assume, since the address arithmetic is still slightly
> dodgy). Do you think we should do something about that as well?

Err, probably.  That just looks like an oversight -- I think I'm
responsible for at least some of those.

There's no good reason not to replace adr+BSYM+bx.

For switches from ARM, this could be replaced with bx <label> which
should work just fine.  There shouldn't be any instances of this from
Thumb, because switching instruction set is the whole point here.

(Thumb doesn't have bx <label>, but blx <label> is available at the cost
of clobbering lr).

Cheers
---Dave

[...]

your mail

[Dave P Martin]

On Tue, Apr 21, 2015 at 01:50:50PM +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> > We should probably create a badr macro to complement the adr pseudo-op
> > which incorporates the BSYM thing so make this clearer - and a comment
> > before it.  This is really the case where BSYM should be used.
> 
> Something like this.  Note that I've also removed the BSYM() usage in
> the KVM code.

Nice.  Wrapping this around adr will make the assembler check that it's
not a cross-section reference too.

>  arch/arm/boot/compressed/head.S          |  4 ++--
>  arch/arm/common/mcpm_head.S              |  2 +-
>  arch/arm/include/asm/assembler.h         | 17 ++++++++++++++++-
>  arch/arm/include/asm/entry-macro-multi.S |  4 ++--
>  arch/arm/include/asm/unified.h           |  2 --
>  arch/arm/kernel/entry-armv.S             | 12 ++++++------
>  arch/arm/kernel/entry-common.S           |  6 +++---
>  arch/arm/kernel/entry-ftrace.S           |  2 +-
>  arch/arm/kernel/head-nommu.S             |  6 +++---
>  arch/arm/kernel/head.S                   |  8 ++++----
>  arch/arm/kernel/sleep.S                  |  2 +-
>  arch/arm/kvm/interrupts.S                |  2 +-
>  arch/arm/lib/call_with_stack.S           |  2 +-
>  arch/arm/mm/proc-v7m.S                   |  2 +-
>  14 files changed, 42 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 2c45b5709fa4..06e983f59980 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -130,7 +130,7 @@ start:
>                 .endr
>     ARM(                mov     r0, r0          )
>     ARM(                b       1f              )
> - THUMB(                adr     r12, BSYM(1f)   )
> + THUMB(                badr    r12, 1f         )
>   THUMB(                bx      r12             )
> 
>                 .word   _magic_sig      @ Magic numbers to help the loader
> @@ -447,7 +447,7 @@ dtb_check_done:
> 
>                 bl      cache_clean_flush
> 
> -               adr     r0, BSYM(restart)
> +               badr    r0, restart
>                 add     r0, r0, r6
>                 mov     pc, r0
> 
> diff --git a/arch/arm/common/mcpm_head.S b/arch/arm/common/mcpm_head.S
> index e02db4b81a66..08b3bb9bc6a2 100644
> --- a/arch/arm/common/mcpm_head.S
> +++ b/arch/arm/common/mcpm_head.S
> @@ -49,7 +49,7 @@
>  ENTRY(mcpm_entry_point)
> 
>   ARM_BE8(setend        be)
> - THUMB(        adr     r12, BSYM(1f)   )
> + THUMB(        badr    r12, 1f         )
>   THUMB(        bx      r12             )
>   THUMB(        .thumb                  )
>  1:
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 186270b3e194..4abe57279c66 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -178,6 +178,21 @@
>         .endm
> 
>  /*
> + * Assembly version of "adr rd, BSYM(sym)".  This should only be used to
> + * reference local symbols in the same assembly file which are to be
> + * resolved by the assembler.  Other usage is undefined.

BSYM() is gone, so this comment shouldn't refer to it...

> + */
> +       .irp    c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo

This wrap-macro-with-cc idiom could be factored, but it may not be worth
it just yet.

[...]

Cheers
---Dave

your mail

[Ard Biesheuvel]

On 21 April 2015 at 14:50, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
>> We should probably create a badr macro to complement the adr pseudo-op
>> which incorporates the BSYM thing so make this clearer - and a comment
>> before it.  This is really the case where BSYM should be used.
>
> Something like this.  Note that I've also removed the BSYM() usage in
> the KVM code.
>

Yes, that is much better. It is a pity that we still can't use '| 1'
but the fact that you are forced to use 'adr' now probably mostly
eliminates the risk regarding that.

I did notice that are are 4 or 5 instances (commented inline) of an
ARM to thumb mode switch which can just as easily be implemented as
'blx 1f' instead of using this badr macro (whose use we want to
discourage, I assume, since the address arithmetic is still slightly
dodgy). Do you think we should do something about that as well?

>  arch/arm/boot/compressed/head.S          |  4 ++--
>  arch/arm/common/mcpm_head.S              |  2 +-
>  arch/arm/include/asm/assembler.h         | 17 ++++++++++++++++-
>  arch/arm/include/asm/entry-macro-multi.S |  4 ++--
>  arch/arm/include/asm/unified.h           |  2 --
>  arch/arm/kernel/entry-armv.S             | 12 ++++++------
>  arch/arm/kernel/entry-common.S           |  6 +++---
>  arch/arm/kernel/entry-ftrace.S           |  2 +-
>  arch/arm/kernel/head-nommu.S             |  6 +++---
>  arch/arm/kernel/head.S                   |  8 ++++----
>  arch/arm/kernel/sleep.S                  |  2 +-
>  arch/arm/kvm/interrupts.S                |  2 +-
>  arch/arm/lib/call_with_stack.S           |  2 +-
>  arch/arm/mm/proc-v7m.S                   |  2 +-
>  14 files changed, 42 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 2c45b5709fa4..06e983f59980 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -130,7 +130,7 @@ start:
>                 .endr
>     ARM(                mov     r0, r0          )
>     ARM(                b       1f              )
> - THUMB(                adr     r12, BSYM(1f)   )
> + THUMB(                badr    r12, 1f         )
>   THUMB(                bx      r12             )
>

blx 1f

>                 .word   _magic_sig      @ Magic numbers to help the loader
> @@ -447,7 +447,7 @@ dtb_check_done:
>
>                 bl      cache_clean_flush
>
> -               adr     r0, BSYM(restart)
> +               badr    r0, restart
>                 add     r0, r0, r6
>                 mov     pc, r0
>
> diff --git a/arch/arm/common/mcpm_head.S b/arch/arm/common/mcpm_head.S
> index e02db4b81a66..08b3bb9bc6a2 100644
> --- a/arch/arm/common/mcpm_head.S
> +++ b/arch/arm/common/mcpm_head.S
> @@ -49,7 +49,7 @@
>  ENTRY(mcpm_entry_point)
>
>   ARM_BE8(setend        be)
> - THUMB(        adr     r12, BSYM(1f)   )
> + THUMB(        badr    r12, 1f         )
>   THUMB(        bx      r12             )
>   THUMB(        .thumb                  )
>  1:

likewise

> [...]
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index 84da14b7cd04..c9660167ef1a 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -46,7 +46,7 @@ ENTRY(stext)
>         .arm
>  ENTRY(stext)
>
> - THUMB(        adr     r9, BSYM(1f)    )       @ Kernel is always entered in ARM.
> + THUMB(        badr    r9, 1f          )       @ Kernel is always entered in ARM.
>   THUMB(        bx      r9              )       @ If this is a Thumb-2 kernel,
>   THUMB(        .thumb                  )       @ switch to Thumb now.
>   THUMB(1:                      )

likewise

> @@ -79,7 +79,7 @@ ENTRY(stext)
>  #endif
>         ldr     r13, =__mmap_switched           @ address to jump to after
>                                                 @ initialising sctlr
> -       adr     lr, BSYM(1f)                    @ return (PIC) address
> +       badr    lr, 1f                          @ return (PIC) address
>         ldr     r12, [r10, #PROCINFO_INITFUNC]
>         add     r12, r12, r10
>         ret     r12
> @@ -115,7 +115,7 @@ ENTRY(secondary_startup)
>         bl      __setup_mpu                     @ Initialize the MPU
>  #endif
>
> -       adr     lr, BSYM(__after_proc_init)     @ return address
> +       badr    lr, __after_proc_init           @ return address
>         mov     r13, r12                        @ __secondary_switched address
>         ldr     r12, [r10, #PROCINFO_INITFUNC]
>         add     r12, r12, r10
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 7304b4c44b52..1eecd57453be 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -80,7 +80,7 @@
>  ENTRY(stext)
>   ARM_BE8(setend        be )                    @ ensure we are in BE8 mode
>
> - THUMB(        adr     r9, BSYM(1f)    )       @ Kernel is always entered in ARM.
> + THUMB(        badr    r9, 1f          )       @ Kernel is always entered in ARM.
>   THUMB(        bx      r9              )       @ If this is a Thumb-2 kernel,
>   THUMB(        .thumb                  )       @ switch to Thumb now.
>   THUMB(1:                      )

likewise

> @@ -148,7 +148,7 @@ ENTRY(stext)
>          */
>         ldr     r13, =__mmap_switched           @ address to jump to after
>                                                 @ mmu has been enabled
> -       adr     lr, BSYM(1f)                    @ return (PIC) address
> +       badr    lr, 1f                          @ return (PIC) address
>  #ifdef CONFIG_ARM_LPAE
>         mov     r5, #0                          @ high TTBR0
>         mov     r8, r4, lsr #12                 @ TTBR1 is swapper_pg_dir pfn
> @@ -364,7 +364,7 @@ __turn_mmu_on_loc:
>         .text
>  ENTRY(secondary_startup_arm)
>         .arm
> - THUMB(        adr     r9, BSYM(1f)    )       @ Kernel is entered in ARM.
> + THUMB(        badr    r9, 1f          )       @ Kernel is entered in ARM.
>   THUMB(        bx      r9              )       @ If this is a Thumb-2 kernel,
>   THUMB(        .thumb                  )       @ switch to Thumb now.
>   THUMB(1:                      )

likewise

-- 
Ard.

your mail

[Russell King - ARM Linux]

On Tue, Apr 21, 2015 at 12:24:20PM +0100, Russell King - ARM Linux wrote:
> We should probably create a badr macro to complement the adr pseudo-op
> which incorporates the BSYM thing so make this clearer - and a comment
> before it.  This is really the case where BSYM should be used.

Something like this.  Note that I've also removed the BSYM() usage in
the KVM code.

 arch/arm/boot/compressed/head.S          |  4 ++--
 arch/arm/common/mcpm_head.S              |  2 +-
 arch/arm/include/asm/assembler.h         | 17 ++++++++++++++++-
 arch/arm/include/asm/entry-macro-multi.S |  4 ++--
 arch/arm/include/asm/unified.h           |  2 --
 arch/arm/kernel/entry-armv.S             | 12 ++++++------
 arch/arm/kernel/entry-common.S           |  6 +++---
 arch/arm/kernel/entry-ftrace.S           |  2 +-
 arch/arm/kernel/head-nommu.S             |  6 +++---
 arch/arm/kernel/head.S                   |  8 ++++----
 arch/arm/kernel/sleep.S                  |  2 +-
 arch/arm/kvm/interrupts.S                |  2 +-
 arch/arm/lib/call_with_stack.S           |  2 +-
 arch/arm/mm/proc-v7m.S                   |  2 +-
 14 files changed, 42 insertions(+), 29 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 2c45b5709fa4..06e983f59980 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -130,7 +130,7 @@ start:
 		.endr
    ARM(		mov	r0, r0		)
    ARM(		b	1f		)
- THUMB(		adr	r12, BSYM(1f)	)
+ THUMB(		badr	r12, 1f		)
  THUMB(		bx	r12		)
 
 		.word	_magic_sig	@ Magic numbers to help the loader
@@ -447,7 +447,7 @@ dtb_check_done:
 
 		bl	cache_clean_flush
 
-		adr	r0, BSYM(restart)
+		badr	r0, restart
 		add	r0, r0, r6
 		mov	pc, r0
 
diff --git a/arch/arm/common/mcpm_head.S b/arch/arm/common/mcpm_head.S
index e02db4b81a66..08b3bb9bc6a2 100644
--- a/arch/arm/common/mcpm_head.S
+++ b/arch/arm/common/mcpm_head.S
@@ -49,7 +49,7 @@
 ENTRY(mcpm_entry_point)
 
  ARM_BE8(setend        be)
- THUMB(	adr	r12, BSYM(1f)	)
+ THUMB(	badr	r12, 1f		)
  THUMB(	bx	r12		)
  THUMB(	.thumb			)
 1:
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 186270b3e194..4abe57279c66 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -178,6 +178,21 @@
 	.endm
 
 /*
+ * Assembly version of "adr rd, BSYM(sym)".  This should only be used to
+ * reference local symbols in the same assembly file which are to be
+ * resolved by the assembler.  Other usage is undefined.
+ */
+	.irp	c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
+	.macro	badr\c, rd, sym
+#ifdef CONFIG_THUMB2_KERNEL
+	adr\c	\rd, \sym + 1
+#else
+	adr\c	\rd, \sym
+#endif
+	.endm
+	.endr
+
+/*
  * Get current thread_info.
  */
 	.macro	get_thread_info, rd
@@ -326,7 +341,7 @@
 THUMB(	orr	\reg , \reg , #PSR_T_BIT	)
 	bne	1f
 	orr	\reg, \reg, #PSR_A_BIT
-	adr	lr, BSYM(2f)
+	badr	lr, 2f
 	msr	spsr_cxsf, \reg
 	__MSR_ELR_HYP(14)
 	__ERET
diff --git a/arch/arm/include/asm/entry-macro-multi.S b/arch/arm/include/asm/entry-macro-multi.S
index 469a2b30fa27..609184f522ee 100644
--- a/arch/arm/include/asm/entry-macro-multi.S
+++ b/arch/arm/include/asm/entry-macro-multi.S
@@ -10,7 +10,7 @@
 	@
 	@ routine called with r0 = irq number, r1 = struct pt_regs *
 	@
-	adrne	lr, BSYM(1b)
+	badrne	lr, 1b
 	bne	asm_do_IRQ
 
 #ifdef CONFIG_SMP
@@ -23,7 +23,7 @@
 	ALT_SMP(test_for_ipi r0, r2, r6, lr)
 	ALT_UP_B(9997f)
 	movne	r1, sp
-	adrne	lr, BSYM(1b)
+	badrne	lr, 1b
 	bne	do_IPI
 #endif
 9997:
diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
index 200f9a7cd623..a91ae499614c 100644
--- a/arch/arm/include/asm/unified.h
+++ b/arch/arm/include/asm/unified.h
@@ -45,7 +45,6 @@
 #define THUMB(x...)	x
 #ifdef __ASSEMBLY__
 #define W(instr)	instr.w
-#define BSYM(sym)	sym + 1
 #else
 #define WASM(instr)	#instr ".w"
 #endif
@@ -59,7 +58,6 @@
 #define THUMB(x...)
 #ifdef __ASSEMBLY__
 #define W(instr)	instr
-#define BSYM(sym)	sym
 #else
 #define WASM(instr)	#instr
 #endif
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 570306c49406..f8f7398c74c2 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -40,7 +40,7 @@
 #ifdef CONFIG_MULTI_IRQ_HANDLER
 	ldr	r1, =handle_arch_irq
 	mov	r0, sp
-	adr	lr, BSYM(9997f)
+	badr	lr, 9997f
 	ldr	pc, [r1]
 #else
 	arch_irq_handler_default
@@ -273,7 +273,7 @@ __und_svc:
 	str	r4, [sp, #S_PC]
 	orr	r0, r9, r0, lsl #16
 #endif
-	adr	r9, BSYM(__und_svc_finish)
+	badr	r9, __und_svc_finish
 	mov	r2, r4
 	bl	call_fpe
 
@@ -469,7 +469,7 @@ __und_usr:
 	@ instruction, or the more conventional lr if we are to treat
 	@ this as a real undefined instruction
 	@
-	adr	r9, BSYM(ret_from_exception)
+	badr	r9, ret_from_exception
 
 	@ IRQs must be enabled before attempting to read the instruction from
 	@ user space since that could cause a page/translation fault if the
@@ -486,7 +486,7 @@ __und_usr:
 	@ r2 = PC value for the following instruction (:= regs->ARM_pc)
 	@ r4 = PC value for the faulting instruction
 	@ lr = 32-bit undefined instruction function
-	adr	lr, BSYM(__und_usr_fault_32)
+	badr	lr, __und_usr_fault_32
 	b	call_fpe
 
 __und_usr_thumb:
@@ -522,7 +522,7 @@ ARM_BE8(rev16	r0, r0)				@ little endian instruction
 	add	r2, r2, #2			@ r2 is PC + 2, make it PC + 4
 	str	r2, [sp, #S_PC]			@ it's a 2x16bit instr, update
 	orr	r0, r0, r5, lsl #16
-	adr	lr, BSYM(__und_usr_fault_32)
+	badr	lr, __und_usr_fault_32
 	@ r0 = the two 16-bit Thumb instructions which caused the exception
 	@ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc)
 	@ r4 = PC value for the first 16-bit Thumb instruction
@@ -716,7 +716,7 @@ __und_usr_fault_32:
 __und_usr_fault_16:
 	mov	r1, #2
 1:	mov	r0, sp
-	adr	lr, BSYM(ret_from_exception)
+	badr	lr, ret_from_exception
 	b	__und_fault
 ENDPROC(__und_usr_fault_32)
 ENDPROC(__und_usr_fault_16)
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index f8ccc21fa032..6ab159384667 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -88,7 +88,7 @@ ENTRY(ret_from_fork)
 	bl	schedule_tail
 	cmp	r5, #0
 	movne	r0, r4
-	adrne	lr, BSYM(1f)
+	badrne	lr, 1f
 	retne	r5
 1:	get_thread_info tsk
 	b	ret_slow_syscall
@@ -196,7 +196,7 @@ local_restart:
 	bne	__sys_trace
 
 	cmp	scno, #NR_syscalls		@ check upper syscall limit
-	adr	lr, BSYM(ret_fast_syscall)	@ return address
+	badr	lr, ret_fast_syscall		@ return address
 	ldrcc	pc, [tbl, scno, lsl #2]		@ call sys_* routine
 
 	add	r1, sp, #S_OFF
@@ -231,7 +231,7 @@ __sys_trace:
 	add	r0, sp, #S_OFF
 	bl	syscall_trace_enter
 
-	adr	lr, BSYM(__sys_trace_return)	@ return address
+	badr	lr, __sys_trace_return		@ return address
 	mov	scno, r0			@ syscall number (possibly new)
 	add	r1, sp, #S_R0 + S_OFF		@ pointer to regs
 	cmp	scno, #NR_syscalls		@ check upper syscall limit
diff --git a/arch/arm/kernel/entry-ftrace.S b/arch/arm/kernel/entry-ftrace.S
index fe57c73e70a4..c73c4030ca5d 100644
--- a/arch/arm/kernel/entry-ftrace.S
+++ b/arch/arm/kernel/entry-ftrace.S
@@ -87,7 +87,7 @@
 
 1: 	mcount_get_lr	r1			@ lr of instrumented func
 	mcount_adjust_addr	r0, lr		@ instrumented function
-	adr	lr, BSYM(2f)
+	badr	lr, 2f
 	mov	pc, r2
 2:	mcount_exit
 .endm
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index 84da14b7cd04..c9660167ef1a 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -46,7 +46,7 @@ ENTRY(stext)
 	.arm
 ENTRY(stext)
 
- THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
+ THUMB(	badr	r9, 1f		)	@ Kernel is always entered in ARM.
  THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
  THUMB(	.thumb			)	@ switch to Thumb now.
  THUMB(1:			)
@@ -79,7 +79,7 @@ ENTRY(stext)
 #endif
 	ldr	r13, =__mmap_switched		@ address to jump to after
 						@ initialising sctlr
-	adr	lr, BSYM(1f)			@ return (PIC) address
+	badr	lr, 1f				@ return (PIC) address
 	ldr	r12, [r10, #PROCINFO_INITFUNC]
 	add	r12, r12, r10
 	ret	r12
@@ -115,7 +115,7 @@ ENTRY(secondary_startup)
 	bl      __setup_mpu			@ Initialize the MPU
 #endif
 
-	adr	lr, BSYM(__after_proc_init)	@ return address
+	badr	lr, __after_proc_init		@ return address
 	mov	r13, r12			@ __secondary_switched address
 	ldr	r12, [r10, #PROCINFO_INITFUNC]
 	add	r12, r12, r10
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 7304b4c44b52..1eecd57453be 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -80,7 +80,7 @@
 ENTRY(stext)
  ARM_BE8(setend	be )			@ ensure we are in BE8 mode
 
- THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is always entered in ARM.
+ THUMB(	badr	r9, 1f		)	@ Kernel is always entered in ARM.
  THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
  THUMB(	.thumb			)	@ switch to Thumb now.
  THUMB(1:			)
@@ -148,7 +148,7 @@ ENTRY(stext)
 	 */
 	ldr	r13, =__mmap_switched		@ address to jump to after
 						@ mmu has been enabled
-	adr	lr, BSYM(1f)			@ return (PIC) address
+	badr	lr, 1f				@ return (PIC) address
 #ifdef CONFIG_ARM_LPAE
 	mov	r5, #0				@ high TTBR0
 	mov	r8, r4, lsr #12			@ TTBR1 is swapper_pg_dir pfn
@@ -364,7 +364,7 @@ __turn_mmu_on_loc:
 	.text
 ENTRY(secondary_startup_arm)
 	.arm
- THUMB(	adr	r9, BSYM(1f)	)	@ Kernel is entered in ARM.
+ THUMB(	badr	r9, 1f		)	@ Kernel is entered in ARM.
  THUMB(	bx	r9		)	@ If this is a Thumb-2 kernel,
  THUMB(	.thumb			)	@ switch to Thumb now.
  THUMB(1:			)
@@ -400,7 +400,7 @@ ENTRY(secondary_startup)
 	add	r3, r7, lr
 	ldrd	r4, [r3, #0]			@ get secondary_data.pgdir
 	ldr	r8, [r3, #8]			@ get secondary_data.swapper_pg_dir
-	adr	lr, BSYM(__enable_mmu)		@ return address
+	badr	lr, __enable_mmu		@ return address
 	mov	r13, r12			@ __secondary_switched address
 	ldr	r12, [r10, #PROCINFO_INITFUNC]
 	add	r12, r12, r10			@ initialise processor
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 7d37bfc50830..76bb3128e135 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -81,7 +81,7 @@ ENTRY(__cpu_suspend)
 	mov	r1, r4			@ size of save block
 	add	r0, sp, #8		@ pointer to save block
 	bl	__cpu_suspend_save
-	adr	lr, BSYM(cpu_suspend_abort)
+	badr	lr, cpu_suspend_abort
 	ldmfd	sp!, {r0, pc}		@ call suspend fn
 ENDPROC(__cpu_suspend)
 	.ltorg
diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 79caf79b304a..87847d2c5f99 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -309,7 +309,7 @@ ENTRY(kvm_call_hyp)
 THUMB(	orr	r2, r2, #PSR_T_BIT	)
 	msr	spsr_cxsf, r2
 	mrs	r1, ELR_hyp
-	ldr	r2, =BSYM(panic)
+	ldr	r2, =panic
 	msr	ELR_hyp, r2
 	ldr	r0, =\panic_str
 	clrex				@ Clear exclusive monitor
diff --git a/arch/arm/lib/call_with_stack.S b/arch/arm/lib/call_with_stack.S
index ed1a421813cb..bf3a40889205 100644
--- a/arch/arm/lib/call_with_stack.S
+++ b/arch/arm/lib/call_with_stack.S
@@ -35,7 +35,7 @@ ENTRY(call_with_stack)
 	mov	r2, r0
 	mov	r0, r1
 
-	adr	lr, BSYM(1f)
+	badr	lr, 1f
 	ret	r2
 
 1:	ldr	lr, [sp]
diff --git a/arch/arm/mm/proc-v7m.S b/arch/arm/mm/proc-v7m.S
index e08e1f2bab76..67d9209077c6 100644
--- a/arch/arm/mm/proc-v7m.S
+++ b/arch/arm/mm/proc-v7m.S
@@ -98,7 +98,7 @@ __v7m_setup:
 	str	r5, [r0, V7M_SCB_SHPR3]	@ set PendSV priority
 
 	@ SVC to run the kernel in this mode
-	adr	r1, BSYM(1f)
+	badr	r1, 1f
 	ldr	r5, [r12, #11 * 4]	@ read the SVC vector entry
 	str	r1, [r12, #11 * 4]	@ write the temporary SVC vector entry
 	mov	r6, lr			@ save LR

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

your mail

[Russell King - ARM Linux]

On Tue, Apr 21, 2015 at 12:10:43PM +0100, Dave P Martin wrote:
> On Tue, Apr 21, 2015 at 11:50:02AM +0100, Ard Biesheuvel wrote:
> > OK, that makes sense. But it does appear that the local cross-section
> > references are working just fine, i.e., references from other sections
> > in the same .o have the thumb bit set correctly even without BSYM()
> 
> For branch targets, the set of situations where BSYM must be used and
> the set of situations where it must not be used are mutually exclusive:
> 
>  * If the assembler resolves the address and the address will be used as a
>    branch target, BSYM() must be used.  This applies to non-cross-section
>    references within in single object only.
> 
>  * If the linker resolves the address, BSYM() must not be used and the
>    target label must be annotated with ENDPROC().  This applies to
>    all cross-section or cross-object references.

Yes, that agrees with the situation we have for the initfunc stuff.

> For any address that won't be used as a branch target, BSYM() must not
> be used.
> 
> Cross-section non-cross-object references where the target is missing
> ENDPROC() and BSYM _is_ used will also work, but this should be avoided
> -- it's an abuse really.

We should probably create a badr macro to complement the adr pseudo-op
which incorporates the BSYM thing so make this clearer - and a comment
before it.  This is really the case where BSYM should be used.

We have one case in the kernel source which is probably buggy:

arch/arm/kvm/interrupts.S:      ldr     r2, =BSYM(panic)

and killing BSYM in favour of a badr macro would prevent this.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

your mail

[Ard Biesheuvel]

On 21 April 2015 at 13:10, Dave P Martin <Dave.Martin@arm.com> wrote:
> On Tue, Apr 21, 2015 at 11:50:02AM +0100, Ard Biesheuvel wrote:
>> On 21 April 2015 at 12:46, Dave P Martin <Dave.Martin@arm.com> wrote:
>> > On Tue, Apr 21, 2015 at 11:18:08AM +0100, Ard Biesheuvel wrote:
>> >> On 21 April 2015 at 12:13, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
>> >> >> This updates the PROCINFO offset-to-setup-function fields of the
>> >> >> Thumb2 capable CPU definitions to include the Thumb bit when building
>> >> >> a Thumb2 kernel. This ensures that these function are always called
>> >> >> in the correct mode.
>> >> >
>> >> > I don't think this is necessary, in fact, I think this is positively
>> >> > regression causing.
>> >> >
>> >> > The symbol 'initfunc' is known to the assembler to be a thumb symbol.
>> >> > As we have seen already from the kernel dumps from the V7M kernel, when
>> >> > it calculates initfunc - name in a T2 kernel, the resulting value is an
>> >> > _odd_ number.
>> >> >
>> >>
>> >> OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
>> >
>> > '| 1' is more logical, but can't be resolved at link time because
>> > there's no relocation for this operation.  Hence '+ 1'.  This matters
>> > for local cross-section references that can't be resolved at assembly
>> > time.
>> >
>>
>> OK, that makes sense. But it does appear that the local cross-section
>> references are working just fine, i.e., references from other sections
>> in the same .o have the thumb bit set correctly even without BSYM()
>
> For branch targets, the set of situations where BSYM must be used and
> the set of situations where it must not be used are mutually exclusive:
>
>  * If the assembler resolves the address and the address will be used as a
>    branch target, BSYM() must be used.  This applies to non-cross-section
>    references within in single object only.
>

Here, 'sym | 1' should work ...

>  * If the linker resolves the address, BSYM() must not be used and the
>    target label must be annotated with ENDPROC().  This applies to
>    all cross-section or cross-object references.
>
> For any address that won't be used as a branch target, BSYM() must not
> be used.
>
> Cross-section non-cross-object references where the target is missing
> ENDPROC() and BSYM _is_ used will also work, but this should be avoided
> -- it's an abuse really.
>

... and for the other cases, we rely on the assembler to emit
relocations for the linker to process.

So in summary, defining BSYM() as 'sym + 1' rather than 'sym | 1' only
enables cases where BSYM() shouldn't be used in the first place. Or am
I missing something?

>
> The reason for these rules is that the assembler doesn't do any Thumb
> bit handling when taking the address of a local symbol, irrespective
> of the symbol's type.  This can result in a screwup unless the assembler
> can't resolve the address and must leave it as a relocation for the
> linker to process, or if the correct annotation for the linker to do
> the right fixup is missing.
>
>
> I don't know the history of why this inconsistency exists between the
> assembler and linker behaviour, but changing it would likely break
> more stuff than it fixes now.
>
> Maybe it would be a good idea to add a comment in asm/unified.h
> explaining this, assuming (hopefully) that my explanation was right...
>

your mail

[Dave P Martin]

On Tue, Apr 21, 2015 at 11:50:02AM +0100, Ard Biesheuvel wrote:
> On 21 April 2015 at 12:46, Dave P Martin <Dave.Martin@arm.com> wrote:
> > On Tue, Apr 21, 2015 at 11:18:08AM +0100, Ard Biesheuvel wrote:
> >> On 21 April 2015 at 12:13, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
> >> >> This updates the PROCINFO offset-to-setup-function fields of the
> >> >> Thumb2 capable CPU definitions to include the Thumb bit when building
> >> >> a Thumb2 kernel. This ensures that these function are always called
> >> >> in the correct mode.
> >> >
> >> > I don't think this is necessary, in fact, I think this is positively
> >> > regression causing.
> >> >
> >> > The symbol 'initfunc' is known to the assembler to be a thumb symbol.
> >> > As we have seen already from the kernel dumps from the V7M kernel, when
> >> > it calculates initfunc - name in a T2 kernel, the resulting value is an
> >> > _odd_ number.
> >> >
> >>
> >> OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
> >
> > '| 1' is more logical, but can't be resolved at link time because
> > there's no relocation for this operation.  Hence '+ 1'.  This matters
> > for local cross-section references that can't be resolved at assembly
> > time.
> >
> 
> OK, that makes sense. But it does appear that the local cross-section
> references are working just fine, i.e., references from other sections
> in the same .o have the thumb bit set correctly even without BSYM()

For branch targets, the set of situations where BSYM must be used and
the set of situations where it must not be used are mutually exclusive:

 * If the assembler resolves the address and the address will be used as a
   branch target, BSYM() must be used.  This applies to non-cross-section
   references within in single object only.

 * If the linker resolves the address, BSYM() must not be used and the
   target label must be annotated with ENDPROC().  This applies to
   all cross-section or cross-object references.

For any address that won't be used as a branch target, BSYM() must not
be used.

Cross-section non-cross-object references where the target is missing
ENDPROC() and BSYM _is_ used will also work, but this should be avoided
-- it's an abuse really.


The reason for these rules is that the assembler doesn't do any Thumb
bit handling when taking the address of a local symbol, irrespective
of the symbol's type.  This can result in a screwup unless the assembler
can't resolve the address and must leave it as a relocation for the
linker to process, or if the correct annotation for the linker to do
the right fixup is missing.


I don't know the history of why this inconsistency exists between the
assembler and linker behaviour, but changing it would likely break
more stuff than it fixes now.

Maybe it would be a good idea to add a comment in asm/unified.h
explaining this, assuming (hopefully) that my explanation was right...

[...]

Cheers
---Dave

your mail

[Ard Biesheuvel]

On 21 April 2015 at 12:46, Dave P Martin <Dave.Martin@arm.com> wrote:
> On Tue, Apr 21, 2015 at 11:18:08AM +0100, Ard Biesheuvel wrote:
>> On 21 April 2015 at 12:13, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
>> >> This updates the PROCINFO offset-to-setup-function fields of the
>> >> Thumb2 capable CPU definitions to include the Thumb bit when building
>> >> a Thumb2 kernel. This ensures that these function are always called
>> >> in the correct mode.
>> >
>> > I don't think this is necessary, in fact, I think this is positively
>> > regression causing.
>> >
>> > The symbol 'initfunc' is known to the assembler to be a thumb symbol.
>> > As we have seen already from the kernel dumps from the V7M kernel, when
>> > it calculates initfunc - name in a T2 kernel, the resulting value is an
>> > _odd_ number.
>> >
>>
>> OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.
>
> '| 1' is more logical, but can't be resolved at link time because
> there's no relocation for this operation.  Hence '+ 1'.  This matters
> for local cross-section references that can't be resolved at assembly
> time.
>

OK, that makes sense. But it does appear that the local cross-section
references are working just fine, i.e., references from other sections
in the same .o have the thumb bit set correctly even without BSYM()

>> But looking at proc-v7.S again, the problem may just be the missing
>> ENDPROC() declarations for a couple of the setup() functions, which
>> explains why they are lacking the Thumb annotations.
>
> Yes, if any are missing ENDPROC() then it should be added there.
>

I am putting together a v2 with this instead of the BSYM() on the initfn


Cheers,
Ard.

your mail

[Dave P Martin]

On Tue, Apr 21, 2015 at 11:18:08AM +0100, Ard Biesheuvel wrote:
> On 21 April 2015 at 12:13, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Apr 21, 2015 at 12:08:51PM +0200, Ard Biesheuvel wrote:
> >> This updates the PROCINFO offset-to-setup-function fields of the
> >> Thumb2 capable CPU definitions to include the Thumb bit when building
> >> a Thumb2 kernel. This ensures that these function are always called
> >> in the correct mode.
> >
> > I don't think this is necessary, in fact, I think this is positively
> > regression causing.
> >
> > The symbol 'initfunc' is known to the assembler to be a thumb symbol.
> > As we have seen already from the kernel dumps from the V7M kernel, when
> > it calculates initfunc - name in a T2 kernel, the resulting value is an
> > _odd_ number.
> >
> 
> OK, so BSYM() uses '+ 1' rather than ' | 1'? I wasn't expecting that, sorry.

'| 1' is more logical, but can't be resolved at link time because
there's no relocation for this operation.  Hence '+ 1'.  This matters
for local cross-section references that can't be resolved at assembly
time.

> But looking at proc-v7.S again, the problem may just be the missing
> ENDPROC() declarations for a couple of the setup() functions, which
> explains why they are lacking the Thumb annotations.

Yes, if any are missing ENDPROC() then it should be added there.

Cheers
---Dave

Re: your mail

[atull]

On Wed, 21 Jan 2015, Jason Gunthorpe wrote:

> [unfutzd the cc a bit, sorry]
> 
> On Wed, Jan 21, 2015 at 04:19:17PM -0600, atull wrote:
> > > If we consider a Zynq, for instance, there are a number of clock nets
> > > that the CPU drives into the FPGA fabric. These nets are controlled by
> > > the kernel CLK framework. So, before we program the FPGA bitstream the
> > > clocks must be setup properly.
> > 
> > It's pretty normal for drivers to find out what their clocks are from
> > the DT and enable them.  
> 
> Sure, but the clocks are bitfile specific, and not related to
> programming. Some bitfiles may not require CPU clocks at all.

The bitfile specific clocks are the clocks that are turned on by the device
driver for that chunk of the bitfile.  So those clocks can be specified
the same way as clocks are specied in the DT.

> 
> > Yes the DT overlay can specify:
> >   * clock info
> >   * firmware file name if user is doing it that way
> >   * fpga manager - specific info
> >     * compatiblity string specifies what type of fpga it is
> >     * which fpga this image should go into
> >   * fpga/processor bridges to enable
> >   * driver(s) info that is dependent on the above
> 
> All sounds reasonable
> 
> > > Today in our Zynq systems we have the bootloader preconfigure
> > > everything for what we are trying to do - but that is specific to the
> > > particular FPGA we are expecting to run, and eg, I expect if we ran a
> > > kernel using the Zynq clk framework there would be problems with it
> > > mangling the configuration.
> > > 
> > > So there would have to be some kind of sequence where the DT is
> > > loaded, the zynq specific FPGA programmer does its pre setup, then the
> > > request_firmarw/fpga_program_fw loads the bitstream and another pass
> > > for a zynq specific post setup and completion handshake?
> > 
> > fpga-mgr.c has the concept that each different FPGA family will
> > likely need its own way of doing these 3 steps:
> >  * write_init (prepare fgpa for receiving configuration information)
> >  * write (write configuration info to the fpga)
> >  * write_complete (done writing, put fpga into running mode)
> > 
> > There are callbacks into the manufacturor/fpga family specific lower
> > level driver to do these things (as part of the "fpga_manager_ops"
> 
> I think the missing bit here is that there are bitfile specific things
> as well.
> 
> The functions above are fine for a generic manufacturer bitfile loader,
> ie Xilinx GPIO twiddling, Altera JTAG, Zynq DMA, etc.
> 
> But wrappered around that should be another set of functions that are
> bitfile specific.
> 
> Like Zynq-PL-boot-protocol-v1 - which deasserts a reset line and waits
> for the PL to signal back that it has completed reset.
> 
> Or jgg-boot-protocol-v1 which monitors the configuration GPIOs for a
> specific ready pattern..
> 
> Or ... 
> 
> All of those procedures depend on the bitfile to implement something.
> 
> > > The DT needs to specify not only the bitstream programming HW to use
> > > but this ancillary programming protocol. There are many ways to do
> > > a out of reset and completion handshake on Zynq, for instance.
> > 
> > Currently the lower level driver supports only one preferred method
> > of programming.  I guess we could add an enumerated DT property to
> > select programming protocol.  It would have to be manufacturor specific.
> > Alternatively it could be encoded into the compatibility string if that
> > makes sense.
> 
> From a DT perspective I'd expect it to look something like:
> 
> soc {
> 
>   // This is the 'how to program a bitstream'
>   fpga-bitstream0: zynq_pl_dma 
>   {
>      compatible = "xilinx,zynq,pl,dma";
>      regs = <..>
>   }
> 
>   fpga: ..
>   {
>      // This is 'what is in the bitstream'
>      boot-protocol = "xilinx,zynq,protocol1";
>      compatible = "jgg,fpga-foo-bar";
>      manager = @fpga-bitstream0
>      clocks = ..
>      clock-frequency = ...
> 
>      zynq_axi_gp0
>      {
>       // Settings for a CPU to FPGA AXI bridge
>        axi setting 1 = ...
>        [...]
>      }
>   }
> }

That's good.  It also needs to specify the driver(s) for the hardware that the
bitstream will instantiate.

> 
> I could also see integrating with the regulator framework as well to
> power up FPGA specific controllable power supplies.
> 
> > > And then user space would need to have control points between each of
> > > these steps.
> 
> > We could have two options, configurable from the ioctl:
> > * When the DT is loaded, do everything
> > * Even when the DT is loaded, wait for further instructions from ioctl or
> > 
> > Freewheeling flow:
> > * Tell ioctl that we are in freewheeling mode
> > * Load DT overlay
> > 
> > Tightly controlled flow:
> > * Tell ioctl that we are doing things stepwise
> > * Load DT overlay
> > * Use ioctl to step through getting the fpga loaded and known to be happy
> 
> I think you've certainly got the idea!
> 
> Thinking it through some more, if the kernel DT tells the fpga-mgr
> that it is 
> 
>   boot-protocol = "xilinx,zynq,protocol1","jgg,foo-bar";
> 
> Then the kernel should refuse to start it if it doesn't know how to do
> both 'xilinx,zynq,protocol1' and 'jgg,foo-bar'.
> 
> Thus the user space ioctl interface becomes more of how to implement a
> boot protocol helper in userspace? With the proper locking - while the
> helper is working the FPGA cannot be messed with..
> 
> Jason
> 

Re: your mail

[One Thousand Gnomes]

> The functions above are fine for a generic manufacturer bitfile loader,
> ie Xilinx GPIO twiddling, Altera JTAG, Zynq DMA, etc.
> 
> But wrappered around that should be another set of functions that are
> bitfile specific.

And also a transport layer. You can have the same FPGA with the same
loader protocol off multiple different bus types (from USB to on CPU die
and all the way between).

Alan

Re: your mail

[Jason Gunthorpe]

[unfutzd the cc a bit, sorry]

On Wed, Jan 21, 2015 at 04:19:17PM -0600, atull wrote:
> > If we consider a Zynq, for instance, there are a number of clock nets
> > that the CPU drives into the FPGA fabric. These nets are controlled by
> > the kernel CLK framework. So, before we program the FPGA bitstream the
> > clocks must be setup properly.
> 
> It's pretty normal for drivers to find out what their clocks are from
> the DT and enable them.  

Sure, but the clocks are bitfile specific, and not related to
programming. Some bitfiles may not require CPU clocks at all.

> Yes the DT overlay can specify:
>   * clock info
>   * firmware file name if user is doing it that way
>   * fpga manager - specific info
>     * compatiblity string specifies what type of fpga it is
>     * which fpga this image should go into
>   * fpga/processor bridges to enable
>   * driver(s) info that is dependent on the above

All sounds reasonable

> > Today in our Zynq systems we have the bootloader preconfigure
> > everything for what we are trying to do - but that is specific to the
> > particular FPGA we are expecting to run, and eg, I expect if we ran a
> > kernel using the Zynq clk framework there would be problems with it
> > mangling the configuration.
> > 
> > So there would have to be some kind of sequence where the DT is
> > loaded, the zynq specific FPGA programmer does its pre setup, then the
> > request_firmarw/fpga_program_fw loads the bitstream and another pass
> > for a zynq specific post setup and completion handshake?
> 
> fpga-mgr.c has the concept that each different FPGA family will
> likely need its own way of doing these 3 steps:
>  * write_init (prepare fgpa for receiving configuration information)
>  * write (write configuration info to the fpga)
>  * write_complete (done writing, put fpga into running mode)
> 
> There are callbacks into the manufacturor/fpga family specific lower
> level driver to do these things (as part of the "fpga_manager_ops"

I think the missing bit here is that there are bitfile specific things
as well.

The functions above are fine for a generic manufacturer bitfile loader,
ie Xilinx GPIO twiddling, Altera JTAG, Zynq DMA, etc.

But wrappered around that should be another set of functions that are
bitfile specific.

Like Zynq-PL-boot-protocol-v1 - which deasserts a reset line and waits
for the PL to signal back that it has completed reset.

Or jgg-boot-protocol-v1 which monitors the configuration GPIOs for a
specific ready pattern..

Or ... 

All of those procedures depend on the bitfile to implement something.

> > The DT needs to specify not only the bitstream programming HW to use
> > but this ancillary programming protocol. There are many ways to do
> > a out of reset and completion handshake on Zynq, for instance.
> 
> Currently the lower level driver supports only one preferred method
> of programming.  I guess we could add an enumerated DT property to
> select programming protocol.  It would have to be manufacturor specific.
> Alternatively it could be encoded into the compatibility string if that
> makes sense.

>From a DT perspective I'd expect it to look something like:

soc {

  // This is the 'how to program a bitstream'
  fpga-bitstream0: zynq_pl_dma 
  {
     compatible = "xilinx,zynq,pl,dma";
     regs = <..>
  }

  fpga: ..
  {
     // This is 'what is in the bitstream'
     boot-protocol = "xilinx,zynq,protocol1";
     compatible = "jgg,fpga-foo-bar";
     manager = @fpga-bitstream0
     clocks = ..
     clock-frequency = ...

     zynq_axi_gp0
     {
      // Settings for a CPU to FPGA AXI bridge
       axi setting 1 = ...
       [...]
     }
  }
}

I could also see integrating with the regulator framework as well to
power up FPGA specific controllable power supplies.

> > And then user space would need to have control points between each of
> > these steps.

> We could have two options, configurable from the ioctl:
> * When the DT is loaded, do everything
> * Even when the DT is loaded, wait for further instructions from ioctl or
> 
> Freewheeling flow:
> * Tell ioctl that we are in freewheeling mode
> * Load DT overlay
> 
> Tightly controlled flow:
> * Tell ioctl that we are doing things stepwise
> * Load DT overlay
> * Use ioctl to step through getting the fpga loaded and known to be happy

I think you've certainly got the idea!

Thinking it through some more, if the kernel DT tells the fpga-mgr
that it is 

  boot-protocol = "xilinx,zynq,protocol1","jgg,foo-bar";

Then the kernel should refuse to start it if it doesn't know how to do
both 'xilinx,zynq,protocol1' and 'jgg,foo-bar'.

Thus the user space ioctl interface becomes more of how to implement a
boot protocol helper in userspace? With the proper locking - while the
helper is working the FPGA cannot be messed with..

Jason

your mail

[Mark Rutland]

On Tue, Oct 28, 2014 at 02:13:25PM +0000, Mark Rutland wrote:
> Bcc:
> Subject: Re: [PATCHv4 7/7] arm64: add better page protections to arm64
> Reply-To:
> In-Reply-To: <1414440752-9411-8-git-send-email-lauraa@codeaurora.org>

Apologies for this, I appear to have accidentally inserted a newline and
confused my mail client. I'll resend this with that fixed.

Mark.

> 
> Hi Laura,
> 
> On Mon, Oct 27, 2014 at 08:12:32PM +0000, Laura Abbott wrote:
> > Add page protections for arm64 similar to those in arm.
> > This is for security reasons to prevent certain classes
> > of exploits. The current method:
> >
> > - Map all memory as either RWX or RW. We round to the nearest
> >   section to avoid creating page tables before everything is mapped
> > - Once everything is mapped, if either end of the RWX section should
> >   not be X, we split the PMD and remap as necessary
> > - When initmem is to be freed, we change the permissions back to
> >   RW (using stop machine if necessary to flush the TLB)
> > - If CONFIG_DEBUG_RODATA is set, the read only sections are set
> >   read only.
> >
> > Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> > ---
> > v4: Combined the Kconfig options
> > ---
> >  arch/arm64/Kconfig.debug            |  23 +++
> >  arch/arm64/include/asm/cacheflush.h |   4 +
> >  arch/arm64/kernel/vmlinux.lds.S     |  17 ++
> >  arch/arm64/mm/init.c                |   1 +
> >  arch/arm64/mm/mm.h                  |   2 +
> >  arch/arm64/mm/mmu.c                 | 303 +++++++++++++++++++++++++++++++-----
> >  6 files changed, 314 insertions(+), 36 deletions(-)
> 
> With this patch applied to v3.18-rc2, my board to blows up at boot when
> using UEFI (without DEBUG_RODATA selected):
> 
> ---->8----
> EFI stub: Booting Linux Kernel...
> Initializing cgroup subsys cpu
> Linux version 3.18.0-rc2+ (mark at leverpostej) (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) ) #112 SMP PREEMPT Tue Oct 28 13:58:41 GMT 2014
> CPU: AArch64 Processor [410fd030] revision 0
> Detected VIPT I-cache on CPU0
> bootconsole [uart0] enabled
> efi: Getting EFI parameters from FDT:
> EFI v2.40 by ARM Juno EFI Oct  7 2014 15:05:42
> efi:  ACPI=0xfebdc000  ACPI 2.0=0xfebdc014
> cma: Reserved 16 MiB at fd800000
> BUG: failure at arch/arm64/mm/mmu.c:234/alloc_init_pmd()!
> Kernel panic - not syncing: BUG!
> CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc2+ #112
> Call trace:
> [<ffffffc000087ec8>] dump_backtrace+0x0/0x124
> [<ffffffc000087ffc>] show_stack+0x10/0x1c
> [<ffffffc0004ebd58>] dump_stack+0x74/0xb8
> [<ffffffc0004eb018>] panic+0xe0/0x220
> [<ffffffc0004e8e08>] alloc_init_pmd+0x1cc/0x1dc
> [<ffffffc0004e8e3c>] alloc_init_pud+0x24/0x6c
> [<ffffffc0004e8f54>] __create_mapping+0xd0/0xf0
> [<ffffffc00069a0a0>] create_id_mapping+0x5c/0x68
> [<ffffffc00069964c>] efi_idmap_init+0x54/0xd8
> [<ffffffc0006978a8>] setup_arch+0x408/0x5c0
> [<ffffffc00069566c>] start_kernel+0x94/0x3a0
> ---[ end Kernel panic - not syncing: BUG!
> ---->8----
> 
> I've not yet figured out precisely why. I haven't tried a !EFI boot
> because of the way my board is set up at the moment.
> 
> Mark.

Re: your mail

[Tejun Heo]

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

Re: your mail

[Dan Carpenter]

No subject.

It should be a subject about adding spaces.

regards,
dan carpenter

Re: your mail

[Dan Carpenter]

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

Re: your mail

[Mark Brown]

[-- 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, &reg_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 --]

Re: your mail

[Will Deacon]

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

Re: your mail

[Will Deacon]

On Tue, Feb 25, 2014 at 11:20:11AM +0000, srikanth TS wrote:
> 
> On Feb 25, 2014 2:28 AM, "Will Deacon" <will.deacon-5wv7dgnIgG8@public.gmane.org<mailto:will.deacon-5wv7dgnIgG8@public.gmane.org>> 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

Re: your mail

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

On Thu, Jan 23, 2014 at 02:36:05PM +0530, Prabhakar Lad wrote:
> Hi Mark,

Please use a subject line for your e-mails, otherwise they look a lot
like spam.

> 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().

What is the problem you're trying to report here?  You're describing the
behaviour of the code but I don't understand the problem.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: your mail

[Steven Rostedt]

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

Re: your mail

[Joe Borġ]

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

Re: your mail

[Greg KH]

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

Re: your mail

[Antonio Quartulli]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

On Sat, Oct 19, 2013 at 08:15:11PM -0400, David Miller wrote:
> From: Antonio Quartulli <antonio@meshcoding.com>
> Date: Sun, 20 Oct 2013 00:21:52 +0200
> 
> > this is another batch intended for net-next/linux-3.13.
> 
> Looks good, pulled, thanks a lot Antonio.
> 
> Please don't use empty subject lines in the future, lots of
> sites block such emails and I see all of those bounces as
> vger postmaster :-/
> 

Ops, my bad. I won't do it again in the future!
Thanks a lot David.


Regards,


-- 
Antonio Quartulli

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: your mail

[Igor Filakhtov]

I have a total control over IP adresses, static DHCP and so on, so
this is not a problem.

Best regards, Igor V. Filakhtov

GMail: filakhtov@gmail.com | Cell: (050) 65-66-280 | Skype: ihor.filakhtov


On Tue, Sep 3, 2013 at 12:11 PM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> The 30/08/13, Igor Filakhtov wrote:
>> Greetings all,
>
>> There are 5 users in my LAN, every of those have at least two devices
>> (pc, smartphone). These devices using static DHCP addresses. All
>> packets from single device owner are marked.
>> These packets later are shaped using TC.
>
> It might be easier to filter the traffic with tc (match ip
> src/dst/sport/dport) instead of relying on iptables.
>
> --
> Nicolas Sebrecht

Re: your mail

[Magnus Bäck]

On Friday, May 17, 2013 at 14:02 EDT,
     ASHISH VERMA <ashunew1989@gmail.com> wrote:

> Hi,  i am using git to push my code from eclipse to heroku , but
> recently iam  getting error like::
> 
> master:master rejected:non fast forward
> 
> and i am not able to resolve it .I tried a git pull but that says -
> conflicts shud be resolved before git pull can be implemented.I can;t
> find the solution Please help ASAP...

Resolve the conflicts by either hand-editing the files (you'll see the
markers where the conflicts are) add running 'git add' to tell git that
you're done resolving them, or set up Git to use a graphical tool like
kdiff3. When you're done, run 'git commit' to create the merge commit.
After that you'll be able to push to your upstream (unless things have
moved again while you were resolving the initial conflict).

This guide to merge conflicts looks pretty good:
http://gitguru.com/2009/02/22/integrating-git-with-a-visual-merge-tool/

-- 
Magnus Bäck
baeck@google.com

Re: your mail

[Kent Overstreet]

On Wed, Jan 23, 2013 at 08:37:10PM +0800, Nitin Kshirsagar wrote:
> Hello Kent,
> 
> I have setup bcache and run fio data verification test on write back and write through caches.
> The fio tests are passed, however I have found following issues while using bcache.
> 
> Issue1: Cache is not created as per user specified options  
> --------------------------------------------------------------------------------------------------------
> Steps:
> 1.Create cache by specifying mode writeback and cache replacement policy as fifo
> [root@annu bcache]# make-bcache --cache  /dev/sdc --bdev /dev/sdd  --writeback --cache_replacement_policy=fifo 
> UUID:                   e25f2840-f02b-46af-81e7-28948b2737cc
> Set UUID:               68da5b89-1e87-457a-80c7-2c822737f969
> nbuckets:               2048
> block_size:             1
> bucket_size:            1024
> nr_in_set:              1
> nr_this_dev:            0
> first_bucket:           1
> UUID:                   a3ce52e6-631b-4c74-afa2-9f8b0088c7f4
> Set UUID:               68da5b89-1e87-457a-80c7-2c822737f969
> nbuckets:               20480
> block_size:             1
> bucket_size:            1024
> nr_in_set:              1
> nr_this_dev:            0
> first_bucket:           1
> 
> [root@annu bcache]# echo /dev/sdc > /sys/fs/bcache/register
> [root@annu bcache]# echo /dev/sdd > /sys/fs/bcache/register
> 
> 
> 2. Cache mode should  be "writeback" instead of "writethrough"
> [root@annu bcache]# cat /sys/block/bcache2/bcache/cache_mode
> [writethrough] writeback writearound none
> [root@annu bcache]# cat /sys/block/bcache2/bcache/writeback_running
> 1
> 
> 3. Cache policy should be "fifo" instead of "lru" 
> [root@annu ~]# cat /sys/block/bcache2/bcache/cache/cache0/cache_replacement_policy
> [lru] fifo random

These two are... oddities/documentation bugs with make-bcache. Options
apply to devices you specify _after_ the option, not before - it was
implemented this way so you could format cache devices and backing
devices at the same time - and really, the other options should be
parsed differently but I haven't spent much time on make-bcache.

Patches welcome :)

> Issue2: Cache dirty data value should not be negative.
> -------------------------------------------------------------------------------------------------------
> Steps:
> 
> 1.Create cache by specifying mode writeback and cache replacement policy as fifo
> 2.To make bcache devices known to the kernel
>     [root@annu bcache]# echo /dev/sdc > /sys/fs/bcache/register
>     [root@annu bcache]# echo /dev/sdd > /sys/fs/bcache/register
> 3.Create FS on cache  /dev/bcacheN and mount in directory
> 4.Create Data set by using fio or dd on mount point.
> 5. Change cache node from "writethrough" to "writeback"    
>     [root@annu ~]# echo writeback >  /sys/block/bcache2/bcache/cache_mode
>     [root@annu ~]# cat /sys/block/bcache2/bcache/cache_mode
>     writethrough [writeback] writearound none
> 6.Check cache dirty data should not be negative value 
>    [root@annu ~]# cat /sys/block/bcache2/bcache/dirty_data
>    -9.4M

Known bug, but fairly harmless one. That value is only used for the pd
controller that adjusts the background writeback rate - and in practice
when there's dirty data in the cache it shouldn't be _too_ far off.

It's on the todo list, but it'll be a bit before I get to it.

Re: your mail

[Greg KH]

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

Re: your mail

[Greg KH]

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

Re: your mail

[walter harms]

Am 18.10.2012 15:17, schrieb Nicolas Palix:
> Hi,
> 
> 
>> But I do think we should maybe find another list for Fengguang's
>> emails?  It's sort of a lot higher traffic than before and sort of a
>> different flavour.
>>
>> I still will want to subscribe to the emails, but it would be better
>> to use a different list.  Apparently Dave Miller didn't like the
>> idea of creating a special list for it because he didn't like the
>> emails in the first place.  But now I think everyone likes them a
>> lot.  It might be worth asking again.
> 
> I agreed in the first place but kernel-janitors is also a great place
> for newcomers.
> Having those reports accessible could be great for them. Also, it is not
> that different than the janitorial work done before. The main difference I see
> is that there is no fixing patches associated to the reports. But the problems
> addressed are almost the same, and they are found with the same tools.
> 
> Does it worth a new list ?
> 
> Maybe the set of branches tested need to be further refined to lower
> the false positives.
> Finally, we may hope developers will test their patches before releasing them.
> 
> Is there any mean for them to apply the tests before pushing ?
> 
> If a new list is created, please let us know how to subscribe to it on this one.
> 
> Regards.
> 


I support the idea of a new list. The reports are mostly nothing that what the janitors can
review. Fengguang is important but cleary targeted to developers in ongoing projects.
Janitors care more about the state of the current kernel.

just my two cents,
 wh

Re: your mail

[Kent Yoder]

 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(-)

Re: your mail

[Christoph Lameter]

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)

Re: your mail

[Christoph Lameter]

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)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Tejun Heo]

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

Re: your mail

[Simon Paillard]

On Tue, Jul 03, 2012 at 10:18:35PM +0200, Elie De Brauwer wrote:
> subscribe linux-man

Not to the list, to majordomo itself:
http://vger.kernel.org/majordomo-info.html#subscription

-- 
Simon Paillard
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: your mail

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [120621 11:31]:
> Hi Tony
> 
> The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71:
> 
>   Linux 3.5-rc3 (2012-06-16 17:25:17 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.6
> 
> for you to fetch changes up to 07b3a13957aa250ff5b5409b8ed756b113544112:
> 
>   Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 (2012-06-20 20:11:36 -0600)
> 
> ----------------------------------------------------------------
> 
> Some OMAP hwmod, clock, and System Control Module cleanup patches for 3.6.
> 
> ----------------------------------------------------------------

Merging into cleanup-hwmod and merging into l-o master for testing.

Tony

your mail

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [120621 11:31]:
> Hi Tony
> 
> The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71:
> 
>   Linux 3.5-rc3 (2012-06-16 17:25:17 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.6
> 
> for you to fetch changes up to 07b3a13957aa250ff5b5409b8ed756b113544112:
> 
>   Merge branches 'clock_cleanup_misc_3.6', 'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6 (2012-06-20 20:11:36 -0600)
> 
> ----------------------------------------------------------------
> 
> Some OMAP hwmod, clock, and System Control Module cleanup patches for 3.6.
> 
> ----------------------------------------------------------------

Merging into cleanup-hwmod and merging into l-o master for testing.

Tony

Re: your mail

[Marcus Karlsson]

On Sun, May 06, 2012 at 10:17:07PM +0800, Bruce Zu wrote:
> I want subscribe this git mail list
> thanks!
> Bruce Zu

Great idea. The instructions for how to subscribe can be found on
http://vger.kernel.org/. Then subscribe to the list named 'git'.

	Marcus

Re: your mail

[Chris Mason]

On Thu, Mar 01, 2012 at 01:58:14PM +0100, David Sterba wrote:
> On Thu, Mar 01, 2012 at 04:41:02AM -0800, bella tk wrote:
> > I want to use btrfs defrag tool but before that i want to know how
> > much the disk is fragmented. I have tried to use filefrag but it gives
> > me FIBMAP:invalid argument for many times.
> 
> The only way to trigger FIBMAP on btrfs is to run filefrag with -B
> option, but it should use FIEMAP by default and it works. With -v option
> it'll list all extents.

We actually disabled bmap to keep the swap code from remembering fixed
offsets for btrfs files.  The only way to get the mapping is with
fiemap.

The defrag ioctl won't bother defragging files that are not fragmented.

-chris

Re: your mail

[David Sterba]

On Thu, Mar 01, 2012 at 04:41:02AM -0800, bella tk wrote:
> I want to use btrfs defrag tool but before that i want to know how
> much the disk is fragmented. I have tried to use filefrag but it gives
> me FIBMAP:invalid argument for many times.

The only way to trigger FIBMAP on btrfs is to run filefrag with -B
option, but it should use FIEMAP by default and it works. With -v option
it'll list all extents.

> I am using e2fsprogs version 1.42 on debian squeeze. Is there another
> way to find out the level of fragmentation on btrfs filesystem?

For while filesystem fragmentation, you can use the btrfs-filefrags
too that Arne sent to the list some time ago.

If you're interested in file level fragmentation, then filefrag is the
tool to use, but beware that just counting extents is not enough, and
compression makes things more complicated to interpret results
correctly.

Also, defragmentation does unCOW the files (until the snapshot aware
defrag is finished).


david

Re: your mail

[Hans J. Koch]

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

Re: your mail

[Jiri Slaby]

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

Re: your mail

[Jiri Slaby]

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

Re: your mail

[Al Viro]

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

Re: your mail

[Al Viro]

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

Re: your mail

[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

Re: your mail

[Al Viro]

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?

Re: your mail

[Jesper Juhl]

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.

Re: your mail

[Maurus Cuelenaere]

Hi Henrik,

Op 25-01-12 14:26, Henrik Rydberg schreef:
> Hi Maurus,
>
>> Subject: [RFC] HID: add Microsoft Touch Mouse driver
>>
>> This patch adds support for the proprietary Microsoft Touch Mouse
>> multitouch protocol.
> Exciting stuff, nice job on the patch too. Please find some initial
> comments inline.
>
>> @@ -0,0 +1,371 @@
>> +/*
>> + *  HID driver for the Microsoft Touch Mouse
>> + *
>> + *  Copyright (c) 2011 Maurus Cuelenaere<mcuelenaere@gmail.com>
>> + *
>> + *
>> + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
>> + *
>> + */
>> +
>> +#include<linux/device.h>
>> +#include<linux/input.h>
>> +#include<linux/hid.h>
>> +#include<linux/module.h>
>> +#include<linux/usb.h>
>> +
>> +#include "hid-ids.h"
>> +
>> +#define MSTM_RAW_DATA_HID_ID		0x27
>> +#define MSTM_RAW_DATA_FOOTER		0x51
>> +
>> +#define MSTM_DATA_WIDTH			15
>> +#define MSTM_DATA_HEIGHT		13
>> +
>> +struct mstm_raw_data_packet {
>> +	__u8 hid_id;
>> +	__u8 data_length;
>> +	__u16 unk1;
>> +	__u8 unk2;
>> +	__u8 footer;
>> +	__u8 timestamp;
>> +	__u8 data[25]; /* milliseconds */
>> +};
> I take it this means you get at most 50 nibbles per transfer?

Correct.

Hmm, looks like that milliseconds comment needs to be on the line above it.

>> +
>> +struct mstm_state {
>> +	bool advance_flag;
>> +	int x;
>> +	int y;
>> +	unsigned char last_timestamp;
>> +	unsigned char data[MSTM_DATA_WIDTH][MSTM_DATA_HEIGHT];
>> +};
> The ability to simply send an "input screen" would be perfect
> here. This device may be on the border of what can/should be handled
> via input events. A memory mapped driver, uio-based or something
> similar, could be an option.

In my first tests, I was doing readouts in userspace using hidraw, which 
performed quite well.

Bandwidth could be an issue, but I'd like to use the current APIs as 
much as possible so I don't need to go modifying mtdev, X, ...

>> +
>> +struct mstm_device {
>> +	struct input_dev *input;
>> +
>> +	struct mstm_state state;
>> +};
>> +
>> +#define MSTM_INTERFACE_KEYBOARD		0
>> +#define MSTM_INTERFACE_MOUSE		1
>> +#define MSTM_INTERFACE_CONTROL		2
>> +
>> +static inline int hid_get_interface_number(struct hid_device *hdev) {
>> +	struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
>> +	return intf->cur_altsetting->desc.bInterfaceNumber;
>> +}
>> +
>> +/*
>> + * The mouse sensor only yields data for a specific part of its surface.
>> + * Because of this, we can't just increase x and y uniformly; so there's
>> + * a need for this simple algorithm.
>> + *
>> + * Visual representation of available data:
>> + *    0 1 2 3 4 5 6 7 8 9 A B C D E F
>> + *  0       * * * * * * * * * *
>> + *  1     * * * * * * * * * * * *
>> + *  2   * * * * * * * * * * * * * *
>> + *  3   * * * * * * * * * * * * * *
>> + *  4 * * * * * * * * * * * * * * * *
>> + *  5 * * * * * * * * * * * * * * * *
>> + *  6 * * * * * * * * * * * * * * * *
>> + *  7 * * * * * * * * * * * * * * * *
>> + *  8 * * * * * * * * * * * * * * * *
>> + *  9 * * * * * * * * * * * * * * * *
>> + *  A * * * * * * * * * * * * * * * *
>> + *  B * * * * * * * * * * * * * * * *
>> + *  C * * * * * * * * * * * * * * * *
>> + *  D * * * * * * * * * * * * * * * *
>> + */
>> +static void mstm_advance_pointer(struct mstm_state *state)
>> +{
>> +	int max, nextMin;
>> +
>> +	state->x++;
>> +
>> +	switch (state->y) {
>> +	case 0:
>> +		max = 11;
>> +		nextMin = 2;
>> +		break;
>> +	case 1:
>> +		max = 12;
>> +		nextMin = 1;
>> +		break;
>> +	case 2:
>> +		max = 13;
>> +		nextMin = 1;
>> +		break;
>> +	case 3:
>> +		max = 13;
>> +		nextMin = 0;
>> +		break;
>> +	default:
>> +		max = 14;
>> +		nextMin = 0;
>> +		break;
>> +	}
>> +
>> +	if (state->x>  max) {
>> +		state->y++;
>> +		state->x = nextMin;
>> +	}
>> +}
>> +
>> +static void mstm_parse_nibble(struct mstm_state *state, __u8 nibble)
>> +{
>> +	int i;
>> +
>> +	if (state->advance_flag) {
>> +		state->advance_flag = false;
>> +		for (i = -3; i<  nibble; i++)
>> +			mstm_advance_pointer(state);
>> +	} else {
>> +		if (nibble == 0xF) {
>> +			/* The next nibble will indicate how many
>> +			* positions to advance, so set a flag */
>> +			state->advance_flag = true;
>> +		} else {
>> +			state->data[state->x][state->y] = nibble;
>> +			mstm_advance_pointer(state);
>> +		}
>> +	}
>> +}
> Looking good.
>
>> +static void mstm_push_data(struct hid_device *hdev)
>> +{
>> +	struct mstm_device *mstm_dev = hid_get_drvdata(hdev);
>> +	struct input_dev *input = mstm_dev->input;
>> +	int x, y;
>> +
>> +	for (x = 0; x<  MSTM_DATA_WIDTH; x++) {
>> +		for (y = 0; y<  MSTM_DATA_HEIGHT; y++) {
>> +			unsigned char pressure = mstm_dev->state.data[x][y];
>> +			if (pressure>  0) {
>> +				//input_report_abs(input, ABS_MT_BLOB_ID, 1);
>> +				//input_report_abs(input, ABS_MT_TOUCH_MAJOR, pressure/3);
>> +				input_report_abs(input, ABS_MT_POSITION_X, x);
>> +				input_report_abs(input, ABS_MT_POSITION_Y, y);
>> +				input_mt_sync(input);
>> +			}
>> +		}
>> +	}
> True, the blob id has not yet been used, but its definition is
> different from how it is used here. Also, since you do not attempt any
> kind of clustering (single-linkage or similar), the blob as stated
> might not even be connected.

Indeed, without clustering the BLOB_ID would be useless but that line 
was only for testing with one finger.

> One possible option could be to use the
> slots, but only send ABS_MT_TOUCH_MAJOR or ABS_MT_PRESSURE, nothing
> else. The device would (rightfully) not be recognized as MT since the
> position is missing, all data would be available for processing in
> userspace, and bandwidth would be minimized since there could only be
> so many changes coming in per millisecond.

So how does userspace then finds out where these pressure points are 
located?
Or do you mean to just dump all data to user space (15 * 13 * 
sizeof(ABS_MT_PRESSURE value) + overhead)?

>> +static int mstm_input_mapping(struct hid_device *hdev,
>> +		struct hid_input *hi, struct hid_field *field,
>> +		struct hid_usage *usage, unsigned long **bit, int *max)
>> +{
>> +	struct mstm_device *mstm_dev = hid_get_drvdata(hdev);
>> +
>> +	//printk("mstm_input_mapping(%p)\n", hdev);
>> +
>> +	/* bail early if not the correct interface */
>> +	if (mstm_dev == NULL)
>> +		return 0;
>> +
>> +	/* HACK: get rid of ABS_MT_* params */
>> +	if ((usage->hid&  HID_USAGE_PAGE) == HID_UP_GENDESK)
>> +		return -1;
> I am not sure about the hack here, nor its explanation. ;-)

The HID tables specify some ABS_MT_* values and I didn't know whether 
these were going to conflict with the ones I report above, so I just 
discard all GenericDesktop fields.

root@hp4530s:~# grep MT /sys/kernel/debug/hid/0003\:045E\:0773.0006/rdesc
GenericDesktop.MultiAxis ---> Absolute.MTMajor
GenericDesktop.0009 ---> Absolute.MTMinor
GenericDesktop.000a ---> Absolute.MTMajorW
GenericDesktop.000b ---> Absolute.MTMinorW
GenericDesktop.000c ---> Absolute.MTOrientation
GenericDesktop.000d ---> Absolute.MTPositionX
GenericDesktop.000e ---> Absolute.MTPositionY
GenericDesktop.000f ---> Absolute.MTToolType
GenericDesktop.0010 ---> Absolute.MTBlobID

>> +
>> +	/* map input device to hid device */
>> +	mstm_dev->input = hi->input;
>> +
>> +	return 0;
>> +}
>> +
>> +static void mstm_setup_input(struct mstm_device *mstm)
>> +{
>> +	__set_bit(EV_ABS, mstm->input->evbit);
>> +
>> +	input_set_abs_params(mstm->input, ABS_MT_POSITION_X, 0, MSTM_DATA_WIDTH, 0, 0);
>> +	input_set_abs_params(mstm->input, ABS_MT_POSITION_Y, 0, MSTM_DATA_HEIGHT, 0, 0);
>> +	input_set_abs_params(mstm->input, ABS_MT_TOUCH_MAJOR, 0, 0xF, 0, 0);
>> +	input_set_abs_params(mstm->input, ABS_MT_BLOB_ID, 0, 10, 0, 0);
>> +
>> +	input_abs_set_res(mstm->input, ABS_MT_POSITION_X, 6); /* 83mm */
>> +	input_abs_set_res(mstm->input, ABS_MT_POSITION_Y, 5); /* 70mm */
>> +
>> +	input_set_events_per_packet(mstm->input, 60);
>> +}
> Regarding the resolution of touch major, it is generally assumed (in
> userspace) that the units are the same as the position, so scaling in
> the driver is reasonable. Otherwise, why not specify resolution for
> touch major as well?

I didn't specify it because other HID drivers only specified resolutions 
for POSITION_{X,Y}, I'll try it and see how mtview reacts.

Thanks for the review!

-- 
Maurus Cuelenaere

Re: your mail

[Henrik Rydberg]

Hi Maurus,

> Subject: [RFC] HID: add Microsoft Touch Mouse driver
> 
> This patch adds support for the proprietary Microsoft Touch Mouse
> multitouch protocol.

Exciting stuff, nice job on the patch too. Please find some initial
comments inline.

> @@ -0,0 +1,371 @@
> +/*
> + *  HID driver for the Microsoft Touch Mouse
> + *
> + *  Copyright (c) 2011 Maurus Cuelenaere <mcuelenaere@gmail.com>
> + *
> + *
> + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + */
> +
> +#include <linux/device.h>
> +#include <linux/input.h>
> +#include <linux/hid.h>
> +#include <linux/module.h>
> +#include <linux/usb.h>
> +
> +#include "hid-ids.h"
> +
> +#define MSTM_RAW_DATA_HID_ID		0x27
> +#define MSTM_RAW_DATA_FOOTER		0x51
> +
> +#define MSTM_DATA_WIDTH			15
> +#define MSTM_DATA_HEIGHT		13
> +
> +struct mstm_raw_data_packet {
> +	__u8 hid_id;
> +	__u8 data_length;
> +	__u16 unk1;
> +	__u8 unk2;
> +	__u8 footer;
> +	__u8 timestamp;
> +	__u8 data[25]; /* milliseconds */
> +};

I take it this means you get at most 50 nibbles per transfer?

> +
> +struct mstm_state {
> +	bool advance_flag;
> +	int x;
> +	int y;
> +	unsigned char last_timestamp;
> +	unsigned char data[MSTM_DATA_WIDTH][MSTM_DATA_HEIGHT];
> +};

The ability to simply send an "input screen" would be perfect
here. This device may be on the border of what can/should be handled
via input events. A memory mapped driver, uio-based or something
similar, could be an option.

> +
> +struct mstm_device {
> +	struct input_dev *input;
> +
> +	struct mstm_state state;
> +};
> +
> +#define MSTM_INTERFACE_KEYBOARD		0
> +#define MSTM_INTERFACE_MOUSE		1
> +#define MSTM_INTERFACE_CONTROL		2
> +
> +static inline int hid_get_interface_number(struct hid_device *hdev) {
> +	struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
> +	return intf->cur_altsetting->desc.bInterfaceNumber;
> +}
> +
> +/*
> + * The mouse sensor only yields data for a specific part of its surface.
> + * Because of this, we can't just increase x and y uniformly; so there's
> + * a need for this simple algorithm.
> + *
> + * Visual representation of available data:
> + *    0 1 2 3 4 5 6 7 8 9 A B C D E F
> + *  0       * * * * * * * * * *
> + *  1     * * * * * * * * * * * *
> + *  2   * * * * * * * * * * * * * *
> + *  3   * * * * * * * * * * * * * *
> + *  4 * * * * * * * * * * * * * * * *
> + *  5 * * * * * * * * * * * * * * * *
> + *  6 * * * * * * * * * * * * * * * *
> + *  7 * * * * * * * * * * * * * * * *
> + *  8 * * * * * * * * * * * * * * * *
> + *  9 * * * * * * * * * * * * * * * *
> + *  A * * * * * * * * * * * * * * * *
> + *  B * * * * * * * * * * * * * * * *
> + *  C * * * * * * * * * * * * * * * *
> + *  D * * * * * * * * * * * * * * * *
> + */
> +static void mstm_advance_pointer(struct mstm_state *state)
> +{
> +	int max, nextMin;
> +
> +	state->x++;
> +
> +	switch (state->y) {
> +	case 0:
> +		max = 11;
> +		nextMin = 2;
> +		break;
> +	case 1:
> +		max = 12;
> +		nextMin = 1;
> +		break;
> +	case 2:
> +		max = 13;
> +		nextMin = 1;
> +		break;
> +	case 3:
> +		max = 13;
> +		nextMin = 0;
> +		break;
> +	default:
> +		max = 14;
> +		nextMin = 0;
> +		break;
> +	}
> +
> +	if (state->x > max) {
> +		state->y++;
> +		state->x = nextMin;
> +	}
> +}
> +
> +static void mstm_parse_nibble(struct mstm_state *state, __u8 nibble)
> +{
> +	int i;
> +
> +	if (state->advance_flag) {
> +		state->advance_flag = false;
> +		for (i = -3; i < nibble; i++)
> +			mstm_advance_pointer(state);
> +	} else {
> +		if (nibble == 0xF) {
> +			/* The next nibble will indicate how many
> +			* positions to advance, so set a flag */
> +			state->advance_flag = true;
> +		} else {
> +			state->data[state->x][state->y] = nibble;
> +			mstm_advance_pointer(state);
> +		}
> +	}
> +}

Looking good.

> +static void mstm_push_data(struct hid_device *hdev)
> +{
> +	struct mstm_device *mstm_dev = hid_get_drvdata(hdev);
> +	struct input_dev *input = mstm_dev->input;
> +	int x, y;
> +
> +	for (x = 0; x < MSTM_DATA_WIDTH; x++) {
> +		for (y = 0; y < MSTM_DATA_HEIGHT; y++) {
> +			unsigned char pressure = mstm_dev->state.data[x][y];
> +			if (pressure > 0) {
> +				//input_report_abs(input, ABS_MT_BLOB_ID, 1);
> +				//input_report_abs(input, ABS_MT_TOUCH_MAJOR, pressure/3);
> +				input_report_abs(input, ABS_MT_POSITION_X, x);
> +				input_report_abs(input, ABS_MT_POSITION_Y, y);
> +				input_mt_sync(input);
> +			}
> +		}
> +	}

True, the blob id has not yet been used, but its definition is
different from how it is used here. Also, since you do not attempt any
kind of clustering (single-linkage or similar), the blob as stated
might not even be connected. One possible option could be to use the
slots, but only send ABS_MT_TOUCH_MAJOR or ABS_MT_PRESSURE, nothing
else. The device would (rightfully) not be recognized as MT since the
position is missing, all data would be available for processing in
userspace, and bandwidth would be minimized since there could only be
so many changes coming in per millisecond.

> +static int mstm_input_mapping(struct hid_device *hdev,
> +		struct hid_input *hi, struct hid_field *field,
> +		struct hid_usage *usage, unsigned long **bit, int *max)
> +{
> +	struct mstm_device *mstm_dev = hid_get_drvdata(hdev);
> +
> +	//printk("mstm_input_mapping(%p)\n", hdev);
> +
> +	/* bail early if not the correct interface */
> +	if (mstm_dev == NULL)
> +		return 0;
> +
> +	/* HACK: get rid of ABS_MT_* params */
> +	if ((usage->hid & HID_USAGE_PAGE) == HID_UP_GENDESK)
> +		return -1;

I am not sure about the hack here, nor its explanation. ;-)

> +
> +	/* map input device to hid device */
> +	mstm_dev->input = hi->input;
> +
> +	return 0;
> +}
> +
> +static void mstm_setup_input(struct mstm_device *mstm)
> +{
> +	__set_bit(EV_ABS, mstm->input->evbit);
> +
> +	input_set_abs_params(mstm->input, ABS_MT_POSITION_X, 0, MSTM_DATA_WIDTH, 0, 0);
> +	input_set_abs_params(mstm->input, ABS_MT_POSITION_Y, 0, MSTM_DATA_HEIGHT, 0, 0);
> +	input_set_abs_params(mstm->input, ABS_MT_TOUCH_MAJOR, 0, 0xF, 0, 0);
> +	input_set_abs_params(mstm->input, ABS_MT_BLOB_ID, 0, 10, 0, 0);
> +
> +	input_abs_set_res(mstm->input, ABS_MT_POSITION_X, 6); /* 83mm */
> +	input_abs_set_res(mstm->input, ABS_MT_POSITION_Y, 5); /* 70mm */
> +
> +	input_set_events_per_packet(mstm->input, 60);
> +}

Regarding the resolution of touch major, it is generally assumed (in
userspace) that the units are the same as the position, so scaling in
the driver is reasonable. Otherwise, why not specify resolution for
touch major as well?

Thanks,
Henrik

Re: your mail

[Dmitry Torokhov]

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

your mail

[Will Deacon]

Hmmm,

On Fri, Dec 02, 2011 at 04:01:13PM +0000, Will Deacon wrote:
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Not that there's a lot to ignore, but please ignore this empty mail. For
some reason, my box decided to tell the world nothing.

Sorry for the spam,

Will (thinks it's time for a reboot...)

Re: your mail

[Tony Breeds]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

On Wed, Nov 23, 2011 at 10:42:45AM +1100, Tony Breeds wrote:
> From 1a44c074e3ce572cbf60d31ac704e6ce42be4708 Mon Sep 17 00:00:00 2001
> From: Tony Breeds <tony@bakeyournoodle.com>
> Date: Wed, 23 Nov 2011 10:16:40 +1100
> Subject: [PATCH] powerpc: 44x: Add mtd ndfc to the ppx44x defconfig

Sorry all for the SPAM.  I screwed up trying to use mutt and git to
send-email

Yours Tony

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: your mail

[Joe Thornber]

On Wed, Oct 19, 2011 at 08:17:37PM -0400, Mikulas Patocka wrote:
> Hi
> 
> Here I'm sending two dm-bufio patches. The first one fixed 
> dm_bufio_release_move function (the write callback could be called with a 
> wrong block number). The next one adds a conditional resched (Alasdair 
> agreed on it --- it should be later put into general Linux headers).

Thanks Mikulas, merging now.

- Joe

Re: your mail

[Alasdair G Kergon]

On Wed, Oct 19, 2011 at 08:17:37PM -0400, Mikulas Patocka wrote:
> The next one adds a conditional resched (Alasdair 
> agreed on it --- it should be later put into general Linux headers).
 
Indeed, this part:

> +#ifdef CONFIG_PREEMPT_VOLUNTARY
> +#define dm_bufio_cond_resched()                	\
> +do {						\
> +	if (unlikely(need_resched()))		\
> +		_cond_resched();		\
> +} while (0)
> +#else
> +#define dm_bufio_cond_resched()                do { } while (0)
> +#endif

doesn't really belong in a dm file.

Alasdair

Re: your mail

[Greg KH]

On Wed, Sep 21, 2011 at 03:54:49PM -0600, jim.cromie@gmail.com wrote:
> hi all,
> 
> this reworked* patchset enhances dynamic-debug with:

I need acks from Jason before I can apply any of this...

Re: your mail

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

   [Your Reply-to: header was screwed up, so I'm sending this again.

From: Ken D'Ambrosio <ken@jots.org>
Reply-to: File's@jots.org, checksum?@jots.org

]

On Tue, Sep 20, 2011 at 04:35:40PM +0100, Hugo Mills wrote:
> On Tue, Sep 20, 2011 at 11:24:30AM -0400, Ken D'Ambrosio wrote:
> > Just wondering if/how one goes about getting the btrfs checksum of a given
> > file.  Is there a way?
> 
>    Checksums are computed on individual 4k blocks, not on the whole
> file. There's no explicit interface for retrieving checksums, but if
> you understand the data structures, you can get hold of the checksums
> for a file using the BTRFS_IOC_TREE_SEARCH ioctl.
> 
>    Hugo.
> 

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- "How deep will this sub go?" "Oh,  she'll go all the way to ---   
                    the bottom if we don't stop her."                    

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: your mail

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

On Tue, Sep 20, 2011 at 11:24:30AM -0400, Ken D'Ambrosio wrote:
> Just wondering if/how one goes about getting the btrfs checksum of a given
> file.  Is there a way?

   Checksums are computed on individual 4k blocks, not on the whole
file. There's no explicit interface for retrieving checksums, but if
you understand the data structures, you can get hold of the checksums
for a file using the BTRFS_IOC_TREE_SEARCH ioctl.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- "How deep will this sub go?" "Oh,  she'll go all the way to ---   
                    the bottom if we don't stop her."                    

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: your mail

[Jozsef Kadlecsik]

On Wed, 31 Aug 2011, Jan Engelhardt wrote:

> On Wednesday 2011-08-31 14:49, Jozsef Kadlecsik wrote:
> 
> >On Wed, 31 Aug 2011, Jan Engelhardt wrote:
> >
> >> On Wednesday 2011-08-31 14:16, Jozsef Kadlecsik wrote:
> >> 
> >> >On Wed, 31 Aug 2011, Jan Engelhardt wrote:
> >> >
> >> >> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
> >> >> 
> >> >> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
> >> >> >
> >> >> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
> >> >> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
> >> >> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
> >> >> >
> >> >> >After rewieving your patches, I don't get it: what userspace tool would 
> >> >> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
> >> >> >definitely not use it and ipset either. So why your patches are 
> >> >> >required?
> >> >> 
> >> >> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which 
> >> >> #includes ip_set.h to get at the definition of ip_set.h.
> >> >> Patch will be resent.
> >> >
> >> >iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and 
> >> >xt_set.h includes nothing.
> >> 
> >> 14:44 seven:../linux/netfilter > git show v3.0:include/linux/netfilter/xt_set.h | grep includ
> >> #include <linux/types.h>
> >> #include <linux/netfilter/ipset/ip_set.h>
> >
> >This is the kernel source tree. You wrote about libxt_SET.c and userspace:
> >
> >kadlec@mentat:/usr/src/git/iptables$ rgrep ip_set.h *
> >kadlec@mentat:/usr/src/git/iptables$ 
> 
> Of course the header files in the iptables source tree come from the 
> (sanitized) kernel headers, and time and again, new copies from the 
> kernel are brought into the iptables tree.
> 
> (Cf. commits b4af04be14560b3fcc6cf23200148d408014a2f5, 
> 350661a6eb089f3e54e67e022db9e16ea280499f, 
> 978e27e8f8c2e49d0528c6c4ae3a56627fbe8492, 
> e0bba47e550420e371c97425cc6d39909a6e059b, and possibly more in the 
> past.)

Then I'm going to apply your patches. After that some more work is 
required from me, because ipset userspace assumes those parts to be 
excluded by #ifdef __KERNEL__.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: your mail

[Jan Engelhardt]

On Wednesday 2011-08-31 14:49, Jozsef Kadlecsik wrote:

>On Wed, 31 Aug 2011, Jan Engelhardt wrote:
>
>> On Wednesday 2011-08-31 14:16, Jozsef Kadlecsik wrote:
>> 
>> >On Wed, 31 Aug 2011, Jan Engelhardt wrote:
>> >
>> >> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
>> >> 
>> >> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
>> >> >
>> >> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
>> >> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
>> >> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
>> >> >
>> >> >After rewieving your patches, I don't get it: what userspace tool would 
>> >> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
>> >> >definitely not use it and ipset either. So why your patches are 
>> >> >required?
>> >> 
>> >> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which 
>> >> #includes ip_set.h to get at the definition of ip_set.h.
>> >> Patch will be resent.
>> >
>> >iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and 
>> >xt_set.h includes nothing.
>> 
>> 14:44 seven:../linux/netfilter > git show v3.0:include/linux/netfilter/xt_set.h | grep includ
>> #include <linux/types.h>
>> #include <linux/netfilter/ipset/ip_set.h>
>
>This is the kernel source tree. You wrote about libxt_SET.c and userspace:
>
>kadlec@mentat:/usr/src/git/iptables$ rgrep ip_set.h *
>kadlec@mentat:/usr/src/git/iptables$ 

Of course the header files in the iptables source tree come from the 
(sanitized) kernel headers, and time and again, new copies from the 
kernel are brought into the iptables tree.

(Cf. commits b4af04be14560b3fcc6cf23200148d408014a2f5, 
350661a6eb089f3e54e67e022db9e16ea280499f, 
978e27e8f8c2e49d0528c6c4ae3a56627fbe8492, 
e0bba47e550420e371c97425cc6d39909a6e059b, and possibly more in the 
past.)

Re: your mail

[Jozsef Kadlecsik]

On Wed, 31 Aug 2011, Jan Engelhardt wrote:

> On Wednesday 2011-08-31 14:16, Jozsef Kadlecsik wrote:
> 
> >On Wed, 31 Aug 2011, Jan Engelhardt wrote:
> >
> >> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
> >> 
> >> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
> >> >
> >> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
> >> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
> >> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
> >> >
> >> >After rewieving your patches, I don't get it: what userspace tool would 
> >> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
> >> >definitely not use it and ipset either. So why your patches are 
> >> >required?
> >> 
> >> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which 
> >> #includes ip_set.h to get at the definition of ip_set.h.
> >> Patch will be resent.
> >
> >iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and 
> >xt_set.h includes nothing.
> 
> 14:44 seven:../linux/netfilter > git show v3.0:include/linux/netfilter/xt_set.h | grep includ
> #include <linux/types.h>
> #include <linux/netfilter/ipset/ip_set.h>

This is the kernel source tree. You wrote about libxt_SET.c and userspace:

kadlec@mentat:/usr/src/git/iptables$ rgrep ip_set.h *
kadlec@mentat:/usr/src/git/iptables$ 

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: your mail

[Jan Engelhardt]

On Wednesday 2011-08-31 14:16, Jozsef Kadlecsik wrote:

>On Wed, 31 Aug 2011, Jan Engelhardt wrote:
>
>> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
>> 
>> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
>> >
>> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
>> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
>> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
>> >
>> >After rewieving your patches, I don't get it: what userspace tool would 
>> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
>> >definitely not use it and ipset either. So why your patches are 
>> >required?
>> 
>> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which 
>> #includes ip_set.h to get at the definition of ip_set.h.
>> Patch will be resent.
>
>iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and 
>xt_set.h includes nothing.

14:44 seven:../linux/netfilter > git show v3.0:include/linux/netfilter/xt_set.h | grep includ
#include <linux/types.h>
#include <linux/netfilter/ipset/ip_set.h>

Re: your mail

[Jozsef Kadlecsik]

On Wed, 31 Aug 2011, Jan Engelhardt wrote:

> On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:
> 
> >On Sun, 28 Aug 2011, Jan Engelhardt wrote:
> >
> >> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
> >> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
> >> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
> >
> >After rewieving your patches, I don't get it: what userspace tool would 
> >use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
> >definitely not use it and ipset either. So why your patches are 
> >required?
> 
> iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which 
> #includes ip_set.h to get at the definition of ip_set.h.
> Patch will be resent.

iptables/extensions/libxt_SET.c includes <linux/netfilter/xt_set.h> and 
xt_set.h includes nothing.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: your mail

[Jan Engelhardt]

On Wednesday 2011-08-31 13:56, Jozsef Kadlecsik wrote:

>Hi Jan,
>
>On Sun, 28 Aug 2011, Jan Engelhardt wrote:
>
>> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
>> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
>> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)
>
>After rewieving your patches, I don't get it: what userspace tool would 
>use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
>definitely not use it and ipset either. So why your patches are 
>required?

iptables/extensions/xt_SET.c #includes <netfilter/xt_set.h> which 
#includes ip_set.h to get at the definition of ip_set.h.
Patch will be resent.

Re: your mail

[Jozsef Kadlecsik]

Hi Jan,

On Sun, 28 Aug 2011, Jan Engelhardt wrote:

> libxt_SET.c requires IPSET_INVALID_ID, but this constant has moved into 
> a #ifdef __KERNEL__ section lately and is thus absent from userspace. 
> (In linux-kernel/include/linux/netfilter/ipset/ip_set.h.)

After rewieving your patches, I don't get it: what userspace tool would 
use linux-kernel/include/linux/netfilter/ipset/ip_set.h? iptables does 
definitely not use it and ipset either. So why your patches are 
required?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: your mail

[Alessio Igor Bogani]

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

Re: your mail

[Greg KH]

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

Re: your mail

[Munegowda, Keshava]

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

Re: your mail

[Felipe Balbi]

[-- 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 --]

your mail

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:35 Fri 13 May     , Vadim Bendebury wrote:
> >From 8ed0ea5fcf5552ca3307611b685b4518794eca41 Mon Sep 17 00:00:00 2001
> From: Vadim Bendebury <vbendeb@chromium.org>
> Date: Wed, 11 May 2011 17:31:40 -0700
> Subject: [PATCH 1/1] ARM: thumb: Have the machine name indicate operation in thumb mode.
> 
> This is a cosmetic change, adding a '_thumb' prefix to the
> 'Hardware' line in /proc/cpuinfo. Tested as follows:
I do think is the right place or right way to do so

I think we need to create a sysfs entry to allow machine to more information

Best Regards,
J.

Re: your mail

[Jan Kara]

On Tue 03-05-11 18:43:48, Surbhi Palande wrote:
> On 05/03/2011 06:36 PM, Jan Kara wrote:
> >On Tue 03-05-11 16:56:57, Surbhi Palande wrote:
> >>On 05/03/2011 04:46 PM, Jan Kara wrote:
> >>>On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
> >>
> >>Sorry for missing the subject line :(
> >>>>On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
> >>>>Toshiyuki pointed out.
> >>>>
> >>>>zap_pte_range()
> >>>>   mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
> >>>>
> >>>>So, I think that it is here that we should do the checking for a ext4 F.S
> >>>>frozen state and also prevent a parallel ext4 F.S freeze from happening.
> >>>>
> >>>>Attaching a patch for initial review. Please do let me know your thoughts!
> >>>   This is definitely the wrong place. ->set_page_dirty() callbacks are
> >>>called with various locks held and the page need not be locked (thus
> >>>dereferencing page->mapping is oopsable). Moreover this particular callback
> >>>is called only in data=journal mode.
> >>Ok! Thanks for that!
> >>
> >>>
> >>>Believe me, the right place is page_mkwrite() - you have to catch the
> >>>read-only =>   read-write page transition. Once the page is mapped
> >>>read-write, you've already lost the race.
> >>
> >>My only point is:
> >>1) something should prevent the freeze from happening. We cant
> >>merely check the vfs_check_frozen()?
> >   Yes, I agree - see my other email with patches.
> >
> >>And this should be done where the page is marked dirty.Also, I
> >>thought that the page is marked read-write only in the page table in
> >>the __do_page_fault()? i.e the zap_pte_range() marks them dirty in
> >>the page cache? Is this understanding right?
> >   The page can become dirty either because it was written via standard
> >write - write_begin is responsible for reliable check here - or it was
> >written via mmap - here we rely on page_mkwrite to do a reliable check -
> >it is analogous to write_begin callback. There should be no other way
> >to dirty a page.
> >
> >With dirty bits it is a bit complicated. We have two of them in fact. One
> >in page table entry maintained by mmu and one in page structure maintained
> >by kernel. Some functions (such as zap_pte_range()) copy the dirty bits
> >from page table into struct page. This is a lazy process so page can in
> >principle have new data without a dirty bit set in struct page because we
> >have not yet copied the dirty bit from page table. Only at moments where it
> >is important (like when we want to unmap the page, or throw away the page,
> >or so), we make sure struct page and page table bits are in sync.
> >
> >Another subtle thing you need not be aware of it that when we clear page
> >dirty bit, we also writeprotect the page. So we are guaranteed to get a
> >page fault when the page is written to again.
> >
> >>IMHO, whatever code dirties the page in the page cache should call a
> >>F.S specific function and let it _prevent_ a fsfreeze while the page
> >>is getting dirtied, so that a freeze called after this point flushes
> >>this page!
> >   Agreed, that's what code in write_begin() and page_mkwrite() should
> >achieve.
> >								Honza
> Thanks a lot for the wonderful explanation :)
> 
> How about the revert : i.e calling  jbd2_journal_unlock_updates()
> from ext4_unfreeze() instead of the ext4_freeze()? Do you agree to
> that?
  Sorry, I don't agree with revert. We could talk about changing
jbd2_journal_unlock_updates() to not return with mutex held (and handle
synchronization of locked journal operations differently) as an alternative
to doing "freeze" reference counting. But returning with mutex held to user
space is no-go. It will cause problems in lockdep, violates kernel locking
rules, and generally is a bad programming ;).

								Honza

-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: your mail

[Surbhi Palande]

On 05/03/2011 06:36 PM, Jan Kara wrote:
> On Tue 03-05-11 16:56:57, Surbhi Palande wrote:
>> On 05/03/2011 04:46 PM, Jan Kara wrote:
>>> On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
>>
>> Sorry for missing the subject line :(
>>>> On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
>>>> Toshiyuki pointed out.
>>>>
>>>> zap_pte_range()
>>>>    mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
>>>>
>>>> So, I think that it is here that we should do the checking for a ext4 F.S
>>>> frozen state and also prevent a parallel ext4 F.S freeze from happening.
>>>>
>>>> Attaching a patch for initial review. Please do let me know your thoughts!
>>>    This is definitely the wrong place. ->set_page_dirty() callbacks are
>>> called with various locks held and the page need not be locked (thus
>>> dereferencing page->mapping is oopsable). Moreover this particular callback
>>> is called only in data=journal mode.
>> Ok! Thanks for that!
>>
>>>
>>> Believe me, the right place is page_mkwrite() - you have to catch the
>>> read-only =>   read-write page transition. Once the page is mapped
>>> read-write, you've already lost the race.
>>
>> My only point is:
>> 1) something should prevent the freeze from happening. We cant
>> merely check the vfs_check_frozen()?
>    Yes, I agree - see my other email with patches.
>
>> And this should be done where the page is marked dirty.Also, I
>> thought that the page is marked read-write only in the page table in
>> the __do_page_fault()? i.e the zap_pte_range() marks them dirty in
>> the page cache? Is this understanding right?
>    The page can become dirty either because it was written via standard
> write - write_begin is responsible for reliable check here - or it was
> written via mmap - here we rely on page_mkwrite to do a reliable check -
> it is analogous to write_begin callback. There should be no other way
> to dirty a page.
>
> With dirty bits it is a bit complicated. We have two of them in fact. One
> in page table entry maintained by mmu and one in page structure maintained
> by kernel. Some functions (such as zap_pte_range()) copy the dirty bits
> from page table into struct page. This is a lazy process so page can in
> principle have new data without a dirty bit set in struct page because we
> have not yet copied the dirty bit from page table. Only at moments where it
> is important (like when we want to unmap the page, or throw away the page,
> or so), we make sure struct page and page table bits are in sync.
>
> Another subtle thing you need not be aware of it that when we clear page
> dirty bit, we also writeprotect the page. So we are guaranteed to get a
> page fault when the page is written to again.
>
>> IMHO, whatever code dirties the page in the page cache should call a
>> F.S specific function and let it _prevent_ a fsfreeze while the page
>> is getting dirtied, so that a freeze called after this point flushes
>> this page!
>    Agreed, that's what code in write_begin() and page_mkwrite() should
> achieve.
> 								Honza
Thanks a lot for the wonderful explanation :)

How about the revert : i.e calling  jbd2_journal_unlock_updates() from 
ext4_unfreeze() instead of the ext4_freeze()? Do you agree to that?


Warm Regards,
Surbhi.

Re: your mail

[Jan Kara]

On Tue 03-05-11 16:56:57, Surbhi Palande wrote:
> On 05/03/2011 04:46 PM, Jan Kara wrote:
> >On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
> 
> Sorry for missing the subject line :(
> >>On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
> >>Toshiyuki pointed out.
> >>
> >>zap_pte_range()
> >>   mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
> >>
> >>So, I think that it is here that we should do the checking for a ext4 F.S
> >>frozen state and also prevent a parallel ext4 F.S freeze from happening.
> >>
> >>Attaching a patch for initial review. Please do let me know your thoughts!
> >   This is definitely the wrong place. ->set_page_dirty() callbacks are
> >called with various locks held and the page need not be locked (thus
> >dereferencing page->mapping is oopsable). Moreover this particular callback
> >is called only in data=journal mode.
> Ok! Thanks for that!
> 
> >
> >Believe me, the right place is page_mkwrite() - you have to catch the
> >read-only =>  read-write page transition. Once the page is mapped
> >read-write, you've already lost the race.
> 
> My only point is:
> 1) something should prevent the freeze from happening. We cant
> merely check the vfs_check_frozen()?
  Yes, I agree - see my other email with patches.

> And this should be done where the page is marked dirty.Also, I
> thought that the page is marked read-write only in the page table in
> the __do_page_fault()? i.e the zap_pte_range() marks them dirty in
> the page cache? Is this understanding right?
  The page can become dirty either because it was written via standard
write - write_begin is responsible for reliable check here - or it was
written via mmap - here we rely on page_mkwrite to do a reliable check -
it is analogous to write_begin callback. There should be no other way
to dirty a page.

With dirty bits it is a bit complicated. We have two of them in fact. One
in page table entry maintained by mmu and one in page structure maintained
by kernel. Some functions (such as zap_pte_range()) copy the dirty bits
from page table into struct page. This is a lazy process so page can in
principle have new data without a dirty bit set in struct page because we
have not yet copied the dirty bit from page table. Only at moments where it
is important (like when we want to unmap the page, or throw away the page,
or so), we make sure struct page and page table bits are in sync.

Another subtle thing you need not be aware of it that when we clear page
dirty bit, we also writeprotect the page. So we are guaranteed to get a
page fault when the page is written to again.

> IMHO, whatever code dirties the page in the page cache should call a
> F.S specific function and let it _prevent_ a fsfreeze while the page
> is getting dirtied, so that a freeze called after this point flushes
> this page!
  Agreed, that's what code in write_begin() and page_mkwrite() should
achieve.
								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: your mail

[Surbhi Palande]

On 05/03/2011 04:56 PM, Surbhi Palande wrote:
> On 05/03/2011 04:46 PM, Jan Kara wrote:
>> On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
>
> Sorry for missing the subject line :(
>>> On munmap() zap_pte_range() is called which dirties the PTE dirty
>>> pages as
>>> Toshiyuki pointed out.
>>>
>>> zap_pte_range()
>>> mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
>>>
>>> So, I think that it is here that we should do the checking for a ext4
>>> F.S
>>> frozen state and also prevent a parallel ext4 F.S freeze from happening.
>>>
>>> Attaching a patch for initial review. Please do let me know your
>>> thoughts!
>> This is definitely the wrong place. ->set_page_dirty() callbacks are
>> called with various locks held and the page need not be locked (thus
>> dereferencing page->mapping is oopsable). Moreover this particular
>> callback
>> is called only in data=journal mode.
> Ok! Thanks for that!
>
>>
>> Believe me, the right place is page_mkwrite() - you have to catch the
>> read-only => read-write page transition. Once the page is mapped
>> read-write, you've already lost the race.
Also, we then need to prevent a munmap()/zap_pte_range() call from 
dirtying a mmapped file page when the F.S is frozen?

Warm Regards,
Surbhi.

>
> My only point is:
> 1) something should prevent the freeze from happening. We cant merely
> check the vfs_check_frozen()?
>
> And this should be done where the page is marked dirty.Also, I thought
> that the page is marked read-write only in the page table in the
> __do_page_fault()? i.e the zap_pte_range() marks them dirty in the page
> cache? Is this understanding right?
>
> IMHO, whatever code dirties the page in the page cache should call a F.S
> specific function and let it _prevent_ a fsfreeze while the page is
> getting dirtied, so that a freeze called after this point flushes this
> page!
>
> Warm Regards,
> Surbhi.
>
>
>
>
>
>
>
>
>
>
>>
>> Honza
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: your mail

[Surbhi Palande]

On 05/03/2011 04:46 PM, Jan Kara wrote:
> On Tue 03-05-11 16:08:36, Surbhi Palande wrote:

Sorry for missing the subject line :(
>> On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
>> Toshiyuki pointed out.
>>
>> zap_pte_range()
>>    mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)
>>
>> So, I think that it is here that we should do the checking for a ext4 F.S
>> frozen state and also prevent a parallel ext4 F.S freeze from happening.
>>
>> Attaching a patch for initial review. Please do let me know your thoughts!
>    This is definitely the wrong place. ->set_page_dirty() callbacks are
> called with various locks held and the page need not be locked (thus
> dereferencing page->mapping is oopsable). Moreover this particular callback
> is called only in data=journal mode.
Ok! Thanks for that!

>
> Believe me, the right place is page_mkwrite() - you have to catch the
> read-only =>  read-write page transition. Once the page is mapped
> read-write, you've already lost the race.

My only point is:
1) something should prevent the freeze from happening. We cant merely 
check the vfs_check_frozen()?

And this should be done where the page is marked dirty.Also, I thought 
that the page is marked read-write only in the page table in the 
__do_page_fault()? i.e the zap_pte_range() marks them dirty in the page 
cache? Is this understanding right?

IMHO, whatever code dirties the page in the page cache should call a F.S 
specific function and let it _prevent_ a fsfreeze while the page is 
getting dirtied, so that a freeze called after this point flushes this page!

Warm Regards,
Surbhi.










>
> 								Honza

Re: your mail

[Jan Kara]

On Tue 03-05-11 16:08:36, Surbhi Palande wrote:
> On munmap() zap_pte_range() is called which dirties the PTE dirty pages as
> Toshiyuki pointed out.
> 
> zap_pte_range()
>   mapping->a_ops->set_page_dirty (= ext4_journalled_set_page_dirty)  
> 
> So, I think that it is here that we should do the checking for a ext4 F.S
> frozen state and also prevent a parallel ext4 F.S freeze from happening.
> 
> Attaching a patch for initial review. Please do let me know your thoughts! 
  This is definitely the wrong place. ->set_page_dirty() callbacks are
called with various locks held and the page need not be locked (thus
dereferencing page->mapping is oopsable). Moreover this particular callback
is called only in data=journal mode.

Believe me, the right place is page_mkwrite() - you have to catch the
read-only => read-write page transition. Once the page is mapped
read-write, you've already lost the race.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

RE: your mail

[Hema Kalliguddi]

Hi,

Yes. This was broken patch. My bad... I resent the patch.

Regards,
Hema

>-----Original Message-----
>From: Felipe Balbi [mailto:balbi@ti.com]
>Sent: Wednesday, February 16, 2011 5:26 PM
>To: Hema HK
>Cc: linux-usb@vger.kernel.org; linux-omap@vger.kernel.org; Felipe Balbi
>Subject: Re: your mail
>
>no subject ??
>
>--
>balbi
>

Re: your mail

[Felipe Balbi]

no subject ??

-- 
balbi

Re: your mail

[Felipe Balbi]

no subject ??

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

Re: your mail

[Greg KH]

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

Re: your mail

[Tejun Heo]

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

Re: your mail

[Stanislaw Gruszka]

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

Re: your mail

[Dominik Brodowski]

Hi Raj,

On Sat, Sep 18, 2010 at 11:36:16AM -0400, Alan Stern wrote:
> > I have question regarding the CPU frequency subsystem through which the frequency of the CPU is scaled.
> > 
> > e.g. If we have device driver (X device contains processor) that wants to scale its own processor based
> > 
> > upon the workload, (DVFS driver for this processor is implemented and registered with cpufreq subsystem)
> > 
> > then X device driver when detects waorkload,  Can this X device driver call policy governor APIS for scaling clock or
> > 
> > this X device driver can directly calls DVFS driver APIs directly?

Best would be to register a cpufreq policy notifier,
(cpufreq_register_notifier()), and then call cpufreq_update_policy()
whenever the "X device driver" needs to modify its frequency constraints.

In addition, it would be best to discuss this on the cpufreq mailing list at

cpufreq@vger.kernel.org

Best,
	Dominik

Re: your mail

[Alan Stern]

On Sat, 18 Sep 2010, Raj Kumar wrote:

> Hi Alan,
> 
>  
> 
> I have question regarding the CPU frequency subsystem through which the frequency of the CPU is scaled.
> 
> e.g. If we have device driver (X device contains processor) that wants to scale its own processor based
> 
> upon the workload, (DVFS driver for this processor is implemented and registered with cpufreq subsystem)
> 
> then X device driver when detects waorkload,  Can this X device driver call policy governor APIS for scaling clock or
> 
> this X device driver can directly calls DVFS driver APIs directly?

I don't know.  I have never used cpufreq and I don't know how it works.

> I just want to know from our device driver how do call DVFS driver if DVFS driver is registered with cpu frequency subsystem?

Then you should ask somebody else.

Alan Stern

Re: your mail

[Wu Fengguang]

On Tue, Jun 22, 2010 at 09:54:58PM +0800, Jan Kara wrote:
> On Tue 22-06-10 10:59:41, Wu Fengguang wrote:
> > > - use tagging also for WB_SYNC_NONE writeback - there's problem with an
> > >   interaction with wbc->nr_to_write. If we tag all dirty pages, we can
> > >   spend too much time tagging when we write only a few pages in the end
> > >   because of nr_to_write. If we tag only say nr_to_write pages, we may
> > >   not have enough pages tagged because some pages are written out by
> > >   someone else and so we would have to restart and tagging would become
> > 
> > This could be addressed by ignoring nr_to_write for the WB_SYNC_NONE
> > writeback triggered by sync(). write_cache_pages() already ignored
> > nr_to_write for WB_SYNC_ALL.
>   We could do that but frankly, I'm not very fond of adding more special
> cases to writeback code than strictly necessary...

So do me. However for this case we only need to broaden the special case test:

                        if (nr_to_write > 0) {
                                nr_to_write--;
                                if (nr_to_write == 0 &&
-                                   wbc->sync_mode == WB_SYNC_NONE) {
+                                   !wbc->for_sync) {

> > >   essentially useless. So my option is - switch to tagging for WB_SYNC_NONE
> > >   writeback if we can get rid of nr_to_write. But that's a story for
> > >   a different patch set.
> > 
> > Besides introducing overheads, it will be a policy change in which the
> > system loses control to somehow "throttle" writeback of huge files.
>   Yes, but if we guarantee we cannot livelock on a single file, do we care?
> Memory management does not care because it's getting rid of dirty pages
> which is what it wants. User might care but actually writing out files in
> the order they were dirtied (i.e., the order user written them) is quite
> natural so it's not a "surprising" behavior. And I don't think we can
> assume that data in those small files are more valuable than data in the
> large file and thus should be written earlier...

It could be a surprising behavior when, there is a 4GB dirty file and
100 small dirty files. The user may expect the 100 small dirty files
be synced to disk after 30s. However without nr_to_write, they could
be delayed by the 4GB file for 40 more seconds. Now if something goes
wrong in between and the small dirty files happen to include some
.c/.tex/.txt/... files. 

Small files are more likely your precious documents that are typed in
word-by-word and perhaps the most important data you want to protect.
Naturally you'll want them enjoy more priority than large files.

>   With the overhead you are right that tagging is more expensive than
> checking nr_to_write limit...

Thanks,
Fengguang

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Jan Kara]

On Tue 22-06-10 10:59:41, Wu Fengguang wrote:
> > - use tagging also for WB_SYNC_NONE writeback - there's problem with an
> >   interaction with wbc->nr_to_write. If we tag all dirty pages, we can
> >   spend too much time tagging when we write only a few pages in the end
> >   because of nr_to_write. If we tag only say nr_to_write pages, we may
> >   not have enough pages tagged because some pages are written out by
> >   someone else and so we would have to restart and tagging would become
> 
> This could be addressed by ignoring nr_to_write for the WB_SYNC_NONE
> writeback triggered by sync(). write_cache_pages() already ignored
> nr_to_write for WB_SYNC_ALL.
  We could do that but frankly, I'm not very fond of adding more special
cases to writeback code than strictly necessary...

> >   essentially useless. So my option is - switch to tagging for WB_SYNC_NONE
> >   writeback if we can get rid of nr_to_write. But that's a story for
> >   a different patch set.
> 
> Besides introducing overheads, it will be a policy change in which the
> system loses control to somehow "throttle" writeback of huge files.
  Yes, but if we guarantee we cannot livelock on a single file, do we care?
Memory management does not care because it's getting rid of dirty pages
which is what it wants. User might care but actually writing out files in
the order they were dirtied (i.e., the order user written them) is quite
natural so it's not a "surprising" behavior. And I don't think we can
assume that data in those small files are more valuable than data in the
large file and thus should be written earlier...
  With the overhead you are right that tagging is more expensive than
checking nr_to_write limit...

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: your mail

[Jan Kara]

On Tue 22-06-10 10:59:41, Wu Fengguang wrote:
> > - use tagging also for WB_SYNC_NONE writeback - there's problem with an
> >   interaction with wbc->nr_to_write. If we tag all dirty pages, we can
> >   spend too much time tagging when we write only a few pages in the end
> >   because of nr_to_write. If we tag only say nr_to_write pages, we may
> >   not have enough pages tagged because some pages are written out by
> >   someone else and so we would have to restart and tagging would become
> 
> This could be addressed by ignoring nr_to_write for the WB_SYNC_NONE
> writeback triggered by sync(). write_cache_pages() already ignored
> nr_to_write for WB_SYNC_ALL.
  We could do that but frankly, I'm not very fond of adding more special
cases to writeback code than strictly necessary...

> >   essentially useless. So my option is - switch to tagging for WB_SYNC_NONE
> >   writeback if we can get rid of nr_to_write. But that's a story for
> >   a different patch set.
> 
> Besides introducing overheads, it will be a policy change in which the
> system loses control to somehow "throttle" writeback of huge files.
  Yes, but if we guarantee we cannot livelock on a single file, do we care?
Memory management does not care because it's getting rid of dirty pages
which is what it wants. User might care but actually writing out files in
the order they were dirtied (i.e., the order user written them) is quite
natural so it's not a "surprising" behavior. And I don't think we can
assume that data in those small files are more valuable than data in the
large file and thus should be written earlier...
  With the overhead you are right that tagging is more expensive than
checking nr_to_write limit...

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Wu Fengguang]

> - use tagging also for WB_SYNC_NONE writeback - there's problem with an
>   interaction with wbc->nr_to_write. If we tag all dirty pages, we can
>   spend too much time tagging when we write only a few pages in the end
>   because of nr_to_write. If we tag only say nr_to_write pages, we may
>   not have enough pages tagged because some pages are written out by
>   someone else and so we would have to restart and tagging would become

This could be addressed by ignoring nr_to_write for the WB_SYNC_NONE
writeback triggered by sync(). write_cache_pages() already ignored
nr_to_write for WB_SYNC_ALL.

>   essentially useless. So my option is - switch to tagging for WB_SYNC_NONE
>   writeback if we can get rid of nr_to_write. But that's a story for
>   a different patch set.

Besides introducing overheads, it will be a policy change in which the
system loses control to somehow "throttle" writeback of huge files.

So it may be safer to enlarge nr_to_write instead of canceling it totally.

Thanks,
Fengguang

Re: your mail

[Wu Fengguang]

> - use tagging also for WB_SYNC_NONE writeback - there's problem with an
>   interaction with wbc->nr_to_write. If we tag all dirty pages, we can
>   spend too much time tagging when we write only a few pages in the end
>   because of nr_to_write. If we tag only say nr_to_write pages, we may
>   not have enough pages tagged because some pages are written out by
>   someone else and so we would have to restart and tagging would become

This could be addressed by ignoring nr_to_write for the WB_SYNC_NONE
writeback triggered by sync(). write_cache_pages() already ignored
nr_to_write for WB_SYNC_ALL.

>   essentially useless. So my option is - switch to tagging for WB_SYNC_NONE
>   writeback if we can get rid of nr_to_write. But that's a story for
>   a different patch set.

Besides introducing overheads, it will be a policy change in which the
system loses control to somehow "throttle" writeback of huge files.

So it may be safer to enlarge nr_to_write instead of canceling it totally.

Thanks,
Fengguang

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Greg KH]

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

Re: your mail

[Dave Chinner]

On Wed, Jun 16, 2010 at 06:33:49PM +0200, Jan Kara wrote:
>   Hello,
> 
>   here is the fourth version of the writeback livelock avoidance patches
> for data integrity writes. To quickly summarize the idea: we tag dirty
> pages at the beginning of write_cache_pages with a new TOWRITE tag and
> then write only tagged pages to avoid parallel writers to livelock us.
> See changelogs of the patches for more details.
>   I have tested the patches with fsx and a test program I wrote which
> checks that if we crash after fsync, the data is indeed on disk.
>   If there are no more concerns, can these patches get merged?

Has it been run through xfstests? I'd suggest doing that at least
with XFS as there are several significant sync sanity tests for XFS
in the suite...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

your mail

[Dave Hylands]

HI Jamie,

On Mon, Jun 7, 2010 at 3:10 PM, Jamie Lokier wrote:
> Dave Hylands wrote:
[...]
>> Another way of asking this: If both cores are writing to the same
>> 32-bit word (but different bytes) do the writes collide?
>
> I'm pretty sure any system compatible with pthreads has to be fine
> with the variables being independent, because the bytes could be
> variables protected by separate mutexes.
>
> However, other questions for your lockless structures are whether
> writes by one processor are seen in a reasonable or even bounded time
> by reads on another processor (write buffering), and which barrier
> instructions to use between the index accesses and accessing some
> array they might indexing (only a problem for userspace, because the
> kernel already provides barriers).

After lots of reading - I think that the Snoop Control Unit takes care
of moving the cache lines from one core to the other when both cores
are trying to access data from the same cache line.

So it's not very efficient to have both cores accessing data from the
same cache line - but it seems that the integrity of the data should
be maintained (or at least this is my current understanding).

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/

your mail

[Jamie Lokier]

Dave Hylands wrote:
> I'm trying to understand what I need to be concerned about with SMP
> processors and sharing global data (in particular a dual Cortex-A9)
> 
> I'm familiar with spinlocks, but in this case I'm trying to work with
> some lockless data structures.
> 
> What I'm not sure is whether the following would work. Suppose I have
> a couple of 8-bit get/put indicies which are in adjacent memory
> locations (within the same 32-bit word).
> 
> If I have an ISR and a thread running on an SMP core, and the ISR is
> running on one core and the thread is running on a second core, if the
> ISR were to only write to the put pointer and the thread were only to
> write to the get pointer, does the cache maintain consistency? Or do
> the get and put pointers need to be in separate cache lines?
> 
> Another way of asking this: If both cores are writing to the same
> 32-bit word (but different bytes) do the writes collide?

I'm pretty sure any system compatible with pthreads has to be fine
with the variables being independent, because the bytes could be
variables protected by separate mutexes.

However, other questions for your lockless structures are whether
writes by one processor are seen in a reasonable or even bounded time
by reads on another processor (write buffering), and which barrier
instructions to use between the index accesses and accessing some
array they might indexing (only a problem for userspace, because the
kernel already provides barriers).

-- Jamie

Re: your mail

[Ben Dooks]

On Tue, May 18, 2010 at 12:38:38PM +0200, Marek Szyprowski wrote:
> Hello,

Hi, messages are supposed to have subjects... please supply one next
timne.
 
> This patch series perform a general cleanup in Samsung S5PC100 SoC support.
> This chip is moved from custom s5pc1xx platform framework to new plat-s5p
> framework, so more common code can be easily reused in upcomming extensions
> for S5PV210/S5PC110 SoCs.
> 
> This patch series is prepared against next-samsung tree, with assumption
> that the "[PATCH v3] ARM: S5PC100: Pre-requisite clock patch for
> plat-s5pc1xx to plat-s5p" has been applied as well as the '[PATCH v6]
> ARM: S5PV210: Add Ext interrupt support' (with additional bug fixes).
>
> I've tried to split my changes as much as possible to clearly show how the
> transition from plat-s5pc1xx to plat-s5p is being done.

Ok, this seems to be a pretty good progression from one to the other.

I will chase up the EINT support, it got dropped from the first pull due
to your bug reports.

Will start sorting out a second round of branches with a view to trying to
get this into the current merge window. I hope to have something to test
by the end of today.
 
> Changes since v2:
> - fixed some whitespace/tabs errors
> - removed external interrupt code, a common code from plat-s5p will be used
> - moved SMDKC100 fixes to separate patch series
> 
> Changes since v1:
> - bases on completely new clock code provided by Kukjin Kim
> - added some plat-s5p fixes required for transition
> - removed custom functions from gpiolib implementation (now uses common
>   code from plat-samsung)
> - restructured the changes to avoid breaking the functionality beteen the
>   patches
> - some other minor cleanups (mainly c1xx to c100 renames)
> 
> This patch series includes:
> 
> [PATCH 01/11] drivers: serial: S5PC100 serial driver cleanup
> [PATCH 02/11] ARM: S5PC100: Use common functions for gpiolib implementation
> [PATCH 03/11] ARM: S5PC100: Move gpio support from plat-s5pc1xx to mach-s5pc100
> [PATCH 04/11] ARM: S5PC100: gpio.h cleanup
> [PATCH 05/11] ARM: S5PC100: Move frame buffer helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 06/11] ARM: S5PC100: Move i2c helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 07/11] ARM: S5PC100: Move sdhci helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 08/11] ARM: Samsung: move S5PC100 support from plat-s5pc1xx to plat-s5p framework
> [PATCH 09/11] ARM: S5PC100: Add support for gpio interrupt
> [PATCH 10/11] ARM: S5PC100: use common plat-s5p external interrupt code
> [PATCH 11/11] ARM: remove obsolete plat-s5pc1xx directory
> 
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

your mail

[Ben Dooks]

On Tue, May 18, 2010 at 12:38:38PM +0200, Marek Szyprowski wrote:
> Hello,

Hi, messages are supposed to have subjects... please supply one next
timne.
 
> This patch series perform a general cleanup in Samsung S5PC100 SoC support.
> This chip is moved from custom s5pc1xx platform framework to new plat-s5p
> framework, so more common code can be easily reused in upcomming extensions
> for S5PV210/S5PC110 SoCs.
> 
> This patch series is prepared against next-samsung tree, with assumption
> that the "[PATCH v3] ARM: S5PC100: Pre-requisite clock patch for
> plat-s5pc1xx to plat-s5p" has been applied as well as the '[PATCH v6]
> ARM: S5PV210: Add Ext interrupt support' (with additional bug fixes).
>
> I've tried to split my changes as much as possible to clearly show how the
> transition from plat-s5pc1xx to plat-s5p is being done.

Ok, this seems to be a pretty good progression from one to the other.

I will chase up the EINT support, it got dropped from the first pull due
to your bug reports.

Will start sorting out a second round of branches with a view to trying to
get this into the current merge window. I hope to have something to test
by the end of today.
 
> Changes since v2:
> - fixed some whitespace/tabs errors
> - removed external interrupt code, a common code from plat-s5p will be used
> - moved SMDKC100 fixes to separate patch series
> 
> Changes since v1:
> - bases on completely new clock code provided by Kukjin Kim
> - added some plat-s5p fixes required for transition
> - removed custom functions from gpiolib implementation (now uses common
>   code from plat-samsung)
> - restructured the changes to avoid breaking the functionality beteen the
>   patches
> - some other minor cleanups (mainly c1xx to c100 renames)
> 
> This patch series includes:
> 
> [PATCH 01/11] drivers: serial: S5PC100 serial driver cleanup
> [PATCH 02/11] ARM: S5PC100: Use common functions for gpiolib implementation
> [PATCH 03/11] ARM: S5PC100: Move gpio support from plat-s5pc1xx to mach-s5pc100
> [PATCH 04/11] ARM: S5PC100: gpio.h cleanup
> [PATCH 05/11] ARM: S5PC100: Move frame buffer helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 06/11] ARM: S5PC100: Move i2c helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 07/11] ARM: S5PC100: Move sdhci helpers from plat-s5pc1xx to mach-s5pc100
> [PATCH 08/11] ARM: Samsung: move S5PC100 support from plat-s5pc1xx to plat-s5p framework
> [PATCH 09/11] ARM: S5PC100: Add support for gpio interrupt
> [PATCH 10/11] ARM: S5PC100: use common plat-s5p external interrupt code
> [PATCH 11/11] ARM: remove obsolete plat-s5pc1xx directory
> 
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

Re: your mail

[tytso]

On Fri, May 14, 2010 at 02:39:45PM -0700, Jiaying Zhang wrote:
> This patch changes e2fsck to use the same checking on the validity
> of an extent as the kernel ext4 is using.

Actually, the better fix is to explicitly test for extent.e_blk == 0.
The kernel test works because at the moment nothing creates file
systems where s_first_data_block is anything other than 0 or 1.  But
technically speaking, having an extent which begins at
s_first_data_block isn't actually _wrong_.  It might overlap with fs
metadata, but pass1b will handle that.  The reason why it doesn't in
the case of 0 is because 0 is a special case and also means "there's
no block present" when returned by ext2fs_block_iterate.

Arguably the kernel should be changed to something similar, but in
practice it won't make a difference in practice.  E2fsck can do a
slightly better job recovering in the case of 1k block filesystems, so
this patch is slightly better.

						- Ted

commit e6238d3708d328851bfdff7580d1b8504c7cf2e4
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri May 14 18:03:14 2010 -0400

    e2fsck: Explicitly reject extents that begin at physical block 0 as illegal
    
    In the case where s_first_data_block is 1, we need to explictly reject
    an extent whose starting physical block is zero.
    
    Thanks to Jiaying Zhang <jiayingz@google.com> for finding this bug.
    
    Addresses-Google-Bug: #2573806
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index 5e2ecc7..c35937f 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
@@ -1694,7 +1694,8 @@ static void scan_extent_node(e2fsck_t ctx, struct problem_context *pctx,
 		is_dir = LINUX_S_ISDIR(pctx->inode->i_mode);
 
 		problem = 0;
-		if (extent.e_pblk < ctx->fs->super->s_first_data_block ||
+		if (extent.e_pblk == 0 ||
+		    extent.e_pblk < ctx->fs->super->s_first_data_block ||
 		    extent.e_pblk >= ctx->fs->super->s_blocks_count)
 			problem = PR_1_EXTENT_BAD_START_BLK;
 		else if (extent.e_lblk < start_block)

Re: your mail

[Dmitry Torokhov]

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

Re: your mail

[Rafi Rubin]

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

Re: your mail

[Dmitry Torokhov]

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

Re: your mail

[Sukadev Bhattiprolu]

Matt Helsley [matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org] wrote:
| On Mon, Feb 15, 2010 at 04:58:13PM -0600, Serge Hallyn wrote:
| > We've currently got ns_exec both in user-cr and cr_tests.  Let's
| > give the user-cr version all features of the cr_tests one, and
| > get rid of the cr_tests one.
| > 
| > I'm also renaming it nsexec bc nsexecwp is stupid and ns_exec is
| > annoying, whereas nsexec lets you type 'nse<tab>'.

To further simplify typing, how about having nsexec clone() all namespaces
by default ? Or maybe with "-a" option ?

But this patch set looks good.

| 
| For the series:
| 
| Acked-by: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

Acked-by: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
| 
| Cheers,
| 	-Matt Helsley
| _______________________________________________
| Containers mailing list
| Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
| https://lists.linux-foundation.org/mailman/listinfo/containers

Re: your mail

[Matt Helsley]

On Mon, Feb 15, 2010 at 04:58:13PM -0600, Serge Hallyn wrote:
> We've currently got ns_exec both in user-cr and cr_tests.  Let's
> give the user-cr version all features of the cr_tests one, and
> get rid of the cr_tests one.
> 
> I'm also renaming it nsexec bc nsexecwp is stupid and ns_exec is
> annoying, whereas nsexec lets you type 'nse<tab>'.

For the series:

Acked-by: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

Cheers,
	-Matt Helsley

Re: your mail

[scameron]

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

your mail

[Russell King - ARM Linux]

On Fri, Oct 02, 2009 at 04:53:15PM +0200, Thierry Reding wrote:
> * Thierry Reding wrote:
> > So it's been quite a while since I last posted this series and there have been
> > a number of changes.
> > 
> > Support for T-Pid analog variants is dropped and will be handled in user-space
> > instead. There hardware does not differ from the standard T-Pid. This gets rid 
> > of some ugly platform-specific #ifdefs.
> > 
> > Front-panel controls are now handled in a separate driver, adx-keypad. That
> > way backlight control can be moved to userspace.
> > 
> > This series also adds a watchdog driver that can be used on all Avionic Design
> > Xanthos-based boards.
> 
> Russell,
> 
> with the watchdog and backlight drivers out of the way, would you like me to
> get any of the other drivers (fb, keypad) in via seperate trees or can they go
> in through the ARM tree?

They should go in via the relevant driver trees.

your mail

[Thierry Reding]

* Thierry Reding wrote:
> So it's been quite a while since I last posted this series and there have been
> a number of changes.
> 
> Support for T-Pid analog variants is dropped and will be handled in user-space
> instead. There hardware does not differ from the standard T-Pid. This gets rid 
> of some ugly platform-specific #ifdefs.
> 
> Front-panel controls are now handled in a separate driver, adx-keypad. That
> way backlight control can be moved to userspace.
> 
> This series also adds a watchdog driver that can be used on all Avionic Design
> Xanthos-based boards.

Russell,

with the watchdog and backlight drivers out of the way, would you like me to
get any of the other drivers (fb, keypad) in via seperate trees or can they go
in through the ARM tree?

Do the remaining patches need additional work or can I go ahead and submit
them to the patch system? Or do you prefer some other way to get them into
your tree?

Thierry

Your Mail

[Brown.K]

Its a pleasure to be in contact with you today. I wish to let you know that I have a client who wants to invest in your country. We will eventually fly into your country to visit you.

 

 

 I will give you more details and how much he wishes to invest, if you will assure us that you will be a reliable Investor, If you can handle this Investment Procurement in your country , please provide your response to discuss more and I will study your Feasibility appraisal because this is a genuine business we need to establish in your country.

 

 

You have to be diligent,honest and be focused to do business and posses managerial abilities. Note that a fully signed and stamped Memorandum of Understanding will be initiated in this business venture to aid in guiding both parties & commitments in this transaction.

Kindly send me the below information for my perusal:

 

1. Your Complete Full Names 2. Your Residential Address 3. Your age and Occupation 4. Your Phone and Fax Numbers for Easy and Faster Communication.



[For your information: FRAUDULENT OR DUBIOUS ELEMENTS ARE NOT ALLOWED!!]

 

Thanks for your anticipated cooperation. Have a nice day while i wait for your answer now.

Sir Kelly Brown

------------------------



Doing Good Business Brings Good Money: B & K Consultants.





------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Re: your mail

[Gleb Natapov]

On Thu, Jul 23, 2009 at 11:39:55AM +0530, Haneef Syed wrote:
> Is kvm-88 is compatible with linux-2.6.24 kernel..??? 
> 
It may be. Some degree of compatibility with older kernels is
maintained. Try it.

http://www.linux-kvm.org/page/Code

--
			Gleb.

Re: your mail

[Haneef Syed]

Is kvm-88 is compatible with linux-2.6.24 kernel..??? 

______________________________________________________________________

Re: your mail

[Gleb Natapov]

On Thu, Jul 23, 2009 at 11:08:41AM +0530, Haneef Syed wrote:
> HI All,
> 
> I have taken kvm-22 with linux-2.6.24 kernel but when ever i install guest 
> through qemu bins, system hangs.
> 
> In dmesg it prints as "Unable to handle NULL derefrencing pointer".
> 
> Please suggest me why it is behaving like this
> 
I would suggest you to use more recent KVM. The latest one is kvm-88.
There were a couple of bug fixes and enhancements in those 66 version.

--
			Gleb.

Re: your mail

[Matthew Wilcox]

On Wed, Jun 17, 2009 at 12:08:03PM -0400, Koffi Nogbe wrote:
> How can I modify the kernel to be able to create unlimited partition
> on a single drive.

You can't in any sensible way.

> The reason for the question is I want to use one of
> my box as a storage server for fast access to the be able to create my
> RAID across all drives all the time so I want to slice the drives into
> multiple 2GB partition and used that in the RAID then use LVM to put
> it together. With SCSI drive I m stock with 15 partitions and with IDE
> 20. Any help is appreciated.

Sounds like you want to use LVM to create lots of PEs, then tie them
together into RAIDs.  http://tldp.org/HOWTO/LVM-HOWTO/tyingittogether.html
may be helpful.

-- 
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."

Re: your mail

[Casey Schaufler]

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

Re: your mail

[Ingo Molnar]

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

Re: your mail

[Luca Berra]

On Wed, Apr 01, 2009 at 11:16:06PM -0500, Lelsie Rhorer wrote:
>8T of active space is formatted as a single Reiserfs file system.  The
....
>The issue is the entire array will occasionally pause completely for about
>40 seconds when a file is created.  This does not always happen, but the
>situation is easily reproducible.  The frequency at which the symptom
i wonder how costly b-tree operaton are for a 8Tb filesystem...

L.

-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

Re: your mail

[Linus Torvalds]

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

Re: your mail

[Ralf Nyren]

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

Re: your mail

[Vitaly Mayatskikh]

> 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

Re: your mail

[Linus Torvalds]

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

Re: your mail

[Johannes Weiner]

On Fri, Feb 13, 2009 at 09:45:13AM +0900, Youngwhan Kim wrote:
> unsubscribe

There is just no way out!

> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org        ^^^^^^^^^^^^

                           ^^^^^^^^^^^^^^^^^^^^^^^^^

Re: your mail

[Paul Mundt]

On Tue, Jan 13, 2009 at 03:45:47PM +0000, Steve Glendinning wrote:
> From: Steve Glendinning <steve.glendinning@smsc.com>
> Date: Tue, 13 Jan 2009 15:22:36 +0000
> Subject: [PATCH 0/3] sh: convert platforms to use smsc911x
> 
> This patchset, intended for 2.6.30, converts all in-tree sh platforms 
> from smc911x to the actively maintained smsc911x driver.
> 
> I've rebased and fixed up the patchset against the current linus tree, 
> please let me know if I should rebase it against another instead.
> 
> Steve Glendinning (3):
>   sh: convert magicpanelr2 platform to use smsc911x
>   sh: convert ap325rxa platform to use smsc911x
>   sh: convert rsk7203 platform to use smsc911x
> 
Thanks, these are already in the queue, they will be included in the next
merge.

Re: your mail

[Matthew Wilcox]

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."

Re: your mail

[Steven Rostedt]

On Tue, Jan 13, 2009 at 01:10:04AM -0500, Steven Rostedt wrote:

Bah! sorry for the noise here. My scripts to send out the patch
queue failed to handle the comma in "Luck, Tony" email address.
But it unfortunately did a partial send :-(

I had to modify Tony's email for the final send.

-- Steve

Re: your mail

[Jesper Juhl]

On Sat, 10 Jan 2009, Jose Luis Marchetti wrote:

> Hi,
> 
> I would like to open/read/write/close a regular file from my device
> driver.

That's probably a bad idea and what you really want to do is use procfs, 
sysfs, debugfs, relayfs, module parameters or similar.

Take a look here: 
http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad 


-- 
Jesper Juhl <jj@chaosbits.net>        http://personal.chaosbits.net/
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: your mail

[Aneesh Kumar K.V]

On Wed, Aug 13, 2008 at 08:24:28PM +0530, aneesh.kumar@gmail.com wrote:
> From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
> 
> topgit: Implement tg-import
> 
> This can be used to import a set of commits
> between range specified by range1..range2
> This should help us to convert an already
> existing quilt, stgit branches to topgit
> managed one
> 
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
> 
> ---
>  Makefile     |    2 +-
>  README       |    7 ++++++
>  tg-create.sh |   22 ++++++++----------
>  tg-export.sh |    2 +-
>  tg-import.sh |   68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 87 insertions(+), 14 deletions(-)
> 

tg-create.sh and tg-export.sh should not be part of this patch. I will
send a new version.

-aneesh

Re: your mail

[David Boulding]

Thanks for the help!

Dave

On Tue, Jul 29, 2008 at 3:11 AM, Eric Leblond <eric@inl.fr> wrote:
> Hello,
>
> On Monday, 2008 July 28 at 11:33:24 -0400, David Boulding wrote:
>> I've never heard of NFLOG or ULOG, is there any documentation under
>> netfilter on how to use it? How would I get the data that I want (to
>> sniff) using NFLOG/ULOG?
>
> For ULOG, you can have a look at ulogd or ulogd2 code.
>        http://git.netfilter.org/cgi-bin/gitweb.cgi?p=ulogd2.git;a=blob;f=input/packet/ulogd_inppkt_ULOG.c;h=c00d9bf8a965be7f961738892e19191efcf8f691;hb=0b789ea9bf810497845456e9b83bff8c5ae5ca23
> By the way, as ulogd2 uses a plugin mechanism, you may be able to build
> what you want by coding an ulogd2 plugin. It can provide you a way to
> code something independant from low level (NFLOG or ULOG can be used as
> input without changing your plugin).
>
> A mini doc about ulogd2 hacking is available here:
>        http://home.regit.org/?page_id=90
>
> For NFLOG, you need to use latest git for kernel and libnetfilter_log.
>
> The following functions are available:
>
> - nflog_get_hwtype: to fetch hardware type (and thus give the parser to
>  use)
> - nflog_get_msg_packet_hwhdrlen: to get hardware header len
> - nflog_get_msg_packet_hwhdr: get hardware datas
>
> BR,
> --
> Eric Leblond
> INL: http://www.inl.fr/
> NuFW: http://www.nufw.org/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIjsKinxA7CdMWjzIRAofmAJ9mi4P5SRkPugu8wADwtmB2LlHmigCfWjNn
> E77TPzKV3LStdfYgpFCobVA=
> =ruvK
> -----END PGP SIGNATURE-----
>
>

Re: your mail

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

Hello,

On Monday, 2008 July 28 at 11:33:24 -0400, David Boulding wrote:
> I've never heard of NFLOG or ULOG, is there any documentation under
> netfilter on how to use it? How would I get the data that I want (to
> sniff) using NFLOG/ULOG?

For ULOG, you can have a look at ulogd or ulogd2 code.
	http://git.netfilter.org/cgi-bin/gitweb.cgi?p=ulogd2.git;a=blob;f=input/packet/ulogd_inppkt_ULOG.c;h=c00d9bf8a965be7f961738892e19191efcf8f691;hb=0b789ea9bf810497845456e9b83bff8c5ae5ca23
By the way, as ulogd2 uses a plugin mechanism, you may be able to build
what you want by coding an ulogd2 plugin. It can provide you a way to
code something independant from low level (NFLOG or ULOG can be used as
input without changing your plugin).

A mini doc about ulogd2 hacking is available here:
	http://home.regit.org/?page_id=90

For NFLOG, you need to use latest git for kernel and libnetfilter_log.

The following functions are available:

- nflog_get_hwtype: to fetch hardware type (and thus give the parser to
  use)
- nflog_get_msg_packet_hwhdrlen: to get hardware header len
- nflog_get_msg_packet_hwhdr: get hardware datas

BR,
-- 
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: your mail

[David Boulding]

I've never heard of NFLOG or ULOG, is there any documentation under
netfilter on how to use it? How would I get the data that I want (to
sniff) using NFLOG/ULOG?

Dave

On Mon, Jul 28, 2008 at 10:43 AM, Eric Leblond <eric@inl.fr> wrote:
> Hello,
>
> On Monday, 2008 July 28 at 10:21:43 -0400, David Boulding wrote:
>> Thanks for the reply.
>> I knew of nfq_get_packet_hw(), but I'm looking for a way to get the raw byte
>> > >
>> > > I'm developing with libnetfilter_queue, using "iptables -A FORWARD ." to
>> > > capture packets of interest on a bridge for analysis (firewall).
>
> As you said "analysis", you may only want to "sniff" packet. In that case,
> you can use NFLOG (latest git) or ULOG.
>
> NFQUEUE moudle uses the dev_parse_header() function which only return the
> source hardware address. You will not be able to retrieve the wanted
> information without patching the kernel.
>
> BR,
> --
> Eric Leblond
> INL: http://www.inl.fr/
> NuFW: http://www.nufw.org/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkiN2x0ACgkQnxA7CdMWjzJSmQCdHBt2ro5Tx7m5GbWhl7uGZz7l
> 5H8Anjc9CaBwO/tOVaywfm+WwzeeBayE
> =felb
> -----END PGP SIGNATURE-----
>
>

Re: your mail

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Hello,

On Monday, 2008 July 28 at 10:21:43 -0400, David Boulding wrote:
> Thanks for the reply.
> I knew of nfq_get_packet_hw(), but I'm looking for a way to get the raw byte
> > >
> > > I'm developing with libnetfilter_queue, using "iptables -A FORWARD ." to
> > > capture packets of interest on a bridge for analysis (firewall).

As you said "analysis", you may only want to "sniff" packet. In that case,
you can use NFLOG (latest git) or ULOG.

NFQUEUE moudle uses the dev_parse_header() function which only return the
source hardware address. You will not be able to retrieve the wanted
information without patching the kernel.

BR,
-- 
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: your mail

[David Boulding]

Thanks for the reply.
I knew of nfq_get_packet_hw(), but I'm looking for a way to get the
raw byte array of the header that I get from the nfq_get_payload()
call. I'm not only looking for the MAC header information (which
nfq_get_packet_hw() will give me easy enough), but whatever else is
there, for example PPPoE and PPP header information. Is there anyway
to get that?

Thanks,

Dave

On Mon, Jul 28, 2008 at 10:14 AM, Eric Leblond <eric@inl.fr> wrote:
>
> Hello,
>
> On Saturday, 2008 July 26 at 21:11:08 -0400, David Boulding wrote:
> > Hey all,
> >
> > I'm developing with libnetfilter_queue, using "iptables -A FORWARD ." to
> > capture packets of interest on a bridge for analysis (firewall).
> > I use nfq_get_payload() to grab everything from the IP layer and on, but I
> > was wondering if there was any way to get the raw MAC layer.
> > Is there any command like nfq_get_payload() that will return everything
> > similar to what you would get using wireshark or ethereal?
>
> You can use nfq_get_packet_hw():
>
>        Retrieves the hardware address associated with the given queued packet.
>        For ethernet packets, the hardware address returned (if any) will be the
>        MAC address of the packet source host.  The destination MAC address is not
>        known until after POSTROUTING and a successful ARP request, so cannot
>        currently be retrieved.
>
>        The nfqnl_msg_packet_hw structure is defined in "libnetfilter_queue/libnetfilter_queue.h" as:
>
>                struct nfqnl_msg_packet_hw {
>                        u_int16_t       hw_addrlen;
>                        u_int16_t       _pad;
>                        u_int8_t        hw_addr[8];
>                } __attribute__ ((packed));
> .
>
> http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023286.html
>
> BR,
> --
> Eric Leblond
> INL: http://www.inl.fr/
> NuFW: http://www.nufw.org/

Re: your mail

[Eric Leblond]

Hello,

On Saturday, 2008 July 26 at 21:11:08 -0400, David Boulding wrote:
> Hey all,
> 
> I'm developing with libnetfilter_queue, using "iptables -A FORWARD ." to
> capture packets of interest on a bridge for analysis (firewall). 
> I use nfq_get_payload() to grab everything from the IP layer and on, but I
> was wondering if there was any way to get the raw MAC layer. 
> Is there any command like nfq_get_payload() that will return everything
> similar to what you would get using wireshark or ethereal?

You can use nfq_get_packet_hw():

	Retrieves the hardware address associated with the given queued packet.
	For ethernet packets, the hardware address returned (if any) will be the
	MAC address of the packet source host.  The destination MAC address is not
	known until after POSTROUTING and a successful ARP request, so cannot
	currently be retrieved.

	The nfqnl_msg_packet_hw structure is defined in "libnetfilter_queue/libnetfilter_queue.h" as:

		struct nfqnl_msg_packet_hw {
			u_int16_t	hw_addrlen;
			u_int16_t	_pad;
			u_int8_t	hw_addr[8];
		} __attribute__ ((packed));
.

http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023286.html

BR,
-- 
Eric Leblond
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/

Re: your mail

[Henrique de Moraes Holschuh]

On Tue, 01 Jul 2008, Henrique de Moraes Holschuh wrote:
> Bcc: 
> Subject: Re: [PATCH/RFC] b43: remove input device usage for rfkill
> Reply-To: 
> In-Reply-To: <1214937876.3462.10.camel@johannes.berg>
> X-GPG-Fingerprint: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04  3738 EE25 DE3F
> 	1CDB 0FE3
> 
[...]

Sorry about this, hit the wrong key while adding Dmitry to the CC.  I have
resent it properly.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: your mail

[Daniel Walker]

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

Re: your mail

[Thomas Gleixner]

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

Re: your mail

[Alan Stern]

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

Re: your mail

[Ralf Baechle]

On Tue, Jan 22, 2008 at 12:00:26AM +0000, Thiemo Seufer wrote:

> This patch moves the micro-assembler in a separate implementation, as
> it is useful for further run-time optimizations. The only change in
> behaviour is cutting down printk noise at kernel startup time.
> 
> Checkpatch complains about macro parameters which aren't protected by
> parentheses. I believe this is a flaw in checkpatch, the paste operator
> used in those macros won't work with parenthesised parameters.
> 
> Tested on:
> - Qemu 32-bit little endian
> - BCM1480 64-bit big endian
> 
> 
> Thiemo
> 
> 
> ---
> Split the micro-assembler from tlbex.c.
> 
> Signed-off-by:  Thiemo Seufer <ths@networkno.de>

Looks technically ok but conflicts with these 7 other patches which also
touch arch/mips/mm/tlbex.c:

Please keep all the stuff the stuff that should go into the commit
message - and only that - above the "---" tearline.  git-am will drop
anything below it and friendly greetings, signatures etc. should not go
into the log message so keep that below the tearoff line.

commit 699a78e99f302003ae6d6090bf7f35eb69b772e0
Author: Manuel Lauss <mano@roarinelk.homelinux.net>
Date:   Thu Dec 6 09:07:55 2007 +0100

    [MIPS] Alchemy: Au1210/Au1250 CPU support
    
    This patch adds IDs for new Au1200 variants: Au1210 and Au1250.
    They are essentially identical to the Au1200 except for the Au1210
    which has a different SoC-ID in the PRId register [bits 31:24].
    The Au1250 is a "Au1200 V0.2".
    
    Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 56bccd5921f7b1160ddab0f9c3e9cc227ecd9aef
Author: Franck Bui-Huu <fbuihuu@gmail.com>
Date:   Thu Oct 18 09:11:17 2007 +0200

    [MIPS] tlbex.c: cleanup debug code
    
    Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 97432dc56d464006a62b1cd3ee6484828bde816c
Author: Franck Bui-Huu <fbuihuu@gmail.com>
Date:   Thu Oct 18 09:11:16 2007 +0200

    [MIPS] tlbex.c: use __cacheline_aligned instead of __tlb_handler_align
    
    Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 82e27810cd28e4322bd400640c8627ceacfc29f5
Author: Franck Bui-Huu <fbuihuu@gmail.com>
Date:   Thu Oct 18 09:11:15 2007 +0200

    [MIPS] tlbex.c: cleanup include files
    
    Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit b849ac81b87278c9b9e17aef8f4d82a30578ec93
Author: Franck Bui-Huu <fbuihuu@gmail.com>
Date:   Thu Oct 18 09:11:14 2007 +0200

    [MIPS] tlbex.c: Cleanup __init usages.
    
    Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit bf672b2f700d031d933c7dadcd9fae5edaa019b4
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date:   Tue Oct 23 12:43:25 2007 +0100

    [MIPS] R4000/R4400 daddiu erratum workaround
    
     This complements the generic R4000/R4400 errata workaround code and adds
    bits for the daddiu problem.  In most places it just modifies handwritten
    assembly code so that the assembler is allowed to use a temporary register
    as daddiu may now be treated as a macro that expands to a sequence of li
    and daddu.  It is the AT register or, where AT is unavailable or used
    explicitly for another purpose, an explicitly-named register is selected,
    using the .set at=<reg> feature added recently to gas.  This feature is
    only used if CONFIG_CPU_DADDI_WORKAROUNDS has been set, so if the
    workaround remains disabled, the required version of binutils stays
    unchanged.
    
     Similarly, daddiu instructions put in branch delay slots in noreorder
    fragments are now taken out of them and the assembler is allowed to
    reorder them itself as possible (which it does making the whole idea of
    scheduling them into delay slots manually questionable).
    
     Also in the very few places where such a simple conversion was not
    possible, a handcoded longer sequence is implemented.
    
     Other than that there are changes to code responsible for building the
    TLB fault and page clear/copy handlers to avoid daddiu as appropriate.
    These are only effective if the erratum is verified to be present at the
    run time.
    
     Finally there is a trivial update to __delay(), because it uses daddiu in
    a branch delay slot.
    
    Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 2d220349159729f143570673f8752aafd6d8da74
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Mon Jan 28 17:14:10 2008 +0000

    [MIPS] tlbex: Cleanup handling of R2 hazards in TLB handlers.
    
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

But I'm really happing to see the generalization we've been talking about
to finally proceed.

  Ralf

Re: your mail

[Johannes Schindelin]

Hi,

On Wed, 5 Dec 2007, Johannes Schindelin wrote:

> [PATCH 1/6] path-list: add functions to work with unsorted lists

Ooops.

Sorry,
Dscho

Re: your mail

[nicholas.thompson1]

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

Re: your mail

[Matti Aarnio]

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

Re: your mail

[Jan Engelhardt]

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

Re: your mail

[Jeff King]

On Sat, Oct 13, 2007 at 12:01:04AM -0400, Michael Witten wrote:

> Now that you mention it, I think the best approach would be to:
> 	
> 	(1) cvsexportcommit
> 	(2) git reset --hard LAST_CVS_IMPORT_AND_MERGE
> 	(3) git cvsimport ..... # and merge
>
> I think this is what you mean; it seems to me that rebasing isn't quite 
> that.

No, I mean rebasing instead of merge. As in, you have a history like
this:

    /--C---D  <-- your master
A--B
    \--C'--D' <-- cvsimport merge tip

where "C" and "D" are your commits in git, and C' and D' are pulled in
from cvsimport. You want to rebase your work like this:

A--B--C'--D'--C--D

except that git-rebase is smart enough to realize that C == C' and skip
it (so it's a "safe" way of moving forward).

> However, this will not preserve more complicated history such as merges
> from another git repository.

Correct. Rebasing doesn't really handle merges, but I assumed you were
just making simple commits on top of a cvs master.

> Basically, I want to treat my git repository as the official
> repository; the CVS repo is just their for the old farts to get the
> latest stuff ;-P

Then my suggestion doesn't really work. You might consider using git as
the official server and letting the old farts use git-cvsserver.

HTH,
-Peff

Re: your mail

[Justin Piszcz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 352 bytes --]

You need to e-mail majordomo@vger.kernel.org.

On Tue, 9 Oct 2007, Frédéric Mantegazza wrote:

> subscribe linux-raid
> --
>   Frédéric
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: your mail

[Ricard Wanderlof]

On Thu, 27 Sep 2007, Gangadhar Kodishala wrote:

> I created another partition on NAND to use specifically for the data. I
> would like to create a JFFS2 file system on this data partition, mount it
> and use it to store my application code and data files,

If you just want to create an empty JFFS2 file system, then just erase the 
partition, and mount it.

/Ricard
--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: your mail

[Steven Rostedt]

--
On Mon, 24 Sep 2007, Steven Rostedt wrote:

> linux-rt-users@vger.kernel.org
> Bcc:
> Subject: Re: realtime preemption performance difference
> Reply-To:
> In-Reply-To: <3f9a31f40709240448h4a9e8337t437328b5c675ecd5@mail.gmail.com>

[ I'm actually just learning how to screw-up^Wuse mutt ]

bah!

-- Steve

Re: your mail

[Herbert Xu]

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

Re: your mail

[Bob Picco]

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

Re: your mail

[Bob Picco]

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

Re: your mail

[Olof Johansson]

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

Re: your mail

[Olof Johansson]

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

Re: your mail

[Linas Vepstas]

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

Re: your mail

[Linas Vepstas]

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

Re: your mail

[Gerard Braad]

Sorry, this wasn't supposed to happen. Already done...
Unsubscribed due to lack of a digest mail.

> I wonder why people can't send their unsubscribe message to the same
> address they sent their subscribe message to.

Re: your mail

[David Miller]

From: Jan Engelhardt <jengelh@linux01.gwdg.de>
Date: Thu, 29 Mar 2007 23:42:17 +0200 (MEST)

> > unsubscribe linux-kernel ..
> 
> I wonder why people can't send their unsubscribe message to the same 
> address they sent their subscribe message to.

People get frustrated that it doesn't work then start doing stupid
things like sending it to the actual list, like this person did.

Of course they always fail to consider doing the proper thing which is
to ask postmaster@vger.kernel.org or the list owner
(linux-kernel-owner@vger.kernel.org in this case) for help if it is
the case that their email has changed and they no longer have a way to
send from the subscribed address.

Re: your mail

[Jan Engelhardt]

>
> unsubscribe linux-kernel ..

I wonder why people can't send their unsubscribe message to the same 
address they sent their subscribe message to.

Re: your mail

[Joerg Roedel]

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

Re: your mail

[Pekka Enberg]

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

Re: your mail

[Joerg Roedel]

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

Re: your mail

[Joerg Roedel]

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: your mail

[Davide Libenzi]

On Tue, 21 Nov 2006, Johannes Schindelin wrote:

> [PATCH] xdiff: add xdl_merge()
> 
> This new function implements the functionality of RCS merge, but
> in-memory. It returns < 0 on error, otherwise the number of conflicts.
> 
> Finding the conflicting lines can be a very expensive task. You can
> control the eagerness of this algorithm:
> 
> - a level value of 0 means that all overlapping changes are treated
>   as conflicts,
> - a value of 1 means that if the overlapping changes are identical,
>   it is not treated as a conflict.
> - If you set level to 2, overlapping changes will be analyzed, so that
>   almost identical changes will not result in huge conflicts. Rather,
>   only the conflicting lines will be shown inside conflict markers.
> 
> With each increasing level, the algorithm gets slower, but more accurate.
> Note that the code for level 2 depends on the simple definition of
> mmfile_t specific to git, and therefore it will be harder to port that
> to LibXDiff.

Johannes, at the moment I'm chased by a huge storm of never ending emails, 
so I won't be able to follow up this one soon. A smart 3-way merge is in 
my plans for LibXDiff though.
There is quite some nice code around, that does pretty smart tricks and 
goes down to resolve sub-hunk non-trivial conflicts. You may want to take 
a look at that code too.



- Davide

Re: your mail

[Chris Wedgwood]

On Mon, Oct 23, 2006 at 12:47:20PM +0530, Chakka Satish Kumar wrote:

> I formatted a partition of size 5GB with xfs block size=16K

you can't use a block size large than your machines page size, so you
probably want to leave it at 4K (the default in most cases)

Re: your mail

[Johannes Schindelin]

Hi,

your email is horridly mixed here. I get an empty subject here, and the 
complete email header at the beginning of the email:

On Fri, 20 Oct 2006, andyparkins@gmail.com wrote:

> >From 9c128bc4b9b85385b7b98ceae0c89283d70e5d45 Mon Sep 17 00:00:00 2001
> From: Andy Parkins <andyparkins@gmail.com>
> [... complete email header including MIME header ...]
> Content-Disposition: inline
> 
> git-send-email doesn't exist; so don't refer to it in the documentation.

But it does! I just removed it, and "make" remade it. I don't even see in 
the Makefile why it should _not_ be made...

Ciao,
Dscho

Re: your mail

[Linus Torvalds]

On Tue, 26 Sep 2006, Zhao, Jing wrote:
> 
>  I subscribed git emailing list (git@vger.kernel.org). I don't know for 
> what reason, my post emails all have been rejected. Could you post this 
> for me and shed some light on this issue? thanks,

The vger.kernel.org lists have various spam detectors, and I suspect a 
combination of your email address and the signature you use just triggers 
that system to believe that you are trying to sell us house payment plans 
or something..

So I would suggest removing your signature in particular, that points to a 
web-site that is associated with an industry that has over-used the email 
medium for selling their services...

> I tried to port git to VOS system (Stratus). When i compiled it, i 
> found it did not have 'regex.h' and its library. Do you know any 
> workaround for this problem? Or which package contains these code i can 
> port at first?

I do not know if stratus has regex libraries anywhere, but googling for 
"VOS Stratus regex" seems to be saying that this isn't the first time that 
platform has had problems compiling various programs.

I suspect you'd just have to compile one of the regex libraries that are 
out there as source. I think Henry Spencer's libraries are likely the 
canonical ones, but there's a "GNU regex" too, and that's probably the 
basis for the ones that are used in glibc. Dunno.

Google for either of those, you'll find them. It's not new code, but I 
doubt it needs to be ;)

			Linus

Re: your mail

[J. Bruce Fields]

On Sun, May 21, 2006 at 05:16:44PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
> > On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >> >From nobody Mon Sep 17 00:00:00 2001
> >> From: J. Bruce Fields <bfields@citi.umich.edu>
> >
> > Oops, sorry, I screwed up sending those; let me know if you'd like them
> > resent....
> 
> That's OK.  I just cooked up this one ;-).

Thanks!--b.

Re: your mail

[Junio C Hamano]

"J. Bruce Fields" <bfields@fieldses.org> writes:

> On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
>> >From nobody Mon Sep 17 00:00:00 2001
>> From: J. Bruce Fields <bfields@citi.umich.edu>
>
> Oops, sorry, I screwed up sending those; let me know if you'd like them
> resent....

That's OK.  I just cooked up this one ;-).

-- >8 --
From 03946787890c12fbb6ecfbe0382cbf02ac209801 Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Sun, 21 May 2006 17:15:06 -0700
Subject: [PATCH] mailinfo: skip bogus UNIX From line inside body

Sometimes people just include the whole format-patch output in
the commit e-mail.  Detect it and skip the bogus ">From " line.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 mailinfo.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/mailinfo.c b/mailinfo.c
index b276519..a133e6d 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -237,10 +237,17 @@ static int eatspace(char *line)
 #define SEEN_FROM 01
 #define SEEN_DATE 02
 #define SEEN_SUBJECT 04
+#define SEEN_BOGUS_UNIX_FROM 010
 
 /* First lines of body can have From:, Date:, and Subject: */
 static int handle_inbody_header(int *seen, char *line)
 {
+	if (!memcmp(">From", line, 5) && isspace(line[5])) {
+		if (!(*seen & SEEN_BOGUS_UNIX_FROM)) {
+			*seen |= SEEN_BOGUS_UNIX_FROM;
+			return 1;
+		}
+	}
 	if (!memcmp("From:", line, 5) && isspace(line[5])) {
 		if (!(*seen & SEEN_FROM) && handle_from(line+6)) {
 			*seen |= SEEN_FROM;
-- 
1.3.3.g292f

Re: your mail

[J. Bruce Fields]

On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >From nobody Mon Sep 17 00:00:00 2001
> From: J. Bruce Fields <bfields@citi.umich.edu>

Oops, sorry, I screwed up sending those; let me know if you'd like them
resent....

--b.

Re: your mail

[Ross Vandegrift]

On Wed, Jan 11, 2006 at 09:47:03AM -0500, bhess@patmedia.net wrote:
> Has anyone put an effort into building a raid 1 based on USB connected
> drives under Redhat 3/4 not as the root/boot
> drive.

No, I haven't actually tried this, but I do know that it'll work
without any problem.

The main issue that you'll confront - USB devices do not have fixed
device numbers.  They can change every time they are plugged/unplugged.
As a result, you may not be able to depend on your disks to always be
(for example) /dev/sde and /dev/sdf.

There's a user-space daemon called hotplug that manages this stuff.
It load appropriate drivers for the devices it sees plugged into the
USB bus.  I don't know enough about to tell you specifically how it
will handle your setup.

My initial suggestion:
	1) Start with no driver plugged
	2) cat /proc/partitions > ~/nousb
	3) Plug one drive in
	4) cat /proc/partitions > ~/oneusb
	5) Plug second drive in
	6) cat /proc/parititons > ~/twousb
	7) diff -u ~/nousb ~/oneusb
	8) diff -u ~/oneusb ~/twousb

This should give you a good idea of how the kernel treats the
situation from the device perspective.

As far as the RAID part - that's easy.  Once you know what the block
devices look like, make your RAID.  I promise the md driver will work.
I've run md across all sorts of weird device setups and so long as
it's a working block device, md is happy!

Finally, if you use mdadm's --uuid option to assemble your array after
creating it, it should just find the USB disks, regardless of where
they came up.  That way, you only need to worry about what device node
they are using when you first create the array.

Good luck! 


-- 
Ross Vandegrift
ross@lug.udel.edu

"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
	--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

Re: your mail

[Hugh Dickins]

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

Re: your mail

[Elfyn McBratney]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On Wed, Oct 05, 2005 at 08:10:24AM +0200, Willem Swart wrote:
 > subscribe git
 > -
 > To unsubscribe from this list: send the line "unsubscribe git" in
 > the body of a message to majordomo@vger.kernel.org
 > More majordomo info at  http://vger.kernel.org/majordomo-info.html
s/unsubscribe/subscribe/g

Might want to re-send that to majordomo@vger.kernel.org ;)

Best,
Elfyn

-- 
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net                            http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc

PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
  DBD3 B756 ED58 B1B4 47B9  B3BD 8D41 E597 69DF 17AD

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: your mail

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

On Tue, Aug 30, 2005 at 10:21:31PM +0900, Yasuyuki KOZAKAI wrote:
> 
> Hi,
> 
> If CONFIG_NF_IP_CONNTRACK=y, CONFIG_NETFILTER_NETLINK=m, and
> CONFIG_NF_CONNTRACK_NETLINK=m, it's failed to build kernel
> of netfilter-2.6.14 git tree. Because __nfa_fill() in nfnetlink
> called from ip_conntrack isn't built into kernel image in this case.
> It's necessary to fix Kconfig or change source code to make dependencies
> more simple.

Thanks for pointing this out.

This problem will be fixed by Thomas Graf's generic netlink macros
(which will be part of the core network stack) which will be merged
during the net-2.6.14 process, so I think we can ignore
this for now.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: your mail

[Tom McNeal]

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

Re: your mail

[Chris Wedgwood]

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

Re: your mail

[Ralf Baechle]

On Thu, Apr 28, 2005 at 03:15:49PM -0400, Bryan Althouse wrote:

> I would like to use a 2.6.x kernel with my Yosemite/HalfDome board.
> Somehow, I am unable to compile the kernel.  I have tried the 2.6.10 kernel
> trees from ftp.pmc-sierra.com and also the latest 2.6.12 snapshot from
> linux-mips.  I am using the 3.3.x cross compile tools from
> ftp.pmc-sierra.com .  The 2.4.x kernels from PMC compile fine.
> 
> In the case of 2.6.10 from ftp.pmc-sierra.com, my error looks like:
>        Make[3]: *** [drivers/char/agp/backend.o] Error 1

Configuring AGP support for a MIPS kernel is obviously nonsense.  Disable
CONFIG_AGP.

> In the case of 2.6.12 from linux-mips, my error looks like:
> 	drivers/net/titan_ge.c1950: error: 'titan_device_remove"  undeclared
> here (not in a function)

Whoops, a bug.  The function indeed doesn't exist even though it should,
will fix that.  You will hit this bug only if compiling the titan driver
as a module, so workaround set CONFIG_TITAN_GE=y.  Which for the typical
titan-based device seems to be the preferable choice anyway.

  Ralf

Re: your mail

[Alan Stern]

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

Re: your mail

[Matthew Dharm]

[-- 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 --]

Re: your mail

[Artem B. Bityuckiy]

On Tue, 16 Nov 2004, David Woodhouse wrote:

> On Tue, 2004-11-16 at 14:54 +0000, Artem B. Bityuckiy wrote:
> > Yes. But imagine some file which is constant and is never changed. We 
> > create checkpoint for it and this checkpoint covers all the nodes. So, we 
> > will need to rewrite new checkpoint even for this file when its nodes are 
> > garbage collected... 
> 
> Yeah. In particular we'd nee to rewrite a new checkpoint when the block
> containing the old checkpoint was garbage-collected anyway.
> 
Hmm, do not get it why. Why we need this? We may just copu old checkpoint 
inact I believe. What happen If we do this? 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: your mail

[David Woodhouse]

On Tue, 2004-11-16 at 14:54 +0000, Artem B. Bityuckiy wrote:
> Yes. But imagine some file which is constant and is never changed. We 
> create checkpoint for it and this checkpoint covers all the nodes. So, we 
> will need to rewrite new checkpoint even for this file when its nodes are 
> garbage collected... 

Yeah. In particular we'd nee to rewrite a new checkpoint when the block
containing the old checkpoint was garbage-collected anyway.

-- 
dwmw2

Re: your mail

[Artem B. Bityuckiy]

On Tue, 16 Nov 2004, David Woodhouse wrote:

> On Tue, 2004-11-16 at 14:21 +0000, Artem B. Bityuckiy wrote:
> > I dreamed about checkpoints which we may write only once for constant 
> > files (for example, glibc libraries) ....
> > 
> > So, this problem is solvable I believe, but no I'm not quite sure are 
> > checkpoints will be so useful as I thought ... 
> 
> Hm. I was imagining that we'd read in the information from the
> checkpoint, and then pull in anything _new_ -- which would include any
> nodes which weren't included in the checkpoint.

Yes. But imagine some file which is constant and is never changed. We 
create checkpoint for it and this checkpoint covers all the nodes. So, we 
will need to rewrite new checkpoint even for this file when its nodes are 
garbage collected... 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: your mail

[David Woodhouse]

On Tue, 2004-11-16 at 14:21 +0000, Artem B. Bityuckiy wrote:
> I dreamed about checkpoints which we may write only once for constant 
> files (for example, glibc libraries) ....
> 
> So, this problem is solvable I believe, but no I'm not quite sure are 
> checkpoints will be so useful as I thought ... 

Hm. I was imagining that we'd read in the information from the
checkpoint, and then pull in anything _new_ -- which would include any
nodes which weren't included in the checkpoint.

-- 
dwmw2

Re: your mail

[Artem B. Bityuckiy]

On Tue, 16 Nov 2004, David Woodhouse wrote:

> On Tue, 2004-11-16 at 13:48 +0000, Artem B. Bityuckiy wrote:
> > Hello David,
> > 
> > When I create checkpoints, I read all the nodes which will be referred by 
> > this checkpoint and check their CRCs. This is because we must trust 
> > checkpoints and do not check CRCs for them on the iget() call.
> > 
> > When the Garbage Collector moves node, which is currently referred by an 
> > checkpoint inact (I mean the jffs2_garbage_collect_pristine() function), 
> > we have to read this node after we GC it. This is the problem. The unclean 
> > reboot may happed and we can not guarantee that all noted in checkpoint 
> > are OK. :-(
> > 
> > So, how do you think is it absolutely necessary to check that nodes which 
> > are reffered by checkpoint are OK? Is it OK if we just detect errors when 
> > we actually read file?
> 
> No, that's not OK. We'd actually lose the data in that case, surely? We
> _need_ to pick up the new copy of the node, if the old one is absent.
> Either we have to obsolete the newer checkpoint or we have to ignore the
> checkpoint data if we get a failure, and rescan properly.
> 
> -- 
> dwmw2
> 
> 
:-((

Very bad...
This means that checkpoints will have short live-time. I mean, that if we 
have some read-only file and have generated the checkpoint for this file, 
we will need to rewrite the checkpoint periodically when it becomes 
obsolete because the file's nodes are moved by the GC.... :-(

I call checkpoint obsolete when:
1. The newer checkpoint exist (usual meaning)
2. More that N % of nodes, referred by the checkpoint are disappeared 
since were Garbage Collected.

I dreamed about checkpoints which we may write only once for constant 
files (for example, glibc libraries) ....

So, this problem is solvable I believe, but no I'm not quite sure are 
checkpoints will be so useful as I thought ... 

 -- Best 
Regards, Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: your mail

[Jesper Juhl]

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

Re: your mail

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On Tue, 2004-08-24 08:05:08 +0200, Francisco M. Marzoa Alonso <fmmarzoa@softronica.org>
wrote in message <200408240805.08811.fmmarzoa@softronica.org>:
> >>       TOut.tv_sec = Wait / 1000;
> >>       TOut.tv_usec = Wait % 1000;
> >
> >So "Wait" is in milli-seconds? That doesn't look correct, then:)
> >
> >        TOut.tv_sec = Wait / 1000;
> >        TOut.tv_usec = (Wait % 1000) * 1000;
> 
> Sure you're right, but this is a thing that I do not understand. I made a 
> function GetTickCount to emulate Window's one based on gettimeofday and see 
> that milliseconds on timeval structure can have values up to 999999 when I 
> expect to found a maximum value of 999 as there are only 1000 milliseconds in 
> a second.

Notice, it's not "tv_msec" but "tv_usec", which is micro-seconde and
not milli-seconds. A small 'u' is commonly used instead of the greek
'µ', because 'µ' won't be properly handled by all email clients, let
alone in code to be compiled.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: your mail

[Dave Airlie]

> 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

Re: your mail

[Dave Airlie]

>
> All the fbdev handling code in X is also an accident?

I've no idea I've nothing to do with X... but the fact that graphics work
at all with fb/drm/X is by no fault of any design it is pure hack ...

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

It means writing 6 or 7 stub drivers, for cards we don't have, it means
making PCI probing different for some fbdev drivers and some DRM drivers
(e.g. the i915 doesn't have a framebuffer driver in 2.6 so do I write a
stub on the chance that someone writes an fb driver for it? -  why do this
when the DRM will start encompassing the fb soon..) it is a lot of work
that we intend throwing away, the final solution is not to merge DRM/fb
via a stub, it is to create a single driver for each card, what happens
when the DRM starts doing memory management and 2d stuff.. we won't want
fb to be able to load anymore as it will break the DRM...I see Jon Smirl
has found the thread, please discuss with him as he was the one doing all
the legwork at the kernel summit...

again this doesn't break any real setups, it is the path of least
resistance as it doesn't affect fb drivers, why should DRM be a second
class citizen, when it is clearly going to have to be a first class 2.6
driver to do its job... if you can find someone with a real world setup
that this breaks I'll consider it a really bad idea... but I think Jon has
made his point far better than I...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: your mail

[Jon Smirl]

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

Re: your mail

[Christoph Hellwig]

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.

Re: your mail

[Dave Airlie]

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

Re: your mail

[Christoph Hellwig]

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.

Re: your mail

[Dave Airlie]

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

Re: your mail

[Alan Cox]

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

Re: your mail

[Alan Cox]

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.

Re: your mail

[Christoph Hellwig]

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.

Re: your mail

[Dave Airlie]

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

Re: your mail

[Christoph Hellwig]

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.

Re: your mail

[Dave Airlie]

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

Re: your mail

[Christoph Hellwig]

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.

Re: your mail

[Dave Airlie]

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

Re: your mail

[Christoph Hellwig]

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.

Re: your mail

[Dave Airlie]

> 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

Re: your mail

[Christoph Hellwig]

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?

Re: your mail

[Chris Wright]

* Laughlin, Joseph V (Joseph.V.Laughlin@boeing.com) wrote:
> Currently, we're using sched_setaffinity() to control it, which existed
> in our 2.4.19 kernel.  (but, you have to be root to use it, and we'd
> like non-root users to be able to change the affinity.)

Sounds like it's patched in.  And it likely doesn't require root per se,
but CAP_SYS_NICE (as the 2.6 code does).

So, you've got choices of how to disable those capability checks to do
what you want.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

RE: your mail

[Laughlin, Joseph V]

> -----Original Message-----
> From: Bernd Petrovitsch [mailto:bernd@firmix.at] 
> Sent: Monday, May 24, 2004 4:13 PM
> To: Laughlin, Joseph V; linux-kernel@vger.kernel.org
> Subject: RE: your mail
> 
> 
> On Tue, 2004-05-25 at 01:04, Laughlin, Joseph V wrote:
> > > -----Original Message-----
> [...]
> > > On Mon, May 24, 2004 at 03:20:33PM -0700, Laughlin, 
> Joseph V wrote:
> > > > I've been tasked with modifying a 2.4 kernel so that a
> > > non-root user
> > > > can do the following:
> > > > 
> > > > Dynamically change the priorities of processes (up and 
> down) Lock
> > > > processes in memory Can change process cpu affinity
> [...]
> > Currently, we're using sched_setaffinity() to control it, which 
> > existed in our 2.4.19 kernel.  (but, you have to be root to use it, 
> > and we'd like non-root users to be able to change the affinity.)
> 
> And using sudo or setuid Binaries?
> 
> 	Bernd
> -- 

Not an option, unfortunately. 

RE: your mail

[Bernd Petrovitsch]

On Tue, 2004-05-25 at 01:04, Laughlin, Joseph V wrote:
> > -----Original Message-----
[...]
> > On Mon, May 24, 2004 at 03:20:33PM -0700, Laughlin, Joseph V wrote:
> > > I've been tasked with modifying a 2.4 kernel so that a 
> > non-root user 
> > > can do the following:
> > > 
> > > Dynamically change the priorities of processes (up and down) Lock 
> > > processes in memory Can change process cpu affinity
[...]
> Currently, we're using sched_setaffinity() to control it, which existed
> in our 2.4.19 kernel.  (but, you have to be root to use it, and we'd
> like non-root users to be able to change the affinity.)

And using sudo or setuid Binaries?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

RE: your mail

[Laughlin, Joseph V]

> -----Original Message-----
> From: Herbert Poetzl [mailto:herbert@13thfloor.at] 
> Sent: Monday, May 24, 2004 3:30 PM
> To: Laughlin, Joseph V
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: your mail
> 
> 
> On Mon, May 24, 2004 at 03:20:33PM -0700, Laughlin, Joseph V wrote:
> > I've been tasked with modifying a 2.4 kernel so that a 
> non-root user 
> > can do the following:
> > 
> > Dynamically change the priorities of processes (up and down) Lock 
> > processes in memory Can change process cpu affinity
> > 
> > Anyone got any ideas about how I could start doing this?  
> (I'm new to 
> > kernel development, btw.)
> 
> check the kernel capability system ...
> (it's quite simple)
> 
> #define CAP_SYS_NICE         23
> #define CAP_IPC_LOCK         14
> 
> cpu scheduler affinity isn't part of 2.4 AFAIK
> so there is no easy way to 'control' it ...
> 

Currently, we're using sched_setaffinity() to control it, which existed
in our 2.4.19 kernel.  (but, you have to be root to use it, and we'd
like non-root users to be able to change the affinity.)

Joe

Re: your mail

[Marc-Christian Petersen]

On Tuesday 25 May 2004 00:30, Herbert Poetzl wrote:

Hi Joseph,

> > Dynamically change the priorities of processes (up and down)
> > Lock processes in memory
> > Can change process cpu affinity
> > Anyone got any ideas about how I could start doing this?  (I'm new to
> > kernel development, btw.)
> check the kernel capability system ...
> (it's quite simple)
> #define CAP_SYS_NICE         23
> #define CAP_IPC_LOCK         14
> cpu scheduler affinity isn't part of 2.4 AFAIK
> so there is no easy way to 'control' it ...

at least I have a patch in my 2.4-tree where a user in a predefined GID 
(changeable via /proc) can change his/her nice of his/her own processes up 
and down.

ciao, Marc

Re: your mail

[Chris Wright]

* Laughlin, Joseph V (Joseph.V.Laughlin@boeing.com) wrote:
> I've been tasked with modifying a 2.4 kernel so that a non-root user can
> do the following:
> 
> Dynamically change the priorities of processes (up and down)

Requires CAP_SYS_NICE.

> Lock processes in memory

Currently requires CAP_IPC_LOCK.  However, this one is already been
done using rlimits (at least via mlock() and friends, SHM_LOCK has
different issue).

> Can change process cpu affinity

Requires CAP_SYS_NICE (but I believe this was a 2.6 feature).

> Anyone got any ideas about how I could start doing this?  (I'm new to
> kernel development, btw.)

There's a few approaches floating about.  Probably the simplest is to
disable the checks globally, but this will also be less secure.  I have
an example of this in 2.6 if you'd like.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: your mail

[Herbert Poetzl]

On Mon, May 24, 2004 at 03:20:33PM -0700, Laughlin, Joseph V wrote:
> I've been tasked with modifying a 2.4 kernel so that a non-root user can
> do the following:
> 
> Dynamically change the priorities of processes (up and down)
> Lock processes in memory
> Can change process cpu affinity
> 
> Anyone got any ideas about how I could start doing this?  (I'm new to
> kernel development, btw.)

check the kernel capability system ...
(it's quite simple)

#define CAP_SYS_NICE         23
#define CAP_IPC_LOCK         14

cpu scheduler affinity isn't part of 2.4 AFAIK
so there is no easy way to 'control' it ...

HTH,
Herbert

> Thanks,
> 
> Joe Laughlin
> Phantom Works - Integrated Technology Development Labs 
> The Boeing Company
> 
> 
> 
> -
> 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/

Re: your mail

[Jon]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Wed, Apr 28, 2004 at 11:03:08PM -0400, whitehorse@mustika.net wrote:
> dear Sir,
>  I have a problem in compiling kernel 2.6.4 from kernel 2.4.19. I use
>  Debian woody. When I rebooting new kernel, some message occur such:
>  "modprobe: QM_MODULES: function not implemented"
>  and I can't load my modules when boot. I would like to waiting any one who
>  answer this. Please send to this mail. Thanks
> 
>  Best regards,
> 
>  Hafid
>  Indonesia
> 
You need to install module-init-tools which is not in Debian Woody
A backport of it for x86 machines is here
http://www.backports.org/debian/dists/woody/module-init-tools/
-- 
Jon
http://tesla.resnet.mtu.edu
The only meaning in life is the meaning you create for it.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: your mail

[James Morris]

On Mon, 12 Apr 2004, Denis Vlasenko wrote:

> According to my measurements,
> 
> ip_vs_control_add() (from include/net/ip_vs.h) is called twice
> and
> sock_queue_rcv_skb() (from include/net/sock.h) is called 19 times
> from various kernel .c files.
> 
> Both these includes generate more than 500 bytes of code on x86.
> 
> These patches uninline them. Please apply.

What kind of performance impact (if any) does this patch have?


- James
-- 
James Morris
<jmorris@redhat.com>

Re: your mail

[Joel Jaeggli]

On Fri, 9 Apr 2004, Martin Knoblauch wrote:

> >I was wondering if for linux or better for a linux filesystem
> >there is something like dynamic swapping of files possible.
> >For explanation: I habeaccess to an Infinstor via NFS and
> >linux is runnig there. This server has a nice funtion I'd
> >like to have: if there are files that are not used for a
> >specified time (i.e. 30 days) they are moved to another storage
> >(disk and after that to an streamer tape) and are replaced
> >by some kind of 'link'. So if you look at your directory you
> >can see everything that was there, but if you try to open it,
> >you have to wait a moment (some seconds if the file was
> >swapped to another disk) oder just another moment (some
> >minutes if the file is on a tape) and then it restored at
> >it's old place.
> >
> 
>  Good description of a HSM (Hierarchical Storage Management)
> System.
> 
> >So is there anything which provides such a feature? By now
> >I have a little script that moves such files out of the way and
> >replaces them by links. But restoring is somewhat harder and
> >it's not automatic.
> >
> >Any ideas?
> >

part of the thing for us (my group at UO) right now, is tape robots aren't
cheaper than disk, so a lot of our offline/near-line backup is slowly
moving in that direction... 1TB lto jukeboxs cost order of $8-9K ea and
the driver for your commercial tabe-backup software can cost nearly that
much on top of it, but I can put 3.5TB of disk in a 5u enclosure and
locate in some other building for a similar price if not less. Even If buy
it in something like a netapp filer it's still only around $10,000 a TB so
HSM systems involving tape don't really have the same apeal as when we
were paying $1200ea for 4GB scsi disks. If I had sunk costs in something
like a storagetek powerhorn with 6000 tape capacity I might think a little
differently but I suspect your situation is closer to mine that it is to
the sorts of people who buy those.

>  Really depends. As far as I know thare are no "free" HSM Systems
> out there for Linux The only one that I am faintly familiar with
> that runs on Linux is StorNext from ADIC. Definitely not free.
> 
>  DMF/Irix may now be ported to Linux (Altix/IA64), but I doubt
> it will be free.
> 
>  Sun is most likely not (yet) interested in doing a Linux port
> of SAM-FS (there are still Sparc/Solaris Machines to sell).
> And it won't be free (my guess).
> 
>  Tivoli/IBM and UniTree are also sold for Linux. Again "sold" is
> the important word
> 
> Martin
> 
> 
> =====
> ------------------------------------------------------
> Martin Knoblauch
> email: k n o b i AT knobisoft DOT de
> www:   http://www.knobisoft.de
> -
> 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/
> 

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli  	       Unix Consulting 	       joelja@darkwing.uoregon.edu    
GPG Key Fingerprint:     5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

Re: your mail

[Richard B. Johnson]

On Mon, 15 Mar 2004, Kevin Leung wrote:

> Hello All,
>
> I am very new to Linux and am working on a project. The nature of the
> project is to essentially record all process/thread scheduling activity for
> use in a later application. I wanted to know if any experts out there knew
> of any libraries that could essentially "monitor" or "listen" for any
> scheduling changes made. For instance if the kernel decides to set process A
> from "sleeping" to "running" and process B from "running" to "sleeping", I
> wanted to know if there was a function that could generate an immediate
> notification of this event.

No. FYI, there are hundreds-of-thousands of such "events" per second
of operation! Basically, any time some task is waiting for I/O its
CPU is taken away and given to somebody else. This is what "sleeping"
usually means. Once the I/O completes, the task gets the CPU
again and that's what "running" means. If you were to instrument
these two state-changes for all tasks, it would certainly leave
only a new percent of CPU available for the tasks. This would
royally screw up the meaning of anything you were trying to
instrument.

> Priority change information is also desireable.

If you mean the dynamic priority that keeps changing until
the task is executed, no. If you mean priority like
'nice', you can instrument the sys-call.

> The more aspects which trigger notificaiton, the better. As a first attempt,

There is a kernel logging daemon that writes 'printk' messages. This
works by having a user-mode daemon open and read /proc/kmsg. You can
make a similar communications interface, using the existing daemon
as a template, that will instrument anything you want.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: your mail

[Richard B. Johnson]

On Tue, 24 Feb 2004, Jim Deas wrote:

> Can someone point me in the right direction.
> I am getting a oops on a driver I am porting from 2.4 to 2.6.2 kernel.
> I have expanded the file_operations structures and have a driver that
> loads and inits the hardware but when I call the open function I
> get an oops. The best I can track it is
>

Fix your line-warp!

> EIP 0060:[c0188954]
> chrdev_open +0x104
>
> What is the best debug tool to put this oops information in clear
> sight? It appears to never get to my modules open routine so I am
> at a debugging crossroad. What is the option on a kernel compile
> to get the compile listing so I can see what is at 0x104 in this
> block of code?
>

Nothing is going to help with that EIP with a segment value of
0x60. It looks like some dumb coding error, using a pointer
that disappeared after the module init function. In other
words, it's probably something like:

int __init init_module()
{
    struct file_operations fops;
    mset(&fops, 0x00, sizeof(fops));
    fops.open = open;
    fops.release = close;
    fops.owner = THIS_MODULE;
    register_chrdev(DEV_MAJOR, dev, &fops);
}

So, everything in init_module is GONE. Your program calls open()
and the pointer in the kernel gets dereferenced to junk.

There are kernel debugging tools, however I have found that
the most useful tools are printk() and some discipline.

In the case of code above, don't just change the declaration
of the fops object to static. Instead, move it outside the
function, so it's obviously where it won't go away.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: your mail

[Richard B. Johnson]

On Thu, 19 Feb 2004, Joilnen Leite wrote:

> excuse me friends shcedule_timeout(1) is not a problem
> for spin_lock_irqsave ?
>
> drivers/scsi/ide-scsi.c:897
>
> spin_lock_irqsave(&ide_lock, flags);
> while (HWGROUP(drive)->handler) {
>        HWGROUP(drive)->handler = NULL;
>        schedule_timeout(1);
> }
>
> pub 1024D/5139533E Joilnen Batista Leite
> F565 BD0B 1A39 390D 827E 03E5 0CD4 0F20 5139 533E

What kernel version?  It is very bad. You can't sleep with
a spin-lock being held!

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an Intel Pentium III machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

RE: your mail

[Bloch, Jack]

By the way shouldn't a munmap call really free the memory. I have an strace
showing that the process calls munmap a lot but I do not seeany gaps in the
map file

Jack Bloch 
Siemens ICN
phone                (561) 923-6550
e-mail                jack.bloch@icn.siemens.com


-----Original Message-----
From: Bloch, Jack 
Sent: Friday, February 13, 2004 2:14 PM
To: 'Maciej Zenczykowski'
Cc: linux-kernel@vger.kernel.org
Subject: RE: your mail


Yes, your assumtion about the 1GB is correct.

Jack Bloch 
Siemens ICN
phone                (561) 923-6550
e-mail                jack.bloch@icn.siemens.com


-----Original Message-----
From: Maciej Zenczykowski [mailto:maze@cela.pl]
Sent: Friday, February 13, 2004 1:11 PM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail


The deleted marks in question mean that the file in question has been 
unlinked (rm'ed), however it is still being used and the inode in question 
still exists.  This memory is in use and thus validly takes up mapping 
space.  You'd need to unmap inorder to free that memory.  Deleting a file 
does not delete that file until _all_ processes close and unmap any 
references to it.  What's more worrying is the large area of unmapped 
memory below 1GB (0x40000000), wonder why it doesn't get allocated?  But I 
think the answer is that the standard allocator only searches 1GB..3GB for 
free areas...

Cheers,
MaZe.

On Fri, 13 Feb 2004, Bloch, Jack wrote:

> I am running a 2.4.19 Kernel and have a problem where a process is using
the
> up to the 0xC0000000 of space. It is no longer possible for this process
to
> get any more memory vi mmap or via shmget. However, when I dump the
> /procs/#/maps file, I see large chunks of memory deleted. i.e this should
be
> freely available to be used by the next call. I do not see these addresses
> get re-used. The maps file is attached.
> 
>  <<9369>> 
> 
> Jack Bloch 
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com
> 
> 

RE: your mail

[Bloch, Jack]

Yes, your assumtion about the 1GB is correct.

Jack Bloch 
Siemens ICN
phone                (561) 923-6550
e-mail                jack.bloch@icn.siemens.com


-----Original Message-----
From: Maciej Zenczykowski [mailto:maze@cela.pl]
Sent: Friday, February 13, 2004 1:11 PM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail


The deleted marks in question mean that the file in question has been 
unlinked (rm'ed), however it is still being used and the inode in question 
still exists.  This memory is in use and thus validly takes up mapping 
space.  You'd need to unmap inorder to free that memory.  Deleting a file 
does not delete that file until _all_ processes close and unmap any 
references to it.  What's more worrying is the large area of unmapped 
memory below 1GB (0x40000000), wonder why it doesn't get allocated?  But I 
think the answer is that the standard allocator only searches 1GB..3GB for 
free areas...

Cheers,
MaZe.

On Fri, 13 Feb 2004, Bloch, Jack wrote:

> I am running a 2.4.19 Kernel and have a problem where a process is using
the
> up to the 0xC0000000 of space. It is no longer possible for this process
to
> get any more memory vi mmap or via shmget. However, when I dump the
> /procs/#/maps file, I see large chunks of memory deleted. i.e this should
be
> freely available to be used by the next call. I do not see these addresses
> get re-used. The maps file is attached.
> 
>  <<9369>> 
> 
> Jack Bloch 
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com
> 
> 

Re: your mail

[Maciej Zenczykowski]

The deleted marks in question mean that the file in question has been 
unlinked (rm'ed), however it is still being used and the inode in question 
still exists.  This memory is in use and thus validly takes up mapping 
space.  You'd need to unmap inorder to free that memory.  Deleting a file 
does not delete that file until _all_ processes close and unmap any 
references to it.  What's more worrying is the large area of unmapped 
memory below 1GB (0x40000000), wonder why it doesn't get allocated?  But I 
think the answer is that the standard allocator only searches 1GB..3GB for 
free areas...

Cheers,
MaZe.

On Fri, 13 Feb 2004, Bloch, Jack wrote:

> I am running a 2.4.19 Kernel and have a problem where a process is using the
> up to the 0xC0000000 of space. It is no longer possible for this process to
> get any more memory vi mmap or via shmget. However, when I dump the
> /procs/#/maps file, I see large chunks of memory deleted. i.e this should be
> freely available to be used by the next call. I do not see these addresses
> get re-used. The maps file is attached.
> 
>  <<9369>> 
> 
> Jack Bloch 
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com
> 
> 

Re: your mail

[Maciej Zenczykowski]

On Tue, 10 Feb 2004, Bloch, Jack wrote:

> I have a system with 2GB of memory. One of my processes calls mmap to try to
> map a 100MB file into memory. This calls fails with -ENOMEM. I rebuilt the
> kernel with a few debug printk statements in mmap.c to see where the failure
> was occurring it occurred in the function arch_get_unmapped_area. the code
> is as follows:
> 
> for (vma = find_vma(mm, addr); ; vma = vma->vm_next) {
> 		/* At this point:  (!vma || addr < vma->vm_end). */
> 		unsigned long __heap_stack_gap;
> 		if (TASK_SIZE - len < addr)
>                 { 

it's valid there's no point in searching further for an area of at least 
len bytes.  The user area is 0 .. TASK_SIZE-1.  The addr is the address 
currently being checked, the len is the requested length.  if addr+len is 
greater or equal to TASK_SIZE then the current addr (which is increasing 
within this loop) already causes such a mapping to overflow into kernel 
space (exceeds the TASK_SIZE virtual address limit).  This is precisely as 
expected.

I'd assume your program has fragmented memory to such a level that a 
single consecutive 100 MB area is no longer free (not that hard to do, 
since TASK_SIZE is 3 GB).

Cheers,
MaZe.

Re: your mail

[Gerd Knorr]

> 		....
>                         while (voffset >= sg_dma_len(vsg)) {
>                                 voffset -= sg_dma_len(vsg);
>                                 vsg++;
>                         }
> 		....

> I suspect the problem is that 
> 
> 	"voffset >= sg_dma_len(vsg)"
> 
> test: if "voffset" is _exactly_ the same as sg_dma_len(), then we will 
> test one more iteration (when "voffset" is 0), and that iteration may be 
> past the end of the "vsg" array.

That certainly makes sense, the 'v' plane is the last one in the memory
block for the video frame to be captured, so voffset / vsg will walk to
the last sg entry and may overrun described.  Good catch, I'm impressed.

> I suspect the fix might be to change the test to
> 
> 	"voffset && voffset >= sg_dma_len(vsg)"

Merged into my tree, thanks.

still busy with the xmas mail backlog,

  Gerd

Re: your mail

[Linus Torvalds]

On Fri, 26 Dec 2003 caszonyi@rdslink.ro wrote:
> 
> I was trying to capture a tv program  with mencoder when the oops occured
> a couple  of hours later the system froze without leaving a single trace
> in logs. I was able to reboot with SysRq.
> 
> Programs versions, config and dmesg are attached.

Looks like this loop:

		....
                        while (voffset >= sg_dma_len(vsg)) {
                                voffset -= sg_dma_len(vsg);
                                vsg++;
                        }
		....

and in particular, it's the "sg_dma_len()" access that oopses, apparently 
because vsg was stale to begin with, or because it incremented past the 
last pointer.

The pointer that fails (0xc4bea00c) looks reasonable, so it's almost
certainly due to CONFIG_PAGE_DEBUG showing some kind of use-after-free
problem (ie the pointer is stale, and the memory has already been freed).

I suspect the problem is that 

	"voffset >= sg_dma_len(vsg)"

test: if "voffset" is _exactly_ the same as sg_dma_len(), then we will 
test one more iteration (when "voffset" is 0), and that iteration may be 
past the end of the "vsg" array.

I suspect the fix might be to change the test to

	"voffset && voffset >= sg_dma_len(vsg)"

to make sure that we never access vsg past the end of the array.
		

		Linus

Re: your mail

[Norberto Bensa]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 354 bytes --]

Matti Aarnio wrote:
> Folks, I don't understand you...
> In EVERY list posting there are explicite instructions
> of how to unsubscribe, and STILL people do it wrong...

People doesn't read.

Regards,
Norberto

-- 
Linux 2.6.0-mm1 Pentium III (Coppermine) GenuineIntel GNU/Linux
 14:35:46 up 39 min,  1 user,  load average: 0.34, 0.18, 0.13

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: your mail

[Matti Aarnio]

Folks, I don't understand you...
In EVERY list posting there are explicite instructions
of how to unsubscribe, and STILL people do it wrong...

Do tell us (postmaster@vger.kernel.org) if you do find that
there is something confusing, and should be improved.

  /Matti Aarnio -- one of  <postmaster@vger.kernel.org>

On Tue, Dec 23, 2003 at 03:16:22PM +0100, dublinux wrote:
> Date:	Tue, 23 Dec 2003 15:16:22 +0100
> From:	dublinux <dublinux@box.it>
> To:	linux-kernel@vger.kernel.org
> 
> unsubscribe linux-kernel
> -
> 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/

Re: your mail

[Stephan von Krawczynski]

On Wed, 10 Dec 2003 04:03:36 -0800
William Lee Irwin III <wli@holomorphy.com> wrote:

> On Tue, 9 Dec 2003, William Lee Irwin III wrote:
> >>> Just apply the patch if you're for some reason terrified of 2.6.
> 
> On Wed, 10 Dec 2003 00:15:17 +0000 (GMT) Paul Jakma <paul@clubi.ie> wrote:
> >> Or get RedHat or Fedora to apply the patch.
> 
> On Wed, Dec 10, 2003 at 11:49:28AM +0000, skraw@ithnet.com wrote:
> > There it is again, this /dev/null argument.
> > "Multi-billion dollar companies" have gone bancrupt on the simple
> > fact that diversification of one product can rattle customers/users
> > to a degree that they in fact decide against the whole product range.
> > IOW go on with the idea to spread around an unknown number of kernel
> > versions and you can be sure that linux as a whole will greatly suffer.
> > This is a "user" issue, not a "developer" issue of course. Developers
> > can apply any kind of patches they like, but don't go and tell the
> > vast user base to "just apply patch xyz". They won't honor this at
> > all, your level of acceptance will dramatically drop.
> 
> One of the main reasons to have an open source OS is customization.
> Arguing that it's not truly feasible to customize will not hold water.

Are you calling a user-configured (not user-patched) kernel "customized" or
not?
_The_ top reason (at least when reading Al's posts :-) is probably that the
source is cross-checked by many eyes. If you create a infinite number of
patched kernel-versions it is obvious you will loose this primary advantage.
The more versions the fewer cross-checking.
IOW a "customized" but instable OS values exactly zero.

> Pretty much every "productized" version of Linux is heavily customized
> to get some kind of value-add. There's no reason to bother mainline
> with this; if it's a serious user issue of that magnitude vendors will
> pick it up.

"Serious" is a subjective argument, therefore different people see different
issues as serious. In my opinion a kernel.org kernel should cover most if not
all possible stable customizations, see it as a pool.
So my primary question for inclusion would not be "what is it worth?" but "does
it do any harm?". I am not god, therefore I do not and can not judge 
"worthness". Can you?

Regards,
Stephan

RE: your mail

[Bloch, Jack]

Thanks,

I found the problem. I do have errno.h included. I was doing a read of errno
after calling perror. If I read it directly after getting the neagtive 0ne
back, it contains the right value.

Jack Bloch 
Siemens ICN
phone                (561) 923-6550
e-mail                jack.bloch@icn.siemens.com


-----Original Message-----
From: Linus Torvalds [mailto:torvalds@osdl.org]
Sent: Wednesday, December 03, 2003 11:04 AM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail




On Wed, 3 Dec 2003, Bloch, Jack wrote:
>
> I try to open a non-existan device driver node file. The Kernel returns a
> value of -1 (expected). However, when I read the value of errno it
contains
> a value of 29. A call to the perror functrion does print out the correct
> error message (a value of 2). Why does this happen?

Because you forgot a "#include <errno.h>"? Or you have something else
wrong in your program that makes "errno" mean the wrong thing?

		Linus

Re: your mail

[Linus Torvalds]

On Wed, 3 Dec 2003, Bloch, Jack wrote:
>
> I try to open a non-existan device driver node file. The Kernel returns a
> value of -1 (expected). However, when I read the value of errno it contains
> a value of 29. A call to the perror functrion does print out the correct
> error message (a value of 2). Why does this happen?

Because you forgot a "#include <errno.h>"? Or you have something else
wrong in your program that makes "errno" mean the wrong thing?

		Linus

Re: your mail

[Richard B. Johnson]

On Wed, 3 Dec 2003, Bloch, Jack wrote:

> I try to open a non-existan device driver node file. The Kernel returns a
> value of -1 (expected). However, when I read the value of errno it contains
> a value of 29. A call to the perror functrion does print out the correct
> error message (a value of 2). Why does this happen?
>
> Jack Bloch
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com


Because it doesn't happen! You are likely polluting the errno
variable either with another system call before you test it
or by not including the correct header file (errno may be a
MACRO).


Try this program:


#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <fcntl.h>
#include <errno.h>

int main(int args, char *argv[])
{
    int fd, save_errno;
    if(args < 2) {
        fprintf(stderr, "Usage:\n%s <filename>\n", argv[0]);
        exit(EXIT_FAILURE);
    }
    if((fd = open(argv[1], O_RDONLY)) < 0) {
        save_errno = errno;
        perror("open");
        fprintf(stderr, "Was %d (%s)\n", save_errno, strerror(save_errno));
        exit(EXIT_FAILURE);
    }
    (void)close(fd);
    return 0;
}

Script started on Wed Dec  3 10:41:24 2003
# ./xxx /dev/XXX
open: No such file or directory
Was 2 (No such file or directory)
# ./xxx /dev/VXI
open: Operation not supported by device
Was 19 (Operation not supported by device)
# exit
exit
Script done on Wed Dec  3 10:42:12 2003

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: your mail

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

On Wed, Nov 19, 2003 at 01:48:07AM +0300, Oleg Savostyanov wrote:
> Hello , Harald
> I tryed to install extra package, written by you -
> pptp-conntrack-nat
> but failed to do this.

please report such problems to netfilter@lists.gnumonks.org, or
netfilter-devel@lists.gnumonks.org (like documented on
http://www.netfilter.org/contact.html).

also, which version of patch-o-matic were you using?

> Do you have any ideas what to do?

Martin Josefsson is the patch-o-matic maintainer, maybe he can help you.

-- 
- Harald Welte <laforge@gnumonks.org>               http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your lifetime

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: your mail

[Adrian Bunk]

On Tue, Sep 30, 2003 at 03:50:08PM +0100, Dave Jones wrote:
>...
>  > Basically, if you're building a
>  > distro boot kernel, you must turn on all known workarounds.  That's
>  > certainly lowest-common-denominator, but it's a far cry from the
>  > configuration that a 386-as-firewall user wants.
> 
> Ok, I see what you're getting at, but Adrian's patch turned arch/i386/Kconfig
> and arch/i386/Makefile into guacamole.  After spending so much time
> getting that crap into something maintainable, it seemed a huge step
> backwards to litter it with dozens of ifdefs and duplication.
> There has to be a cleaner way of pleasing everyone.
>...

Referring to the latest patch I sent:

arch/i386/Kconfig:
The only problems seem to be some CPU_ONLY_* derived symbols I haven't 
yet found a better solution for.

arch/i386/Makefile:
There are two ifdefs to deal with Pentium 4 and K7/K8 selected at the 
same time:
ifdef CONFIG_CPU_PENTIUM4
  cpuflags-$(CONFIG_CPU_K{7,8})    := ...
else
  cpuflags-$(CONFIG_CPU_K{7,8})    := ...
endif

That's perhaps not optimal but IMHO not that bad.

The dozens of ifdefs were in other areas where I tried to add some 
additional space optimizations. It was a mistake to put them into the 
same patch and in the latest patches I sent they were already separated 
and they are _not_ required for the CPU selection scheme.

> 		Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: your mail

[Jamie Lokier]

Dave Jones wrote:
>  > I'm not sure what the fuss is; a strict 386 kernel runs just fine
>  > without any problems on an Athlon.  But anyway...
> 
> Unless it got configured away as proposed in your earlier patch.

No, I don't understand.  What about my patch, or indeed anything else,
stops a "strict 386" kernel from running on an Athlon?

>  > The latter is for distro boots.  The former is for that
>  > 386-as-a-firewall with 1MB of RAM, where it _really_ has to trim
>  > everything it can, and no errata thank you.
> 
> Again, 'trimming' away a few hundred bytes of errata workarounds
> is ridiculous when we have bigger fish to fry where we can save
> KBs of .text size, and MB's of runtime memory.

Well I think both are worthwhile.  Low hanging fruit and all that -
this is an example of a small saving that's very clear and easy.

>  > I've not heard of anyone actually wanting a strict 386 kernel lately,
>  > but strict 486 is not so unusual.
> 
> ISTR that current gcc's emit 486 instructions anyway, so its possible
> that with a modern toolchain, you can't *build* a 386 kernel.
> I'm not sure if that got fixed or not, I don't track gcc lists any more.

Afaict GCC has fine targetting for the 386, better than it did years
ago.  It didn't used to use the "leave" instruction, have an option to
optimise for size, or options for selecting exactly which
architectural instruction set it would use.

Anyway, that there is very little difference between 386 and 486 from
an application point of view anyway.  You may be thinking of the
recent C++ ABI debacle, I think it was, which accidentially turned out
to require some instruction emulation in the Debian kernel.  I think
they've fixed it in GCC now.

>  > Just as some people want a P4 optimised kernel, and some people want a
>  > K7 optimised kernel, so some people want a 386 or 486 or Pentium
>  > optimised kernel.  Lowest-common-denominator means it runs on
>  > everything, and isn't really anything to do with 386 any more - that's
>  > not really the lowest-common-denominator, by virtue of the obvious
>  > fact that pure 386 code isn't reliable on all other CPUs.
> 
> Elaborate? "pure 386 code" (whatever that means in your definition)
> should run perfectly reliable on every CPU we care about.

If that were true, why are we talking about needing workarounds for
non-386 chips to work correctly?

The canonical example is the F00F sequence: reliable on a 386, crashes
a Pentium.  That's a fine example of pure 386 code not being reliable
on a higher CPU.  And that's why it isn't safe to run Linux 1.0 on
your Pentium web server.

> So first you argue for compiling out a few hundred bytes of errata
> workaround, now you want to instead compile in checks & printk's
> (which probably add up to not far off the same amount of space).

Oh, I have nothing against __init space :)

>  > By selecting a PII kernel, it is possible to configure out the code
>  > for X86_PPRO_FENCE and X86_F00F_BUG, yet as far as I can tell, those
>  > _can_ possibly boot on kernels where the errata are needed, and nary a
>  > printk is emitted for it.  Nasty bugs they are, too.
> 
> Indeed. That's arguably a bug that occured when someone split the
> original CONFIG_M686 into _M686 & MPENTIUMII.

It's a bit more complicated.  It dates from before we had the
"alternative" macro, and it was still cool to optimise spin_unlock()
into the most minimal instruction sequence at compile time.

It's only since then that we've been generalising to "M586 should run
on all later models correctly".  Arguably, tidying up in the process.

Now we could use "alternative" to put the locked store or non-locked
store there and it would not look out of place.

If we're honest, Linux seems to have evolved through the 2.5 series
from "optimise the primitives as tight as reasonable for a target
architecture" to "a few nops here and there won't hurt".  Perhaps
Transmeta's malign influence, as nops cost virtually nothing on those :)

Or perhaps it's because CPU models have branched and don't make a
straight line any more.  So we have to do more run-time checking to
keep it sane.

>  > More generally than the CPU, you can also configure out BLK_DEV_RZ1000
>  > which is another crucial workaround that needs to go in any
>  > lowest-common-denominator kernel.
> 
> I wouldn't look at the history of drivers/ide/ as a shining example of
> good design 8-)

No, but as an example of needing to enable all the workarounds for a
distro boot kernel, it's a glorious gem.  Even now people aren't quite
sure if multi-sector mode or DMA should be enabled by default :)

>  > Basically, if you're building a
>  > distro boot kernel, you must turn on all known workarounds.  That's
>  > certainly lowest-common-denominator, but it's a far cry from the
>  > configuration that a 386-as-firewall user wants.
> 
> Ok, I see what you're getting at, but Adrian's patch turned arch/i386/Kconfig
> and arch/i386/Makefile into guacamole.  After spending so much time
> getting that crap into something maintainable, it seemed a huge step
> backwards to litter it with dozens of ifdefs and duplication.
> There has to be a cleaner way of pleasing everyone.

Perhaps it's in a name.  It doesn't help that there's an assumed
linear progression of CPUs to support, up to the point where they
branch off all over the place in feature space.  In the linear part,
CONFIG_M586, CONFIG_M686 etc. seem to mean "support this CPU or
later", whatever later means (and it's not stated exactly).  After the
explosion of different feature directions, they stop meaning that and
just become optimisation knobs, as all the different essential features
are supported at run time.

Personally I think Adrian's patch's heart is in the right place,
simply because the menu options make more sense than the present
rather confusion decision, if you intend to (or might ever, take your
pick) run a kernel compiled for one CPU on another.  I am never sure,
for example, if it's safe to take the hard disk from my K6 and drop it
into a P5MMX box and boot from it.  The kernel config just doesn't
make that clear.

With Adrian's it does, even if the code behind it is a little like
guacamole.  Perhaps the code could be cleaner; I don't see that
individual CPU model support is much different than what we already
have, except for the option to fix features at compile time rather than
run time.

And that gives me an idea.... ;)

-- Jamie

Re: your mail

[Dave Jones]

On Tue, Sep 30, 2003 at 03:58:54PM +0100, Jamie Lokier wrote:

 > (Aside: It is quite an anomaly that those cumbersome floating point
 > instructions are emulated on the older CPUs, yet all the other
 > instructions aren't emulated.  Emulation is very slow, and forcing
 > userspace to just use different code instead is good, but that's just
 > as valid for floating point as it is for MMX, cmpxchg etc.)

There was a patch around a while back that did 486 emulation on 386
kernels. I think it even made into the Mandrake kernel.

 > To be fair, the kernel really ought to just say that and halt.  That
 > is a fine compromise.  It won't make embedded systems folks completely
 > happy, because if you've only got 2MB of NVRAM for your whole kernel
 > _and_ filesystem including user data (think PDA or cellphone), then a
 > hundred bytes here or there is actually worth trimming.

With such tight constraints, why not just use 2.4 (or even 2.2) which
has much lower memory usage and diskspace requirements ?

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: your mail

[Jamie Lokier]

John Bradford wrote:
> Unless, of course, you object to the possibility that somebody might
> go out of their way to compile a 386 specific kernel from source
> themselves, then run it on an Athlon.  By chance it will probably
> appear to work OK, but won't have the workaround enabled.  So what?

Actually the 386 kernel will work just fine on the AMD...  The
workaround is only needed, in the kernel, to protect against the
kernel's own use of non-386 features...

Userspace is a different matter, but userspace has a lot of
model-specific things to worry about beyond this one instruction on
AMD.  In practice: bswap, cmov, cmpxchg, mmx, sse, sse2, so knowing
whether to use prefetch or not is just one more variable for userspace
- and one which any portable app or library will have to know about in
any case.

(Aside: It is quite an anomaly that those cumbersome floating point
instructions are emulated on the older CPUs, yet all the other
instructions aren't emulated.  Emulation is very slow, and forcing
userspace to just use different code instead is good, but that's just
as valid for floating point as it is for MMX, cmpxchg etc.)

> Only somebody who knows exactly what they were doing is likely to do
> that - how could it happen by accident?  If you really must, put a
> warning in to say, 'This kernel doesn't support your processor', but
> doing that just adds more bloat.  OK, so the bloat will be freed after
> boot, but it's still bloat on the boot device, which matters in some
> embedded systems.

To be fair, the kernel really ought to just say that and halt.  That
is a fine compromise.  It won't make embedded systems folks completely
happy, because if you've only got 2MB of NVRAM for your whole kernel
_and_ filesystem including user data (think PDA or cellphone), then a
hundred bytes here or there is actually worth trimming.

But then, those sort of embedded folks should just figure out
compressed software-suspend, and then they can ditch __init data from
the NVRAM image completely.  It's much better to lose all of __init
than just a few bytes here or there, isn't it?

-- Jamie

Re: your mail

[Dave Jones]

On Tue, Sep 30, 2003 at 03:06:27PM +0100, Jamie Lokier wrote:
 > Dave Jones wrote:
 > > On Tue, Sep 30, 2003 at 09:17:16AM +0100, John Bradford wrote:
 > >  > Of course a kernel compiled strictly for 386s may seem to boot on an
 > >  > Athlon but not work properly.  So what?  Just don't run the 'wrong'
 > >  > kernel.
 > > Wrong answer. How do you intend to install Linux when a distro boot
 > > kernel is compiled for lowest-common-denominator (386), and is the
 > > 'wrong' kernel for an Athlon ?
 > I'm not sure what the fuss is; a strict 386 kernel runs just fine
 > without any problems on an Athlon.  But anyway...

Unless it got configured away as proposed in your earlier patch.

 > Dave, you are conflating "kernel compiled strictly for 386s" with
 > "compiled for lowest-common-denominator".
 > 
 > They are totally different configurations.  Isn't that why we have
 > "generic" now?

CONFIG_GENERIC could be extended to offer other options yes,
but right now what it does doesn't really match the name IMO.
Right now its closer to a CONFIG_MAX_CACHELINE_SIZE

 > The latter is for distro boots.  The former is for that
 > 386-as-a-firewall with 1MB of RAM, where it _really_ has to trim
 > everything it can, and no errata thank you.

Again, 'trimming' away a few hundred bytes of errata workarounds
is ridiculous when we have bigger fish to fry where we can save
KBs of .text size, and MB's of runtime memory.

 > I've not heard of anyone actually wanting a strict 386 kernel lately,
 > but strict 486 is not so unusual.

ISTR that current gcc's emit 486 instructions anyway, so its possible
that with a modern toolchain, you can't *build* a 386 kernel.
I'm not sure if that got fixed or not, I don't track gcc lists any more.

 > Just as some people want a P4 optimised kernel, and some people want a
 > K7 optimised kernel, so some people want a 386 or 486 or Pentium
 > optimised kernel.  Lowest-common-denominator means it runs on
 > everything, and isn't really anything to do with 386 any more - that's
 > not really the lowest-common-denominator, by virtue of the obvious
 > fact that pure 386 code isn't reliable on all other CPUs.

Elaborate? "pure 386 code" (whatever that means in your definition)
should run perfectly reliable on every CPU we care about.

 > > We hashed this argument out a week or so ago, it seems the message
 > > didn't get across. YOU CAN NOT DISABLE ERRATA WORKAROUNDS IN A KERNEL
 > > THAT MAY POSSIBLY BOOT ON HARDWARE THAT WORKAROUND IS FOR.
 > I agree.  It shouln't be possible to boot on the wrong hardware: it
 > should refuse.

So first you argue for compiling out a few hundred bytes of errata
workaround, now you want to instead compile in checks & printk's
(which probably add up to not far off the same amount of space).

 > By selecting a PII kernel, it is possible to configure out the code
 > for X86_PPRO_FENCE and X86_F00F_BUG, yet as far as I can tell, those
 > _can_ possibly boot on kernels where the errata are needed, and nary a
 > printk is emitted for it.  Nasty bugs they are, too.

Indeed. That's arguably a bug that occured when someone split the
original CONFIG_M686 into _M686 & MPENTIUMII.

 > More generally than the CPU, you can also configure out BLK_DEV_RZ1000
 > which is another crucial workaround that needs to go in any
 > lowest-common-denominator kernel.

I wouldn't look at the history of drivers/ide/ as a shining example of
good design 8-)

 > Basically, if you're building a
 > distro boot kernel, you must turn on all known workarounds.  That's
 > certainly lowest-common-denominator, but it's a far cry from the
 > configuration that a 386-as-firewall user wants.

Ok, I see what you're getting at, but Adrian's patch turned arch/i386/Kconfig
and arch/i386/Makefile into guacamole.  After spending so much time
getting that crap into something maintainable, it seemed a huge step
backwards to litter it with dozens of ifdefs and duplication.
There has to be a cleaner way of pleasing everyone.

 > > clearer?
 > If the kernel had a consistent policy so far, it would be more clear,
 > but it doesn't.

Agreed, there are some questionable parts.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: your mail

[John Bradford]

Quote from Dave Jones <davej@redhat.com>:
> On Tue, Sep 30, 2003 at 09:17:16AM +0100, John Bradford wrote:
>  
>  > Of course a kernel compiled strictly for 386s may seem to boot on an
>  > Athlon but not work properly.  So what?  Just don't run the 'wrong'
>  > kernel.
> 
> Wrong answer. How do you intend to install Linux when a distro boot
> kernel is compiled for lowest-common-denominator (386), and is the
> 'wrong' kernel for an Athlon ?

I don't.  I *never* suggested doing that.  I clearly said a kernel
compiled *strictly* for 386s.  I.E. Without support for other
processors.

> We hashed this argument out a week or so ago, it seems the message
> didn't get across. YOU CAN NOT DISABLE ERRATA WORKAROUNDS IN A KERNEL
> THAT MAY POSSIBLY BOOT ON HARDWARE THAT WORKAROUND IS FOR.

It seems the message didn't get across to you.

Have you actually looked at Adrian's patch?

*Forget* that 386=lowest-common-denominator.  This
'386=lowest-common-denominator' theme is out of date, and we should be
moving away from it - oh, hang on, that's exactly what Adrian's patch
allows us to do.

A distribution installation kernel needs to boot all supported
hardware - of course it does.  So what?  Just select support for all
the processors in the configurator.  No, don't just select 386,
because 386 doesn't mean 386 and above anymore with Adrian's patch, it
means support 386 and don't bloat the kernel with workarounds for
other processors.  Select *all* processors.  Now you have a nice,
(bloated), kernel that boots on the same hardware that you old '386'
one did.  Fine for installation on diverse hardware.  Rubbish for
performance.

Unless, of course, you object to the possibility that somebody might
go out of their way to compile a 386 specific kernel from source
themselves, then run it on an Athlon.  By chance it will probably
appear to work OK, but won't have the workaround enabled.  So what?
Only somebody who knows exactly what they were doing is likely to do
that - how could it happen by accident?  If you really must, put a
warning in to say, 'This kernel doesn't support your processor', but
doing that just adds more bloat.  OK, so the bloat will be freed after
boot, but it's still bloat on the boot device, which matters in some
embedded systems.

> clearer ?

It's clear that you didn't read my original post, yes.

John.

Re: your mail

[Jamie Lokier]

Dave Jones wrote:
> On Tue, Sep 30, 2003 at 09:17:16AM +0100, John Bradford wrote:
>  > Of course a kernel compiled strictly for 386s may seem to boot on an
>  > Athlon but not work properly.  So what?  Just don't run the 'wrong'
>  > kernel.
> 
> Wrong answer. How do you intend to install Linux when a distro boot
> kernel is compiled for lowest-common-denominator (386), and is the
> 'wrong' kernel for an Athlon ?

I'm not sure what the fuss is; a strict 386 kernel runs just fine
without any problems on an Athlon.  But anyway...

Dave, you are conflating "kernel compiled strictly for 386s" with
"compiled for lowest-common-denominator".

They are totally different configurations.  Isn't that why we have
"generic" now?

The latter is for distro boots.  The former is for that
386-as-a-firewall with 1MB of RAM, where it _really_ has to trim
everything it can, and no errata thank you.

I've not heard of anyone actually wanting a strict 386 kernel lately,
but strict 486 is not so unusual.

Just as some people want a P4 optimised kernel, and some people want a
K7 optimised kernel, so some people want a 386 or 486 or Pentium
optimised kernel.  Lowest-common-denominator means it runs on
everything, and isn't really anything to do with 386 any more - that's
not really the lowest-common-denominator, by virtue of the obvious
fact that pure 386 code isn't reliable on all other CPUs.

> We hashed this argument out a week or so ago, it seems the message
> didn't get across. YOU CAN NOT DISABLE ERRATA WORKAROUNDS IN A KERNEL
> THAT MAY POSSIBLY BOOT ON HARDWARE THAT WORKAROUND IS FOR.

I agree.  It shouln't be possible to boot on the wrong hardware: it
should refuse.

There is precedent: X86_GOOD_APIC && X86_LOCAL_APIC: when booted on a
non-MMX P5, it refuses to boot, because it does not contain the errata
workaround.

Unfortunately the kernel has opposite precedents too.

By selecting a PII kernel, it is possible to configure out the code
for X86_PPRO_FENCE and X86_F00F_BUG, yet as far as I can tell, those
_can_ possibly boot on kernels where the errata are needed, and nary a
printk is emitted for it.  Nasty bugs they are, too.

More generally than the CPU, you can also configure out BLK_DEV_RZ1000
which is another crucial workaround that needs to go in any
lowest-common-denominator kernel.  Basically, if you're building a
distro boot kernel, you must turn on all known workarounds.  That's
certainly lowest-common-denominator, but it's a far cry from the
configuration that a 386-as-firewall user wants.

> clearer?

If the kernel had a consistent policy so far, it would be more clear,
but it doesn't.

-- Jamie

Re: your mail

[Dave Jones]

On Tue, Sep 30, 2003 at 09:17:16AM +0100, John Bradford wrote:
 
 > Of course a kernel compiled strictly for 386s may seem to boot on an
 > Athlon but not work properly.  So what?  Just don't run the 'wrong'
 > kernel.

Wrong answer. How do you intend to install Linux when a distro boot
kernel is compiled for lowest-common-denominator (386), and is the
'wrong' kernel for an Athlon ?

We hashed this argument out a week or so ago, it seems the message
didn't get across. YOU CAN NOT DISABLE ERRATA WORKAROUNDS IN A KERNEL
THAT MAY POSSIBLY BOOT ON HARDWARE THAT WORKAROUND IS FOR.

clearer ?

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: your mail

[Jeff Garzik]

On Thu, Sep 18, 2003 at 08:35:36PM +0200, Robert Olsson wrote:

This issue is already fixed in 2.4 and 2.5 :)


> --- include/linux/netdevice.h.orig	2003-09-08 21:50:31.000000000 +0200
> +++ include/linux/netdevice.h	2003-09-17 17:27:58.000000000 +0200
> @@ -830,9 +830,9 @@
>  	local_irq_restore(flags);
>  }
>  
> -static inline void netif_poll_disable(struct net_device *dev)
> +static inline void netif_poll_sync(struct net_device *dev)
>  {
> -	while (test_and_set_bit(__LINK_STATE_RX_SCHED, &dev->state)) {
> +	while (test_bit(__LINK_STATE_RX_SCHED, &dev->state)) {
>  		/* No hurry. */
>  		current->state = TASK_INTERRUPTIBLE;
>  		schedule_timeout(1);

This patch breaks tg3 build, and operation...
tg3 wants a different operation than net/core/dev.c.

	Jeff

Re: your mail

[Jörn Engel]

On Tue, 9 September 2003 08:44:21 -0500, J B wrote:
> 
> A jffs2 internals question for the masses:
> 
> Besides the 128Kb max kmalloc issue, is there any restriction on the size 
> of an eraseblock that jffs2 can use?
> 
> I am using the slram driver with a 4Kb eraseblock size to create a 4Mb ram 
> device.  I mount jffs2 on top of this and everything appears to work until 
> the filesystem becomes full.  I try removing a file and the remove command 
> returns "rm: cannot unlink `foo' : No space left on device".  df reports 
> 100% usage.
> 
> Also, looking at the output from having CONFIG_JFFS2_FS_DEBUG=1, it appears 
> that garbage collection is constantly running and picking blocks from the 
> clean list because there are none on the dirty list.  Eventually even this 
> fails and the garbage collector loops and complains repeatedly:
> 
> "Argh. No free space left for GC.  nr_erasing_blocks is 0.  nr_free_blocks 
> is 0. (erasingempty: yes, erasependingempty: yes)
> jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28"
> 
> The thread_should_wake is returning 1 because the dirty size is > an 
> eraseblock, so it loops forever.
> 
> If I switch the eraseblock size in slram back to 64Kb, this problem does 
> not appear.  So again, are there any restricitons on how small of an 
> eraseblock size you can use, or is this something that hasn't ever really 
> been an issue?

Not completely unexpected.  I've always disliked the 5-eraseblock
number and started a discussion with David on the mtd list some time
ago.  For some reason, other matters occupied our minds so this was
unfinished.  But it is still in the archives.

The problem is that jffs2 doesn't need 5 eraseblocks, but rather 2 +
number_of_eraseblocks / some_constant.  So with 1024 eraseblocks, you
appear to need more than 5 (empirically proven :), while with 64
eraseblocks, you could get away with 5.  Maybe not, but there are very
few (no) bug reports, so it should be safe.

What jffs2 needs is to get rid of the constants for
JFFS2_RESERVED_BLOCKS_* and make them superblock variables instead.
Then we have to calculate them during mount time using some formula.
A patch doing the first step should still be in the archives, in the
same thread as the discussion or nearby.

Hope that helps!

Jörn

-- 
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens

Re: your mail

[William Lee Irwin III]

On Wed, Aug 27, 2003 at 09:25:23PM -0500, warudkar@vsnl.net wrote:
> Con - With swappiness set to 100, the apps do start up in 3 minutes and kswapd doesn't hog the CPU. But X is still unusable till all of them have started up.
> Wli - Sorry, vmstat segfaults on 2.6!

This is a bug in older versions of vmstat. Upgrade vmstat.


-- wli

Re: your mail

[Herbert Pötzl]

On Mon, Aug 25, 2003 at 01:45:25PM -0300, Marcelo Tosatti wrote:
> On Mon, 25 Aug 2003, Herbert Pötzl wrote:
> 
> > On Mon, Aug 25, 2003 at 10:53:21AM -0300, Marcelo Tosatti wrote:
> > >
> > > >
> > > >
> > > > Matthias Andree wrote:
> > > >
> > > > >On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
> > > > >
> > > > >
> > > > >>- 2.4.22-rc4 was released as 2.4.22 with no changes.
> > > > >>
> > > > >
> > > > >What are the plans for 2.4.23? XFS merge perhaps <hint>?
> > > > >
> > > >
> > > > Maybe some of Andrea's VM stuff?
> > >
> > > Definately. Thats the first thing I'm going to do after looking
> through
> > > "2.4.23-pre-patches" folder.
> >
> > any chance for the Bind Mount Extensions? 8-)
> 
> I haven't found time to at the patch yet but will do so soon.

fine, no problem, let me know if you need something
(like rediff, resend, explanation, etc ...)

best,
Herbert

Re: your mail

[Marcelo Tosatti]

On Mon, 25 Aug 2003, Herbert Pötzl wrote:

> On Mon, Aug 25, 2003 at 10:53:21AM -0300, Marcelo Tosatti wrote:
> >
> > >
> > >
> > > Matthias Andree wrote:
> > >
> > > >On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
> > > >
> > > >
> > > >>- 2.4.22-rc4 was released as 2.4.22 with no changes.
> > > >>
> > > >
> > > >What are the plans for 2.4.23? XFS merge perhaps <hint>?
> > > >
> > >
> > > Maybe some of Andrea's VM stuff?
> >
> > Definately. Thats the first thing I'm going to do after looking
through
> > "2.4.23-pre-patches" folder.
>
> any chance for the Bind Mount Extensions? 8-)

I haven't found time to at the patch yet but will do so soon.

Re: your mail

[Herbert Pötzl]

On Mon, Aug 25, 2003 at 10:53:21AM -0300, Marcelo Tosatti wrote:
> 
> >
> >
> > Matthias Andree wrote:
> >
> > >On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
> > >
> > >
> > >>- 2.4.22-rc4 was released as 2.4.22 with no changes.
> > >>
> > >
> > >What are the plans for 2.4.23? XFS merge perhaps <hint>?
> > >
> >
> > Maybe some of Andrea's VM stuff?
> 
> Definately. Thats the first thing I'm going to do after looking through
> "2.4.23-pre-patches" folder.

any chance for the Bind Mount Extensions? 8-)

best,
Herbert

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

Re: your mail

[Greg KH]

On Mon, Aug 18, 2003 at 10:21:22AM +0400, "Andrey Borzenkov"  wrote:
> 
> just to show what I expected from sysfs - here is entry from Solaris
> /devices:
> 
> brw-r-----   1 root     sys       32,240 Jan 24  2002 /devices/pci@16,4000/scsi@5,1/sd@0,0:a
> 
> this entry identifies disk partition 0 on drive with SCSI ID 0, LUN 0
> connected to bus 1 of controller in slot 5 of PCI bus identified
> by 16. Now you can use whatever policy you like to give human
> meaningful name to this entry. And if you have USB it will continue
> further giving you exact topology starting from the root of your
> device tree.
> 
> and this path does not contain single logical id so it is not subject
> to change if I add the same controller somewhere else.
> 
> hopefully it clarifies what I mean ...

Hm, a bit.  First, have you looked at what sysfs provides?  Here's one
of my machines and tell me if it has all the info you are looking for:

$ tree /sys/bus/scsi/
/sys/bus/scsi/
|-- devices
|   `-- 0:0:0:0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
`-- drivers
    `-- sd
        `-- 0:0:0:0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0

$ tree /sys/block/sda/
/sys/block/sda/
|-- dev
|-- device -> ../../devices/pci0000:00/0000:00:1e.0/0000:02:05.0/host0/0:0:0:0
|-- queue
|   |-- iosched
|   |   |-- antic_expire
|   |   |-- read_batch_expire
|   |   |-- read_expire
|   |   |-- write_batch_expire
|   |   `-- write_expire
|   `-- nr_requests
|-- range
|-- sda1
|   |-- dev
|   |-- size
|   |-- start
|   `-- stat
|-- sda2
|   |-- dev
|   |-- size
|   |-- start
|   `-- stat
|-- sda3
|   |-- dev
|   |-- size
|   |-- start
|   `-- stat
|-- sda4
|   |-- dev
|   |-- size
|   |-- start
|   `-- stat
|-- size
`-- stat


Now, from that you can see exactly where my scsi device is in the pci
tree, and you can see in the block directory, what block device is
assigned to what physical device in the device tree.  Then there are 4
partitions on this disk, all what those specific paramaters.

So, when sda shows up, udev can determine that it lives on a specific
scsi device, located in a specific place in the pci space, and that it
has some number of partitions, all of specific sizes, wich specific
major/minor numbers.  It can then create all of the /dev links based on
this.

Please, take a few minutes looking at the existing sysfs tree on Linux.
If you then have any specific questions, I would be glad to answer
them.

Hope this helps,

greg k-h

Re: your mail

[James Morris]

On Fri, 15 Aug 2003, kartikey bhatt wrote:

> Hi James.
> A little bit work for you.
> Somebody on mailing list commented that you should *really* go for better
> algorithm like CAST6 (rfc2612) to be included in kernel.
> This time I'm sending you cast6.c (cast6 cipher algorithm) implementation.
> But this time it's a patch.

Cool.  Unfortunately the patch is corrupted, please try sending as an 
attachment or via a different mail system.


- James
-- 
James Morris
<jmorris@intercode.com.au>

Re: your mail

[Linus Torvalds]

On Sun, 3 Aug 2003, hp wrote:
>
> so He/You did lock me out, too?
> whithout any notice. by what reason?

Maybe because this has nothing to do with the kernel?

It's ok to discuss kernel issues on the kernel mailing list, but we've had 
tons of totally off-topic flames, rants and general noise.

To the point that a lot of people don't even have time to follow 
linux-kernel any more, since a lot of the discussion has nothing to do 
with the technical kernel work.

Since some of these rants are started (and kept going) by people who don't
ever seem to actually get involved in _real_ kernel-related technical
discussions, David felt that one way to curb it was to just blacklist 
people who repeatedly post things that aren't related to the kernel.

It's ok to be off-topic every once in a while, but it's not ok to 
consistently be so.

That said, David is also not the most politic person I know, and I suspect 
this could have been handled slightly more gracefully. One potential less 
annoying approach is to not block posting from people, but rewrite the 
subject line for such posters with a prepended "[OFF-TOPIC]", and just let 
people filter those out on the receiving end. Or just automatically shunt 
them off to another list.

I dunno. I don't personally much care - but I've never been the maintainer 
of the mailing list, and I sure as hell don't ever want to be. Whoever is 
the maintainer gets to set the rules.

			Linus

Re: your mail

[Jochen Reinwand]

> > Nevertheless it would be possible to make this distribution. But there
> > are a lot of things that have to be figured out. A basic problem: Do we
> > use a Windows/DOS or a Linux/Unix system for extracting the files from
> > Windows and for building the new system.
> > The following functions need further inspection:
> >
> > What boot system to use? Booting from a Windows CD is possible, but
> > building a new bootable CD is better. The ERD could be used.
> > If we only have Linux how can we build this ERD. The necessary file are
> > installed with Windows in the directory EBD and should be somewhere in
> > the CAB files on the Windows CD. Copy them to disk is easy, but how to do
> > a "sys a:" from within Linux?
>
> Well, I booted Dos 7 (from 98se) on my hard drive with Dosemu 1.1.5 as
> root and executed "sys c: a:". And the resulting boot disk works! You
> will need a working Dos installed, though. Or at least a boot floppy.

Nice idea! Perhaps it is possible to execute MS-DOS "sys" with some tricks 
without installing a complete 98SE...
It would be nice to have small a Linux prog to do the same, but booting the 
Win98SE cd with dosemu would be a solution if this cannot be done.
Seems to be the only real problem I face in this project......

I believe I found it! On the win98se cd I found in tools/mtsutil/fat32ebd/ the 
MS-DOS tool that does exactly what I want to do without using "sys". Seems 
like image.dsk "formats" and "sys's" a floppy be simply doing a
cat image.dsk > /dev/fd0
I will reboot and test it after sending this mail ;-)

> > Can we access CAB files from within Linux at all? I have not searched for
> > a tool by now...
>
> You can extract cabs with extract.exe (from windir\command, or it can be
> found on the windows install cd, too). Seems to work perfectly with both
> Dosemu and Wine under Linux.

I found a really cool Linux tool called cabextract 
(http://www.kyz.uklinux.net/cabextract.php3). I can extract the complete 
Win98SE CABs from cd! But that's also the problem. I can only extract 
everything. I wrote an e-mail to the author requesting a possibility to 
specify the files to be extracted.

Jochen

Re: your mail

[Eemeli Kantola]

Jochen Reinwand wrote:

> AutoScan=1     ; Can't remember what that option is good for...

If I remember correctly, that is used by Windows only to automatically 
scan disks at startup after a system crash or something. Not needed for 
plain dos.

> Nevertheless it would be possible to make this distribution. But there are a 
> lot of things that have to be figured out. A basic problem: Do we use a 
> Windows/DOS or a Linux/Unix system for extracting the files from Windows and 
> for building the new system.
> The following functions need further inspection:
> 
> What boot system to use? Booting from a Windows CD is possible, but building a 
> new bootable CD is better. The ERD could be used.
> If we only have Linux how can we build this ERD. The necessary file are 
> installed with Windows in the directory EBD and should be somewhere in the 
> CAB files on the Windows CD. Copy them to disk is easy, but how to do a "sys 
> a:" from within Linux?

Well, I booted Dos 7 (from 98se) on my hard drive with Dosemu 1.1.5 as 
root and executed "sys c: a:". And the resulting boot disk works! You 
will need a working Dos installed, though. Or at least a boot floppy.

> Can we access CAB files from within Linux at all? I have not searched for a 
> tool by now...

You can extract cabs with extract.exe (from windir\command, or it can be 
found on the windows install cd, too). Seems to work perfectly with both 
Dosemu and Wine under Linux.


-Eemeli

Re: your mail

[Jochen Reinwand]

[-- Attachment #1: Type: text/plain, Size: 5288 bytes --]

Hi!

> I have an app for my business that's been running under DOS for about
> 20 years.  I'm (still) working on porting it to Linux because it's
> getting close to the point where MSDOS6.22 won't be able to cope with
> the size of disc partitions I'm going to need.  I've tried using the
> W98 DOS to run this app, but it failed miserably every time and I
> don't know why.  I haven't spent much time looking for the reasons but
> it looks like the memory management - there are several versions of
> EMM386.SYS and HIMEM.SYS with are supplied with the various flavours
> of DOS and I haven't worked out what combinations are OK and what not.

There are a few problems, when using a "Windows-DOS" like a normal MS-DOS. The 
first problem is MSDOS.SYS (see below). Another Problem that took me a long 
time to figure out were the new commands in CONFIG.SYS. E.g. you should 
normale use the following setting for "DOS":
DOS=HIGH,UMB,NOAUTO

HIGH and UMB are well known, but NOAUTO is VERY important. If it is not 
present, Windows/DOS will load drivers if you don't load them. So if no line 
like
device=C:\MSDOS\himem.sys
is present, himem.sys will be loaded automatically with the parameters Windows 
thinks are good for you!
Another example: A lot of old programs have problems, when emm386.exe is 
loaded. So you comment out the line in config.sys, reboot and... EMM386 is 
once again loaded and your program is still not working. So you should set 
NOAUTO and after disabling EMM386 in CONFIG.SYS it is _really_ disabled.

I found a lot of info about the boot process and other interesting things 
about "Windows-DOS". But a lot of it is in German and only on paper. So the 
information has to be digitized and translated. Or you can search for more 
info on the net. Btw: Has M$ really deleted all DOS info from there web 
pages? I found a lot of interesting stuff there...
Would be useful to include it in a distribution...

> Are you saying that the W98 DOS will allow me to use bigger discs?
> If so then I'm very interested indeed.  My understanding is that even
> with the W98 VFAT you can still only go up to about 8G, is that right?

No. The 8GB limit is a hardware/BIOS problem.
On my system:

# fdisk -l /dev/hde
(...)
/dev/hde7           639      5005  35077896    b  Win95 FAT32
(...)

35GB FAT32 formated and now problems under Windows, Linux or MS-DOS (7.x)!

> > I once installed 98SE and stripped of all Windows parts. After a few very
> > easy tricks (e.g. add/change some lines to/in msdos.sys)
>
> Tell us more!

MSDOS.SYS controls the start of Windows. You can even change it to an extend 
that Windows isn't loaded at all!
I changed for example:

In the [Paths] section:

;WinDir=C:\WINDOWS
;WinBootDir=C:\WINDOWS
WinDir=C:\MSDOS
WinBootDir=C:\MSDOS

If it is MS-DOS it should have it's own place ;-)

More important:

[Options]
BootMulti=1    ; Make it possible to start DOS
BootGUI=0      ; Don't start Windows, only MS-DOS. Now you don't need any 
               ; Windows files at all
Logo=0         ; Don't display this silly Windows logo!
AutoScan=1     ; Can't remember what that option is good for...

I attached a text I found about MSDOS.SYS. I don't know where...

> > Perhaps it would be a good idea to build an MS-DOS distribution with that
> > version. Don't get it wrong! I'm not talking about illegal copies. [snip]
> >
> > Anybody interested in such an distribution?
>
> Very much so.  It could give me a breathing space I think I might need.

I started this "project" a long time ago and made a GREAT mistake. I tried to 
build up a C:\MSDOS directory containing everything I found useful for a DOS 
distribution. Now I don't know where all these files came from. So it will 
get hard to figure it out again.
Another problem is that I have a German version of Windows. Even filenames 
differ between the different international version. I doubt that you will 
find files like allgem.txt and antwort.txt in an English version of 
Windows...

Nevertheless it would be possible to make this distribution. But there are a 
lot of things that have to be figured out. A basic problem: Do we use a 
Windows/DOS or a Linux/Unix system for extracting the files from Windows and 
for building the new system.
The following functions need further inspection:

What boot system to use? Booting from a Windows CD is possible, but building a 
new bootable CD is better. The ERD could be used.
If we only have Linux how can we build this ERD. The necessary file are 
installed with Windows in the directory EBD and should be somewhere in the 
CAB files on the Windows CD. Copy them to disk is easy, but how to do a "sys 
a:" from within Linux?
Or is it possible to extract the boot image from the Windows CD?

Can we access CAB files from within Linux at all? I have not searched for a 
tool by now...

The greatest problem: If you make a build system running under DOS or DOS 
compatible Windows: You can only use it, if you already have a DOS compatible 
system! Normally someone wants such a distribution builder, if he/she only 
has a Unix or DOS incompatible Windows system.
And don't forget: Linux is much more powerful in doing scripting tasks ;-)

Comments welcome. Especially if someone has an idea how all this could be done 
really easy...

Jochen

[-- Attachment #2: msdossys.txt --]
[-- Type: text/plain, Size: 5437 bytes --]

MSDOS.SYS: Special Startup Values

Windows 95 Setup creates a hidden, read-only system file named MSDOS.SYS in
the root of the computer's boot drive. This file contains important paths used
to locate other Windows files, including the Registry. MSDOS.SYS also supports
an [Options] section, which you can add to tailor the startup process.

The following example shows a typical file with default values:

------------------------------------------------------------------------------
[Options]
BootGUI=1

[Paths]
WinDir=C:\WINDOWS
WinBootDir=C:\WINDOWS
HostWinBootDrv=C
------------------------------------------------------------------------------

Most values in the [Options] section are Boolean  that is, the value can be 1
(enabled) or 0 (disabled). The following table describes entries in MSDOS.SYS,
using the typical default values.



MSDOS.SYS Values


Entry               Description


[Paths] section:

HostWinBootDrv=c    Defines the location of the boot drive root directory.
WinBootDir=         Defines the location of the necessary startup files. The
                    default is the directory specified during Setup;
                    for example, C:\WINDOWS.
WinDir=             Defines the location of the Windows 95 directory as
                    specified during Setup.

[Options] section:

BootDelay=n         Sets the initial startup delay to n seconds. The default
                    is 2. BootKeys=0 disables the delay. The only purpose of
                    the delay is to give the user sufficient time to press F8
                    after the Starting Windows message appears.
BootFailSafe=       Enables Safe Mode for system startup. The default is 0.
                    (This setting is enabled typically by equipment
                    manufacturers for installation.)
BootGUI=            Enables automatic graphical startup into Windows 95. The
                    default is 1.
BootKeys=           Enables the startup option keys (that is, F5, F6, and F8).
                    The default is 1. Setting this value to 0 overrides the
                    value of BootDelay=n and prevents any startup keys from
                    functioning. This setting allows system administrators to
                    configure more secure systems. (These startup keys are
                    described in Chapter 35, "General Troubleshooting.")
BootMenu=           Enables automatic display of the Windows 95 Startup menu,
                    so that the user must press F8 to see the menu. The
                    default is 0. Setting this value to 1 eliminates the need
                    to press F8 to see the menu.
BootMenuDefault=#   Sets the default menu item on the Windows Startup menu;
                    the default is 3 for a computer with no networking
                    components, and 4 for a networked computer.
BootMenuDelay=#     Sets the number of seconds to display the Windows Startup
                    menu before running the default menu item. The default is
                    30.
BootMulti=          Enables dual-boot capabilities. The default is 0. Setting
                    this value to 1 enables the ability to start MS-DOS by
                    pressing F4 or by pressing F8 to use the Windows Startup
                    menu.
BootWarn=           Enables the Safe Mode startup warning. The default is 1.
BootWin=            Enables Windows 95 as the default operating system.
                    Setting this value to 0 disables Windows 95 as the
                    default; this is useful only with MS-DOS version 5 or 6.x
                    on the computer. The default is 1.
DblSpace=           Enables automatic loading of DBLSPACE.BIN.
                    The default is 1.
DoubleBuffer=       Enables loading of a double-buffering driver for a SCSI
                    controller. The default is 0. Setting this value to 1
                    enables double-buffering, if required by the SCSI
                    controller.
DrvSpace=           Enables automatic loading of DRVSPACE.BIN.
                    The default is 1.
LoadTop=            Enables loading of COMMAND.COM or DRVSPACE.BIN at the top
                    of 640K memory. The default is 1. Set this value to 0 with
                    Novell® NetWare® or any software that makes assumptions
                    about what is used in specific memory areas.
Logo=               Enables display of the animated logo. The default is 1.
                    Setting this value to 0 also avoids hooking a variety of
                    interrupts that can create incompatibilities with certain
                    memory managers from other vendors.
Network=            Enables Safe Mode With Networking as a menu option. The
                    default is 1 for computers with networking installed. This
                    value should be 0 if network software components are not
                    installed.



Tip for Starting an Earlier Version of MS-DOS
If you installed Windows 95 in its own directory, the earlier version of
MS-DOS is preserved on your hard disk. If you set BootMulti=1 in the [Options]
section in the Windows 95 version of MSDOS.SYS, you can start the earlier
version of MS-DOS by pressing F4 when the Starting Windows message appears
during system startup.

Re: your mail

[Ged Haywood]

Hi theere,

On Sun, 6 Jul 2003, Jochen Reinwand wrote:

> The latest and best MS-DOS is as far as I know the DOS included in Windoze 
> 98SE. The One from ME is much smaller and misses a lot of tools. Although it 
> is really there, no matter what M$ says...

I have an app for my business that's been running under DOS for about
20 years.  I'm (still) working on porting it to Linux because it's
getting close to the point where MSDOS6.22 won't be able to cope with
the size of disc partitions I'm going to need.  I've tried using the
W98 DOS to run this app, but it failed miserably every time and I
don't know why.  I haven't spent much time looking for the reasons but
it looks like the memory management - there are several versions of
EMM386.SYS and HIMEM.SYS with are supplied with the various flavours
of DOS and I haven't worked out what combinations are OK and what not.

Are you saying that the W98 DOS will allow me to use bigger discs?
If so then I'm very interested indeed.  My understanding is that even
with the W98 VFAT you can still only go up to about 8G, is that right?
It would be nice to know - although it's OK for my app, I'll be long
dead before we use that much for our product file... :(

> I once installed 98SE and stripped of all Windows parts. After a few very easy 
> tricks (e.g. add/change some lines to/in msdos.sys)

Tell us more!

> Perhaps it would be a good idea to build an MS-DOS distribution with that 
> version. Don't get it wrong! I'm not talking about illegal copies. [snip]
> 
> Anybody interested in such an distribution?

Very much so.  It could give me a breathing space I think I might need.

73,
Ged.

Re: your mail

[Jochen Reinwand]

The latest and best MS-DOS is as far as I know the DOS included in Windoze 
98SE. The One from ME is much smaller and misses a lot of tools. Although it 
is really there, no matter what M$ says...

I once installed 98SE and stripped of all Windows parts. After a few very easy 
tricks (e.g. add/change some lines to/in msdos.sys) you have a really good 
MS-DOS. VFAT is really important with today's harddrives...

Perhaps it would be a good idea to build an MS-DOS distribution with that 
version. Don't get it wrong! I'm not talking about illegal copies. It should 
be possible to write scripts that extract the necessary files from a 98SE CD, 
build ZIPs out of them, make a boot cd using the ERD (Emergency Rescue Disk) 
and so on. So everyone owning a legal 98SE copy can make his/her own _legal_ 
MS-DOS distribution with the help of free tools and scripts.
Then it would be nice to provide additional support for free tools and djgpp. 
Everything on one cd and a real cool Unix compatible MS-DOS is ready ;-)

Anybody interested in such an distribution?

Jochen

On Sunday 06 July 2003 06:06, Jim Hartley wrote:
> DOS 7.10? I guess that's one of those "M$-hidden-under-Windoze-DOS"
> versions? It gets confusing, since M$ used 7.x for those, while there is
> also an IBM PC-DOS 7.0 which is a "real" DOS and that's the one I always
> think of when DOS 7 is mentioned. That one is my favorite, I still have
> copies around, especially in the form of quick-boot utility diskettes. I
> guess one reason I like it is because I got it LEGALLY for free - a
> reward for participating in the Beta test. (Then again, those who know
> me know I will go to great lengths to avoid using ANY Micro$quish
> products.)
>
> Jim Hartley

Re: your mail

[Jim Hartley]

DOS 7.10? I guess that's one of those "M$-hidden-under-Windoze-DOS" 
versions? It gets confusing, since M$ used 7.x for those, while there is 
also an IBM PC-DOS 7.0 which is a "real" DOS and that's the one I always 
think of when DOS 7 is mentioned. That one is my favorite, I still have 
copies around, especially in the form of quick-boot utility diskettes. I 
guess one reason I like it is because I got it LEGALLY for free - a 
reward for participating in the Beta test. (Then again, those who know 
me know I will go to great lengths to avoid using ANY Micro$quish products.)

Jim Hartley

Lyvim Xaphir wrote:

>I agree with Jim Hartley.  This is pretty much a nonissue.  Dos isn't
>even supported by M$ any more as far as I know, and I've never heard of
>any case where M$ has gone after an individual for such a thing in the
>past anyway.  Their only concern are large scale pirates selling on the
>black market or corporations doing *current* release software on a
>significant basis.  They pretty much leave the individuals alone.
>
>And I don't think anyone will ever mistake this place as a site for
>swapping of illegal software.  This isn't anywhere near that class and
>to suggest that it might be is kind of edging over into the pinhead
>arena.
>
>On another note, if I was going to share a copy of Dos it would be
>version 7.10 because of it's superior memory management and stability. 
>7.10 was partially a response in 98 to gamer's claims of
>incompatibilities in winblows with some of the more sophisticated Dos
>games like Elder Scrolls Arena, Duke Nukem 3d and others.  It was the
>last best version of Dos.
>
>
>On Sat, 2003-07-05 at 10:53, Ged Haywood wrote:
>  
>
>>Hi there,
>>
>>On Sat, 5 Jul 2003, Jim Hartley wrote:
>>
>>    
>>
>>>I think this one is WAY, WAY under the radar.
>>>      
>>>
>>I'd agree if this weren't a public mailing list.
>>
>>I'm more concerned with the reputation of the list.  If it earns a
>>reputation as a place for swapping pirate copies of software, that
>>might not be a Good Thing.
>>
>>There has to be a way for the guy to get what he wants done without
>>broadcasting a technical infringement of a copyright owned by a ten
>>billion dollar potential adversary.
>>
>>73,
>>Ged.
>>    
>>
>
>--LX
>
>  
>

Re: your mail

[Ged Haywood]

Hi there,

On Sat, 5 Jul 2003, Jim Hartley wrote:

> I think this one is WAY, WAY under the radar.

I'd agree if this weren't a public mailing list.

I'm more concerned with the reputation of the list.  If it earns a
reputation as a place for swapping pirate copies of software, that
might not be a Good Thing.

There has to be a way for the guy to get what he wants done without
broadcasting a technical infringement of a copyright owned by a ten
billion dollar potential adversary.

73,
Ged.

Re: your mail

[Jim Hartley]

If he owns a legal copy of the product (he says he'd do it himself if he 
had a floppy drive on the machine), one would have to be nitpicking in 
the extreme to call this a violation. He COULD send his copy to someone 
who would build the hdimage and send it back to him, that would be 
legal, wouldn't it? (IANAL) Getting someone who owns an identical copy 
of the DOS to send him the image without all the bother really doesn't 
sound any worse.

In any case, who is going to bother about suing one individual over a 
copy of **DOS** in this day and age? Most people have forgotten what DOS 
is by now! If he was doing a few thousand copies it might be a problem, 
but I think this one is WAY, WAY under the radar.

Jim Hartley

Ged Haywood wrote:

>Hi there,
>
>On Fri, 4 Jul 2003, Darryl Perry wrote:
>
>  
>
>>Does anybody have an hdimage file with MSDOS6.x
>>installed that I can use?
>>    
>>
>
>Do be careful.  That sounds like abuse of copyright to me.
>
>  
>
>>I'd make it myself, but I don't have a floppy drive on my linux box.
>>    
>>
>
>Installing a floppy drive is a lot cheaper than defending a lawsuit...
>
>73,
>Ged.
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>

Re: your mail

[Ged Haywood]

Hi there,

On Fri, 4 Jul 2003, Darryl Perry wrote:

> Does anybody have an hdimage file with MSDOS6.x
> installed that I can use?

Do be careful.  That sounds like abuse of copyright to me.

> I'd make it myself, but I don't have a floppy drive on my linux box.

Installing a floppy drive is a lot cheaper than defending a lawsuit...

73,
Ged.

Re: your mail

[Maciej Soltysiak]

> - Where I can find a list of RFCs?
http://www.ietf.org/rfc

There is a RFC Index link

> - Where I can find a cdfs format ( cd file system format)?
You mean kernel drivers or the specification?
The kernel drivers are in the stock kernel.

Regards,
Maciej

Re: your mail

[Gerd Knorr]

> Actually it does in some cases. I know of two devices that have analog
> tuners on an smbus-like interface (OV511 USB TV and W9967CF USB TV). The
> tuner can be controlled using a pair of i2c_smbus_write_byte_data()
> calls.

Hmm, maybe we should rename the SMBUS class to SENSORS or MAINBOARD or
something like that?  I assumed you smbus interfaces are used for
mainboard sensors only ...

> Would a patch that adds smbus algorithm support to tuner.c be
> acceptable?

Yes.  Certainly makes more sense than duplicating the whole rest of
tuner.c just for a smbus-aware tuner driver ;)

  Gerd

-- 
sigfault

Re: your mail

[Greg KH]

On Wed, Apr 30, 2003 at 06:39:41PM -0300, Mauricio Oliveira Carneiro wrote:
> But I can't see it mounted anywhere in my system, nor can I mount it by 
> hand since I don't know the device filename (/dev/?) .

Have you read the Linux USB Guide at http://www.linux-usb.org/ ?

If you still have questions/problems after reading that, try asking this
on the linux-usb-users mailing list.  The people there can help you out.

thanks,

greg k-h

Re: your mail

[Francois Romieu]

Bloch, Jack <Jack.Bloch@icn.siemens.com> :
> Is there example driver source code available for a MUSYCC CN8478 device?
> Please CC me directly on any answers. 

http://ww.google.com/search?q=musycc.c+bsd&ie=ISO-8859-1&hl=fr&lr=

Example source code for a complete reset of a PEB20534 device operating in
last descriptor address control mode will be welcome too.

Regards

--
Ueimor

RE: your mail

[Dennis Castleman]

[-- Attachment #1: Type: text/plain, Size: 3089 bytes --]

Thanks Ralf

Looks like I made the correct call when I picked MIPS32 Kernel.
Look like some of my preformance issues are in Montavistas 2.95.3 toolchain,
it's generating code that looks like this

0000000000000000 <bitBufferCreate>:
   0: 27bdffe0  addiu $sp,$sp,-32
   4: afbf001c  sw  $ra,28($sp)
   8: afb20018  sw  $s2,24($sp)
   c: afb10014  sw  $s1,20($sp)
  10: afb00010  sw  $s0,16($sp)
  14: 00809021  move  $s2,$a0
  18: 00a08021  move  $s0,$a1
  1c: 00c08821  move  $s1,$a2
  20: 24040001  li  $a0,1
  24: 24050010  li  $a1,16
  28: 3c020000  lui $v0,0x0
  2c: 24420000  addiu $v0,$v0,0

but if I use the 2.95.3 toolchain I build myself it's
generating code that looks like this.

0000000000000000 <bitBufferCreate>:
   0: 27bdffe0  addiu $sp,$sp,-32
   4: afb20018  sw  $s2,24($sp)
   8: 00809021  move  $s2,$a0
   c: afb00010  sw  $s0,16($sp)
  10: 00a08021  move  $s0,$a1
  14: afb10014  sw  $s1,20($sp)
  18: 00c08821  move  $s1,$a2
  1c: 24040001  li  $a0,1
  20: 24050010  li  $a1,16
  24: 3c020000  lui $v0,0x0
  28: 24420000  addiu $v0,$v0,0


Any idea whats up MV tool-chain.


Dennis 


-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Thursday, April 17, 2003 5:04 PM
To: Dennis Castleman
Cc: linux-mips@linux-mips.org
Subject: Re: your mail


On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:

> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?

As a rule of thumb - less performance.  64-bit code is typically larger
resulting in lower cache hit rate.  And since performance optimization
these days is essentially equivalent to maximising the cache hit rate
going 64-bit usually means a performance drop due to the drastically
larger size of code and data.

On the positive side for 64-bit stuff there's the possibility to do
64-bit computations with just one instruction, move data with less
instructions, use twice as many double precission fp registers that are
offered by 64-bit ABIs and more calling sequences.

The first two paragraphs were sort of a generic statement regarding
32-bit vs. 64-bit software on MIPS processors and affect both kernel and
userspace.  There's a few additional issues with the Linux kernel.
The 32-bit kernels requires all memory to be addressable through KSEG0
which limits it to at most 512MB; typically the limit is more like 256MB.
Memory above 512MB physical address can only be used as highmem.  That's
fairly inefficient and requires alot of special care when writing new
kernel software.  For processors that suffer from virtual aliases in
their data cache highmem currently is frighteningly inefficient - and
high memory pressure on lowmem doesn't help either.  So from a certain
point on that's simply making a 64-bit kernel is simply the better
idea - even for running 32-bit software.  That in particular applies
to very I/O intensive stuff.

In short - the right choice is a tradeoff between the hardware platform
and the application's requirements.  Choose wrong and you'll curse
loudly :-)

  Ralf

[-- Attachment #2: Type: text/html, Size: 5525 bytes --]

Re: your mail

[Ralf Baechle]

On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:

> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?

As a rule of thumb - less performance.  64-bit code is typically larger
resulting in lower cache hit rate.  And since performance optimization
these days is essentially equivalent to maximising the cache hit rate
going 64-bit usually means a performance drop due to the drastically
larger size of code and data.

On the positive side for 64-bit stuff there's the possibility to do
64-bit computations with just one instruction, move data with less
instructions, use twice as many double precission fp registers that are
offered by 64-bit ABIs and more calling sequences.

The first two paragraphs were sort of a generic statement regarding
32-bit vs. 64-bit software on MIPS processors and affect both kernel and
userspace.  There's a few additional issues with the Linux kernel.
The 32-bit kernels requires all memory to be addressable through KSEG0
which limits it to at most 512MB; typically the limit is more like 256MB.
Memory above 512MB physical address can only be used as highmem.  That's
fairly inefficient and requires alot of special care when writing new
kernel software.  For processors that suffer from virtual aliases in
their data cache highmem currently is frighteningly inefficient - and
high memory pressure on lowmem doesn't help either.  So from a certain
point on that's simply making a 64-bit kernel is simply the better
idea - even for running 32-bit software.  That in particular applies
to very I/O intensive stuff.

In short - the right choice is a tradeoff between the hardware platform
and the application's requirements.  Choose wrong and you'll curse
loudly :-)

  Ralf

Re: your mail

[Greg Lindahl]

On Thu, Apr 17, 2003 at 11:17:10AM -0700, Jun Sun wrote:

> It really depends on the applications.  The biggest gain from 64bit,
> other than the obviously bigger address space, is 64bit data
> manipulation.  A single 64bit instruction (add/sub/...) is carried
> out by several instructions in 32bit.

A big gain is the increased # of registers and better calling
sequence. Everyone sees that, not just people who want to use 64-bit
integers. At the moment you need to run the 64-bit kernel -- and the
new binutils & glibc -- in order to get n32 programs to work.

-- greg

Re: your mail

[Jun Sun]

On Thu, Apr 17, 2003 at 10:53:57AM -0700, Dennis Castleman wrote:
> ALL
> 
> Anybody know the performance differences I can expect using a MIPS 5K core
> @250 Mhz in 64bit mode versus 32bit mode?
>

It really depends on the applications.  The biggest gain from 64bit,
other than the obviously bigger address space, is 64bit data
manipulation.  A single 64bit instruction (add/sub/...) is carried
out by several instructions in 32bit.

If your apps are heavy on 64bit operations, then you gain.
Otherwise I suspect no performance gain or even possibly a little 
worse performance due more stress on cache/memory subsystems.

I am sure others with more 64bit experience probably have more 
to say.  :)


Jun

Re: your mail

[Keith Owens]

On Fri, 4 Apr 2003 16:38:50 -0800 , 
Ed Vance <EdV@macrolink.com> wrote:
>On Fri, Apr 04, 2003 at 3:21 PM, Keith Owens wrote:
>> 
>> On Fri, 4 Apr 2003 14:10:16 -0800 , 
>> Ed Vance <EdV@macrolink.com> wrote:
>> >Perhaps there is a middle ground. Leave the list open, but require a
>> >confirmation reply prior to passing along posts from addresses that:
>> >
>> >1. are not members of the list, AND
>> >2. have not previously done a proper confirmation reply.
>> 
>> 30 seconds after doing that, the spammers will forge email that claims
>> to be from LT, AC, DM, MT etc.  Not to mention all the viruses that
>> forge the headers.  Verification by 'From:' line on an open list is
>> pointless.
>> 
>The goal was to greatly reduce, in one swell foop, the volume of spam that
>the filters (and postmaster) must interactively deal with. I thought that
>perhaps this method could replace one of more of the troublesome filtering
>techniques to achieve the same net spam reduction without evoking as much
>whining.

Paraphrase: Replace filtering code that catches spam with filtering
code based on checking header content that can be trivially forged by
spammers.

>Matti, 
>Roughly what percentage of the spam actually hitting vger today (and
>bouncing off) is based on Keith's flavor of spoofing? Is it even 1 percent? 

Current figures are irrelevant, spammers react to spam filters and they
react very quickly[*].  If you replace "reject HTML bodies" with "allow
HTML based on known From: lines" then the spammers will send HTML
bodies with forged headers, because they know it will get through.
That will require the original HTML filters to be reintroduced, the end
result is you added an extra step for new posters without reducing the
spam or users whining "my mail does not get through".

[*] About 24 hours after slashdot carried a story on Baysian spam
    filters, I started receiving HTML spam that contained comments that
    were designed to fool the Baysian filters, like this.

    FREE 1 MONTH SUPP<!--kernel-->Y WITH THIS

    The comment has no effect on the spam display but the use of
    non-spam words skews the Baysian rules on whether the content is
    spam or not.

RE: your mail

[Ed Vance]

On Fri, Apr 04, 2003 at 3:21 PM, Keith Owens wrote:
> 
> On Fri, 4 Apr 2003 14:10:16 -0800 , 
> Ed Vance <EdV@macrolink.com> wrote:
> >Perhaps there is a middle ground. Leave the list open, but require a
> >confirmation reply prior to passing along posts from addresses that:
> >
> >1. are not members of the list, AND
> >2. have not previously done a proper confirmation reply.
> 
> 30 seconds after doing that, the spammers will forge email that claims
> to be from LT, AC, DM, MT etc.  Not to mention all the viruses that
> forge the headers.  Verification by 'From:' line on an open list is
> pointless.
> 

Keith,

No single method is perfect. Your point is well taken. 

The goal was to greatly reduce, in one swell foop, the volume of spam that
the filters (and postmaster) must interactively deal with. I thought that
perhaps this method could replace one of more of the troublesome filtering
techniques to achieve the same net spam reduction without evoking as much
whining.

imperfect != pointless

Matti, 
Roughly what percentage of the spam actually hitting vger today (and
bouncing off) is based on Keith's flavor of spoofing? Is it even 1 percent? 

Cheers,
Ed

---------------------------------------------------------------- 
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

Re: your mail

[Keith Owens]

On Fri, 4 Apr 2003 14:10:16 -0800 , 
Ed Vance <EdV@macrolink.com> wrote:
>Perhaps there is a middle ground. Leave the list open, but require a
>confirmation reply prior to passing along posts from addresses that:
>
>1. are not members of the list, AND
>2. have not previously done a proper confirmation reply.

30 seconds after doing that, the spammers will forge email that claims
to be from LT, AC, DM, MT etc.  Not to mention all the viruses that
forge the headers.  Verification by 'From:' line on an open list is
pointless.

RE: your mail

[William Scott Lockwood III]

That is the best suggestion I've yet seen.  It's an excellent idea!

On Fri, 4 Apr 2003, Ed Vance wrote:

> On Fri, Apr 04, 2003 at 12:38 PM, Matti Aarnio wrote:
> > [snip]
> > A somewhat better anti-spam filter method, than what we use presently
> > is to use strictly CLOSED list -- e.g. must be a member to post.
> > I have seen what kind of pains closed lists are, I even moderate
> > couple small ones.
> >
> > However we are deliberately running "open for posting, subject to
> > filters" policy, which lets questions and reports to come from
> > non-subscribers.
> >
>
> Perhaps there is a middle ground. Leave the list open, but require a
> confirmation reply prior to passing along posts from addresses that:
>
> 1. are not members of the list, AND
> 2. have not previously done a proper confirmation reply.
>
> The unconfirmed posts would time out and disappear after a decent interval,
> to prevent constipation.
>
> So, anybody could still post, the members would not be inconvenienced, and
> non-members would be inconvenienced only on their first post from each
> address they post from. This would preserve the "real time" nature of the
> list, while gaining the assurance that all who post are life-forms, even if
> they live in front of a keyboard and have no real life.  ;-)
>
> Of course, this would require storage for the list of confirmed addresses
> and pending unconfirmed posts, and the bandwidth and other overhead of the
> infrequent confirmation messages.
>
> Just a thought.
>
> Cheers,
> Ed
>
> ----------------------------------------------------------------
> Ed Vance              edv (at) macrolink (dot) com
> Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
> ----------------------------------------------------------------
>

RE: your mail

[Ed Vance]

On Fri, Apr 04, 2003 at 12:38 PM, Matti Aarnio wrote:
> [snip]
> A somewhat better anti-spam filter method, than what we use presently
> is to use strictly CLOSED list -- e.g. must be a member to post.
> I have seen what kind of pains closed lists are, I even moderate
> couple small ones.
> 
> However we are deliberately running "open for posting, subject to
> filters" policy, which lets questions and reports to come from
> non-subscribers.
> 

Perhaps there is a middle ground. Leave the list open, but require a
confirmation reply prior to passing along posts from addresses that:

1. are not members of the list, AND
2. have not previously done a proper confirmation reply.

The unconfirmed posts would time out and disappear after a decent interval,
to prevent constipation.

So, anybody could still post, the members would not be inconvenienced, and
non-members would be inconvenienced only on their first post from each
address they post from. This would preserve the "real time" nature of the
list, while gaining the assurance that all who post are life-forms, even if
they live in front of a keyboard and have no real life.  ;-)

Of course, this would require storage for the list of confirmed addresses
and pending unconfirmed posts, and the bandwidth and other overhead of the
infrequent confirmation messages.

Just a thought. 

Cheers,
Ed

---------------------------------------------------------------- 
Ed Vance              edv (at) macrolink (dot) com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

Re: your mail

[Matti Aarnio]

On Fri, Apr 04, 2003 at 07:28:12AM -0800, William Scott Lockwood III wrote:
...
> The best list is one that is inclusive.  One that tollerates other opinions
> and choices.  LKML has turned into the largest, nastiest click I've ever
> seen, and that's really sad, as I'm sure it scares some good people away.

Are you speaking about PEOPLE who react on emails by flaming, or
something of list filtering "technology" ?

>  Look at all the crap I and others got for using hotmail - I finally
> got sick and tired of the whining and now have to take 3x as long to 
> read my mail - but it's not a hotmail address anymore, so the whining
> stoped.

About people, then..    There I can't help, unfortunately.

We have lots of people subscribing on Hotmail addresses, and only 
complaint I can voice is that those people will at times let their
mailbox quotas overflow, which leads to bounces, and then subscription
revocation...  (Hard controlled quotas are not unique to Hotmail, nor
people who let them overflow...)


> Why not spend less timing restricting what people can read and post
> from, and just let people participate?

There is this small thing called spam...

We have various filters (see my other posting), but obviously they
are not infallible, a few spams do leak thru, and earn new filter
rules (if I can think up something suitably specific, while generic..)

A somewhat better anti-spam filter method, than what we use presently
is to use strictly CLOSED list -- e.g. must be a member to post.
I have seen what kind of pains closed lists are, I even moderate
couple small ones.

However we are deliberately running "open for posting, subject to
filters" policy, which lets questions and reports to come from
non-subscribers.


/Matti Aarnio

Re: your mail

[Jens Axboe]

On Fri, Apr 04 2003, William Scott Lockwood III wrote:
> On Fri, 4 Apr 2003, Richard B. Johnson wrote:
> > On Thu, 3 Apr 2003, William Scott Lockwood III wrote:
> > > On Thu, 3 Apr 2003, David S. Miller wrote:
> > > >    From: "Richard B. Johnson" <root@chaos.analogic.com>
> > > >    Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> > > >    Well it's not a yahoo users problem because yahoo users can't fix
> > > >    it. Some yahoo users have yahoo "free" mail as their only connection
> > > >    to the internet because of facist network administrators.
> > > > If you want all the SPAM that will result on Linux-kernel, we
> > > > can disable the filter if you want.
> > > > I refuse to sit here and listen to all the "this is the only
> > > > connection person FOO has to the internet" stories, quite frankly I'm
> > > > absolutely sick of hearing them.
> > > > If you don't have properly functioning mail, you can't use these
> > > > lists.
> > > > Period.
> > > When did that become your call?  I didn't realize you owned LKML.
> > Well it's his "baseball" and; "You'll play by my rules or you won't
> > play at all..."
> > FYI, there is no Major Domo. It's Latin, major domus, "master of
> > the house". He doith whatever he careth...
> 
> Yes, I can see that.  No matter who it alienates.  Weither or not he's
> checked with anyone else either.  How about leting those of us who (like
> Linus) choose to use a commercial email product do so?  Garbage about
> headers, etc. is just that - garbage.  The best list is one that is
> inclusive.  One that tollerates other opinions and choices.  LKML has
> turned into the largest, nastiest click I've ever seen, and that's really
> sad, as I'm sure it scares some good people away.  Look at all the crap I
> and others got for using hotmail - I finally got sick and tired of the
> whining and now have to take 3x as long to read my mail - but it's not a
> hotmail address anymore, so the whining stoped.  Why not spend less timing
> restricting what people can read and post from, and just let people
> participate?

Oh please go away. Would you rather see lkml be as ridden with spam as
other lists? You have the right to use a commercial product, and you may
also exercise your right to choose a _bad_ one.

Besides, crap like the above doesn't carry much weight. Especially not
from someone who rarely contributes anything but noise on the list. No
time for whiners, to the kill file you go.

-- 
Jens Axboe

Re: your mail

[Christoph Hellwig]

On Fri, Apr 04, 2003 at 07:28:12AM -0800, William Scott Lockwood III wrote:
> Yes, I can see that.  No matter who it alienates.  Weither or not he's
> checked with anyone else either.

LKML is DaveM's list.  If the choice he and his co-postmaster make don't
suit yours or others need setup your own linux kernel list.

> How about leting those of us who (like
> Linus) choose to use a commercial email product do so?  Garbage about
> headers, etc. is just that - garbage.

Who said anything about commercial products?  lkml refuses _broken_
mails, it doesn't check what MUA you used.

> and others got for using hotmail - I finally got sick and tired of the
> whining and now have to take 3x as long to read my mail - but it's not a
> hotmail address anymore, so the whining stoped.  Why not spend less timing
> restricting what people can read and post from, and just let people
> participate?

Please red the mail RFC and the nettiquette and come back once you've
done that.  Your current whining wastes our time.

Re: your mail

[Richard B. Johnson]

On Fri, 4 Apr 2003, William Scott Lockwood III wrote:

> On Fri, 4 Apr 2003, Richard B. Johnson wrote:
> > On Thu, 3 Apr 2003, William Scott Lockwood III wrote:
> > > On Thu, 3 Apr 2003, David S. Miller wrote:
> > > >    From: "Richard B. Johnson" <root@chaos.analogic.com>
> > > >    Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> > > >    Well it's not a yahoo users problem because yahoo users can't fix
> > > >    it. Some yahoo users have yahoo "free" mail as their only connection
> > > >    to the internet because of facist network administrators.
> > > > If you want all the SPAM that will result on Linux-kernel, we
> > > > can disable the filter if you want.
> > > > I refuse to sit here and listen to all the "this is the only
> > > > connection person FOO has to the internet" stories, quite frankly I'm
> > > > absolutely sick of hearing them.
> > > > If you don't have properly functioning mail, you can't use these
> > > > lists.
> > > > Period.
> > > When did that become your call?  I didn't realize you owned LKML.
> > Well it's his "baseball" and; "You'll play by my rules or you won't
> > play at all..."
> > FYI, there is no Major Domo. It's Latin, major domus, "master of
> > the house". He doith whatever he careth...
>
> Yes, I can see that.  No matter who it alienates.  Weither or not he's
> checked with anyone else either.  How about leting those of us who (like
> Linus) choose to use a commercial email product do so?  Garbage about
> headers, etc. is just that - garbage.  The best list is one that is
> inclusive.  One that tollerates other opinions and choices.  LKML has
> turned into the largest, nastiest click I've ever seen, and that's really
> sad, as I'm sure it scares some good people away.  Look at all the crap I
> and others got for using hotmail - I finally got sick and tired of the
> whining and now have to take 3x as long to read my mail - but it's not a
> hotmail address anymore, so the whining stoped.  Why not spend less timing
> restricting what people can read and post from, and just let people
> participate?
>

Well SPAM is a very big problem and I can see that David is trying.
Sometimes he has a bad day and pisses a few off with his answers.
However, in every case in which somebody that I know of has complained,
the problems did get "mysteriously" fixed so, like they say; "Don't go
away mad. Just go away!".

Once you get flammed for a few years, you get used to it. That's why
some people send email to me rather than "the list". Sometimes I am
able to help without having to forward their problems to the list.
Sometimes I have to take a work-break and can't help, and other times
I can't help because I don't know what they are talking about. Anyway
if David wants invoke the rage of the Gods, yawn... It doesn't bother
me anymore....


Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: your mail

[William Scott Lockwood III]

On Fri, 4 Apr 2003, Richard B. Johnson wrote:
> On Thu, 3 Apr 2003, William Scott Lockwood III wrote:
> > On Thu, 3 Apr 2003, David S. Miller wrote:
> > >    From: "Richard B. Johnson" <root@chaos.analogic.com>
> > >    Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> > >    Well it's not a yahoo users problem because yahoo users can't fix
> > >    it. Some yahoo users have yahoo "free" mail as their only connection
> > >    to the internet because of facist network administrators.
> > > If you want all the SPAM that will result on Linux-kernel, we
> > > can disable the filter if you want.
> > > I refuse to sit here and listen to all the "this is the only
> > > connection person FOO has to the internet" stories, quite frankly I'm
> > > absolutely sick of hearing them.
> > > If you don't have properly functioning mail, you can't use these
> > > lists.
> > > Period.
> > When did that become your call?  I didn't realize you owned LKML.
> Well it's his "baseball" and; "You'll play by my rules or you won't
> play at all..."
> FYI, there is no Major Domo. It's Latin, major domus, "master of
> the house". He doith whatever he careth...

Yes, I can see that.  No matter who it alienates.  Weither or not he's
checked with anyone else either.  How about leting those of us who (like
Linus) choose to use a commercial email product do so?  Garbage about
headers, etc. is just that - garbage.  The best list is one that is
inclusive.  One that tollerates other opinions and choices.  LKML has
turned into the largest, nastiest click I've ever seen, and that's really
sad, as I'm sure it scares some good people away.  Look at all the crap I
and others got for using hotmail - I finally got sick and tired of the
whining and now have to take 3x as long to read my mail - but it's not a
hotmail address anymore, so the whining stoped.  Why not spend less timing
restricting what people can read and post from, and just let people
participate?

Re: your mail

[Richard B. Johnson]

On Thu, 3 Apr 2003, William Scott Lockwood III wrote:

> On Thu, 3 Apr 2003, David S. Miller wrote:
> >    From: "Richard B. Johnson" <root@chaos.analogic.com>
> >    Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
> >    Well it's not a yahoo users problem because yahoo users can't fix
> >    it. Some yahoo users have yahoo "free" mail as their only connection
> >    to the internet because of facist network administrators.
> > If you want all the SPAM that will result on Linux-kernel, we
> > can disable the filter if you want.
> > I refuse to sit here and listen to all the "this is the only
> > connection person FOO has to the internet" stories, quite frankly I'm
> > absolutely sick of hearing them.
> > If you don't have properly functioning mail, you can't use these
> > lists.
> > Period.
>
> When did that become your call?  I didn't realize you owned LKML.
>

Well it's his "baseball" and; "You'll play by my rules or you won't
play at all..."

FYI, there is no Major Domo. It's Latin, major domus, "master of
the house". He doith whatever he careth...

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: your mail

[William Scott Lockwood III]

Yeah, sorry - I thought HPA was running it for some reason.  I still don't
think you should make that kind of a call unilaterally, but hey - after
all the incessant whining I put up with about using OE, I finally caved
and moved to a real email address myself.  I guess it just goes to show
that if you while and act petulant long enough...

On Thu, 3 Apr 2003, David S. Miller wrote:

>    From: William Scott Lockwood III <vlad@geekizoid.com>
>    Date: Thu, 3 Apr 2003 16:31:13 -0800 (PST)
>
>    When did that become your call?  I didn't realize you owned LKML.
>
> Maybe this is news to you, but I've been running LKML for
> 6 or so years now.
>

Re: your mail

[David S. Miller]

   From: William Scott Lockwood III <vlad@geekizoid.com>
   Date: Thu, 3 Apr 2003 16:31:13 -0800 (PST)

   When did that become your call?  I didn't realize you owned LKML.
   
Maybe this is news to you, but I've been running LKML for
6 or so years now.

Re: your mail

[William Scott Lockwood III]

On Thu, 3 Apr 2003, David S. Miller wrote:
>    From: "Richard B. Johnson" <root@chaos.analogic.com>
>    Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
>    Well it's not a yahoo users problem because yahoo users can't fix
>    it. Some yahoo users have yahoo "free" mail as their only connection
>    to the internet because of facist network administrators.
> If you want all the SPAM that will result on Linux-kernel, we
> can disable the filter if you want.
> I refuse to sit here and listen to all the "this is the only
> connection person FOO has to the internet" stories, quite frankly I'm
> absolutely sick of hearing them.
> If you don't have properly functioning mail, you can't use these
> lists.
> Period.

When did that become your call?  I didn't realize you owned LKML.

Re: your mail

[Trever L. Adams]

On Thu, 2003-04-03 at 15:02, Richard B. Johnson wrote:
> Well it's not a yahoo users problem because yahoo users can't fix
> it. Some yahoo users have yahoo "free" mail as their only connection
> to the internet because of facist network administrators. It gets
> worse how that you can't tell a company to go screw themselves and
> get another job. The three engineers that I know who use yahoo do
> so because they don't have any choice and there is no way that they
> can configure the mailer to get rid of the empty HTML section.

I would suggest that those who think Yahoo is there only option, check
out digitalme.com or myrealbox.com.  Web, pop, imap, etc.  All free.

Trever
--
"Never raise your hand to your children - it leaves your midsection
unprotected." -- Matthew Harrell

Re: your mail

[Richard B. Johnson]

On Thu, 3 Apr 2003, David S. Miller wrote:

>    From: "Richard B. Johnson" <root@chaos.analogic.com>
>    Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
>
>    Well it's not a yahoo users problem because yahoo users can't fix
>    it. Some yahoo users have yahoo "free" mail as their only connection
>    to the internet because of facist network administrators.
>
> If you want all the SPAM that will result on Linux-kernel, we
> can disable the filter if you want.

No. I think you can let empty HTML sections go through.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: your mail

[David S. Miller]

   From: "Richard B. Johnson" <root@chaos.analogic.com>
   Date: Thu, 3 Apr 2003 15:21:25 -0500 (EST)

   On Thu, 3 Apr 2003, David S. Miller wrote:
   
   > If you want all the SPAM that will result on Linux-kernel, we
   > can disable the filter if you want.
   
   No. I think you can let empty HTML sections go through.
   
I think these people who it matters to can petition yahoo.com to drop
this dumb empty HTML section.

Re: your mail

[Richard B. Johnson]

On Thu, 3 Apr 2003, David S. Miller wrote:

> On Thu, 2003-04-03 at 08:22, Richard B. Johnson wrote:
> > FYI vger rejects mail sent from yahoo.com, claims that it
> > has a HTML subpart and considers it spam or Outlook Virus.
> >
> > FYI any mail sent from yahoo will end up using the yahoo tools
> > (qmail). This will put an empty HTML section in all mail. It
> > is not a good thing to reject this because that means you reject
> > all mail from yahoo.
>
> That's yahoo users problem not ours.  If you can't be bothered
> to get a plain text email out, you shouldn't be using these
> lists.
>

Well it's not a yahoo users problem because yahoo users can't fix
it. Some yahoo users have yahoo "free" mail as their only connection
to the internet because of facist network administrators. It gets
worse how that you can't tell a company to go screw themselves and
get another job. The three engineers that I know who use yahoo do
so because they don't have any choice and there is no way that they
can configure the mailer to get rid of the empty HTML section.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: your mail

[David S. Miller]

   From: "Richard B. Johnson" <root@chaos.analogic.com>
   Date: Thu, 3 Apr 2003 15:02:41 -0500 (EST)
   
   Well it's not a yahoo users problem because yahoo users can't fix
   it. Some yahoo users have yahoo "free" mail as their only connection
   to the internet because of facist network administrators.

If you want all the SPAM that will result on Linux-kernel, we
can disable the filter if you want.

I refuse to sit here and listen to all the "this is the only
connection person FOO has to the internet" stories, quite frankly I'm
absolutely sick of hearing them.

If you don't have properly functioning mail, you can't use these
lists.

Period.

Re: your mail

[Alan Cox]

On Iau, 2003-04-03 at 21:02, Richard B. Johnson wrote:
> Well it's not a yahoo users problem because yahoo users can't fix
> it. Some yahoo users have yahoo "free" mail as their only connection
> to the internet because of facist network administrators. It gets
> worse how that you can't tell a company to go screw themselves and
> get another job. The three engineers that I know who use yahoo do
> so because they don't have any choice and there is no way that they
> can configure the mailer to get rid of the empty HTML section.

There are lots of other free email providers.

Re: your mail

[Thiemo Seufer]

Avinash S. wrote:
> Hello,
> 
> Im trying to build a kernel config for a big endian IDT79S334 board. I 
> have sucessfully mangaged to get a vmlinux image using Embedix tools for 
> little endian but am having problems with big endian configs. I am using 
> binutils version 2.8. I get an error when i reaches irq.c saying:
                   ^^^
That's _very_ old.

> Unknown ISA level 
> Unknown opcode 'clz'
> 
> im using a mips-linux-gcc from egcs pacakge(1.1.2-4). Does anyone know 
> how to solve this problem or where can i get a mips-linux-gcc that 
> supports the opcode.

It's the assembler, not the compiler. Upgrade binutils.


Thiemo

Re: your mail

[Alexander Kellett]

hiya,

unfortunately this list isn't for such problems and it
would be better to contact your distribution or the various
forums it has. try google.

/me wonders again why this list isn't called linux-kernel-dev@...

Alex

On Fri, Jan 31, 2003 at 06:46:05PM -0000, saurabh  khanna wrote:
> Problem: My xwindows did not open and my sound card don't work.
> 
> Xwindows:
> I am a novice. I am using redhat linux 8. It detects my graphics 
> card
> correctly but when i tried to open xwindows, my system hangs.
> 
> Sound:
> Linux has detected my sound card once but not configured it and 
> after
> that nor it is working nither it is detected by my linux.
> 
> GRUB:
> Also, i can boot my linux through LILO only. GRUB wont work, it 
> gives
> error "Not enough memory".
> 
> I have re-installed linux on my computer but the problem 
> remains.
> All other detailes are follows.
> 
> Kernel version:
> Linux version 2.4.18-14 (bhcompile@astest.test.redhat.com)
> (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7))
> #1 Wed Sep 4 12:13:11 EDT 2002
> 
> 
> Commond which triggers the problem:
> startx
> 
> Processor information:
> processor	: 0
> 
> vendor_id	: AuthenticAMD
> 
> cpu family	: 6
> 
> model		: 6
> 
> model name	: AMD Athlon(TM) XP 1700+
> 
> stepping	: 2
> 
> cpu MHz		: 1469.861
> 
> cache size	: 256 KB
> 
> fdiv_bug	: no
> 
> hlt_bug		: no
> 
> f00f_bug	: no
> 
> coma_bug	: no
> 
> fpu		: yes
> 
> fpu_exception	: yes
> 
> cpuid level	: 1
> 
> wp		: yes
> 
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
> cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
> 
> bogomips	: 2920.57
> 
> 
> 
> Module information:
> nls_iso8859-1           3516   1 (autoclean)
> 
> nls_cp437               5116   1 (autoclean)
> 
> vfat                   13084   1 (autoclean)
> 
> fat                    38744   0 (autoclean)
> [vfat]
> autofs                 13348   0 (autoclean) (unused)
> 
> ipt_REJECT              3736   2 (autoclean)
> 
> iptable_filter          2412   1 (autoclean)
> 
> ip_tables              14840   2 [ipt_REJECT iptable_filter]
> 
> mousedev                5524   0 (unused)
> 
> keybdev                 2976   0 (unused)
> 
> hid                    22244   0 (unused)
> 
> input                   5888   0 [mousedev keybdev hid]
> 
> usb-ohci               21288   0 (unused)
> 
> usbcore                77056   1 [hid usb-ohci]
> 
> ext3                   70400   1
> 
> jbd                    52212   1 [ext3]
> 
> 
> 
> Loaded driver and hardware information:
> 0000-001f : dma
> 1
> 0020-003f : pic
> 1
> 0040-005f : timer
> 
> 0060-006f : keyboard
> 
> 0070-007f : rtc
> 
> 0080-008f : dma page reg
> 
> 00a0-00bf : pic
> 2
> 00c0-00df : dma
> 2
> 00f0-00ff : fpu
> 
> 01f0-01f7 : ide
> 0
> 02f8-02ff : serial(auto)
> 
> 03c0-03df : vga+
> 
> 03f6-03f6 : ide
> 0
> 03f8-03ff : serial(auto)
> 
> 0cf8-0cff : PCI conf
> 1
> 5000-500f : PCI device 10de:01b4 (nVidia Corporation)
> 
> 5100-511f : PCI device 10de:01b4 (nVidia Corporation)
> 
> 5500-550f : PCI device 10de:01b4 (nVidia Corporation)
> 
> a800-a80f : nVidia Corporation nForce IDE
> 
> a800-a807 : ide0
> 
> a808-a80f : ide1
> 
> b000-bfff : PCI Bus #01
> 
> b800-b807 : Rockwell International HCF 56k Data/Fax/Voice/Spkp 
> (w/Handset) Modem
> 
> d800-d807 : PCI device 10de:01c3 (nVidia Corporation)
> 
> e000-e07f : PCI device 10de:01b1 (nVidia Corporation)
> 
> e100-e1ff : PCI device 10de:01b1 (nVidia Corporation)
> 
> 00000000-0007ffff : System RAM
> 
> 0009fc00-0009ffff : reserved
> 
> 000a0000-000bffff : Video RAM area
> 
> 000c0000-000c7fff : Video ROM
> 
> 000f0000-000fffff : System ROM
> 
> 00100000-06febfff : System RAM
> 
> 00100000-00247f2e : Kernel code
> 
> 00247f2f-0033ed03 : Kernel data
> 
> 06fec000-06feefff : ACPI Tables
> 
> 06fef000-06ffefff : reserved
> 
> 06fff000-06ffffff : ACPI Non-volatile Storage
> 
> eb000000-ec7fffff : PCI Bus #02
> 
> eb000000-ebffffff : nVidia Corporation GeForce2 Integrated GPU
> 
> ec800000-ecffffff : PCI Bus #01
> 
> ec800000-ec80ffff : Rockwell International HCF 56k 
> Data/Fax/Voice/Spkp (w/Handset) Modem
> 
> ed000000-ed000fff : PCI device 10de:01b1 (nVidia Corporation)
> 
> ed800000-ed87ffff : PCI device 10de:01b0 (nVidia Corporation)
> 
> ee000000-ee0003ff : PCI device 10de:01c3 (nVidia Corporation)
> 
> ee800000-ee800fff : PCI device 10de:01c2 (nVidia Corporation)
> 
> ee800000-ee800fff : usb-ohci
> e
> f000000-ef000fff : PCI device
> 10de:01c2 (nVidia Corporation)
> 
> ef000000-ef000fff : usb-ohci
> e
> ff00000-f7ffffff : PCI Bus #02
> 
> f0000000-f7ffffff : nVidia Corporation GeForce2 Integrated GPU
> 
> f8000000-fbffffff : PCI device
> 10de:01a4 (nVidia Corporation)
> 
> fec00000-fec00fff : reserved
> 
> fee00000-fee00fff : reserved
> 
> ffff0000-ffffffff : reserved
> 
> 
> PCI information:
> 00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev 
> b2)
> 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0
> 	Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
> 	Capabilities: [40] AGP version 2.0
> 		Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2,x4
> 		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=x1
> 	Capabilities: [60] #08 [2001]
> 
> 00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory 
> Controller (rev b2)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 
> 00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory 
> Controller (rev b2)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 
> 00:00.3 RAM memory: nVidia Corporation: Unknown device 01aa (rev 
> b2)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 
> 00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev 
> c3)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0
> 	Capabilities: [50] #08 [01e1]
> 
> 00:01.1 SMBus: nVidia Corporation nForce PCI System Management 
> (rev c1)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Interrupt: pin A routed to IRQ 5
> 	Region 0: I/O ports at 5000 [size=16]
> 	Region 1: I/O ports at 5500 [size=16]
> 	Region 2: I/O ports at 5100 [size=32]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:02.0 USB Controller: nVidia Corporation: Unknown device 01c2 
> (rev c3) (prog-if 10 [OHCI])
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0 (750ns min, 250ns max)
> 	Interrupt: pin A routed to IRQ 5
> 	Region 0: Memory at ef000000 (32-bit, non-prefetchable) 
> [size=4K]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:03.0 USB Controller: nVidia Corporation: Unknown device 01c2 
> (rev c3) (prog-if 10 [OHCI])
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0 (750ns min, 250ns max)
> 	Interrupt: pin A routed to IRQ 5
> 	Region 0: Memory at ee800000 (32-bit, non-prefetchable) 
> [size=4K]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:04.0 Ethernet controller: nVidia Corporation: Unknown device 
> 01c3 (rev c2)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0 (250ns min, 5000ns max)
> 	Interrupt: pin A routed to IRQ 5
> 	Region 0: Memory at ee000000 (32-bit, non-prefetchable) 
> [size=1K]
> 	Region 1: I/O ports at d800 [size=8]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:05.0 Multimedia audio controller: nVidia Corporation: Unknown 
> device 01b0 (rev c2)
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0 (250ns min, 3000ns max)
> 	Interrupt: pin A routed to IRQ 5
> 	Region 0: Memory at ed800000 (32-bit, non-prefetchable) 
> [size=512K]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:06.0 Multimedia audio controller: nVidia Corporation nForce 
> Audio (rev c2)
> 	Subsystem: nVidia Corporation: Unknown device 8384
> 	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0 (500ns min, 1250ns max)
> 	Interrupt: pin A routed to IRQ 11
> 	Region 0: I/O ports at e100 [size=256]
> 	Region 1: I/O ports at e000 [size=128]
> 	Region 2: Memory at ed000000 (32-bit, non-prefetchable) 
> [disabled] [size=4K]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:08.0 PCI bridge: nVidia Corporation nForce PCI-to-PCI bridge 
> (rev c2) (prog-if 00 [Normal decode])
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0
> 	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> 	I/O behind bridge: 0000b000-0000bfff
> 	Memory behind bridge: ec800000-ecffffff
> 	Prefetchable memory behind bridge: f8000000-f7ffffff
> 	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> 
> 00:09.0 IDE interface: nVidia Corporation nForce IDE (rev c3) 
> (prog-if 8a [Master SecP PriP])
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0 (750ns min, 250ns max)
> 	Region 4: I/O ports at a800 [size=16]
> 	Capabilities: [44] Power Management version 2
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:1e.0 PCI bridge: nVidia Corporation nForce AGP to PCI Bridge 
> (rev b2) (prog-if 00 [Normal decode])
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0
> 	Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
> 	I/O behind bridge: 0000a000-00009fff
> 	Memory behind bridge: eb000000-ec7fffff
> 	Prefetchable memory behind bridge: eff00000-f7ffffff
> 	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
> 
> 01:08.0 Communication controller: Rockwell International HCF 56k 
> Data/Fax/Voice/Spkp (w/Handset) Modem (rev 01)
> 	Subsystem: Rockwell International HCF 56k Data/Fax/Voice/Spkp 
> (w/Handset) Modem
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 64
> 	Interrupt: pin A routed to IRQ 5
> 	Region 0: Memory at ec800000 (32-bit, non-prefetchable) 
> [size=64K]
> 	Region 1: I/O ports at b800 [size=8]
> 	Capabilities: [40] Power Management version 2
> 		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA 
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> 		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
> 
> 02:00.0 VGA compatible controller: nVidia Corporation NV15 
> [GeForce2 - nForce GPU] (rev b1) (prog-if 00 [VGA])
> 	Subsystem: nVidia Corporation: Unknown device 0c11
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 32 (1250ns min, 250ns max)
> 	Interrupt: pin A routed to IRQ 11
> 	Region 0: Memory at eb000000 (32-bit, non-prefetchable) 
> [size=16M]
> 	Region 1: Memory at f0000000 (32-bit, prefetchable) 
> [size=128M]
> 	Expansion ROM at efff0000 [disabled] [size=64K]
> 	Capabilities: [60] Power Management version 2
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> 		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 	Capabilities: [44] AGP version 2.0
> 		Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x4
> 		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
> 
> 
> 
> XF86Config:
> 
> # File generated by anaconda.
> 
> Section "ServerLayout"
>         Identifier     "Anaconda Configured"
>         Screen      0  "Screen0" 0 0
>         InputDevice    "Mouse0" "CorePointer"
> 	InputDevice	"Mouse1" "SendCoreEvents"
>         InputDevice    "Keyboard0" "CoreKeyboard"
> EndSection
> 
> Section "Files"
> 
> # The location of the RGB database.  Note, this is the name of 
> the
> # file minus the extension (like ".txt" or ".db").  There is 
> normally
> # no need to change the default.
> 
>     RgbPath	"/usr/X11R6/lib/X11/rgb"
> 
> # Multiple FontPath entries are allowed (they are concatenated 
> together)
> # By default, Red Hat 6.0 and later now use a font server 
> independent of
> # the X server to render fonts.
> 
>     FontPath   "unix/:7100"
> 
> EndSection
> 
> Section "Module"
>         Load  "dbe"
>         Load  "extmod"
> 	Load  "fbdevhw"
> 	Load  "dri"
>         Load  "glx"
>         Load  "record"
>         Load  "freetype"
>         Load  "type1"
> EndSection
> 
> Section "InputDevice"
>         Identifier  "Keyboard0"
>         Driver      "keyboard"
> 
> #	Option	"AutoRepeat"	"500 5"
> 
> # when using XQUEUE, comment out the above line, and uncomment 
> the
> # following line
> #	Option	"Protocol"	"Xqueue"
> 
> # Specify which keyboard LEDs can be user-controlled (eg, with 
> xset(1))
> #	Option	"Xleds"		"1 2 3"
> 
> # To disable the XKEYBOARD extension, uncomment XkbDisable.
> #	Option	"XkbDisable"
> 
> # To customise the XKB settings to suit your keyboard, modify 
> the
> # lines below (which are the defaults).  For example, for a 
> non-U.S.
> # keyboard, you will probably want to use:
> #	Option	"XkbModel"	"pc102"
> # If you have a US Microsoft Natural keyboard, you can use:
> #	Option	"XkbModel"	"microsoft"
> #
> # Then to change the language, change the Layout setting.
> # For example, a german layout can be obtained with:
> #	Option	"XkbLayout"	"de"
> # or:
> #	Option	"XkbLayout"	"de"
> #	Option	"XkbVariant"	"nodeadkeys"
> #
> # If you'd like to switch the positions of your capslock and
> # control keys, use:
> #	Option	"XkbOptions"	"ctrl:swapcaps"
> 	Option	"XkbRules"	"xfree86"
> 	Option	"XkbModel"	"pc105"
> 	Option	"XkbLayout"	"us"
> 	#Option	"XkbVariant"	""
> 	#Option	"XkbOptions"	""
> EndSection
> 
> Section "InputDevice"
>         Identifier  "Mouse0"
>         Driver      "mouse"
>         Option      "Protocol" "PS/2"
>         Option      "Device" "/dev/psaux"
>         Option      "ZAxisMapping" "4 5"
>         Option      "Emulate3Buttons" "yes"
> EndSection
> 
> 
> Section "InputDevice"
> 	Identifier	"Mouse1"
> 	Driver		"mouse"
> 	Option		"Device"		"/dev/input/mice"
> 	Option		"Protocol"		"IMPS/2"
> 	Option		"Emulate3Buttons"	"no"
> 	Option		"ZAxisMapping"		"4 5"
> EndSection
> 
> 
> Section "Monitor"
>         Identifier   "Monitor0"
>         VendorName   "Monitor Vendor"
>         ModelName    "Monitor Model"
>         HorizSync   30-55
>         VertRefresh 50-120
>         Option "dpms"
> 
> 
> EndSection
> 
> Section "Device"
> 	# no known options
> 	Identifier   "NVIDIA GeForce 2 MX (generic)"
>         Driver       "nv"
>         VendorName   "NVIDIA GeForce 2 MX (generic)"
>         BoardName     "NVIDIA GeForce 2 MX (generic)"
> 
>         #BusID
> EndSection
> 
> Section "Screen"
> 	Identifier   "Screen0"
>         Device       "NVIDIA GeForce 2 MX (generic)"
>         Monitor      "Monitor0"
> 	DefaultDepth	16
> 
> 	Subsection "Display"
>         	Depth       16
>                 Modes       "1024x768" "800x600" "640x480"
> 	EndSubsection
> 
> EndSection
> 
> Section "DRI"
> 	Mode 0666
> EndSection
> 
> cmdline:
> auto BOOT_IMAGE=linux ro BOOT_FILE=/boot/vmlinuz-2.4.18-14 
> root=LABEL=/
> 
> 
> dma:
> 4: cascade
> 
> 
> intrrupts:
> CPU0
>   0:     337647          XT-PIC  timer
>   1:       2694          XT-PIC  keyboard
>   2:          0          XT-PIC  cascade
>   5:          0          XT-PIC  usb-ohci, usb-ohci
>   8:          1          XT-PIC  rtc
>  12:         20          XT-PIC  PS/2 Mouse
>  14:      27338          XT-PIC  ide0
> NMI:          0
> ERR:          2
> 
> 
> partitions:
> major minor  #blocks  name     rio rmerge rsect ruse wio wmerge 
> wsect wuse running use aveq
> 
>    3     0   39121488 hda 2567 4181 52107 22201 1417 1941 26952 
> 45880 -2 329576 7788488
>    3     1    5245191 hda1 9 43 104 109 0 0 0 0 0 109 109
>    3     2          1 hda2 0 0 0 0 0 0 0 0 0 0 0
>    3     5   10490413 hda5 9 43 104 95 0 0 0 0 0 95 95
>    3     6   11695288 hda6 50 43 145 214 7 1 8 95 0 230 310
>    3     7    8104761 hda7 9 43 104 132 0 0 0 0 0 132 132
>    3     8    3277228 hda8 2475 3966 51498 21527 1410 1940 26944 
> 45785 0 22394 67314
>    3     9     305203 hda9 9 25 104 56 0 0 0 0 0 56 56
> 
> 
> 
> My e-mail addresses are: linux_guyus@yahoo.com and 
> linux_guyus@rediff.com
> My postel address: 80, Ahilya Nagar Ext. Annapurna Road, Indore, 
> M.P.,
> India. PIN 452009
> please answer me soon.
> 		Thanking you.
> 			Saurabh Khanna.
> 
> -
> 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/
> 

mvg,
Alex

-- 
"[...] Konqueror open source project. Weighing in at less than
            one tenth the size of another open source renderer"
Apple,  Jan 2003 (http://www.apple.com/safari/)

Re: your mail

[David S. Miller]

On Sat, 2003-01-25 at 15:10, Larry McVoy wrote:
> All good page coloring implementation do exactly that.  The starting
> index into the page buckets is based on process id.

I think everyone interested in learning more about this
topic should go read the following papers, they were very
helpful when I was fiddling around in this area.

These papers, in turn, reference several others which are
good reads as well.

1) W. L. Lynch, B. K. Bray, and M. J. Flynn. "The effect of page
   allocation on caches". In Micro-25 Conference Proceedings, pages
   222-225, December 1992. 

2) W. Lynch and M. Flynn. "Cache improvements through colored page
   allocation". ACM Transactions on Computer Systems, 1993. Submitted
   for review, 1992. 

3) William L. Lynch. "The Interaction of Virtual Memory and Cache
   Memory". PhD thesis, Stanford University, October
   1993. CSL-TR-93-587.

Re: your mail

[David S. Miller]

On Sat, 2003-01-25 at 15:10, Larry McVoy wrote:
> All good page coloring implementation do exactly that.  The starting
> index into the page buckets is based on process id.

I think everyone interested in learning more about this
topic should go read the following papers, they were very
helpful when I was fiddling around in this area.

These papers, in turn, reference several others which are
good reads as well.

1) W. L. Lynch, B. K. Bray, and M. J. Flynn. "The effect of page
   allocation on caches". In Micro-25 Conference Proceedings, pages
   222-225, December 1992. 

2) W. Lynch and M. Flynn. "Cache improvements through colored page
   allocation". ACM Transactions on Computer Systems, 1993. Submitted
   for review, 1992. 

3) William L. Lynch. "The Interaction of Virtual Memory and Cache
   Memory". PhD thesis, Stanford University, October
   1993. CSL-TR-93-587.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[Larry McVoy]

> I am wondering if there is any point in biasing page addresses in between
> processes so that processes are less likely to have a cache conflict.
> i.e.  process 1 address 0 %16K == 0, process 2 address 0 %16K == 4K 

All good page coloring implementation do exactly that.  The starting
index into the page buckets is based on process id.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: your mail

[Larry McVoy]

> I am wondering if there is any point in biasing page addresses in between
> processes so that processes are less likely to have a cache conflict.
> i.e.  process 1 address 0 %16K == 0, process 2 address 0 %16K == 4K 

All good page coloring implementation do exactly that.  The starting
index into the page buckets is based on process id.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[Eric W. Biederman]

Larry McVoy <lm@bitmover.com> writes:

> > For the record, I finally got to try my own page coloring patch on a 1GHz
> > Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
> > own number crunching benchmarks and a kernel compile don't show any benefit 
> > at all, and lmbench is completely unchanged except for the mmap latency, 
> > which is slightly worse. Hardly a compelling case for PCs!
> 
> If it works correctly then the variability in lat_ctx should go away.
> Try this
> 
> 	for p in 2 4 8 12 16 24 32 64
> 	do	for size in 0 2 4 8 16
> 		do	for i in 1 2 3 4 5 6 7 8 9 0
> 			do	lat_ctx -s$size $p
> 			done
> 		done
> 	done
> 
> on both the with and without kernel.  The page coloring should make the 
> numbers rock steady, without it, they will bounce a lot.

On the same kind of vein I have seen some tremendous variability in the
stream benchmark.  Under linux I have gotten it to very as much
as a 100MB/sec by running updatedb, between runs.  In one case
it ran faster with updatedb running in the background.

But at the same time streams tends to be very steady if you have a quiet
machine and run it several times in a row repeatedly because it gets
allocated essentially the same memory every run.

So I do no the variables of cache contention do have effect on some
real programs.  I have not yet tracked it down to see if cache coloring
could be a benefit.  I suspect the buddy allocator actually comes
quite close most of the time, and tricks like allocating multiple pages
at once could improve that even more with very little effort, while reducing
page fault miss times.

I am wondering if there is any point in biasing page addresses in between
processes so that processes are less likely to have a cache conflict.
i.e.  process 1 address 0 %16K == 0, process 2 address 0 %16K == 4K 

Eric

Re: your mail

[Eric W. Biederman]

Larry McVoy <lm@bitmover.com> writes:

> > For the record, I finally got to try my own page coloring patch on a 1GHz
> > Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
> > own number crunching benchmarks and a kernel compile don't show any benefit 
> > at all, and lmbench is completely unchanged except for the mmap latency, 
> > which is slightly worse. Hardly a compelling case for PCs!
> 
> If it works correctly then the variability in lat_ctx should go away.
> Try this
> 
> 	for p in 2 4 8 12 16 24 32 64
> 	do	for size in 0 2 4 8 16
> 		do	for i in 1 2 3 4 5 6 7 8 9 0
> 			do	lat_ctx -s$size $p
> 			done
> 		done
> 	done
> 
> on both the with and without kernel.  The page coloring should make the 
> numbers rock steady, without it, they will bounce a lot.

On the same kind of vein I have seen some tremendous variability in the
stream benchmark.  Under linux I have gotten it to very as much
as a 100MB/sec by running updatedb, between runs.  In one case
it ran faster with updatedb running in the background.

But at the same time streams tends to be very steady if you have a quiet
machine and run it several times in a row repeatedly because it gets
allocated essentially the same memory every run.

So I do no the variables of cache contention do have effect on some
real programs.  I have not yet tracked it down to see if cache coloring
could be a benefit.  I suspect the buddy allocator actually comes
quite close most of the time, and tricks like allocating multiple pages
at once could improve that even more with very little effort, while reducing
page fault miss times.

I am wondering if there is any point in biasing page addresses in between
processes so that processes are less likely to have a cache conflict.
i.e.  process 1 address 0 %16K == 0, process 2 address 0 %16K == 4K 

Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[Jason Papadopoulos]

At 10:06 PM 1/23/03 -0800, John Alvord wrote:

>The big challenge in Linux is that several serious attempts to add
>page coloring have foundered on the shoals of "no benefit found". It
>may be that the typical hardware Linux runs on just doesn't experience
>the problem very much.

Another strike against page coloring is that it gives tremendous benefits
when caches are large and not very associative, but if both of these are
not present the benefits are much smaller. In the case of latter-day PCs,
neither of these is the case: the caches are very small and at least 8-way
set associative.

For the record, I finally got to try my own page coloring patch on a 1GHz
Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
own number crunching benchmarks and a kernel compile don't show any benefit 
at all, and lmbench is completely unchanged except for the mmap latency, 
which is slightly worse. Hardly a compelling case for PCs!

Oh well. At least now I'll be able to port to 2.5 :)

jasonp

Re: your mail

[Jason Papadopoulos]

At 10:06 PM 1/23/03 -0800, John Alvord wrote:

>The big challenge in Linux is that several serious attempts to add
>page coloring have foundered on the shoals of "no benefit found". It
>may be that the typical hardware Linux runs on just doesn't experience
>the problem very much.

Another strike against page coloring is that it gives tremendous benefits
when caches are large and not very associative, but if both of these are
not present the benefits are much smaller. In the case of latter-day PCs,
neither of these is the case: the caches are very small and at least 8-way
set associative.

For the record, I finally got to try my own page coloring patch on a 1GHz
Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
own number crunching benchmarks and a kernel compile don't show any benefit 
at all, and lmbench is completely unchanged except for the mmap latency, 
which is slightly worse. Hardly a compelling case for PCs!

Oh well. At least now I'll be able to port to 2.5 :)

jasonp
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[Larry McVoy]

> For the record, I finally got to try my own page coloring patch on a 1GHz
> Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
> own number crunching benchmarks and a kernel compile don't show any benefit 
> at all, and lmbench is completely unchanged except for the mmap latency, 
> which is slightly worse. Hardly a compelling case for PCs!

If it works correctly then the variability in lat_ctx should go away.
Try this

	for p in 2 4 8 12 16 24 32 64
	do	for size in 0 2 4 8 16
		do	for i in 1 2 3 4 5 6 7 8 9 0
			do	lat_ctx -s$size $p
			done
		done
	done

on both the with and without kernel.  The page coloring should make the 
numbers rock steady, without it, they will bounce a lot.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: your mail

[Larry McVoy]

> For the record, I finally got to try my own page coloring patch on a 1GHz
> Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
> own number crunching benchmarks and a kernel compile don't show any benefit 
> at all, and lmbench is completely unchanged except for the mmap latency, 
> which is slightly worse. Hardly a compelling case for PCs!

If it works correctly then the variability in lat_ctx should go away.
Try this

	for p in 2 4 8 12 16 24 32 64
	do	for size in 0 2 4 8 16
		do	for i in 1 2 3 4 5 6 7 8 9 0
			do	lat_ctx -s$size $p
			done
		done
	done

on both the with and without kernel.  The page coloring should make the 
numbers rock steady, without it, they will bounce a lot.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[Maciej W. Rozycki]

On Fri, 24 Jan 2003, David Lang wrote:

> the cache never sees the virtual addresses, it operated excclusivly on the
> physical addresses so the problem of aliasing never comes up.

 It depends on the implementation.

> virtual to physical addres mapping is all resolved before anything hits
> the cache.

 It depends on the processor.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: your mail

[Maciej W. Rozycki]

On Fri, 24 Jan 2003, David Lang wrote:

> the cache never sees the virtual addresses, it operated excclusivly on the
> physical addresses so the problem of aliasing never comes up.

 It depends on the implementation.

> virtual to physical addres mapping is all resolved before anything hits
> the cache.

 It depends on the processor.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[David Lang]

the cache never sees the virtual addresses, it operated excclusivly on the
physical addresses so the problem of aliasing never comes up.

virtual to physical addres mapping is all resolved before anything hits
the cache.

David Lang

On Fri, 24 Jan 2003, Anoop J. wrote:

> Date: Fri, 24 Jan 2003 15:19:16 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: david.lang@digitalinsight.com
> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
> Subject: Re: your mail
>
> ok i shall put it in another way
> since virtual indexing is a representation of the virtual memory,
> it is possible for more multiple virtual addresses to represent the same
> physical address.So the problem of aliasing occurs in the cache.Does page
> coloring guarantee a unique mapping of physical address.If so how is the
> maping from virtual to physical address
>
>
>
> Thanks
>
>
>
> > I think this is a case of the same tuerm being used for two different
> > purposes. I don't know the use you are refering to.
> >
> > David Lang
> >
> >
> >
>
>
>
>

Re: your mail

[David Lang]

the cache never sees the virtual addresses, it operated excclusivly on the
physical addresses so the problem of aliasing never comes up.

virtual to physical addres mapping is all resolved before anything hits
the cache.

David Lang

On Fri, 24 Jan 2003, Anoop J. wrote:

> Date: Fri, 24 Jan 2003 15:19:16 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: david.lang@digitalinsight.com
> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
> Subject: Re: your mail
>
> ok i shall put it in another way
> since virtual indexing is a representation of the virtual memory,
> it is possible for more multiple virtual addresses to represent the same
> physical address.So the problem of aliasing occurs in the cache.Does page
> coloring guarantee a unique mapping of physical address.If so how is the
> maping from virtual to physical address
>
>
>
> Thanks
>
>
>
> > I think this is a case of the same tuerm being used for two different
> > purposes. I don't know the use you are refering to.
> >
> > David Lang
> >
> >
> >
>
>
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[Anoop J.]

ok i shall put it in another way
since virtual indexing is a representation of the virtual memory,
it is possible for more multiple virtual addresses to represent the same
physical address.So the problem of aliasing occurs in the cache.Does page
coloring guarantee a unique mapping of physical address.If so how is the
maping from virtual to physical address



Thanks



> I think this is a case of the same tuerm being used for two different
> purposes. I don't know the use you are refering to.
>
> David Lang
>
>
>

Re: your mail

[Anoop J.]

ok i shall put it in another way
since virtual indexing is a representation of the virtual memory,
it is possible for more multiple virtual addresses to represent the same
physical address.So the problem of aliasing occurs in the cache.Does page
coloring guarantee a unique mapping of physical address.If so how is the
maping from virtual to physical address



Thanks



> I think this is a case of the same tuerm being used for two different
> purposes. I don't know the use you are refering to.
>
> David Lang
>
>
>




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[Anoop J.]

I read that the data coherency problem due to virtual indexing is avoided
through page coloring and it has also got the speed of physical indexing
can u just elaborate on how this is possible?


Thanks




> implementing a fully associative cache eliminates the need for page
> coloring, but it has to be implemented in hardware. if you don't have
> fully associative caches in your hardware page coloring helps avoid the
> worst case memory allocations.
>
> from what I have seen on the attempts to implement it the problem is
> that the calculations needed to do page colored allocations end up
> costing enough that they end up with a net loss compared to the old
> method.
>
> David Lang
>
>
>  On Fri, 24 Jan 2003, Anoop J.
> wrote:
>
>> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
>> From: Anoop J. <cs99001@nitc.ac.in>
>> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
>>
>>
>> How is this different from a fully associative cache .Would be better
>> if u could deal it based on the address bits used
>>

Re: your mail

[Anoop J.]

I read that the data coherency problem due to virtual indexing is avoided
through page coloring and it has also got the speed of physical indexing
can u just elaborate on how this is possible?


Thanks




> implementing a fully associative cache eliminates the need for page
> coloring, but it has to be implemented in hardware. if you don't have
> fully associative caches in your hardware page coloring helps avoid the
> worst case memory allocations.
>
> from what I have seen on the attempts to implement it the problem is
> that the calculations needed to do page colored allocations end up
> costing enough that they end up with a net loss compared to the old
> method.
>
> David Lang
>
>
>  On Fri, 24 Jan 2003, Anoop J.
> wrote:
>
>> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
>> From: Anoop J. <cs99001@nitc.ac.in>
>> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
>>
>>
>> How is this different from a fully associative cache .Would be better
>> if u could deal it based on the address bits used
>>



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[David Lang]

I think this is a case of the same tuerm being used for two different
purposes. I don't know the use you are refering to.

David Lang


On Fri, 24 Jan 2003, Anoop J. wrote:

> I read that the data coherency problem due to virtual indexing is avoided
> through page coloring and it has also got the speed of physical indexing
> can u just elaborate on how this is possible?
>
>
> Thanks
>
>
>
>
> > implementing a fully associative cache eliminates the need for page
> > coloring, but it has to be implemented in hardware. if you don't have
> > fully associative caches in your hardware page coloring helps avoid the
> > worst case memory allocations.
> >
> > from what I have seen on the attempts to implement it the problem is
> > that the calculations needed to do page colored allocations end up
> > costing enough that they end up with a net loss compared to the old
> > method.
> >
> > David Lang
> >
> >
> >  On Fri, 24 Jan 2003, Anoop J.
> > wrote:
> >
> >> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
> >> From: Anoop J. <cs99001@nitc.ac.in>
> >> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
> >>
> >>
> >> How is this different from a fully associative cache .Would be better
> >> if u could deal it based on the address bits used
> >>
>
>
>

Re: your mail

[David Lang]

I think this is a case of the same tuerm being used for two different
purposes. I don't know the use you are refering to.

David Lang


On Fri, 24 Jan 2003, Anoop J. wrote:

> I read that the data coherency problem due to virtual indexing is avoided
> through page coloring and it has also got the speed of physical indexing
> can u just elaborate on how this is possible?
>
>
> Thanks
>
>
>
>
> > implementing a fully associative cache eliminates the need for page
> > coloring, but it has to be implemented in hardware. if you don't have
> > fully associative caches in your hardware page coloring helps avoid the
> > worst case memory allocations.
> >
> > from what I have seen on the attempts to implement it the problem is
> > that the calculations needed to do page colored allocations end up
> > costing enough that they end up with a net loss compared to the old
> > method.
> >
> > David Lang
> >
> >
> >  On Fri, 24 Jan 2003, Anoop J.
> > wrote:
> >
> >> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
> >> From: Anoop J. <cs99001@nitc.ac.in>
> >> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
> >>
> >>
> >> How is this different from a fully associative cache .Would be better
> >> if u could deal it based on the address bits used
> >>
>
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[David Lang]

implementing a fully associative cache eliminates the need for page
coloring, but it has to be implemented in hardware. if you don't have
fully associative caches in your hardware page coloring helps avoid the
worst case memory allocations.

from what I have seen on the attempts to implement it the problem is that
the calculations needed to do page colored allocations end up costing
enough that they end up with a net loss compared to the old method.

David Lang


 On Fri, 24 Jan 2003, Anoop J.
wrote:

> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
>
>
> How is this different from a fully associative cache .Would be better if u
> could deal it based on the address bits used
>
> Thanks
>
> David Lang wrote:
>
> >The idea of page coloring is based on the fact that common implementations
> >of caching can't put any page in memory in any line in the cache (such an
> >implementation is possible, but is more expensive to do so is not commonly
> >done)
> >
> >With this implementation it means that if your program happens to use
> >memory that cannot be mapped to half of the cache lines then effectivly
> >the CPU cache is half it's rated size for your program. the next time your
> >program runs it may get a more favorable memory allocation and be able to
> >use all of the cache and therefor run faster.
> >
> >Page coloring is an attampt to take this into account when allocating
> >memory to programs so that every program gets to use all of the cache.
> >
> >David Lang
> >
> >
> > On Fri, 24 Jan 2003, Anoop J. wrote:
> >
> >>Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
> >>From: Anoop J. <cs99001@nitc.ac.in>
> >>To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
> >>
> >>
> >>How does page coloring work. Iwant its mechanism not the implementation.
> >>I went through some pages of W.L.Lynch's paper on cache and VM. Still not
> >>able to grasp it .
> >>
> >>
> >>Thanks in advance
> >>
> >>
> >>
> >>-
> >>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/
> >>
> >
>
>
>
> -
> 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/
>

Re: your mail

[David Lang]

implementing a fully associative cache eliminates the need for page
coloring, but it has to be implemented in hardware. if you don't have
fully associative caches in your hardware page coloring helps avoid the
worst case memory allocations.

from what I have seen on the attempts to implement it the problem is that
the calculations needed to do page colored allocations end up costing
enough that they end up with a net loss compared to the old method.

David Lang


 On Fri, 24 Jan 2003, Anoop J.
wrote:

> Date: Fri, 24 Jan 2003 11:24:24 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
>
>
> How is this different from a fully associative cache .Would be better if u
> could deal it based on the address bits used
>
> Thanks
>
> David Lang wrote:
>
> >The idea of page coloring is based on the fact that common implementations
> >of caching can't put any page in memory in any line in the cache (such an
> >implementation is possible, but is more expensive to do so is not commonly
> >done)
> >
> >With this implementation it means that if your program happens to use
> >memory that cannot be mapped to half of the cache lines then effectivly
> >the CPU cache is half it's rated size for your program. the next time your
> >program runs it may get a more favorable memory allocation and be able to
> >use all of the cache and therefor run faster.
> >
> >Page coloring is an attampt to take this into account when allocating
> >memory to programs so that every program gets to use all of the cache.
> >
> >David Lang
> >
> >
> > On Fri, 24 Jan 2003, Anoop J. wrote:
> >
> >>Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
> >>From: Anoop J. <cs99001@nitc.ac.in>
> >>To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
> >>
> >>
> >>How does page coloring work. Iwant its mechanism not the implementation.
> >>I went through some pages of W.L.Lynch's paper on cache and VM. Still not
> >>able to grasp it .
> >>
> >>
> >>Thanks in advance
> >>
> >>
> >>
> >>-
> >>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/
> >>
> >
>
>
>
> -
> 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/
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[John Alvord]

The big challenge in Linux is that several serious attempts to add
page coloring have foundered on the shoals of "no benefit found". It
may be that the typical hardware Linux runs on just doesn't experience
the problem very much.

john


On Thu, 23 Jan 2003 21:11:10 -0800 (PST), David Lang
<david.lang@digitalinsight.com> wrote:

>The idea of page coloring is based on the fact that common implementations
>of caching can't put any page in memory in any line in the cache (such an
>implementation is possible, but is more expensive to do so is not commonly
>done)
>
>With this implementation it means that if your program happens to use
>memory that cannot be mapped to half of the cache lines then effectivly
>the CPU cache is half it's rated size for your program. the next time your
>program runs it may get a more favorable memory allocation and be able to
>use all of the cache and therefor run faster.
>
>Page coloring is an attampt to take this into account when allocating
>memory to programs so that every program gets to use all of the cache.
>
>David Lang
>
>
> On Fri, 24 Jan 2003, Anoop J. wrote:
>
>> Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
>> From: Anoop J. <cs99001@nitc.ac.in>
>> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
>>
>>
>> How does page coloring work. Iwant its mechanism not the implementation.
>> I went through some pages of W.L.Lynch's paper on cache and VM. Still not
>> able to grasp it .
>>
>>
>> Thanks in advance
>>
>>
>>
>> -
>> 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/
>>
>-
>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/

Re: your mail

[John Alvord]

The big challenge in Linux is that several serious attempts to add
page coloring have foundered on the shoals of "no benefit found". It
may be that the typical hardware Linux runs on just doesn't experience
the problem very much.

john


On Thu, 23 Jan 2003 21:11:10 -0800 (PST), David Lang
<david.lang@digitalinsight.com> wrote:

>The idea of page coloring is based on the fact that common implementations
>of caching can't put any page in memory in any line in the cache (such an
>implementation is possible, but is more expensive to do so is not commonly
>done)
>
>With this implementation it means that if your program happens to use
>memory that cannot be mapped to half of the cache lines then effectivly
>the CPU cache is half it's rated size for your program. the next time your
>program runs it may get a more favorable memory allocation and be able to
>use all of the cache and therefor run faster.
>
>Page coloring is an attampt to take this into account when allocating
>memory to programs so that every program gets to use all of the cache.
>
>David Lang
>
>
> On Fri, 24 Jan 2003, Anoop J. wrote:
>
>> Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
>> From: Anoop J. <cs99001@nitc.ac.in>
>> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
>>
>>
>> How does page coloring work. Iwant its mechanism not the implementation.
>> I went through some pages of W.L.Lynch's paper on cache and VM. Still not
>> able to grasp it .
>>
>>
>> Thanks in advance
>>
>>
>>
>> -
>> 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/
>>
>-
>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/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[Anoop J.]

How is this different from a fully associative cache .Would be better if u
could deal it based on the address bits used

Thanks

David Lang wrote:

>The idea of page coloring is based on the fact that common implementations
>of caching can't put any page in memory in any line in the cache (such an
>implementation is possible, but is more expensive to do so is not commonly
>done)
>
>With this implementation it means that if your program happens to use
>memory that cannot be mapped to half of the cache lines then effectivly
>the CPU cache is half it's rated size for your program. the next time your
>program runs it may get a more favorable memory allocation and be able to
>use all of the cache and therefor run faster.
>
>Page coloring is an attampt to take this into account when allocating
>memory to programs so that every program gets to use all of the cache.
>
>David Lang
>
>
> On Fri, 24 Jan 2003, Anoop J. wrote:
>
>>Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
>>From: Anoop J. <cs99001@nitc.ac.in>
>>To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
>>
>>
>>How does page coloring work. Iwant its mechanism not the implementation.
>>I went through some pages of W.L.Lynch's paper on cache and VM. Still not
>>able to grasp it .
>>
>>
>>Thanks in advance
>>
>>
>>
>>-
>>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/
>>
>



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[David Lang]

The idea of page coloring is based on the fact that common implementations
of caching can't put any page in memory in any line in the cache (such an
implementation is possible, but is more expensive to do so is not commonly
done)

With this implementation it means that if your program happens to use
memory that cannot be mapped to half of the cache lines then effectivly
the CPU cache is half it's rated size for your program. the next time your
program runs it may get a more favorable memory allocation and be able to
use all of the cache and therefor run faster.

Page coloring is an attampt to take this into account when allocating
memory to programs so that every program gets to use all of the cache.

David Lang


 On Fri, 24 Jan 2003, Anoop J. wrote:

> Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
>
>
> How does page coloring work. Iwant its mechanism not the implementation.
> I went through some pages of W.L.Lynch's paper on cache and VM. Still not
> able to grasp it .
>
>
> Thanks in advance
>
>
>
> -
> 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/
>

Re: your mail

[David Lang]

The idea of page coloring is based on the fact that common implementations
of caching can't put any page in memory in any line in the cache (such an
implementation is possible, but is more expensive to do so is not commonly
done)

With this implementation it means that if your program happens to use
memory that cannot be mapped to half of the cache lines then effectivly
the CPU cache is half it's rated size for your program. the next time your
program runs it may get a more favorable memory allocation and be able to
use all of the cache and therefor run faster.

Page coloring is an attampt to take this into account when allocating
memory to programs so that every program gets to use all of the cache.

David Lang


 On Fri, 24 Jan 2003, Anoop J. wrote:

> Date: Fri, 24 Jan 2003 10:38:03 +0530 (IST)
> From: Anoop J. <cs99001@nitc.ac.in>
> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
>
>
> How does page coloring work. Iwant its mechanism not the implementation.
> I went through some pages of W.L.Lynch's paper on cache and VM. Still not
> able to grasp it .
>
>
> Thanks in advance
>
>
>
> -
> 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/
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[Bruce]

On Thu, 16 Jan 2003, William Lee Irwin III wrote:

> On Thu, Jan 16, 2003 at 06:54:55PM -0500, devnull@adc.idt.com wrote:
> > unsubscribe linux-scsi@vger.kernel.org
> 
> Try sending that to majordomo@vger.kernel.org instead.

     Some people just don't pay attention...
       (perhaps they can't afford it ?)

Re: your mail

[William Lee Irwin III]

On Thu, Jan 16, 2003 at 06:54:55PM -0500, devnull@adc.idt.com wrote:
> unsubscribe linux-scsi@vger.kernel.org

Try sending that to majordomo@vger.kernel.org instead.


Bill

Re: your mail

[Pete Zaitcev]

> Linux version 2.4.20 (root@tomwaits) (gcc version 3.2) #1 SMP Sat Jan 11 18:46:51 CET 2003
> Intel MultiProcessor Specification v1.4
>     Virtual Wire compatibility mode.
>[...]
> PCI: Using IRQ router AMD768 [1022/7443] at 00:07.3
> PCI->APIC IRQ transform: (B1,I5,P0) -> 16
> PCI->APIC IRQ transform: (B2,I5,P0) -> 18

> PCI: Enabling device 02:08.2 (0014 -> 0016)
> PCI: No IRQ known for interrupt pin C of device 02:08.2. Probably buggy
> MP table.

I am sorry to say, I cannot help you. This is the department
of Manfred, most likely. The 95% bet is that your BIOS is crap,
and you have to poke ASUS. However, you might want to explore
a possiblity of a bug. The best way to do it is to run "mptable"
program to dump the table and then get someone who makes
a sense of the data. Try to figure out who wrote the code
to support AMD IRQ router. He may be the culprit (5%, but...)

 http://people.redhat.com/zaitcev/linux/mptable-2.0.15a-1.i386.rpm
 http://people.redhat.com/zaitcev/linux/mptable-2.0.15a-1.src.rpm

-- Pete

Re: your mail

[Rik van Riel]

On Mon, 11 Nov 2002, David Mosberger wrote:
> >>>>> On Mon, 11 Nov 2002 10:29:29 -0600, Mario Smarduch <cms063@email.mot.com> said:
>
>   Mario> I know that on some commercial Unix systems there are ways to
>   Mario> cap the CPU utilization by user/group ids are there such
>   Mario> features/patches available on Linux?

> The kernel patches available from this URL are pretty old (up to
> 2.4.6, as far as I could see), and I'm not sure what the future plans
> for PRM on Linux are.  Perhaps someone else can provide more details.

I'm (slowly) working on a per-user fair scheduler on top of Ingo's
O(1) scheduler.  Slowly because it's a fairly complex thing.

Once that is done it should be possible to change the accounting
to other resource containers and generally have fun assigning
priorities, though that is beyond the scope of what I'm trying to
achieve.

cheers,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://distro.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>

RE: your mail

[Bloch, Jack]

Thanks very much.

Jack Bloch 
Siemens ICN
phone                (561) 923-6550
e-mail                jack.bloch@icn.siemens.com


-----Original Message-----
From: Tom Bradley [mailto:tojabr@tojabr.com]
Sent: Thursday, October 31, 2002 1:00 PM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail


They are just regular values. The UL tells the compiler to format the
number as an unsgned long.


On Thu, 31 Oct 2002, Bloch, Jack wrote:

> I am looking at some sample driver code which shows the usage of some
> unsigned integers 1UL, 2UL, 4UL, 16UL, 64UL, 128UL and 256UL.  I need to
> know what these are defined as. Please excuse my ignorance.
>
> Please CC me directly on any responses.
>
> Jack Bloch
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com
>
> -
> 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/
>

Re: your mail

[Tom Bradley]

They are just regular values. The UL tells the compiler to format the
number as an unsgned long.


On Thu, 31 Oct 2002, Bloch, Jack wrote:

> I am looking at some sample driver code which shows the usage of some
> unsigned integers 1UL, 2UL, 4UL, 16UL, 64UL, 128UL and 256UL.  I need to
> know what these are defined as. Please excuse my ignorance.
>
> Please CC me directly on any responses.
>
> Jack Bloch
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com
>
> -
> 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/
>

Re: your mail

[Richard B. Johnson]

On Wed, 30 Oct 2002, Roberto Fichera wrote:

> I've a problem with a DAT on a Compaq Proliant ML350 with PIII 1GHz,
> 1Gb RAM, RAID controller Smart Array 451 with 3 x HDD 9Gb RAID 5
> and an internal SCSI controller Adaptec 7899 Ultra160 where is connected
> only a DAT 12/24 Gb. Current installed distribution is RH7.3 with its kernel
> 2.4.18-10 but I've tryed the standard 2.4.19 with the same problem.
> The problem is that the DAT don't work any more with Linux. This DAT work
> well on Win2K :-(! Below  there is some logs and a 'ps fax' showing a tar in
> D state.
> 
> Does anyone know a solution ?

> 
> Adaptec AIC7xxx driver version: 6.2.6
> aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
> Corrupted Serial EEPROM
^^^^^^^^^^^^^^^^^^^^^^^^^

I think your controller has fallen-back into survival mode
because it lost it's mind. You may want to upgrade the
controller BIOS to fix this problem. Then, see if it handles
tapes okay.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
   Bush : The Fourth Reich of America

Re: your mail

[Massimiliano Masserelli]

On Tue, Oct 29, 2002 at 05:26:23PM -0800, Michael Robinton wrote:

> There is no standard for the behavior of the motherboard bios when the
> first device 0x80 is not available at boot time. Some motherboards
> will automove 0x81 -> 0x80, some can do it as a bios change, some
> you're stuck.

Yes, I know. Anyway the problem doesn't seem connected with LILO, since
the kernel uncompresses smoothly, loads up the initrd image and THEN
hangs. The point is that the raidstart seems unable to initialize the
array if the /dev/hda disk is not present, and I can't understand why.
Is there some sort of priority between disks in a RAID-1 array?

Bye.
-- 
Massimiliano Masserelli
-------------------------------------------------------------------------------
He who hesitates is sometimes saved.

Re: your mail

[Greg Lindahl]

On Sat, Oct 26, 2002 at 03:48:27PM -0400, Zajerko-McKee, Nick wrote:

> I'm porting some code from x86 to mips(32) and noticed that in
> include/asm-mips/siginfo.h differs from include/asm-i386/siginfo.h in the
> order of elements of the sigchld structure.  Was this an oversight or a
> design decision?  I would think that it would be desirable to be almost the
> same as the x86 for userland ease of portability...

User programs normally get recompiled, so anything using the proper
includes IS portable.

The issue only appears if you are using binary translation of x86
programs on mips. For example, this is one:

http://www.transitives.com/products.htm

For this, you need to write a system call translation layer which
rearranges things appropriately. An existing example is the o32 layer
in mips64, and soon the n32 layer in mips64.

-- greg

Re: your mail

[Daniel Jacobowitz]

On Sat, Oct 26, 2002 at 03:48:27PM -0400, Zajerko-McKee, Nick wrote:
> Hi,
> 
> I'm porting some code from x86 to mips(32) and noticed that in
> include/asm-mips/siginfo.h differs from include/asm-i386/siginfo.h in the
> order of elements of the sigchld structure.  Was this an oversight or a
> design decision?  I would think that it would be desirable to be almost the
> same as the x86 for userland ease of portability...

It's probably for compatibility with that other MIPS operating system -
IRIX.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: your mail

[Kai Germaschewski]

On Fri, 18 Oct 2002, Rusty Russell wrote:

> > I wonder if this new method is going to be mandatory (the only one
> > available) or optional. I think there's two different kind of users, for
> > one modules which use an API which provides its own infrastructure for
> > dealing with modules via ->owner, on the other hand things like netfilter
> > (that's probably where you are coming from) where calls into a module,
> > which need protection are really frequent.
> 
> Mandatory for interfaces where the function can sleep (or be preempted).

and is not protected by other means (try_inc_mod_count()), I presume.

> > I see that your approach makes frequent calls into the module cheaper, but
> > I'm not totally convinced that the current safe interfaces need to change
> > just to accomodate rare cases like netfilter (there's most likely some
> > more cases like it, but the majority of modules is not).
> 
> They're not changing.  The current users doing try_inc_mod_count() are
> fine.  It's the ones not doing it which are problematic.

Alright, so I'm fine with it ;) (not that makes a difference, but...)

--Kai

Re: your mail

[Rusty Russell]

In message <Pine.LNX.4.44.0210170930410.6301-100000@chaos.physics.uiowa.edu> yo
u write:
> Since I made the mistake of getting involved into this discussion lately,

My condolences. 8)

> I wonder if this new method is going to be mandatory (the only one
> available) or optional. I think there's two different kind of users, for
> one modules which use an API which provides its own infrastructure for
> dealing with modules via ->owner, on the other hand things like netfilter
> (that's probably where you are coming from) where calls into a module,
> which need protection are really frequent.

Mandatory for interfaces where the function can sleep (or be preempted).

> Note that for the vast majority of modules, dealing with unload races is 
> as simple as setting ->owner, for example filesystems, network drivers.

Yes.  We do not have complete coverage though, this policy would
extend it.

> I see that your approach makes frequent calls into the module cheaper, but
> I'm not totally convinced that the current safe interfaces need to change
> just to accomodate rare cases like netfilter (there's most likely some
> more cases like it, but the majority of modules is not).

They're not changing.  The current users doing try_inc_mod_count() are
fine.  It's the ones not doing it which are problematic.

> Anyway, I may see further problems, but let me check first: Is your count
> supposed to only count users which are currently executing in the module's
> .text, or is it also to count references to data allocated in the module?
> (I.e. when I register_netdev(), does that keep a reference to the module
> even after the code has left the module's .text?)

It's to protect entry to the function, but of course, some interfaces
(eg. filesystems) lend themselves very neatly to batching this at
mount/unmount time.  Data is already protected by the usual means.

At risk of boring you, here's the document from the documentation
patch.  Suggestions welcome.

+Writing Modules and the Interfaces To Be Used By Them: A Gentle Guide.
+Copyright 2002, Rusty Russell IBM Corportation
+
+Modules are running parts of the kernel which can be added, and
+sometimes removed, while the kernel is operational.
+
+There are several delicate issues involved in this procedure which
+indicate special care should be taken.
+
+There are three cases you need to be careful:
+
+1) Any code which creates an interface for callbacks (ie. almost any
+   function called register_*)
+	=> See Rule #1
+
+2) Any modules which use (old) interfaces which do not obey Rule #1
+	=> See Rule #2
+
+Rule #1: Module-safe Interfaces.  Any interface which allows
+	registration of callbacks, must also allow registration of a
+	"struct module *owner", either in the structure or as a
+	function parameter, and it must use them to protect the
+	callbacks.  See "MAKING INTERFACES SAFE".
+
+Exception #1: As an optimization, you may skip this protection if you
+	   *know* that the callbacks are non-preemtible and never
+	   sleep (eg. registration of interrupt handlers).
+
+
+Rule #2: Modules using unsafe interfaces.  If your module is using any
+	interface which does not obey rule number 1, that means your
+	module functions may be called from the rest of the kernel
+	without the caller first doing a successful try_module_get().
+
+	You must not register a "module_cleanup" handler, and your module
+	cannot be unloaded except by force.  You must be especially
+	careful in this case with initialization: see "INITIALIZING
+	MODULES WHICH USE UNSAFE INTERFACES".
+
+MAKING INTERFACES SAFE
+
+A caller must always call "try_module_get()" on a function pointers's
+owner before calling through that function pointer.  If
+"try_module_get()" returns 0 (false), the function pointer must *not*
+be called, and the caller should pretend that registration does not
+exist: this means the (module) owner is closing down and doesn't want
+any more calls, or in the process of starting up and isn't ready yet.
+
+For many interfaces, this can be optimized by assuming that a
+structure containing function pointers has the same owner, and knowing
+that one function is always called before the others, such as the
+filesystem code which knows a mount must succeed before any other
+methods can be accessed.
+
+You must call "module_put()" on the owner sometime after you have
+called the function(s).
+
+If you cannot make your interface module-safe in this way, you can at
+least split registration into a "reserve" stage and an "activate"
+stage, so that modules can use the interface, even if they cannot
+(easily) unload.
+
+
+INITIALIZING MODULES WHICH USE UNSAFE INTERFACES
+
+Safe interfaces will never enter your module before module_init() has
+successfully finished, but unsafe interfaces may.  The rule is simple:
+your init_module() function *must* succeed (by returning 0) if it has
+successfully used any unsafe interfaces.
+
+So, if you are only using ONE unsafe interface, simply use that
+interface last.  Otherwise you will have to use printk() to report
+failure and leave the module initialized (but possibly useless).
+
+
+
+If you have questions about how to apply this document to your own
+modules, please ask rusty@rustcorp.com.au or linux-kernel@vger.kernel.org.
+
+Thankyou,
+Rusty.

--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: your mail

[Kai Germaschewski]

On Thu, 17 Oct 2002, Rusty Russell wrote:

> > But that one is easy: the zero check just takes the same spinlock as 
> > TRY_INC_MOD_COUNT, then sets can't-increment only in the case the count
> > is zero, considerably simpler than:
> 
> The current spinlock is horrible.  You could use a brlock, of course,
> but I didn't mainly because of code bloat and speed.  My current code
> looks like:
> 
> static inline int try_module_get(struct module *module)
> {
> 	int ret = 1;
> 
> 	if (module) {
> 		unsigned int cpu = get_cpu();
> 		if (likely(module->ref[cpu].live))
> 			local_inc(&module->ref[cpu].counter);
> 		else
> 			ret = 0;
> 		put_cpu();
> 	}
> 	return ret;
> }

Since I made the mistake of getting involved into this discussion lately,
I wonder if this new method is going to be mandatory (the only one
available) or optional. I think there's two different kind of users, for
one modules which use an API which provides its own infrastructure for
dealing with modules via ->owner, on the other hand things like netfilter
(that's probably where you are coming from) where calls into a module,
which need protection are really frequent.

Note that for the vast majority of modules, dealing with unload races is 
as simple as setting ->owner, for example filesystems, network drivers.

Sure, we need a global lock (unload_lock) when calling into these modules
initially, but these "binding/unbinding" calls are really rare. For
filesystems, they happen once per mount, for network drivers only for
ifconfig up/down. Afterwards, calling into the module (e.g. accessing the
mounted filesystem, xmitting/receiving data) doesn't have any overhead at
all compared to a linked-in filesystem/driver (well, ignore TLB misses)

I don't see a good reason to change this, in particular, since it provides 
useful information to the user, that is the mod_use_count. It means "Is it 
possible to successfully unload the module now?", and since looking at
the count and the actual unload is protected by unload_lock, the unload 
will either succeed basically immediately, or fail with -EBUSY right away.

I see that your approach makes frequent calls into the module cheaper, but
I'm not totally convinced that the current safe interfaces need to change
just to accomodate rare cases like netfilter (there's most likely some
more cases like it, but the majority of modules is not).

Anyway, I may see further problems, but let me check first: Is your count
supposed to only count users which are currently executing in the module's
.text, or is it also to count references to data allocated in the module?
(I.e. when I register_netdev(), does that keep a reference to the module
even after the code has left the module's .text?)

--Kai

Re: your mail

[Dave Jones]

On Mon, Oct 14, 2002 at 08:28:28AM +0200, Maros RAJNOCH /HiaeR Silvanna/ wrote:
 > Linux version 2.4.2-2 (root@porky.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-79)) #1 Sun Apr 8 20:41:30 EDT 2001

1, 2.4.2 is /very/ old, there are updated errata kernel packages at
    ftp.redhat.com
2, Bugs in Red Hat's kernel should be filed in http://bugzilla.redhat.com
   and not in linux-kernel.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: your mail

[Konstantin Boldyshev]

On Wed, 9 Oct 2002, Joshua Hudson wrote:

> When hunting down the last errors remaining in tar, I came across
> a particularly weird one in both tar and chmod.
>
> Try chmod 4755 true. True will have mode 755.
> This happens in linux 2.0.63, 2.2.22, 2.4.18-3
> Is anybody else getting this? Anybody have a solution?

It is chmod bug, it did 'mul bl' instead of mul bx.
CVS version has this bug fixed.

-- 
Regards,
Konstantin

Re: your mail

[jbradford]

> On Wed, 2002-10-02 at 17:09, Alan Cox wrote:
> > Look at history - if such a mess got in, it would never get sorted.
> 
> Instead of throwing around vague statements with little
> context like "compost heap" and "such a mess", why don't
> you spell out the specific design points of EVMS that you
> disagree with. The advantages and disadvantages of
> each point can then be discussed.

Yeah, but he is right in any case - look how the IDE mess of 2.5.x, which, frankly, I don't believe was ever as bad as people seem to be saying it was, has put people off testing 2.5.x.  Instead they are waiting for Linus to type

mv linux-2.5.x linux-2.6.0

at which point they think that all remaining bugs will auto-magically correct themselves and the tree is one again safe to use.  WRONG answer!

Simply from the point of view of not wanting to 'scare off' people from a whole tree, (which is so rediculous, I think I'll go and patent it), and as a result get less testing, we're better off trying to stop weirdness from getting in.

John.

Re: your mail

[Sam Ravnborg]

On Wed, Oct 02, 2002 at 02:41:42PM +0200, s.stoklossa@mentopolis.de wrote:
> beim versuch, die Einstellungen von alsa aufzurufen, kam folgende FM:
> 
>  Q> ./scripts/Menuconfig: MCmenu74: command not found
> 
> grusz
> 
> Sven
Known problem, try this patch:
copy-n-pated so may not apply cleanly, try by hand.
Ps. Please in english next time.

        Sam

--- linux/sound/Config.in       2002-10-01 12:09:44.000000000 +0200
+++ linux/sound/Config.in       2002-10-01 12:21:05.000000000 +0200
@@ -31,10 +31,7 @@
 if [ "$CONFIG_SND" != "n" -a "$CONFIG_ARM" = "y" ]; then
   source sound/arm/Config.in
 fi
-if [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC32" = "y" ]; then
-  source sound/sparc/Config.in
-fi
-if [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC64" = "y" ]; then
+if [ "$CONFIG_SND" != "n" -a "$CONFIG_SPARC32" = "y" ] || [ "$CONFIG_SND" !=
"n" -a "$CONFIG_SPARC64" = "y" ] ; then
   source sound/sparc/Config.in
 fi

Re: your mail

[Patrick Mochel]

In general, I agree completely with what Greg says (as usual), but I do 
have a few additional comments.

> (I'll skip the intro, and feel good sections and get into the details
> that you lay out, starting in section 2)
> 
> Section 2:
> 2.1:
> 	- do NOT use /proc for driver info.  Use driverfs.
> 	- If you are using a kernel version that does not have driverfs,
> 	  put all /proc driver info under /proc/drivers, which is where
> 	  it belongs.

Actually, they mention using driverfs in Section 3: Instrumentation. I 
can't tell if this was around before, or this was just added. The date is 
the same (16 Aug), but there is no changelog information about the spec. 

I would suggest not using procfs at all, even if driverfs is not avaiable.  
If you're using 2.4, backport driverfs, or clone it for your own
filesystem. It's not dependent on the driver model at all, and has been
done at least once before (Greg's pcihpfs).

> Section 3:

> The Common Statistic Manager:

Please drop the term 'Manager' from your nomenclature. It is ambiguous, 
because of the context in which its generally used in. Windows uses the 
term for any collection of kernel or device data and/or kernel policy. 
It's not a bad term, but it fails to make a clear distinction between 
kernel space and user space, which we insist on. 

Only the mechanism for setting the policy should exist in the kernel, and
itself my be very intelligent. But, the policy itself should exist outside
of the kernel.


> 3.2.5.2:
> (I'm not condoning ANY of these functions or code, just trying to point out how
> you should, if they were to be in the kernel, done properly.)
> 	- do not use typedef
> 	- struct stat_info does not need *unit, as that is already
> 	  specified in the scale field, right?
> 	- the stat_value_t union is just a horrible abomination, don't
> 	  do that.

Please do not pass void *. You should only pass type-safe structures. If 
you cannot get that information, you should redesign the API. 

> 3.4 Event logging:
> 	- I'm not even going to touch this, sorry.

There are a lot of topics in this spec, most of which are irrelevant to 
actually hardening drivers. They may be features dependent on your APIs, 
but they are completely optional and may hinder acceptance of your primary 
objectives. 

Event logging is definitely one of them, esp. with a function like

evl_log_event_string(  
	ME_EVENT_BUCKET_EMPTY, 
	LOG_WARNING, 
	"Leaky bucket exception (bucket empty):\ 
	Bucket_Level <= Observed_Value - Last_Value\ 
	|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s|%s=%s\ 
	|%s=%u|%s=%u|%s=%u|%s=%u|%s=%u|%s=%u|", 
	RMGT_FacilityIDAttrStr,         RMUUID, 
	RMGT_SubsystemIDAttrStr,    SUBSYSTEM_UUID, 
	RMGT_SubsystemNameAttrStr,  subsystem_name, 
	RMGT_ResourceIDAttrStr,         resource_id, 
	RMGT_ResourceNameAttrStr,   resource_name, 
	ME_MonitorIDAttrStr,        monitor_uuid,  
	ME_StatisticIDAttrStr,         statistic_id, 
	ME_StatisticNameAttrStr,    statistic_name,  
	ME_BucketSizeAttrStr,       bucketsz,  
	ME_FillValueAttrStr,            fillval, 
	ME_FillIntervalAttrStr,         fillint, 
	ME_BucketLevelAttrStr,      bucketlvl, 
	ME_ObservedValueAttrStr,    obsval, 
	ME_LastValueAttrStr,        lastval); 


> In summary, I think that a lot of people have spent a lot of time in
> creating this document, and the surrounding code that matches this
> document.  I really wish that a tiny bit of that effort had gone into
> contacting the Linux kernel development community, and asking to work
> with them on a project like this.  Due to that not happening, and by
> looking at the resultant spec and code, I'm really afraid the majority
> of that time and effort will have been wasted.

I completely agree. There is definitely good intention in some aspects of 
the spec, and definitely in the effort put forth to support this type of 
work. But, in order to gain the support of kernel developers, or even the 
blessing of a few, you should be working with them on the design from the 
beginnging.

Designing APIs is hard. Doing it well is very hard. I'm not claiming I've 
done a stellar job, but I have at least learned that. I've made a lot of 
poor design decisions, many of which are also evident in your code 
descriptions and examples. I can't tell you how many times I've rewritten 
things over and over and over because someone hated them (usually Linus or 
Greg).

There are people that are willing to help, as we are trying to do. But,
it's much easier if you do things gradually and get that help from the
beginning.

> What do I think can be salvaged?  Diagnostics are a good idea, and I
> think they fit into the driver model in 2.5 pretty well.  A lot of
> kernel janitoring work could be done by the CG team to clean up, and
> harden (by applying the things in section 2) the existing kernel
> drivers.  That effort alone would go a long way in helping the stability
> of Linux, and also introduce the CG developers into the kernel community
> as active, helping developers.  It would allow the CG developers to
> learn from the existing developers, as we must be doing something right
> for Linux to be working as well as it does :)

Which kernel are you targeting? I didn't see it in the spec, though I 
could have easily missed it. CGL is based on 2.4, so I would assume that. 
But, I would think the ideal choice would be to start in 2.5 and backport 
it to 2.4. 

If that's the case, how do you intend to work with the driver model? 
There will be quite a bit of code and interface duplication between
your code and the driver model. I can see ways to support many of the
things you want in a relatively easy manner, and not punish the common
user or developer; but the margin is to small to write the answer... ;)

Also, there are many projects in areas similar to what your doing: 
diganostics, HA, etc, etc. It would be nice to see some collaboration 
between the developers of those projects instead of having many disparate 
projects with similar goals. 


	-pat

Re: your mail

[Rik van Riel]

On Sat, 14 Sep 2002, Paolo Ciarrocchi wrote:

> I think that only the _memload_ test is not
> working with 2.5.*, am I wrong?

You're right, the memload test doesn't work with 2.5 but
needs the following patch...

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  september@surriel.com trac@trac.org


--- contest-0.1/mem_load.c.orig	2002-09-13 23:36:47.000000000 -0400
+++ contest-0.1/mem_load.c	2002-09-14 11:10:07.000000000 -0400
@@ -47,24 +47,25 @@
   switch (type) {

   case 0: /* RAM */
-    if ((position = strstr(buffer, "Mem:")) == (char *) NULL) {
-      fprintf (stderr, "Can't parse \"Mem:\" in /proc/meminfo\n");
+    if ((position = strstr(buffer, "MemTotal:")) == (char *) NULL) {
+      fprintf (stderr, "Can't parse \"MemTotal:\" in /proc/meminfo\n");
       exit (-1);
     }
-    sscanf (position, "Mem:  %ul", &size);
+    sscanf (position, "MemTotal:  %ul", &size);
     break;

   case 1:
-    if ((position = strstr(buffer, "Swap:")) == (char *) NULL) {
-      fprintf (stderr, "Can't parse \"Swap:\" in /proc/meminfo\n");
+    if ((position = strstr(buffer, "SwapTotal:")) == (char *) NULL) {
+      fprintf (stderr, "Can't parse \"SwapTotal:\" in /proc/meminfo\n");
       exit (-1);
     }
-    sscanf (position, "Swap: %ul", &size);
+    sscanf (position, "SwapTotal: %ul", &size);
     break;

   }

-  return (size / MB);
+  /* convert from kB to MB */
+  return (size / KB);

 }

--- contest-0.1/mem_load.h.orig	2002-09-14 11:09:28.000000000 -0400
+++ contest-0.1/mem_load.h	2002-09-14 11:09:42.000000000 -0400
@@ -24,6 +24,7 @@

 #define MAX_BUF_SIZE 1024          /* size of /proc/meminfo in bytes */
 #define MB (1024 * 1024)           /* 2^20 bytes */
+#define KB 1024
 #define MAX_MEM_IN_MB (1024 * 64)  /* 64 GB */

 /* Tuning parameter.  Increase if you are getting an 'unreasonable' load

Re: your mail

[Krzysiek Taraszka]

On Sat, 31 Aug 2002, Milton Miller wrote:

> At Fri Aug 30 2002 - 12:54:37 EST Krzysiek Taraszka (dzimi@pld.org.pl) wrote:
> > Great work, but in 2.2.22rc2 powerpc's still broken.
> > First of All Sources have got a lot of unsed stuff.
> > For example look like that:
> > 
> > [dzimi@cyborg linux]$ rgrep -n -R '*.*' 'CONFIG_PPC64' . 
> ...
> 
> Doesn't sound like -rc (release canidate) changes.

Well yes, in 2.2.10 someone tried to add CONFIG_PPC64 support in to 2.2 
kernel.
In 2.2.11 someone add CONFIG_PPC64 in to Config.in! but on 2.2.12 or 
2.2.13 someone remove it ... 
(without remove it from directory != arch/ppc/kernel/ )
 
> > Second kernel-2.2.21 still have got time init problems in symbios driver
> > on powerpc platform.
> > I send to you my ugly hack witch work, but IMHO he's ugly ;) I need to do
> > it correct.
> 
> > Third, kernel for powerpc boot and work on g3-266 but on g3-333 Ops ...
> > (kernel traps, kernel wrote: Caused by SRR1 or somethink like that, in 2.3
> > i saw #define FIX_SRR1 macro ...)
> 
> Well, SRR1 doesn't cause traps, but it does help tell you why they occurred.
> And the FIX_SRR1 stuff isn't the solution either if you look at it closer.
> How about a decoded oops?  Also, you didn't say what platform you were using.

I used g3 (pmac). My based system was PLD with 2.4.18 tree.
I used gcc-2.95.4 to build 2.2.21 vmlinux.

> As far as the open-pic changes you posted, how about explaining what your
> trying to fix (partly hidden by the rename and move to chrp_setup.c from
> open_pic.c)?

I tried to fix problem witch is on my IBM RS/6000 (model b50).
Openpic can't initialize propertly my scsi system. (sym82c8xx scsi 
driver). Some time init problems.

Oh I forgot, 2.2.22rc1/2 or kernel >= 2.2.16 (2.2 tree) didn't work on my 
IBM RS/6000 (b50).
Build with egcs work, but work slow (Bogomips: 16MHz!) and won't reboot 
and shutdown -h now.
The same code build with gcc Ops (Kernel Exception, look like openpic 
allocation address.)
I'll post the Ops later.

> I see you are wrapping the 8259 checks, but it also refers to a few new
> functions/macros I didn't see defined.

Hmm, yes, that why my patch is ugly. I want to do this correctly.
 
> How about discussing these problems and patches over at
> linuxppc-dev@lists.linuxppc.org ? (I set the reply-to there).

Ok, but first of all i should subscribe there.

Krzysiek Taraszka			(dzimi@pld.org.pl)

Re: your mail

[David Woodhouse]

adilger@clusterfs.com said:
>  I would instead suggest using a filesystem like JFFS2 for flash
> devices. This is journaled like ext3, but it also has the benefit of
> doing wear levelling on the device, which otherwise will probably wear
> out the superblock part of the flash rather quickly. 

He said he's using CompactFlash. CompactFlash is not flash, as far as we're
concerned: it is an IDE drive. You may think it has flash inside it; we
couldn't possibly comment.

In fact, it generally has a kind of pseudo-filesystem internally which it 
uses to emulate a block device with 512-byte sectors. It may do its own 
wear-levelling; the manufacturers are often quite cagey about whether it 
actually does or not. Draw your own conclusions about that if you will.

It's quite common to find that this internal pseudo-filesystem _itself_ gets
screwed on power failures. This tends to manifest itself as unrecoverable 
I/O errors.

There is no fundamental reason why every CF card should have these 
problems, in the same way as there is no fundamental reason why all PC 
BIOSes should be crap. But the same expectations apply.

If you want to pass power-fail testing, I would recommend you switch to
using real flash. JFFS2 on real flash has survived days of stress testing
whilst being power cycled randomly every ~5 minutes. The same tests were 
observed to destroy CF cards¹.

CF is bog-roll technology. It's disposable storage designed for temporary
use in stuff like cameras -- not for real computing. Think of it like a
floppy disc and you won't go far wrong.

--
dwmw2
¹ http://www.embeddedlinuxworks.com/articles/jffs_guide.html²
² Constant reboots no longer screw the wear levelling, as reported there.

Re: your mail

[Andreas Dilger]

On Aug 30, 2002  14:43 -0400, Bloch, Jack wrote:
> I have an embedded system runing a 2.4.18-3 Kernel. It runs from a 256MB
> compact flash disk (emulates an IDE interface). I am using an EXT2
> filesystem. During some power-off/power-on testing, the disk check failed.
> It dropped me to a shell and I had to run e2fsck -cfv to correct this
> problem. This is all good and well in a lab environment, but in reality,
> there is nobody there to perform the repair (running system is not equipped
> with keyboard and monitor). Is there any way to invoke e2fsck automatically
> or inhibit the failure detection mechanism? Please CC me directly on any
> responses.

I would instead suggest using a filesystem like JFFS2 for flash devices.
This is journaled like ext3, but it also has the benefit of doing wear
levelling on the device, which otherwise will probably wear out the
superblock part of the flash rather quickly.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: your mail

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

I would simply recommend switching to ext3, where these types of errors
generally don't occur.

Oh, and if you just edit your initscripts, you can do anything you want.

Matt

On Fri, Aug 30, 2002 at 02:43:52PM -0400, Bloch, Jack wrote:
> I have an embedded system runing a 2.4.18-3 Kernel. It runs from a 256MB
> compact flash disk (emulates an IDE interface). I am using an EXT2
> filesystem. During some power-off/power-on testing, the disk check failed.
> It dropped me to a shell and I had to run e2fsck -cfv to correct this
> problem. This is all good and well in a lab environment, but in reality,
> there is nobody there to perform the repair (running system is not equipped
> with keyboard and monitor). Is there any way to invoke e2fsck automatically
> or inhibit the failure detection mechanism? Please CC me directly on any
> responses.
> 
> 
> Thanks in advance....
> 
> Jack Bloch 
> Siemens ICN
> phone                (561) 923-6550
> e-mail                jack.bloch@icn.siemens.com
> 
> -
> 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/

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

My mother not mind to die for stoppink Windows NT!  She is rememberink 
Stalin!
					-- Pitr
User Friendly, 9/6/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: your mail

[Willy Tarreau]

On Tue, Aug 27, 2002 at 08:22:03PM +0200, Steffen Persvold wrote:
 
> I have an idea that this happens because the packets are comming out of 
> order into the receiving node (i.e the bonding device is alternating 
> between each interface when sending, and when the receiving node gets the 
> packets it is possible that the first interface get packets number 0, 2, 
> 4 and 6 in one interrupt and queues it to the network stack before packet 
> 1, 3, 5 is handled on the other interface).

You pointed your finger on this exact common problem.
You can use the XOR bonding mode (modprobe bonding mode=2), which uses a
hash of mac addresses to select the outgoing interface. This is interesting
if you have lots of L2 hosts on the same network switch.

Or if you have a few hosts on the same switch, you'd better use the "nexthop"
parameter of "ip route". IIRC, it should be something like :
  ip route add <destination> nexthop dev eth0 nexthop dev eth1
but read the help, I'm not certain.

Cheers,
Willy

RE: your mail

[Alex Pavloff]

Hi Gerald, here's some more info:

Sending data isn't the problem.  The problem is acting as a slave and
receiving unsolicited packets from a master.   I need to determine when a
packet is complete.  If I was sending the packets (which I have done before
and am doing now), I can cheat a bit because I know the length of the packet
I'm "supposed" to be getting back.   I can't do that when acting as a slave.

This is different that the other protocol I'm familiar with.

GE's SNP uses two packets -- the first fixed size and containing the length
of the second size.
AB's DF1 has a fixed packet structure with many special characaters that
makes it easy to pull in a piece at a time

With Modbus RTU I neither know how long a packet is going to be, nor do I
have a sequence of bytes that can be used to judge the end of a packet.  I
need to be able to understand that 3.5 characters times of nothing means the
end of the packet.

Do I need a line discipline for this one portion of the driver?

Alex Pavloff
Software Engineer
Eason Technology
 


-----Original Message-----
From: Gerald Emig [mailto:gme@emig-software.de]
Sent: Tuesday, August 27, 2002 3:00 AM
To: Alex Pavloff
Cc: 'linux-serial@vger.kernel.org'
Subject: Re: your mail



To wait for at least 3.5 character times you can simply wait for this time
or more using usleep() before sending your data.

On Mon, 26 Aug 2002, Alex Pavloff wrote:

>
> Good (morning/afternoon/evening) folks,
>
> I am writing Modbus RTU code for Linux 2.4.19.  While seeminly simple to
do
> in userspace, there's one big kicker that I can't handle there easily.
> Modbus RTU is a binary serial protocol used in industrial automation.
First
> used by the Modicon PLCs, it's found on a variety of devices from a
variety
> of manufacturers.
>
> The specification is at www.modbus.org, under "Modbus Standard Library",
and
> its the Modbus Serial Protocol Reference Guide.
>
> Here's the part that I don't think I can resolve in userspace:
> -----
> RTU Framing
> In RTU mode, messages start with a silent interval of at least 3.5
character
> times. This is most easily implemented as a multiple of character times at
> the baud rate that is being used on the network (shown as T1-T2-T3-T4 in
the
> figure below). The first field then transmitted is the device address.
>
> The allowable characters transmitted for all fields are hexadecimal 0-9,
> A-F. Networked devices monitor the network bus continuously, including
> during the 'silent' intervals. When the first field (the address field) is
> received, each device decodes it to find out if it is the addressed
device.
>
> Following the last transmitted character, a similar interval of at least
3.5
> character times marks the end of the message. A new message can begin
after
> this interval.
>
> The entire message frame must be transmitted as a continuous stream. If a
> silent interval of more than 1.5 character times occurs before completion
of
> the frame, the receiving device flushes the incomplete message and assumes
> that the next byte will be the address field of a new message.
> -----
>
> 3.5 character times at high baud rates is not something I can pull off
with
> termios.  To get the Modbus RTU frames without resorting to some really
> strange code in userspace, should I write a line-discipline module whose
> sole purpose is to deal with the character timing?
>
> Any comments (yay/nay/huh?) appreciated.
>
> Alex Pavloff
> Software Engineer
> Eason Technology
>
>

Gerald Emig

Re: your mail

[Gerald Emig]

To wait for at least 3.5 character times you can simply wait for this time
or more using usleep() before sending your data.

On Mon, 26 Aug 2002, Alex Pavloff wrote:

>
> Good (morning/afternoon/evening) folks,
>
> I am writing Modbus RTU code for Linux 2.4.19.  While seeminly simple to do
> in userspace, there's one big kicker that I can't handle there easily.
> Modbus RTU is a binary serial protocol used in industrial automation.  First
> used by the Modicon PLCs, it's found on a variety of devices from a variety
> of manufacturers.
>
> The specification is at www.modbus.org, under "Modbus Standard Library", and
> its the Modbus Serial Protocol Reference Guide.
>
> Here's the part that I don't think I can resolve in userspace:
> -----
> RTU Framing
> In RTU mode, messages start with a silent interval of at least 3.5 character
> times. This is most easily implemented as a multiple of character times at
> the baud rate that is being used on the network (shown as T1-T2-T3-T4 in the
> figure below). The first field then transmitted is the device address.
>
> The allowable characters transmitted for all fields are hexadecimal 0-9,
> A-F. Networked devices monitor the network bus continuously, including
> during the 'silent' intervals. When the first field (the address field) is
> received, each device decodes it to find out if it is the addressed device.
>
> Following the last transmitted character, a similar interval of at least 3.5
> character times marks the end of the message. A new message can begin after
> this interval.
>
> The entire message frame must be transmitted as a continuous stream. If a
> silent interval of more than 1.5 character times occurs before completion of
> the frame, the receiving device flushes the incomplete message and assumes
> that the next byte will be the address field of a new message.
> -----
>
> 3.5 character times at high baud rates is not something I can pull off with
> termios.  To get the Modbus RTU frames without resorting to some really
> strange code in userspace, should I write a line-discipline module whose
> sole purpose is to deal with the character timing?
>
> Any comments (yay/nay/huh?) appreciated.
>
> Alex Pavloff
> Software Engineer
> Eason Technology
>
>

Gerald Emig

Re: your mail

[Mike Dresser]

On Fri, 23 Aug 2002, Bill Unruh wrote:

> You could try running the little program I got basically from Carlson in
> http://axion.physics.ubc.ca/modem-chk.html
> to try resetting the serial line befor the next attempt (eg, put it into
> /etc/ppp/ip-down).
> Not sure if this is the problem however.

It died again.

I'm going to go out there and swap out the modem with a different model if
i have one.  If that doesn't fix it, I'll get that VIA garbage out of the
system and replaced with a proper Intel 815 based motherboard.

Mike

Re: your mail

[Mike Dresser]

On Fri, 23 Aug 2002, Bill Unruh wrote:

>
> OK, that problem is usually a "hardware" problem-- ie the hardware is
> not responding properly to the icotl request. This could be because
> there is not hardware there (eg trying to open a serial port which does
> not exist on the machine), or is busy, or has been left in some weird
> state. The last sounds most likely here-- eg the serial port on your
> modem thinks it is still busy.
>
> You could try running the little program I got basically from Carlson in
> http://axion.physics.ubc.ca/modem-chk.html
> to try resetting the serial line befor the next attempt (eg, put it into
> /etc/ppp/ip-down).
> Not sure if this is the problem however.

Another 7 minutes, and I'll know if this worked or not.

Another data point I just thought of, if i poff chatham, and then pon
chatham, that actually works.

It just hung up.

And redialed.

And connected properly.

Thank you so very much, it looks like your reset-serial did the job.

I'll implement it on future machines, just in case the same problem
happens, rather than pray it works.

I saw a lot of postings on the 5160 USR modem on the serial-pci-info list,
perhaps it's something to do with this modem.

I'll know for sure at 10:30 this evening, if it is definately owrking or
not.  I was logged in on the other line to monitor the syslog, and bring
up the internet line, just in case.

Thanks again,

Mike

Re: your mail

[Bill Unruh]

OK, that problem is usually a "hardware" problem-- ie the hardware is
not responding properly to the icotl request. This could be because
there is not hardware there (eg trying to open a serial port which does
not exist on the machine), or is busy, or has been left in some weird
state. The last sounds most likely here-- eg the serial port on your
modem thinks it is still busy.

You could try running the little program I got basically from Carlson in
http://axion.physics.ubc.ca/modem-chk.html
to try resetting the serial line befor the next attempt (eg, put it into
/etc/ppp/ip-down).
Not sure if this is the problem however.

On Fri, 23 Aug 2002, Mike Dresser wrote:

> On Fri, 23 Aug 2002, Bill Unruh wrote:
>
> > Well, it would be good if you actually told us what problem you were
> > describing. Is this a new connection attempt after the first hang up?
> > What?
> >
> > What repeats over and over-- I see no repeat.
>
> I >
> > You also do not tell us info like what kind of modem is this-- external,
> > internal, serial, usb, pci, winmodem,....
> >
> > I assume what you are refering to is the "inappropriate ioctl" line.
> > This indicates a hardware problem.
> >
> > Actually, it looks to me like another pppd is up on the line. Those
> > EchoReq are another pppd receiving stuff on an open pppd on another
> > line. More information on what it is you are trying to do, on what your
> > system is, and what the problem is might get you help.
> >
>
> Sorry.
>
> It's a new connection from the persist option.  The exact same message
> repeats for every dial out it attempts.
>
> It's a PCI 3com 56k Sportster.  It's a hardware modem.
>
> There is sometimes another pppd up on ttys1
>
> Here's the setup:
>
> There is an external modem on ttyS01, irq 3, that dials in occasionally as
> needed.
>
> there is an internal PCI modem on ttyS04, irq 5, that dials in permamently
> to the ISP.
>
> Every 6 hours, the ISP enforces the 6 hour hangup rule they have.
>
> The modem is set to persist, max-fails 0.  It is not able to redial, and
> keeps giving the error message that i pasted.
>
> Under 2.2.x, this functioned properly.
>
> System is a VIA VT82C693A/694x [Apollo PRO133x] based motherboard, from
> Giga-byte, if I remember correctly.  Celeron 533.
>
> Sorry about the too brief error message, I fell into my "it makes sense to
> me the way it is" trap.
>
> Mike
>
>

-- 
William G. Unruh        Canadian Institute for          Tel: +1(604)822-3273
Physics&Astronomy          Advanced Research            Fax: +1(604)822-5324
UBC, Vancouver,BC        Program in Cosmology           unruh@physics.ubc.ca
Canada V6T 1Z1               and Gravity           www.theory.physics.ubc.ca/
For step by step instructions about setting up ppp under Linux, see
            http://www.theory.physics.ubc.ca/ppp-linux.html

Re: your mail

[Mike Dresser]

On Fri, 23 Aug 2002, Bill Unruh wrote:

> Well, it would be good if you actually told us what problem you were
> describing. Is this a new connection attempt after the first hang up?
> What?
>
> What repeats over and over-- I see no repeat.

I >
> You also do not tell us info like what kind of modem is this-- external,
> internal, serial, usb, pci, winmodem,....
>
> I assume what you are refering to is the "inappropriate ioctl" line.
> This indicates a hardware problem.
>
> Actually, it looks to me like another pppd is up on the line. Those
> EchoReq are another pppd receiving stuff on an open pppd on another
> line. More information on what it is you are trying to do, on what your
> system is, and what the problem is might get you help.
>

Sorry.

It's a new connection from the persist option.  The exact same message
repeats for every dial out it attempts.

It's a PCI 3com 56k Sportster.  It's a hardware modem.

There is sometimes another pppd up on ttys1

Here's the setup:

There is an external modem on ttyS01, irq 3, that dials in occasionally as
needed.

there is an internal PCI modem on ttyS04, irq 5, that dials in permamently
to the ISP.

Every 6 hours, the ISP enforces the 6 hour hangup rule they have.

The modem is set to persist, max-fails 0.  It is not able to redial, and
keeps giving the error message that i pasted.

Under 2.2.x, this functioned properly.

System is a VIA VT82C693A/694x [Apollo PRO133x] based motherboard, from
Giga-byte, if I remember correctly.  Celeron 533.

Sorry about the too brief error message, I fell into my "it makes sense to
me the way it is" trap.

Mike

Re: your mail

[Bill Unruh]

Well, it would be good if you actually told us what problem you were
describing. Is this a new connection attempt after the first hang up?
What?

What repeats over and over-- I see no repeat.

You also do not tell us info like what kind of modem is this-- external,
internal, serial, usb, pci, winmodem,....

I assume what you are refering to is the "inappropriate ioctl" line.
This indicates a hardware problem.

Actually, it looks to me like another pppd is up on the line. Those
EchoReq are another pppd receiving stuff on an open pppd on another
line. More information on what it is you are trying to do, on what your
system is, and what the problem is might get you help.


On Fri, 23 Aug 2002, Mike Dresser wrote:

> I'm having problems with pppd under 2.4.19, with pppd 2.4.1
>
> I can establish a new connection, and no problems.  But once the ISP on
> the other end hangs up, this is what i get in my syslog.
> Repeats over and over.  I saw a few google postings about this, but those
> were back in _1999_, so I would think they were fixed by now.
>
> Doesn't matter if PPP is compiled in with the kernel, or modules.
>
> I'm running Debian 3.0(woody)
>
> This worked under Debian 2.2 and kernel 2.2.21
>
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (BUSY)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO CARRIER)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (VOICE)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO DIALTONE)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO DIAL TONE)
> Aug 23 10:25:55 tilburybackup chat[9825]: abort on (NO ANSWER)
> Aug 23 10:25:55 tilburybackup chat[9825]: send (ATZ^M)
> Aug 23 10:25:55 tilburybackup chat[9825]: expect (OK)
> Aug 23 10:25:55 tilburybackup chat[9825]: ATZ^M^M
> Aug 23 10:25:55 tilburybackup chat[9825]: OK
> Aug 23 10:25:55 tilburybackup chat[9825]:  -- got it
> Aug 23 10:25:55 tilburybackup chat[9825]: send (ATDT3806600^M)
> Aug 23 10:25:55 tilburybackup chat[9825]: expect (CONNECT)
> Aug 23 10:25:55 tilburybackup chat[9825]: ^M
> Aug 23 10:26:11 tilburybackup pppd[9804]: rcvd [LCP EchoReq id=0x4 magic=0x96835d5b]
> Aug 23 10:26:11 tilburybackup pppd[9804]: sent [LCP EchoRep id=0x4 magic=0x72c56787]
> Aug 23 10:26:11 tilburybackup pppd[9804]: sent [LCP EchoReq id=0x4 magic=0x72c56787]
> Aug 23 10:26:11 tilburybackup pppd[9804]: rcvd [LCP EchoRep id=0x4 magic=0x96835d5b]
> Aug 23 10:26:16 tilburybackup chat[9825]: ATDT3806600^M^M
> Aug 23 10:26:16 tilburybackup chat[9825]: CONNECT
> Aug 23 10:26:16 tilburybackup chat[9825]:  -- got it
> Aug 23 10:26:16 tilburybackup chat[9825]: send (\d)
> Aug 23 10:26:17 tilburybackup pppd[329]: Serial connection established.
> Aug 23 10:26:17 tilburybackup pppd[329]: using channel 1179
> Aug 23 10:26:17 tilburybackup pppd[329]: Couldn't create new ppp unit: Inappropriate ioctl for device
> Aug 23 10:26:18 tilburybackup pppd[329]: Hangup (SIGHUP)
>
> tilburybackup:/etc/ppp# egrep -v '#|^ *$' /etc/ppp/options
> asyncmap 0
> auth
> crtscts
> lock
> hide-password
> modem
> proxyarp
> lcp-echo-interval 30
> lcp-echo-failure 4
> noipx
> persist
> maxfail 0
>
> ttyS04 at port 0xcc00 (irq = 5) is a 16550A
>
> 00:0b.0 Serial controller: US Robotics/3Com 56K FaxModem Model 5610 (rev 01) (prog-if 02 [16550])
>         Subsystem: US Robotics/3Com USR 56k Internal FAX Modem (Model 2977)
>         Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
>         Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>         Interrupt: pin A routed to IRQ 5
>         Region 0: I/O ports at cc00 [size=8]
>         Capabilities: [dc] Power Management version 2
>                 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold+)
>                 Status: D0 PME-Enable- DSel=0 DScale=2 PME-
>
> Any ideas?
>
> Mike
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
William G. Unruh        Canadian Institute for          Tel: +1(604)822-3273
Physics&Astronomy          Advanced Research            Fax: +1(604)822-5324
UBC, Vancouver,BC        Program in Cosmology           unruh@physics.ubc.ca
Canada V6T 1Z1               and Gravity           www.theory.physics.ubc.ca/
For step by step instructions about setting up ppp under Linux, see
            http://www.theory.physics.ubc.ca/ppp-linux.html

Re: your mail

[Philipp Matthias Hahn]

Hello Jack!

On Mon, Aug 19, 2002 at 05:29:26PM -0400, Bloch, Jack wrote:
> Are there any plans to do an SCTP (RFC 2960) implementation for Linux?
> Please CC me directly on any responses.

The Linux Kernel 2.5 Status page at
	http://www.kernelnewbies.org/status/latest.html
lists the following URL:
	http://www.sf.net/projects/lksctp

BYtE
Philipp
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de

Re: your mail

[Willy Tarreau]

Hello !

On Fri, Aug 16, 2002 at 07:51:37AM +0000, Misha Alex wrote:
 
>      Also i tried the linear addressing linear = c*H*S + h*S +s -1 .But 
> linear or linear*512 never gave me the exact byte offset to seek.
> 
> I am working in linux and using a hexeditor to seek .How many exact bytes 
> should i seek to find out the extended partition.I read the MBR and found 
> the exteneded partiton.
> 00 01 01 00 02 fe 3f 01 3f 00 00 00 43 7d 00 00
> 80 00 01 02 0b fe bf 7e 82 7d 00 00 3d 26 9c 00
> 00 00 81 7f 0f fe ff ff bf a3 9c 00 f1 49 c3 01
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I haven't played with this for a long time, but I still have some memory
about this. First, when an offset is higher than 8GB, there's no way to
code it with the bios' CHS scheme as you find it in the partition table.
I see that you know how to decode this, so set all the CHS bits to ones
and look at the offset. For this reason, we often use only the size to
locate these partitions. If I recall correctly, the last 4 bytes of your
parts are the sizes in sectors. For example, hda2 is 9c263d sectors long,
which equals 5.2 GB. You'll notice that bytes 8 to 11 of each partitions
are nearly equivalent to the size of the previous part. They should be
the start offset in sectors. So in this case, hda3 begins at 9ca3bf
(byte 5255953920), and is 1c349f1 sectors long (15.1 GB).

I think that 'fe ff ff' after the partition type indicates that only the
linear mode should be used, but I'm not sure about this nor I do I have
any proof. You should read the partition code to get more clues, IMHO.

Hoping this helps,
Willy

Re: your mail

[Wayne Salamon]

On 8 Aug 2002, Samarth  Sharma wrote:

> hi,
>   A security aware application like the sshd daemon acts as an
> object manager for all its related processes..is this correct?? or
> are object managers are a part of the kernel.
>   if sshd does act as an object manager who enforces the access
> decisions for the sshd daemon..
>   Also if the daemon does act as an object manager does it not
> involve incorporating policy logic in the manager therby violating
> the primary principle of Flask architecture..

  All object access by processes will be controlled by the SELinux
module.  Security aware applications can make use of extended system calls
provided with SELinux to control security IDs on objects, but only as far
as the policy allows. Therefore, there is no violation, or bypassing, of
the controls provided by the Flask architecture.

  The application can control labeling of objects, but not the enforcement
of the policy based on those labels.


-- 
Wayne Salamon
wsalamon@tislabs.com


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[Stephen Smalley]

On Wed, 24 Jul 2002, Richard Mayo wrote:

> It's obvious to me how to configure my computer to boot only to SELinux,
> but how do I force the computer into Enforcing mode?

You need to specify enforcing=1 on the kernel command line, as noted in
selinux/README.  You can add an append="enforcing=1" line to the entry in
lilo.conf if using LILO or you can add enforcing=1 to the kernel line
in grub.conf if using GRUB.  If you want the kernel to always operate in
enforcing mode (i.e. never be able to toggle into permissive mode), you
can simply rebuild the kernel without the SELinux Development Module
option.  See step 20 of the README.

> Also, when a user logs on the system asks if he or she would like to switch
> user contexts.  Is there an easy way to suppress this?

You could change login.c to use get_default_user_sid rather than
get_user_sid if you want login to always use the default user SID.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[Jaroslav Kysela]

On Sat, 20 Jul 2002, Fernando Pablo Lopez-Lezcano wrote:

> > > > on a related note, although the above suggestion will fix this
> > > > particular problem, it seems that it might be wise to consider adding
> > > > a parameter order information field to the driver API, so that drivers
> > > > can say "you have to set param P first, then param N, then param
> > > > O". the default would obviously be "don't care", but for devices that
> > > > lose certain capabilities when certain parameters are set, it would
> > > > make things very much easier.
> > > 
> > > agreed that it's good to have such one.
> > > but how to implement this?
> > > from the design of hw_constraint, i don't think it's so easy...
> > 
> > I think that this implementation will create a big mess for the 
> > application developers. Also, I'm not sure, if it's really needed, because 
> > our refining code should already reduce the available configurations. 
> > Applications should use *_near() functions in order of their priority. You 
> > can't predict, if rate or count of channels or any other parameter is more 
> > important for a specific application.
> 
> [not exactly an answer but more details on what is actually happening]
> 
> I think this is what is happening with the current driver (Gary, please
> correct me if I'm wrong):  The application looks at the configuration
> space and selects from it one particular sampling rate. Then it looks at
> the channel count and sees a range of channel counts (10:18 - or some
> numbers like that, I don't remember). The application chooses the minimum
> channel count and the set function fails.
> 
> IMHO at that point the configuration space should have changed the number
> of channels available to match the sampling rate selected so that the
> channel count as advertised is legal (ie: if the selected sampling rate is
> one of the "single speed" rates then the range of channels should be
> 18:18, if the sampling rate is one of the "double speed" rates then the
> range should be 10:10).
> 
> The reverse is also true, if the application first selects number of 
> channels the sampling rates should be constrained to the set of rates that 
> can be supported by that number of channels. 

You've described exactly the behaviour which should be implemented in your
paragraphs. If the current implementation is broken, then we should fix
it.

> If it is not possible to do this with the current api, then the next best
> solution I can imagine is to have a switch that changes the mode of the
> card between single and double speed (that would make the dependency
> between sample rate and number of channels dissapear).

You may look to snd_rme9652_hw_rule_channels(), 
snd_rme9652_hw_rule_channels_rate() and 
snd_rme9652_hw_rule_rate_channels() functions in rme9652.c.

These functions exactly describes the contraints for rate/channels.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: your mail

[Min Li]

Hello, Yes, I tried to subcribe to those two lists. But I don't think they
are working. But I do need help right now...


On Sat, 6 Jul 2002, Hacksaw wrote:

> Hello Min:
> 
> I suggest your questions would be better asked on the kernle newbies list:
> http://mail.nl.linux.org/kernelnewbies/
> 
> and/or on the RedHat install List:
> 
> https://listman.redhat.com/mailman/listinfo/redhat-install-list.
> 
> The kernel list is strictly for talk about developing the kernel. Also, please 
> read the linux kernel mailing list FAQ: http://www.tux.org/lkml/
> -- 
> Powered by beta particles
> http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
> 
> 
> 

Re: your mail

[Gerhard Mack]

Right command wrong email address.  You need to send that to
majordomo@vger.kernel.org



On 5 Jul 2002, Christian Berger wrote:

> Date: 05 Jul 2002 10:47:32 +0200
> From: Christian Berger <christian@berger-online.de>
> To: linux-kernel@vger.kernel.org
>
> unsubscribe linux-kernel
>
>
> -
> 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/
>

--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: your mail

[Stephen Tweedie]

Hi,

On Thu, Jul 04, 2002 at 06:47:11PM +0500, Naseer Bhatti <naseer@digitallinx.com> wrote:

> I got these errors in the log on a Production server. I am running ProFTPD 1.2.4 with RedHat 7.2 Kernel 2.4.7-10 not yet compiled myself and Apache 1.3.26. I got my server stop responding and after reboot I checked the logs and got a lots of kernel bugs. ProFTPD was also involved in that. httpd (Apache 1.3.26) also gave some stack output. Correct me if I am wrong. I have attached the file for detailed analysis. Please check it and let me know about the possible bug/solution.

The log shows no sign of any ext3 problem.  I can't see anything in it
which would justify trying to send a compressed log of nearly 400kB to
an ext3 general users mailing list.

For what it's worth, your dcache oopses are most often associated with
bad memory --- try memtest86 on that machine before you go any
further.

--Stephen

Re: your mail

[Zwane Mwaikambo]

On 24 Jun 2002 pah@promiscua.org wrote:

> 	I've just found a bug (an unsignificant bug) in the panic() function!
> 	There's a possible buffer overflow if the formated string exceeds
> 1024 characters (I think that the problem is in all kernel releases).
> 	The problem is in the use of vsprintf() insted of vsnprintf()!
> 
> 	I know that this doesn't compromise any exploitation by an uid
> different than zero, but should be fixed in the case of panic()'s arguments
> exceeds the buffer limit (probably by an lkm or something like that) and
> cause (probably) a system crash.
> 

In that case there are quite a number of other places in the kernel which 
can be 'exploited' in various ways.

Cheers,
	Zwane

--
http://function.linuxpower.ca
		

Re: your mail

[David Mosberger]

>>>>> On Thu, 16 May 2002 21:24:10 +0530 (IST), Sanket Rathi <sanket.rathi@cdac.ernet.in> said:

  Sanket> No actually i don't want that for DMA it is for diffrent
  Sanket> requirment.  actually in our device there is a page table in
  Sanket> device which have virtual to physical address translation we
  Sanket> save virtual address in device and corresponding physical
  Sanket> address. but we can store only upto 44 bit information of
  Sanket> virtual address thats why i want that.

  Sanket> Can you help me in this

There is no way to limit virtual memory to 44 bits.  I don't know how
your device works, but just fyi: ia64 divides the address space into 8
equal-sized regions and user space applications tend to use at least
two regions (2 for text and 3 for data/stack).  This means that even
with the smallest page size, you'll have to take virtual address bits
61-63 into account.

Hope this helps,

	--david
--
Interested in learning more about IA-64 Linux?  Try http://www.lia64.org/book/

Re: your mail

[Alan Cox]

> No actually i don't want that for DMA it is for diffrent requirment.
> actually in our device there is a page table in device which have
> virtual to physical address translation we save virtual address in device
> and corresponding physical address. but we can store only upto 44 bit 
> information of virtual address thats why i want that.

Still read Documentation/DMA-mapping.txt

Whether its DMA or not you are going to need to keep the allocations below
44bits and thats what the DMA allocators do

Re: your mail

[Sanket Rathi]

No actually i don't want that for DMA it is for diffrent requirment.
actually in our device there is a page table in device which have
virtual to physical address translation we save virtual address in device
and corresponding physical address. but we can store only upto 44 bit 
information of virtual address thats why i want that.

Can you help me in this 

Thanks in advance

-----
--------Sanket


> > I just want to know how can we restrict the maximum virtual memory and
> > maximum physical memory on ia64 platform.
> > kernel. Actually we have a device which can only access 44 bits so we cant
> 
> That won't help you. You might not be dealing with RAM at the bottom of the
> address space. You might also be in platforms with an iommu, or doing DMA
> to another PCI target
> 
> > Tell me something related to this or any link which i can refer
> 
> Assuming the device is doing bus mastering. Read
> Documentation/DMA-mapping.txt
> 

Re: your mail

[Alan Cox]

> I just want to know how can we restrict the maximum virtual memory and
> maximum physical memory on ia64 platform.
> kernel. Actually we have a device which can only access 44 bits so we cant

That won't help you. You might not be dealing with RAM at the bottom of the
address space. You might also be in platforms with an iommu, or doing DMA
to another PCI target

> Tell me something related to this or any link which i can refer

Assuming the device is doing bus mastering. Read
Documentation/DMA-mapping.txt

Re: your mail

[tomas szepe]

> On Fri, 3 May 2002 16:37:38 +0200, 
> tomas szepe <kala@pinerecords.com> wrote:
>
> >kala@nibbler:~$ tar xzf /usr/src/linux-2.5.13.tgz 
> >kala@nibbler:~$ cd linux-2.5.13 
> >kala@nibbler:~/linux-2.5.13$ zcat /usr/src/kbuild-2.5-core-10.gz /usr/src/kbuild-2.5-common-2.5.13-1.gz /usr/src/kbuild-2.5-i386-2.5.13-1.gz |patch -sp1
> >kala@nibbler:~/linux-2.5.13$ cp /lib/modules/2.5.13/.config .
> >kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 oldconfig
> >Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
> 
> The trailing '/' is omitted in one case.  Workaround for common source and object
> 
> export KBUILD_SRCTREE_000=`pwd`/
> make -f Makefile-2.5 oldconfig

Another problem/question:

$ cd build
$ export KBUILD_OBJTREE=$PWD
$ export KBUILD_SRCTREE_000=/usr/src/linux-2.5.13
$ alias M="make -f $KBUILD_SRCTREE_000/Makefile-2.5"
$ cp /lib/modules/2.5.13/.config .
$ M oldconfig
...

$ M installable
...

[so far so good]

$ make -f Makefile-2.5 menuconfig
[enable RAMDISK support, tweak ramdisk size, enable initrd]
...

Now, issuing "M installable" will result in nearly all files getting rebuilt.
The same happens when switching ramdisk off again. How's that?

I tried enabling/disabling many other config options and doing rebuilds but
couldn't find anything as damaging buildtime-wise as the ramdisk stuff.

Hopefully I'm causing no headaches,
T.

Re: your mail

[Keith Owens]

On Fri, 3 May 2002 16:37:38 +0200, 
tomas szepe <kala@pinerecords.com> wrote:
>kala@nibbler:~$ tar xzf /usr/src/linux-2.5.13.tgz 
>kala@nibbler:~$ cd linux-2.5.13 
>kala@nibbler:~/linux-2.5.13$ zcat /usr/src/kbuild-2.5-core-10.gz /usr/src/kbuild-2.5-common-2.5.13-1.gz /usr/src/kbuild-2.5-i386-2.5.13-1.gz |patch -sp1
>kala@nibbler:~/linux-2.5.13$ cp /lib/modules/2.5.13/.config .
>kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 oldconfig
>Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory

The trailing '/' is omitted in one case.  Workaround for common source and object

export KBUILD_SRCTREE_000=`pwd`/
make -f Makefile-2.5 oldconfig

Re: your mail

[tomas szepe]

Building as follows works, though.

$ cd /usr/src && tar xzf linux-2.5.13.tar.gz
$ cd ~ && mkdir build && cd build
$ export KBUILD_OBJTREE=$PWD
$ export KBUILD_SRCTREE_000=/usr/src/linux-2.5.13
$ alias M="make -f $KBUILD_SRCTREE_000/Makefile-2.5"
$ cp /lib/modules/2.5.13/.config .
$ M oldconfig
$ M installable

T.


> > Release 2.4 of kernel build for kernel 2.5 (kbuild 2.5) is available.
> > http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
> > release 2.4.
> >
> > kbuild-2.5-core-13-1.
> 
> I believe you meant 's/13/10/'.
> 
> > kbuild-2.5-common-2.5.13-1.
> > kbuild-2.5-i386-2.5.13-1.
> 
> hmmm.. doesn't look so good.
> 
> kala@nibbler:~$ tar xzf /usr/src/linux-2.5.13.tgz 
> kala@nibbler:~$ cd linux-2.5.13 
> kala@nibbler:~/linux-2.5.13$ zcat /usr/src/kbuild-2.5-core-10.gz /usr/src/kbuild-2.5-common-2.5.13-1.gz /usr/src/kbuild-2.5-i386-2.5.13-1.gz |patch -sp1
> kala@nibbler:~/linux-2.5.13$ cp /lib/modules/2.5.13/.config .
> kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 oldconfig
> Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
> /home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
> Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
> /home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
> Using ARCH='i386' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
> Generating global Makefile
>   phase 1 (find all inputs)
> ...
> 
> kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 installable
> Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
> spec value %p not found
> /home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
> Using ARCH='i386' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
> Generating global Makefile
>   phase 1 (find all inputs)
>   phase 2 (convert all Makefile.in files)
>   phase 3 (evaluate selections)
>   phase 4 (integrity checks, write global makefile)
> pp_makefile4: arch/i386/lib/lib.a is selected but is not part of vmlinux, missing link_subdirs?
> make: *** [phase4] Error 1
> 
> 
> T.
> -
> 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/

Re: your mail

[tomas szepe]

> Release 2.4 of kernel build for kernel 2.5 (kbuild 2.5) is available.
> http://sourceforge.net/projects/kbuild/, package kbuild-2.5, download
> release 2.4.
>
> kbuild-2.5-core-13-1.

I believe you meant 's/13/10/'.

> kbuild-2.5-common-2.5.13-1.
> kbuild-2.5-i386-2.5.13-1.

hmmm.. doesn't look so good.

kala@nibbler:~$ tar xzf /usr/src/linux-2.5.13.tgz 
kala@nibbler:~$ cd linux-2.5.13 
kala@nibbler:~/linux-2.5.13$ zcat /usr/src/kbuild-2.5-core-10.gz /usr/src/kbuild-2.5-common-2.5.13-1.gz /usr/src/kbuild-2.5-i386-2.5.13-1.gz |patch -sp1
kala@nibbler:~/linux-2.5.13$ cp /lib/modules/2.5.13/.config .
kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 oldconfig
Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
/home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
/home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
Using ARCH='i386' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
Generating global Makefile
  phase 1 (find all inputs)
...

kala@nibbler:~/linux-2.5.13$ make -f Makefile-2.5 installable
Makefile-2.5:251: /no_such_file-arch/i386/Makefile.defs.noconfig: No such file or directory
spec value %p not found
/home/kala/linux-2.5.13/scripts/Makefile-2.5:473: /no_such_file-arch/i386/Makefile.defs.config: No such file or directory
Using ARCH='i386' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar'
Generating global Makefile
  phase 1 (find all inputs)
  phase 2 (convert all Makefile.in files)
  phase 3 (evaluate selections)
  phase 4 (integrity checks, write global makefile)
pp_makefile4: arch/i386/lib/lib.a is selected but is not part of vmlinux, missing link_subdirs?
make: *** [phase4] Error 1


T.

Re: your mail

[Stephen Smalley]

On Thu, 25 Apr 2002, Debian User wrote:

> I just used the prel script. Now im working on the syntax. I have the two
> white papers with me. I think I need to define new types and domains.
> What would possibly be the criteria for the decision? A rule of thumb if
> i may say so.

First, read the selinux/README file, particularly the post-install
instructions (starting around step 18).  Make sure that you don't have any
system processes left in initrc_t, as mentioned in step 18.

Domains and types are security equivalence classes for processes and
objects, respectively.  In other words, all processes in the same domain
have the same permissions, and all objects with the same type (and class)
can be accessed in the same way.  You want to use a distinct domain or
type when you want to distinguish a process or an object from others in
the security policy.  Processes that have the same security properties can
be placed into the same domain.  Similarly for objects and types.

The new policy report should be helpful in getting you started, although
it still isn't at the level of a HOWTO, so I'm hoping that others will
start writing HOWTOs derived from it and expanding upon it.  I expect this
report to be released soon, but I'm not sure exactly when.  Some
people at Tresys Technology have started writing some white papers related
to the policy that you can find at http://www.tresys.com/selinux.html.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com














--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[Alan Cox]

> 
> >INIT: Switching to runlevel: 6
> >INIT: Send processes the TERM signal
> >Unable to handle kernel NULL pointer dereference
>   
>   What's wrong with my machines?  They are all running linux-2.2.18(SMP-supported) with a kernel module which is a driver of Myricom NIC M3S-PCI64C-2 written by my group.
>   Thank you in advance 8-)

If you boot the machije without your driver, then reboot does the
same happen ? If not then it may well be your driver has an error but only
when it closes down

Re: your mail

[Zwane Mwaikambo]

On Wed, 24 Apr 2002, Huo Zhigang wrote:

>   Hi, all.
>   My cluster go wrong these days. So many times when I "/sbin/reboot" a node, the following message will be displayed on the console.
> 
> >INIT: Switching to runlevel: 6
> >INIT: Send processes the TERM signal
> >Unable to handle kernel NULL pointer dereference
>   
>   What's wrong with my machines?  They are all running linux-2.2.18(SMP-supported) with a kernel module which is a driver of Myricom NIC M3S-PCI64C-2 written by my group.
>   Thank you in advance 8-)
>   
>             Zhigang Huo
>             zghuo@ncic.ac.cn

Have you tried decoding the oops? Have a look at  
linux/Documentation/oops-tracing.txt

	Zwane

-- 
http://function.linuxpower.ca

Re: your mail

[Jeff Garzik]

On Sun, Apr 21, 2002 at 03:16:40PM -0600, Ivan G. wrote:
> Urban,
> 
> About the suggestion to make via_rhine_error handle more interrupts,
> 
> enum intr_status_bits {
>         IntrRxDone=0x0001, IntrRxErr=0x0004, IntrRxEmpty=0x0020,
>         IntrTxDone=0x0002, IntrTxAbort=0x0008, IntrTxUnderrun=0x0010,
>         IntrPCIErr=0x0040,
>         IntrStatsMax=0x0080, IntrRxEarly=0x0100, IntrMIIChange=0x0200,
>         IntrRxOverflow=0x0400, IntrRxDropped=0x0800, IntrRxNoBuf=0x1000,
>         IntrTxAborted=0x2000, IntrLinkChange=0x4000,
>         IntrRxWakeUp=0x8000,
>         IntrNormalSummary=0x0003, IntrAbnormalSummary=0xC260,
> };
> 
> RxEarly, RxOverflow, RxNoBuf are not handled
> (which brings up another question - how should they be handled 
> and where?? It doesn't seem to me that those should end up in error,
> sending CmdTxDemand. )

*blink*  I had not noticed that.

All drivers actually need to handle RxNoBufs and RxOverflow, assuming
they have similar meaning to what I'm familiar with on other chips.
The chip may recover transparently, but one should be at least aware of
them.

RxEarly you very likely do -not- want to handle...

	Jeff

Re: your mail

[William Lee Irwin III]

On Sun, Apr 21, 2002 at 02:54:00PM +0000, raciel wrote:
> Hello all :)
> 	I have been trying to understand the rmap patch from Rik Van Riel, but
> i dont undertand what the rmap patch do. Somebody can explain me or know
> a good site where i can get documentation?
> Regards Raciel 

The largest piece of functionality is additional accounting that enables
the kernel to find all users of a given page. This is known as physical
scanning, and other OS's call similar functionality "pmap", "ptov" (for
physical to virtual), and "HAT" (Hardware Address Translation), though
the interfaces are just as different as the names.

There are two very important translation mechanisms:
	(1) physical page to page table entry
	(2) 3rd-level pagetable to address space (mm_struct)

(1) is accomplished by using a singly linked list of page table entry
	addresses attached to a per-physical-page structure (struct page).

(2) is accomplished by reusing one of the fields of struct page for the
	3rd-level pagetable to hold the pointer to the mm_struct.


To clarify how a physical page is handled, the page replacement
algorithm might decide that a given physical page is targeted for
eviction. It then calls try_to_unmap(), which traverses the list of
3rd-level pagetable entries, and then rounds their addresses to
obtain the physical page occupied by the 3rd-level pagetable, then
it finds the struct page for that physical page, and then it tries
to obtain locks on the address space's pagetable lock and when it
does, it just removes the thing from the pagetable, otherwise it
returns an error code saying "try again later" (SWAP_AGAIN).

All this requires is

(1) putting an entry onto the per-page list when entering a page
	into pagetables

(2) pulling things off the per-page list when removing a page
	 from pagetables

(3) marking a 3rd-level pagetable's struct page with the mm_struct


Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[James Morris]

On 19 Apr 2002, raciel wrote:

> Somebody can tell me where i can get the LSM patch?

http://lsm.immunix.org/

-- 
James Morris
<jmorris@intercode.com.au>

Re: your mail

[Stephen Smalley]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2499 bytes --]


On Fri, 15 Mar 2002, [iso-8859-1] Vanuxem grégory wrote:

> I try to record the PSID directly in some attribute of inodes. Particularly
> in xfs.
> What do you think about that ?

This has come up previously on the mailing list, so you might want to
review the mailing list archives.  A brief review:

In the original SELinux kernel patch, we stored the PSID directly in a
spare field of the on-disk ext2 inode.  When SELinux was re-implemented to
use the LSM kernel patch, the persistent label mapping was changed to
maintain the inode-to-PSID mapping in a regular file rather than using a
field in the inode since LSM does not provide any low-level
filesystem-specific hooks.  That change allows SELinux to support other
filesystem types more easily, but has disadvantages in terms of
performance and consistency.

As support for extended attributes becomes mainstreamed, I'd like to see
SELinux enhanced to optionally use them for persistent labeling when they
are supported by the filesystem type.  This seems reasonable for XFS (but
see my earlier email regarding other issues with using XFS -
http://marc.theaimsgroup.com/?l=selinux&m=101300861319394&w=2).

Storing PSIDs via extended attributes is certainly one option.  Another
option would be to directly store file security contexts using extended
attributes, completely eliminating the separate persistent label mapping.
Regardless, you need to ensure that any changes you make don't prevent
SELinux from continuing to work with filesystems that do not support EAs.

> Another question, why the mapping inode->psid is always record in the file
> ...security/inode.
> For example, if I mount a file system that contained 50 differents types of
> files (context),the SECFILES keep all the mapping. Now I have just three
> types for the initialization, the root dir type, the fs type and the
> "file_t" type but the avc keep the precedent mapping (50 psids and
> contexts).

I'm not sure what you are asking.  The SELinux kernel module opens the
mapping files and does an initial load of the PSID-to-context mapping at
mount time.  The incore cache for the PSID-to-context mapping is for
performance.  The inode-to-PSID mapping would be too large to keep incore.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[Zwane Mwaikambo]

Firstly, thanks for doing this =) secondly i'll give your driver a try 
when you release the serial version (i have a serial cable + TI-83)

Cheers,
	Zwane

Re: your mail

[Alan Cox]

> +/*
> + * Deal with CONFIG_MODVERSIONS
> + */
> +#if 0 /* Pb with MODVERSIONS */
> +#if CONFIG_MODVERSIONS==1
> +#define MODVERSIONS
> +#include <linux/modversions.h>
> +#endif
> +#endif

[modversions.h is magically included by the kernel for you when its in 
 kernel if you haven't worked that one out yet]

> +#define PP_NO 3
> +struct tipar_struct  table[PP_NO];
static ?

> +               for(i=0; i < delay; i++) {
> +                       inbyte(minor);
> +               }
> +               schedule();

Oh random tip

		  if(current->need_resched)
			schedule();

will just give up the CPU when you are out of time

> +       if(table[minor].opened)
> +               return -EBUSY;
> +       table[minor].opened++;

Think about open/close at the same moment or SMP - the watchdog drivers all
had this problem and now do

	unsigned long opened = 0;

	if(test_and_set_bit(0, &opened))
		return -EBUSY;

	clear_bit(0, &opened)

[this generates atomic operations so is always safe]

> +       if(!table[minor].opened)
> +               return -EFAULT;

	BUG() may be better - it can't happen so BUG() will get a backtrace
and actually get it reported 8)

> +static long long tipar_lseek(struct file * file, long long offset, int origin)
> +{
> +       return -ESPIPE;
> +}

Can go (you now use no_llseek)


Basically except for the open/close one I'm now just picking holes. 
For the device major/minors see http://www.lanana.org.

Re: your mail

[Alan Cox]

> > +                       START(max);=20
> > +                       do {
> > +                               WAIT(max);
> > +                       } while (inbyte(minor) & 0x10);
> 
>              This may never happen. You end up waiting forever!

No - its hidden in his macros. Look harder

Re: your mail

[Richard B. Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 4611 bytes --]

On Wed, 13 Mar 2002, [ISO-8859-1] Romain Liévin wrote:
I'm going to comment on a few points:

[SNIPPED most...]

> +
> +/* D-bus protocol:
> +                    1                 0                      0
> +       _______        ______|______    __________|________    __________
> +Red  :        ________      |      ____          |        ____
> +       _        ____________|________      ______|__________       _____
> +White:  ________            |        ______      |          _______
> +*/
> +
> +/* Try to transmit a byte on the specified port (-1 if error). */
> +static int put_ti_parallel(int minor, unsigned char data)
> +{
> +       int bit, i;
> +       unsigned long max;
> +  
> +       for (bit=0; bit<8; bit++) {
> +               if (data & 1) {
> +                       outbyte(2, minor);
> +                       START(max); 
> +                       do {
> +                               WAIT(max);
> +                       } while (inbyte(minor) & 0x10);

             This may never happen. You end up waiting forever!
             If the port doesn't exist or is broken, it may return 0xff
             forever! You need to time-out and get out.


> +                       
> +                       outbyte(3, minor);
> +                       START(max);
> +                       do {
> +                               WAIT(max);
> +                       } while (!(inbyte(minor) & 0x10));

                     This may never happen. You end up awiting forever!
                     You need to time-out and get out.


> +               } else {
> +                       outbyte(1, minor);
> +                       START(max);
> +                       do {
> +                               WAIT(max);
> +                       } while (inbyte(minor) & 0x20);
> +                       
                       This also may never happen!
                       Same applies, time-out and get out.
                     
> +                       outbyte(3, minor);
> +                       START(max);
> +                       do {
> +                               WAIT(max);
> +                       } while (!(inbyte(minor) & 0x20));

                      This also may never happen!
                      Same applives, time-out and get out.

> +               }
> +               data >>= 1;
> +               for(i=0; i < delay; i++) {
> +                       inbyte(minor);
> +               }

> +               schedule();

                  This will just spin without setting
                  current->policy |= SCHED_YIELD;
                  (you really should use sys_sched_yield())


> +       }
> +       
> +       return 0;
> +}
> +
> +/* Receive a byte on the specified port or -1 if error. */
> +static int get_ti_parallel(int minor)
> +{
> +       int bit,i;
> +       unsigned char v, data=0;
> +       unsigned long max;
> +
> +       for (bit=0; bit<8; bit++) {
> +               START(max); 
> +               do {
> +                       WAIT(max);
> +               } while ((v=inbyte(minor) & 0x30) == 0x30);
> +      
                  More wait-forever above...

> +               if (v == 0x10) { 
> +                       data=(data>>1) | 0x80;
> +                       outbyte(1, minor);
> +                       START(max);
> +                       do {
> +                               WAIT(max);
> +                       } while (!(inbyte(minor) & 0x20));

                      More wait-forever above.


> +                       outbyte(3, minor);
> +               } else {
> +                       data=data>>1;
> +                       outbyte(2, minor);
> +                       START(max);
> +                       do {
> +                               WAIT(max);
> +                       } while (!(inbyte(minor) & 0x10));
> +                       outbyte(3, minor);
                      More wait-forever!

> +               }
> +               for(i=0; i<delay; i++) {
> +                       inbyte(minor);
> +               }
> +               schedule();
                  No current->policy

> +       }
> +       return (int)data;
> +}
> +

[SNIPPED rest]


Basically, this code performs a needed function. I have been waiting
for someone to write this! However, it's not yet ready for prime-time.
Never assume that hardware is going to produce what you expect. Don't
wait forever for something that was supposed to happen. You'll hang
the machine.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: your mail

[Romain Liévin]

Quoting Alan Cox <alan@lxorguk.ukuu.org.uk>:

> > It has been tested on x86 for almost 2 years and on Alpha & Sparc too
> with 
> > various calculators.
> 
> One oddity - some other comments
> 
> > +static int tipar_open(struct inode *inode, struct file *file)
> > +{
> > +       unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
> > +
> > +       if (minor >= PP_NO)
> > +               return -ENXIO;  
> > +       
> > +       init_ti_parallel(minor);
> > +
> > +       MOD_INC_USE_COUNT;
> 
> You should remove these and use in 2.4 + . Also what stops multiple
> simultaneous runs of init_ti_parallel if two people open it at once ?
> 
> 
> > +static unsigned int tipar_poll(struct file *file, poll_table *
> wait)
> > +{
> > +       unsigned int mask=0;
> > +       return mask;
> > +}
> 
> That seems unfinished ??
> 
> > +static int tipar_ioctl(struct inode *inode, struct file *file,
> > +                      unsigned int cmd, unsigned long arg)
> > +       case O_NONBLOCK:
> > +               file->f_flags |= O_NONBLOCK;
> > +               return 0;
> 
> O_NDELAY is set by fcntl - your driver never needs this.
> 
> > +       default:
> > +               retval = -EINVAL;
> 
> SuS says -ENOTTY here (lots of drivers get this wrong still)
> 
> > +static long long tipar_lseek(struct file * file, long long offset,
> int origin)
> > +{
> > +       return -ESPIPE;
> > +}
> 
> There is a generic no_llseek function
> 
> > +/* Major & minor number for character devices */
> > +#define TIPAR_MAJOR   61
> 
> These don't appear to be officially assigned via lanana ?
> -
> 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/
> 

Fixed some stuffs according to your remarks.

Comments are welcome...

=================== [ cuts here ] =====================
--- linux.orig/drivers/char/tipar.c     Wed Mar 13 19:19:10 2002
+++ linux/drivers/char/tipar.c  Wed Mar 13 21:24:51 2002
@@ -0,0 +1,543 @@
+/* Hey EMACS -*- linux-c -*-
+ *
+ * tipar - low level driver for handling a parallel link cable
+ * designed for Texas Instruments graphing calculators.
+ *
+ * Copyright (C) 2000-2002, Romain Lievin <roms@lpg.ticalc.org>
+ * under the terms of the GNU General Public License.
+ */
+
+#define VERSION "1.12"
+
+/* This driver should, in theory, work with any parallel port that has an
+ * appropriate low-level driver; all I/O is done through the parport
+ * abstraction layer.
+ *
+ * If this driver is built into the kernel, you can configure it using the
+ * kernel command-line.  For example:
+ *
+ *      tipar=timeout,delay       (set timeout and delay)
+ *
+ * If the driver is loaded as a module, similar functionality is available
+ * using module parameters.  The equivalent of the above commands would be:
+ *
+ *      # insmod tipar.o tipar=15,10
+ */
+
+/* COMPATIBILITY WITH OLD KERNELS
+ *
+ * Usually, parallel cables were bound to ports at
+ * particular I/O addresses, as follows:
+ *
+ *      tipar0             0x378
+ *      tipar1             0x278
+ *      tipar2             0x3bc
+ *
+ *
+ * This driver, by default, binds tipar devices according to parport and
+ * the minor number.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/config.h>
+#include <linux/version.h>
+#include <linux/init.h>
+#include <asm/uaccess.h>
+#include <linux/ioport.h>
+#include <linux/errno.h>
+#include <linux/sched.h>
+#include <linux/fs.h>
+#include <asm/io.h>
+#include <linux/devfs_fs_kernel.h>
+#include <linux/parport.h> /* Our code depend on parport */
+
+/*
+ * TI definitions
+ */
+#include <linux/ticable.h>
+
+/*
+ * Deal with CONFIG_MODVERSIONS
+ */
+#if 0 /* Pb with MODVERSIONS */
+#if CONFIG_MODVERSIONS==1
+#define MODVERSIONS
+#include <linux/modversions.h>
+#endif
+#endif
+
+/* ----- global variables --------------------------------------------- */
+
+struct tipar_struct {
+       struct pardevice *dev;                  /* Parport device entry */
+       int opened;
+};
+
+#define PP_NO 3
+struct tipar_struct  table[PP_NO];
+
+static int delay   = IO_DELAY;      /* inter-bit delay in microseconds */
+static int timeout = TIMAXTIME;     /* timeout in tenth of seconds     */
+
+static devfs_handle_t devfs_handle = NULL;
+static unsigned int tp_count = 0;   /* tipar_count */
+
+/* --- macros for parport access -------------------------------------- */
+
+#define r_dtr(x)        (parport_read_data(table[(x)].dev->port))
+#define r_str(x)        (parport_read_status(table[(x)].dev->port))
+#define w_ctr(x,y)      (parport_write_control(table[(x)].dev->port, (y)))
+#define w_dtr(x,y)      (parport_write_data(table[(x)].dev->port, (y)))
+
+/* --- setting states on the D-bus with the right timing: ------------- */
+
+static inline void outbyte(int value, int minor)
+{
+       w_dtr(minor, value);
+}
+
+static inline int inbyte(int minor)
+{
+       return (r_str(minor) & 0x30);
+}
+
+static inline void init_ti_parallel(int minor)
+{
+       outbyte(3, minor);
+}
+
+/* ----- global defines ----------------------------------------------- */
+
+#define START(x) { max=jiffies+HZ/(timeout/10); }
+#define WAIT(x) { if(!time_before(jiffies, (x))) return -1; schedule(); }
+
+/* ----- D-bus bit-banging functions ---------------------------------- */
+
+/* D-bus protocol:
+                    1                 0                      0
+       _______        ______|______    __________|________    __________
+Red  :        ________      |      ____          |        ____
+       _        ____________|________      ______|__________       _____
+White:  ________            |        ______      |          _______
+*/
+
+/* Try to transmit a byte on the specified port (-1 if error). */
+static int put_ti_parallel(int minor, unsigned char data)
+{
+       int bit, i;
+       unsigned long max;
+  
+       for (bit=0; bit<8; bit++) {
+               if (data & 1) {
+                       outbyte(2, minor);
+                       START(max); 
+                       do {
+                               WAIT(max);
+                       } while (inbyte(minor) & 0x10);
+                       
+                       outbyte(3, minor);
+                       START(max);
+                       do {
+                               WAIT(max);
+                       } while (!(inbyte(minor) & 0x10));
+               } else {
+                       outbyte(1, minor);
+                       START(max);
+                       do {
+                               WAIT(max);
+                       } while (inbyte(minor) & 0x20);
+                       
+                       outbyte(3, minor);
+                       START(max);
+                       do {
+                               WAIT(max);
+                       } while (!(inbyte(minor) & 0x20));
+               }
+               data >>= 1;
+               for(i=0; i < delay; i++) {
+                       inbyte(minor);
+               }
+               schedule();
+       }
+       
+       return 0;
+}
+
+/* Receive a byte on the specified port or -1 if error. */
+static int get_ti_parallel(int minor)
+{
+       int bit,i;
+       unsigned char v, data=0;
+       unsigned long max;
+
+       for (bit=0; bit<8; bit++) {
+               START(max); 
+               do {
+                       WAIT(max);
+               } while ((v=inbyte(minor) & 0x30) == 0x30);
+      
+               if (v == 0x10) { 
+                       data=(data>>1) | 0x80;
+                       outbyte(1, minor);
+                       START(max);
+                       do {
+                               WAIT(max);
+                       } while (!(inbyte(minor) & 0x20));
+                       outbyte(3, minor);
+               } else {
+                       data=data>>1;
+                       outbyte(2, minor);
+                       START(max);
+                       do {
+                               WAIT(max);
+                       } while (!(inbyte(minor) & 0x10));
+                       outbyte(3, minor);
+               }
+               for(i=0; i<delay; i++) {
+                       inbyte(minor);
+               }
+               schedule();
+       }
+       return (int)data;
+}
+
+/* Return non zero if both lines are at logical one */
+static int check_ti_parallel(int minor)
+{
+       return ((inbyte(minor) & 0x30) == 0x30);
+}
+
+/* Try to detect a parallel link cable on the specified port */
+static int probe_ti_parallel(int minor)
+{
+       int i, j;
+       int seq[]={ 0x00, 0x20, 0x10, 0x30 };
+       unsigned char data = 0;
+       
+       for(i=3; i>=0; i--) {
+               outbyte(3, minor);
+               outbyte(i, minor);
+               for(j=0; j<delay; j++) data = inbyte(minor);
+               /*printk("Probing -> %i: 0x%02x 0x%02x\n", i, data & 0x30,
seq[i]);*/
+               if( (data & 0x30) != seq[i]) {
+                       outbyte(3, minor);
+                       return -1;
+               }
+       } 
+       outbyte(3, minor);
+       return 0;
+}
+
+/* ----- kernel module functions--------------------------------------- */
+
+static int tipar_open(struct inode *inode, struct file *file)
+{
+       unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
+
+       if (minor >= PP_NO)
+               return -ENXIO;
+
+       if(table[minor].opened)
+               return -EBUSY;
+
+       table[minor].opened++;
+
+       lp_claim_parport_or_block(table[minor].dev);
+       init_ti_parallel(minor);
+       lp_release_parport(table[minor].dev);
+
+       return 0;
+}
+
+static int tipar_close(struct inode *inode, struct file *file)
+{
+       if (minor >= PP_NO)
+               return -ENXIO;
+
+       if(!table[minor].opened)
+               return -EFAULT;
+
+       table[minor].opened--;
+
+       return 0;
+}
+
+static ssize_t tipar_write(struct file *file,
+                          const char *buf, size_t count, loff_t *ppos)
+{
+       unsigned int minor = minor(file->f_dentry->d_inode->i_rdev) - 
+               TIPAR_MINOR_0;
+       ssize_t n;
+  
+       if (minor >= PP_NO)
+               return -ENXIO;
+
+       if (table[minor].dev == NULL) 
+               return -ENXIO;
+
+       parport_claim_or_block (table[minor].dev);
+       
+       for(n=0; n<count; n++) {
+               unsigned char b;
+               
+               if(get_user(b, buf + n)) {
+                       n = -EFAULT;
+                       goto out;
+               }
+
+               if(put_ti_parallel(minor, b) == -1) {
+                       init_ti_parallel(minor);
+                       n = -ETIMEDOUT;
+                       goto out;
+               }
+       }
+
+ out:
+       parport_release (table[minor].dev);
+       return n;
+}
+
+static ssize_t tipar_read(struct file *file, char *buf, 
+                         size_t count, loff_t *ppos)
+{
+       int b=0;
+       unsigned int minor=minor(file->f_dentry->d_inode->i_rdev) - 
+               TIPAR_MINOR_0;
+       ssize_t retval = 0;
+
+       if(count == 0)
+               return 0;
+
+       if(ppos != &file->f_pos)
+               return -ESPIPE;
+
+       parport_claim_or_block(table[minor].dev);
+  
+       do {
+               b = get_ti_parallel(minor);
+               if(b == -1) {
+                       init_ti_parallel(minor);
+                       retval = -ETIMEDOUT;
+                       goto out;
+               }
+               else
+                       break;
+      
+               /* Non-blocking mode: try again ! */
+               if (file->f_flags & O_NONBLOCK) {
+                       retval = -EAGAIN;
+                       goto out;
+               }
+               
+               /* Signal pending, try again ! */
+               if (signal_pending(current)) {
+                       retval = -ERESTARTSYS;
+                       goto out;
+               }
+
+               schedule();
+       } while (1);
+
+       retval = put_user(b, (unsigned char *)buf);
+       if(!retval)
+               retval = 1;
+       else
+               retval = -EFAULT;
+
+ out:
+       parport_release(table[minor].dev);
+       return retval;
+}
+
+static int tipar_ioctl(struct inode *inode, struct file *file,
+                      unsigned int cmd, unsigned long arg)
+{
+       unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
+       int retval = 0;
+
+       if (minor >= PP_NO) 
+               return -ENODEV;
+
+       switch (cmd) {
+       case 0:
+               break;
+       case TIPAR_DELAY:
+               delay = arg;
+               return 0;
+       case TIPAR_TIMEOUT:
+               timeout = arg;
+               return 0;
+       default:
+               retval = -ENOTTY;
+               break;
+       }
+
+       return retval;
+}
+
+static long long tipar_lseek(struct file * file, long long offset, int origin)
+{
+       return -ESPIPE;
+}
+
+
+/* ----- kernel module registering ------------------------------------ */
+
+static struct file_operations tipar_fops = {
+       owner:   THIS_MODULE,
+       llseek:  no_llseek,
+       read:    tipar_read,
+       write:   tipar_write,
+       ioctl:   tipar_ioctl,
+       open:    tipar_open,
+       release: tipar_close,
+};
+
+/* --- initialisation code ------------------------------------- */
+
+#ifndef MODULE
+/*      You must set these - there is no sane way to probe for this cable.
+ *      You can use tipar=timeout,delay to set these now. */
+static int __init tipar_setup (char *str)
+{
+       int ints[2];
+
+        str = get_options (str, ARRAY_SIZE(ints), ints);
+
+        if (ints[0] > 0) {
+                timeout = ints[1];
+                if(ints[0] > 1) {
+                        delay = ints[2];
+               }
+        }
+        return 1;
+}
+#endif
+
+/*
+ * Register our module into parport.
+ * Pass also 2 callbacks functions to parport: a pre-emptive function and an
+ * interrupt handler function (unused).
+ * Display a message such "tipar0: using parport0 (polling)".
+ */
+static int tipar_register(int nr, struct parport *port)
+{
+       char name[8];
+       
+       /* Register our module into parport */
+       table[nr].dev = parport_register_device(port, "tipar",
+                                               NULL, NULL, NULL, 0,
+                                               (void *) &table[nr]);
+       
+       if (table[nr].dev == NULL)
+               return 1;
+ 
+       /* Use devfs, tree: /dev/ticables/par/[0..2] */
+       sprintf(name, "%d", nr);
+       devfs_register(devfs_handle, name,
+                       DEVFS_FL_AUTO_DEVNUM, TIPAR_MAJOR, nr,
+                       S_IFCHR | S_IRUGO | S_IWUGO,
+                       &tipar_fops, NULL);
+
+       /* Display informations */
+       printk(KERN_INFO "tipar%d: using %s (%s).\n", nr, port->name,
+              (port->irq == PARPORT_IRQ_NONE) ? "polling" :
"interrupt-driven");
+
+       if(probe_ti_parallel(nr) != -1)
+               printk("tipar%d: link cable found !\n", nr);
+       else
+               printk("tipar%d: link cable not found (do not plug cable to
calc).\n", nr);
+
+       return 0;
+}
+
+static void tipar_attach (struct parport *port)
+{
+       if (tp_count == PP_NO) {
+               printk("tipar: ignoring parallel port (max. %d)\n", 
+                      PP_NO);
+               return;
+       }
+       if (!tipar_register(tp_count, port))
+               tp_count++;
+}
+
+static void tipar_detach (struct parport *port)
+{
+       /* Will be written at some point in the future */
+}
+
+static struct parport_driver tipar_driver = {
+       "tipar",
+       tipar_attach,
+       tipar_detach,
+       NULL
+};
+
+int tipar_init(void)
+{
+       unsigned int i;
+       
+       /* Initialize structure */
+       for (i = 0; i < PP_NO; i++) {
+               table[i].dev = NULL;
+               table[i].opened = 0;
+       }
+
+       /* Register parport device */  
+       if (devfs_register_chrdev (TIPAR_MAJOR, "tipar", &tipar_fops)) {
+               printk("tipar: unable to get major %d\n", TIPAR_MAJOR);
+               return -EIO;
+       }
+
+       /* Use devfs with tree: /dev/ticables/par/[0..2] */
+       devfs_handle = devfs_mk_dir (NULL, "ticables/par", NULL);
+
+       if (parport_register_driver (&tipar_driver)) {
+               printk ("tipar: unable to register with parport\n");
+               return -EIO;
+       }
+
+       return 0;
+}  
+
+int __init tipar_init_module(void)
+{
+       printk("tipar: parallel link cable driver, version %s\n", VERSION);
+       return tipar_init();
+}
+
+void __exit tipar_cleanup_module(void)
+{
+       unsigned int offset;
+
+       /* Unregistering module */
+       parport_unregister_driver (&tipar_driver);
+
+       devfs_unregister (devfs_handle);
+       devfs_unregister_chrdev(TIPAR_MAJOR, "tipar");  
+
+       for (offset = 0; offset < PP_NO; offset++) {
+               if (table[offset].dev == NULL)
+                       continue;
+               parport_unregister_device(table[offset].dev);
+       }
+}
+
+__setup("tipar=", tipar_setup);
+module_init(tipar_init_module);
+module_exit(tipar_cleanup_module);
+
+MODULE_AUTHOR("Author/Maintainer: Romain Lievin <roms@lpg.ticalc.org>");
+MODULE_DESCRIPTION("Device driver for TI/PC parallel link cables");
+MODULE_LICENSE("GPL");
+
+EXPORT_NO_SYMBOLS;
+
+MODULE_PARM(timeout, "i");
+MODULE_PARM_DESC(timeout, "Timeout, default=1.5 seconds");
+MODULE_PARM(delay, "i");
+MODULE_PARM_DESC(delay, "Inter-bit delay, default=10 microseconds");
--- linux.orig/include/linux/ticable.h  Wed Mar 13 19:42:30 2002
+++ linux/include/linux/ticable.h       Wed Mar 13 21:25:03 2002
@@ -0,0 +1,41 @@
+/* Hey EMACS -*- linux-c -*-
+ *
+ * tipar/tiser/tiglusb - low level driver for handling link cables
+ * designed for Texas Instruments graphing calculators.
+ *
+ * Copyright (C) 2000-2002, Romain Lievin <roms@lpg.ticalc.org>
+ * under the terms of the GNU General Public License.
+ */
+
+#ifndef TICABLE_H 
+#define TICABLE_H 1
+
+/* Internal default constants for the kernel module */
+#define TIMAXTIME 10      /* 1 seconds                         */
+#define IO_DELAY  10      /* 10 micro-seconds  */
+
+/* Major & minor number for character devices */
+#define TIPAR_MAJOR   61
+#define TIPAR_MINOR_0  1
+#define TIPAR_MINOR_1  2
+#define TIPAR_MINOR_2  3
+
+#define TISER_MAJOR   62
+#define TISER_MINOR_0  1
+#define TISER_MINOR_1  2
+#define TISER_MINOR_2  3
+#define TISER_MINOR_3  4
+
+/*
+ * Request values for the 'ioctl' function.
+ * Simply pass the appropriate value as arg of the ioctl call.
+ * These values do not conflict with other ones but they have to be
+ * allocated... (/usr/src/linux/Documentation/ioctl-number.txt).
+ */
+#define TIPAR_DELAY     _IOW('p', 0xa8, int) /* set delay   */
+#define TIPAR_TIMEOUT   _IOW('p', 0xa9, int) /* set timeout */
+
+#define TISER_DELAY     _IOW('p', 0xa0, int) /* set delay   */
+#define TISER_TIMEOUT   _IOW('p', 0xa1, int) /* set timeout */
+
+#endif /* TICABLE_H */


Romain.

---
Romain Liévin (aka roms)
http://lpg.ticalc.org/prj_tilp, prj_usb, prj_tidev, prj_gtktiemu
mail: roms@lpg.ticalc.org

Re: your mail

[Alan Cox]

> It has been tested on x86 for almost 2 years and on Alpha & Sparc too with 
> various calculators.

One oddity - some other comments

> +static int tipar_open(struct inode *inode, struct file *file)
> +{
> +       unsigned int minor = minor(inode->i_rdev) - TIPAR_MINOR_0;
> +
> +       if (minor >= PP_NO)
> +               return -ENXIO;  
> +       
> +       init_ti_parallel(minor);
> +
> +       MOD_INC_USE_COUNT;

You should remove these and use in 2.4 + . Also what stops multiple
simultaneous runs of init_ti_parallel if two people open it at once ?


> +static unsigned int tipar_poll(struct file *file, poll_table * wait)
> +{
> +       unsigned int mask=0;
> +       return mask;
> +}

That seems unfinished ??

> +static int tipar_ioctl(struct inode *inode, struct file *file,
> +                      unsigned int cmd, unsigned long arg)
> +       case O_NONBLOCK:
> +               file->f_flags |= O_NONBLOCK;
> +               return 0;

O_NDELAY is set by fcntl - your driver never needs this.

> +       default:
> +               retval = -EINVAL;

SuS says -ENOTTY here (lots of drivers get this wrong still)

> +static long long tipar_lseek(struct file * file, long long offset, int origin)
> +{
> +       return -ESPIPE;
> +}

There is a generic no_llseek function

> +/* Major & minor number for character devices */
> +#define TIPAR_MAJOR   61

These don't appear to be officially assigned via lanana ?

Re: your mail

[Stephen Smalley]

On 10 Mar 2002, Samarth  Sharma wrote:

> 1.On login i get the following message :
>   [ avc: denied {write} for pid=647 exe=/bin/login
>   path=/var/log/wtmp dev=03:07 ino=182350
>   scontext=system_u:system_r:local_login_t
>   tcontext=system_u:object_r:cron_log_t tclass=file ]
> what does this mean and how can i get around it.
>   i get similar messages while loading 'atd'.

This indicates that your /var/log/wtmp file has the wrong security context
(system_u:object_r:cron_log_t rather than system_u:object_r:wtmp_t).
Run 'make verbose' in your setfiles directory after logging into the
sysadm_r role and sysadm_t domain to ensure that all of your file security
contexts are set properly.  You should have done this originally as step
15 of the README after you first booted SELinux.  You still need to figure
out why this happened to prevent a recurrence.  Some possible
explanations:

1) You have a cron job set up to rotate wtmp (and other log files) using
something other than the SELinux-modified logrotate program.  The
SELinux-modified logrotate program ensures that rotated files retain the
security context of the original file.  If you are rotating wtmp in some
other way, then it will pick up the cron_log_t type by default, as noted
by Russell Coker.  In this case, you need to ensure that you preserve
security contexts on log files when you rotate them.

2) You've switched back-and-forth between running an ordinary Linux kernel
and the SELinux kernel, and the wtmp file was re-created (possibly
rotated) while running the ordinary Linux kernel.  In this case, it is
sufficient to run 'make verbose' in the setfiles directory to ensure that
the file security contexts are set properly.

> 2.Can u give me a specific example where SElinux is able to solve
> a security flaw in normal Linux

I'd suggest reading the FAQ (esp. question #2,
http://www.nsa.gov/selinux/faq.html#l2) and the two published papers
about SELinux from http://www.nsa.gov/selinux/docs.html.
The Inevitability of Failure background paper
(http://www.nsa.gov/selinux/inevit-abs.html) provides a good explanation
of why mandatory access controls are necessary in general.  Two simple
examples are confining malicious mobile code that exploits a flaw in your
web browser and confining an exploit of a flaw in apache, bind, sendmail,
or any other system service.

> 3.i tried loading the selinux kernel on an amd machine.
> however the machine keeps rebooting immediately after the lilo
> screen. Linux 7.1 (redhat) runs fine on this machine.

Make sure that you set up your Processor type and features correctly in
the kernel configuration before building the SELinux kernel.  You could
try using the default RedHat kernel configuration from the RedHat SRPM
with just a few alterations for the SELinux-related options.

> 4.how do u add a user to the system. i added a new user in the
> ../policy/users file with appropriate context and compiled the
> policy but security context for that user was not initialized.

You also need to update the /etc/security/default_context and
/etc/security/cron_context files to define default login and cron job
security contexts for the user.  These files will become obsolete pending
some ongoing work, so at some point, you will only need to update
policy/users.  Also, we've merged support for a generic unprivileged user
that will show up in the next public release, so you will no longer need
to update any of these files if the new user only requires unprivileged
access and does not need to be separated from other such users by the
policy.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[Jan-Marek Glogowski]

Hi

> I'm setting up a new machine with a pair of IDE drives connected to
> HPT 370 controller. I defined a RAID-1 array using the HPT370 bios
> setting utility.
> Description - hard:
> motherboard Abit ST6-RAID, HPT370, 2 identical hard disks as
> primary/secondary master on ide3/ide4
> - bios:
> Primary Master:   Mirror (Raid 1) for Array #0 UDMA 5 78150 BOOT
> Primary Slave:    No drive
> Secondary Master: Mirror (Raid 1) for Array #0 UDMA 5 78150 HIDDEEN
> Secondary Slave:  No drive
> - os:
> Linux RedHat 7.1 & kernel 2.4.17
> with compilation option
> CONFIG_BLK_DEV_ATARAID_HPT=y
> Lilo:
> ...
> root=/dev/hde10

The root should be /dev/ataraid/xxx for any ata raid but that is not the
real problem...

> During system booting i see following
> ...
> ataraid/d0: ataraid/d0p1 ataraid/d0p2 ataraid/d0p3 ataraid/d0p4 <>
> Highpoint HPT370 Softwareraid driver for linux version 0.01
> Drive 0 is 76319 Mb
> Drive 6 is 76319 Mb
> Raid array consists of 2 drivers
> ...
> Kernel panic: VFS: Unable to mount root fs on 21:0a
> ...

Ataraid seems to find four partitions d0p[1234]. But as far as I know
mirroring isn't supported by the in kernel open source drivers at all -
you may look at the closed source drivers at www.highpoint-tech.com, if
you really need the "hpt native" raid.
(http://people.redhat.com/arjanv/pdcraid/ataraidhowto.html)

> Booting with option root=/dev/atarad/d0p1 ro
> (or root=/dev/ataraid/d0p10 ro)
> and etc - no effect

If you just just use need to access the harddisks from linux it is
suggested to use linux software raid (there was a discussion at lkml - if
I remember right). On modern PCs it uses < 5% CPU and is faster, as it
operates high level in the kernel, not right before the hardware, as those
"big software part, small hardware part" raid controller from Promise and
Highpoint do.

HTH

Jan-Marek

Re: your mail

[Stephen Smalley]

On Wed, 27 Feb 2002, Metrix wrote:

> with selinux is it possible to say make a file or
> directory unable to be viewed, deleted or moved, or
> even altered, the ONLY operation allowed is
> appending....is this possible to implement with
> selinux?

You can certainly define a type, only grant append permission to it in
the policy configuration, and label a file with it.

> i am a bit unsure oh what MAC and such is, is there a
> guide somewhere that clearly explains it?

I'd suggest reading the papers available from
http://www.nsa.gov/selinux/docs.html.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[Stephen Smalley]

On Wed, 27 Feb 2002, Metrix wrote:

> Hey people, just wanted to compliment you on the good
> job, I will actualy be using RSBAC as it suits my
> needs a bit better...
>
> My question is, what are the diferences of RSBAC
> [rsbac.org] and SELinux from a technical standpoint?

This has been previously discussed on the mailing list, and is also
summarized in the related work section of the Freenix '01 paper.  The
mailing list thread starts at
http://marc.theaimsgroup.com/?l=selinux&m=98618795624462&w=2 and the
Freenix '01 paper is available at
http://www.nsa.gov/selinux/freenix01-abs.html.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[Rusty Russell]

In message <Pine.GSO.4.21.0202242230370.1549-100000@weyl.math.psu.edu> you write:
> Honour or not, in this case your complaint is hardly deserved.  To
> compress the above a bit:
> 
> you: <false statement>
> me: RTFS.  <short description of the reasons why statement is wrong; further
> details could be obtained by reading TFS>

Al, *please* read.

Rusty said:
> First, fd passing sucks: you can't leave an fd somewhere and wait for
> someone to pick it up, and they vanish when you exit.  Secondly, you
> have some arbitrary limit on the number of semaphores.  Thirdly,
> someone has to own them.

These are all true: I was criticising the "fd == semaphore" approach,
in the context of my "tied to mapped location" approach, and Linus's
"magic cookie" approach.

I went on to explain furthur:

> Consider tdb, the Trivial Database.  There is no "master locking
> daemon".  There is no way for the first opener (who then has to create
> the semaphores in your model) to pass them to other openers: this is a
> library.

You also managed to ignore my previous comment on the "fd ==
semaphore" approach:

> Implemented exactly that (and posted to l-k IIRC), and it's
> *horrible* to use.

And you came out assuming I had no idea how fd passing works:

> Yes, you can.  Please, RTFS

...and then in the next mail you suggested I implement a "master
locking daemon".

I have taken the liberty of rewriting your reply as I might expect to
see from a peer:

================
From: Al Viro's Polite Twin
To: Rusty Russell
Subject: Re: [PATCH] Lightweight userspace semaphores... 
Date: Two days after hell freezes over

On Mon, 25 Feb 2002, Rusty Russell wrote:
> First, fd passing sucks: you can't leave an fd somewhere and wait for
> someone to pick it up, and they vanish when you exit.  Secondly, you

Have you considered using a daemon to hold the fds?  It shouldn't be
that bad.

================

See how it doesn't assume that I am an idiot?  It's not condescending,
and invites furthur consideration.  It's also shorter than your other
two replies.

I might have replied as follows:

		Yes, and for a "serious" database it's not a problem, as
	it usually has some kind of daemon anyway.  But for TDB, I
	found that it's fragile and extremely unwieldy.  Creating a
	unix domain socket for each .tdb file may not be possible.
	The tdb_open call would have to fork off a daemon if it's the
	first process to access it.  It starts to get fairly icky:
	certainly when compared with the fairly trivial patch to
	support the "semaphore tied to mapped region" approach.

		You can try if you want (TDB enclosed).

Maybe I'm the only one who finds it *really* painful to continually
deal with your "Dan Bernstein of Linux" approach: enough that it
hinders my kernel work.

Genuinely hope this helps,
Rusty.
--
  Taste: it's not just for source code anymore...

#ifndef __TDB_H__
#define __TDB_H__
/* 
   Unix SMB/Netbios implementation.
   Version 3.0
   Samba database functions
   Copyright (C) Andrew Tridgell 1999
   
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.
   
   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.
*/
#ifdef  __cplusplus
extern "C" {
#endif

/* flags to tdb_store() */
#define TDB_REPLACE 1
#define TDB_INSERT 2
#define TDB_MODIFY 3

/* flags for tdb_open() */
#define TDB_DEFAULT 0 /* just a readability place holder */
#define TDB_CLEAR_IF_FIRST 1
#define TDB_INTERNAL 2 /* don't store on disk */
#define TDB_NOLOCK   4 /* don't do any locking */
#define TDB_NOMMAP   8 /* don't use mmap */
#define TDB_CONVERT 16 /* convert endian (internal use) */

#define TDB_ERRCODE(code, ret) ((tdb->ecode = (code)), ret)

/* error codes */
enum TDB_ERROR {TDB_SUCCESS=0, TDB_ERR_CORRUPT, TDB_ERR_IO, TDB_ERR_LOCK, 
		TDB_ERR_OOM, TDB_ERR_EXISTS, TDB_ERR_NOEXIST, TDB_ERR_NOLOCK };

#ifndef u32
#define u32 unsigned
#endif

typedef struct {
	char *dptr;
	size_t dsize;
} TDB_DATA;

typedef u32 tdb_len;
typedef u32 tdb_off;

/* this is stored at the front of every database */
struct tdb_header {
	char magic_food[32]; /* for /etc/magic */
	u32 version; /* version of the code */
	u32 hash_size; /* number of hash entries */
	tdb_off rwlocks;
	tdb_off reserved[31];
};

struct tdb_lock_type {
	u32 count;
	u32 ltype;
};

struct tdb_traverse_lock {
	struct tdb_traverse_lock *next;
	u32 off;
	u32 hash;
};

/* this is the context structure that is returned from a db open */
typedef struct tdb_context {
	char *name; /* the name of the database */
	void *map_ptr; /* where it is currently mapped */
	int fd; /* open file descriptor for the database */
	tdb_len map_size; /* how much space has been mapped */
	int read_only; /* opened read-only */
	struct tdb_lock_type *locked; /* array of chain locks */
	enum TDB_ERROR ecode; /* error code for last tdb error */
	struct tdb_header header; /* a cached copy of the header */
	u32 flags; /* the flags passed to tdb_open */
	u32 *lockedkeys; /* array of locked keys: first is #keys */
	struct tdb_traverse_lock travlocks; /* current traversal locks */
	struct tdb_context *next; /* all tdbs to avoid multiple opens */
	dev_t device;	/* uniquely identifies this tdb */
	ino_t inode;	/* uniquely identifies this tdb */
} TDB_CONTEXT;

typedef int (*tdb_traverse_func)(TDB_CONTEXT *, TDB_DATA, TDB_DATA, void *);
typedef void (*tdb_log_func)(TDB_CONTEXT *, int , const char *, ...);

TDB_CONTEXT *tdb_open(char *name, int hash_size, int tdb_flags,
		      int open_flags, mode_t mode);

enum TDB_ERROR tdb_error(TDB_CONTEXT *tdb);
const char *tdb_errorstr(TDB_CONTEXT *tdb);
TDB_DATA tdb_fetch(TDB_CONTEXT *tdb, TDB_DATA key);
int tdb_delete(TDB_CONTEXT *tdb, TDB_DATA key);
int tdb_store(TDB_CONTEXT *tdb, TDB_DATA key, TDB_DATA dbuf, int flag);
int tdb_close(TDB_CONTEXT *tdb);
TDB_DATA tdb_firstkey(TDB_CONTEXT *tdb);
TDB_DATA tdb_nextkey(TDB_CONTEXT *tdb, TDB_DATA key);
int tdb_traverse(TDB_CONTEXT *tdb, tdb_traverse_func fn, void *state);
int tdb_exists(TDB_CONTEXT *tdb, TDB_DATA key);
int tdb_lockkeys(TDB_CONTEXT *tdb, u32 number, TDB_DATA keys[]);
void tdb_unlockkeys(TDB_CONTEXT *tdb);
int tdb_lockall(TDB_CONTEXT *tdb);
void tdb_unlockall(TDB_CONTEXT *tdb);

/* Low level locking functions: use with care */
int tdb_chainlock(TDB_CONTEXT *tdb, TDB_DATA key);
void tdb_chainunlock(TDB_CONTEXT *tdb, TDB_DATA key);

/* Debug functions. Not used in production. */
void tdb_dump_all(TDB_CONTEXT *tdb);
void tdb_printfreelist(TDB_CONTEXT *tdb);

extern TDB_DATA tdb_null;
#ifdef  __cplusplus
}
#endif

#endif /* tdb.h */

 /* 
   Unix SMB/Netbios implementation.
   Version 3.0
   Samba database functions
   Copyright (C) Andrew Tridgell              1999-2000
   Copyright (C) Luke Kenneth Casson Leighton      2000
   Copyright (C) Paul `Rusty' Russell		   2000
   Copyright (C) Jeremy Allison			   2000
   
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.
   
   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 <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include "tdb.h"

#define TDB_MAGIC_FOOD "TDB file\n"
#define TDB_VERSION (0x26011967 + 6)
#define TDB_MAGIC (0x26011999U)
#define TDB_FREE_MAGIC (~TDB_MAGIC)
#define TDB_DEAD_MAGIC (0xFEE1DEAD)
#define TDB_ALIGNMENT 4
#define MIN_REC_SIZE (2*sizeof(struct list_struct) + TDB_ALIGNMENT)
#define DEFAULT_HASH_SIZE 131
#define TDB_PAGE_SIZE 0x2000
#define FREELIST_TOP (sizeof(struct tdb_header))
#define TDB_ALIGN(x,a) (((x) + (a)-1) & ~((a)-1))
#define TDB_BYTEREV(x) (((((x)&0xff)<<24)|((x)&0xFF00)<<8)|(((x)>>8)&0xFF00)|((x)>>24))
#define TDB_DEAD(r) ((r)->magic == TDB_DEAD_MAGIC)
#define TDB_BAD_MAGIC(r) ((r)->magic != TDB_MAGIC && !TDB_DEAD(r))
#define TDB_HASH_TOP(hash) (FREELIST_TOP + (BUCKET(hash)+1)*sizeof(tdb_off))

/* lock offsets */
#define GLOBAL_LOCK 0
#define ACTIVE_LOCK 4

#ifndef MAP_FILE
#define MAP_FILE 0
#endif

#ifndef MAP_FAILED
#define MAP_FAILED ((void *)-1)
#endif

#define BUCKET(hash) ((hash) % tdb->header.hash_size)
TDB_DATA tdb_null;

/* all contexts, to ensure no double-opens (fcntl locks don't nest!) */
static TDB_CONTEXT *tdbs = NULL;

static void tdb_munmap(TDB_CONTEXT *tdb)
{
	if (tdb->flags & TDB_INTERNAL)
		return;

	if (tdb->map_ptr)
		munmap(tdb->map_ptr, tdb->map_size);
	tdb->map_ptr = NULL;
}

static void tdb_mmap(TDB_CONTEXT *tdb)
{
	if (tdb->flags & TDB_INTERNAL)
		return;

	if (!(tdb->flags & TDB_NOMMAP)) {
		tdb->map_ptr = mmap(NULL, tdb->map_size, 
				    PROT_READ|(tdb->read_only? 0:PROT_WRITE), 
				    MAP_SHARED|MAP_FILE, tdb->fd, 0);

		/*
		 * NB. When mmap fails it returns MAP_FAILED *NOT* NULL !!!!
		 */

		if (tdb->map_ptr == MAP_FAILED)
			tdb->map_ptr = NULL;
	} else {
		tdb->map_ptr = NULL;
	}
}

/* Endian conversion: we only ever deal with 4 byte quantities */
static void *convert(void *buf, u32 size)
{
	u32 i, *p = buf;
	for (i = 0; i < size / 4; i++)
		p[i] = TDB_BYTEREV(p[i]);
	return buf;
}
#define DOCONV() (tdb->flags & TDB_CONVERT)
#define CONVERT(x) (DOCONV() ? convert(&x, sizeof(x)) : &x)

/* the body of the database is made of one list_struct for the free space
   plus a separate data list for each hash value */
struct list_struct {
	tdb_off next; /* offset of the next record in the list */
	tdb_len rec_len; /* total byte length of record */
	tdb_len key_len; /* byte length of key */
	tdb_len data_len; /* byte length of data */
	u32 full_hash; /* the full 32 bit hash of the key */
	u32 magic;   /* try to catch errors */
	/* the following union is implied:
		union {
			char record[rec_len];
			struct {
				char key[key_len];
				char data[data_len];
			}
			u32 totalsize; (tailer)
		}
	*/
};

/* a byte range locking function - return 0 on success
   this functions locks/unlocks 1 byte at the specified offset.

   On error, errno is also set so that errors are passed back properly
   through tdb_open(). */
static int tdb_brlock(TDB_CONTEXT *tdb, tdb_off offset, 
		      int rw_type, int lck_type)
{
	struct flock fl;

	if (tdb->flags & TDB_NOLOCK)
		return 0;
	if (tdb->read_only) {
		errno = EACCES;
		return -1;
	}

	fl.l_type = rw_type;
	fl.l_whence = SEEK_SET;
	fl.l_start = offset;
	fl.l_len = 1;
	fl.l_pid = 0;

	if (fcntl(tdb->fd,lck_type,&fl)) {
		/* errno set by fcntl */
		return TDB_ERRCODE(TDB_ERR_LOCK, -1);
	}
	return 0;
}

/* lock a list in the database. list -1 is the alloc list */
static int tdb_lock(TDB_CONTEXT *tdb, int list, int ltype)
{
	if (list < -1 || list >= (int)tdb->header.hash_size) {
		return -1;
	}
	if (tdb->flags & TDB_NOLOCK)
		return 0;

	/* Since fcntl locks don't nest, we do a lock for the first one,
	   and simply bump the count for future ones */
	if (tdb->locked[list+1].count == 0) {
		if (tdb_brlock(tdb,FREELIST_TOP+4*list,ltype,F_SETLKW)) {
			return -1;
		}
		tdb->locked[list+1].ltype = ltype;
	}
	tdb->locked[list+1].count++;
	return 0;
}

/* unlock the database: returns void because it's too late for errors. */
static void tdb_unlock(TDB_CONTEXT *tdb, int list, int ltype)
{
	if (tdb->flags & TDB_NOLOCK)
		return;

	/* Sanity checks */
	if (list < -1 || list >= (int)tdb->header.hash_size)
		return;
	if (tdb->locked[list+1].count==0)
		return;

	if (tdb->locked[list+1].count == 1) {
		/* Down to last nested lock: unlock underneath */
		tdb_brlock(tdb, FREELIST_TOP+4*list, F_UNLCK, F_SETLKW);
	}
	tdb->locked[list+1].count--;
}

/* This is based on the hash agorithm from gdbm */
static u32 tdb_hash(TDB_DATA *key)
{
	u32 value;	/* Used to compute the hash value.  */
	u32   i;	/* Used to cycle through random values. */

	/* Set the initial value from the key size. */
	for (value = 0x238F13AF * key->dsize, i=0; i < key->dsize; i++)
		value = (value + (key->dptr[i] << (i*5 % 24)));

	return (1103515243 * value + 12345);  
}

/* check for an out of bounds access - if it is out of bounds then
   see if the database has been expanded by someone else and expand
   if necessary 
   note that "len" is the minimum length needed for the db
*/
static int tdb_oob(TDB_CONTEXT *tdb, tdb_off len)
{
	struct stat st;
	if (len <= tdb->map_size)
		return 0;
	if (tdb->flags & TDB_INTERNAL) {
		return TDB_ERRCODE(TDB_ERR_IO, -1);
	}

	if (fstat(tdb->fd, &st) == -1)
		return TDB_ERRCODE(TDB_ERR_IO, -1);

	if (st.st_size < (size_t)len) {
		return TDB_ERRCODE(TDB_ERR_IO, -1);
	}

	/* Unmap, update size, remap */
	tdb_munmap(tdb);
	tdb->map_size = st.st_size;
	tdb_mmap(tdb);
	return 0;
}

/* write a lump of data at a specified offset */
static int tdb_write(TDB_CONTEXT *tdb, tdb_off off, void *buf, tdb_len len)
{
	if (tdb_oob(tdb, off + len) != 0)
		return -1;

	if (tdb->map_ptr)
		memcpy(off + (char *)tdb->map_ptr, buf, len);
	else if (lseek(tdb->fd, off, SEEK_SET) != off
		 || write(tdb->fd, buf, len) != (ssize_t)len) {
		return TDB_ERRCODE(TDB_ERR_IO, -1);
	}
	return 0;
}

/* read a lump of data at a specified offset, maybe convert */
static int tdb_read(TDB_CONTEXT *tdb,tdb_off off,void *buf,tdb_len len,int cv)
{
	if (tdb_oob(tdb, off + len) != 0)
		return -1;

	if (tdb->map_ptr)
		memcpy(buf, off + (char *)tdb->map_ptr, len);
	else if (lseek(tdb->fd, off, SEEK_SET) != off
		 || read(tdb->fd, buf, len) != (ssize_t)len) {
		return TDB_ERRCODE(TDB_ERR_IO, -1);
	}
	if (cv)
		convert(buf, len);
	return 0;
}

/* read a lump of data, allocating the space for it */
static char *tdb_alloc_read(TDB_CONTEXT *tdb, tdb_off offset, tdb_len len)
{
	char *buf;

	if (!(buf = malloc(len))) {
		return TDB_ERRCODE(TDB_ERR_OOM, buf);
	}
	if (tdb_read(tdb, offset, buf, len, 0) == -1) {
		free(buf);
		return NULL;
	}
	return buf;
}

/* read/write a tdb_off */
static int ofs_read(TDB_CONTEXT *tdb, tdb_off offset, tdb_off *d)
{
	return tdb_read(tdb, offset, (char*)d, sizeof(*d), DOCONV());
}
static int ofs_write(TDB_CONTEXT *tdb, tdb_off offset, tdb_off *d)
{
	tdb_off off = *d;
	return tdb_write(tdb, offset, CONVERT(off), sizeof(*d));
}

/* read/write a record */
static int rec_read(TDB_CONTEXT *tdb, tdb_off offset, struct list_struct *rec)
{
	if (tdb_read(tdb, offset, rec, sizeof(*rec),DOCONV()) == -1)
		return -1;
	if (TDB_BAD_MAGIC(rec)) {
		return TDB_ERRCODE(TDB_ERR_CORRUPT, -1);
	}
	return tdb_oob(tdb, rec->next+sizeof(*rec));
}
static int rec_write(TDB_CONTEXT *tdb, tdb_off offset, struct list_struct *rec)
{
	struct list_struct r = *rec;
	return tdb_write(tdb, offset, CONVERT(r), sizeof(r));
}

/* read a freelist record and check for simple errors */
static int rec_free_read(TDB_CONTEXT *tdb, tdb_off off, struct list_struct *rec)
{
	if (tdb_read(tdb, off, rec, sizeof(*rec),DOCONV()) == -1)
		return -1;
	if (rec->magic != TDB_FREE_MAGIC) {
		return TDB_ERRCODE(TDB_ERR_CORRUPT, -1);
	}
	if (tdb_oob(tdb, rec->next+sizeof(*rec)) != 0)
		return -1;
	return 0;
}

/* update a record tailer (must hold allocation lock) */
static int update_tailer(TDB_CONTEXT *tdb, tdb_off offset,
			 const struct list_struct *rec)
{
	tdb_off totalsize;

	/* Offset of tailer from record header */
	totalsize = sizeof(*rec) + rec->rec_len;
	return ofs_write(tdb, offset + totalsize - sizeof(tdb_off),
			 &totalsize);
}

static tdb_off tdb_dump_record(TDB_CONTEXT *tdb, tdb_off offset)
{
	struct list_struct rec;
	tdb_off tailer_ofs, tailer;

	if (tdb_read(tdb, offset, (char *)&rec, sizeof(rec), DOCONV()) == -1) {
		printf("ERROR: failed to read record at %u\n", offset);
		return 0;
	}

	printf(" rec: offset=%u next=%d rec_len=%d key_len=%d data_len=%d full_hash=0x%x magic=0x%x\n",
	       offset, rec.next, rec.rec_len, rec.key_len, rec.data_len, rec.full_hash, rec.magic);

	tailer_ofs = offset + sizeof(rec) + rec.rec_len - sizeof(tdb_off);
	if (ofs_read(tdb, tailer_ofs, &tailer) == -1) {
		printf("ERROR: failed to read tailer at %u\n", tailer_ofs);
		return rec.next;
	}

	if (tailer != rec.rec_len + sizeof(rec)) {
		printf("ERROR: tailer does not match record! tailer=%u totalsize=%u\n", tailer, rec.rec_len + sizeof(rec));
	}
	return rec.next;
}

static void tdb_dump_chain(TDB_CONTEXT *tdb, int i)
{
	tdb_off rec_ptr, top;

	top = TDB_HASH_TOP(i);

	tdb_lock(tdb, i, F_WRLCK);

	if (ofs_read(tdb, top, &rec_ptr) == -1) {
		tdb_unlock(tdb, i, F_WRLCK);
		return;
	}

	if (rec_ptr)
		printf("hash=%d\n", i);

	while (rec_ptr) {
		rec_ptr = tdb_dump_record(tdb, rec_ptr);
	}
	tdb_unlock(tdb, i, F_WRLCK);
}

void tdb_dump_all(TDB_CONTEXT *tdb)
{
	int i;
	for (i=0;i<tdb->header.hash_size;i++) {
		tdb_dump_chain(tdb, i);
	}
	printf("freelist:\n");
	tdb_dump_chain(tdb, -1);
}

void tdb_printfreelist(TDB_CONTEXT *tdb)
{
	long total_free = 0;
	tdb_off offset, rec_ptr, last_ptr;
	struct list_struct rec;

	tdb_lock(tdb, -1, F_WRLCK);

	last_ptr = 0;
	offset = FREELIST_TOP;

	/* read in the freelist top */
	if (ofs_read(tdb, offset, &rec_ptr) == -1) {
		return;
	}

	printf("freelist top=[0x%08x]\n", rec_ptr );
	while (rec_ptr) {
		if (tdb_read(tdb, rec_ptr, (char *)&rec, sizeof(rec), DOCONV()) == -1) {
			return;
		}

		if (rec.magic != TDB_FREE_MAGIC) {
			printf("bad magic 0x%08x in free list\n", rec.magic);
			return;
		}

		printf("entry offset=[0x%08x], rec.rec_len = [0x%08x (%d)]\n", rec.next, rec.rec_len, rec.rec_len );
		total_free += rec.rec_len;

		/* move to the next record */
		rec_ptr = rec.next;
	}
	printf("total rec_len = [0x%08x (%d)]\n", (int)total_free, 
               (int)total_free);

	tdb_unlock(tdb, -1, F_WRLCK);
}

/* Remove an element from the freelist.  Must have alloc lock. */
static int remove_from_freelist(TDB_CONTEXT *tdb, tdb_off off, tdb_off next)
{
	tdb_off last_ptr, i;

	/* read in the freelist top */
	last_ptr = FREELIST_TOP;
	while (ofs_read(tdb, last_ptr, &i) != -1 && i != 0) {
		if (i == off) {
			/* We've found it! */
			return ofs_write(tdb, last_ptr, &next);
		}
		/* Follow chain (next offset is at start of record) */
		last_ptr = i;
	}
	return TDB_ERRCODE(TDB_ERR_CORRUPT, -1);
}

/* Add an element into the freelist. Merge adjacent records if
   neccessary. */
static int tdb_free(TDB_CONTEXT *tdb, tdb_off offset, struct list_struct *rec)
{
	tdb_off right, left;

	/* Allocation and tailer lock */
	if (tdb_lock(tdb, -1, F_WRLCK) != 0)
		return -1;

	/* set an initial tailer, so if we fail we don't leave a bogus record */
	update_tailer(tdb, offset, rec);

	/* Look right first (I'm an Australian, dammit) */
	right = offset + sizeof(*rec) + rec->rec_len;
	if (right + sizeof(*rec) <= tdb->map_size) {
		struct list_struct r;

		if (tdb_read(tdb, right, &r, sizeof(r), DOCONV()) == -1) {
			goto left;
		}

		/* If it's free, expand to include it. */
		if (r.magic == TDB_FREE_MAGIC) {
			if (remove_from_freelist(tdb, right, r.next) == -1) {
				goto left;
			}
			rec->rec_len += sizeof(r) + r.rec_len;
		}
	}

left:
	/* Look left */
	left = offset - sizeof(tdb_off);
	if (left > TDB_HASH_TOP(tdb->header.hash_size-1)) {
		struct list_struct l;
		tdb_off leftsize;

		/* Read in tailer and jump back to header */
		if (ofs_read(tdb, left, &leftsize) == -1) {
			goto update;
		}
		left = offset - leftsize;

		/* Now read in record */
		if (tdb_read(tdb, left, &l, sizeof(l), DOCONV()) == -1) {
			goto update;
		}

		/* If it's free, expand to include it. */
		if (l.magic == TDB_FREE_MAGIC) {
			if (remove_from_freelist(tdb, left, l.next) == -1) {
				goto update;
			} else {
				offset = left;
				rec->rec_len += leftsize;
			}
		}
	}

update:
	if (update_tailer(tdb, offset, rec) == -1) {
		goto fail;
	}

	/* Now, prepend to free list */
	rec->magic = TDB_FREE_MAGIC;

	if (ofs_read(tdb, FREELIST_TOP, &rec->next) == -1 ||
	    rec_write(tdb, offset, rec) == -1 ||
	    ofs_write(tdb, FREELIST_TOP, &offset) == -1) {
		goto fail;
	}

	/* And we're done. */
	tdb_unlock(tdb, -1, F_WRLCK);
	return 0;

 fail:
	tdb_unlock(tdb, -1, F_WRLCK);
	return -1;
}


/* expand a file.  we prefer to use ftruncate, as that is what posix
  says to use for mmap expansion */
static int expand_file(TDB_CONTEXT *tdb, tdb_off size, tdb_off addition)
{
	char buf[1024];

	if (ftruncate(tdb->fd, size+addition) != 0) {
		return -1;
	}

	/* now fill the file with something. This ensures that the file isn't sparse, which would be
	   very bad if we ran out of disk. This must be done with write, not via mmap */
	memset(buf, 0x42, sizeof(buf));
	while (addition) {
		int n = addition>sizeof(buf)?sizeof(buf):addition;
		int ret;
		if (lseek(tdb->fd, size, SEEK_SET) != size)
			return -1;
		ret = write(tdb->fd, buf, n);
		if (ret != n) {
			return -1;
		}
		addition -= n;
		size += n;
	}
	return 0;
}


/* expand the database at least size bytes by expanding the underlying
   file and doing the mmap again if necessary */
static int tdb_expand(TDB_CONTEXT *tdb, tdb_off size)
{
	struct list_struct rec;
	tdb_off offset;

	if (tdb_lock(tdb, -1, F_WRLCK) == -1) {
		return -1;
	}

	/* must know about any previous expansions by another process */
	tdb_oob(tdb, tdb->map_size + 1);

	/* always make room for at least 10 more records, and round
           the database up to a multiple of TDB_PAGE_SIZE */
	size = TDB_ALIGN(tdb->map_size + size*10, TDB_PAGE_SIZE) - tdb->map_size;

	if (!(tdb->flags & TDB_INTERNAL))
		tdb_munmap(tdb);

	/*
	 * We must ensure the file is unmapped before doing this
	 * to ensure consistency with systems like OpenBSD where
	 * writes and mmaps are not consistent.
	 */

	/* expand the file itself */
	if (!(tdb->flags & TDB_INTERNAL)) {
		if (expand_file(tdb, tdb->map_size, size) != 0)
			goto fail;
	}

	tdb->map_size += size;

	if (tdb->flags & TDB_INTERNAL)
		tdb->map_ptr = realloc(tdb->map_ptr, tdb->map_size);
	else {
		/*
		 * We must ensure the file is remapped before adding the space
		 * to ensure consistency with systems like OpenBSD where
		 * writes and mmaps are not consistent.
		 */

		/* We're ok if the mmap fails as we'll fallback to read/write */
		tdb_mmap(tdb);
	}

	/* form a new freelist record */
	memset(&rec,'\0',sizeof(rec));
	rec.rec_len = size - sizeof(rec);

	/* link it into the free list */
	offset = tdb->map_size - size;
	if (tdb_free(tdb, offset, &rec) == -1)
		goto fail;

	tdb_unlock(tdb, -1, F_WRLCK);
	return 0;
 fail:
	tdb_unlock(tdb, -1, F_WRLCK);
	return -1;
}

/* allocate some space from the free list. The offset returned points
   to a unconnected list_struct within the database with room for at
   least length bytes of total data

   0 is returned if the space could not be allocated
 */
static tdb_off tdb_allocate(TDB_CONTEXT *tdb, tdb_len length,
			    struct list_struct *rec)
{
	tdb_off rec_ptr, last_ptr, newrec_ptr;
	struct list_struct newrec;

	if (tdb_lock(tdb, -1, F_WRLCK) == -1)
		return 0;

	/* Extra bytes required for tailer */
	length += sizeof(tdb_off);

 again:
	last_ptr = FREELIST_TOP;

	/* read in the freelist top */
	if (ofs_read(tdb, FREELIST_TOP, &rec_ptr) == -1)
		goto fail;

	/* keep looking until we find a freelist record big enough */
	while (rec_ptr) {
		if (rec_free_read(tdb, rec_ptr, rec) == -1)
			goto fail;

		if (rec->rec_len >= length) {
			/* found it - now possibly split it up  */
			if (rec->rec_len > length + MIN_REC_SIZE) {
				/* Length of left piece */
				length = TDB_ALIGN(length, TDB_ALIGNMENT);

				/* Right piece to go on free list */
				newrec.rec_len = rec->rec_len
					- (sizeof(*rec) + length);
				newrec_ptr = rec_ptr + sizeof(*rec) + length;

				/* And left record is shortened */
				rec->rec_len = length;
			} else
				newrec_ptr = 0;

			/* Remove allocated record from the free list */
			if (ofs_write(tdb, last_ptr, &rec->next) == -1)
				goto fail;

			/* Update header: do this before we drop alloc
                           lock, otherwise tdb_free() might try to
                           merge with us, thinking we're free.
                           (Thanks Jeremy Allison). */
			rec->magic = TDB_MAGIC;
			if (rec_write(tdb, rec_ptr, rec) == -1)
				goto fail;

			/* Did we create new block? */
			if (newrec_ptr) {
				/* Update allocated record tailer (we
                                   shortened it). */
				if (update_tailer(tdb, rec_ptr, rec) == -1)
					goto fail;

				/* Free new record */
				if (tdb_free(tdb, newrec_ptr, &newrec) == -1)
					goto fail;
			}

			/* all done - return the new record offset */
			tdb_unlock(tdb, -1, F_WRLCK);
			return rec_ptr;
		}
		/* move to the next record */
		last_ptr = rec_ptr;
		rec_ptr = rec->next;
	}
	/* we didn't find enough space. See if we can expand the
	   database and if we can then try again */
	if (tdb_expand(tdb, length + sizeof(*rec)) == 0)
		goto again;
 fail:
	tdb_unlock(tdb, -1, F_WRLCK);
	return 0;
}

/* initialise a new database with a specified hash size */
static int tdb_new_database(TDB_CONTEXT *tdb, int hash_size)
{
	struct tdb_header *newdb;
	int size, ret = -1;

	/* We make it up in memory, then write it out if not internal */
	size = sizeof(struct tdb_header) + (hash_size+1)*sizeof(tdb_off);
	if (!(newdb = calloc(size, 1)))
		return TDB_ERRCODE(TDB_ERR_OOM, -1);

	/* Fill in the header */
	newdb->version = TDB_VERSION;
	newdb->hash_size = hash_size;
	if (tdb->flags & TDB_INTERNAL) {
		tdb->map_size = size;
		tdb->map_ptr = (char *)newdb;
		memcpy(&tdb->header, newdb, sizeof(tdb->header));
		/* Convert the `ondisk' version if asked. */
		CONVERT(*newdb);
		return 0;
	}
	if (lseek(tdb->fd, 0, SEEK_SET) == -1)
		goto fail;

	if (ftruncate(tdb->fd, 0) == -1)
		goto fail;

	/* This creates an endian-converted header, as if read from disk */
	CONVERT(*newdb);
	memcpy(&tdb->header, newdb, sizeof(tdb->header));
	/* Don't endian-convert the magic food! */
	memcpy(newdb->magic_food, TDB_MAGIC_FOOD, strlen(TDB_MAGIC_FOOD)+1);
	if (write(tdb->fd, newdb, size) != size)
		ret = -1;
	else
		ret = 0;

  fail:
	free(newdb);
	return ret;
}

/* Returns 0 on fail.  On success, return offset of record, and fills
   in rec */
static tdb_off tdb_find(TDB_CONTEXT *tdb, TDB_DATA key, u32 hash,
			struct list_struct *r)
{
	tdb_off rec_ptr;
	
	/* read in the hash top */
	if (ofs_read(tdb, TDB_HASH_TOP(hash), &rec_ptr) == -1)
		return 0;

	/* keep looking until we find the right record */
	while (rec_ptr) {
		if (rec_read(tdb, rec_ptr, r) == -1)
			return 0;

		if (!TDB_DEAD(r) && hash==r->full_hash && key.dsize==r->key_len) {
			char *k;
			/* a very likely hit - read the key */
			k = tdb_alloc_read(tdb, rec_ptr + sizeof(*r), 
					   r->key_len);
			if (!k)
				return 0;

			if (memcmp(key.dptr, k, key.dsize) == 0) {
				free(k);
				return rec_ptr;
			}
			free(k);
		}
		rec_ptr = r->next;
	}
	return TDB_ERRCODE(TDB_ERR_NOEXIST, 0);
}

/* If they do lockkeys, check that this hash is one they locked */
static int tdb_keylocked(TDB_CONTEXT *tdb, u32 hash)
{
	u32 i;
	if (!tdb->lockedkeys)
		return 1;
	for (i = 0; i < tdb->lockedkeys[0]; i++)
		if (tdb->lockedkeys[i+1] == hash)
			return 1;
	return TDB_ERRCODE(TDB_ERR_NOLOCK, 0);
}

/* As tdb_find, but if you succeed, keep the lock */
static tdb_off tdb_find_lock(TDB_CONTEXT *tdb, TDB_DATA key, int locktype,
			     struct list_struct *rec)
{
	u32 hash, rec_ptr;

	hash = tdb_hash(&key);
	if (!tdb_keylocked(tdb, hash))
		return 0;
	if (tdb_lock(tdb, BUCKET(hash), locktype) == -1)
		return 0;
	if (!(rec_ptr = tdb_find(tdb, key, hash, rec)))
		tdb_unlock(tdb, BUCKET(hash), locktype);
	return rec_ptr;
}

enum TDB_ERROR tdb_error(TDB_CONTEXT *tdb)
{
	return tdb->ecode;
}

static struct tdb_errname {
	enum TDB_ERROR ecode; const char *estring;
} emap[] = { {TDB_SUCCESS, "Success"},
	     {TDB_ERR_CORRUPT, "Corrupt database"},
	     {TDB_ERR_IO, "IO Error"},
	     {TDB_ERR_LOCK, "Locking error"},
	     {TDB_ERR_OOM, "Out of memory"},
	     {TDB_ERR_EXISTS, "Record exists"},
	     {TDB_ERR_NOLOCK, "Lock exists on other keys"},
	     {TDB_ERR_NOEXIST, "Record does not exist"} };

/* Error string for the last tdb error */
const char *tdb_errorstr(TDB_CONTEXT *tdb)
{
	u32 i;
	for (i = 0; i < sizeof(emap) / sizeof(struct tdb_errname); i++)
		if (tdb->ecode == emap[i].ecode)
			return emap[i].estring;
	return "Invalid error code";
}

/* update an entry in place - this only works if the new data size
   is <= the old data size and the key exists.
   on failure return -1
*/
static int tdb_update(TDB_CONTEXT *tdb, TDB_DATA key, TDB_DATA dbuf)
{
	struct list_struct rec;
	tdb_off rec_ptr;
	int ret = -1;

	/* find entry */
	if (!(rec_ptr = tdb_find_lock(tdb, key, F_WRLCK, &rec)))
		return -1;

	/* must be long enough key, data and tailer */
	if (rec.rec_len < key.dsize + dbuf.dsize + sizeof(tdb_off)) {
		tdb->ecode = TDB_SUCCESS; /* Not really an error */
		goto out;
	}

	if (tdb_write(tdb, rec_ptr + sizeof(rec) + rec.key_len,
		      dbuf.dptr, dbuf.dsize) == -1)
		goto out;

	if (dbuf.dsize != rec.data_len) {
		/* update size */
		rec.data_len = dbuf.dsize;
		ret = rec_write(tdb, rec_ptr, &rec);
	} else
		ret = 0;
 out:
	tdb_unlock(tdb, BUCKET(rec.full_hash), F_WRLCK);
	return ret;
}

/* find an entry in the database given a key */
TDB_DATA tdb_fetch(TDB_CONTEXT *tdb, TDB_DATA key)
{
	tdb_off rec_ptr;
	struct list_struct rec;
	TDB_DATA ret;

	/* find which hash bucket it is in */
	if (!(rec_ptr = tdb_find_lock(tdb,key,F_RDLCK,&rec)))
		return tdb_null;

	ret.dptr = tdb_alloc_read(tdb, rec_ptr + sizeof(rec) + rec.key_len,
				  rec.data_len);
	ret.dsize = rec.data_len;
	tdb_unlock(tdb, BUCKET(rec.full_hash), F_RDLCK);
	return ret;
}

/* check if an entry in the database exists 

   note that 1 is returned if the key is found and 0 is returned if not found
   this doesn't match the conventions in the rest of this module, but is
   compatible with gdbm
*/
int tdb_exists(TDB_CONTEXT *tdb, TDB_DATA key)
{
	struct list_struct rec;
	
	if (tdb_find_lock(tdb, key, F_RDLCK, &rec) == 0)
		return 0;
	tdb_unlock(tdb, BUCKET(rec.full_hash), F_RDLCK);
	return 1;
}

/* record lock stops delete underneath */
static int lock_record(TDB_CONTEXT *tdb, tdb_off off)
{
	return off ? tdb_brlock(tdb, off, F_RDLCK, F_SETLKW) : 0;
}
/*
  Write locks override our own fcntl readlocks, so check it here.
  Note this is meant to be F_SETLK, *not* F_SETLKW, as it's not
  an error to fail to get the lock here.
*/
 
static int write_lock_record(TDB_CONTEXT *tdb, tdb_off off)
{
	struct tdb_traverse_lock *i;
	for (i = &tdb->travlocks; i; i = i->next)
		if (i->off == off)
			return -1;
	return tdb_brlock(tdb, off, F_WRLCK, F_SETLK);
}

/*
  Note this is meant to be F_SETLK, *not* F_SETLKW, as it's not
  an error to fail to get the lock here.
*/

static int write_unlock_record(TDB_CONTEXT *tdb, tdb_off off)
{
	return tdb_brlock(tdb, off, F_UNLCK, F_SETLK);
}
/* fcntl locks don't stack: avoid unlocking someone else's */
static int unlock_record(TDB_CONTEXT *tdb, tdb_off off)
{
	struct tdb_traverse_lock *i;
	u32 count = 0;

	if (off == 0)
		return 0;
	for (i = &tdb->travlocks; i; i = i->next)
		if (i->off == off)
			count++;
	return (count == 1 ? tdb_brlock(tdb, off, F_UNLCK, F_SETLKW) : 0);
}

/* actually delete an entry in the database given the offset */
static int do_delete(TDB_CONTEXT *tdb, tdb_off rec_ptr, struct list_struct*rec)
{
	tdb_off last_ptr, i;
	struct list_struct lastrec;

	if (tdb->read_only) return -1;

	if (write_lock_record(tdb, rec_ptr) == -1) {
		/* Someone traversing here: mark it as dead */
		rec->magic = TDB_DEAD_MAGIC;
		return rec_write(tdb, rec_ptr, rec);
	}
	write_unlock_record(tdb, rec_ptr);

	/* find previous record in hash chain */
	if (ofs_read(tdb, TDB_HASH_TOP(rec->full_hash), &i) == -1)
		return -1;
	for (last_ptr = 0; i != rec_ptr; last_ptr = i, i = lastrec.next)
		if (rec_read(tdb, i, &lastrec) == -1)
			return -1;

	/* unlink it: next ptr is at start of record. */
	if (last_ptr == 0)
		last_ptr = TDB_HASH_TOP(rec->full_hash);
	if (ofs_write(tdb, last_ptr, &rec->next) == -1)
		return -1;

	/* recover the space */
	if (tdb_free(tdb, rec_ptr, rec) == -1)
		return -1;
	return 0;
}

/* Uses traverse lock: 0 = finish, -1 = error, other = record offset */
static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
			 struct list_struct *rec)
{
	int want_next = (tlock->off != 0);

	/* No traversal allows if you've called tdb_lockkeys() */
	if (tdb->lockedkeys)
		return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);

	/* Lock each chain from the start one. */
	for (; tlock->hash < tdb->header.hash_size; tlock->hash++) {
		if (tdb_lock(tdb, tlock->hash, F_WRLCK) == -1)
			return -1;

		/* No previous record?  Start at top of chain. */
		if (!tlock->off) {
			if (ofs_read(tdb, TDB_HASH_TOP(tlock->hash),
				     &tlock->off) == -1)
				goto fail;
		} else {
			/* Otherwise unlock the previous record. */
			unlock_record(tdb, tlock->off);
		}

		if (want_next) {
			/* We have offset of old record: grab next */
			if (rec_read(tdb, tlock->off, rec) == -1)
				goto fail;
			tlock->off = rec->next;
		}

		/* Iterate through chain */
		while( tlock->off) {
			tdb_off current;
			if (rec_read(tdb, tlock->off, rec) == -1)
				goto fail;
			if (!TDB_DEAD(rec)) {
				/* Woohoo: we found one! */
				lock_record(tdb, tlock->off);
				return tlock->off;
			}
			/* Try to clean dead ones from old traverses */
			current = tlock->off;
			tlock->off = rec->next;
			do_delete(tdb, current, rec);
		}
		tdb_unlock(tdb, tlock->hash, F_WRLCK);
		want_next = 0;
	}
	/* We finished iteration without finding anything */
	return TDB_ERRCODE(TDB_SUCCESS, 0);

 fail:
	tlock->off = 0;
	tdb_unlock(tdb, tlock->hash, F_WRLCK);
	return -1;
}

/* traverse the entire database - calling fn(tdb, key, data) on each element.
   return -1 on error or the record count traversed
   if fn is NULL then it is not called
   a non-zero return value from fn() indicates that the traversal should stop
  */
int tdb_traverse(TDB_CONTEXT *tdb, tdb_traverse_func fn, void *state)
{
	TDB_DATA key, dbuf;
	struct list_struct rec;
	struct tdb_traverse_lock tl = { NULL, 0, 0 };
	int ret, count = 0;

	/* This was in the initializaton, above, but the IRIX compiler
	 * did not like it.  crh
	 */
	tl.next = tdb->travlocks.next;

	/* fcntl locks don't stack: beware traverse inside traverse */
	tdb->travlocks.next = &tl;

	/* tdb_next_lock places locks on the record returned, and its chain */
	while ((ret = tdb_next_lock(tdb, &tl, &rec)) > 0) {
		count++;
		/* now read the full record */
		key.dptr = tdb_alloc_read(tdb, tl.off + sizeof(rec), 
					  rec.key_len + rec.data_len);
		if (!key.dptr) {
			tdb_unlock(tdb, tl.hash, F_WRLCK);
			unlock_record(tdb, tl.off);
			tdb->travlocks.next = tl.next;
			return -1;
		}
		key.dsize = rec.key_len;
		dbuf.dptr = key.dptr + rec.key_len;
		dbuf.dsize = rec.data_len;

		/* Drop chain lock, call out */
		tdb_unlock(tdb, tl.hash, F_WRLCK);
		if (fn && fn(tdb, key, dbuf, state)) {
			/* They want us to terminate traversal */
			unlock_record(tdb, tl.off);
			tdb->travlocks.next = tl.next;
			free(key.dptr);
			return count;
		}
		free(key.dptr);
	}
	tdb->travlocks.next = tl.next;
	if (ret < 0)
		return -1;
	else
		return count;
}

/* find the first entry in the database and return its key */
TDB_DATA tdb_firstkey(TDB_CONTEXT *tdb)
{
	TDB_DATA key;
	struct list_struct rec;

	/* release any old lock */
	unlock_record(tdb, tdb->travlocks.off);
	tdb->travlocks.off = tdb->travlocks.hash = 0;

	if (tdb_next_lock(tdb, &tdb->travlocks, &rec) <= 0)
		return tdb_null;
	/* now read the key */
	key.dsize = rec.key_len;
	key.dptr =tdb_alloc_read(tdb,tdb->travlocks.off+sizeof(rec),key.dsize);
	tdb_unlock(tdb, BUCKET(tdb->travlocks.hash), F_WRLCK);
	return key;
}

/* find the next entry in the database, returning its key */
TDB_DATA tdb_nextkey(TDB_CONTEXT *tdb, TDB_DATA oldkey)
{
	u32 oldhash;
	TDB_DATA key = tdb_null;
	struct list_struct rec;
	char *k = NULL;

	/* Is locked key the old key?  If so, traverse will be reliable. */
	if (tdb->travlocks.off) {
		if (tdb_lock(tdb,tdb->travlocks.hash,F_WRLCK))
			return tdb_null;
		if (rec_read(tdb, tdb->travlocks.off, &rec) == -1
		    || !(k = tdb_alloc_read(tdb,tdb->travlocks.off+sizeof(rec),
					    rec.key_len))
		    || memcmp(k, oldkey.dptr, oldkey.dsize) != 0) {
			/* No, it wasn't: unlock it and start from scratch */
			unlock_record(tdb, tdb->travlocks.off);
			tdb_unlock(tdb, tdb->travlocks.hash, F_WRLCK);
			tdb->travlocks.off = 0;
		}

		if (k)
			free(k);
	}

	if (!tdb->travlocks.off) {
		/* No previous element: do normal find, and lock record */
		tdb->travlocks.off = tdb_find_lock(tdb, oldkey, F_WRLCK, &rec);
		if (!tdb->travlocks.off)
			return tdb_null;
		tdb->travlocks.hash = BUCKET(rec.full_hash);
		lock_record(tdb, tdb->travlocks.off);
	}
	oldhash = tdb->travlocks.hash;

	/* Grab next record: locks chain and returned record,
	   unlocks old record */
	if (tdb_next_lock(tdb, &tdb->travlocks, &rec) > 0) {
		key.dsize = rec.key_len;
		key.dptr = tdb_alloc_read(tdb, tdb->travlocks.off+sizeof(rec),
					  key.dsize);
		/* Unlock the chain of this new record */
		tdb_unlock(tdb, tdb->travlocks.hash, F_WRLCK);
	}
	/* Unlock the chain of old record */
	tdb_unlock(tdb, BUCKET(oldhash), F_WRLCK);
	return key;
}

/* delete an entry in the database given a key */
int tdb_delete(TDB_CONTEXT *tdb, TDB_DATA key)
{
	tdb_off rec_ptr;
	struct list_struct rec;
	int ret;

	if (!(rec_ptr = tdb_find_lock(tdb, key, F_WRLCK, &rec)))
		return -1;
	ret = do_delete(tdb, rec_ptr, &rec);
	tdb_unlock(tdb, BUCKET(rec.full_hash), F_WRLCK);
	return ret;
}

/* store an element in the database, replacing any existing element
   with the same key 

   return 0 on success, -1 on failure
*/
int tdb_store(TDB_CONTEXT *tdb, TDB_DATA key, TDB_DATA dbuf, int flag)
{
	struct list_struct rec;
	u32 hash;
	tdb_off rec_ptr;
	char *p = NULL;
	int ret = 0;

	/* find which hash bucket it is in */
	hash = tdb_hash(&key);
	if (!tdb_keylocked(tdb, hash))
		return -1;
	if (tdb_lock(tdb, BUCKET(hash), F_WRLCK) == -1)
		return -1;

	/* check for it existing, on insert. */
	if (flag == TDB_INSERT) {
		if (tdb_exists(tdb, key)) {
			tdb->ecode = TDB_ERR_EXISTS;
			goto fail;
		}
	} else {
		/* first try in-place update, on modify or replace. */
		if (tdb_update(tdb, key, dbuf) == 0)
			goto out;
		if (flag == TDB_MODIFY && tdb->ecode == TDB_ERR_NOEXIST)
			goto fail;
	}
	/* reset the error code potentially set by the tdb_update() */
	tdb->ecode = TDB_SUCCESS;

	/* delete any existing record - if it doesn't exist we don't
           care.  Doing this first reduces fragmentation, and avoids
           coalescing with `allocated' block before it's updated. */
	if (flag != TDB_INSERT)
		tdb_delete(tdb, key);

	/* Copy key+value *before* allocating free space in case malloc
	   fails and we are left with a dead spot in the tdb. */

	if (!(p = (char *)malloc(key.dsize + dbuf.dsize))) {
		tdb->ecode = TDB_ERR_OOM;
		goto fail;
	}

	memcpy(p, key.dptr, key.dsize);
	memcpy(p+key.dsize, dbuf.dptr, dbuf.dsize);

	/* now we're into insert / modify / replace of a record which
	 * we know could not be optimised by an in-place store (for
	 * various reasons).  */
	if (!(rec_ptr = tdb_allocate(tdb, key.dsize + dbuf.dsize, &rec)))
		goto fail;

	/* Read hash top into next ptr */
	if (ofs_read(tdb, TDB_HASH_TOP(hash), &rec.next) == -1)
		goto fail;

	rec.key_len = key.dsize;
	rec.data_len = dbuf.dsize;
	rec.full_hash = hash;
	rec.magic = TDB_MAGIC;

	/* write out and point the top of the hash chain at it */
	if (rec_write(tdb, rec_ptr, &rec) == -1
	    || tdb_write(tdb, rec_ptr+sizeof(rec), p, key.dsize+dbuf.dsize)==-1
	    || ofs_write(tdb, TDB_HASH_TOP(hash), &rec_ptr) == -1) {
	fail:
		/* Need to tdb_unallocate() here */
		ret = -1;
	}
 out:
	if (p)
		free(p); 
	tdb_unlock(tdb, BUCKET(hash), F_WRLCK);
	return ret;
}

static int tdb_already_open(dev_t device,
			    ino_t ino)
{
	TDB_CONTEXT *i;
	
	for (i = tdbs; i; i = i->next) {
		if (i->device == device && i->inode == ino) {
			return 1;
		}
	}

	return 0;
}

/* open the database, creating it if necessary 

   The open_flags and mode are passed straight to the open call on the
   database file. A flags value of O_WRONLY is invalid. The hash size
   is advisory, use zero for a default value.

   Return is NULL on error, in which case errno is also set.  Don't 
   try to call tdb_error or tdb_errname, just do strerror(errno).

   @param name may be NULL for internal databases. */
TDB_CONTEXT *tdb_open(char *name, int hash_size, int tdb_flags,
		      int open_flags, mode_t mode)
{
	TDB_CONTEXT *tdb;
	struct stat st;
	int rev = 0, locked;

	if (!(tdb = calloc(1, sizeof *tdb))) {
		/* Can't log this */
		errno = ENOMEM;
		goto fail;
	}
	tdb->fd = -1;
	tdb->name = NULL;
	tdb->map_ptr = NULL;
	tdb->lockedkeys = NULL;
	tdb->flags = tdb_flags;
	
	if ((open_flags & O_ACCMODE) == O_WRONLY) {
		errno = EINVAL;
		goto fail;
	}
	
	if (hash_size == 0)
		hash_size = DEFAULT_HASH_SIZE;
	if ((open_flags & O_ACCMODE) == O_RDONLY) {
		tdb->read_only = 1;
		/* read only databases don't do locking or clear if first */
		tdb->flags |= TDB_NOLOCK;
		tdb->flags &= ~TDB_CLEAR_IF_FIRST;
	}

	/* internal databases don't mmap or lock, and start off cleared */
	if (tdb->flags & TDB_INTERNAL) {
		tdb->flags |= (TDB_NOLOCK | TDB_NOMMAP);
		tdb->flags &= ~TDB_CLEAR_IF_FIRST;
		tdb_new_database(tdb, hash_size);
		goto internal;
	}

	if ((tdb->fd = open(name, open_flags, mode)) == -1) {
		goto fail;	/* errno set by open(2) */
	}

	/* ensure there is only one process initialising at once */
	if (tdb_brlock(tdb, GLOBAL_LOCK, F_WRLCK, F_SETLKW) == -1) {
		goto fail;	/* errno set by tdb_brlock */
	}

	/* we need to zero database if we are the only one with it open */
	if ((locked = (tdb_brlock(tdb, ACTIVE_LOCK, F_WRLCK, F_SETLK) == 0))
	    && (tdb_flags & TDB_CLEAR_IF_FIRST)) {
		open_flags |= O_CREAT;
		if (ftruncate(tdb->fd, 0) == -1) {
			goto fail; /* errno set by ftruncate */
		}
	}

	if (read(tdb->fd, &tdb->header, sizeof(tdb->header)) != sizeof(tdb->header)
	    || strcmp(tdb->header.magic_food, TDB_MAGIC_FOOD) != 0
	    || (tdb->header.version != TDB_VERSION
		&& !(rev = (tdb->header.version==TDB_BYTEREV(TDB_VERSION))))) {
		/* its not a valid database - possibly initialise it */
		if (!(open_flags & O_CREAT) || tdb_new_database(tdb, hash_size) == -1) {
			errno = EIO; /* ie bad format or something */
			goto fail;
		}
		rev = (tdb->flags & TDB_CONVERT);
	}
	if (!rev)
		tdb->flags &= ~TDB_CONVERT;
	else {
		tdb->flags |= TDB_CONVERT;
		convert(&tdb->header, sizeof(tdb->header));
	}
	if (fstat(tdb->fd, &st) == -1)
		goto fail;

	/* Is it already in the open list?  If so, fail. */
	if (tdb_already_open(st.st_dev, st.st_ino)) {
		errno = EBUSY;
		goto fail;
	}

	if (!(tdb->name = (char *)strdup(name))) {
		errno = ENOMEM;
		goto fail;
	}

	tdb->map_size = st.st_size;
	tdb->device = st.st_dev;
	tdb->inode = st.st_ino;
	tdb->locked = calloc(tdb->header.hash_size+1, sizeof(tdb->locked[0]));
	if (!tdb->locked) {
		errno = ENOMEM;
		goto fail;
	}
	tdb_mmap(tdb);
	if (locked) {
		if (tdb_brlock(tdb, ACTIVE_LOCK, F_UNLCK, F_SETLK) == -1) {
			goto fail;
		}
	}
	/* leave this lock in place to indicate it's in use */
	if (tdb_brlock(tdb, ACTIVE_LOCK, F_RDLCK, F_SETLKW) == -1)
		goto fail;

 internal:
	/* Internal (memory-only) databases skip all the code above to
	 * do with disk files, and resume here by releasing their
	 * global lock and hooking into the active list. */
	if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW) == -1)
		goto fail;
	tdb->next = tdbs;
	tdbs = tdb;
	return tdb;

 fail:
	{ int save_errno = errno;

	if (!tdb)
		return NULL;
	
	if (tdb->map_ptr) {
		if (tdb->flags & TDB_INTERNAL)
			free(tdb->map_ptr);
		else
			tdb_munmap(tdb);
	}
	if (tdb->name)
		free(tdb->name);
	if (tdb->fd != -1)
		close(tdb->fd);
	if (tdb->locked)
		free(tdb->locked);
	errno = save_errno;
	return NULL;
	}
}

/* close a database */
int tdb_close(TDB_CONTEXT *tdb)
{
	TDB_CONTEXT **i;
	int ret = 0;

	if (tdb->map_ptr) {
		if (tdb->flags & TDB_INTERNAL)
			free(tdb->map_ptr);
		else
			tdb_munmap(tdb);
	}
	if (tdb->name)
		free(tdb->name);
	if (tdb->fd != -1)
		ret = close(tdb->fd);
	if (tdb->locked)
		free(tdb->locked);
	if (tdb->lockedkeys)
		free(tdb->lockedkeys);

	/* Remove from contexts list */
	for (i = &tdbs; *i; i = &(*i)->next) {
		if (*i == tdb) {
			*i = tdb->next;
			break;
		}
	}

	memset(tdb, 0, sizeof(*tdb));
	free(tdb);

	return ret;
}

/* lock/unlock entire database */
int tdb_lockall(TDB_CONTEXT *tdb)
{
	u32 i;

	/* There are no locks on read-only dbs */
	if (tdb->read_only)
		return TDB_ERRCODE(TDB_ERR_LOCK, -1);
	if (tdb->lockedkeys)
		return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
	for (i = 0; i < tdb->header.hash_size; i++) 
		if (tdb_lock(tdb, i, F_WRLCK))
			break;

	/* If error, release locks we have... */
	if (i < tdb->header.hash_size) {
		u32 j;

		for ( j = 0; j < i; j++)
			tdb_unlock(tdb, j, F_WRLCK);
		return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
	}

	return 0;
}
void tdb_unlockall(TDB_CONTEXT *tdb)
{
	u32 i;
	for (i=0; i < tdb->header.hash_size; i++)
		tdb_unlock(tdb, i, F_WRLCK);
}

int tdb_lockkeys(TDB_CONTEXT *tdb, u32 number, TDB_DATA keys[])
{
	u32 i, j, hash;

	/* Can't lock more keys if already locked */
	if (tdb->lockedkeys)
		return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
	if (!(tdb->lockedkeys = malloc(sizeof(u32) * (number+1))))
		return TDB_ERRCODE(TDB_ERR_OOM, -1);
	/* First number in array is # keys */
	tdb->lockedkeys[0] = number;

	/* Insertion sort by bucket */
	for (i = 0; i < number; i++) {
		hash = tdb_hash(&keys[i]);
		for (j = 0; j < i && BUCKET(tdb->lockedkeys[j+1]) < BUCKET(hash); j++);
			memmove(&tdb->lockedkeys[j+2], &tdb->lockedkeys[j+1], sizeof(u32) * (i-j));
		tdb->lockedkeys[j+1] = hash;
	}
	/* Finally, lock in order */
	for (i = 0; i < number; i++)
		if (tdb_lock(tdb, i, F_WRLCK))
			break;

	/* If error, release locks we have... */
	if (i < number) {
		for ( j = 0; j < i; j++)
			tdb_unlock(tdb, j, F_WRLCK);
		free(tdb->lockedkeys);
		tdb->lockedkeys = NULL;
		return TDB_ERRCODE(TDB_ERR_NOLOCK, -1);
	}
	return 0;
}

/* Unlock the keys previously locked by tdb_lockkeys() */
void tdb_unlockkeys(TDB_CONTEXT *tdb)
{
	u32 i;
	for (i = 0; i < tdb->lockedkeys[0]; i++)
		tdb_unlock(tdb, tdb->lockedkeys[i+1], F_WRLCK);
	free(tdb->lockedkeys);
	tdb->lockedkeys = NULL;
}

/* lock/unlock one hash chain. This is meant to be used to reduce
   contention - it cannot guarantee how many records will be locked */
int tdb_chainlock(TDB_CONTEXT *tdb, TDB_DATA key)
{
	return tdb_lock(tdb, BUCKET(tdb_hash(&key)), F_WRLCK);
}
void tdb_chainunlock(TDB_CONTEXT *tdb, TDB_DATA key)
{
	tdb_unlock(tdb, BUCKET(tdb_hash(&key)), F_WRLCK);
}

Re: your mail

[Alan Cox]

> > 	fd = sem_initialize();
> > 	mmap(fd, ...)
> > 	..
> > 	munmap(..)
> > 
> > which gives you a handle for the semaphore.
> 
> No no no!  Implemented exactly that (and posted to l-k IIRC), and it's
> *horrible* to use.

All Linus forgot was to sem_initialize("filename"); With that the rest
comes out for free.

Re: your mail

[Alexander Viro]

On Mon, 25 Feb 2002, Rusty Russell wrote:

> In message <Pine.GSO.4.21.0202242054410.1329-100000@weyl.math.psu.edu> you writ
> e:
> > 
> > 
> > On Mon, 25 Feb 2002, Rusty Russell wrote:
> > > First, fd passing sucks: you can't leave an fd somewhere and wait for
> > > someone to pick it up, and they vanish when you exit.  Secondly, you
> > 
> > Yes, you can.  Please, RTFS - what is passed is not a descriptor, it's
> > struct file *.  As soon as datagram is sent, descriptors are resolved and
> > after that point descriptor table of sender (or, for that matter, survival
> > of sender) doesn't matter.
> 
> Please explain how I leave a fd somewhere for other processes to grab
> it.  
> 
> And then please explain how they get the fd after I've exited.
> 
> Al, you are one of the most unpleasant people to deal with on this
> list.  This is *not* an honor, and I beg you to consider a different
> approach in future correspondence.

Honour or not, in this case your complaint is hardly deserved.  To
compress the above a bit:

you: <false statement>
me: RTFS.  <short description of the reasons why statement is wrong; further
details could be obtained by reading TFS>

As for your question, SCM_RIGHTS datagram can easily outlive the sending
process.  You will need a helper process (either per-meeting point or
system-wide) to avoid GC killing the thing, but that's it.

Writing such helper is left as an exercise to reader - it _is_ trivial.
To put fd(s):
	connect to (name of AF_UNIX socket)
	sendmsg to it; no OOB data, one byte of data (non-0)
	form an SCM_RIGHTS datagram with fds in question
	sendmsg it to the same socket.
	close the socket
In helper:
	listen on (name)
repeat:
	accept connection
	read one byte
	if it's non-zero
		put fd of connection into a list
		goto repeat
	else
		take first fd from list
		form an SCM_RIGHTS datagram with that fd
		send it into the new connection
		close fd
		close connection
		goto repeat
To get fd(s):
	connect ....
	sendmsg .................................... (0)
	recvmsg and pick fd from the message
	close connection
	recvmsg from fd and pick the set of fds from the message
	close fd

End of story.  In real-life situation you will want to throttle in helper,
etc., but in any case main loop is ~20 lines of code.

Re: your mail

[Davide Libenzi]

On Mon, 25 Feb 2002, Rusty Russell wrote:

> In message <Pine.GSO.4.21.0202242054410.1329-100000@weyl.math.psu.edu> you writ
> e:
> >
> >
> > On Mon, 25 Feb 2002, Rusty Russell wrote:
> > > First, fd passing sucks: you can't leave an fd somewhere and wait for
> > > someone to pick it up, and they vanish when you exit.  Secondly, you
> >
> > Yes, you can.  Please, RTFS - what is passed is not a descriptor, it's
> > struct file *.  As soon as datagram is sent, descriptors are resolved and
> > after that point descriptor table of sender (or, for that matter, survival
> > of sender) doesn't matter.
>
> Please explain how I leave a fd somewhere for other processes to grab
> it.
>
> And then please explain how they get the fd after I've exited.
>
> Al, you are one of the most unpleasant people to deal with on this
> list.  This is *not* an honor, and I beg you to consider a different
> approach in future correspondence.

Actually, this is one of Al's nicest posts :-)
You obviously can't share fd# but you can share file*
I don't know how you're going to have these semaphores 'externally visible',
if with numbers like IPC sems or if with pathnames like unix sockets ( or
something else ). But you can have internally a number/path/else -> file*
mapping and when a task attaches the sem you map the file* onto an fd# in
the task's file table. If you keep this mapping persistent ( until
explicit deletion ) the file* remain alive event with zero attached
processes. I think it's this what Al was trying to say.




- Davide

Re: your mail

[Rusty Russell]

In message <Pine.GSO.4.21.0202242054410.1329-100000@weyl.math.psu.edu> you writ
e:
> 
> 
> On Mon, 25 Feb 2002, Rusty Russell wrote:
> > First, fd passing sucks: you can't leave an fd somewhere and wait for
> > someone to pick it up, and they vanish when you exit.  Secondly, you
> 
> Yes, you can.  Please, RTFS - what is passed is not a descriptor, it's
> struct file *.  As soon as datagram is sent, descriptors are resolved and
> after that point descriptor table of sender (or, for that matter, survival
> of sender) doesn't matter.

Please explain how I leave a fd somewhere for other processes to grab
it.  

And then please explain how they get the fd after I've exited.

Al, you are one of the most unpleasant people to deal with on this
list.  This is *not* an honor, and I beg you to consider a different
approach in future correspondence.

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: your mail

[Alexander Viro]

On Mon, 25 Feb 2002, Rusty Russell wrote:

> > Note that getting a file descriptor is really quite useful - it means that
> > you can pass the file descriptor around through unix domain sockets, for
> > example, and allow sharing of the semaphore across unrelated processes
> > that way.
> 
> First, fd passing sucks: you can't leave an fd somewhere and wait for
> someone to pick it up, and they vanish when you exit.  Secondly, you

Yes, you can.  Please, RTFS - what is passed is not a descriptor, it's
struct file *.  As soon as datagram is sent, descriptors are resolved and
after that point descriptor table of sender (or, for that matter, survival
of sender) doesn't matter.

Re: your mail

[Drew P. Vogel]

Personally, when I'm getting a few hundred emails per day, I don't even
notice the 5% spam.

--Drew Vogel

On Wed, 30 Jan 2002, Nickolaos Fotopoulos wrote:

>I'm new to this list.  Does it get spammed often, like this guy
>(grumph@pakistanmail.com) is doing?  It is allready becoming quite anouying!
>This is by far the busiest list I have ever subscribed to, and there does
>not seem to be any sort of spam blocker working here.  I thought Majodomo
>had stuff like this built in?  If not maybe a list moderator could address
>this.
>				Nick Fotopoulos
>-
>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/
>

Re: your mail

[Matti Aarnio]

On Wed, Jan 30, 2002 at 01:21:17PM -0500, Nickolaos Fotopoulos wrote:
> I'm new to this list.  Does it get spammed often, like this guy
> (grumph@pakistanmail.com) is doing?  It is allready becoming quite anouying!

  I already asked about the phenomena, and the guy(?) replied that
  he won't use that system anymore as it is doing those repeated
  sends all by itself.

> This is by far the busiest list I have ever subscribed to, and there does
> not seem to be any sort of spam blocker working here.  I thought Majodomo
> had stuff like this built in?  If not maybe a list moderator could address
> this.

  http://vger.kernel.org/majordomo-info.html

  Trust me, there is HEAVY filtering.
  Still some spams do get thru.

> 				Nick Fotopoulos

/Matti Aarnio

Re: your mail

[Jens Axboe]

On Wed, Jan 09 2002, Michael Zhu wrote:
> > 
> > This may be a troll. How would you boot? Who
> decrypts during the
> > boot?
> > 
> 
> You mean that the loop device couldn't en/decrypt the
> whole data on the disk? That mean the loop device
> could implement the block level en/decryption.

Please, read up on the loop crypto stuff off-list. Most of these
questions are very FAQ. You can loop crypto a whole disk or partition of
you want.

-- 
Jens Axboe

Re: your mail

[Rik van Riel]

On 2 Jan 2002, mehul radheshyam choube wrote:

>    i would like to do some developement work for linux-mm
>    please guide me .

This all depends on what kind of project you would be
interested in. ;)

If you want to play with new VM features, you could
start by testing the reverse mapping patch and finding
bugs, maybe looking at how things work or even at
implementing some items from the TODO list ;)

http://surriel.com/patches/
http://linuxvm.bkbits.net/

kind regards,

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[Martin Dalecki]

Linus Torvalds wrote:

>(Right now you can see this in block_ioctl.c - while only a few of the
>ioctl's have been converted, you get the idea. I'm actually surprised that
>nobody seems to have commented on that part).
>

That was just too obvious, at least for me... However I don't see why 
you just don't start killing of constructs like:

swtch  (ioctrl)

    BLASH:
BLAHHH:
 BLASHH:
 BLAASS:
     BLAH:
    default:
            return -ENOVAL;
}

There are ton' s of them out there in the block drivers..

Re: your mail

[Andrew Morton]

Linus Torvalds wrote:
> 
> The other part of the bio rewrite has been to get rid of another coupling:
> the coupling between "struct buffer_head" (which is used for a limited
> kind of memory management by a number of filesystems) and the act of
> actually just doing IO.
> 
> I used to think that we could just relegate "struct buffer_head" to _be_
> the IO entity, but it turns out to be much easier to just split off the IO
> part, which is why you now have a separate "bio" structure for the block
> IO part, and the buffer_head stuff uses that to get the work done.
> 

So... would it be correct to say that there won't be any large
changes to the buffer_head concept in 2.5?

Re: your mail

[Linus Torvalds]

On Thu, 27 Dec 2001, Andre Hedrick wrote:
>
> Lots of luck ... please pass your crack pipe arounds so the rest of us
> idiots can see your vision or lack of ...

Heh. I think I must have passed it on to you long ago, and you never gave
it back, you sneaky bastard ;)

The vision, btw, is to get the request layer in good enough shape that we
can dispense with the mid-layer approaches of SCSI/IDE, and block devices
turn into _just_ device drivers.

For example, ide-scsi is heading for that big scrap-yard in the sky: it's
not the SCSI layer that handles special ioctl requests any more, because
the upper layers are going to be flexible enough that you can just pass
the requests down the regular pipe.

(Right now you can see this in block_ioctl.c - while only a few of the
ioctl's have been converted, you get the idea. I'm actually surprised that
nobody seems to have commented on that part).

The final end result of this (I sincerely hope) is that we can get rid of
some of the couplings that we've had in the block layer. ide-scsi is just
the most obvious strange coupling - things like "sg.c" in general are
rather horrible. There's very little _SCSI_ in sg.c - it's really about
sending commands down to the block devices.

The reason I want to get rid of the couplings is that they end up being
big anchors holding down development: you can create a clean driver that
isn't dependent on the SCSI layer overheads (and people do, for things
like DAC etc), but when you do that you lose _all_ of the support
infrastructure, not just the bloat. Which is sad.

(And which is why things like ide-scsi exist - IDE didn't really want to
be a SCSI driver, but people _did_ want to be able to use some of the
generic support routines that the SCSI layer offers. You couldn't just
cherry-pick the parts you wanted).

The other part of the bio rewrite has been to get rid of another coupling:
the coupling between "struct buffer_head" (which is used for a limited
kind of memory management by a number of filesystems) and the act of
actually just doing IO.

I used to think that we could just relegate "struct buffer_head" to _be_
the IO entity, but it turns out to be much easier to just split off the IO
part, which is why you now have a separate "bio" structure for the block
IO part, and the buffer_head stuff uses that to get the work done.

Andre, I know that you're worried about the low-level drivers, but:

 - I've long since noticed that we cannot communicate, which is why Jens
   is the block level driver person. You'll have to live with it.

 - I personally don't think you _can_ make a good driver without having
   reasonable interfaces, and we didn't have them.

   For example, the network drivers have improved a lot and do not have
   _nearly_ the amount of problems block drivers have. That's obviously
   partly just because it is a simpler problem, but because it was simpler
   it was also possible to change them. The infrastructure changes in the
   networking during 2.3.x really did help drivers.

And note that the "Jens" and "communication" part is important. If you
have patches, please talk to Jens, tell him what the issues, are, and I
know I can communicate with him.

			Linus

Re: your mail

[Andre Hedrick]

On Thu, 6 Dec 2001, Linus Torvalds wrote:

> 
> On Fri, 7 Dec 2001, Keith Owens wrote:
> >
> > Linus, the time has come to convert the 2.5 kernel to kbuild 2.5.
> 
> We're getting the block IO layer in shape first, the time has not come for
> _anything_ else before that.
> 
> 		Linus

Lots of luck ... please pass your crack pipe arounds so the rest of us
idiots can see your vision or lack of ...

Regards,

Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project

Re: your mail

[Kirk Alexander]

 --- Gérard_Roudier <groudier@free.fr> wrote: > 
> 
[snip]
> 
> You may let me know if sym53c8xx_2 still works with 810 rev 2.
> 



I tried the sym53c8xx_2 driver, put a fair load on the system (lots of sync'ing
and swapping) and didn't seem to have any trouble.

Cheers,
 Kirk Alexander

Re: your mail

[Dave Jones]

On Mon, 17 Dec 2001, Sebastian Dröge wrote:

> So I removed the apic.c hunk
> I think you meant that ;)

*nod*

> Anyway this doesn't solve the problem :(

Ok, this isn't urgent anyway, I'll get around to cleaning that
up later. Thanks for your help tracing this.

Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: your mail

[Sebastian Dröge]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

Hmm...
I don't see anything about ioapic.c in the patch...
So I removed the apic.c hunk
I think you meant that ;)
Anyway this doesn't solve the problem :(

Bye

On Mon, 17 Dec 2001 18:25:37 +0100 (CET)
Dave Jones <davej@suse.de> wrote:

> On Mon, 17 Dec 2001, Sebastian Dröge wrote:
> 
> > Thanks
> > This does work
> 
> Great, now can you edit the patch to remove the ioapic.c hunk,
> reapply, and see if that works..
> 
> > What do you think was exactly the problem?
> 
> looks like I dorked the apic init...
> I'll back that bit out for -dj2, until I've given
> it a bit more work.
> 
> regards,
> Dave.
> 
> -- 
> | Dave Jones.        http://www.codemonkey.org.uk
> | SuSE Labs
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: your mail

[Dave Jones]

On Mon, 17 Dec 2001, Sebastian Dröge wrote:

> Thanks
> This does work

Great, now can you edit the patch to remove the ioapic.c hunk,
reapply, and see if that works..

> What do you think was exactly the problem?

looks like I dorked the apic init...
I'll back that bit out for -dj2, until I've given
it a bit more work.

regards,
Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: your mail

[Sebastian Dröge]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

Thanks
This does work
What do you think was exactly the problem?

Bye

On Mon, 17 Dec 2001 17:57:01 +0100 (CET)
Dave Jones <davej@suse.de> wrote:

> On Mon, 17 Dec 2001, Sebastian Dröge wrote:
> 
> > 2.4.16-2.4.17-rc1 works perfectly
> > 2.5.0-2.5.1 works perfectly
> > Only 2.5.1-dj1 has this 2 errors (ISA-PnP non-detection and USB only root hub detection)
> > All have the same .config
> > If you need some more information feel free to ask me ;)
> 
> Ok, can you try backing out this patch.. (just patch as normal but with -R)
> http://www.codemonkey.org.uk/patches/2.5/small-bits/early-cpuinit-1.diff
> 
> regards,
> Dave.
> 
> -- 
> | Dave Jones.        http://www.codemonkey.org.uk
> | SuSE Labs
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: your mail

[Arnaldo Carvalho de Melo]

Em Mon, Dec 17, 2001 at 05:52:06PM +0100, Sebastian Dröge escreveu:
> PS: 2.5.1 (dj1 or not ;) has one problem more on my pc:
> INIT can't send the TERM signal to all processes...

see the kill(-1,sig) thread...

> Nothing happens... no error message no nothing
> SysRQ works
> I don't know when it went into 2.5 but I think it wasn't there in -pre10 (don't try -pre11)
> PPS: What the hell is APIC (no I don't mean ACPI)? ;) I've enabled it on my UP machine but don't know what it does...
> Does anyone have informations about it?

Advanced Programmable Interrupt Controller, found in SMP machines and in
some UP ones, for UP its shouldn't be enabled in most cases.

- Arnaldo

Re: your mail

[Sebastian Dröge]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

Ok...
2.4.16-2.4.17-rc1 works perfectly
2.5.0-2.5.1 works perfectly
Only 2.5.1-dj1 has this 2 errors (ISA-PnP non-detection and USB only root hub detection)
All have the same .config
If you need some more information feel free to ask me ;)

Bye

PS: 2.5.1 (dj1 or not ;) has one problem more on my pc:
INIT can't send the TERM signal to all processes...
Nothing happens... no error message no nothing
SysRQ works
I don't know when it went into 2.5 but I think it wasn't there in -pre10 (don't try -pre11)
PPS: What the hell is APIC (no I don't mean ACPI)? ;) I've enabled it on my UP machine but don't know what it does...
Does anyone have informations about it?

On Mon, 17 Dec 2001 17:22:14 +0100 (CET)
Dave Jones <davej@suse.de> wrote:

> On Mon, 17 Dec 2001, Sebastian Dröge wrote:
> 
> > Attached you find my .config, lspci -vvv and dmesg output
> > I'll test 2.4.17-rc1 in a few minutes and will report what happens ;)
> 
> Thanks. Right now getting 2.4 into a better shape is more
> important than fixing 2.5, so if you find any problems repeatable
> in 2.4.17rc1, Marcelo really needs to know about it.
> 
> The only USB changes in my tree are __devinit_p changes, which
> really shouldn't be causing a problem, but there could be some
> other unrelated-to-usb patch which is causing this..
> 
> 2.4 info would be appreciated.
> 
> Dave.
> 
> -- 
> | Dave Jones.        http://www.codemonkey.org.uk
> | SuSE Labs
> 
> -
> 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/
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: your mail

[Dave Jones]

On Mon, 17 Dec 2001, Sebastian Dröge wrote:

> Attached you find my .config, lspci -vvv and dmesg output
> I'll test 2.4.17-rc1 in a few minutes and will report what happens ;)

Thanks. Right now getting 2.4 into a better shape is more
important than fixing 2.5, so if you find any problems repeatable
in 2.4.17rc1, Marcelo really needs to know about it.

The only USB changes in my tree are __devinit_p changes, which
really shouldn't be causing a problem, but there could be some
other unrelated-to-usb patch which is causing this..

2.4 info would be appreciated.

Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: your mail

[Gérard Roudier]

On Sat, 15 Dec 2001, Stephan von Krawczynski wrote:

> On Fri, 14 Dec 2001 17:46:37 +0100 (CET)
> Gérard Roudier <groudier@free.fr> wrote:
>
> > > My system is a clunky old Digital Pentium Pro with a
> > > NCR53c810 rev 2 scsi controller, so it can't use the
> > > sym driver.
> >
> > Use sym53c8xx_2 instead. This one uses 2 different firmwares,
> > [...]
> > You may let me know if sym53c8xx_2 still works with 810 rev 2.
>
> On my system it does. I have it as a second controller and am using sym-2
> without troubles.

Thanks for your report.

  Gérard.

Re: your mail

[Gérard Roudier]

On Sat, 15 Dec 2001, Peter Bornemann wrote:

> On Fri, 14 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
>
> >
> >
> > On Fri, 14 Dec 2001, Peter Bornemann wrote:
> > > Ahemm -- well,
> > > maybe I'm the first one. I have a symbios card, which is recognized by
> > > lspci:  SCSI storage controller: LSI Logic Corp. / Symbios Logic Inc.
> > > (formerly NCR) 53c810 (rev 23).
> > Could you, please,  report me more accurate information.
> > TIA,
> >
>
> Well, it seems I made my intention not very clear: I do not want You to
> fix something in the driver, I just wanted from You to leave the old
> ncr-driver in the kernel, just for the situation of a first install. I
> think no newbie with little knowledge will be able to install Linux (or,
> maybe, FreeBSD), when he happens to own such an controller. First, he
> won't be able to read very much on the screen, for the loop runs much too
> fast and second, he will not understand when he reads something about a
> sym53c8xx. Exactly for this case I think the old driver should be left in.
> If You want, You can tell him "Attention! Use of this driver deprecated.
> Contact Your support." or whatever seems appropriate. It is just about the
> first step to linuxland :-)
>
> Hope I managed to make myself clear tris time

I have limited time and am very bad in politics. I do prefer to have to
deal with accurate technical issues. My english is also limited to this
field.

You would have been clear if you had reported:

1) Which of the mpar= spar= and/or corresponding compiled-in options made
   your broken hardware works (with high risks of silent corruption).

2) If using the corresponding compiled-in option worked with sym-2.

3) Optionnaly, relevant messages printed by sym-2, even taken by hand,
   when the problem occurs.

+ any other pertinent information I cannot guess about you thought can
  help.

About FreeBSD, the only information I have is that the (sad) work-around I
implemented and that is incorporated in sym-2 _did_ work around the
problem of PCI parity error for people that did report results.

Could you be clear, as expected by technical group of discussions, please.

  Gérard.

PS: The ncr53c8xx may just work since it does trust POST software to
    enable PCI parity checking bit in PCI config space. But it seems that
    most POST shits donnot do so, leaving systems with the risk of silent
    data corruption in contradiction with either PCI specifications and user
    expectation.

Re: your mail

[Stephan von Krawczynski]

On Fri, 14 Dec 2001 17:46:37 +0100 (CET)
Gérard Roudier <groudier@free.fr> wrote:

> > My system is a clunky old Digital Pentium Pro with a
> > NCR53c810 rev 2 scsi controller, so it can't use the
> > sym driver.
> 
> Use sym53c8xx_2 instead. This one uses 2 different firmwares,
> [...]
> You may let me know if sym53c8xx_2 still works with 810 rev 2.

On my system it does. I have it as a second controller and am using sym-2
without troubles.

Regards,
Stephan

Re: your mail

[Peter Bornemann]

On Fri, 14 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:

>
>
> On Fri, 14 Dec 2001, Peter Bornemann wrote:
> > Ahemm -- well,
> > maybe I'm the first one. I have a symbios card, which is recognized by
> > lspci:  SCSI storage controller: LSI Logic Corp. / Symbios Logic Inc.
> > (formerly NCR) 53c810 (rev 23).
> Could you, please,  report me more accurate information.
> TIA,
>

Well, it seems I made my intention not very clear: I do not want You to
fix something in the driver, I just wanted from You to leave the old
ncr-driver in the kernel, just for the situation of a first install. I
think no newbie with little knowledge will be able to install Linux (or,
maybe, FreeBSD), when he happens to own such an controller. First, he
won't be able to read very much on the screen, for the loop runs much too
fast and second, he will not understand when he reads something about a
sym53c8xx. Exactly for this case I think the old driver should be left in.
If You want, You can tell him "Attention! Use of this driver deprecated.
Contact Your support." or whatever seems appropriate. It is just about the
first step to linuxland :-)

Hope I managed to make myself clear tris time

Peter B



          .         .
          |\_-^^^-_/|
          / (|)_(|) \
         ( === X === )
          \  ._|_.  /
           ^-_   _-^
              °°°

Re: your mail

[Peter Bornemann]

On Fri, 14 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
> By the way, for now, I haven't received any report about sym-2 failing
> when sym-1 or ncr succeeds, and my feeling is that this could well be very
> unlikely.
>

Ahemm -- well,
maybe I'm the first one. I have a symbios card, which is recognized by
lspci:  SCSI storage controller: LSI Logic Corp. / Symbios Logic Inc.
(formerly NCR) 53c810 (rev 23).

This card goes into an endless loop during parity-checking. So tried to
disable it for the new sym53cxx in modules.conf:
options sym53c8xx mpar:n spar:n
This did not help in this case, however.

There have been so far three ways to solve  this problem:
1. Use the very old ncr53c7,8 or so driver. This is working rather
unreliable for me.
2. Use the ncr53c8xx, which works usually well
3. Use sym53c8xx(old) compiled with parity disabled

Probably there is a way around that, but somebody trying to install Linux
from a SCSI-CDROM with this card for the first time will very likely not
succeed. I have seen this with (for instance) Corel-Linux and FreeBSD
(same driver).
NB Parity checking for me is not really all that important as there is no
hardrive connected to that card. Only CD and scanner.

Peter B

          .         .
          |\_-^^^-_/|
          / (|)_(|) \
         ( === X === )
          \  ._|_.  /
           ^-_   _-^
              °°°

Re: your mail

[Jens Axboe]

On Fri, Dec 14 2001, Kirk Alexander wrote:
> [cc'ed to lkml and Gerard Roudier]
> 
> Hi Jens,
> 
> You asked people to send in reports of which drivers
> were broken by the removal of io_request_lock.
> 
> My system is a clunky old Digital Pentium Pro with a
> NCR53c810 rev 2 scsi controller, so it can't use the
> sym driver. I fixed the problem by seeing what the sym
> driver did i.e. the patch below 
> This may not be right at all, and I haven't had a
> chance to boot the kernel - but it did build OK.

Missed your original post, it had no subject line. At first view, your
patch looks correct. However, check the ->detect() routing and verify
it's not assuming the lock is held there. That should be the only
pitfall.

Minor nit pick -- since this driver is _in_ the 2.5 tree, there's no way
the #ifdef would not hit. So the way I've been fixing these is to just
always assume latest kernel.

I think this was already fixed though, but at least know you now you did
it right :-)

-- 
Jens Axboe

Re: your mail

[Gérard Roudier]

On Fri, 14 Dec 2001, Peter Bornemann wrote:

> On Fri, 14 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
> > By the way, for now, I haven't received any report about sym-2 failing
> > when sym-1 or ncr succeeds, and my feeling is that this could well be very
> > unlikely.
> >
>
> Ahemm -- well,
> maybe I'm the first one. I have a symbios card, which is recognized by
> lspci:  SCSI storage controller: LSI Logic Corp. / Symbios Logic Inc.
> (formerly NCR) 53c810 (rev 23).
>
> This card goes into an endless loop during parity-checking. So tried to
> disable it for the new sym53cxx in modules.conf:
> options sym53c8xx mpar:n spar:n
> This did not help in this case, however.
>
> There have been so far three ways to solve  this problem:
> 1. Use the very old ncr53c7,8 or so driver. This is working rather
> unreliable for me.
> 2. Use the ncr53c8xx, which works usually well
> 3. Use sym53c8xx(old) compiled with parity disabled
>
> Probably there is a way around that, but somebody trying to install Linux
> from a SCSI-CDROM with this card for the first time will very likely not
> succeed. I have seen this with (for instance) Corel-Linux and FreeBSD
> (same driver).
> NB Parity checking for me is not really all that important as there is no
> hardrive connected to that card. Only CD and scanner.

About what parity sort are you talking about ?
PCI parity ? SCSI parity ?

PCI parity checking is not an option. If it is this one, then your
hardware is simply broken. For such broken hardwares that returns such
spurious PCI parity error early during HBA probing, sym-2 can detect this
and disable PCI parity checking. This has been reported to work well under
FreeBSD. And sym-2 is also supposed to accept the manual disabling, either
by compiled-in option or using the mpar=n boot-up options.

For SCSI parity, which is different matter, both drivers try to cope and
still sym-2 should accept the spar=n boot-up option.

Could you, please,  report me more accurate information.
TIA,
  Gérard.

Re: your mail

[Jens Axboe]

On Fri, Dec 14 2001, Gérard Roudier wrote:
> > I fixed the problem by seeing what the sym
> > driver did i.e. the patch below
> > This may not be right at all, and I haven't had a
> > chance to boot the kernel - but it did build OK.
> 
> The ncr53c8xx and sym53c8xx version 1 use the obsolete scsi eh handling.
> Moving the eh code from sym53c8xx_2 (version 2) to ncr53c8xx/sym53c8xx is
> quite feasible, but may-be it is just useless given sym53c8xx_2. For now,
> it seems that sym53c8xx_2 replaces both ncr/sym53c8xx without any loss of
> reliability and performance.

Gerard,

For 2.5, why don't we just yank old sym and ncr out of the kernel? Is
there _any_ reason to keep the two older ones given your new driver
handles it all?

-- 
Jens Axboe

Re: your mail

[Gérard Roudier]

On Fri, 14 Dec 2001, Jens Axboe wrote:

> On Fri, Dec 14 2001, Gérard Roudier wrote:
> > > I fixed the problem by seeing what the sym
> > > driver did i.e. the patch below
> > > This may not be right at all, and I haven't had a
> > > chance to boot the kernel - but it did build OK.
> >
> > The ncr53c8xx and sym53c8xx version 1 use the obsolete scsi eh handling.
> > Moving the eh code from sym53c8xx_2 (version 2) to ncr53c8xx/sym53c8xx is
> > quite feasible, but may-be it is just useless given sym53c8xx_2. For now,
> > it seems that sym53c8xx_2 replaces both ncr/sym53c8xx without any loss of
> > reliability and performance.
>
> Gerard,
>
> For 2.5, why don't we just yank old sym and ncr out of the kernel? Is
> there _any_ reason to keep the two older ones given your new driver
> handles it all?

On my side, there is obviously no reason to keep them in 2.5, as sym-2 is
intended to replace them both. Personnaly I have switched to sym-2 on my
systems since several months.

However, I donnot consider myself as the only owner of these drivers. The
owners are all people that may need symbios chips support under Linux. My
personnal vote, as a user/owner, is to remove them and rely for symbios
chip support on sym-2.

--

Linux stable is a different issue. For this one, I would prefer the old
drivers to remain in place for a longer time. However, I personnaly will
not track bugs on old drivers if either,

- The problem also shows up in sym-2. Then I will try to fix sym-2,
- Or the problem simply doesn't occur in sym-2.

This will apply to problems reported directly by users or by packagers.

By the way, for now, I haven't received any report about sym-2 failing
when sym-1 or ncr succeeds, and my feeling is that this could well be very
unlikely.

But I can make mistakes, me too. :-)

  Gérard.

Re: your mail

[Gérard Roudier]

On Fri, 14 Dec 2001, Kirk Alexander wrote:

> [cc'ed to lkml and Gerard Roudier]
>
> Hi Jens,
>
> You asked people to send in reports of which drivers
> were broken by the removal of io_request_lock.
>
> My system is a clunky old Digital Pentium Pro with a
> NCR53c810 rev 2 scsi controller, so it can't use the
> sym driver.

Use sym53c8xx_2 instead. This one uses 2 different firmwares,

- one based on sym53c8xx driver scripts called
  'LOAD/STORE based' firmware,
- and another one that only uses generic scripts instructions
  and called 'GENERIC' firmware.

The GENERIC firmware has worked for me witn a 810 rev. 2.

I haven't this controller installed at the moment, but I can test the
driver by forcing the driver to use the GENERIC scripts instead for any
symbios chip.

You may let me know if sym53c8xx_2 still works with 810 rev 2.

> I fixed the problem by seeing what the sym
> driver did i.e. the patch below
> This may not be right at all, and I haven't had a
> chance to boot the kernel - but it did build OK.

The ncr53c8xx and sym53c8xx version 1 use the obsolete scsi eh handling.
Moving the eh code from sym53c8xx_2 (version 2) to ncr53c8xx/sym53c8xx is
quite feasible, but may-be it is just useless given sym53c8xx_2. For now,
it seems that sym53c8xx_2 replaces both ncr/sym53c8xx without any loss of
reliability and performance.

  Gérard.

> Cheers,
> Kirk Alexander
>
> P.S.
> Please excuse me if this has already been fixed or
> posted, or if I've broken some lkml etiquette - first
> post I think after lurking off and on for ages. Also
> first time I've compiled a kernel that has only been
> out a few days!

You are welcome and you didn't break any etiquette. The lkml is a very
open mailing list but it gets more than 200 postings a day. Thus the
linux-scsi@vger.kernel.org list should be preferred for topics that
address scsi specifically.


> --- linux/drivers/scsi/sym53c8xx_comm.h	Fri Dec 14
> 16:46:45 2001
> +++ linux/drivers/scsi/sym53c8xx_comm.h	Fri Dec 14
> 16:49:19 2001
> @@ -438,11 +438,20 @@
>  #define	NCR_LOCK_NCB(np, flags)
> spin_lock_irqsave(&np->smp_lock, flags)
>  #define	NCR_UNLOCK_NCB(np, flags)
> spin_unlock_irqrestore(&np->smp_lock, flags)
>
> +#if LINUX_VERSION_CODE >= LinuxVersionCode(2,5,0)
> +
> +#define	NCR_LOCK_SCSI_DONE(np, flags) \
> +		spin_lock_irqsave((np)->done_list->host, flags)
> +#define	NCR_UNLOCK_SCSI_DONE(np, flags) \
> +		spin_unlock_irqrestore((np)->done_list->host,
> flags)
> +#else
> +
>  #define	NCR_LOCK_SCSI_DONE(np, flags) \
>  		spin_lock_irqsave(&io_request_lock, flags)
>  #define	NCR_UNLOCK_SCSI_DONE(np, flags) \
>  		spin_unlock_irqrestore(&io_request_lock, flags)
>
> +#endif
>  #else
>
>  #define	NCR_LOCK_DRIVER(flags)     do {
> save_flags(flags); cli(); } while (0)

Re: your mail

[Linus Torvalds]

On Fri, 7 Dec 2001, Keith Owens wrote:
>
> Linus, the time has come to convert the 2.5 kernel to kbuild 2.5.

We're getting the block IO layer in shape first, the time has not come for
_anything_ else before that.

		Linus

Re: your mail

[Tim Hockin]

> What is the effect of following statement at the end of function definition?
> *(int *)0 = 0;	

to cause a crash - you can't derefernce a pointer whose value is 0 (NULL).

Re: your mail

[Martin Schulze]

Marian Kafadarov wrote:
> Hello,
> We have DEC station 5000 / 240
> From were we can download Linux distribution and documentation for it and
> what we can do on it.

You could wait until we have finished boot-floppies for this machine
(1-3 weeks) or bootstrap from scratch by using a kernel and a Debian
base system.  Both is available, Karsten can also provide a correct
2.4.x kernel.

I'd rather like to ask you to wait a couple of days/weeks until
boot-floppies are available for this machine and you can use the
regular Debian installation process which will be less painful
than the other.  If you do so, please come back to us in some
days/weeks to find out if things are ready already.

Regards,

	Joey

-- 
All language designers are arrogant.  Goes with the territory...
	-- Larry Wall

Re: your mail

[Michael H. Warfield]

On Tue, Oct 02, 2001 at 03:29:45PM -0000, Dinesh  Gandhewar wrote:

> Hello,
> I have written a linux kernel module. The linux version is 2.2.14. 
> In this module I have declared an array of size 2048. If I use this
	array, the execution of this module function causes kernel to
	reboot. If I kmalloc() this array then execution of this module
	function doesnot cause any problem.
> Can you explain this behaviour?

	You didn't say how you declared the array or what the element
size was.  If the array elements were larger than a char, by saying an
array of size 2048, do you mean in bytes or in array elements?

	You also didn't say where you called your module from.  Was it
in an interrupt handler or at insmod time or from a system call.

	If it was a automatic array on the stack (declared inside the
function and not declared static), you probably overflowed the stack.

> Thnaks,
> Dinesh 

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Re: your mail

[Richard B. Johnson]

On 2 Oct 2001, Dinesh  Gandhewar wrote:

> 
> Hello,
> I have written a linux kernel module. The linux version is 2.2.14. 
> In this module I have declared an array of size 2048. If I use this
> array, the execution of this module function causes kernel to reboot.
> If I kmalloc() this array then execution of this module function
> doesnot cause any problem.
> Can you explain this behaviour?
> Thnaks,
> Dinesh 

I would check that you are not accidentally exceeding the bounds of
your array. Actual allocation occurs in page-size chunks. You may
be exceeding your 2048 byte-limit without exceeding the 4096-byte
page-size (of ix86).

However, a global array, or an array on the stack, has very strict
limits. You can blow things up on the stack by exceeding an array
boundary by one byte. And you can overwrite important memory objects
by exceeding the bounds of a global memory object.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: your mail

[Alan Cox]

> I have written a linux kernel module. The linux version is 2.2.14. 
> In this module I have declared an array of size 2048. If I use this array, the execution of this module function causes kernel to reboot. If I kmalloc() this array then execution of this module function doesnot cause any problem.
> Can you explain this behaviour?

Yes
--
Alan

[Oh wait you want to know why...]

Either

1.	You are using it for DMA
2.	You are putting it on the stack and causing a stack overflow

Re: your mail

[Francois Romieu]

The Sat, Aug 04, 2001 at 03:40:43PM +0430, Mahmoud Taghizadeh wrote :
[...]
> is there any linux distribution without memory managment unit?
> I mean, the paging is disabled and memory managemnt is done only
> by segmentation.

ELKS ?

-- 
Ueimor
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[Richard B. Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 505 bytes --]

On Tue, 24 Jul 2001, [gb2312] ÐÂ ÔÂ wrote:

> Hi:
> 	how does the kernel know which filesystem should be
> mounted as root filesytem?
> 

The Easter Bunny whispers in its ear.... Erm actually, check
/etc/lilo.conf for hints.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: your mail

[Jan Hudec]

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

Re: your mail

[Luigi Genoni]

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

Re: your mail

[Ralf Baechle]

On Fri, Jun 08, 2001 at 09:36:48AM +0800, jnn wrote:

>      somebody PLS tell me where can I find some documention about the mechanism of the cach flushing.

Right there in your kernel source, in Documentation/cachetlb.txt.  It
probably still leaves alot of questions open.

  Ralf
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: your mail

[H. Peter Anvin]

Followup to:  <200105312037.WAA01610@kufel.dom>
By author:    Andrzej Krzysztofowicz <kufel!ankry@green.mif.pg.gda.pl>
In newsgroup: linux.dev.kernel
> 
> BTW, linux-kernel readers: anybody is a volunteer for making the kernel size
> counter 32-bit here? This would enable using the simple bootloader for
> greater kernel loading...  (current limit is sligtly below 1MB)
> Possibly some 16/32-bit real mode code mixing would be necessary.
> 

PLEASE don't go there.  bootsect.S is fundamentally broken these days
(doesn't work on USB floppies, for example.)  It should be killed
DEAD, DEAD, DEAD and not dragged along like a dead albatross.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: your mail

[Andrzej Krzysztofowicz]

> 
> Minor issue with bootsect.s.

1. bootsect.S is the source file

> The single instance of the lds assembly instruction includes the comment of
> !  ds:si is source
> ...
> seg fs
> lds  si,(bx)        !     ds:si is source
> ...
> Is this comment not in reverse order (i.e should be lds
> dest,src)................

2. This is not a comment of i386 mnemonics. This comments the role of
   specific register in the following instructions.

BTW, linux-kernel readers: anybody is a volunteer for making the kernel size
counter 32-bit here? This would enable using the simple bootloader for
greater kernel loading...  (current limit is sligtly below 1MB)
Possibly some 16/32-bit real mode code mixing would be necessary.

Andrzej

Re: your mail

[Thomas Palm]

1. The corrupted files have the same length but differ (I cannot say on what
bit-position)
2. I reproduced the problem while burning CD from SCSI-Disk to
SCSI-CD-Burner!!!
-> It´s definetly not a (single?) IDE-Problem

Burning CD (on slow 4x speed) seems to initialize many small transfers
(instead of a smooth stream)(same as copying many small files) on PCI/DMA wich
generate the same problems!!!



> On Mon, 21 May 2001, Thomas Palm wrote:
> 
> > there ist still file-corruption. I use an ASUS A7V133 (Revision 1.05,
> > including Sound + Raid). My tests:
> > 1st run of "diff -r srcdir destdir" -> no differs
> > 2nd run of "diff -r srcdir destdir" -> 2 files differ
> > 3rd run of "diff -r srcdir destdir" -> 1 file differs
> > 4th run of "diff -r srcdir destdir" -> 1 file differs
> > 5th run of "diff -r srcdir destdir" -> no differs
> 
> Could you check WHERE the file differ and WHERE the data come from ?
> 
> I've got the same mobo AND some nasty DAT tape corruption problems...
> (also, VERY rarely, on the CD burner). I've got all on SCSI, but if it's
> the DMA troubling us...
> 
> 				-- Lorenzo Marcantonio
> 
> 

-- 
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a

--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: your mail

[Lorenzo Marcantonio]

On Mon, 21 May 2001, Thomas Palm wrote:

> there ist still file-corruption. I use an ASUS A7V133 (Revision 1.05,
> including Sound + Raid). My tests:
> 1st run of "diff -r srcdir destdir" -> no differs
> 2nd run of "diff -r srcdir destdir" -> 2 files differ
> 3rd run of "diff -r srcdir destdir" -> 1 file differs
> 4th run of "diff -r srcdir destdir" -> 1 file differs
> 5th run of "diff -r srcdir destdir" -> no differs

Could you check WHERE the file differ and WHERE the data come from ?

I've got the same mobo AND some nasty DAT tape corruption problems...
(also, VERY rarely, on the CD burner). I've got all on SCSI, but if it's
the DMA troubling us...

				-- Lorenzo Marcantonio

Re: your mail

[Erik Mouw]

On Wed, May 16, 2001 at 08:05:38AM -0700, siva prasad wrote:
> Is it true that the ipc calls like
> msgget(),shmget()...
> are  not really system calls?

No, they all use a system call, but the system call is the same for all
functions.

> Cos in the file "asm/unistd.h" where the
> system calls are listed as __NR_xxx we dont find
> the appropriate listing for the ipc calls.
> What I guessed was that all the ipc calls are
> clubbed under the 'int ipc()' system call and this
> is well listed in the "asm/unistd.h" 

Right, they all use __NR_ipc. See sys_ipc() in
arch/i386/kernel.sys_i386.c, especially the comment right above the
function...

> Could some one explain why the ipc is implemented 
> this way rather that implementing them as individual 
> system calls as in UNIX.

Probably because the original designer liked it this way and nobody
cared enough to do it otherwise.

> Or is it the same way in UNIX

I don't know, I don't have Unix source available.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: your mail

[Richard B. Johnson]

On Tue, 8 May 2001, Jens Axboe wrote:

> On Tue, May 08 2001, Richard B. Johnson wrote:
> > > Use a kernel thread? If you don't need to access user space, context
> > > switches are very cheap.
> > > 
> > > > So, what am I supposed to do to add a piece of driver code to the
> > > > run queue so it gets scheduled occasionally?
> > > 
> > > Several, grep for kernel_thread.
> > > 
> > > -- 
> > > Jens Axboe
> > > 
> > 
> > Okay. Thanks. I thought I would have to do that too. No problem.
> 
> A small worker thread and a wait queue to sleeep on and you are all set,
> 10 minutes tops :-)
> 
> > It's a "tomorrow" thing. Ten hours it too long to stare at a
> > screen.
> 
> Sissy!
> 

Okay. I am now awake. I will now try the kernel thread. Looks
simple. Got to remember to kill it before/during module removal.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: your mail

[Richard B. Johnson]

On Tue, 8 May 2001, Alan Cox wrote:

> > I have a driver which needs to wait for some hardware.
> > Basically, it needs to have some code added to the run-queue
> > so it can get some CPU time even though it's not being called.
> 
> Wht does it have to wait ? Why cant it just poll and come back next time ?
> 

Good question. I wanted to be able to call the exact same routine(s)
that other routines (exected from read() and write()), execute.
These routines are complex and sleep while waiting for events. I
didn't want to duplicate that code with different time-out mechanisms.

GPIB is nasty because you can't do anything unless the 'controller'
tells you to do it. When "addressed to talk", you have to parse
all the stuff sent via interrupt (ATN bit set, control byte, which
address from the control byte, etc.), then let somebody sleeping
in poll() know that they can now "write()". That can all be handled
via interrupt. But, now for the receive <grin>. The user-mode code
needs to be sleeping until some data are available. That data
may never be available. Something in the driver needs to wait
until the hardware is addressed to receive. Since it is not now
receiving, there is no interrupt! It takes time for the controller
to tell you to listen and then tell somebody else to talk to you.
This means that I need some timeout to recover from the fact
that the other guy may never talk.

Once the other guy starts sending data, the interrupts can be
used to handle the data and, once there are valid data, the
device owner can be awakened, presumably sleeping in poll() or
select(). It's the intermediate time where there are no
interrupts that needs the CPU to determine that we've waited
too long for interrupts so the device had better get off the
bus to start the error recovery procedure.

Bright an early tommorrow, I will check out both ways. A kernel
thread might be "neat". However, I may just look to see if
I can just poll while using existing code.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: your mail

[Alan Cox]

> I have a driver which needs to wait for some hardware.
> Basically, it needs to have some code added to the run-queue
> so it can get some CPU time even though it's not being called.

Wht does it have to wait ? Why cant it just poll and come back next time ?

Re: your mail

[Jens Axboe]

On Tue, May 08 2001, Richard B. Johnson wrote:
> > Use a kernel thread? If you don't need to access user space, context
> > switches are very cheap.
> > 
> > > So, what am I supposed to do to add a piece of driver code to the
> > > run queue so it gets scheduled occasionally?
> > 
> > Several, grep for kernel_thread.
> > 
> > -- 
> > Jens Axboe
> > 
> 
> Okay. Thanks. I thought I would have to do that too. No problem.

A small worker thread and a wait queue to sleeep on and you are all set,
10 minutes tops :-)

> It's a "tomorrow" thing. Ten hours it too long to stare at a
> screen.

Sissy!

-- 
Jens Axboe

Re: your mail

[Richard B. Johnson]

On Tue, 8 May 2001, Jens Axboe wrote:

> On Tue, May 08 2001, Richard B. Johnson wrote:
> > 
> > To driver wizards:
> > 
> > I have a driver which needs to wait for some hardware.
> > Basically, it needs to have some code added to the run-queue
> > so it can get some CPU time even though it's not being called.
> > 
> > It needs to get some CPU time which can be "turned on" or
> > "turned off" as a result of an interrupt or some external
> > input from  an ioctl().
> > 
> > So I thought that the "tasklet" would be ideal. However, the
> > scheduler "thinks" that a tasklet is an interrupt, so any
> > attempt to sleep in the tasklet results in a kernel panic,
> > "ieee scheduling in an interrupt..., BUG sched.c line 688".
> 
> Use a kernel thread? If you don't need to access user space, context
> switches are very cheap.
> 
> > So, what am I supposed to do to add a piece of driver code to the
> > run queue so it gets scheduled occasionally?
> 
> Several, grep for kernel_thread.
> 
> -- 
> Jens Axboe
> 

Okay. Thanks. I thought I would have to do that too. No problem.
It's a "tomorrow" thing. Ten hours it too long to stare at a
screen.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: your mail

[Jens Axboe]

On Tue, May 08 2001, Richard B. Johnson wrote:
> 
> To driver wizards:
> 
> I have a driver which needs to wait for some hardware.
> Basically, it needs to have some code added to the run-queue
> so it can get some CPU time even though it's not being called.
> 
> It needs to get some CPU time which can be "turned on" or
> "turned off" as a result of an interrupt or some external
> input from  an ioctl().
> 
> So I thought that the "tasklet" would be ideal. However, the
> scheduler "thinks" that a tasklet is an interrupt, so any
> attempt to sleep in the tasklet results in a kernel panic,
> "ieee scheduling in an interrupt..., BUG sched.c line 688".

Use a kernel thread? If you don't need to access user space, context
switches are very cheap.

> So, what am I supposed to do to add a piece of driver code to the
> run queue so it gets scheduled occasionally?

Several, grep for kernel_thread.

-- 
Jens Axboe

Re: your mail

[Erik Mouw]

On Mon, May 07, 2001 at 05:08:43PM +0530, Chandrashekar Nagaraj wrote:
> 	i want to know how to read tab without a terminating character,
> ie., if i use getchar() i have to enter '\n' after tab to read tab,
> same is the case with read system call and scanf. 

This is off topic for this list, but anyway.

Read man cfmakeraw, and/or get a copy of "Advanced programming in the
UNIX environment" by W. Richard Stevens.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: your mail

[Linus Torvalds]

On Wed, 2 May 2001, Duc Vianney wrote:
>
> Has anyone seen performance degradations between 2.2.19 and 2.4.x

Yes.

The signal handling one is because 2.4.x will save off the full SSE2
state, which means that the signal stack is almost 700 bytes, as compared
to <200 before. This is sadly necessary to be able to take advantage of
the SSE2 instructions - and on special applications the win can be quite
noticeable. This one you won't be able to avoid, although you shouldn't
see it on older hardware that do not have SSE2 (you see it because you
have a PIII).

You don't say how much memory you have, but the file handling ones might
be due to a really unfortunate hash thinko that cause the dentry hash to
be pretty much useless on machines that have 512MB of RAM (it can show up
in other cases, but 512M is the case that makes the hash really become a
non-hash). If so, it should be fixed in 2.4.2.

2.4.4 will give noticeably better numbers for fork and fork+exec. However,
the scheduling optimization that does that actually breaks at least
"bash", and it appears that we will just undo it during the stable series.
Even if the bug is obviously in user land (and a fix is available), stable
kernels shouldn't try to hide the problems.

			Linus

Re: your mail

[Joel Jaeggli]

yeah two hour upgrade window today...

joelja

On Thu, 26 Apr 2001, Alexandru Barloiu Nicolae wrote:

> is ftp.kernel.org down or is just my connections fault ?
>
> axl
>
>
> ______________________________________________________
> support slackware anyway posible paypal@slackware.com anyone ?
>    http://www.slackware.com/forum/read.php?f=5&i=7887&t=7887
>
>
> -
> 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/
>

-- 
--------------------------------------------------------------------------
Joel Jaeggli				       joelja@darkwing.uoregon.edu
Academic User Services			     consult@gladstone.uoregon.edu
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.

Re: your mail

[Mohammad A. Haque]

Down for maint.


On Thu, 26 Apr 2001, Alexandru Barloiu Nicolae wrote:

> is ftp.kernel.org down or is just my connections fault ?
>

-- 

=====================================================================
Mohammad A. Haque                              http://www.haque.net/
                                               mhaque@haque.net

  "Alcohol and calculus don't mix.             Project Lead
   Don't drink and derive." --Unknown          http://wm.themes.org/
                                               batmanppc@themes.org
=====================================================================

Re: your mail

[Erik Mouw]

On Thu, Apr 26, 2001 at 10:37:32PM +0300, Alexandru Barloiu Nicolae wrote:
> is ftp.kernel.org down or is just my connections fault ?

Yes, scheduled downtime. Use your local mirror (ftp.ro.kernel.org).


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: your mail

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Mon, Apr 02, 2001 at 09:20:43PM +0200, Jakob Kemi wrote:

> Ok, maybe this isn't the right list for this question. In 2.2.x the
> parport_probe module extracted the ieee1284 device id correctly and
> added to the proc fs. However this doesn't seem to work for me in
> 2.4.x

It changed place: perhaps that's the problem?  /proc/parport/$n is now
/proc/sys/dev/parport/$name.

> Is there some option I need to enable. As far as I understand the
>  CONFIG_PARPORT_1284 should be enough??

Yes, it should.

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: your mail

[Ralf Baechle]

On Wed, Apr 04, 2001 at 04:37:47PM -0500, Matthew Fredrickson wrote:

> > hello,
> > Yeah i am trying to compile it while running Irix 6.5. Once i get it all 
> > working I was going to boot into it. Does that make sense?
> > james
> 
> <g>No offense, but not really.  Actually, you'll probably need to start
> off by setting up the x86-mips cross compilers on an x86 linux machine of
> yours and booting the kernel via tftp over the network to get started.  I
> think most of this is covered in the FAQ on the site.  Anyway, I don't
> think it's _ever_ been supported to compile up the kernel in IRIX anyway,
> so your kind of out of luck for that.

You obvious didn't even check.  I assure you that I rarely compile a MIPS
kernel under Linux so if that works, it's coincidental.  Crosscompiling
on IRIX works just fine.

  Ralf

Re: your mail

[Matthew Fredrickson]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

On Wed, Apr 04, 2001 at 05:29:54PM -0700, jsc6233@ritvax.isc.rit.edu wrote:
> 
> hello,
> Yeah i am trying to compile it while running Irix 6.5. Once i get it all 
> working I was going to boot into it. Does that make sense?
> james

<g>No offense, but not really.  Actually, you'll probably need to start
off by setting up the x86-mips cross compilers on an x86 linux machine of
yours and booting the kernel via tftp over the network to get started.  I
think most of this is covered in the FAQ on the site.  Anyway, I don't
think it's _ever_ been supported to compile up the kernel in IRIX anyway,
so your kind of out of luck for that.  On a side note, you probably want
to stop by freeware.sgi.com and upgrade your gcc from 2.7 to the latest
(2.95.3 I think).  Might even try downloading some pre3.0 stuff and try
that out.  Back to topic:  Read EVERYTHING you can on the linux-mips sgi
site before asking a question here;  if you don't, that's a very good way
to get kindly (and a lot of times unkindly) pointed to the FAQ.  Hope this
helps.

-- 
Matthew Fredrickson AIM MatthewFredricks
ICQ 13923212 matt@NOSPAMfredricknet.net 
http://www.fredricknet.net/~matt/
"Everything is relative"

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: your mail

[Stephen Smalley]

The kernel patch is based on the stock kernel sources from
www.kernel.org or its mirrors.  The current release provides
patches for kernel versions 2.2.18 and 2.4.2, although the
2.2-based patch is no longer being actively developed.

--
Stephen D. Smalley, NAI Labs
sds@tislabs.com


On Fri, 23 Mar 2001, frenzy@frenzy.org wrote:

> It was my understanding that the kernel patch was only made for the
> supplied kernel that comes with RH6.1
> I could be completely wrong here however. The last one I tried it with was
> 2.2.17-14smp, which also failed to compile.
> Sincerely,
> 
> Randy McCleland-Bane
> http://www.frenzy.org -- Administrator
> MSN: drekbot@hotmail.com ICQ: 32276169
> EM: frenzy@frenzy.org,mcclellr@oit.edu
> "We must be the change we wish to see 
> in the world." - Mahatma Gandhi   
> PGP key: http://www.frenzy.org/frenzy/
> frenzy_at_frenzy.org.asc.txt
> 
> On Fri, 23 Mar 2001, Hubertus Franke wrote:
> 
> just downloaded the SELinux for 2.4.
> 
> I did the ./tools/build-kernel  and get the following errors.
> 
> 
> /home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
> linux/flask/flask.h: No such file or directory
> 
> 
> /home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
> config/flask/audit.h: No such file or directory
> 
> Looks like various files are missing in the distribution.
> Any ideas ?
> 
> 
> Hubertus Franke
> Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
> , OS-PIC (Chair)
> email: frankeh@us.ibm.com
> (w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003
> 
> 
> 
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
> 
> 
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
> 


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[Stephen Smalley]

These header files should be automatically generated during
the build.  I just tried again with a clean copy of the release
on my RedHat 6.1 system, and it built without any problems.
Try expanding a clean copy of the release and building the
kernel by hand rather than using the build-kernel script, i.e.

tar xzf slinux-200103151617-release.tgz
cd slinux
ln -sf kernel-2.4 kernel
cd kernel
make xconfig or make menuconfig or make config
	(Configure the kernel appropriately.)
make dep
make 
make modules

--
Stephen D. Smalley, NAI Labs
sds@tislabs.com


On Fri, 23 Mar 2001, Hubertus Franke wrote:

> just downloaded the SELinux for 2.4.
> 
> I did the ./tools/build-kernel  and get the following errors.
> 
> 
> /home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
> linux/flask/flask.h: No such file or directory
> 
> 
> /home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
> config/flask/audit.h: No such file or directory
> 
> Looks like various files are missing in the distribution.
> Any ideas ?
> 
> 
> Hubertus Franke
> Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
> , OS-PIC (Chair)
> email: frankeh@us.ibm.com
> (w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003
> 
> 
> 
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
> 


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[Hubertus Franke]

That's not what the website said. I actually downloaded
(a) the full version
(b) the full 2.4.2 patched kernel
(c) and the patch itself.

All have the same problem. The trick with dobule compile didn't work for
me.
I do run on Redhat 7.0.

Hubertus Franke
Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003



"frenzy@frenzy.org" <mcclellr@OIT.EDU>@tycho.nsa.gov on 03/24/2001 02:26:49
AM

Sent by:  owner-selinux@tycho.nsa.gov


To:
cc:   SELinux@tycho.nsa.gov
Subject:  Re: your mail



It was my understanding that the kernel patch was only made for the
supplied kernel that comes with RH6.1
I could be completely wrong here however. The last one I tried it with was
2.2.17-14smp, which also failed to compile.
Sincerely,

Randy McCleland-Bane
http://www.frenzy.org -- Administrator
MSN: drekbot@hotmail.com ICQ: 32276169
EM: frenzy@frenzy.org,mcclellr@oit.edu
"We must be the change we wish to see
in the world." - Mahatma Gandhi
PGP key: http://www.frenzy.org/frenzy/
frenzy_at_frenzy.org.asc.txt

On Fri, 23 Mar 2001, Hubertus Franke wrote:

just downloaded the SELinux for 2.4.

I did the ./tools/build-kernel  and get the following errors.


/home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
linux/flask/flask.h: No such file or directory


/home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
config/flask/audit.h: No such file or directory

Looks like various files are missing in the distribution.
Any ideas ?


Hubertus Franke
Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003



--
You have received this message because you are subscribed to the selinux
list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
the words "unsubscribe selinux" without quotes as the message.


--
You have received this message because you are subscribed to the selinux
list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
the words "unsubscribe selinux" without quotes as the message.




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[frenzy@frenzy.org]

It was my understanding that the kernel patch was only made for the
supplied kernel that comes with RH6.1
I could be completely wrong here however. The last one I tried it with was
2.2.17-14smp, which also failed to compile.
Sincerely,

Randy McCleland-Bane
http://www.frenzy.org -- Administrator
MSN: drekbot@hotmail.com ICQ: 32276169
EM: frenzy@frenzy.org,mcclellr@oit.edu
"We must be the change we wish to see 
in the world." - Mahatma Gandhi   
PGP key: http://www.frenzy.org/frenzy/
frenzy_at_frenzy.org.asc.txt

On Fri, 23 Mar 2001, Hubertus Franke wrote:

just downloaded the SELinux for 2.4.

I did the ./tools/build-kernel  and get the following errors.


/home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
linux/flask/flask.h: No such file or directory


/home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
config/flask/audit.h: No such file or directory

Looks like various files are missing in the distribution.
Any ideas ?


Hubertus Franke
Enterprise Linux Group (Mgr),  Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
email: frankeh@us.ibm.com
(w) 914-945-2003    (fax) 914-945-4425   TL: 862-2003



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[gawain.lynch]

> > /home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
> > linux/flask/flask.h: No such file or directory
> > /home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
> > config/flask/audit.h: No such file or directory
> > 
> > Looks like various files are missing in the distribution.
> > Any ideas ?

>                The header files get auto-created by the build, but 
they're not
> there when make dep is run, so you get all the errors, but the Kernel 
does
> compile.

I am having the same issue with the current release, I let 
tool/build-kernel run twice, but both times it exits with the error below:

        In file included from /usr/include/errno.h:36,
                         from scripts/split-include.c:26:
        /usr/include/bits/errno.h:25: linux/errno.h: No such file or 
directory
        make: *** [scripts/split-include] Error 1

I have also tried patching fresh source here and I get the same issues.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[Chris Crowther]

On Fri, 23 Mar 2001, Hubertus Franke wrote:

> /home/frankeh/slinux/kernel/include/linux/flask/avc.h:13:31:
> linux/flask/flask.h: No such file or directory
> /home/frankeh/slinux/kernel/include/linux/flask/security.h:49:32:
> config/flask/audit.h: No such file or directory
> 
> Looks like various files are missing in the distribution.
> Any ideas ?

	The header files get auto-created by the build, but they're not
there when make dep is run, so you get all the errors, but the Kernel does
compile.

-- 
Chris "_Shad0w_" Crowther
shad0w@shad0w.org
http://www.shad0w.org.uk/



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: your mail

[Tim Wright]

Hmmm...
you don't really give enough information to make much of a guess.
I'd do the following:
Grab at least 2.2.18, or even better, get Alan's 2.2.19pre (which is almost
2.2.19 now, I believe), and build and install that kernel.

Now, if you run into the same problems, record the crash details, especially
if the kernels oopses, and then send the information (kernel version, output
of ksymoops if there is an oops, kernel .config used etc.) to the mailing list.

Tim

On Sat, Mar 24, 2001 at 05:34:39AM +0530, dhar wrote:
> Hi,
> 
> I am not a member of either of these lists and would appreciate if you could send your replies to me personally.
> 
> Now the problem:
> 
> I have an IBM Netfinity X330 server. Dual Processor (PIII 800). I compiled kernel 2.2.14 with SMP support. NFS was however compiled as a module. 
> 
> Now the problem is as follows:
> 
> Most of the times the machine just works fine. 
> But whenever there is heavy disk write activity it just hangs/crashes. Also this is when the SMP kernel is used. If I use the normal kernel then there is no problem. 
> 
> Could any one tell me what has to be done to prevent this from happening? 
> 
> Any help in this regard will be very much appreciated.
> 
> Once again, kindly reply to me personally as I am not a member of either of these lists.
>  
> Regards
> Dhar 
> 
> -
> 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/

-- 
Tim Wright - timw@splhi.com or timw@aracnet.com or twright@us.ibm.com
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI

Re: your mail

[Robert Read]

On Sun, Mar 11, 2001 at 09:03:09PM -0800, Greg KH wrote:
> On Sun, Mar 11, 2001 at 06:06:24PM +0100, Martin Bruchanov wrote:
> > 
> > Bug report from Martin Bruchanov (bruxy@kgb.cz, bruchm@racom.cz)
> > 
> > ############################################################################
> > [1.] One line summary of the problem:    
> > USB doesn't work properly with SMP kernel on dual-mainboard or with APIC.
> 
> What kind of motherboard is this?
> 

>From the lspci output, looks like I have the same mainboard or at
least one with an identical chipset. I've got an MSI 694D Pro
Mainboard with 694X VIA chipset, with 2 cpus installed, and I had the
same USB problem with 2.4.0, but haven't had time to test it on a
recent kernel.

robert

> And does USB work in SMP mode with "noapic" given on the kernel command
> line?
> 
> thanks,
> 
> greg k-h
> 
> -- 
> greg@(kroah|wirex).com
> http://immunix.org/~greg
> -
> 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/

Re: your mail

[Greg KH]

On Sun, Mar 11, 2001 at 06:06:24PM +0100, Martin Bruchanov wrote:
> 
> Bug report from Martin Bruchanov (bruxy@kgb.cz, bruchm@racom.cz)
> 
> ############################################################################
> [1.] One line summary of the problem:    
> USB doesn't work properly with SMP kernel on dual-mainboard or with APIC.

What kind of motherboard is this?

And does USB work in SMP mode with "noapic" given on the kernel command
line?

thanks,

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg

Re: your mail

[Don Dugger]

Ying-

I'm a little confused here.  It's very hard to compare a UP application
vs. the same app. converted to use threads.  Unless the app. is
structured such that multiple threads can run at the same time then
no, you won't see any improvement by going to SMP, in fact a true
single threaded app. will frequently slow down when run on an SMP
kernel.

Have you watched a CPU meter while your benchmark runs?  Even something
basic like `top' should give you a feel for whether or not your
using all of the CPU's.


On Tue, Mar 06, 2001 at 03:55:55PM -0800, Ying Chen wrote:
> Hi,
> 
> I have two questions on Linux pthread related issues. Would anyone be able 
> to help?
> 
> ...
>
> 2. We ran multi-threaded application using Linux pthread library on 2-way 
> SMP and UP intel platforms (with both 2.2 and 2.4 kernels). We see 
> significant increase in context switching when moving from UP to SMP, and 
> high CPU usage with no performance gain in turns of actual work being done 
> when moving to SMP, despite the fact the benchmark we are running is 
> CPU-bound. The kernel profiler indicates that the a lot of kernel CPU ticks 
> went to scheduling and signaling overheads. Has anyone seen something like 
> this before with pthread applications running on SMP platforms? Any 
> suggestions or pointers on this subject?
> 
> Thanks a lot!
> 
> Ying
> 
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> -
> 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/

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@valinux.com
Ph: 303/938-9838

Re: your mail

[Geert Uytterhoeven]

On Wed, 14 Feb 2001, Deepa  Suresh wrote:
> We have a QED based MIPs processor, running Linux 2.4-test6. 
> We use our own graphics card.
> We want to get X/display up on this board. WE have a frame buffer driver
> written
> for the same card running on x86 Linux version and running X using
> XFBDev server.

Does the frame buffer driver you wrote for x86 Linux relies on the card being
initialised by the video BIOS on the card? If not, it'll work out-of-the-box.
If yes, you'll have to make sure a similar initialization is done on the MIPS
platform.

> I want to know if we can reuse the same driver for mips also?
> In the case of i386 Linux, fbcon.c and fbmem.c do most of the
> processing before giving control to the corresponding graphics card.
> 
> In mips port can we use the same fbcon.c and fbmem.c functionality 
> with our graphics driver. Is this enough for X to come up
> without any problems. (i have seen sgi using newport_con , can we use
> fb_con itself instead , what are the problems?)

Fbmem and fbcon should work fine. They are not architecture specific.

And if these work, XF{68,86}_FBDev should work as well.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

Re: your mail

[Steve Hill]

On Fri, 19 Jan 2001, RobertKaiser wrote:

> On Thu Jan 18 16:30:30 2001 steve@navaho.co.uk wrote
> > Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86
> > hardware?  It doesn't even seem to start (I get nothing on the screen from
> >t he kernel, it just sits there and does nothing). :(
> 
> What processor does it use ? (386 or 486 perchance?)

AMD K6 (so 586) - I was trying the i386 version of the kernel on it
though, if that's going to be a problem, I can try the 586 version...

-- 

- Steve Hill
System Administrator         Email: steve@navaho.co.uk
Navaho Technologies Ltd.       Tel: +44-870-7034015

        ... Alcohol and calculus don't mix - Don't drink and derive! ...


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

Re: your mail

[David Hinds]

On Wed, Jan 10, 2001 at 04:24:21PM -0200, Thiago Rondon wrote:
> 
> Check kmalloc().
> 
> -Thiago Rondon
> 
> --- linux-2.4.0-ac5/drivers/pcmcia/ds.c	Sat Sep  2 04:13:49 2000
> +++ linux-2.4.0-ac5.maluco/drivers/pcmcia/ds.c	Wed Jan 10 16:20:53 2001
> @@ -414,6 +414,8 @@
>      /* Add binding to list for this socket */
>      driver->use_count++;
>      b = kmalloc(sizeof(socket_bind_t), GFP_KERNEL);
> +    if (!b) 
> +      return -ENOMEM;    
>      b->driver = driver;
>      b->function = bind_info->function;
>      b->instance = NULL;
> 

As with the other kmalloc patch, this is also broken; things have been
done that need to be un-done, and you can't just exit the function
here.  I'll come up with a better fix.

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

Re: your mail

[Maciej W. Rozycki]

On Thu, 4 Jan 2001, Joe deBlaquiere wrote:

> It was meant as a workaround...
> 
> Perhaps we could have an option to objcopy that would allow you to copy 
> the addresses without sign extension?

 Please do either implement a clean solution or wait until someone else
(possibly me) does.  We don't want any more hacks -- MIPS/Linux already
has enough of them.  This is my view of the situation at present. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: your mail

[Joe deBlaquiere]

Ralf Baechle wrote:

> On Thu, Jan 04, 2001 at 10:40:41AM -0600, Joe deBlaquiere wrote:
> 
> If you're really only doing 32-bit mips you might consider removing the 
>> 64 bit targets in the config.bfd... I think that will solve the problems.
> 
> 
> Doesn't really solve the problem.  For example on an Origin we have a 32-bit
> userland but 64-bit kernel addresses which confuses ksymops and procps.
> 
>   Ralf


It was meant as a workaround...

Perhaps we could have an option to objcopy that would allow you to copy 
the addresses without sign extension?

Joe

Re: your mail

[Maciej W. Rozycki]

On Thu, 4 Jan 2001, Joe deBlaquiere wrote:

> If the BFD stuff is built with any support for 64 bit (even as an 
> optional target) it will maintain all addresses as 64-bit values, even 
> if the file is 32 bit.

 I do consider it fine BFD handles all addresses as 64-bit internally.  I
just think it should truncate them to 32-bits upon printing (and always
whenever appropriate) when the selected target is 32-bit.  It does so (it
has to!) for output anyway, so what's the deal? 

> If you're really only doing 32-bit mips you might consider removing the 
> 64 bit targets in the config.bfd... I think that will solve the problems.

 Nope, I insist 32-bit targets need to work correctly regardless of
whether there are any 64-bit ones supported by a particular BFD binary or
not.  Do you think elf32-i386 should switch to printing 64-bit addresses
if elf64-alpha is also supported by a given configuration of BFD?  I
don't.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: your mail

[Ralf Baechle]

On Thu, Jan 04, 2001 at 10:40:41AM -0600, Joe deBlaquiere wrote:

> There is a bug in that "some" newer versions of objcopy will not allow 
> you to translate these sign-extended 32 bit addresses into Intel Hex 
> format.

I couldn't care less ...

> If you're really only doing 32-bit mips you might consider removing the 
> 64 bit targets in the config.bfd... I think that will solve the problems.

Doesn't really solve the problem.  For example on an Origin we have a 32-bit
userland but 64-bit kernel addresses which confuses ksymops and procps.

  Ralf

Re: your mail

[Joe deBlaquiere]

If the BFD stuff is built with any support for 64 bit (even as an 
optional target) it will maintain all addresses as 64-bit values, even 
if the file is 32 bit.

There is a bug in that "some" newer versions of objcopy will not allow 
you to translate these sign-extended 32 bit addresses into Intel Hex 
format.

If you're really only doing 32-bit mips you might consider removing the 
64 bit targets in the config.bfd... I think that will solve the problems.

Maciej W. Rozycki wrote:

> On Thu, 4 Jan 2001, Ralf Baechle wrote:
> 
> 
>>> I see that our start address of 0x80102584 has been turned into
>>> 0xffffffff80102584. I'm thinking that
>>> I need to tell ld something to stop it from doing this. Any ideas?
>> 
>> That's be ok.  32-bit MIPS addresses are sign-extended into 64-bit addresses.
>> Older binutils used to zero-extend addresses which was broken.  So what
>> you observe is actually the sympthom of a bug that got fixed.
> 
> 
>  I'm not sure that's the best solution, I'm afraid.  For elf32-mips
> addresses should be 32-bit and not 64-bit.  It would be consistent with
> other 32-bit platforms, it would make interoperability easier (ksymoops
> cannot make use of System.map to grok kernel oopses which provide 32-bit
> addresses) and it would make objdump outputs more readable.
> 
>  Fixing this problem with BFD is on my to do list (but has a low priority
> assigned). 

Re: your mail

[Maciej W. Rozycki]

On Thu, 4 Jan 2001, Ralf Baechle wrote:

> > I see that our start address of 0x80102584 has been turned into
> > 0xffffffff80102584. I'm thinking that
> > I need to tell ld something to stop it from doing this. Any ideas?
> 
> That's be ok.  32-bit MIPS addresses are sign-extended into 64-bit addresses.
> Older binutils used to zero-extend addresses which was broken.  So what
> you observe is actually the sympthom of a bug that got fixed.

 I'm not sure that's the best solution, I'm afraid.  For elf32-mips
addresses should be 32-bit and not 64-bit.  It would be consistent with
other 32-bit platforms, it would make interoperability easier (ksymoops
cannot make use of System.map to grok kernel oopses which provide 32-bit
addresses) and it would make objdump outputs more readable.

 Fixing this problem with BFD is on my to do list (but has a low priority
assigned). 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: your mail

[Ralf Baechle]

On Wed, Jan 03, 2001 at 05:36:44PM -0800, John Van Horne wrote:

> First, while the kernel builds just fine, when we use objcopy to convert the
> elf image into a binary
> image which we can download to our target, objcopy fails with warnings
> saying that it is writing
> sections to huge (i.e. negative) file offsets. When I use objdump to analyze
> the kernel image,
> I see that our start address of 0x80102584 has been turned into
> 0xffffffff80102584. I'm thinking that
> I need to tell ld something to stop it from doing this. Any ideas?

That's be ok.  32-bit MIPS addresses are sign-extended into 64-bit addresses.
Older binutils used to zero-extend addresses which was broken.  So what
you observe is actually the sympthom of a bug that got fixed.

> Second, the way we build our application, we first create a partially linked
> image, with the -r flag. Then 
> we run ld on this (and an additional object file). When we do this with the
> tools from cross-all-001027
> we get the following error on the second link step:
> 
> mips-linux-ld:  BFD internal error, aborting at
> /homes/local/mips-cross/crossdev-build/src/binutils-001027/bfd/elf32-mips.c
> line 6942 in _bfd_mips_elf_relocate_section
> 
> mips-linux-ld: Please report this bug.

Not good ...  Two possibilities.

 - it's fairly easy to make ld die in funny ways by feeding it with nonsense
   options, linker scripts or similar.
 - it's really a bug.

Assuming it's really a bug, can you extract a small test case that
demonstrate this bug?

> Actually, on the application we didn't get this far using
> binutils-mips-linux-2.8.1 and egcs-mips-linux-1.0.3a,
> so I have nothing to compare it to.  I'm not sure if this is a bug or if I
> should be passing some flags to gcc or ld.

It may well be a bug; especially -r is used relativly rarely so the code
isn't getting excercised too well.  I'd like to see it get fixed in the
current linker, though.

  Ralf

Re: your mail

[Alan Cox]

> sigp. To synchronize n CPUs one can create n kernel threads and give
> them a high priority to make sure they will be executed soon (e.g. by
> setting p->policy to SCHED_RR and p->rt_priority to a very high
> value). As soon as all CPUs are in synchronized state (with
> interrupts disabled) the new CPU can be started. But before this can
> be done there are some other things left to do:

You dont IMHO need to use such a large hammer. We already do similar sequences
for tlb invalidation on X86 for example. You can broadcast an interprocessor
interrupt and have the other processors set a flag each. You spin until they
are all captured, then when you clear the flag they all continue. You just
need to watch two processors doing it at the same time 8)

Alan

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

Re: your mail

[Rik van Riel]

On Mon, 4 Sep 2000, Sahil wrote:

> I am a newbie to kernel programming.
> can anyone suggest some good readings for the same?

http://kernelnewbies.org/
http://www.linux.eu.org/Linux-MM/

cheers,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: your mail

[Matthew Wilcox]

On Fri, Jul 21, 2000 at 01:06:33PM -0500, borislav dzodzo wrote:
> hi i found some of your posts on 
> http://puffin.external.hp.com/mailing-lists/parisc-linux/2000/
> and i thought you might know if 
> there already exists a linux version of fsck for 
> under pa-risc for HFS (not apple but HewlettPackard).

HP's HFS is a BSD Fast Filesystem (FFS) derivative.  There are a few
minor differences, but they are very closely related.  By studying the
HP-specific magic numbers added to recent 2.3/4 series kernels, you should
have no problem making a fsck.ufs or fsck.ffs work on Linux.  If anyone
can find one, let me know, and a mkfs would also be useful to have.

> if not... could you please tell me where are some good specs on
> HFS so that i could write my own.

-- 
Revolutions do not require corporate support.

Re: your mail

[Gabriel Paubert]

On Thu, 13 Jul 2000, Crusman wrote:

> >The configurations I have are for 2600 with a PMC graphics board, remove
> >CONFIG_VT from the setup and it will use a serial console.
> >
> >BTW use PrePboot for these boards (CONFIG_PREPBOOT) since it gives a nicer
> >PCI layout to access the VMEbus...
> >
> >Please use the patches mvme2600.*.bz2...
>
> I have tested the patches but the new kernel don't see the scsi device...so
> I can't try it anyway !

Did you try the nfsroot (or nfsinstall but it's probably broken now) ? The
nfsroot does not have any CONFIG_VT set so it should work. At least it
works on headless 2600 and 2400.

> Yes, I have tested your kernel, but there is a message ( PC keyb error... or
> something like this) wich lock the kernel during the boot ! It's probably
> due to the Virtual Terminal support in the kernel !
> I always use the "console=ttyS0,9600" kernel option.

Then it should not do this, I don't know what happens. AFAIR it works on
MVME2400 whcih don't have the KB controller either.

> In short :
>
> - I can't use your kernel because of the PC_key error !
> - I can't patch & build a new kernel because this new kernel don't see my
> SCSI PMC !

Did you ever see the PMC module with some kernel ? Once booted (an nfsrrot
system is the best for this), see what you have in /proc/bus/pci.

	Gabriel.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: your mail

[Stephen C. Tweedie]

Hi,

On Tue, Mar 28, 2000 at 01:49:04PM +0530, pnilesh@in.ibm.com wrote:
> 
> No, if both processes have faulted in the page into their ptes, it will
> be 2.

3.  The page cache counts as a reference.

> One more thing if the process ocurrs a page fault on text page it calls
> file_no_page()
> From what you said in this case it should increment the page count but in
> this function no where I could see the page count getting incremented.

It is done implicitly when filemap_nopage() looks for the page in the
page cache: __find_page() increments the reference count of any page
it finds before returning.

> The David Rusling book says when reducing page cache and buffer cache the
> page table entries are not modified and the pages can be dropped directly.

Yes, but it checks the page reference count to make sure it is legal to
do so first.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: your mail

[pnilesh]

No, if both processes have faulted in the page into their ptes, it will
be 2. The page count is normally the number of references from user
ptes, plus any long/short term holds kernel code establishes on the
page.

I was confused as Maurice Bach increases region reference count when any
region say text is shared among more than one processes, and not the page
reference count.

One more thing if the process ocurrs a page fault on text page it calls
file_no_page()
>From what you said in this case it should increment the page count but in
this function no where I could see the page count getting incremented.


>
> Q    When a page of a file is in page hash queue, does this page have
page
> table entry in any process ?

Possibly, if the file is mmaped into some other process.

> Q     Can this be discarded right away , if the need arises?
>
At the minimum, you need to write modified contents back to disk, if
the file page has not already been discarded.

The David Rusling book says when reducing page cache and buffer cache the
page table entries are not modified and the pages can be dropped directly.

Kanoj

> Nilesh Patel
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux.eu.org/Linux-MM/
>




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: your mail

[Jason Gunthorpe]

On Fri, 9 Jul 1999, D. Jeff Dionne / VE3DJF wrote: 

> > Can you fire over your patch to ROMfs to make it do this? The 2.2.10
> > kernel version doesn't. 
> 
> Unfortunately, in it's current form it will not be of any use to you I suspect.
> It's for 2.0.37, and is tied up with another meg of patch.  It touches lots
> of stuff, and it needs cleaning :-(
> 
> We're also very 68k right now, so Linux/Intel would be some work.  You'll
> need fully position independant code to start with... Does -fpic go far enough
> on Intel?  You'll need to hack the ELF loader, we run a simple (low overhead)
> binary format.

Oh this is not at all what I was thinking, on Intel all we'd need to do is
setup the proper page tables so that each 4k page mapped to the correct 4k
chunk of flash, the FFS write unit size and alignment would be set to 4k
for executables. There should be no need to worry about pic and elf will
run fine like that too.
 
It should be really simple if someone can think up either a modification
to readpage() that adjusts the physical  location of the given page
structure or a new mmap that sets up a new page table mapping..

Jason



To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

Re: your mail

[D. Jeff Dionne / VE3DJF]

> 
> On Thu, 8 Jul 1999, David Woodhouse wrote:
> 
> > > Anyway, having come over from the uClinux project, I am very
> > > interested in anything you may have.  I can also lend a hand.  We've
> > > had XIP from FLASH now for about a year, but are stuck using ROMfs
> > > (which as you know is read only). 
> 
> Can you fire over your patch to ROMfs to make it do this? The 2.2.10
> kernel version doesn't. 

Unfortunately, in it's current form it will not be of any use to you I suspect.
It's for 2.0.37, and is tied up with another meg of patch.  It touches lots
of stuff, and it needs cleaning :-(

We're also very 68k right now, so Linux/Intel would be some work.  You'll
need fully position independant code to start with... Does -fpic go far enough
on Intel?  You'll need to hack the ELF loader, we run a simple (low overhead)
binary format.

>   
> > We don't have XIP. We _do_ have FTL, and are working on FFS2. The situation is 
> > something like this:
> 
> I have read only ffs2 running, but the hair brained compression scheme is
> giving me pain :<
> 
> On lwn there was a pointer to a Hard Hat linux which also claimed flash
> support with a flash file system, anyone know more about those guys?
> 
> Jason
> 



To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

Re: your mail

[Jason Gunthorpe]

On Thu, 8 Jul 1999, David Woodhouse wrote:

> > Anyway, having come over from the uClinux project, I am very
> > interested in anything you may have.  I can also lend a hand.  We've
> > had XIP from FLASH now for about a year, but are stuck using ROMfs
> > (which as you know is read only). 

Can you fire over your patch to ROMfs to make it do this? The 2.2.10
kernel version doesn't. 
  
> We don't have XIP. We _do_ have FTL, and are working on FFS2. The situation is 
> something like this:

I have read only ffs2 running, but the hair brained compression scheme is
giving me pain :<

On lwn there was a pointer to a Hard Hat linux which also claimed flash
support with a flash file system, anyone know more about those guys?

Jason



To unsubscribe, send "unsubscribe mtd" to majordomo@imladris.demon.co.uk

Re: your mail

[Bill Nottingham]

jason (rohwedde@uiuc.edu) said: 
> Does anyone know how to make a pci card with a ensoniq es1370 chipset on it
> work with linux??  It came out of a gateway.. thanks for any help

You should just be able to use the es1370 driver, either the one
in the standard 2.2 kernel or in the ALSA project.

Bill

Re: your mail

[David Edelsohn]

>>>>> Gabriel Paubert writes:

Gabriel> Ok, better like this. Unfortunately for rlwinm and friends, gas allows you
Gabriel> to replace the last 2 parameters by a single value (bit mask), for
Gabriel> example: rlwinm r3,r4,0, 0x00ffff00, but it does not work if you have the
Gabriel> complementary mask (ones, zeros, ones) so you can't type rlwinm
Gabriel> r0,r0,0,~MSR_EE. Note that gcc/egcs would generate the code with the
Gabriel> rlwinm instruction. Anybody wants to tweak binutils to allow this ?

	I think that this already was discovered and fixed in the
development sources.  From the ChangeLog:

Wed Aug 12 14:00:38 1998  Ian Lance Taylor  <ian@cygnus.com>

        From Peter Thiemann <thiemann@informatik.uni-tuebingen.de>:
        * ppc-opc.c (insert_mbe): Handle wrapping bitmasks.
        (extract_mbe): Likewise.

David

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: your mail

[Gabriel Paubert]

On Mon, 15 Feb 1999, Benjamin Herrenschmidt wrote:

> My bootstrap is now a two-step bootstrap too, written all in asm to avoid
> relocation problems. 

Well, -m relocate is quite powerful IMHO. And I tried to write as little
assembly as possible, as you can easily guess from the 5000 lines of
PPC assembly of the x86 emulator :-)

> Since the MMU is switched off by the boostrap, I beleive those TLB
> entries won't do any harm until the kernel switches the MMU back on,
> that's it ? (I just want to make sure I fully understand). So, basically,
> I could add to my bootstrap a piece of code that invalidates all BATs and
> flush the TLB (I'll look at your preploader code for that).

No, but I need to run the bootloader mostly with MMU on to initialize the
VGA boards by emulating the VGA ROM BIOS for 2 reasons:
- having correct memeory attributes and the caches enabled,
- emulating the 1Mb of Intel Mobo (640k RAM+128k VGA+ ROM BIOS...)

I found that if I did not invalidate the TLB before starting the kernel, I
was allowed to do strange things (specifically accessing I/O space before
it was even mapped by BATs or PTE) due to stale TLB entries.  This caused
the introduction of a few bugs in some versions of my PreP initialization
code which were extremely hard to find. I even was unlucky enough to fall
on the borderline case where adding or suppressing a single debug message
in the loader cause the critical TLB entry to be valid or invalid.

Note that my code to invalidate TLB is the hammer to kill flies method: it
is guaranteed to work for all PPC (except embedded) implementations from
the architectural handbook because I don't want to rely on any system info
(too often wrong), so I invalidate 65536 TLB entries. In a bootloader, I
obviously don't care about the couple of milliseconds it takes. 

> 
> >Wrong, what is in r31 before ? You may clear unwanted MSR bits: 
> 
> You are right. I already changed this to rlwinm approx. 5 minutes after
> sending the previous mail ;-)

Ok, better like this. Unfortunately for rlwinm and friends, gas allows you
to replace the last 2 parameters by a single value (bit mask), for
example: rlwinm r3,r4,0, 0x00ffff00, but it does not work if you have the
complementary mask (ones, zeros, ones) so you can't type rlwinm
r0,r0,0,~MSR_EE. Note that gcc/egcs would generate the code with the
rlwinm instruction. Anybody wants to tweak binutils to allow this ?

	Gabriel. 


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: your mail

[Benjamin Herrenschmidt]

On Mon, Feb 15, 1999, Gabriel Paubert <paubert@iram.es> wrote:

>One of the first steps I do in prepboot is to invalidate all the BATs and
>all the TLB entries, to make sur that I start from a known state
>(invalidating the BATs is a pain because it's different in 601 and
>others). But then I'm quite sure I'm called with address translation
>disabled, only that some FW version leave stale values in these registers. 

My bootstrap is now a two-step bootstrap too, written all in asm to avoid
relocation problems. 

>I still had problems with stale TLB entries between prepboot when the 
>kernel enabled the MMU. You have to flush the TLB before starting the
>kernel to be absolutely sure that there the kernel uses only translations 
>it has defined (I discovered that I had added code accessing I/O 
>space before the corresponding BATs were set up due to staale TLB
>entries).

Since the MMU is switched off by the boostrap, I beleive those TLB
entries won't do any harm until the kernel switches the MMU back on,
that's it ? (I just want to make sure I fully understand). So, basically,
I could add to my bootstrap a piece of code that invalidates all BATs and
flush the TLB (I'll look at your preploader code for that).

>Wrong, what is in r31 before ? You may clear unwanted MSR bits:

You are right. I already changed this to rlwinm approx. 5 minutes after
sending the previous mail ;-)
	
>	mfmsr	r0
>	rlwinm  r0,r0,0,17,15
>	mtmsr 	r0
>
>is enough (And if you don't like using rlwinm like this, which is
>guaranteed to work according to the architecture):
>	
>	mfmsr	r0
>	ori	r0,r0,MSR_EE
>	xori	r0,r0,MSR_EE
>	mtmsr	r0
>
>and you never need a sync before or after disabling interrupts. It is
>different when enabling them however, because you have to make
>sure that accesses to the interrupt controller have made it to the bus.  

Ok, so I'll finally remove this sync.

>I would recommend that you take a look at the patch files I have for
>prep (only have a look at the prepboot directory): 
>
>	ftp://vcorr1.iram.es/pub/linux-2.2/mvme2600.generic-patch-2.2.1.gz
>
>it is even probably overkill for what you need. But the Makefile
>(with -m rleocatable), the linker script (ppcboot.lds) and the
>early boot (head.S) are probably good examples (and I tried to keep them
>clean). 

Ok, thanks.


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: your mail

[Gabriel Paubert]

On Sat, 13 Feb 1999, Benjamin Herrenschmidt wrote:

> 
> Hi !
> 
> I would like your point of view about the following:
> 
> The kernel entry code starts playing with BATs as soon as it is entered.
> Isn't that dangerous ? I mean, you must have enough luck for this BAT not
> to be used at this specific time, or not overlapping another BAT setup by
> MacOS (overlapping BATs causes undefined behaviour according to the PPC
> manual) ?

One of the first steps I do in prepboot is to invalidate all the BATs and
all the TLB entries, to make sur that I start from a known state
(invalidating the BATs is a pain because it's different in 601 and
others). But then I'm quite sure I'm called with address translation
disabled, only that some FW version leave stale values in these registers. 

> I have made a test bootx that I'll upload to
> ftp.linuxppc.org/developement/users/benh later today (the archive will
> probably be called BootX_phys_test.sit). This version of BootX doesn't
> jump directly to the kernel but goes to a small piece of PPC asm that
> will cause the kernel to be entered with MMU (and interrupts) disabled. I
> beleive this should get rid of potential problems with TLB misses during
> boot too. Of course, all addresses passed to the kernel are turned into
> physical addresses (frame buffer, stack, boot_infos).

I still had problems with stale TLB entries between prepboot when the 
kernel enabled the MMU. You have to flush the TLB before starting the
kernel to be absolutely sure that there the kernel uses only translations 
it has defined (I discovered that I had added code accessing I/O 
space before the corresponding BATs were set up due to staale TLB
entries).

> This version works on my desktop G3, I didn't have time to test it on
> other machines yet.
> The bootstrap code is simple (it's entered with the same parameters as
> the kernel, but with physical addresses and with the kernel physical
> entry in r6) :
> 
>     /* switch interrupts off */
>     mfmsr   r0;
>     ori     r31,r31,MSR_EE;
>     andc    r0,r0,r31;
>     sync;
>     mtmsr   r0;
>     sync;

Wrong, what is in r31 before ? You may clear unwanted MSR bits:
	
	mfmsr	r0
	rlwinm  r0,r0,0,17,15
	mtmsr 	r0

is enough (And if you don't like using rlwinm like this, which is
guaranteed to work according to the architecture):
	
	mfmsr	r0
	ori	r0,r0,MSR_EE
	xori	r0,r0,MSR_EE
	mtmsr	r0

and you never need a sync before or after disabling interrupts. It is
different when enabling them however, because you have to make
sure that accesses to the interrupt controller have made it to the bus.  


> 
>     /* put kernel entry (phys) in ssr0 */
>     mtspr   SSR0, r6;
> 
>     /* Setup ssr1 (kernel entry MSR) */
>     ori     r31,r31,(MSR_IR|MSR_DR);
>     andc    r0,r0,r31;
>     mtspr   SSR1, r0;
> 
>     /* Branch to the kernel */
>     rfi;
> 
> Note: I wrote this little piece of asm with CodeWarrior. Since I would
> like to make a C boostrap that takes place between this and the kernel, I
> still need to figure out how to build code for this with egcs. If I could
> find the correct MakeFile options to get an output like prom.c
> (PC-relative branches, datas accessed thru a RELOC macro), I think it
> would be just fine. A better approach would be to store datas relative to
> a register that I can setup before entering the boostrap, but that means
> parsing enough of the ELF to extract the offset of the datas. I would
> appreciate if someone could give me some tips about what is usually done
> in those cases or some pointers to infos/samples.


I would recommend that you take a look at the patch files I have for
prep (only have a look at the prepboot directory): 

	ftp://vcorr1.iram.es/pub/linux-2.2/mvme2600.generic-patch-2.2.1.gz

it is even probably overkill for what you need. But the Makefile
(with -m rleocatable), the linker script (ppcboot.lds) and the
early boot (head.S) are probably good examples (and I tried to keep them
clean). 

	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: your mail

[rtlynch]

You need the isapnp package. This package has tools to inspect isa cards 
and also to activate the recomended pnp settings. I belive the home page
is at http://www.roestock.demon.co.uk/isapnptools

	-Rusty Lynch

On Thu, 24 Sep 1998, Jonathan Herringer (PHY) wrote:

> I have a PnP Sound blaster card  that can't get detected by linux.  I have
> soft booted from widows, dos and it still doesnt' get detected.
> 
> I got the latest version of the kernel (2.1.122) with plug and play
> support (but couldn't find any thing on how to configure the PnP)
> 
> Can any one suggest reading material etc...  I have read the Sound HOW-To
> 
> 
> Thanks,
> Jonathan Herringer
> 
> 

Re: your mail

[Rik van Riel]

On Wed, 25 Feb 1998, Linus Torvalds wrote:

> > We could simply prohibit the VM subsystem from swapping
> > out pages which have been allocated less than one second
> > ago, this way the movement of pages becomes 'slower', and
> > thrashing might get somewhat less.
> 
> The reason I dislike rate-based things is that it is _so_ hard to give any
> kind of guarantees at all on the sanity of the thing. You can tweak the
> rates, but they don't have any logic to them, and most importantly they
> are very hard to make self-tweaking. 

Yup, I don't like 'em either, but I proposed it anyways
in case anyone of you might like it :-)
Personally, I like balancing code too, if possible with
some balancing on the balancing code as well...

OK, we go with balancing code.

Rik.
+-----------------------------+------------------------------+
| For Linux mm-patches, go to | "I'm busy managing memory.." |
| my homepage (via LinuxHQ).  | H.H.vanRiel@fys.ruu.nl       |
| ...submissions welcome...   | http://www.fys.ruu.nl/~riel/ |
+-----------------------------+------------------------------+

Re: your mail

[Linus Torvalds]

On Wed, 25 Feb 1998, Rik van Riel wrote:
> 
> I've just come up with a very simple idea to limit
> thrashing, and I'm asking you if you want it implemented
> (there's some cost involved :-( ).
> 
> We could simply prohibit the VM subsystem from swapping
> out pages which have been allocated less than one second
> ago, this way the movement of pages becomes 'slower', and
> thrashing might get somewhat less.

I'm _really_ nervous about "rate-based" limiting. Personally I think that
it only makes sense for things like networking, and even there it had
better be done by hardware. 

The reason I dislike rate-based things is that it is _so_ hard to give any
kind of guarantees at all on the sanity of the thing. You can tweak the
rates, but they don't have any logic to them, and most importantly they
are very hard to make self-tweaking. 

I tend to prefer a "balancing" approach to these problems: the important
part about balancing is that while it may not have some specific
well-defined behaviour that you can point your finger to ("will not page
out the same page that it paged in within 5 seconds"), the basic approach
is to write something that doesn't have any hard rules but that TENDS
towards some certain goal. 

That way you get algorithms that you can be fairly confident work well in
the normal cases (because you test those normal cases), and because there
are no hard rules you also don't get strange "edges" when something
unexpected happens: performance may well degrade badly, but it degrades
_softly_ rather than in quantisized jumps.

			Linus

Re: your mail

[Vincent Renardias]

On Sat, 9 Aug 1997, Ralf Baechle wrote:

> > % mips-linux-gcc  -o pwgen pwgen.o -lm
> > /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> > index; run ranlib to add one
> > 
> > running mips-linux-ranlib on the given file does not change anything.
> > (ie: still getting the same message)
> > 
> > Did I do anything wrong, or is this a problem in the Linux/SGI glibc?
> 
> No.  Looks as if your lib still isn't correctly installed.  If ranlib
> doesn't help, then your libc.a is probably corrupted into a zero lenght
> file.

You're right. (Not an empty file through, but somehow it got truncated to
~50 K). Reinstalling fixed it.

Here's the list of what I compiled so far:

file_3.20.1-6_mips.deb              gzip_1.2.4-15_mips.deb
debmake_3.3.11_mips.deb             grep_2.0-12_mips.deb
dpkg-dev_1.4.0.8_all.deb            makedev_1.6-16_mips.deb
dpkg_1.4.0.8_mips.deb               sysklogd_1.3-17_mips.deb
dpkg_1.4.0.8_mips.nondebbin.tar.gz  update_1.3-1_mips.deb
cpio_2.4.2-11_mips.deb              tar_1.12-1_mips.deb
patch_2.2-1_mips.deb                sed_2.05-15_mips.deb
flex_2.5.4a-1_mips.deb              findutils_4.1-23_mips.deb
bison_1.25-9_mips.deb               shellutils_1.16-4_mips.deb
diff_2.7-13_mips.deb                textutils_1.22-2_mips.deb
rpm_2.4.2-2_mips.deb                pwgen_1-8_mips.deb
adduser_3.6_all.deb

These packages are available from odin.waw.com/pub/linux (the pgp signed
checksums are in the changes/ subdirectory). I'd be glad if someone could
test a few of them and tell me if everything is okay.

Quick install instructions:
untar the file dpkg_1.4.0.8_mips.nondebbin.tar.gz at the root of your FS,
then install other packages with 'dpkg -i foo.deb'.

	Cordialement,

-- 
-     ** Linux **         +-------------------+             ** WAW **     -
-  vincent@debian.org     | RENARDIAS Vincent |          vincent@waw.com  -
-  Debian/GNU Linux       +-------------------+      http://www.waw.com/  -
-  http://www.debian.org/           |            WAW  (33) 4 91 81 21 45  -
---------------------------------------------------------------------------

Re: your mail

[Mike Shaver]

Thus spake Vincent Renardias:
> % mips-linux-gcc  -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
> 
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)

Did you use mips-linux-ar to create the archive?
Many packages, I've discovered, don't listen to $AR in the
environment, and I used to get that error all the time.

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>            Chief System Architect and Herder of Bits                
#>                                                                     
#> "Yoda say, `Just slap a little public key crypto into it' does not  
#>      a secure system make." -- Marcus J. Ranum (mjr@clark.net)      

Re: your mail

[Mike Shaver]

Thus spake Vincent Renardias:
> % mips-linux-gcc  -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
> 
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)

Did you use mips-linux-ar to create the archive?
Many packages, I've discovered, don't listen to $AR in the
environment, and I used to get that error all the time.

Mike

-- 
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation 
#>            Chief System Architect and Herder of Bits                
#>                                                                     
#> "Yoda say, `Just slap a little public key crypto into it' does not  
#>      a secure system make." -- Marcus J. Ranum (mjr@clark.net)      

Re: your mail

[Ralf Baechle]

> % mips-linux-gcc  -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
> 
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)
> 
> Did I do anything wrong, or is this a problem in the Linux/SGI glibc?

No.  Looks as if your lib still isn't correctly installed.  If ranlib
doesn't help, then your libc.a is probably corrupted into a zero lenght
file.

  Ralf

Re: your mail

[Ralf Baechle]

> % mips-linux-gcc  -o pwgen pwgen.o -lm
> /usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
> index; run ranlib to add one
> 
> running mips-linux-ranlib on the given file does not change anything.
> (ie: still getting the same message)
> 
> Did I do anything wrong, or is this a problem in the Linux/SGI glibc?

No.  Looks as if your lib still isn't correctly installed.  If ranlib
doesn't help, then your libc.a is probably corrupted into a zero lenght
file.

  Ralf

Re: your mail

[Vincent Renardias]

On Sat, 9 Aug 1997, Ralf Baechle wrote:

> > I just installed the binutils/gcc crossdev packages from
> > ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
> > from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
> > (i386).
> 
> Well, it doesn't matter except that I built the executables with Linux
> libc and you therefore need that one.  DANGER:  When you install libs
> for a crosscompiler you will have to move the libs a bit around.
> Just doing tar zxf ... -C / will fry your native system.  MIPS stuff
> just has too much octane to be suitable as fuel for your Intel machine ;-)

Debian provides nice tools to handdle this kind of installation:

- alien: allows to convert binary packages between any 2 of the
{.deb,.tgz,.rpm} formats.

- dpkg-cross: tool handdling cross-compilation packages. That is any file
that should go into /*/lib is redirected into /usr/local/$ARCH-linux/lib.
(same for the include files). It also makes it possible to build a given
package for several architectures at the same time.
Those tools should probably work on any Linux flavour (distrib./arch.)

Anyway, I've installed glibc-2.0.4 to get around the missing sgidefs.h
problem, and I run into another problem:
now mips-linux-gcc complains about:

% mips-linux-gcc  -o pwgen pwgen.o -lm
/usr/local/mips-linux/lib/libc.a: could not read symbols: Archive has no
index; run ranlib to add one

running mips-linux-ranlib on the given file does not change anything.
(ie: still getting the same message)

Did I do anything wrong, or is this a problem in the Linux/SGI glibc?

	Cordialement,

--
-     ** Linux **         +-------------------+             ** WAW **     -
-  vincent@debian.org     | RENARDIAS Vincent |          vincent@waw.com  -
-  Debian/GNU Linux       +-------------------+      http://www.waw.com/  -
-  http://www.debian.org/           |            WAW  (33) 4 91 81 21 45  -
---------------------------------------------------------------------------

Re: your mail

[Ralf Baechle]

> > Not the right thing, but won't hurt.  I shows that your libc is
> > not installed correctly.
> 
> I just installed the binutils/gcc crossdev packages from
> ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
> from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
> (i386).

Well, it doesn't matter except that I built the executables with Linux
libc and you therefore need that one.  DANGER:  When you install libs
for a crosscompiler you will have to move the libs a bit around.
Just doing tar zxf ... -C / will fry your native system.  MIPS stuff
just has too much octane to be suitable as fuel for your Intel machine ;-)

Btw, as I'm writing this I've built about 88mb of binary .rpm packages
running native.  The sole problems I currently have is that the kernel
seems to have some memory corruption problem.  That is nasty because
it usually hits the bitmaps ...  It might as well explain Miguel's
recently reported NFS problem.

  Ralf

Re: your mail

[Ralf Baechle]

> > Not the right thing, but won't hurt.  I shows that your libc is
> > not installed correctly.
> 
> I just installed the binutils/gcc crossdev packages from
> ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
> from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
> (i386).

Well, it doesn't matter except that I built the executables with Linux
libc and you therefore need that one.  DANGER:  When you install libs
for a crosscompiler you will have to move the libs a bit around.
Just doing tar zxf ... -C / will fry your native system.  MIPS stuff
just has too much octane to be suitable as fuel for your Intel machine ;-)

Btw, as I'm writing this I've built about 88mb of binary .rpm packages
running native.  The sole problems I currently have is that the kernel
seems to have some memory corruption problem.  That is nasty because
it usually hits the bitmaps ...  It might as well explain Miguel's
recently reported NFS problem.

  Ralf

Re: your mail

[Vincent Renardias]

On Sat, 9 Aug 1997, Ralf Baechle wrote:

> > 2/ While using the crossdev gcc, several times I got complains about a
> > file 'sgidefs.h' missing (from
> > /usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41). 
> > Commenting the '#include' file made the compile work, but I not sure it's
> > the right fix. 
> 
> Not the right thing, but won't hurt.  I shows that your libc is
> not installed correctly.

I just installed the binutils/gcc crossdev packages from
ftp.linux.sgi.com. Should i also install the glibc-2.0.4-1.tar.gz package
from /pub/mips-linux? In case it matters my native libc is glibc-2.0.4
(i386).

[Thanx for the explanation on endianess ;]

	Cordialement,

--
-     ** Linux **         +-------------------+             ** WAW **     -
-  vincent@debian.org     | RENARDIAS Vincent |          vincent@waw.com  -
-  Debian/GNU Linux       +-------------------+      http://www.waw.com/  -
-  http://www.debian.org/           |            WAW  (33) 4 91 81 21 45  -
---------------------------------------------------------------------------

Re: your mail

[Ralf Baechle]

> 	I've just joined this ML, and I'm trying to contribute to the
> Linux/SGI development. Since I'm not too good at kernel hacking, I've
> tough about working on porting the userland part (I have some experience
> with this part since I've been a Debian developper for a while and
> initiated the Debian/PowerPC port).
> 	By now I don't have access to any SGI hardware, but i've been able
> to build some packages with the crossdev (i486-linux) packages from
> ftp.linux.sgi.com.
> 
> 	So here are my questions:
> 
> 1/ Which are the 'most wanted' packages not yet recompiled/ported to
> Linux/SGI? I've looked at the RPMs available RPM list, and some important
> packages seem unavailable yet. (sed,tar,perl come to mind).

sed, tar: confilicting declaration in source and libc.  Both work other-
wise.  Perl: builds shrink wrapped & works, just the binary packaging
with RPM fails.  I think because groff/man are missing.  I've got another
two dozen packages on disk which I'll upload when I next pass by in
Mountain View ...

> 2/ While using the crossdev gcc, several times I got complains about a
> file 'sgidefs.h' missing (from
> /usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41). 
> Commenting the '#include' file made the compile work, but I not sure it's
> the right fix. 

Not the right thing, but won't hurt.  I shows that your libc is
not installed correctly.

> 3/ Can any1 confirm/correct the following values for GNU/autoconf:

> ac_cv_c_bigendian=no

MIPS CPUs can be configured for both byte orders.  SGI, Mips Inc.,
Sony machines are wired big endian, most other machines are little
endian or configurable by replacing the firmware.  As a consequence
we have to build all packages twice, once for each byte sex.
mips-linux-* tools are big endian by default, mipsel-linux-* tools
little endian.

> ac_cv_c_char_unsigned=no

True by default, unless you give -funsigned-char.

> ac_cv_sizeof_long=4
> ac_cv_sizeof_int=4

True by default in the mips{el}-linux configurations; the size of
these types can be changed by -mlong64 and -mint64.  These options
are incompatible with libc, so I mention them only for completeness.

  Ralf

Re: your mail

[Ralf Baechle]

> 	I've just joined this ML, and I'm trying to contribute to the
> Linux/SGI development. Since I'm not too good at kernel hacking, I've
> tough about working on porting the userland part (I have some experience
> with this part since I've been a Debian developper for a while and
> initiated the Debian/PowerPC port).
> 	By now I don't have access to any SGI hardware, but i've been able
> to build some packages with the crossdev (i486-linux) packages from
> ftp.linux.sgi.com.
> 
> 	So here are my questions:
> 
> 1/ Which are the 'most wanted' packages not yet recompiled/ported to
> Linux/SGI? I've looked at the RPMs available RPM list, and some important
> packages seem unavailable yet. (sed,tar,perl come to mind).

sed, tar: confilicting declaration in source and libc.  Both work other-
wise.  Perl: builds shrink wrapped & works, just the binary packaging
with RPM fails.  I think because groff/man are missing.  I've got another
two dozen packages on disk which I'll upload when I next pass by in
Mountain View ...

> 2/ While using the crossdev gcc, several times I got complains about a
> file 'sgidefs.h' missing (from
> /usr/local/lib/gcc-lib/mips-linux/2.7.2/include/va-mips.h, line 41). 
> Commenting the '#include' file made the compile work, but I not sure it's
> the right fix. 

Not the right thing, but won't hurt.  I shows that your libc is
not installed correctly.

> 3/ Can any1 confirm/correct the following values for GNU/autoconf:

> ac_cv_c_bigendian=no

MIPS CPUs can be configured for both byte orders.  SGI, Mips Inc.,
Sony machines are wired big endian, most other machines are little
endian or configurable by replacing the firmware.  As a consequence
we have to build all packages twice, once for each byte sex.
mips-linux-* tools are big endian by default, mipsel-linux-* tools
little endian.

> ac_cv_c_char_unsigned=no

True by default, unless you give -funsigned-char.

> ac_cv_sizeof_long=4
> ac_cv_sizeof_int=4

True by default in the mips{el}-linux configurations; the size of
these types can be changed by -mlong64 and -mint64.  These options
are incompatible with libc, so I mention them only for completeness.

  Ralf