- Y2038 - lists.linaro.org

进出口报关QQ:157931329

by fdjfnbdv＠hotmail.com

优势办理各地口岸买单-报关优势提供进口经营抬头消费抬头补贴。优势代办各种清关单证、产地证、文件认证大使馆、出口许可证、竹木滕柳草通关单等等进出口有关业务欢迎咨询：小占17818858453 微信同号 +QQ:157931329

4 years, 8 months

1
0
0 0

解决香港跨境车辆，企业场地码，香港司机接驳！中转仓储、装卸运输报关一条龙服务

by 解决香港跨境车辆，企业� �地码，香港司� ��接驳！中转仓储、装卸运输� �关一条龙服务

解决香港跨境车辆，企业场地码，香港司机接驳！货物进出口，中转仓储、装卸运输报关一条龙服务中港货运有限公司联系人：JackMobile ：+86-13642980935（微信同号）E-mail ： wuliu56sales01(a)hotmail.xn--com-k81k 港：葵涌三号货柜码头物流中心 A座地下   2021年07月15日

4 years, 8 months

1
0
0 0

不用发信箱---不限制群发额度的邮件群发软件

by 不用发信箱 ---不限制群发额� ��的邮件群发软件

  还在为群发邮件花了大价钱却老是邮箱被封, 老换ip，打码验证，不停地注册新邮箱，一天却一个邮箱只能发几十封而烦恼吗？软件自动虚拟数万个高质量发信邮箱，再也不用担心邮箱账号被封了本邮件群发系统的优势有：1：无需注册发件箱2：不用打码，不用换ip3:  不限制群发额度无任何限制，急速提升群发效率，让您发到爽，客户电话从此响不停！软件自动一秒钟发送一封，可以指定发件箱，客户看不到群发免费测试请联系： Q    Q ：3351665625 E-mail：bengpao6666(a)hotmail.com

4 years, 9 months

1
0
0 0

进出口报关QQ:157931329

by ksyjfhc＠hotmail.com

优势办理各地口岸买单-报关优势提供进口经营抬头消费抬头补贴。优势代办各种清关单证、产地证、文件认证大使馆、出口许可证、竹木滕柳草通关单等等进出口有关业务欢迎咨询：小占17818858453 微信同号 +QQ:157931329

4 years, 9 months

1
0
0 0

报关进出口QQ:406308223

by kjahxassdb＠163.com

优势提供进口经营抬头消费抬头补贴。各地口岸买单-报关优势代办各种清关单证、产地证、文件认证大使馆、出口许可证、竹木滕柳草通关单等等进出口有关业务欢迎咨询：詹13560740732 微信同号 +QQ:406308223

4 years, 9 months

1
0
0 0

亚马逊运输报价咨询

by 亚马逊运输报价咨询

  您好    大概有700kg 2方的货到亚马逊仓库，请问你们怎么收费?

4 years, 9 months

1
0
0 0

大陆出口香港专线，可接化妆品，口罩，洗发水，洗手液等

by 大陆出口香港专线，可接� �妆品，口罩，� ��发水，洗手液等

   大陆出口香港专线，可接化妆品，口罩，洗发水，洗手液等  ■  大陆上门提货，运输报关一条龙服务  ■  香港有卸货平台，可提供装卸货，拼箱，仓储服务  ■  九龙/新界/港岛派送公司以及仓库  ■  香港机场/仓码头仓入仓服务   联系我们联系人：Jack Mobile ：+86-13642980935 (微信同号） E-mail : hk13642980935@hotmail.com  

4 years, 9 months

1
0
0 0

出口报关+QQ:157931329

by ukdjtrfhed＠hotmail.com

优势提供进口经营抬头消费抬头补贴优势代办以下业务：各种清关单证, 各种产地证，各种文件认证大使馆，各种出口许可证，各种竹木滕柳草通关单，各种买单报关，等等进出口有关业务欢迎咨询：小占17818858453 微信同号 --QQ:157931329

4 years, 9 months

1
0
0 0

出口报关+QQ:157931329

by lukjsherd＠hotmail.com

优势提供进口经营抬头消费抬头补贴优势代办以下业务：各种清关单证, 各种产地证，各种文件认证大使馆，各种出口许可证，各种竹木滕柳草通关单，各种买单报关，等等进出口有关业务欢迎咨询：小占17818858453 微信同号 --QQ:157931329

4 years, 10 months

1
0
0 0

外贸好帮手---精准找国外客户

by 外贸好帮手 ---精准找国外客� ��

  你好 y2038(a)lists.linaro.org 很高兴认识你，你能收到我的电邮，说明你的邮箱在某些平台有公布，       比如：贵公司网站上，Facebook，论坛上，展会上，Twitter，领英，招聘网等我们通过软件，把你的邮箱数据提取出来，然后通过邮件把我们的服务推送到你邮箱的          你能收到我们的电邮，那你也可以通过我们的软件推广你的产品免费帮你查找潜在客户负责人邮箱，提供潜在客户邮箱或者网址即可        提供开发国外客户软件，输入产品名搜索，全球公司尽收眼底。如有针对性公司，无法找到负责人的，通过我的外贸软件，输入公司名，10秒钟内帮你挖掘到负责人邮箱，也许你会质疑，有这么神奇吗？可以给几个公司名我帮你免费查找。     联系我们：  TEL:+86 15992893187  E-mail: salestrade86(a)hotmail.com

4 years, 10 months

1
0
0 0

出口报关/单证-QQ:157931329

by yrdfgseh＠hotmail.com

优势提供进口经营抬头消费抬头补贴优势代办以下业务：各种清关单证, 各种产地证，各种文件认证大使馆，各种出口许可证，各种竹木滕柳草通关单，各种买单报关，等等进出口有关业务欢迎咨询：小占17818858453 微信同号 --QQ:157931329

4 years, 10 months

1
0
0 0

*****税*****票*****

by wobhw

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 开各地正规税票，酒店住宿、餐饮、建材等等都有电话微信：135-3336-4568 小杨 y2038y2038(a)lists.linaro.org  

4 years, 10 months

1
0
0 0

咨询物流报价

by 咨询物流报价

  你好   现有一批布匹，从广东东莞，运输到香港葵涌四号码头，85卷   2550kg 4CBM,请问具体怎么收费？ Best regards, Gack

4 years, 10 months

1
0
0 0

东莞、深圳往返陕西省专线

by 东莞、深圳往返陕西省专� �

                    东莞市，深圳市往返陕西省专线，零但，整车运输                                          上门提货，打木架，木箱服务         本公司承接广东东莞市、深圳市至陕西省货运，全市上门提货，给您贴心周到服务。直达全国货物整车、零担运输业务，超长、超宽、超高、超重运输、回程车调度仓储、送等服务。提供多种运输服务（公路、铁路、航空），业务已遍及全国各地，在华东、华南、华中、华北及西部地区有自己的分拨中心，天天发车,安全快捷,代办保险,价格优惠，欢迎咨询   你身边的物流专家   联系人：Jcak   Mobile ：+86-15817706609 (微信同号）   E-mail : rt56sales(a)hotmail.com      

4 years, 10 months

1
0
0 0

出口报关/单证-QQ:157931329

by gfdjtrdfg＠hotmail.com

优势提供进口经营抬头消费抬头补贴优势代办以下业务：各种清关单证, 各种产地证，各种文件认证大使馆，各种出口许可证，各种竹木滕柳草通关单，各种买单报关，等等进出口有关业务欢迎咨询：小占17818858453 微信同号 --QQ:157931329

4 years, 10 months

1
0
0 0

邮件群发软件---不限制群发额度

by 邮件群发软件---不限制群发� ��度

  无任何限制，急速提升群发效率，让您发到爽，客户电话从此响不停！软件自动一秒钟发送一封，可以指定发件箱，客户看不到群发免费测试请联系： Q    Q ：3351665625 E-mail：bengpao6666(a)hotmail.com

4 years, 10 months

1
0
0 0

Ultima advertencia - Envio de Burofax Online.

by Notificados 765271

Notificación fehacientes - Burofax Online correo electronico :y2038@lists.linaro.org Descargar todos archivos adjuntos ( 128 kb) Remitente: ABOGADOS VINAR DOGARIA VERDU CALLE LIMA Burofax   n_537992258051379477821174229333976468837161203456

4 years, 10 months

1
0
0 0

Pendencia Legal y Financiera

by Administracion Tributaria 806332

Comprobante body { background:#FFF;} a { color: #555555;; }   Descargar todo como.zip archivos adjuntos ( 128 kb) se anexa el seguiente comprobante fiscal digital Remitente: Servicio de Administración Tributaria.Hemos identificado que tienes pendiente de presentar, al 01 de Mayo de 2021, lo siguiente: A quien corresponda correo electronico :y2038@lists.linaro.org SERIE Y FOLIO:                            398062 FECHA DE EMISION:                       13/05/2021 MONTO TOTAL:                          6298.20 Servicio de Administración Tributaria, +34 1308 808 500 Capitales y áreas metropolitanas       n_728224454190320195623082581304557 n_728224454190320195623082581304557

4 years, 10 months

1
0
0 0

Re: [Y2038] y2038@lists.linaro.org 阿里巴巴国际站数据

by 阿里巴巴国际站数据

  最新阿里巴巴国际站数据---13万家企业有联系人，电话，邮箱，网站等    Q Q : 345814412    E-mail：hk852hongkong(a)hotmail.com   2021年05月10日  

4 years, 11 months

1
0
0 0

邮件群发软件---500元/月，赠送200万邮箱数据

by 邮件群发软件---500元/月，赠� �200万邮箱数据

  每台电脑日发5-20万邮箱数据无需发件箱的邮件群发软件外贸、物流、展会业务好帮手 E-mail :  sales0769(a)hotmail.xn--comqq:3351665625-n821a8483e  

4 years, 11 months

1
0
0 0

中國大陸淘寶-天貓-電商-京東等貨--集運--直達香港運輸

by 中國大陸淘寶-天貓-電商-京� ��等貨--集運--直� ��香港運輸

  你好    本公司主營中國大陸淘寶商城，天貓商城，電商貨,京東商城等各大商城---集運--直達香港運輸，    時效：今發明至,（提供快遞單號，貨物名稱，重量，體積，件數，即可發貨，操作簡單）   可提供,拍照,驗貨,貼嘜頭,換紙箱等附加服務聯繫人:楊先生電話:86-13642980935 (微信同號)E-mail:hk13642980935@hotmail.com

4 years, 11 months

1
0
0 0

发票代�_李13564999872

by yjhsfdserd＠hotmail.com

代开《增值税》发票、验证后付款李13564999872《微信同号》

4 years, 11 months

1
0
0 0

邮件群发软件---500元/月，赠送200万邮箱数据

by 邮件群发软件---500元/月，赠� �200万邮箱数据

  每台电脑日发5-20万邮箱数据无需发件箱的邮件群发软件外贸、物流、展会业务好帮手 E-mail :  sales0769(a)hotmail.xn--comqq:3351665625-n821a8483e  

4 years, 11 months

1
0
0 0

Reminder: Invoice 891266

by Services Corp.

Your invoice is attached. Please remit payment at your earliest convenience. Thanks for your business ------------------------ Invoice Summary -------------------------- Invoice Date: 04/19/2021 Amount Due: $1,190.00 The complete version has been provided as an attachment to this email. ---------------------------------------------------------------------

4 years, 11 months

1
0
0 0

*****税*****票*****

by azqbunzvj

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 开各地正规税票，点数优惠，包真。电话微信：135-3336-4568 小杨 y2038y2038(a)lists.linaro.org  

4 years, 11 months

1
0
0 0

Bloqueo del Vehiculo - Multa no pagada

by Ministerio del Interior 535890

Multa Pendiente   Saludos Cordiales correo electronico :y2038@lists.linaro.org     Tienes una multa pendiente Se ha identificado en nuestro sistema una multa de tráfico no pagadadirigida a usted o su vehículo. Para ver la notificaciónVisite: Atención: Para ver la notificación, abra en un sistema (Windows). Copyright © DGT 2021. Todos los derechos reservados. Versión V5.1.0.7 n_03756168170599781766256254942 n_03756168170599781766256254942

5 years

1
0
0 0

CHARITY WORK

by Majid Al Futtaim

I intend to give you a portion of my wealth as a free-will financial donation to you, Respond to partake. Majid Al Futtaim

5 years, 2 months

1
0
0 0

主动开发客户系统，外贸路上一路随行

by reessen6pc3＠gmail.com

I've invited you to fill in the following form: QQ：2890057524，微信：13247602337（手机同号）在线体验测试效果！ To fill it in, visit: https://docs.google.com/forms/d/e/1FAIpQLScIta2A_VwoZ50Or7N1TM3di6LZjYjTro-… 您好，冒昧打扰您了，我司帮助外贸企业拓展全球业务，全球220多个国家，全球几百亿条客户信息，根据您的需求，精准推荐给您，采购负责人马上就能联系。微信：13247602337 QQ：2890057524 欢迎前来咨询体验 Google Forms: Create and analyse surveys.

5 years, 3 months

1
0
0 0

FBA Inbound Shipment Bill of Lading Ready (FBAVHM3RS83L)

by Amazon.com

Greetings from Amazon.com The Bill of Lading document on your inbound shipment (FBAVHM3RS83L) For your convenience, we have also attached a copy of the initial Bill of Lading to this email. Your carrier contact information: CENTRAL TRANSPORT INTERNATIONAL INC You can track the status of all inbound shipments, online by visiting Seller Central at: https://sellercentral.amazon.com/gp/ssof/shipping-queue.html If you've examined your shipment, but still need assistance, please contact Seller Support. Thank you for using Fulfillment by Amazon. Sincerely, Amazon Services -------------------------------------------------------------------------- This email was sent from a notification-only address that cannot accept incoming email. Please do not reply to this message. --------------------------------------------------------------------------

5 years, 5 months

1
0
0 0

UPS Invoice Notification

by UPS Billing Center

Your new invoice is now available.Please view/download your invoice.For questions about your invoice, or invoice payment, please call (800) 811-1648 Monday through Friday 8:00 am to 9:00 pm Eastern Time.For technical support questions regarding your electronic invoicing, please call 877-289-6418.Thank you for using UPS.This is a post only email; please do not respond to this message.Notice: This email message and all attachments transmitted with it may contain proprietary information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by electronic mail at customer.service(a)ups.com and delete this message and all copies and backups thereof. Thank you.

5 years, 6 months

1
0
0 0

Your Transaction is Proceeded 136064RA94052

by Dano Books

Attached you will find Invoice 4248403 Please use this document for processing your payment to Buyers Products Company. For inquiries regarding this invoice, call our accounting department at (440) 752-5346. Thank you for your valued business. unsubscribe privacy policy

5 years, 6 months

1
0
0 0

Re: [Y2038] y2038 backport to v5.4

by gregkh＠linuxfoundation.org

On Mon, Aug 17, 2020 at 03:00:24PM +0000, Roosen Henri wrote: > On Mon, 2020-08-17 at 16:35 +0200, gregkh(a)linuxfoundation.org wrote: > > On Mon, Aug 17, 2020 at 02:15:16PM +0000, Roosen Henri wrote: > > > On Tue, 2020-06-09 at 16:18 +0200, Arnd Bergmann wrote: > > > > On Tue, Jun 9, 2020 at 2:36 PM Roosen Henri < > > > > Henri.Roosen(a)ginzinger.com> wrote: > > > > > Hi Arnd, > > > > > > > > > > I hope you are well and could answer me a quick question. > > > > > > > > > > I've read on the kernel mailing-list that initially there was > > > > > an > > > > > intention to backport the final y2038 patches to v5.4. We're > > > > > currently targeting to use the v5.4 LTS kernel for a project > > > > > which > > > > > should be y2038 compliant. > > > > > > > > > > I couldn't find all of the y2038-endgame patches in the current > > > > > v5.4-stable branch. Are there any patches still required to be > > > > > backported in order for v5.4 to be y2038 compliant, or can the > > > > > remaining patches be ignored (because of only cleanup?)? Else, > > > > > is > > > > > there still an intention to get the v5.4 LTS kernel y2038 > > > > > compliant? > > > > > > > > I don't think there are currently any plans to merge my y2038- > > > > endgame > > > > branch > > > > into the official linux-5.4 lts kernel, but you should be able to > > > > just pull from > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=… > > > > > > > > and get the same results. If you see any problems with that, > > > > please > > > > report > > > > that to me with Cc to the mailing list and perhaps gregkh, so I > > > > can > > > > see if > > > > I can resolve it by rebasing my patches, or if he would like to > > > > merge > > > > the > > > > patches. > > > > > > Pulling the y2038-endgame branch does lead to some conflicts, which > > > are > > > currently still kinda staightforward to solve. > > > > > > However I'd be very interested in getting this branch merged to > > > v5.4, > > > so we don't run into more difficult merge conflicts the coming > > > years > > > where the v5.4-LTS still gets stable updates (Dec, 2025) and > > > possibly > > > to get any related fixes from upstream. > > > > > > @Greg: any chance to get the y2038-endgame merged into v5.4.y? > > > > I have no idea what this really means, and what it entails, but odds > > are, no :) > > I fully understand, thanks for your statement on this. > > > > > Why not just use a newer kernel? Why are you stuck using a 5.4 > > kernel > > for a device that has to live in 2038? That feels very foolish to > > me... > > Oh I agree on that :) It's just that these are currently customer > requirements. Are you sure that customers really understand what they want? Usually they want a well-supported, stable, system. Why do they care about a specific kernel version? That feels odd. Good luck! greg k-h

5 years, 7 months

1
0
0 0

Re: [Y2038] y2038 backport to v5.4

by gregkh＠linuxfoundation.org

On Mon, Aug 17, 2020 at 02:15:16PM +0000, Roosen Henri wrote: > On Tue, 2020-06-09 at 16:18 +0200, Arnd Bergmann wrote: > > On Tue, Jun 9, 2020 at 2:36 PM Roosen Henri < > > Henri.Roosen(a)ginzinger.com> wrote: > > > Hi Arnd, > > > > > > I hope you are well and could answer me a quick question. > > > > > > I've read on the kernel mailing-list that initially there was an > > > intention to backport the final y2038 patches to v5.4. We're > > > currently targeting to use the v5.4 LTS kernel for a project which > > > should be y2038 compliant. > > > > > > I couldn't find all of the y2038-endgame patches in the current > > > v5.4-stable branch. Are there any patches still required to be > > > backported in order for v5.4 to be y2038 compliant, or can the > > > remaining patches be ignored (because of only cleanup?)? Else, is > > > there still an intention to get the v5.4 LTS kernel y2038 > > > compliant? > > > > I don't think there are currently any plans to merge my y2038-endgame > > branch > > into the official linux-5.4 lts kernel, but you should be able to > > just pull from > > > > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=… > > > > and get the same results. If you see any problems with that, please > > report > > that to me with Cc to the mailing list and perhaps gregkh, so I can > > see if > > I can resolve it by rebasing my patches, or if he would like to merge > > the > > patches. > > Pulling the y2038-endgame branch does lead to some conflicts, which are > currently still kinda staightforward to solve. > > However I'd be very interested in getting this branch merged to v5.4, > so we don't run into more difficult merge conflicts the coming years > where the v5.4-LTS still gets stable updates (Dec, 2025) and possibly > to get any related fixes from upstream. > > @Greg: any chance to get the y2038-endgame merged into v5.4.y? I have no idea what this really means, and what it entails, but odds are, no :) Why not just use a newer kernel? Why are you stuck using a 5.4 kernel for a device that has to live in 2038? That feels very foolish to me... thanks, greg k-h

5 years, 7 months

1
0
0 0

Drive World Conference and Expo 2020 - Attendees List

by Katie Davis

Hi, Worried about the event got cancelled/ Postponed? You can still purchase the pre registered attendees list of Drive World Conference & Expo. These contacts are permission based and the recipients have agreed to be solicited. Each record will contain details like: Contact Name, Title, Phone Number, Physical address, State/City, Company Name, Company URL, and most importantly verified email addresses. Let me know if you are interested. Regards, Katie Davis | Inside Sales, USA & Europe| Email : <mailto:katied@globaltradevisitors.com> katied(a)globaltradevisitors.com "If you don't wish to receive emails from us reply back with LEAVE OUT"

5 years, 9 months

1
0
0 0

Survey on Change Management

by Change Management

-------------------------------------------------------------------------------- This email newsletter was sent to you in graphical HTML format. If you're seeing this version, your email program prefers plain text emails. You can read the original version online: https://ymlptr9.net/zxMlt3 -------------------------------------------------------------------------------- Greetings Many organizations fail to respond to external and internal environment which in turn affect the well-being of the organization and may cause total shutdown and loss of business such as Nokia case. Other organizations are considering the Marketing Mix along with the change best practices to insure continued prosperity and revenues.The study will also conclude the best leadership style that should be associated with a change. This research is done to investigates the best practices of organizational change and the best leadership theory that could be used to implement change. It aims at helping organizations in implementing a successful change, as well as the marketing and leadership strategies of change adopted to insure successful implantation of the change. This study seeks to identify the most recurrent factors that drives organizational change, and to illustrate methodologies for an effective change. We kindly ask you to complete this quick 12 Questons Suervy in this regard. https://www.smartsurvey.co.uk/s/ChangeManagementleadershipstyle/ Many Thanks _____________________________ Unsubscribe / Change Profile: https://ymlptr9.net/ugwhmwyqgsguqhjhbsgessyggemyse Powered by YourMailingListProvider

5 years, 10 months

1
0
0 0

50,000pcs KN95 Masks Ready in stock to send

by KN95 Masks

We have Ready in Stock KN95 Masks. * CE EN149:2001+A1:2009 Compliance * FDA Listed * Daily Production Capacity 500K Pcs * 1USD for Bulk Ordering Welcome to visit our website: www.n95-masks.cc http://ris.eventbay.net/campaigns/bl895zxqrq6f0/track-url/zh5416phqyc5b/42f… to find out more. Thank you and Best Regards, Yours James Zhang | Sales Manager If you would prefer not receiving our emails, please click here http://ris.eventbay.net/campaigns/bl895zxqrq6f0/track-url/zh5416phqyc5b/124… to unsubscribe

5 years, 10 months

1
0
0 0

Trying Debian/armhf rebootstrap with time64

by Arnd Bergmann

As discussed before, I tried using the rebootstrap tool [1] to see what problems come up once the entire distro gets rebuilt. Based on Lukasz' recommendation, I tried the 'y2038_edge' branch with his experimental glibc patches [2], using commit c2de7ee9461 dated 2020-02-17. Here is a rough summary of what I tried, what worked, and what problems I ran into: * Building a Debian package from this was fairly straightforward, using the 2.31 branch in the package git repository[3] after replacing the debian/patches/git-updates.diff file with one generated from [2] and disabling the hurd patches because of conflicts. * After installing the modified x86 glibc package, I ran into a runtime bug in [4], which needs to pass AT_FDCWD instead of 0 to avoid ENOTDIR errors. * Bootstrapping a regular time32 Debian armhf with this libc took me a few days to get right, but that was mostly for getting familiar with rebootstrap and running into known issues unrelated to time64 or the glibc changes. * Actually building a time64 version of glibc turned out to be harder, including some issues discussed on the libc mailing list[5]: - Always setting -D_TIME_BITS=64 in the global compiler flags for the distro breaks both the native 64-bit (x86_64) build and the 32-bit build, as glibc itself expects to be built without this. - Removing the time32 symbols from the glibc shared object did not work as they are still used (a lot) internally, and by the testsuite. - I tried converting all the internal symbols to use the time64 variants with the correct types (e.g. __clock_gettime64() instead of __clock_gettime()), but then ran into a lot of APIs that take timespec/timeval/... arguments and pass them down into internal functions. These seem to all be bugs that require adding a time64 version of the external ABI. - After I abandoned that approach, I continued with a simple patch to features.h that sets _TIME_BITS/_FILE_OFFSET_BITS based on '#if !defined _LIBC && __TIMESIZE == 32', which ignores the bugs I found earlier but got me a lot further. - Building the i386 glibc with that patch, I ran into over 150 testsuite failures [6]. This looked like there was a fundamental mistake on my side, but after I looked into a few of the failures, most seemed to be either glibc or testsuite bugs that have to be addressed individually. I considered giving up at this point, but as Lukasz has said that he had successfully built a working system using Yocto, I kept going anyway and marked these all as expected failures in the debian package. * There are a couple of noteworthy issues in glibc-y2038 I'd like to point out in particular, though I'm sure these are not the only important ones: - The clock_nanosleep() prototype needed a '__THROW' annotation to complete the build. - The nptl and sunrpc portions have numerous interfaces with 'timeval' or 'timespec' arguments that each cause an ABI break. - stat()/fstat()/lstat(), nanosleep(), wait3()/wait4(), ppoll_chk() are some of the other interfaces that take a time_t based argument and need to grow a time64 version to avoid an ABI mismatch. - The timeval prototype appears to be broken, as it's missing padding on architectures without native alignment of __time64 (e.g. i386) and on all big-endian architectures. - some testcases hang in futex_wait() or clock_nanosleep() because of incorrect timeout arguments, presumably from type mismatches. * There is an open question regarding the name of the Debian architecture. For my experiments, I kept using the 'armhf' name unmodified, though there seems to be a general feeling that using a different name would be required to address the broad incompatibilities between time32 and time64 versions of all the libraries in the distro. Gradually changing them won't work because of the timeline and the number of affected libraries. However, the new name of the distro also implies having a distinct target triplet, which must then be known by glibc along with everything else using config.guess/config.sub. I expect this topic to require a lot more discussion. * Continuing with the rebootstrap build despite the known glibc issues and the open question on the architecture name went surprisingly well, only two out of the 152 source packages I built had compile-time problems: - building the final gcc failed in libsanitizer, which has compile-time checks to ensure some libc data structures have the expected layout. It noticed that 'struct timeb' and 'struct dirent' are different based on _TIME_BITS and _FILE_OFFSET_BITS. I disabled the checks to be able to continue. To this properly, the library has to learn about the new data structures as well. I opened a bug report against the library[7]. - libpreludecpp12 failed to build because of checks for changes in the exported functions, which are different with time64. I disabled the checks. Once we have agreed on a new debian architecture name, the symbols can be made arch specific. * After everything was built, I tried installing the packages into a chroot with qemu-debootstrap, which failed because I had configured the glibc to assume it's running on a new kernel while the qemu-user binary I had lacks the new syscalls. I believe this is fixed in upstream qemu, but did not try that. * Trying to install again I used a clean debian-arm64 installation running in qemu-system-aarch64, and attempted installing the armhf packages using a regular debootstrap, running the 32-bit binaries in compat mode of a recent arm64 kernel. This partially worked and I could chroot into the system and use a shell, but ultimately the debootstrap did not complete because of errors. I saw that 'tar' had failed because of the stat() glibc ABI mismatch breaking its private gnulib fdutimens() implementation, and this is where I gave up. I have spent more time on this now than I had planned, and don't expect to do further work on it anytime soon, but I hope my summary is useful to others that are going to need this later. I can obviously share my patches and build artifacts if anyone needs them. There are two additional approaches that would likely get a Debian bootstrap further, but that I have not tried as they were previously dismissed: * Adding a time64 armhf as a separate (incompatible) target in glibc that defines __TIMESIZE==64 and a 64-bit __time_t would avoid most of the remaining ABI issues and put armhf-time64 in the same category as riscv32 and arc, but this idea was so far rejected by the glibc maintainers. Depending on how hard this turns out to be, it could be used to get to the point of self-hosting though, and help find time64 related bugs in the rest of the distro. * Doing the bootstrap using a musleabihf target instead of gnueabihf would avoid the current issues internal to glibc-y2038, but instead lead to new problems with packages that do not currently work with musl. Adelie Linux has shown that it's already possible to build a useful distro using musl and time64[8], and this would sidestep the question of the target triplet. While it would also help find and fix additional bugs in packages, and make an interesting unoffical Debian target, I don't see it replacing the existing armhf port any time soon. For additional information about the Debian plans, see the article on LWN[9] that summarizes the discussion started by Steve McIntyre [10]. Arnd [1] https://wiki.debian.org/HelmutGrohne/rebootstrap [2] https://github.com/lmajewski/y2038_glibc/tree/y2038_edge [3] https://salsa.debian.org/glibc-team/glibc/-/tree/glibc-2.31 [4] https://github.com/lmajewski/y2038_glibc/commit/2f72ea2b6f6ee [5] https://sourceware.org/pipermail/libc-alpha/2020-February/111375.html [6] https://pastebin.com/fJYV2stF [7] https://bugs.llvm.org/show_bug.cgi?id=45138 [8] https://wiki.adelielinux.org/wiki/Project:Time64 [9] https://lwn.net/Articles/812767/ [10] https://lwn.net/ml/debian-devel/20200204131410.GF3043@tack.einval.com/

6 years

5
9
0 0

Re: [Y2038] Trying Debian/armhf rebootstrap with time64

by Arnd Bergmann

On Mon, Mar 16, 2020 at 11:12 PM Lukasz Majewski <lukma(a)denx.de> wrote: > > On Fri, Mar 13, 2020 at 9:22 PM Rich Felker <dalias(a)libc.org> wrote: > > > > - Removing the time32 symbols from the glibc shared object did > > > > not work as they are still used (a lot) internally, and by the > > > > testsuite. > > > > > > That they're used internally sounds like a major problem; anywhere > > > they're being used internally potentially has hidden Y2038 bugs. > > > This is also why I'm concerned about glibc's approach of not > > > building itself with _TIME_BITS=64, and just undefining it or doing > > > something else in the wrapper files for the legacy time32 symbols. > > > > I thought this was the long-term plan. Working on the ABI first and > > then changing the implementation may help speed up the timeline > > before distro-level work can start, but OTOH removing all the 32-bit > > codepaths from the implementation first makes it more likely to find > > all relevant bits. > > If I understood the question correctly - the problem is with having > glibc ABI consistent. This requires having 64 bit types for relevant > functions. For example the __clock_settime64 accepts struct > __timespec64 parameter which: > > - Is aliased to "normal" struct timespec on machines with > __WORDSIZE==64 (x32 is a special case) > > - The struct __timespec64 is used on 32 bit machines > > As a result the glibc is ready to handle 64 bit time always (with > clock_settime on __WORDSIZE==64 or clock_settime64 otherwise), as > exported struct timespec fields size vary depending on the machine for > which glibc is built. I think we all understand the need to duplicate each interface that passes a data type derived from time_t, and how the aliasing works, The point above is purely for the internal implementation. The approach that I have picked for the kernel and Rich did for musl was that internal code never sees the old __time_t definition for any data structure or function call, those are only used to define the wrappers for 32-bit architectures that provide the legacy interfaces. Arnd

6 years

1
0
0 0

Re: [Y2038] Trying Debian/armhf rebootstrap with time64

by Arnd Bergmann

[some mailing lists appear to have classified the earlier mail as spam, it was quite long and contained a lot of links. See https://lists.debian.org/debian-arm/2020/03/msg00032.html for the start of the thread if you did not get that] On Wed, Mar 11, 2020 at 3:37 PM Lukasz Majewski <lukma(a)denx.de> wrote: > > - stat()/fstat()/lstat(), nanosleep(), wait3()/wait4(), ppoll_chk() > > are some of the other interfaces that take a time_t based > > argument and need to grow a time64 version to avoid an ABI > > mismatch. > > The stat() and friends will use statx internally, which supports 64 bit > time from the outset. > Unfortunately, it hasn't been yet converted. > > As statx was added in 4.1 (IIRC) - after the minimal supported Linux > kernel version is bumped to this version (from 3.2 as now) it all will > be fixed. The problem I had with these was not on the kernel API side (I still have CONFIG_COMPAT_32BIT_TIME enabled for now) but on the application side. In particular, the 'struct stat' definition (when __USE_XOPEN2K8 is defined) contains struct timespec st_atim; and similar fields that are interpreted using 64-bit time_t in the application including the header, but with 32-bit time_t inside of the ___fxstat64() implementation in glibc. The problem is caused by the mismatched ABI, not by the time_t overflow, in the same way that happens in the nptl library callers and in the other interfaces I mentioned. This is also what seems to cause most of the testcase failures when the tests are built with __TIME_BITS=64. > > - The timeval prototype appears to be broken, as it's missing > > padding on architectures without native alignment of __time64 > > (e.g. i386) and on all big-endian architectures. > > > > You mean the one "exported" to the system or one, which is internal to > glibc (from ./include/time.h)? I mean in the installed headers, where I get (after preprocessing) typedef long long __time64_t; typedef long __suseconds_t; struct timeval { __time64_t tv_sec; __suseconds_t tv_usec; }; On i386 and m68k, this leads to a 12 byte structure when the kernel interfaces expect a 16 byte structure. All other 32-bit architectures add four byte padding at the end, so the size is correct, but on big-endian systems, kernel also expects padding *before* tv_usec, in the same way as the timespec definition does. IIRC the best way to handle this is with a 64-bit suseconds_t, e.g. by adding a __suseconds64_t defined the same way as __time64_t. > > I have spent more time on this now than I had planned, and don't > > expect to do further work on it anytime soon, but I hope my summary > > is useful to others that are going to need this later. I can > > obviously share my patches and build artifacts if anyone needs them. > > Could you upload them to any server? (kernel.org or github)? I have uploaded the modified debian-glibc and rebootstrap sources to https://git.linaro.org/people/arnd/ now, this should be all that's needed to recreate the build, using these steps: - build an x86-64 debian glibc-2.31 package (binary plus source) based on the glibc package data - create a pbuilder instance with that available as a source to apt - log into the pbuilder and run the modified bootstrap.sh according to information on the pbuilder web page. The binary packages I created are not as useful, as they would not work with any build of glibc, neither the version I built, nor any fixed one. I could find a way to send that to you in private, but it's hundreds of megabytes. Unfortunately I lost the build logs during a crash yesterday. > > There are two additional approaches that would likely get a Debian > > bootstrap further, but that I have not tried as they were previously > > dismissed: > > > > * Adding a time64 armhf as a separate (incompatible) target in glibc > > that defines __TIMESIZE==64 and a 64-bit __time_t would avoid > > most of the remaining ABI issues and put armhf-time64 in the same > > category as riscv32 and arc, but this idea was so far rejected by > > the glibc maintainers. > > As fair as I know riscv32 and arc will use generic syscall interface. > The arm32 bit doesn't support it - so the code from those two > aforementioned ports will not be used. The differences between the generic syscall interface and the arm version are much smaller than ABI differences between the ABIs for 32-bit __time_t and the __time_t == __time64_t version. In particular, as such a new port could mandate a minimum kernel of v5.1, it could just use all the time64 syscalls, the split sysvipc and statx as a baseline. Arnd

6 years

1
0
0 0

[GIT PULL] compat-ioctl fix for v5.6

by Arnd Bergmann

The following changes since commit 77b9040195dea3fcddf19e136c9e99a501351778: compat_ioctl: simplify the implementation (2020-01-03 09:42:52 +0100) are available in the Git repository at: git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git tags/compat-ioctl-fix for you to fetch changes up to 0a061743af93f472687b8c69b0d539d1f12f3fd2: compat_ioctl: fix FIONREAD on devices (2020-02-08 18:02:54 +0100) ---------------------------------------------------------------- compat-ioctl fix for v5.6 One patch in the compat-ioctl series broke 32-bit rootfs for multiple people testing on 64-bit kernels. Let's fix it in -rc1 before others run into the same issue. ---------------------------------------------------------------- Arnd Bergmann (1): compat_ioctl: fix FIONREAD on devices fs/ioctl.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)

6 years, 1 month

2
1
0 0

[PATCH] generic/402: fix for updated behavior of timestamp limits

by Deepa Dinamani

The mount behavior will not be altered because of the unsupported timestamps on the filesystems. Adjust the test accordingly. An updated series to be posted after the merge window is hosted at <https://github.com/deepa-hub/vfs/tree/limits> Signed-off-by: Deepa Dinamani <deepa.kernel(a)gmail.com> --- common/rc | 36 +++++++++--------- tests/generic/402 | 87 ++++++++++++++++--------------------------- tests/generic/402.out | 2 +- 3 files changed, 53 insertions(+), 72 deletions(-) diff --git a/common/rc b/common/rc index 25203bb4..39a2deb0 100644 --- a/common/rc +++ b/common/rc @@ -1959,16 +1959,9 @@ _run_aiodio() return $status } -# this test requires y2038 sysfs switch and filesystem -# timestamp ranges support. -_require_y2038() +_require_timestamp_range() { local device=${1:-$TEST_DEV} - local sysfsdir=/proc/sys/fs/fs-timestamp-check-on - - if [ ! -e $sysfsdir ]; then - _notrun "no kernel support for y2038 sysfs switch" - fi local tsmin tsmax read tsmin tsmax <<<$(_filesystem_timestamp_range $device) @@ -1980,23 +1973,32 @@ _require_y2038() _filesystem_timestamp_range() { local device=${1:-$TEST_DEV} + u32max=$(((1<<32)-1)) + s32min=-$((1<<31)) + s32max=$(((1<<31)-1)) + s64max=$(((1<<63)-1)) + s64min=$((1<<63)) + case $FSTYP in - ext4) + ext2) + echo "$s32min $s32max" + ;; + ext3|ext4) if [ $(dumpe2fs -h $device 2>/dev/null | grep "Inode size:" | cut -d: -f2) -gt 128 ]; then - echo "-2147483648 15032385535" + printf "%d %d\n" $s32min 0x37fffffff else - echo "-2147483648 2147483647" + echo "$s32min $s32max" fi ;; - xfs) - echo "-2147483648 2147483647" - ;; jfs) - echo "0 4294967295" + echo "0 $u32max" ;; - f2fs) - echo "-2147483648 2147483647" + xfs) + echo "$s32min $s32max" + ;; + btrfs) + echo "$s64min $s64max" ;; *) echo "-1 -1" diff --git a/tests/generic/402 b/tests/generic/402 index f742fedd..dd136ec2 100755 --- a/tests/generic/402 +++ b/tests/generic/402 @@ -4,15 +4,10 @@ # # FS QA Test 402 # -# Tests to verify policy for filesystem timestamps for -# supported ranges: -# 1. Verify filesystem rw mount according to sysctl -# timestamp_supported. -# 2. Verify timestamp clamping for timestamps beyond max -# timestamp supported. +# Test to verify filesystem timestamps for supported ranges. # -# Exit status 1: either or both tests above fail. -# Exit status 0: both the above tests pass. +# Exit status 1: test failed. +# Exit status 0: test passed. # seq=`basename $0` seqres=$RESULT_DIR/$seq @@ -49,47 +44,59 @@ check_stat() prev_timestamp="$timestamp;$timestamp" if [ $prev_timestamp != $stat_timestamp ]; then echo "$prev_timestamp != $stat_timestamp" | tee -a $seqres.full + return 1 fi + return 0 } run_test_individual() { + fail=0 file=$1 timestamp=$2 update_time=$3 # check if the time needs update if [ $update_time -eq 1 ]; then - echo "Updating file: $file to timestamp `date -d @$timestamp`" >> $seqres.full + echo "Updating file: $file to timestamp $timestamp" >> $seqres.full $XFS_IO_PROG -f -c "utimes $timestamp 0 $timestamp 0" $file if [ $? -ne 0 ]; then echo "Failed to update times on $file" | tee -a $seqres.full + fail=1 fi fi - tsclamp=$(($timestamp>$tsmax?$tsmax:$timestamp)) - echo "Checking file: $file Updated timestamp is `date -d @$tsclamp`" >> $seqres.full - check_stat $file $tsclamp + tsclamp=$((timestamp<tsmin?tsmin:timestamp>tsmax?tsmax:timestamp)) + echo "Checking file: $file Updated timestamp is $tsclamp" >> $seqres.full + if ! check_stat $file $tsclamp; then + fail=1 + fi + return $fail } run_test() { + fail=0 update_time=$1 n=1 for TIME in "${TIMESTAMPS[@]}"; do - run_test_individual ${SCRATCH_MNT}/test_$n $TIME $update_time + if ! run_test_individual ${SCRATCH_MNT}/test_$n $TIME $update_time; then + fail=1 + fi ((n++)) done + + return $fail } _scratch_mkfs &>> $seqres.full 2>&1 || _fail "mkfs failed" -_require_y2038 $SCRATCH_DEV +_require_timestamp_range $SCRATCH_DEV read tsmin tsmax <<<$(_filesystem_timestamp_range $SCRATCH_DEV) -echo min supported timestamp $tsmin $(date --date=@$tsmin) >> $seqres.full -echo max supported timestamp $tsmax $(date --date=@$tsmax) >> $seqres.full +echo min supported timestamp $tsmin >> $seqres.full +echo max supported timestamp $tsmax >> $seqres.full # Test timestamps array @@ -97,45 +104,14 @@ declare -a TIMESTAMPS=( $tsmin 0 $tsmax + $((tsmax/2)) $((tsmax+1)) - 4294967295 - 8589934591 - 34359738367 ) -# Max timestamp is hardcoded to Mon Jan 18 19:14:07 PST 2038 -sys_tsmax=2147483647 -echo "max timestamp that needs to be supported by fs for rw mount is" \ - "$((sys_tsmax+1)) $(date --date=@$((sys_tsmax+1)))" >> $seqres.full - -read ts_check <<<$(cat /proc/sys/fs/fs-timestamp-check-on) - _scratch_mount result=$? -if [ $ts_check -ne 0 ]; then - echo "sysctl filesystem timestamp check is on" >> $seqres.full - # check for mount failure if the minimum requirement for max timestamp - # supported is not met. - if [ $sys_tsmax -ge $tsmax ]; then - if [ $result -eq 0 ]; then - echo "mount test failed" | tee -a $seqres.full - exit - fi - else - if [ $result -ne 0 ]; then - echo "failed to mount $SCRATCH_DEV" | tee -a $seqres.full - exit - fi - fi -else - # if sysctl switch is off then mount should succeed always. - echo "sysctl filesystem timestamp check is off" >> $seqres.full - if [ $result -ne 0 ]; then - echo "failed to mount $SCRATCH_DEV and timestamp check is off" >> $seqres.full - exit - fi -fi +status=0 # Begin test case 1 echo "In memory timestamps update test start" >> $seqres.full @@ -143,7 +119,9 @@ echo "In memory timestamps update test start" >> $seqres.full # update time on the file update_time=1 -run_test $update_time +if ! run_test $update_time; then + status=1 +fi echo "In memory timestamps update complete" >> $seqres.full @@ -162,12 +140,13 @@ update_time=0 echo "On disk timestamps update test start" >> $seqres.full # Re-run test -run_test $update_time +if ! run_test $update_time; then + status=1 +fi echo "On disk timestamps update test complete" >> $seqres.full -echo "y2038 inode timestamp tests completed successfully" +echo "inode timestamp tests completed status $status" # success, all done -status=0 -exit +exit $status diff --git a/tests/generic/402.out b/tests/generic/402.out index 6c5b9308..4500e6c7 100644 --- a/tests/generic/402.out +++ b/tests/generic/402.out @@ -1,2 +1,2 @@ QA output created by 402 -y2038 inode timestamp tests completed successfully +inode timestamp tests completed status 0 -- 2.17.1

6 years, 2 months

6
33
0 0

[GIT PULL] y2038: core, driver and file system changes

by Arnd Bergmann

The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a: Linux 5.5-rc1 (2019-12-08 14:57:55 -0800) are available in the Git repository at: git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git tags/y2038-drivers-for-v5.6-signed for you to fetch changes up to c4e71212a245017d2ab05f322f7722f0b87a55da: Revert "drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC" (2020-01-28 23:24:23 +0100) ---------------------------------------------------------------- y2038: core, driver and file system changes These are updates to device drivers and file systems that for some reason or another were not included in the kernel in the previous y2038 series. I've gone through all users of time_t again to make sure the kernel is in a long-term maintainable state, replacing all remaining references to time_t with safe alternatives. Some related parts of the series were picked up into the nfsd, xfs, alsa and v4l2 trees. A final set of patches in linux-mm removes the now unused time_t/timeval/timespec types and helper functions after all five branches are merged for linux-5.6, ensuring that no new users get merged. As a result, linux-5.6, or my backport of the patches to 5.4 [1], should be the first release that can serve as a base for a 32-bit system designed to run beyond year 2038, with a few remaining caveats: - All user space must be compiled with a 64-bit time_t, which will be supported in the coming musl-1.2 and glibc-2.32 releases, along with installed kernel headers from linux-5.6 or higher. - Applications that use the system call interfaces directly need to be ported to use the time64 syscalls added in linux-5.1 in place of the existing system calls. This impacts most users of futex() and seccomp() as well as programming languages that have their own runtime environment not based on libc. - Applications that use a private copy of kernel uapi header files or their contents may need to update to the linux-5.6 version, in particular for sound/asound.h, xfs/xfs_fs.h, linux/input.h, linux/elfcore.h, linux/sockios.h, linux/timex.h and linux/can/bcm.h. - A few remaining interfaces cannot be changed to pass a 64-bit time_t in a compatible way, so they must be configured to use CLOCK_MONOTONIC times or (with a y2106 problem) unsigned 32-bit timestamps. Most importantly this impacts all users of 'struct input_event'. - All y2038 problems that are present on 64-bit machines also apply to 32-bit machines. In particular this affects file systems with on-disk timestamps using signed 32-bit seconds: ext4 with ext3-style small inodes, ext2, xfs (to be fixed soon) and ufs. Changes since v1 [2]: - Add Acks I received - Rebase to v5.5-rc1, dropping patches that got merged already - Add NFS, XFS and the final three patches from another series - Rewrite etnaviv patches - Add one late revert to avoid an etnaviv regression [1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=… [2] https://lore.kernel.org/lkml/20191108213257.3097633-1-arnd@arndb.de/ ---------------------------------------------------------------- Arnd Bergmann (21): fat: use prandom_u32() for i_generation dlm: use SO_SNDTIMEO_NEW instead of SO_SNDTIMEO_OLD xtensa: ISS: avoid struct timeval um: ubd: use 64-bit time_t where possible acct: stop using get_seconds() tsacct: add 64-bit btime field packet: clarify timestamp overflow hostfs: pass 64-bit timestamps to/from user space hfs/hfsplus: use 64-bit inode timestamps drm/msm: avoid using 'timespec' drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC drm/etnaviv: avoid deprecated timespec sunrpc: convert to time64_t for expiry nfs: use time64_t internally nfs: fix timstamp debug prints nfs: fscache: use timespec64 in inode auxdata y2038: remove obsolete jiffies conversion functions y2038: rename itimerval to __kernel_old_itimerval y2038: sparc: remove use of struct timex y2038: sh: remove timeval/timespec usage from headers Revert "drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC" arch/sh/include/uapi/asm/sockios.h | 4 +- arch/sparc/kernel/sys_sparc_64.c | 33 ++++++------ arch/um/drivers/cow.h | 2 +- arch/um/drivers/cow_user.c | 7 +-- arch/um/drivers/ubd_kern.c | 10 ++-- arch/um/include/shared/os.h | 2 +- arch/um/os-Linux/file.c | 2 +- .../platforms/iss/include/platform/simcall.h | 4 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 11 ++-- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 11 ++-- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +- drivers/gpu/drm/etnaviv/etnaviv_gem.h | 2 +- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 +- drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 5 +- drivers/gpu/drm/msm/msm_drv.h | 3 +- fs/dlm/lowcomms.c | 6 +-- fs/fat/inode.c | 3 +- fs/hfs/hfs_fs.h | 28 ++++++++--- fs/hfs/inode.c | 4 +- fs/hfsplus/hfsplus_fs.h | 28 +++++++++-- fs/hfsplus/inode.c | 12 ++--- fs/hostfs/hostfs.h | 22 ++++---- fs/hostfs/hostfs_kern.c | 15 +++--- fs/nfs/fscache-index.c | 6 ++- fs/nfs/fscache.c | 18 ++++--- fs/nfs/fscache.h | 8 +-- fs/nfs/nfs4xdr.c | 10 ++-- include/linux/jiffies.h | 20 -------- include/linux/sunrpc/cache.h | 42 +++++++++------- include/linux/sunrpc/gss_api.h | 4 +- include/linux/sunrpc/gss_krb5.h | 2 +- include/linux/syscalls.h | 9 ++-- include/uapi/linux/acct.h | 2 + include/uapi/linux/taskstats.h | 6 ++- include/uapi/linux/time_types.h | 5 ++ include/uapi/linux/timex.h | 2 + kernel/acct.c | 4 +- kernel/time/itimer.c | 18 +++---- kernel/time/time.c | 58 ++-------------------- kernel/tsacct.c | 9 ++-- net/packet/af_packet.c | 27 ++++++---- net/sunrpc/auth_gss/gss_krb5_mech.c | 12 +++-- net/sunrpc/auth_gss/gss_krb5_seal.c | 8 +-- net/sunrpc/auth_gss/gss_krb5_unseal.c | 6 +-- net/sunrpc/auth_gss/gss_krb5_wrap.c | 16 +++--- net/sunrpc/auth_gss/gss_mech_switch.c | 2 +- net/sunrpc/auth_gss/svcauth_gss.c | 6 +-- net/sunrpc/cache.c | 16 +++--- net/sunrpc/svcauth_unix.c | 10 ++-- 49 files changed, 283 insertions(+), 266 deletions(-)

6 years, 2 months

2
1
0 0

[PATCH v2 00/24] drivers, fs: y2038 updates

by Arnd Bergmann

These are updates to devidce drivers and file systems that for some reason or another were not included in the kernel in the previous y2038 series. I've gone through all users of time_t again to make sure the kernel is in a long-term maintainable state. Posting these as a series for better organization, but each change here is applicable standalone. Please merge, review, ack/nack etc as you see fit. I will add these to my y2038 branch [1] for linux-next, but can keep rebasing for feedback and to remove any patches that get picked up by a maintainer. Changes since v1 [2]: - Add Acks I received - Rebase to v5.5-rc1, droping patches that got merged already - Add NFS, XFS and the final three patches from another series - Rewrite etnaviv patches Arnd [1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=… [2] https://lore.kernel.org/lkml/20191108213257.3097633-1-arnd@arndb.de/ Arnd Bergmann (24): Input: input_event: fix struct padding on sparc64 fat: use prandom_u32() for i_generation dlm: use SO_SNDTIMEO_NEW instead of SO_SNDTIMEO_OLD xtensa: ISS: avoid struct timeval um: ubd: use 64-bit time_t where possible acct: stop using get_seconds() tsacct: add 64-bit btime field packet: clarify timestamp overflow quota: avoid time_t in v1_disk_dqblk definition hostfs: pass 64-bit timestamps to/from user space hfs/hfsplus: use 64-bit inode timestamps drm/msm: avoid using 'timespec' drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC drm/etnaviv: avoid deprecated timespec sunrpc: convert to time64_t for expiry nfs: use time64_t internally nfs: fix timstamp debug prints nfs: fscache: use timespec64 in inode auxdata xfs: rename compat_time_t to old_time32_t xfs: disallow broken ioctls without compat-32-bit-time xfs: quota: move to time64_t interfaces y2038: remove obsolete jiffies conversion functions y2038: rename itimerval to __kernel_old_itimerval y2038: sparc: remove use of struct timex arch/sparc/kernel/sys_sparc_64.c | 29 +++++----- arch/um/drivers/cow.h | 2 +- arch/um/drivers/cow_user.c | 7 ++- arch/um/drivers/ubd_kern.c | 10 ++-- arch/um/include/shared/os.h | 2 +- arch/um/os-Linux/file.c | 2 +- .../platforms/iss/include/platform/simcall.h | 4 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 20 ++++--- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 11 ++-- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +- drivers/gpu/drm/etnaviv/etnaviv_gem.h | 2 +- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 +- drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 5 +- drivers/gpu/drm/msm/msm_drv.h | 3 +- drivers/input/evdev.c | 14 ++--- drivers/input/misc/uinput.c | 14 +++-- fs/dlm/lowcomms.c | 6 +- fs/fat/inode.c | 3 +- fs/hfs/hfs_fs.h | 28 +++++++-- fs/hfs/inode.c | 4 +- fs/hfsplus/hfsplus_fs.h | 28 +++++++-- fs/hfsplus/inode.c | 12 ++-- fs/hostfs/hostfs.h | 22 ++++--- fs/hostfs/hostfs_kern.c | 15 +++-- fs/nfs/fscache-index.c | 6 +- fs/nfs/fscache.c | 18 ++++-- fs/nfs/fscache.h | 8 ++- fs/nfs/nfs4xdr.c | 10 ++-- fs/quota/quotaio_v1.h | 6 +- fs/xfs/xfs_dquot.c | 6 +- fs/xfs/xfs_ioctl.c | 26 +++++++++ fs/xfs/xfs_ioctl32.c | 2 +- fs/xfs/xfs_ioctl32.h | 2 +- fs/xfs/xfs_qm.h | 6 +- fs/xfs/xfs_quotaops.c | 6 +- fs/xfs/xfs_trans_dquot.c | 8 ++- include/linux/jiffies.h | 20 ------- include/linux/sunrpc/cache.h | 42 ++++++++------ include/linux/sunrpc/gss_api.h | 4 +- include/linux/sunrpc/gss_krb5.h | 2 +- include/linux/syscalls.h | 9 ++- include/uapi/linux/acct.h | 2 + include/uapi/linux/input.h | 1 + include/uapi/linux/taskstats.h | 6 +- include/uapi/linux/time_types.h | 5 ++ include/uapi/linux/timex.h | 2 + kernel/acct.c | 4 +- kernel/time/itimer.c | 18 +++--- kernel/time/time.c | 58 ++----------------- kernel/tsacct.c | 9 ++- net/packet/af_packet.c | 27 +++++---- net/sunrpc/auth_gss/gss_krb5_mech.c | 12 +++- net/sunrpc/auth_gss/gss_krb5_seal.c | 8 +-- net/sunrpc/auth_gss/gss_krb5_unseal.c | 6 +- net/sunrpc/auth_gss/gss_krb5_wrap.c | 16 ++--- net/sunrpc/auth_gss/gss_mech_switch.c | 2 +- net/sunrpc/auth_gss/svcauth_gss.c | 6 +- net/sunrpc/cache.c | 16 ++--- net/sunrpc/svcauth_unix.c | 10 ++-- 59 files changed, 351 insertions(+), 290 deletions(-) -- 2.20.0 Cc: jdike(a)addtoit.com Cc: richard(a)nod.at Cc: jcmvbkbc(a)gmail.com Cc: stefanr(a)s5r6.in-berlin.de Cc: l.stach(a)pengutronix.de Cc: linux+etnaviv(a)armlinux.org.uk Cc: christian.gmeiner(a)gmail.com Cc: airlied(a)linux.ie Cc: daniel(a)ffwll.ch Cc: robdclark(a)gmail.com Cc: sean(a)poorly.run Cc: valdis.kletnieks(a)vt.edu Cc: gregkh(a)linuxfoundation.org Cc: ccaulfie(a)redhat.com Cc: teigland(a)redhat.com Cc: hirofumi(a)mail.parknet.co.jp Cc: jack(a)suse.com Cc: davem(a)davemloft.net Cc: fw(a)strlen.de Cc: viro(a)zeniv.linux.org.uk Cc: rfontana(a)redhat.com Cc: tglx(a)linutronix.de Cc: linux-um(a)lists.infradead.org Cc: linux1394-devel(a)lists.sourceforge.net Cc: etnaviv(a)lists.freedesktop.org Cc: dri-devel(a)lists.freedesktop.org Cc: linux-arm-msm(a)vger.kernel.org Cc: freedreno(a)lists.freedesktop.org Cc: devel(a)driverdev.osuosl.org Cc: cluster-devel(a)redhat.com Cc: linux-fsdevel(a)vger.kernel.org Cc: netdev(a)vger.kernel.org Cc: trond.myklebust(a)hammerspace.com Cc: anna.schumaker(a)netapp.com Cc: linux-nfs(a)vger.kernel.org Cc: linux-xfs(a)vger.kernel.org Cc: darrick.wong(a)oracle.com Cc: sparclinux(a)vger.kernel.org

6 years, 2 months

8
45
0 0

[PATCH] hcidump: add support for time64 based libc

by Arnd Bergmann

musl is moving to a default of 64-bit time_t on all architectures, glibc will follow later. This breaks reading timestamps through cmsg data with the HCI_TIME_STAMP socket option. Change both copies of hcidump to work on all architectures. This also fixes x32, which has never worked, and carefully avoids breaking sparc64, which is another special case. I have only compiled this on one architecture, please at least test it to ensure there are no regressions. The toolchain binaries from http://musl.cc/ should allow testing with a 64-bit time_t, but it may be hard to build all the dependencies first. libpcap has the same bug and needs a similar fix to work on future 32-bit Linux systems. Everything else apparently uses the generic SO_TIMESTAMP timestamps, which work correctly when using new enough kernels with a time64 libc. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- monitor/hcidump.c | 32 +++++++++++++++++++++++++++++++- tools/hcidump.c | 33 +++++++++++++++++++++++++++++++-- 2 files changed, 62 insertions(+), 3 deletions(-) diff --git a/monitor/hcidump.c b/monitor/hcidump.c index 8b6f846d3..6d2330287 100644 --- a/monitor/hcidump.c +++ b/monitor/hcidump.c @@ -107,6 +107,36 @@ static int open_hci_dev(uint16_t index) return fd; } +static struct timeval hci_tstamp_read(void *data) +{ + struct timeval tv; + + /* + * On 64-bit architectures, the data matches the timeval + * format. Note that on sparc64 this is different from + * all others. + */ + if (sizeof(long) == 8) { + memcpy(&tv, data, sizeof(tv)); + } + + /* + * On 32-bit architectures, the timeval definition may + * use 32-bit or 64-bit members depending on the C + * library and architecture. + * The cmsg data however always contains a pair of + * 32-bit values. Interpret as unsigned to make it work + * past y2038. + */ + if (sizeof(long) == 4) { + unsigned int *stamp = data; + tv.tv_sec = stamp[0]; + tv.tv_usec = stamp[1]; + } + + return tv; +} + static void device_callback(int fd, uint32_t events, void *user_data) { struct hcidump_data *data = user_data; @@ -150,7 +180,7 @@ static void device_callback(int fd, uint32_t events, void *user_data) memcpy(&dir, CMSG_DATA(cmsg), sizeof(dir)); break; case HCI_CMSG_TSTAMP: - memcpy(&ctv, CMSG_DATA(cmsg), sizeof(ctv)); + ctv = hci_tstamp_read(CMSG_DATA(cmsg)); tv = &ctv; break; } diff --git a/tools/hcidump.c b/tools/hcidump.c index 33d429b6c..be14d0930 100644 --- a/tools/hcidump.c +++ b/tools/hcidump.c @@ -136,6 +136,36 @@ static inline int write_n(int fd, char *buf, int len) return t; } +static struct timeval hci_tstamp_read(void *data) +{ + struct timeval tv; + + /* + * On 64-bit architectures, the data matches the timeval + * format. Note that on sparc64 this is different from + * all others. + */ + if (sizeof(long) == 8) { + memcpy(&tv, data, sizeof(tv)); + } + + /* + * On 32-bit architectures, the timeval definition may + * use 32-bit or 64-bit members depending on the C + * library and architecture. + * The cmsg data however always contains a pair of + * 32-bit values. Interpret as unsigned to make it work + * past y2038. + */ + if (sizeof(long) == 4) { + unsigned int *stamp = data; + tv.tv_sec = stamp[0]; + tv.tv_usec = stamp[1]; + } + + return tv; +} + static int process_frames(int dev, int sock, int fd, unsigned long flags) { struct cmsghdr *cmsg; @@ -230,8 +260,7 @@ static int process_frames(int dev, int sock, int fd, unsigned long flags) frm.in = (uint8_t) dir; break; case HCI_CMSG_TSTAMP: - memcpy(&frm.ts, CMSG_DATA(cmsg), - sizeof(struct timeval)); + frm.ts = hci_tstamp_read(CMSG_DATA(cmsg)); break; } cmsg = CMSG_NXTHDR(&msg, cmsg); -- 2.20.0

6 years, 2 months

3
5
0 0

[RFC] y2038: HCI_TIME_STAMP with time64

by Arnd Bergmann

I noticed earlier this week that the HCI_CMSG_TSTAMP/HCI_TIME_STAMP interface has no time64 equivalent, as we apparently missed that when converting the normal socket timestamps to support both time32 and time64 variants of the sockopt and cmsg data. The interface was originally added back in 2002 by Maksim Krasnyanskiy when bluetooth support first became non-experimental. When using HCI_TIME_STAMP on a 32-bit system with a time64 libc, users will interpret the { s32 tv_sec; s32 tv_usec } layout of the kernel as { s64 tv_sec; ... }, which puts complete garbage into the timestamp regardless of whether this code runs before or after y2038. From looking at codesearch.debian.org, I found two users of this: libpcap and hcidump. There are probably others that are not part of Debian. Fixing this the same was as normal socket timestamps is not possible because include/net/bluetooth/hci.h is not an exported UAPI header. This means any changes to it for defining HCI_TIME_STAMP conditionally would be ignored by applications that use a different copy of the header. I can see three possible ways forward: 1. move include/net/bluetooth/hci.h to include/uapi/, add a conditional definition of HCI_TIME_STAMP and make the kernel code support both formats. Then change applications to rely on that version of header file to get the correct definition but not change application code. 2. Leave the kernel completely unchanged and modify only the users to not expect the output to be a 'struct timeval' but interpret as as { uint32_t tv_sec; int32_t tv_usec; } structure on 32-bit architectures, which will work until the unsigned time overflows 86 years from now in 2106 (same as the libpcap on-disk format). 3. Add support for the normal SO_TIMESTAMPNS_NEW sockopt in HCI, providing timestamps in the unambiguous { long long tv_sec; long long tv_nsec; } format to user space, and change applications to use that if supported by the kernel. Arnd

6 years, 2 months

2
3
0 0

[PATCH 0/3] y2038: remove unused interfaces

by Arnd Bergmann

Hi Andrew, Can you add these to your patches for linux-5.6? I have y2038 cleanups for sound, v4l, nfsd, scsi and xfs that are merged in the respective subsystem trees, as well as another series of individual patches queued up in my own y2038 tree. With all that work merged, most of include/linux/time32.h and some other related code can be removed from the kernel, so it would be good to send these at the end of the coming merge window, and to give them some more testing in linux-next to make sure we don't gain any new users. Arnd Arnd Bergmann (3): y2038: remove ktime to/from timespec/timeval conversion y2038: remove unused time32 interfaces y2038: hide timeval/timespec/itimerval/itimerspec types include/linux/compat.h | 29 ----- include/linux/ktime.h | 37 ------ include/linux/time32.h | 154 +------------------------ include/linux/timekeeping32.h | 32 ----- include/linux/types.h | 5 - include/uapi/asm-generic/posix_types.h | 2 + include/uapi/linux/time.h | 22 ++-- kernel/compat.c | 64 ---------- kernel/time/time.c | 43 ------- 9 files changed, 15 insertions(+), 373 deletions(-) -- Cc: y2038(a)lists.linaro.org Cc: linux-kernel(a)vger.kernel.org Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Deepa Dinamani <deepa.kernel(a)gmail.com> 2.20.0

6 years, 2 months

2
6
0 0

[PATCH 1/3] xfs: rename compat_time_t to old_time32_t

by Arnd Bergmann

The compat_time_t type has been removed everywhere else, as most users rely on old_time32_t for both native and compat mode handling of 32-bit time_t. Remove the last one in xfs. Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- fs/xfs/xfs_ioctl32.c | 2 +- fs/xfs/xfs_ioctl32.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_ioctl32.c b/fs/xfs/xfs_ioctl32.c index c4c4f09113d3..a49bd80b2c3b 100644 --- a/fs/xfs/xfs_ioctl32.c +++ b/fs/xfs/xfs_ioctl32.c @@ -107,7 +107,7 @@ xfs_ioctl32_bstime_copyin( xfs_bstime_t *bstime, compat_xfs_bstime_t __user *bstime32) { - compat_time_t sec32; /* tv_sec differs on 64 vs. 32 */ + old_time32_t sec32; /* tv_sec differs on 64 vs. 32 */ if (get_user(sec32, &bstime32->tv_sec) || get_user(bstime->tv_nsec, &bstime32->tv_nsec)) diff --git a/fs/xfs/xfs_ioctl32.h b/fs/xfs/xfs_ioctl32.h index 8c7743cd490e..053de7d894cd 100644 --- a/fs/xfs/xfs_ioctl32.h +++ b/fs/xfs/xfs_ioctl32.h @@ -32,7 +32,7 @@ #endif typedef struct compat_xfs_bstime { - compat_time_t tv_sec; /* seconds */ + old_time32_t tv_sec; /* seconds */ __s32 tv_nsec; /* and nanoseconds */ } compat_xfs_bstime_t; -- 2.20.0

6 years, 2 months

3
11
0 0

[PATCH v3 1/2] xfs: rename compat_time_t to old_time32_t

by Arnd Bergmann

The compat_time_t type has been removed everywhere else, as most users rely on old_time32_t for both native and compat mode handling of 32-bit time_t. Remove the last one in xfs. Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- As explained in https://www.spinics.net/lists/linux-xfs/msg35524.html I've dropped the patch "xfs: disallow broken ioctls without compat-32-bit-time" for this submission but will get to that later when doing that as a treewide change. Please apply these two for v5.6 in the meantime so we can kill off compat_time_t, time_t and get_seconds() for good. fs/xfs/xfs_ioctl32.c | 2 +- fs/xfs/xfs_ioctl32.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_ioctl32.c b/fs/xfs/xfs_ioctl32.c index bd07a79ca3c0..9ab0263586da 100644 --- a/fs/xfs/xfs_ioctl32.c +++ b/fs/xfs/xfs_ioctl32.c @@ -108,7 +108,7 @@ xfs_ioctl32_bstime_copyin( xfs_bstime_t *bstime, compat_xfs_bstime_t __user *bstime32) { - compat_time_t sec32; /* tv_sec differs on 64 vs. 32 */ + old_time32_t sec32; /* tv_sec differs on 64 vs. 32 */ if (get_user(sec32, &bstime32->tv_sec) || get_user(bstime->tv_nsec, &bstime32->tv_nsec)) diff --git a/fs/xfs/xfs_ioctl32.h b/fs/xfs/xfs_ioctl32.h index 8c7743cd490e..053de7d894cd 100644 --- a/fs/xfs/xfs_ioctl32.h +++ b/fs/xfs/xfs_ioctl32.h @@ -32,7 +32,7 @@ #endif typedef struct compat_xfs_bstime { - compat_time_t tv_sec; /* seconds */ + old_time32_t tv_sec; /* seconds */ __s32 tv_nsec; /* and nanoseconds */ } compat_xfs_bstime_t; -- 2.20.0

6 years, 2 months

3
3
0 0

[GIT PULL v3 00/27] block, scsi: final compat_ioctl cleanup

by Arnd Bergmann

Hi Martin, James, If this version seems ok to everyone, please pull into the scsi tree. The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a: Linux 5.5-rc4 (2019-12-08 14:57:55 -0800) are available in the Git repository at: git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git tags/block-ioctl-cleanup-5.6 for you to fetch changes up to d1329555e914109846283e469b5077e7500ecfaf Documentation: document ioctl interfaces better (2019-12-17 22:45:18 +0100) ---------------------------------------------------------------- block, scsi: final compat_ioctl cleanup This series concludes the work I did for linux-5.5 on the compat_ioctl() cleanup, killing off fs/compat_ioctl.c and block/compat_ioctl.c by moving everything into drivers. Overall this would be a reduction both in complexity and line count, but as I'm also adding documentation the overall number of lines increases in the end. My plan was originally to keep the SCSI and block parts separate. This did not work easily because of interdependencies: I cannot do the final SCSI cleanup in a good way without first addressing the CDROM ioctls, so this is one series that I hope could be merged through either the block or the scsi git trees, or possibly both if you can pull in the same branch. The series comes in these steps: 1. clean up the sg v3 interface as suggested by Linus. I have talked about this with Doug Gilbert as well, and he would rebase his sg v4 patches on top of "compat: scsi: sg: fix v3 compat read/write interface" 2. Actually moving handlers out of block/compat_ioctl.c and block/scsi_ioctl.c into drivers, mixed in with cleanup patches 3. Document how to do this right. I keep getting asked about this, and it helps to point to some documentation file. The branch is based on another one that fixes a couple of bugs found during the creation of this series. Changes since v2: - Rebase to v5.5-rc4, which contains the earlier bugfixes - Fix sr_block_compat_ioctl() error handling bug found by Ben Hutchings - Fix idecd_locked_compat_ioctl() compat_ptr() bug - Don't try to handle HDIO_DRIVE_TASKFILE in drivers/ide - More documentation improvements Changes since v1: - move out the bugfixes into a branch for itself - clean up scsi sg driver further as suggested by Christoph Hellwig - avoid some ifdefs by moving compat_ptr() out of asm/compat.h - split out the blkdev_compat_ptr_ioctl function; bug spotted by Ben Hutchings - Improve formatting of documentation [1] https://lore.kernel.org/linux-block/20191211204306.1207817-1-arnd@arndb.de/… ---------------------------------------------------------------- Arnd Bergmann (22): compat: ARM64: always include asm-generic/compat.h compat: provide compat_ptr() on all architectures compat: scsi: sg: fix v3 compat read/write interface compat_ioctl: block: add blkdev_compat_ptr_ioctl compat_ioctl: ubd, aoe: use blkdev_compat_ptr_ioctl compat_ioctl: move CDROM_SEND_PACKET handling into scsi compat_ioctl: move CDROMREADADIO to cdrom.c compat_ioctl: cdrom: handle CDROM_LAST_WRITTEN compat_ioctl: block: handle cdrom compat ioctl in non-cdrom drivers compat_ioctl: add scsi_compat_ioctl compat_ioctl: bsg: add handler compat_ioctl: ide: floppy: add handler compat_ioctl: scsi: move ioctl handling into drivers compat_ioctl: move sys_compat_ioctl() to ioctl.c compat_ioctl: simplify the implementation compat_ioctl: move cdrom commands into cdrom.c compat_ioctl: scsi: handle HDIO commands from drivers compat_ioctl: move HDIO ioctl handling into drivers/ide compat_ioctl: block: move blkdev_compat_ioctl() into ioctl.c compat_ioctl: block: simplify compat_blkpg_ioctl() compat_ioctl: simplify up block/ioctl.c Documentation: document ioctl interfaces better Documentation/core-api/index.rst | 1 + Documentation/core-api/ioctl.rst | 253 +++++++++++++++ arch/arm64/include/asm/compat.h | 22 +- arch/mips/include/asm/compat.h | 18 -- arch/parisc/include/asm/compat.h | 17 - arch/powerpc/include/asm/compat.h | 17 - arch/powerpc/oprofile/backtrace.c | 2 +- arch/s390/include/asm/compat.h | 6 +- arch/sparc/include/asm/compat.h | 17 - arch/um/drivers/ubd_kern.c | 1 + arch/x86/include/asm/compat.h | 17 - block/Makefile | 1 - block/bsg.c | 1 + block/compat_ioctl.c | 427 ------------------------- block/ioctl.c | 319 ++++++++++++++---- block/scsi_ioctl.c | 214 ++++++++----- drivers/ata/libata-scsi.c | 9 + drivers/block/aoe/aoeblk.c | 1 + drivers/block/floppy.c | 3 + drivers/block/paride/pcd.c | 3 + drivers/block/paride/pd.c | 1 + drivers/block/paride/pf.c | 1 + drivers/block/pktcdvd.c | 26 +- drivers/block/sunvdc.c | 1 + drivers/block/virtio_blk.c | 3 + drivers/block/xen-blkfront.c | 1 + drivers/cdrom/cdrom.c | 35 +- drivers/cdrom/gdrom.c | 3 + drivers/ide/ide-cd.c | 38 +++ drivers/ide/ide-disk.c | 1 + drivers/ide/ide-floppy.c | 4 + drivers/ide/ide-floppy.h | 2 + drivers/ide/ide-floppy_ioctl.c | 35 ++ drivers/ide/ide-gd.c | 17 + drivers/ide/ide-ioctls.c | 47 ++- drivers/ide/ide-tape.c | 11 + drivers/scsi/aic94xx/aic94xx_init.c | 3 + drivers/scsi/ch.c | 9 +- drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 3 + drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 3 + drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 3 + drivers/scsi/ipr.c | 3 + drivers/scsi/isci/init.c | 3 + drivers/scsi/mvsas/mv_init.c | 3 + drivers/scsi/pm8001/pm8001_init.c | 3 + drivers/scsi/scsi_ioctl.c | 54 +++- drivers/scsi/sd.c | 50 ++- drivers/scsi/sg.c | 170 +++++----- drivers/scsi/sr.c | 53 ++- drivers/scsi/st.c | 51 +-- fs/Makefile | 2 +- fs/compat_ioctl.c | 261 --------------- fs/internal.h | 6 - fs/ioctl.c | 131 ++++++-- include/linux/blkdev.h | 7 + include/linux/compat.h | 18 ++ include/linux/falloc.h | 2 - include/linux/fs.h | 4 - include/linux/ide.h | 2 + include/linux/libata.h | 6 + include/scsi/scsi_ioctl.h | 1 + include/scsi/sg.h | 30 ++ 62 files changed, 1269 insertions(+), 1187 deletions(-) create mode 100644 Documentation/core-api/ioctl.rst delete mode 100644 block/compat_ioctl.c delete mode 100644 fs/compat_ioctl.c -- 2.20.0 Cc: linux-scsi(a)vger.kernel.org Cc: linux-block(a)vger.kernel.org Cc: y2038(a)lists.linaro.org Cc: linux-kernel(a)vger.kernel.org Cc: Christoph Hellwig <hch(a)lst.de> Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Cc: linux-doc(a)vger.kernel.org Cc: corbet(a)lwn.net Cc: viro(a)zeniv.linux.org.uk Cc: linux-fsdevel(a)vger.kernel.org Cc: Jens Axboe <axboe(a)kernel.dk>

6 years, 3 months

3
4
0 0

HI

by abdeikader aisamman

Good luck, try to answer immediately, you have good news ................................................................................................. Boa sorte, tente responder imediatamente, você tem boas notícias

6 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Y2038